Atuin Desktop: Runbook yang Dapat Dijalankan

 (blog.atuin.sh)
1 poin oleh GN⁺ 2025-04-23 | 1 komentar | Bagikan ke WhatsApp
  • Atuin Desktop adalah editor runbook local-first yang terlihat seperti dokumen tetapi berjalan seperti terminal, sebuah alat yang bertujuan mengubah prosedur operasional berulang menjadi alur kerja yang bisa dibagikan
  • Perintah shell, kueri database, dan permintaan HTTP ditangani bersama di dalam blok skrip serta terminal bawaan, klien database, dan grafik Prometheus yang terintegrasi
  • Jika Atuin CLI menyediakan riwayat shell yang dapat disinkronkan dan dicari, Desktop memperluasnya menjadi dokumen yang dapat dijalankan agar pengetahuan tim tidak hanya tersimpan dalam ingatan pribadi atau riwayat
  • Tim Atuin sudah menggunakannya untuk rilis CLI, migrasi infrastruktur lintas environment, eksekusi staging/prod, serta pengelolaan dan kolaborasi kueri database live
  • Langkah berikutnya adalah merencanakan Team accounts dan kemampuan membuat runbook dari riwayat shell, dan saat ini mereka sedang membuka early access

Mendokumentasikan prosedur operasional yang sebelumnya bergantung pada ingatan pribadi

  • Banyak pekerjaan infrastruktur saat terjadi insiden bergantung pada beberapa perintah yang diingat seseorang, sementara dokumentasi sering kali tidak ada atau mudah usang
  • Petunjuk penyelesaian yang sebenarnya bisa tersebar di thread Slack, dokumen Notion, atau riwayat shell pribadi
  • Atuin CLI menyelesaikan sebagian masalah ini dengan riwayat shell yang tersinkronisasi dan dapat dicari, tetapi tim membutuhkan alur kerja yang bisa dibagikan yang lebih dari sekadar riwayat
  • Atuin Desktop adalah editor runbook eksekusional yang dibuat dari premis bahwa “runbook harus bisa dijalankan”
  • Unduhan tersedia di halaman unduhan

Alur kerja terminal yang berjalan di dalam dokumen

  • Atuin Desktop dirancang agar alur kerja terminal nyata dapat dijalankan di dalam UI dokumen

  • Elemen kerja yang disatukan di satu tempat

    • blok skrip
    • terminal bawaan
    • klien database
    • grafik Prometheus

  • Fitur yang disediakan

    • Mengurangi perpindahan konteks: menghubungkan perintah shell, kueri database, dan permintaan HTTP
    • Dokumentasi yang tidak membusuk: menjaga tetap mutakhir dengan menjalankannya langsung dari dokumen
    • Otomatisasi yang dapat digunakan ulang: membuat runbook dinamis dengan template bergaya Jinja
    • Pemanggilan ulang instan: menyediakan pelengkapan otomatis dari riwayat shell nyata
    • Local-first, CRDT-powered: apa pun yang berjalan di terminal juga berjalan di runbook
    • Sinkronisasi dan berbagi lewat Atuin Hub: menjaga status tetap terbaru di antara perangkat dan tim

Kasus penggunaan nyata dan status peluncuran

  • Tim Atuin sudah menggunakan Atuin Desktop untuk pekerjaan nyata
    • rilis Atuin CLI
    • migrasi infrastruktur lintas environment
    • eksekusi staging atau prod
    • pengelolaan dan kolaborasi kueri database live
  • Fitur berikutnya yang direncanakan adalah Team accounts dan kemampuan membuat runbook dari riwayat shell
  • Saat ini sedang diluncurkan, dan Anda dapat ikut melalui early access list

Bacaan terkait

1 komentar

 
GN⁺ 2025-04-23
Pendapat Hacker News

  • Jika Anda penasaran dengan Emacs, Anda bisa melakukan hal serupa dengan org-babel
    Satu berkas teks polos bisa menjadi program sekaligus dokumen/notebook/situs web, dan ini merupakan contoh yang meyakinkan dari literate programming
    Penjelasan yang bagus ada di sini: https://osem.seagl.org/conferences/seagl2019/program/proposa...

    • Dari sisi fitur, org-babel termasuk salah satu sistem literate programming paling kuat, bahkan mungkin yang terkuat
      Ini sangat membantu saat belajar dari buku pemrograman, dan ketika kemudian melihat kembali literate program itu, pemahaman kembali jauh lebih cepat dibanding saat pertama kali membaca bukunya
      Bagian literate-nya menjawab pertanyaan “bodoh” yang muncul karena tidak 100% mengingat penalaran atau pikiran saya saat itu
      Tentu saja ada learning curve, jadi tidak cocok bagi orang yang tidak ingin mempelajarinya
    • org-babel sangat cocok untuk pekerjaan ini dan bisa menghasilkan dokumentasi yang bagus
      Anda juga bisa melihat video presentasi[0] dan repositori Git[1] dengan demo yang lebih lanjut
      [0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
      [1]: https://gitlab.com/spudlyo/orgdemo2
    • Shell Worksheets di BBEdit juga serupa: Anda bisa mencampur teks penjelasan dan perintah yang dapat dijalankan dengan sekali tombol

  • Sekitar 7 tahun lalu saya pernah mencoba ini: https://nurtch.com/
    Idenya sendiri punya banyak kelebihan, dan saya juga pernah memberi presentasi terkait di JupyterCon Paris 2023: https://www.youtube.com/watch?v=TUYY2kHrTzs
    Jika ada kode yang bisa dijalankan di dalam dokumen, orang-orang juga ingin menerapkan alur kerja review PR pada dokumen, dan ini membutuhkan investasi tim yang lebih besar daripada sekadar menyunting wiki

    • Pikiran pertama saya juga “kenapa bukan Jupyter?”, jadi senang melihat ada orang lain yang berpikiran sama

  • Ini persis barang yang saya inginkan untuk tim kami saat berada di AWS
    Ada sangat banyak pekerjaan operasional yang sedikit terlalu berisiko untuk diautomasi penuh, dan ini menyediakan jalur untuk secara bertahap menumbuhkannya menjadi otomasi yang berulang

    • Ini hanya pendapat pribadi dan bukan posisi pemberi kerja
      Saya penasaran kapan Anda berada di AWS
      Dalam beberapa tahun terakhir, AWS membangun layanan platform internal yang membantu mengodekan runbook operasional dan menjalankannya otomatis dengan aman untuk mengurangi pekerjaan operasional remeh
      Atuin Desktop dalam beberapa hal mirip dengan layanan itu, tetapi layanan internal tersebut punya fitur jauh lebih banyak
    • Saat berada di AWS, saya membuat sesuatu yang bisa dijalankan langsung dari wiki
      Caranya menjalankan hal-hal seperti kueri CloudWatch dan perintah AWS CLI beserta input pengguna, tetapi menghilangkan beban konfigurasi untuk mengambil kredensial yang tepat secara aman dan memformat input
      Setelah itu saya membuat ulang agar bisa dijalankan langsung dari GitHub, dan contoh memanggil fungsi Lambda dari wiki GitHub dengan input pengguna dalam 4 baris kode ada di sini: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
    • Jika itu masa sebelum COVID saat berada di Amazon, sepertinya Eider bisa dipakai untuk tujuan seperti itu
      Itu adalah notebook ter-hosting dengan integrasi IAM

  • Saya penasaran apa bedanya dengan notebook Jupyter lokal
    Bukankah ini bisa dilakukan di .ipynb dengan ! atau %?
    Saya benar-benar bertanya karena tidak terlalu mengenal perusahaan ini atau produk CLI-nya

    • Alasan terbesar yang membuat saya menghindari notebook Jupyter kecuali untuk pekerjaan yang sepenuhnya hanya Python adalah Python
      Alur yang dimulai dari pipenv/pyenv/conda/poetry/uv/dependencies.txt dan “untuk menjalankan notebook ini harus menaikkan versi Python, ya… baiklah”, lalu dua minggu kemudian menjadi “upgrade itu merusak Ansible lama dan sekarang saya tidak bisa memperbaiki 15 server yang nyaris bertahan” adalah neraka
      Untuk otomasi fondasional, saya berusaha menjauhi Python
      Proyek Python yang saya tangani rusak setidaknya sekali setahun karena masalah dependensi atau runtime, termasuk Ansible, pipeline build, dan hal seperti deploy.py
      Notebook Jupyter membawa pohon dependensi dan persyaratan yang besar, jadi saya tidak akan menggunakannya untuk otomasi yang penting dan mendasar seperti itu
      Tentu saja pekerjaan saya membuat saya menangani terlalu banyak codebase, dan dalam dua bulan terakhir saja ada setidaknya 6 proyek Python
      Ada yang membutuhkan Python 2.7, ada yang membutuhkan versi lib-something.h yang sudah ditinggalkan, ada yang paling mutakhir, dan ada yang tidak terdokumentasi tetapi pada praktiknya sangat ketat sampai statusnya seperti “berfungsi selama satu mesin milik satu developer penanggung jawab tidak memperbarui apa pun”
      Puppet atau Chef juga sama buruknya karena Ruby dan mengalami masalah yang sama, tetapi bedanya Ruby selama puluhan tahun hanya punya satu sistem manajemen paket
    • Notebook Jupyter selalu terasa agak seperti hack yang dipaksakan untuk penggunaan terminal, jadi saya ingin mencoba ini
    • Saya 100% punya pertanyaan yang sama
      Biasanya Jupyter terasa memberikan scripting yang fleksibel sekaligus dukungan perintah sistem operasi
      Bisa juga dengan !/% atau os.system()

  • Ini terlihat sangat mirip dengan https://runme.dev

    • Saya salah satu pembuat Runme
      Saya menyukai dokumen yang dapat dijalankan, dan menurut saya jumlahnya masih belum cukup banyak

  • Terlihat menarik
    Belakangan ini saya mulai memakai https://marimo.io/ sebagai pengganti notebook Jupyter, dan ada banyak peningkatan; ini juga terlihat seperti gerakan ke arah yang serupa

  • Jika mengutamakan lokal, itu sudah menjadi sasaran pembusukan (rot)
    Begitu adanya jika tidak semuanya dijalankan di container; kalau dijalankan di container, fakta bahwa itu lokal tidak penting
    Kalau ingin mencatat runbook, ya catat saja runbook-nya
    Ada tak terhitung cara: file teks, dokumen Confluence, rekaman layar, skrip shell, dan sebagainya
    Orang-orang sekarang pun sudah tidak melakukannya, dan UI yang lebih keren tidak akan tiba-tiba membuat mereka lebih rajin melakukannya
    Secara pribadi, saya tidak ingin menghabiskan seharian menulis kode atau dokumentasi untuk membuat sistem berada dalam keadaan X
    Saya ingin membuat keadaan X secara manual, lalu memakai alat untuk men-dump keadaan itu, dan nanti menjalankan alat itu lagi untuk membuat atau memaksakan keadaan tersebut
    Saya tidak ingin menjelaskan dengan kode bagaimana komputer mencapai keadaan itu, dan juga tidak ingin memakai konfigurasi deklaratif yang pada dasarnya hanya kode dengan nama berbeda
    Saya ingin melakukannya langsung, mengambil snapshot, lalu memutarnya ulang
    Ini harus berjalan di mana saja dan pada sistem apa pun tanpa bergantung pada pemantauan perintah shell Bash

    • Bukankah dengan begitu yang dimiliki hanya gumpalan biner berisi keadaan tanpa dokumentasi tentang mengapa bisa menjadi keadaan itu? Kelihatannya tidak mudah dipelihara
      Dockerfile pada dasarnya mirip dengan ini, tetapi mendokumentasikan langkah-langkah yang ditempuh untuk mencapai keadaan tersebut dalam sebuah file
    • Yang diinginkan tampaknya lebih dekat ke autoexpect
      https://linux.die.net/man/1/autoexpect
    • Prosedur seperti itu umumnya kurang portabel dan harus diulang untuk tiap sistem yang berbeda
      Pada titik itu, lebih baik sudah ada deskripsi deklaratif yang bisa diubah otomatis menjadi langkah-langkah yang diperlukan untuk mencapai keadaan X
    • Itu tadi deklarasi Docker
    • Yang dijelaskan tampaknya lebih dekat ke Ansible
      Untuk pekerjaan umum seperti memastikan paket sudah terpasang, file ada atau memiliki isi tertentu, ia memakai modul, bersifat deklaratif, dan idempoten

  • Saya penasaran apakah ini juga akan menjadi open source seperti Atuin CLI dan server sinkronisasinya
    Apakah ini akan diproduktisasi?

  • Saya kurang paham mengapa ini dibutuhkan
    Bisa jelaskan apa yang saya lewatkan? Mengapa harus memakai ini alih-alih skrip shell sederhana?

    • Pengalaman saya dengan runbook seperti ini
      Saya berada di tim yang menangani banyak hal; sebagian sangat kami pahami dan sering kami sentuh, sementara sebagian lain hanya samar-samar kami tahu ada dan hampir tidak pernah kami utak-atik
      X, yang termasuk kelompok terakhir, rusak
      Semua orang yang benar-benar tahu X sedang cuti/meninggal/rapat
      Untungnya ada dokumen yang menjelaskan apa yang harus dilakukan dalam situasi ini
      Namun entah bagaimana dokumen itu menunjukkan keajaiban informasi buruk: usang dan salah
      Inilah masalah yang ingin diselesaikan
      Dari sedikit pembicaraan saya dengan pembuatnya, niatnya lebih mirip membuat sesuatu di tengah antara Jupyter Notebooks dan Ansible Tower
      Dokumentasi, skrip, dan metrik ditempatkan berdekatan sehingga lebih mudah mengetahui apa yang salah, bagaimana memperbaikinya, dan apakah perbaikannya berhasil
      [1] Pengungkapan: saya membantu mengoperasikan Discord atuin
    • Ini tampak seperti pemrograman literer untuk skrip shell
      Karena itu “Runbooks That Run”
    • Karena ditulis dalam Rust dan ini Hacker News
    • Apa tujuan deployment biasanya disusun dengan alat seperti Ansible atau Deployer? Dan mengapa skrip Python yang menjalankan pekerjaan umum ikut dipaketkan lalu semuanya dimasukkan ke repositori Git?
      Sebagian orang menyukai alur kerja atau alur alat tertentu, jadi mereka membuatnya saja
      Jika cocok untuk cukup banyak orang, mungkin ada pasarnya, mungkin juga tidak
      Untuk proyek pribadi, saya memakai proses deployment PHP hanya karena saya ingin begitu; proses itu menangani 60% pekerjaan tanpa saya perlu melakukannya sendiri
      Runbook untuk itu adalah task yang tertanam di alat dan berada di repositori Git yang sama dengan deployment server penuh
      Saya tidak ingin menaruhnya di tempat acak atau skrip shell yang mengharuskan saya mengingat perintah terpisah
      Bagi programmer, kode pada dasarnya menjadi mendokumentasikan diri sendiri jika menghindari kompleksitas dan mempertahankan gaya fungsional yang sederhana
      Sesekali hanya perlu memberi komentar pada bagian yang bukan alur sederhana, seperti “membuat pengguna MySQL, merotasi kata sandi, memperbarui layanan terkait dengan kombinasi pengguna/kata sandi baru, dan menghapus pengguna lama yang kredensialnya mungkin masih dimiliki karyawan yang dipecat kalau pemblokiran VPN gagal”

  • Alat yang saya impikan adalah semua alat menyediakan antarmuka terminal, sehingga bisa membuat sebuah buku raksasa berisi semua konteks yang ada di kepala
    Misalnya mengumpulkan Jira, Datadog, GitHub, dan lainnya dalam satu layar

    • Secara pribadi, saya juga suka TUI yang sedikit lebih ramah pengguna
      Bayangkan ada framework TUI internal dengan komponen untuk tiap layanan internal, lalu itu bisa dirakit seperti Lego untuk membuat dashboard TUI yang dipersonalisasi
      Sepertinya cocok dijadikan proyek sampingan di perusahaan, dan walau pekerjaannya akan sangat besar, tampaknya menarik
    • API saja sudah cukup, dan alat bisa dibuat di atasnya
      Di dunia ideal, semua layanan, alat, dan aplikasi menyediakan API yang bisa saya pakai
      Misalnya jika pintu kulkas terbuka terlalu lama, itu dideteksi lewat polling API atau webhook, lalu memakai API Roomba untuk menyuruhnya menutup pintu
      Kenapa tidak? Ini dunia API
    • GitHub dan Datadog sudah memiliki alat CLI resmi
    • Mungkin yang dimaksud adalah sesuatu seperti wtfutil
      Walau pengembangannya tampaknya berhenti selama setahun, kurang lebih idenya seperti itu
      https://wtfutil.com/
    • Kalau begitu, mungkin Anda akan menyukai MCP