Atuin Desktop : des runbooks exécutables

 (blog.atuin.sh)
1 points par GN⁺ 2025-04-23 | 1 commentaires | Partager sur WhatsApp
  • Atuin Desktop propose les workflows de terminal sous la forme d’un éditeur de runbooks exécutable, local-first
  • Il permet de gérer au même endroit des blocs de script, un terminal intégré, un client de base de données et des graphiques Prometheus
  • Il rend les workflows répétables et fiables grâce à la prévention de l’obsolescence des documents et à une automatisation réutilisable
  • Via Atuin Hub, il permet la synchronisation et le partage, tout en prenant en charge l’autocomplétion à partir de l’historique réel du shell
  • Il est prévu de renforcer les opérations collaboratives grâce aux comptes d’équipe et à la création de runbooks à partir de l’historique du shell

Présentation d’Atuin Desktop

  • Atuin Desktop est un éditeur de runbooks exécutable qui rend les workflows de terminal réels répétables, partageables et fiables
  • Il évite que la documentation ne devienne obsolète dès sa rédaction et propose des runbooks dynamiques utilisant des templates de style Jinja
  • Il prend en charge l’autocomplétion à partir de l’historique réel du shell, permettant un rappel immédiat
  • Local-first et basé sur les CRDT, tout ce qui s’exécute dans le terminal peut aussi s’exécuter dans les runbooks
  • Via Atuin Hub, il est possible de synchroniser et partager l’état le plus récent entre appareils et équipes

Utilisation actuelle

  • Des workflows réels sont exécutés via Atuin Desktop
    • Publication des versions d’Atuin CLI
    • Migration sécurisée de l’infrastructure entre environnements
    • Configuration en toute confiance d’environnements de staging ou de production
    • Gestion et collaboration sur des requêtes de base de données en direct

Feuille de route

  • Comptes d’équipe : de véritables opérations collaboratives
  • Création de runbooks à partir de l’historique du shell : des workflows qui s’écrivent d’eux-mêmes

À lire aussi

1 commentaires

 
GN⁺ 2025-04-23
Avis Hacker News

  • Pour les personnes intéressées par Emacs, il est possible de faire quelque chose de similaire avec org-babel

  • J'ai essayé cette idée il y a environ 7 ans : https://nurtch.com/

    • Cette idée a beaucoup de valeur
    • J'ai donné une présentation sur le sujet à JupyterCon Paris 2023 : https://www.youtube.com/watch?v=TUYY2kHrTzs
    • Si la documentation contient du code exécutable, je voudrais aussi appliquer aux documents le workflow de revue des PR
    • Cela demande plus d'investissement de la part d'une équipe que l'édition d'un wiki
    • Bonne chance

  • Si c'est local-first, c'est déjà sujet à la dérive. À moins de tout exécuter dans des conteneurs, le local n'a pas d'importance

    • Si vous voulez consigner des runbooks, il existe déjà de nombreuses façons de le faire. Fichiers texte, documents Confluence, enregistrements d'écran, scripts shell, etc.
    • Les gens ne le font déjà pas, et ce n'est pas parce que l'interface est plus sophistiquée qu'ils vont soudainement le faire davantage
    • Personnellement, je ne veux pas écrire du code (ou de la documentation) pour amener un système dans un état donné
    • Je préfère créer l'état manuellement, utiliser un outil pour capturer cet état, puis réexécuter l'outil plus tard pour générer (ou imposer) cet état
    • Je ne veux pas écrire en code la manière dont l'ordinateur doit atteindre cet état
    • Je ne veux pas écrire de « configuration déclarative ». C'est simplement du code sous un autre nom
    • Je veux effectuer les opérations manuellement, prendre un instantané et le rejouer
    • Je veux que cela fonctionne partout sur tous les systèmes. Je veux capturer l'état puis le réappliquer plus tard, sans dépendre d'une surveillance du shell Bash pour les commandes

  • C'est exactement ce que j'aurais voulu pour notre équipe quand j'étais chez AWS

    • Il existe de nombreuses variantes d'opérations un peu trop risquées pour être automatisées
    • Cela offre une voie pour construire progressivement à partir de là
    • Félicitations

  • Je me demande en quoi cela diffère d'un notebook Jupyter local

    • Je me demande s'il n'est pas possible de faire cela dans un .ipynb avec ! ou %
    • C'est une vraie question. Je ne connais pas cette entreprise ni ce produit CLI

  • Cela a l'air intéressant

    • J'ai récemment commencé à utiliser marimo.io pour remplacer les notebooks Jupyter
    • Il apporte plusieurs excellentes améliorations, et cela semble aller dans cette direction

  • Félicitations pour le lancement

    • Je suis un peu Atuin depuis quelque temps, et même si je ne suis pas la cible de cette fonctionnalité de runbook, c'est agréable de voir des gens créer quelque chose de nouveau et d'amusant

  • Notre équipe utilisait des notebooks polyglottes : https://marketplace.visualstudio.com/items/…

    • En utilisant C# comme langage principal, nous pouvions avoir des runbooks avec du code partagé via des packages nuget
    • Cela leur permettait d'interagir avec nos propres API et applications comme n'importe quel autre code exécuté en production
    • Ce n'était pas la meilleure expérience pour la revue, mais cela a bien fonctionné pour nous

  • Cela ressemble beaucoup à runme.dev : https://runme.dev

  • Je ne comprends pas l'intérêt. Je me demande si quelqu'un peut m'expliquer ce qui m'échappe

    • Je me demande pourquoi utiliser cela plutôt qu'un simple script shell