1 puan yazan GN⁺ 2025-04-23 | 1 yorum | WhatsApp'ta paylaş
  • Atuin Desktop, terminal iş akışlarını çalıştırılabilir, yerel öncelikli bir runbook düzenleyicisi olarak sunuyor
  • Script blokları, gömülü terminal, veritabanı istemcisi ve Prometheus grafikleri tek bir yerde yönetilebiliyor
  • Dokümanların eskimesini önleme ve yeniden kullanılabilir otomasyon sayesinde iş akışlarını tekrarlanabilir ve güvenilir hale getiriyor
  • Atuin Hub üzerinden senkronizasyon ve paylaşım yapılabiliyor; gerçek shell geçmişi üzerinden otomatik tamamlama destekleniyor
  • Ekip hesapları ve shell geçmişinden runbook oluşturma özellikleriyle işbirlikçi operasyonları güçlendirmeyi planlıyor

Atuin Desktop'a Giriş

  • Atuin Desktop, çalıştırılabilir bir runbook düzenleyicisi olarak gerçek terminal iş akışlarını tekrarlanabilir, paylaşılabilir ve güvenilir hale getiriyor
  • Dokümanların yazılır yazılmaz eskimesini önlüyor ve Jinja tarzı şablonlar kullanan dinamik runbook'lar sunuyor
  • Gerçek shell geçmişi üzerinden otomatik tamamlama sağlayarak anında geri çağırma imkanı veriyor
  • Yerel öncelikli, CRDT tabanlı yapısıyla terminalde çalışan her şey runbook içinde de çalışıyor
  • Atuin Hub aracılığıyla cihazlar ve ekipler arasında güncel kalacak şekilde senkronize edilip paylaşılabiliyor

Güncel kullanım şekilleri

  • Atuin Desktop ile gerçek iş akışları çalıştırılıyor
    • Atuin CLI sürümleri yayımlama
    • Altyapıyı ortamlar arasında güvenli şekilde taşıma
    • Staging veya production ortamlarını güvenle kurma
    • Canlı veritabanı sorgularını yönetme ve birlikte çalışma

Gelecek planları

  • Ekip hesapları: gerçek anlamda işbirlikçi operasyonlar
  • Shell geçmişinden runbook oluşturma: kendini yazan iş akışları

1 yorum

 
GN⁺ 2025-04-23
Hacker News görüşleri
  • Emacs ile ilgilenenler için org-babel kullanarak benzer şeyler yapılabilir

  • Bu fikri yaklaşık 7 yıl önce denemiştim: https://nurtch.com/

    • Bu fikirde çok fazla değer var
    • JupyterCon Paris 2023'te bununla ilgili bir sunum yaptım: https://www.youtube.com/watch?v=TUYY2kHrTzs
    • Dokümanlar çalıştırılabilir kod içeriyorsa, PR inceleme iş akışını dokümanlara da uygulamak isterim
    • Bu, wiki düzenlemeye kıyasla ekipten daha fazla yatırım gerektirir
    • Bol şans
  • Local-first ise zaten bozulmaya açıktır. Her şeyi container içinde çalıştırmadığınız sürece local önemli değildir

    • Runbook kaydetmek istiyorsanız bunu yapmanın pek çok yolu var. Metin dosyaları, Confluence dokümanları, ekran kayıtları, shell script'leri vb.
    • İnsanlar zaten bunu yapmıyor; arayüz daha gösterişli diye bir anda daha fazla yapmaya başlamazlar
    • Ben şahsen bir sistemi belirli bir duruma getirmek için kod (veya dokümantasyon) yazmak istemem
    • Durumu elle oluşturup, bir araçla state'i dump alıp, sonra aynı durumu üretmek (veya zorlamak) için aracı yeniden çalıştırmak isterim
    • Bilgisayarın o duruma nasıl ulaşacağını kodla yazmak istemem
    • "Declarative configuration" yazmak istemem. Bu sadece kodun başka bir adı
    • İşleri elle yapıp snapshot almak ve sonra bunu replay etmek isterim
    • Bunun her sistemde, her yerde çalışmasını isterim. Komutlar için Bash shell izlemeye bağlı kalmadan state'i dump alıp sonra yeniden uygulamak isterim
  • AWS'deyken ekibim için istediğim şey tam olarak buydu

    • Otomatikleştirmesi biraz riskli olan operasyonların birçok versiyonu var
    • Bu, onları kademeli olarak inşa etmek için bir yol sunuyor
    • Tebrikler
  • Bunun local Jupyter notebook'tan farkı ne, merak ediyorum

    • .ipynb içinde ! veya % kullanarak bunu yapamıyor muyuz diye merak ediyorum
    • Bunu içtenlikle soruyorum. Bu şirkete veya CLI ürününe aşina değilim
  • İlginç görünüyor

    • Son zamanlarda Jupyter notebook yerine marimo.io kullanmaya başladım
    • Birçok harika iyileştirme içeriyor ve bu yöne doğru bir hareket gibi görünüyor
  • Çıkışı kutlarım

    • Atuin'i bir süredir biraz takip ediyorum; bu runbook özelliğinin hedef kitlesi ben değilim ama insanların ilginç yeni şeyler yapmasını görmek güzel
  • Ekibimiz polyglot notebook kullanmıştı: https://marketplace.visualstudio.com/items/…

    • Ana dil olarak C# kullanarak, nuget package'larıyla paylaşılan kodu kullanıp runbook'lar oluşturabiliyorduk
    • Bu sayede kendi API'lerimiz ve uygulamalarımızla, production'da çalışan diğer kodlar gibi etkileşim kurabiliyordu
    • İnceleme açısından en iyi deneyim değildi ama bizim için işe yaradı
  • Bu, runme.dev'e çok benziyor gibi görünüyor: https://runme.dev

  • Bu kısmı anlamıyorum. Kaçırdığım şeyi açıklayabilecek biri var mı merak ediyorum

    • Basit bir shell script yerine neden bunu kullanmam gerektiğini merak ediyorum