Atuin Desktop: Ausführbare Runbooks

 (blog.atuin.sh)
1 Punkte von GN⁺ 2025-04-23 | 1 Kommentare | Auf WhatsApp teilen
  • Atuin Desktop bietet einen Local-First-Editor für ausführbare Runbooks, der Terminal-Workflows ausführbar macht
  • Skriptblöcke, eingebettete Terminals, Datenbank-Clients und Prometheus-Diagramme lassen sich an einem Ort verwalten
  • Durch Verhinderung des Veraltens von Dokumentation und wiederverwendbare Automatisierung werden Workflows wiederholbar und zuverlässig
  • Über den Atuin Hub sind Synchronisierung und Teilen möglich, mit Autovervollständigung aus dem echten Shell-Verlauf
  • Geplant sind Team-Accounts und die Erstellung von Runbooks aus dem Shell-Verlauf, um die kollaborative Betriebsarbeit zu stärken

Einführung in Atuin Desktop

  • Atuin Desktop ist ein Editor für ausführbare Runbooks, der reale Terminal-Workflows wiederholbar, teilbar und zuverlässig macht
  • Er verhindert, dass Dokumentation direkt nach dem Schreiben veraltet, und bietet dynamische Runbooks mit Templates im Jinja-Stil
  • Er unterstützt Autovervollständigung aus dem echten Shell-Verlauf und ermöglicht so sofortigen Recall
  • Local-First und CRDT-basiert: Alles, was im Terminal ausgeführt wird, kann auch im Runbook ausgeführt werden
  • Über den Atuin Hub kann alles geräte- und teamübergreifend aktuell synchronisiert und geteilt werden

Aktuelle Einsatzmöglichkeiten

  • Atuin Desktop wird bereits zur Ausführung realer Workflows verwendet
    • Releases für die Atuin CLI
    • Sichere Migration von Infrastruktur zwischen Umgebungen
    • Souveränes Einrichten von Staging- oder Produktionsumgebungen
    • Verwaltung und Zusammenarbeit bei Datenbankabfragen in Echtzeit

Ausblick

  • Team-Accounts: echte kollaborative Betriebsarbeit
  • Runbooks aus dem Shell-Verlauf erzeugen: Workflows, die sich selbst schreiben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-04-23
Hacker-News-Kommentare

  • Für Leute, die sich für Emacs interessieren, lässt sich mit org-babel etwas Ähnliches machen

  • Ich habe diese Idee vor etwa 7 Jahren ausprobiert: https://nurtch.com/

    • Diese Idee hat viel Potenzial
    • Ich habe dazu auf der JupyterCon Paris 2023 einen Vortrag gehalten: https://www.youtube.com/watch?v=TUYY2kHrTzs
    • Wenn Dokumente ausführbaren Code enthalten, möchte ich den PR-Review-Workflow auch auf Dokumente anwenden
    • Das erfordert vom Team mehr Investition als das Bearbeiten eines Wikis
    • Viel Erfolg

  • Wenn es local-first ist, ist es bereits anfällig für Verfall. Lokal ist egal, solange nicht alles in Containern läuft

    • Wenn man Runbooks aufzeichnen will, geht das auf viele Arten: Textdateien, Confluence-Dokumente, Bildschirmaufnahmen, Shell-Skripte usw.
    • Die Leute tun das schon jetzt nicht, und nur weil die UI schicker ist, werden sie es nicht plötzlich häufiger tun
    • Ich persönlich möchte keinen Code (oder Dokumente) schreiben, um ein System in einen bestimmten Zustand zu versetzen
    • Ich möchte den Zustand manuell herstellen, dann mit einem Tool den Zustand dumpen und später das Tool erneut ausführen, um diesen Zustand zu erzeugen (oder zu erzwingen)
    • Ich möchte nicht in Code beschreiben, wie der Computer diesen Zustand erreichen soll
    • Ich möchte keine „deklarative Konfiguration“ schreiben. Das ist nur Code unter einem anderen Namen
    • Ich möchte Dinge manuell tun, einen Snapshot machen und ihn wieder abspielen
    • Ich möchte, dass das auf jedem System überall funktioniert. Ich möchte den Zustand dumpen und später erneut anwenden, ohne mich auf Bash-Shell-Monitoring für Befehle zu verlassen

  • Genau so etwas habe ich mir gewünscht, als ich bei AWS war, für unser Team

    • Es gibt viele Varianten von Abläufen, die für eine vollständige Automatisierung etwas zu riskant sind
    • Das bietet einen Weg, sie schrittweise aufzubauen
    • Glückwunsch

  • Ich frage mich, wie sich das von einem lokalen Jupyter-Notebook unterscheidet

    • Ich frage mich, ob man das nicht in einer .ipynb mit ! oder % machen kann
    • Ehrlich gemeinte Frage. Ich kenne weder diese Firma noch das CLI-Produkt

  • Sieht interessant aus

    • Ich habe vor Kurzem angefangen, marimo.io als Ersatz für Jupyter-Notebooks zu verwenden
    • Es hat mehrere großartige Verbesserungen und wirkt wie eine Bewegung in diese Richtung

  • Glückwunsch zum Launch

    • Ich habe Atuin ein wenig verfolgt, gehöre zwar nicht zur Zielgruppe dieser Runbook-Funktion, aber es ist schön zu sehen, wie Leute etwas Interessantes und Neues bauen

  • Unser Team hat polyglotte Notebooks verwendet: https://marketplace.visualstudio.com/items/…

    • Mit C# als Hauptsprache konnten wir Runbooks haben, die gemeinsam genutzten Code aus NuGet-Paketen verwendeten
    • Dadurch konnten sie mit unseren eigenen APIs und Anwendungen interagieren, genau wie anderer Code, der in Produktion läuft
    • Es war nicht die beste Erfahrung zum Reviewen, aber für uns hat es funktioniert

  • Das sieht runme.dev sehr ähnlich: https://runme.dev

  • Ich verstehe den Punkt hier nicht. Vielleicht kann jemand erklären, was ich übersehe

    • Ich frage mich, warum man das statt eines einfachen Shell-Skripts verwenden sollte