Atuin Desktop: Ausführbare Runbooks
(blog.atuin.sh)- Atuin Desktop ist ein Local-first-Runbook-Editor, der wie ein Dokument aussieht, sich aber wie ein Terminal ausführen lässt, und soll wiederkehrende Betriebsabläufe in gemeinsam nutzbare Workflows verwandeln
- Shell-Befehle, Datenbankabfragen und HTTP-Anfragen werden gemeinsam in Skriptblöcken sowie in einem integrierten Terminal, einem Datenbank-Client und Prometheus-Diagrammen behandelt
- Während Atuin CLI eine synchronisierte und durchsuchbare Shell-Historie bereitstellte, erweitert Desktop dies zu ausführbarer Dokumentation, damit Teamwissen nicht nur in persönlicher Erinnerung oder im Verlauf verbleibt
- Das Atuin-Team nutzt es bereits für CLI-Releases, Infrastrukturmigrationen zwischen Umgebungen, Ausführungen auf Staging/Prod sowie für die Verwaltung und Zusammenarbeit bei Live-Datenbankabfragen
- Als nächste Schritte sind Team accounts und eine Funktion geplant, mit der sich Runbooks aus der Shell-Historie erstellen lassen; aktuell wird Early Access ausgerollt
Betriebsabläufe dokumentieren, die bisher von persönlicher Erinnerung abhingen
- Viele Infrastrukturaufgaben hängen im Störungsfall von ein paar Befehlen ab, an die sich irgendjemand erinnert, und Dokumentation fehlt oft oder ist veraltet
- Die eigentlichen Hinweise zur Lösung können über Slack-Threads, Notion-Dokumente und persönliche Shell-Historien verstreut sein
- Atuin CLI hat einen Teil dieses Problems mit einer synchronisierten und durchsuchbaren Shell-Historie gelöst, doch Teams brauchen mehr als Historie: gemeinsam nutzbare Workflows
- Atuin Desktop ist ein ausführbarer Runbook-Editor, der auf der Annahme basiert: „Runbooks sollten ausführbar sein“
- Der Download ist auf der Download-Seite verfügbar
Terminal-Workflows, die innerhalb des Dokuments ausgeführt werden
- Atuin Desktop ist darauf ausgelegt, echte Terminal-Workflows innerhalb einer Dokumenten-UI auszuführen
-
An einem Ort gebündelte Arbeitselemente
- Skriptblöcke
- Integriertes Terminal
- Datenbank-Client
- Prometheus-Diagramme
-
Funktionen
- Weniger Kontextwechsel: Verknüpft Shell-Befehle, Datenbankabfragen und HTTP-Anfragen
- Dokumentation, die nicht veraltet: Direkt aus dem Dokument ausführbar und dadurch aktuell
- Wiederverwendbare Automatisierung: Erstellt dynamische Runbooks mit Templates im Jinja-Stil
- Sofortiges Wiederfinden: Bietet Autovervollständigung aus der tatsächlichen Shell-Historie
- Local-first, CRDT-powered: Was im Terminal ausgeführt werden kann, läuft auch im Runbook
- Synchronisierung und Teilen über Atuin Hub: Hält den neuesten Stand über Geräte und Teams hinweg aktuell
Reale Einsatzfälle und Bereitstellungsstatus
- Das Atuin-Team verwendet Atuin Desktop bereits für echte Aufgaben
- Atuin-CLI-Releases
- Infrastrukturmigrationen zwischen Umgebungen
- Ausführungen auf Staging oder Prod
- Verwaltung und Zusammenarbeit bei Live-Datenbankabfragen
- Als nächste Funktionen sind Team accounts und das Erstellen von Runbooks aus der Shell-Historie geplant
- Der Rollout läuft aktuell, und eine Teilnahme ist über die Early-Access-Liste möglich
1 Kommentare
Meinungen auf Hacker News
Wer neugierig auf Emacs ist, kann mit org-babel etwas Ähnliches machen.
Eine einzelne Klartextdatei kann zugleich Programm und Dokument/Notebook/Website sein und ist ein überzeugendes Beispiel für Literate Programming.
Eine gute Erklärung gibt es hier: https://osem.seagl.org/conferences/seagl2019/program/proposa...
Beim Lernen mit Programmierbüchern hat es mir enorm geholfen, und wenn ich mir dieses literate Programm später wieder ansehe, finde ich mich viel schneller wieder hinein als beim ersten Lesen des Buchs.
Der literarische Teil beantwortet die „dummen“ Fragen, die entstehen, weil man sich nicht zu 100 % an die damaligen Schlussfolgerungen oder die eigenen Gedanken erinnert.
Natürlich gibt es eine Lernkurve; für Leute, die so etwas nicht lernen wollen, ist es also nichts.
Man kann sich auch das Vortragsvideo[0] und ein Git-Repository[1] mit einer fortgeschritteneren Demo ansehen.
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/orgdemo2
Vor etwa 7 Jahren habe ich so etwas ausprobiert: https://nurtch.com/
Die Idee selbst hat viele Vorzüge, und ich habe dazu auch auf der JupyterCon Paris 2023 einen Vortrag gehalten: https://www.youtube.com/watch?v=TUYY2kHrTzs
Wenn ausführbarer Code in der Dokumentation steckt, möchten Leute auch auf Dokumente einen PR-Review-Workflow anwenden; das erfordert auf Teamebene mehr Investition, als einfach ein Wiki zu bearbeiten.
Das ist genau das, was ich mir damals in meinem Team bei AWS gewünscht hätte.
Es gibt wirklich viele operative Aufgaben, die ein bisschen zu riskant sind, um sie direkt zu automatisieren; das hier bietet einen Weg, solche Aufgaben schrittweise zu wiederholbarer Automatisierung auszubauen.
Mich würde interessieren, wann du bei AWS warst.
In den letzten Jahren hat AWS einen internen Plattformdienst gebaut, der dabei hilft, operative Runbooks als Code abzubilden und sicher automatisch auszuführen, um operative Fleißarbeit zu reduzieren.
Atuin Desktop ähnelt diesem Dienst in mancher Hinsicht, aber dieser interne Dienst hatte deutlich mehr Funktionen.
Dinge wie CloudWatch-Abfragen und AWS-CLI-Befehle wurden zusammen mit Benutzereingaben ausgeführt, wobei die korrekten Zugangsdaten sicher geholt wurden und der Konfigurationsaufwand für das Formatieren der Eingaben wegfiel.
Später habe ich es so umgebaut, dass es direkt aus GitHub heraus läuft; ein Beispiel, wie man aus einem GitHub-Wiki mit Benutzereingaben eine Lambda-Funktion in 4 Zeilen Code aufruft, gibt es hier: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
Das war ein gehostetes Notebook mit IAM-Integration.
Ich frage mich, worin es sich von einem lokalen Jupyter Notebook unterscheidet.
Kann man das in
.ipynbnicht mit!oder%machen?Ich kenne diese Firma oder ihr CLI-Produkt nicht gut, daher ist das eine ernst gemeinte Frage.
Der Ablauf von pipenv/pyenv/conda/poetry/uv/dependencies.txt und „Ich muss also Python aktualisieren, um dieses Notebook auszuführen, ach … na gut“ bis hin zu zwei Wochen später „Dieses Upgrade hat das alte Ansible kaputtgemacht, und jetzt kann ich 15 Server, die gerade so am Leben waren, nicht mehr reparieren“ ist die Hölle.
Für grundlegende Automatisierung versuche ich, Python fernzuhalten.
Die Python-Projekte, mit denen ich zu tun habe, gehen wegen Dependency- oder Runtime-Problemen mindestens einmal im Jahr kaputt; das gilt auch für Ansible, Build-Pipelines,
deploy.pyund Ähnliches.Jupyter Notebooks bringen einen riesigen Dependency-Tree und entsprechende Anforderungen mit, daher würde ich sie für solche wichtige, grundlegende Automatisierung nicht einsetzen.
Natürlich bringt mich meine Arbeit dazu, übermäßig viele Codebasen anzufassen; allein in den letzten zwei Monaten waren es mindestens sechs Python-Projekte.
Manche brauchen Python 2.7, manche eine veraltete Version von
lib-something.h, manche sind Cutting Edge, und manche sind zwar undokumentiert, aber in der Praxis extrem streng: „Funktioniert, solange auf dem Rechner des einen zuständigen Entwicklers nichts aktualisiert wird.“Puppet und Chef sind wegen Ruby genauso schlecht und haben dieselben Probleme; der Unterschied ist allerdings, dass Ruby seit Jahrzehnten im Grunde nur ein Paketverwaltungssystem hatte.
Normalerweise wirkt Jupyter so, als biete es sowohl flexibles Scripting als auch Unterstützung für Betriebssystembefehle.
Mit
!/%oderos.system()geht das ebenfalls.Das sieht https://runme.dev sehr ähnlich.
Ich mag ausführbare Dokumentation und finde, dass es davon noch nicht genug gibt.
Sieht interessant aus.
Ich habe vor Kurzem begonnen, https://marimo.io/ als Jupyter-Notebook-Alternative zu nutzen; es bringt mehrere Verbesserungen mit, und auch das hier scheint in eine ähnliche Richtung zu gehen.
Wenn es Local-first ist, ist es bereits ein Ziel von Verfall (rot)
Es sei denn, alles läuft in Containern; und wenn es in Containern läuft, ist der lokale Aspekt nicht wichtig
Wenn man ein Runbook dokumentieren will, dokumentiert man einfach ein Runbook
Textdateien, Confluence-Dokumente, Bildschirmaufnahmen, Shell-Skripte usw. – es gibt unzählige Möglichkeiten
Die Leute tun das schon jetzt nicht, und nur weil die UI schicker wird, werden sie es nicht plötzlich häufiger tun
Persönlich möchte ich nicht den ganzen Tag Code oder Dokumentation schreiben, nur um ein System in Zustand X zu bringen
Ich möchte Zustand X manuell herstellen, dann den Zustand mit einem Tool dumpen und später dieses Tool erneut ausführen, um diesen Zustand herzustellen oder zu erzwingen
Ich möchte nicht in Code beschreiben, wie ein Computer diesen Zustand erreicht, und ich möchte auch keine deklarative Konfiguration verwenden, die nur Code unter anderem Namen ist
Ich möchte es selbst machen, einen Snapshot erstellen und ihn wieder abspielen
Es sollte überall und auf jedem System funktionieren, ohne Abhängigkeit davon, Bash-Shell-Befehle zu überwachen
Ein Dockerfile ist im Grunde ähnlich, dokumentiert aber in einer Datei die Schritte, die durchlaufen wurden, um diesen Zustand zu erreichen
https://linux.die.net/man/1/autoexpect
An dem Punkt wäre es besser, bereits eine deklarative Beschreibung zu haben, die automatisch in die nötigen Schritte zum Erreichen von Zustand X übersetzt werden kann
Für allgemeine Aufgaben wie sicherzustellen, dass ein Paket installiert ist, eine Datei existiert oder bestimmte Inhalte hat, nutzt man Module; es ist deklarativ und idempotent
Ich frage mich, ob auch das wie Atuin CLI und der Sync-Server Open Source wird
Soll es produktisiert werden?
Trotzdem schön, dass es angekündigt wurde
Ich bin mir nicht sicher, warum das nötig ist
Kann mir jemand erklären, was ich übersehe? Warum sollte man das statt eines einfachen Shell-Skripts verwenden?
Man ist in einem Team, das für mehrere Dinge zuständig ist; einige davon kennt man sehr gut und fasst sie oft an, von anderen weiß man nur vage, dass sie existieren, und rührt sie fast nie an
X, das zur zweiten Kategorie gehört, geht kaputt
Alle, die X wirklich kennen, sind im Urlaub/tot/in Meetings
Zum Glück gibt es ein Dokument, das erklärt, was in dieser Situation zu tun ist
Dieses Dokument vollbringt jedoch irgendwie das Wunder schlechter Informationen: Es ist veraltet und falsch
Das ist das Problem, das hier gelöst werden soll
Nach einigen Gesprächen mit dem Macher geht die Absicht eher in Richtung einer Mischung aus Jupyter Notebooks und Ansible Tower
Dokumentation, Skripte und Metriken liegen nah beieinander, sodass man leichter erkennt, was falsch läuft, wie man es behebt und ob die Behebung funktioniert hat
[1] Offenlegung: Ich helfe beim Betrieb des atuin-Discord
Deshalb „Runbooks That Run“
Manche Leute mögen bestimmte Workflows oder Tool-Flows und bauen sie einfach
Wenn es für genügend Leute passt, kann es marktfähig sein – oder auch nicht
In persönlichen Projekten nutze ich für PHP-Deployments einfach so einen Ablauf, weil ich das so will; er erledigt 60 % der Arbeit, ohne dass ich mich separat darum kümmern muss
Das Runbook dafür sind im Tool eingebaute Aufgaben und liegt im selben Git-Repository wie das gesamte Server-Deployment
Ich möchte es nicht an irgendeinen beliebigen Ort oder in ein Shell-Skript legen, bei dem man sich einen separaten Befehl merken muss
Für Programmierer ist Code im Grunde selbstdokumentierend, wenn man Komplexität vermeidet und einen einfachen funktionalen Stil beibehält
Kommentare braucht man nur gelegentlich bei Dingen, die kein einfacher Ablauf sind, etwa: „MySQL-Benutzer anlegen, Passwort rotieren, die zugehörigen Services mit der neuen Benutzer/Passwort-Kombination aktualisieren und den alten Benutzer entfernen, dessen Zugangsdaten ein entlassener Mitarbeiter noch haben könnte, falls die VPN-Sperre nicht gegriffen hat“
Mein Traum-Tool wäre, dass alle Tools ein Terminal-Interface anbieten, sodass man ein riesiges Buch bauen kann, das den gesamten Kontext im eigenen Kopf enthält
Also Jira, Datadog, GitHub usw. auf einem Bildschirm zusammenbringen
Man stelle sich ein internes TUI-Framework mit Komponenten für jeden internen Service vor, die man wie Lego zusammenstecken kann, um personalisierte TUI-Dashboards zu bauen
Das klingt nach etwas, das man in der Firma nebenbei ausprobieren könnte; es wäre sicher eine riesige Aufgabe, aber interessant
In einer idealen Welt würde jeder Service, jedes Tool und jede Anwendung eine API anbieten, die ich nutzen kann
Wenn zum Beispiel die Kühlschranktür zu lange offen steht, könnte man das per API-Polling oder Webhook erkennen und ihn per Roomba-API losschicken, um sie zu schließen
Warum nicht? Es ist eine Welt der APIs
Die Entwicklung scheint zwar seit einem Jahr stillzustehen, aber die Idee geht ungefähr in diese Richtung
https://wtfutil.com/