Atuin Desktop : des runbooks exécutables
(blog.atuin.sh)- Atuin Desktop est un éditeur de runbooks local-first qui ressemble à de la documentation mais s’exécute comme un terminal, conçu pour transformer des procédures opérationnelles répétitives en workflows partageables
- Il réunit commandes shell, requêtes de base de données et requêtes HTTP dans des blocs de script, avec un terminal intégré, un client de base de données et des graphiques Prometheus
- Là où Atuin CLI apportait un historique shell synchronisé et interrogeable, Desktop l’étend en documentation exécutable afin que les connaissances d’équipe ne restent pas uniquement dans la mémoire individuelle ou l’historique
- L’équipe Atuin l’utilise déjà pour les releases de la CLI, les migrations d’infrastructure entre environnements, les opérations sur staging/prod, ainsi que la gestion et la collaboration autour de requêtes sur des bases de données live
- La prochaine étape prévoit des Team accounts et la possibilité de créer des runbooks à partir de l’historique shell, avec un déploiement en early access en cours
Documenter des procédures opérationnelles autrefois dépendantes de la mémoire individuelle
- De nombreuses tâches d’infrastructure dépendent, au moment d’un incident, de quelques commandes dont quelqu’un se souvient, tandis que la documentation est absente ou vite obsolète
- Les véritables indices de résolution peuvent être dispersés dans des fils Slack, des documents Notion ou l’historique shell personnel
- Atuin CLI a résolu une partie du problème grâce à un historique shell synchronisé et interrogeable, mais les équipes ont besoin d’un workflow partageable qui va au-delà de l’historique
- Atuin Desktop est un éditeur de runbooks exécutables conçu sur le principe que « les runbooks doivent être exécutés »
- Le téléchargement est disponible sur la page de téléchargement
Des workflows terminal qui s’exécutent dans la documentation
- Atuin Desktop est conçu pour exécuter de véritables workflows terminal au sein d’une interface documentaire
-
Éléments de travail réunis au même endroit
- Blocs de script
- Terminal intégré
- Client de base de données
- Graphiques Prometheus
-
Fonctionnalités proposées
- Moins de changements de contexte : relie commandes shell, requêtes de base de données et requêtes HTTP
- Une documentation qui ne se dégrade pas : l’exécution directe depuis le document permet de la garder à jour
- Automatisation réutilisable : création de runbooks dynamiques avec des templates de style Jinja
- Rappel immédiat : autocomplétion fournie à partir du véritable historique shell
- Local-first, CRDT-powered : ce qui s’exécute dans le terminal s’exécute aussi dans le runbook
- Synchronisation et partage via Atuin Hub : maintien d’un état à jour entre appareils et équipes
Cas d’usage réels et état du déploiement
- L’équipe Atuin utilise déjà Atuin Desktop dans des tâches réelles
- Releases de la CLI Atuin
- Migrations d’infrastructure entre environnements
- Opérations sur staging ou prod
- Gestion et collaboration autour de requêtes sur des bases de données live
- Les prochaines fonctionnalités prévues incluent des Team accounts et la création de runbooks à partir de l’historique shell
- Le déploiement est en cours, et il est possible de participer via l’early access list
1 commentaires
Commentaires sur Hacker News
Si Emacs vous intéresse, on peut faire quelque chose de similaire avec org-babel
Un seul fichier texte brut peut être à la fois un programme, un document / notebook / site web, et c’est un exemple convaincant de programmation lettrée
Bonne présentation ici : https://osem.seagl.org/conferences/seagl2019/program/proposa...
Ça m’a énormément aidé en étudiant à partir de livres de programmation, et quand je reviens plus tard sur ce programme lettré, je retrouve la compréhension bien plus vite que lors de ma première lecture du livre
La partie « lettrée » répond aux questions « idiotes » qui viennent du fait qu’on ne se souvient pas à 100 % de son raisonnement ou de ce qu’on pensait à l’époque
Évidemment, il y a une courbe d’apprentissage, donc ce n’est pas fait pour ceux qui n’ont pas envie d’apprendre ce genre de chose
On peut aussi voir une vidéo de présentation[0] et un dépôt Git avec une démo plus avancée[1]
[0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
[1]: https://gitlab.com/spudlyo/orgdemo2
J’ai essayé ça il y a environ 7 ans : https://nurtch.com/
L’idée elle-même a beaucoup d’avantages, et j’ai aussi fait une présentation sur le sujet à JupyterCon Paris 2023 : https://www.youtube.com/watch?v=TUYY2kHrTzs
Quand il y a du code exécutable dans la documentation, les gens veulent aussi appliquer le workflow de revue de PR à la documentation, et cela demande plus d’investissement à l’échelle de l’équipe que de simplement éditer un wiki
C’est exactement le genre d’outil que j’aurais voulu pour notre équipe quand j’étais chez AWS
Il y a énormément d’opérations un peu trop risquées pour être entièrement automatisées, et ça offre un chemin pour les transformer progressivement en automatisation répétable
Je me demande de quelle période chez AWS il s’agit
Ces dernières années, chez AWS, nous avons créé un service de plateforme interne pour réduire les corvées d’exploitation en aidant à mettre les runbooks d’exploitation en code et à les exécuter automatiquement de manière sûre
Atuin Desktop ressemble un peu à ce service sur certains points, mais notre service interne avait bien plus de fonctionnalités
Ça permettait d’exécuter des requêtes CloudWatch, des commandes AWS CLI, etc., avec des entrées utilisateur, tout en récupérant en toute sécurité les bons identifiants et en supprimant la charge de configuration liée au formatage des entrées
Ensuite, je l’ai reconstruit pour l’exécuter directement depuis GitHub, et voici un exemple depuis un wiki GitHub qui appelle une fonction Lambda avec des entrées utilisateur en 4 lignes de code : https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
C’était un notebook hébergé avec intégration IAM
Je me demande en quoi c’est différent d’un notebook Jupyter local
On ne peut pas déjà faire ça dans un
.ipynbavec!ou%?Je pose la question sincèrement, je connais mal cette entreprise et son produit CLI
Toute la séquence pipenv/pyenv/conda/poetry/uv/dependencies.txt puis « ah, il faut installer Python pour exécuter ce notebook… bon, d’accord », qui deux semaines plus tard devient « cette mise à jour a cassé un vieil Ansible et maintenant je ne peux plus réparer 15 serveurs qui tenaient déjà à peine debout », c’est l’enfer
J’essaie de garder Python loin de l’automatisation de base
Tous les projets Python que je touche cassent au moins une fois par an à cause de problèmes de dépendances ou de runtime, y compris Ansible, les pipelines de build et des choses comme
deploy.pyLes notebooks Jupyter traînent avec eux un énorme arbre de dépendances et d’exigences, donc je ne les utiliserais pas pour ce type d’automatisation critique et fondamentale
Évidemment, mon travail m’oblige à gérer bien trop de codebases, et rien que sur les deux derniers mois, j’ai eu au moins 6 projets Python
Certains exigent Python 2.7, d’autres une version abandonnée de
lib-something.h, certains sont à la pointe, et d’autres ne sont pas documentés mais sont en réalité extrêmement stricts, au point de n’être « fonctionnels que sur la machine d’un seul développeur tant qu’on ne met absolument rien à jour »Puppet ou Chef sont tout aussi mauvais pour la même raison, puisqu’ils sont en Ruby, mais Ruby a au moins l’avantage de n’avoir eu qu’un seul système de gestion de paquets pendant des décennies
En général, Jupyter donne l’impression d’offrir à la fois du scripting souple et la prise en charge des commandes du système d’exploitation
On peut aussi le faire avec
!/%ouos.system()Ça a l’air très proche de https://runme.dev
J’adore les documents exécutables, et je pense qu’il n’y en a pas encore assez
Ça a l’air intéressant
J’ai commencé récemment à utiliser https://marimo.io/ comme alternative aux notebooks Jupyter, il y a plusieurs améliorations, et ça semble aller dans une direction similaire
Si c’est du local-first, c’est déjà sujet à la putréfaction (rot)
À moins que tout ne s’exécute dans des conteneurs ; et si c’est le cas, le fait que ce soit local n’a plus vraiment d’importance
Si l’on veut consigner des runbooks, il suffit de consigner des runbooks
Il existe déjà une infinité de moyens de le faire : fichiers texte, documents Confluence, enregistrements d’écran, scripts shell, etc.
Les gens ne le font déjà pas aujourd’hui, et ce n’est pas parce que l’UI devient plus élégante qu’ils vont soudainement s’y mettre
Personnellement, je n’ai pas envie de passer ma journée à écrire du code ou de la documentation pour amener un système à l’état X
Je veux créer manuellement l’état X, puis utiliser un outil pour exporter cet état, et plus tard réexécuter cet outil pour recréer ou imposer cet état
Je ne veux pas décrire en code comment l’ordinateur doit atteindre cet état, et je ne veux pas non plus utiliser une configuration déclarative, qui n’est au fond que du code sous un autre nom
Je veux le faire directement, prendre un snapshot, puis le rejouer
Cela doit fonctionner partout, sur n’importe quel système, sans dépendre d’un mécanisme qui surveille les commandes du shell Bash
Un Dockerfile ressemble en pratique un peu à cela, mais il documente dans un fichier les étapes suivies pour parvenir à cet état
https://linux.die.net/man/1/autoexpect
À ce stade, il vaut mieux disposer d’une description déclarative qu’on peut déjà transformer automatiquement en étapes nécessaires pour atteindre l’état X
On utilise des modules pour les tâches courantes, comme vérifier qu’un package est installé, qu’un fichier existe ou contient un certain contenu ; c’est déclaratif et idempotent
Je me demande si ce sera aussi open source, comme Atuin CLI et le serveur de synchronisation
Est-ce que c’est prévu comme un produit ?
Cela dit, c’est quand même une annonce bienvenue
Je ne vois pas bien pourquoi c’est nécessaire
Est-ce que quelqu’un peut m’expliquer ce que j’ai raté ? Pourquoi utiliser ça plutôt qu’un simple script shell ?
Vous êtes dans une équipe responsable de plusieurs cibles ; certaines, vous les connaissez très bien et vous intervenez dessus souvent, d’autres, vous savez vaguement qu’elles existent et vous n’y touchez presque jamais
X, qui fait partie de cette seconde catégorie, tombe en panne
Toutes les personnes qui connaissent vraiment X sont soit en vacances, soit mortes, soit en réunion
Heureusement, il existe une documentation expliquant quoi faire dans ce cas
Sauf que, par quelque miracle de la mauvaise information, cette documentation est obsolète et fausse
Voilà le problème que cela essaie de résoudre
D’après ce que j’ai compris après avoir un peu discuté avec le créateur, l’idée est de faire quelque chose à mi-chemin entre les Jupyter Notebooks et Ansible Tower
La documentation, les scripts et les métriques sont proches les uns des autres, ce qui permet de mieux voir ce qui ne va pas, comment le corriger et si la correction a eu l’effet attendu
[1] Divulgation : j’aide à l’administration du Discord d’atuin
D’où le nom « Runbooks That Run »
Certaines personnes aiment simplement un workflow ou un enchaînement d’outils particulier, alors elles le construisent
Selon le nombre de personnes à qui cela convient, il y a peut-être un marché, ou pas
Dans mes projets personnels, j’utilise simplement un processus de déploiement PHP parce que j’en ai envie, et cela prend en charge 60 % des tâches sans effort supplémentaire de ma part
Le runbook correspondant consiste en tâches intégrées à l’outil et se trouve dans le même dépôt Git que le déploiement complet du serveur
Je n’ai pas envie de le mettre dans un endroit arbitraire ou dans des scripts shell qui m’obligent à me souvenir de commandes distinctes
Pour un programmeur, le code devient essentiellement auto-documenté à condition d’éviter la complexité et de conserver un style fonctionnel simple
Il suffit parfois d’ajouter des commentaires uniquement sur les parties qui ne relèvent pas d’un flux simple du type « créer un utilisateur MySQL, faire tourner le mot de passe, répercuter la nouvelle combinaison utilisateur/mot de passe dans les services concernés, puis supprimer l’ancien utilisateur qui détenait ces identifiants, au cas où le blocage VPN aurait échoué pour un employé licencié »
L’outil de rêve serait que tous les outils offrent une interface terminal, afin qu’on puisse construire un énorme livre contenant tout le contexte qu’on a en tête
En rassemblant par exemple Jira, Datadog et GitHub sur un seul écran
Imaginez un framework TUI interne doté de composants pour chaque service interne, qu’on pourrait assembler comme des Lego pour créer un tableau de bord TUI personnalisé
Ça ressemble au genre de side project qu’on pourrait tenter dans une entreprise ; ce serait énorme comme chantier, mais intéressant
Dans un monde idéal, tous les services, outils et applications fourniraient une API que je pourrais utiliser
Par exemple, si la porte du frigo reste ouverte trop longtemps, on le détecte via du polling API ou un webhook, puis on utilise l’API de Roomba pour aller la refermer
Pourquoi pas ? C’est le monde des API
Le développement semble à l’arrêt depuis un an, mais l’idée est à peu près celle-là
https://wtfutil.com/