Atuin Desktop: Çalıştırılabilir Runbook'lar

 (blog.atuin.sh)
1 puan yazan GN⁺ 2025-04-23 | 1 yorum | WhatsApp'ta paylaş
  • Atuin Desktop, belge gibi görünen ancak terminal gibi çalışan local-first bir runbook düzenleyicisi; tekrar eden operasyon prosedürlerini paylaşılabilir iş akışlarına dönüştürmeyi amaçlayan bir araç
  • Shell komutlarını, veritabanı sorgularını ve HTTP isteklerini script blokları ile yerleşik terminal, veritabanı istemcisi ve Prometheus grafikleri içinde birlikte ele alıyor
  • Atuin CLI senkronize edilebilen ve aranabilen shell geçmişi sağlıyorsa, Desktop bunu takım bilgisinin yalnızca kişisel hafızada ya da geçmişte kalmaması için çalıştırılabilir belgelere genişletiyor
  • Atuin ekibi bunu şimdiden CLI sürümleri, ortamlar arası altyapı migrasyonu, staging/prod çalıştırmaları, canlı veritabanı sorgularının yönetimi ve iş birliği için kullanıyor
  • Sıradaki adım olarak Team accounts ve shell geçmişinden runbook oluşturma özelliği planlanıyor; şu anda early access dağıtımı sürüyor

Kişisel hafızaya dayanan operasyon prosedürlerini belgelendirmek

  • Birçok altyapı işi, sorun çıktığında birinin hatırladığı birkaç komuta dayanıyor; dokümantasyon ise ya hiç olmuyor ya da kolayca güncelliğini yitiriyor
  • Gerçek çözüm ipuçları Slack thread'lerine, Notion belgelerine ve kişisel shell geçmişine dağılmış olabilir
  • Atuin CLI senkronize ve aranabilir shell geçmişiyle bu sorunun bir kısmını çözdü, ancak ekiplerin geçmişten fazlası olan paylaşılabilir iş akışlarına ihtiyacı var
  • Atuin Desktop, “runbook'lar çalıştırılabilmeli” yaklaşımıyla geliştirilmiş çalıştırılabilir bir runbook düzenleyicisi
  • İndirme bağlantısı download page üzerinden sunuluyor

Belgenin içinde çalışan terminal iş akışları

  • Atuin Desktop, gerçek terminal iş akışlarını bir belge arayüzü içinde çalıştıracak şekilde tasarlandı

  • Tek yerde toplanan bileşenler

    • Script blokları
    • Yerleşik terminal
    • Veritabanı istemcisi
    • Prometheus grafikleri

  • Sunulan özellikler

    • Daha az context switching: Shell komutlarını, veritabanı sorgularını ve HTTP isteklerini birbirine bağlıyor
    • Eskimeyen dokümantasyon: Doğrudan belgenin içinden çalıştırarak güncelliğini koruyor
    • Yeniden kullanılabilir otomasyon: Jinja tarzı şablonlarla dinamik runbook'lar oluşturuyor
    • Anında hatırlama: Gerçek shell geçmişinden otomatik tamamlama sağlıyor
    • Local-first, CRDT-powered: Terminalde çalışan şey runbook'ta da çalışıyor
    • Atuin Hub ile senkronizasyon ve paylaşım: Cihazlar ve ekipler arasında güncel kalmasını sağlıyor

Gerçek kullanım örnekleri ve dağıtım durumu

  • Atuin ekibi Atuin Desktop'ı zaten gerçek işlerde kullanıyor
    • Atuin CLI sürümleri
    • Ortamlar arası altyapı migrasyonu
    • staging veya prod çalıştırmaları
    • Canlı veritabanı sorgularını yönetme ve bu sorgular üzerinde iş birliği
  • Sıradaki özellikler arasında Team accounts ve shell geçmişinden runbook oluşturma yer alıyor
  • Dağıtım şu anda sürüyor; katılım için early access list kullanılabiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-04-23
Hacker News yorumları

  • Emacs’ı merak edenler org-babel ile benzer şeyler yapabilir
    Tek bir düz metin dosyası hem program hem belge/not defteri/web sitesi olabilir; bu da literary programming için ikna edici bir örnek
    İyi bir açıklama burada: https://osem.seagl.org/conferences/seagl2019/program/proposa...

    • Özellikler açısından org-babel, literary programming sistemleri arasında en güçlülerden biri; hatta belki de en güçlüsü olabilir
      Programlama kitaplarından çalışırken çok faydasını gördüm; daha sonra o literary program’a tekrar baktığımda, kitabı ilk okuduğum zamana göre çok daha hızlı kavrıyordum
      Literary kısımlar, o zamanki akıl yürütmemi ya da düşüncelerimi %100 hatırlamamamdan kaynaklanan “aptalca” sorulara yanıt veriyor
      Elbette bir öğrenme eğrisi var; bu yüzden böyle şeyleri öğrenmek istemeyenlere uygun değil
    • org-babel bu iş için çok uygun ve harika belgeler üretebilir
      Sunum videosuna[0] ve daha gelişmiş demoların bulunduğu Git deposuna[1] da bakabilirsiniz
      [0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
      [1]: https://gitlab.com/spudlyo/orgdemo2
    • BBEdit’in Shell Worksheets özelliği de benzer şekilde, açıklama metinleriyle tek tuşla çalıştırılabilen komutları bir arada kullanmaya izin veriyor

  • Yaklaşık 7 yıl önce bunu denemiştim: https://nurtch.com/
    Fikrin kendisinin çok avantajı var ve JupyterCon Paris 2023’te de bununla ilgili bir sunum yaptım: https://www.youtube.com/watch?v=TUYY2kHrTzs
    Belgenin içinde çalıştırılabilir kod olunca insanlar belgelere de PR inceleme iş akışını uygulamak istiyor; bu da ekip düzeyinde, wiki düzenlemekten daha fazla yatırım gerektiriyor

    • Benim de ilk düşüncem “neden Jupyter değil?” olmuştu; aynı şeyi düşünen birinin olması sevindirici

  • AWS’teyken ekibim için tam istediğim şey buydu
    Otomatikleştirmek için biraz riskli olan gerçekten çok sayıda operasyon işi var; bu, bu tür işleri tekrar tekrar otomasyona dönüştürerek büyütmek için bir yol sunuyor

    • Sadece kişisel görüşüm, işverenimin görüşü değil
      AWS’te ne zaman bulunduğunu merak ettim
      Son birkaç yılda AWS’te operasyon runbook’larını kodlaştırmaya ve güvenli biçimde otomatik çalıştırmaya yardım ederek operasyon angaryasını azaltan dahili bir platform servisi yaptık
      Atuin Desktop da bazı açılardan o servise benziyor ama o dahili servisin çok daha fazla özelliği vardı
    • AWS’teyken doğrudan wiki’den çalıştırılabilen bir şey yapmıştım
      CloudWatch sorguları, AWS CLI komutları gibi şeyleri kullanıcı girdileriyle birlikte çalıştırıyor; doğru kimlik bilgilerini güvenli biçimde alma ve girdiyi biçimlendirme ayar yükünü ortadan kaldırıyordu
      Daha sonra bunu doğrudan GitHub’dan çalışacak şekilde yeniden yaptım; GitHub wiki’de kullanıcı girdisiyle bir Lambda fonksiyonunu 4 satır kodla çağırma örneği burada: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
    • Amazon’da COVID öncesi dönemdeysen Eider’ı bu amaçla kullanabiliyor olurdun diye düşünüyorum
      IAM entegrasyonu olan barındırılan bir not defteriydi

  • Yerel Jupyter notebook’lardan nasıl farklı olduğunu merak ediyorum
    .ipynb içinde ! ya da % ile bunu yapamıyor muyuz?
    Bu şirketi ya da CLI ürününü pek bilmediğim için gerçekten soruyorum

    • Jupyter notebook’larından, tamamen Python kullanmadığım sürece kaçınmama neden olan en büyük şey Python
      pipenv/pyenv/conda/poetry/uv/dependencies.txt ve “bu notebook’u çalıştırmak için Python’u yükseltmem gerekiyor, ah… tamam” diye başlayıp 2 hafta sonra “o yükseltme eski Ansible’ı bozdu ve artık zar zor ayakta duran 15 sunucuyu düzeltemiyorum” noktasına gelmek tam bir cehennem
      Temel otomasyonlarda Python’dan uzak durmaya çalışıyorum
      Uğraştığım Python projeleri, bağımlılık ya da runtime sorunları yüzünden yılda en az bir kez bozuluyor; Ansible, build pipeline’ları, deploy.py gibi şeyler de buna dahil
      Jupyter notebook’ları devasa bir bağımlılık ağacı ve gereksinimler getirdiği için, böyle kritik ve temel otomasyonlarda kullanmam
      Elbette işim beni gereğinden fazla codebase ile uğraşmaya zorluyor; sadece son iki ayda bile en az 6 Python projesi vardı
      Bazıları Python 2.7 istiyor, bazıları kullanımdan kalkmış bir lib-something.h sürümü istiyor, bazıları en güncel teknolojiyi kullanıyor, bazıları ise belgelenmemiş olsa da gerçekte çok katı ve “sorumlu tek geliştiricinin makinesinde hiçbir şeyi güncellemediğin sürece çalışır” gibi bir durumda
      Puppet ya da Chef de Ruby olduğu için aynı derecede kötü ve aynı sorunları yaşıyor; ama Ruby’nin on yıllardır tek bir paket yönetim sistemine sahip olması gibi bir fark var
    • Jupyter notebook’ları terminal amacıyla kullanıldığında bana hep biraz hack gibi zorla uydurulmuş geliyor; bunu bir denemek isterim
    • Aynı soru bende de %100 var
      Genelde Jupyter hem esnek betik yazımı hem de işletim sistemi komut desteği veriyor gibi geliyor
      !/% ya da os.system() ile de mümkün

  • Bu, https://runme.dev ile çok benzer görünüyor

    • Runme’nin ortak geliştiricisiyim
      Çalıştırılabilir belgeleri seviyorum ve hâlâ yeterince yaygın olmadıklarını düşünüyorum

  • İlginç görünüyor
    Son zamanlarda Jupyter notebook alternatifi olarak https://marimo.io/ kullanmaya başladım; çeşitli iyileştirmeleri var ve bu da benzer yönde bir hareket gibi görünüyor

  • Yerel öncelikliyse zaten çürüme (rot) hedefidir
    Her şeyi konteyner içinde çalıştırmıyorsanız böyledir; konteyner içinde çalıştırıyorsanız da yerel olması önemli değildir
    Runbook kaydetmek istiyorsanız, sadece runbook kaydedin
    Metin dosyası, Confluence dokümanı, ekran kaydı, shell script vb. sayısız yöntem var
    İnsanlar zaten bunu yapmıyor ve UI daha havalı oldu diye birden daha fazla yapmayacaklar
    Kişisel olarak, sistemi X durumuna getirmek için bütün gün kod ya da doküman yazmak istemem
    X durumunu elle oluşturup sonra bir araçla durumu dump etmek, daha sonra o aracı yeniden çalıştırıp o durumu oluşturmak ya da zorlamak isterim
    Bilgisayarın o duruma nasıl ulaşacağını kodla açıklamak istemiyorum; adı farklı kod olan deklaratif konfigürasyon da kullanmak istemiyorum
    Kendim yapmak, snapshot almak ve replay etmek istiyorum
    Bash shell komutlarını izleme gibi bağımlılıklar olmadan her yerde, her sistemde çalışmalı

    • O zaman neden o duruma gelindiğine dair dokümantasyonu olmayan durumun ikili bir yığınına sahip olmuş olmuyor musunuz? Bakımı yapılabilir görünmüyor
      Dockerfile da aslında buna benzer, ama o duruma ulaşmak için geçilen adımları dosyada dokümante eder
    • İstediğiniz şey autoexpect'e daha yakın görünüyor
      https://linux.die.net/man/1/autoexpect
    • Bu tür prosedürler genelde pek taşınabilir değildir ve farklı sistemlerin her birinde tekrarlanması gerekir
      O noktada, X durumuna ulaşmak için gereken adımlara otomatik dönüştürülebilen bir deklaratif tanımın zaten olması daha iyidir
    • Bu, Docker bildirimi idi
    • Anlattığınız şey Ansible'a daha yakın görünüyor
      Paketin kurulu olup olmadığı, dosyanın var olup olmadığı ya da belirli içeriğe sahip olup olmadığı gibi genel işler için modüller kullanır; deklaratiftir ve idempotenttir

  • Atuin CLI ve senkronizasyon sunucusu gibi bunun da açık kaynak olup olmayacağını merak ediyorum
    Ürünleştirilecek mi?

  • Bunun neden gerekli olduğunu tam anlamıyorum
    Kaçırdığım şeyi açıklayabilir misiniz? Neden basit bir shell script yerine bunu kullanmalıyım?

    • Runbook deneyimim şöyleydi
      Birden fazla şeyden sorumlu bir ekiptesiniz; bazılarını çok iyi biliyor ve sıkça elliyorsunuz, bazılarınınsa varlığını sadece belli belirsiz biliyor ve neredeyse hiç dokunmuyorsunuz
      İkinci gruba giren X bozuluyor
      X'i gerçekten bilen herkes tatilde/ölmüş/toplantıda
      Neyse ki bu durumda ne yapılacağını açıklayan bir doküman var
      Ama o doküman, nasıl olduysa eskimiş ve yanlış olma gibi kötü bilgi mucizesini sergiliyor
      Çözmeye çalıştığı sorun bu
      Yapımcıyla biraz konuştuğum kadarıyla niyet, Jupyter Notebooks ile Ansible Tower arasında bir şey yapmak gibi
      Dokümantasyonun, script'lerin ve metriklerin birbirine yakın durması sayesinde neyin yanlış olduğunu, nasıl düzeltileceğini ve düzeltmenin işe yarayıp yaramadığını anlamayı kolaylaştıran bir yaklaşım
      [1] Açıklama: atuin Discord'unu yönetmeye yardımcı oluyorum
    • Shell script'ler için edebi programlama gibi görünüyor
      Bu yüzden “Runbooks That Run”
    • Rust ile yazıldığı ve burası Hacker News olduğu için
    • Dağıtımın genellikle Ansible ya da Deployer gibi araçlarla yapılandırılmasının amacı ne olabilir? Ve yaygın işleri yapan Python script'lerini ayrıca paketleyip hepsini Git deposuna koymanın nedeni?
      Bazı insanlar belirli iş akışlarını ya da araç akışlarını sevdiği için bunları yapar
      Yeterince kişiye uyarsa pazarlanabilir olabilir, uymayabilir de
      Kişisel projemde PHP dağıtım sürecini sırf öyle istediğim için kullanıyorum; benim ayrıca yapmam gerekmeden işin %60'ını hallediyor
      Ona ait runbook, araca gömülü görevler ve tüm sunucu dağıtımıyla aynı Git deposunda
      Hatırlamam gereken ayrı bir komutun olduğu rastgele bir yere ya da shell script'e koymak istemiyorum
      Programcılar için kod, karmaşıklıktan kaçınıp basit bir fonksiyonel stili koruduğunda özünde kendi kendini dokümante eder
      Sadece bazen “MySQL kullanıcısı oluştur, parolayı döndür, ilgili servislere yeni kullanıcı/parola kombinasyonunu yansıt ve VPN engellemesi başarısız olmuş olabilir diye işten çıkarılan çalışanın kimlik bilgilerine sahip eski kullanıcıyı kaldır” gibi basit olmayan akışlara yorum eklemek yeterli olur

  • Hayalini kurduğum araç, tüm araçların terminal arayüzü sunması; böylece kafamdaki tüm bağlamı içeren dev bir kitap oluşturabilmek
    Jira, Datadog, GitHub vb.'yi tek ekranda toplamak gibi

    • Kişisel olarak biraz daha kullanıcı dostu bir TUI de hoşuma gider
      Her dahili servis için bileşenleri olan dahili bir TUI framework'ü olduğunu ve bunları Lego gibi birleştirip kişiselleştirilmiş TUI panoları yapabildiğinizi hayal edin
      Şirkette yan proje olarak denenebilecek bir işe benziyor; devasa bir iş olurdu ama ilginç olurdu
    • API olması bile yeterli; bunun üstüne araçlar inşa edilebilir
      İdeal bir dünyada tüm servislerin, araçların ve uygulamaların kullanabileceğim bir API sunmasını isterdim
      Örneğin buzdolabı kapısı çok uzun süre açık kalırsa API polling ya da webhook ile algılayıp, Roomba API'sini kullanarak onu kapatmaya göndermek gibi
      Neden olmasın? API dünyası
    • GitHub ve Datadog'un zaten resmi CLI araçları var
    • wtfutil gibi bir şeyden bahsediyor olabilirsiniz
      Geliştirmesi 1 yıldır durmuş gibi görünse de fikir kabaca bu
      https://wtfutil.com/
    • Öyleyse MCP hoşunuza gidebilir