Atuin Desktop: Runbook có thể thực thi
(blog.atuin.sh)- Atuin Desktop là trình soạn thảo runbook ưu tiên cục bộ trông như tài liệu nhưng có thể thực thi như terminal, nhằm biến các quy trình vận hành lặp đi lặp lại thành các workflow có thể chia sẻ
- Công cụ này xử lý lệnh shell, truy vấn cơ sở dữ liệu và yêu cầu HTTP cùng nhau trong khối script, terminal tích hợp, trình khách cơ sở dữ liệu và biểu đồ Prometheus tích hợp
- Nếu Atuin CLI cung cấp lịch sử shell có thể đồng bộ và tìm kiếm, thì Desktop mở rộng điều đó thành tài liệu có thể thực thi để kiến thức của nhóm không chỉ nằm trong trí nhớ cá nhân hay lịch sử
- Nhóm Atuin đã dùng nó cho việc phát hành CLI, di chuyển hạ tầng giữa các môi trường, thao tác trên staging/prod, cũng như quản lý và cộng tác với truy vấn cơ sở dữ liệu trực tiếp
- Bước tiếp theo là lên kế hoạch cho Team accounts và tính năng tạo runbook từ lịch sử shell; hiện tại đang phát hành bản early access
Ghi chép lại các quy trình vận hành từng phụ thuộc vào trí nhớ cá nhân
- Nhiều tác vụ hạ tầng khi xảy ra sự cố vẫn phụ thuộc vào vài lệnh mà ai đó còn nhớ, còn tài liệu thì либо không có hoặc dễ trở nên lỗi thời
- Manh mối để xử lý thực tế có thể nằm rải rác trong thread Slack, tài liệu Notion hoặc lịch sử shell cá nhân
- Atuin CLI đã giải quyết một phần vấn đề này bằng lịch sử shell được đồng bộ và có thể tìm kiếm, nhưng các nhóm cần workflow có thể chia sẻ chứ không chỉ là lịch sử
- Atuin Desktop là trình soạn thảo runbook thực thi được, được xây dựng trên tiền đề rằng “runbook phải có thể chạy được”
- Có thể tải xuống từ trang tải về
Workflow terminal chạy ngay trong tài liệu
- Atuin Desktop được thiết kế để chạy các workflow terminal thực sự ngay trong giao diện tài liệu
-
Các thành phần công việc được gom về một chỗ
- Khối script
- Terminal tích hợp
- Trình khách cơ sở dữ liệu
- Biểu đồ Prometheus
-
Tính năng cung cấp
- Giảm chuyển đổi ngữ cảnh: kết nối lệnh shell, truy vấn cơ sở dữ liệu và yêu cầu HTTP
- Tài liệu không bị mục nát: chạy trực tiếp trong tài liệu để luôn cập nhật
- Tự động hóa có thể tái sử dụng: tạo runbook động bằng mẫu kiểu Jinja
- Gợi nhớ tức thì: cung cấp tự động hoàn thành từ lịch sử shell thực tế
- Local-first, CRDT-powered: thứ gì chạy được trong terminal thì cũng chạy được trong runbook
- Đồng bộ và chia sẻ qua Atuin Hub: giữ trạng thái mới nhất giữa các thiết bị và nhóm
Trường hợp sử dụng thực tế và tình trạng phát hành
- Nhóm Atuin đã dùng Atuin Desktop cho công việc thực tế
- Phát hành Atuin CLI
- Di chuyển hạ tầng giữa các môi trường
- Thao tác trên staging hoặc prod
- Quản lý và cộng tác với truy vấn cơ sở dữ liệu trực tiếp
- Các tính năng tiếp theo dự kiến gồm Team accounts và khả năng tạo runbook từ lịch sử shell
- Hiện đang được phát hành, và có thể tham gia qua danh sách early access
1 bình luận
Ý kiến trên Hacker News
Nếu bạn tò mò về Emacs, có thể làm việc tương tự bằng org-babel
Một tệp văn bản thuần có thể vừa là chương trình, vừa là tài liệu/sổ tay/trang web, và là một ví dụ thuyết phục về lập trình văn chương
Có phần giải thích hay ở đây: https://osem.seagl.org/conferences/seagl2019/program/proposa...
Nó đã giúp tôi rất nhiều khi học qua sách lập trình, và sau này khi xem lại chương trình văn chương đó thì hiểu lại nhanh hơn nhiều so với lúc đọc sách lần đầu
Phần văn chương trả lời những câu hỏi “ngớ ngẩn” nảy sinh vì tôi không nhớ 100% lập luận hay suy nghĩ của mình lúc đó
Tất nhiên là có đường cong học tập, nên không phù hợp với những người không muốn học những thứ như vậy
Bạn cũng có thể xem video bài thuyết trình[0] và kho Git có bản demo nâng cao hơn[1]
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/orgdemo2
Khoảng 7 năm trước tôi đã thử làm việc này: https://nurtch.com/
Bản thân ý tưởng có rất nhiều điểm mạnh, và tôi cũng đã có bài nói liên quan tại JupyterCon Paris 2023: https://www.youtube.com/watch?v=TUYY2kHrTzs
Khi trong tài liệu có mã có thể thực thi, mọi người cũng muốn áp dụng quy trình review PR cho tài liệu, mà việc này đòi hỏi đầu tư ở cấp đội nhóm nhiều hơn so với chỉnh sửa wiki
Đây đúng là thứ tôi từng muốn có cho đội của mình khi còn ở AWS
Có rất nhiều tác vụ vận hành hơi nguy hiểm để tự động hóa hoàn toàn, và công cụ này cung cấp một lộ trình phát triển dần thành tự động hóa lặp lại được cho những tác vụ như vậy
Tôi tò mò bạn ở AWS vào thời điểm nào
Trong vài năm gần đây, AWS đã xây dựng một dịch vụ nền tảng nội bộ giúp mã hóa runbook vận hành và tự động chạy an toàn để giảm việc vặt vận hành
Atuin Desktop ở một số khía cạnh cũng giống dịch vụ đó, nhưng dịch vụ nội bộ kia có nhiều tính năng hơn rất nhiều
Nó chạy những thứ như truy vấn CloudWatch, lệnh AWS CLI cùng với đầu vào từ người dùng, đồng thời loại bỏ gánh nặng cấu hình cho việc lấy đúng thông tin xác thực một cách an toàn và định dạng đầu vào
Sau đó tôi làm lại để chạy trực tiếp từ GitHub, và đây là ví dụ gọi một hàm Lambda bằng đầu vào người dùng từ GitHub wiki với 4 dòng mã: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
Đó là notebook được host có tích hợp IAM
Tôi tò mò nó khác gì so với Jupyter notebook chạy cục bộ
Không phải có thể làm việc này trong
.ipynbbằng!hoặc%sao?Tôi không rành công ty này hay sản phẩm CLI của họ, nên đây là câu hỏi thật lòng
Chuỗi bắt đầu từ pipenv/pyenv/conda/poetry/uv/dependencies.txt và “muốn chạy notebook này thì phải nâng Python lên, à… được rồi”, rồi 2 tuần sau thành “bản nâng cấp đó làm hỏng Ansible cũ, và giờ tôi không sửa được 15 máy chủ vốn đang chật vật cầm cự” đúng là địa ngục
Tôi cố tránh Python trong các tự động hóa nền tảng
Các dự án Python tôi xử lý bị hỏng vì vấn đề phụ thuộc hoặc runtime ít nhất mỗi năm một lần, và điều đó cũng áp dụng cho Ansible, pipeline build, những thứ như
deploy.pyJupyter notebook kéo theo một cây phụ thuộc và yêu cầu khổng lồ, nên tôi sẽ không dùng nó cho các tự động hóa quan trọng và mang tính nền tảng như vậy
Tất nhiên công việc của tôi buộc phải đụng tới quá nhiều codebase, và chỉ riêng hai tháng gần đây đã có ít nhất 6 dự án Python
Có cái cần Python 2.7, có cái cần một phiên bản
lib-something.hđã bị bỏ, có cái thì rất mới, có cái không được ghi tài liệu nhưng thực tế lại cực kỳ nghiêm ngặt, kiểu “chỉ chạy được trên máy của một lập trình viên phụ trách, miễn là không cập nhật gì cả”Puppet hay Chef cũng tệ y như vậy và gặp cùng vấn đề vì dùng Ruby, nhưng điểm khác là Ruby chỉ có một hệ thống quản lý gói trong suốt nhiều thập kỷ
Thông thường Jupyter có vẻ cung cấp cả scripting linh hoạt lẫn hỗ trợ lệnh hệ điều hành
Cũng có thể làm bằng
!/%hoặcos.system()Cái này trông rất giống https://runme.dev
Tôi thích tài liệu có thể thực thi, và thấy hiện vẫn chưa có đủ nhiều loại này
Trông thú vị
Gần đây tôi bắt đầu dùng https://marimo.io/ như một giải pháp thay thế Jupyter notebook, có nhiều cải tiến, và cái này cũng có vẻ là một chuyển động theo hướng tương tự
Nếu đặt ưu tiên local-first thì đã là đối tượng của sự mục nát (rot) rồi
Trừ khi mọi thứ đều chạy trong container; còn nếu chạy trong container thì việc “local” cũng không quan trọng
Nếu muốn ghi lại runbook thì cứ ghi lại runbook
Có vô số cách: tệp văn bản, tài liệu Confluence, quay màn hình, shell script, v.v.
Mọi người vốn đã không làm việc đó, và UI trông đẹp hơn cũng sẽ không khiến họ đột nhiên làm nhiều hơn
Cá nhân tôi không muốn dành cả ngày viết code hay tài liệu chỉ để đưa hệ thống vào trạng thái X
Tôi muốn tự tay tạo trạng thái X, rồi dùng công cụ dump trạng thái đó, và sau này chạy lại công cụ ấy để tạo lại hoặc cưỡng chế trạng thái đó
Tôi không muốn mô tả bằng code cách máy tính đạt tới trạng thái đó, cũng không muốn dùng cấu hình khai báo vốn chỉ là code dưới một cái tên khác
Tôi muốn tự làm, chụp snapshot, rồi phát lại
Nó phải hoạt động ở bất cứ đâu, trên bất kỳ hệ thống nào, mà không phụ thuộc vào kiểu theo dõi lệnh Bash shell
Dockerfile về cơ bản cũng tương tự, nhưng nó ghi lại trong tệp các bước đã đi qua để đạt tới trạng thái đó
https://linux.die.net/man/1/autoexpect
Đến mức đó thì tốt hơn là đã có một mô tả khai báo có thể tự động chuyển thành các bước cần thiết để đạt tới trạng thái X
Nó dùng module cho các tác vụ phổ biến như kiểm tra package đã được cài chưa, tệp có tồn tại hay có nội dung cụ thể không; mang tính khai báo và idempotent
Tôi tò mò liệu cái này có trở thành open source như Atuin CLI và sync server không
Nó có định được sản phẩm hóa không?
Dù vậy thấy nó được công bố cũng vui
Tôi không rõ vì sao cần cái này
Có thể giải thích tôi đang bỏ lỡ điều gì không? Vì sao nên dùng nó thay vì một shell script đơn giản?
Bạn ở trong một đội phụ trách nhiều đối tượng; trong đó có vài thứ bạn biết rất rõ và thường xuyên đụng đến, nhưng cũng có những thứ bạn chỉ mơ hồ biết là tồn tại và gần như không chạm vào
X thuộc nhóm sau bị hỏng
Tất cả những người thật sự biết X đều đang nghỉ phép/đã chết/đang họp
May thay có tài liệu giải thích phải làm gì trong tình huống này
Nhưng tài liệu đó bằng cách nào đó lại thể hiện một phép màu của thông tin tệ: cũ kỹ và sai
Đây là vấn đề mà nó muốn giải quyết
Theo một vài trao đổi với người tạo ra nó, ý định gần giống với việc tạo ra thứ nằm giữa Jupyter Notebooks và Ansible Tower
Tài liệu, script và chỉ số được đặt gần nhau hơn, để dễ biết điều gì đang sai, sửa thế nào, và việc sửa có hiệu quả hay không
[1] Công khai: tôi đang giúp vận hành Discord của atuin
Vì vậy mới là “Runbooks That Run”
Một số người thích workflow hoặc luồng công cụ cụ thể nên cứ thế tạo ra thôi
Nếu phù hợp với đủ nhiều người thì có thể có tính thị trường, cũng có thể không
Trong dự án cá nhân, tôi dùng quy trình deploy PHP chỉ vì muốn vậy; nó xử lý 60% công việc mà tôi không phải tự làm riêng
Runbook cho nó là các tác vụ tích hợp trong công cụ và nằm trong cùng Git repository với toàn bộ phần triển khai server
Tôi không muốn đặt nó ở một nơi tùy tiện hay trong shell script mà phải nhớ thêm lệnh riêng
Với lập trình viên, code về bản chất có thể tự ghi tài liệu nếu tránh phức tạp và giữ phong cách hàm đơn giản
Thỉnh thoảng chỉ cần chú thích những phần không phải luồng đơn giản, kiểu “tạo người dùng MySQL, xoay vòng mật khẩu, phản ánh cặp user/password mới vào các dịch vụ liên quan, và xóa người dùng cũ mà nhân viên đã bị sa thải vẫn có thông tin đăng nhập trong trường hợp việc chặn VPN có thể đã thất bại”
Công cụ tôi mơ ước là mọi công cụ đều cung cấp giao diện terminal, để có thể tạo một cuốn sách khổng lồ chứa toàn bộ ngữ cảnh trong đầu
Kiểu gom Jira, Datadog, GitHub, v.v. vào cùng một màn hình
Hãy tưởng tượng có một framework TUI nội bộ với các component cho từng dịch vụ nội bộ, rồi có thể lắp ghép chúng như Lego để tạo dashboard TUI cá nhân hóa
Nghe như một việc đáng làm bên lề trong công ty, sẽ rất lớn nhưng có vẻ thú vị
Trong thế giới lý tưởng, tôi muốn mọi dịch vụ, công cụ và ứng dụng đều cung cấp API mà tôi có thể dùng
Ví dụ, nếu cửa tủ lạnh mở quá lâu thì phát hiện bằng polling API hoặc webhook, rồi dùng Roomba API để gửi nó đi đóng cửa
Sao lại không được? Đây là thế giới của API mà
Có vẻ việc phát triển đã dừng khoảng 1 năm, nhưng ý tưởng đại khái là vậy
https://wtfutil.com/