Atuin Desktop: Runbooks ejecutables

 (blog.atuin.sh)
1 puntos por GN⁺ 2025-04-23 | 1 comentarios | Compartir por WhatsApp
  • Atuin Desktop es un editor de runbooks local-first que se ve como documentación, pero se ejecuta como una terminal; es una herramienta pensada para convertir procedimientos operativos repetitivos en flujos de trabajo compartibles
  • Reúne comandos de shell, consultas a bases de datos y solicitudes HTTP dentro de bloques de script, junto con una terminal integrada, un cliente de base de datos y gráficos de Prometheus
  • Si Atuin CLI ofrecía un historial de shell sincronizable y con búsqueda, Desktop lo amplía hacia documentación ejecutable para que el conocimiento del equipo no quede solo en la memoria personal o en el historial
  • El equipo de Atuin ya lo usa para releases de CLI, migraciones de infraestructura entre entornos, ejecuciones en staging/prod, y gestión y colaboración sobre consultas a bases de datos en vivo
  • Como siguiente paso, planean Team accounts y la función de crear runbooks a partir del historial de shell; actualmente están distribuyendo acceso anticipado

Documentar procedimientos operativos que antes dependían de la memoria personal

  • Muchas tareas de infraestructura, cuando ocurre una falla, dependen de unos cuantos comandos que alguien recuerda, y la documentación suele no existir o quedar desactualizada
  • Las pistas reales para resolver problemas pueden estar dispersas entre hilos de Slack, documentos de Notion y el historial de shell personal
  • Atuin CLI resolvía parte de este problema con un historial de shell sincronizado y con búsqueda, pero los equipos necesitan flujos de trabajo compartibles que vayan más allá del historial
  • Atuin Desktop es un editor de runbooks ejecutables creado bajo la premisa de que “los runbooks deben poder ejecutarse”
  • La descarga está disponible en la página de descargas

Flujos de trabajo de terminal que se ejecutan dentro de la documentación

  • Atuin Desktop está diseñado para ejecutar flujos de trabajo reales de terminal dentro de una interfaz de documento

  • Elementos de trabajo reunidos en un solo lugar

    • bloques de script
    • terminal integrada
    • cliente de base de datos
    • gráficos de Prometheus

  • Funciones que ofrece

    • Menos cambio de contexto: conecta comandos de shell, consultas a bases de datos y solicitudes HTTP
    • Documentación que no se pudre: se ejecuta directamente desde el documento para mantenerse actualizada
    • Automatización reutilizable: crea runbooks dinámicos con plantillas estilo Jinja
    • Recuerdo inmediato: ofrece autocompletado a partir del historial real de shell
    • Local-first, CRDT-powered: lo que se ejecuta en la terminal también se ejecuta en el runbook
    • Sincronización y uso compartido con Atuin Hub: mantiene todo al día entre dispositivos y equipos

Casos de uso reales y estado de despliegue

  • El equipo de Atuin ya está usando Atuin Desktop en trabajo real
    • releases de Atuin CLI
    • migraciones de infraestructura entre entornos
    • ejecuciones en staging o prod
    • gestión y colaboración sobre consultas a bases de datos en vivo
  • Entre las próximas funciones están Team accounts y la posibilidad de generar runbooks a partir del historial de shell
  • Ya se está distribuyendo, y se puede participar a través de la lista de acceso anticipado

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-04-23
Opiniones en Hacker News

  • Si te da curiosidad Emacs, puedes hacer algo similar con org-babel
    Un solo archivo de texto plano puede ser a la vez programa y documento/notebook/sitio web, y es un ejemplo convincente de programación literaria
    Hay una buena explicación aquí: https://osem.seagl.org/conferences/seagl2019/program/proposa...

    • En cuanto a funcionalidad, org-babel está entre los sistemas de programación literaria más potentes, y quizá sea el más potente
      Me ayudó muchísimo al estudiar con libros de programación, y cuando luego vuelvo a ver ese programa literario, lo entiendo de nuevo mucho más rápido que cuando leí el libro por primera vez
      La parte literaria responde esas preguntas “tontas” que surgen porque no recuerdo al 100% mi razonamiento o mis ideas de ese momento
      Claro que tiene una curva de aprendizaje, así que no es para quienes no quieren aprender ese tipo de cosas
    • org-babel encaja bien con esta tarea y permite crear documentación excelente
      También pueden ver el video de la presentación[0] y un repositorio Git[1] con una demo más avanzada
      [0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
      [1]: https://gitlab.com/spudlyo/orgdemo2
    • Shell Worksheets de BBEdit también son similares: permiten mezclar texto explicativo con comandos que se pueden ejecutar con una sola tecla

  • Probé hacer esto hace unos 7 años: https://nurtch.com/
    La idea en sí tiene muchas ventajas, y también di una charla relacionada en JupyterCon Paris 2023: https://www.youtube.com/watch?v=TUYY2kHrTzs
    Cuando hay código ejecutable dentro de la documentación, la gente quiere aplicar también a los documentos el flujo de revisión de PR, y eso requiere una inversión de equipo mayor que editar una wiki

    • Mi primera reacción también fue “¿por qué no Jupyter?”, y me alegra ver que alguien más pensó lo mismo

  • Es exactamente lo que quería para mi equipo cuando estaba en AWS
    Hay muchísimas tareas operativas que son un poco riesgosas para automatizarlas por completo, y esto ofrece un camino para ir convirtiéndolas repetidamente en automatización

    • Es solo mi opinión personal y no la postura de mi empleador
      Me da curiosidad saber cuándo estuviste en AWS
      En los últimos años, en AWS creamos un servicio de plataforma interno para codificar runbooks operativos y ayudar a ejecutarlos automáticamente de forma segura, reduciendo el trabajo operativo rutinario
      Atuin Desktop se parece a ese servicio en algunos aspectos, aunque ese servicio interno tenía muchas más funciones
    • Cuando estaba en AWS, construí algo que se podía ejecutar directamente desde la wiki
      Ejecutaba cosas como consultas de CloudWatch y comandos de AWS CLI con entradas del usuario, pero eliminaba la carga de configuración para obtener credenciales correctas de forma segura y formatear las entradas
      Luego lo rehice para que se ejecutara directamente desde GitHub, y aquí hay un ejemplo en el que se invoca una función Lambda desde una wiki de GitHub con entradas de usuario en 4 líneas de código: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
    • Si fue en Amazon antes de la pandemia, creo que Eider habría servido para ese uso
      Era un notebook alojado con integración de IAM

  • Me pregunto en qué se diferencia de un notebook Jupyter local
    ¿No se puede hacer esto en un .ipynb con ! o %?
    Lo pregunto sinceramente porque no conozco bien esta empresa ni su producto CLI

    • La razón principal por la que evito los notebooks Jupyter cuando no voy a usar exclusivamente Python es Python
      El camino que empieza con pipenv/pyenv/conda/poetry/uv/dependencies.txt y “ah, para ejecutar este notebook tengo que actualizar Python… bueno, ok” y dos semanas después se convierte en “esa actualización rompió el Ansible viejo y ahora no puedo arreglar 15 servidores que apenas se sostenían” es un infierno
      Intento mantener Python lejos de la automatización de base
      Los proyectos Python que manejo se rompen al menos una vez al año por problemas de dependencias o runtime, y eso también aplica a Ansible, pipelines de build y cosas como deploy.py
      Los notebooks Jupyter arrastran un árbol enorme de dependencias y requisitos, así que no los usaría para automatizaciones tan críticas y fundamentales
      Claro, mi trabajo me obliga a lidiar con demasiadas bases de código, y solo en los últimos dos meses tuve al menos 6 proyectos Python
      Algunos requieren Python 2.7, otros una versión abandonada de lib-something.h, otros están en la punta de lanza, y otros no están documentados pero en la práctica son extremadamente estrictos, del tipo “funciona siempre que no se actualice nada en la máquina de un único desarrollador responsable”
      Puppet y Chef son igual de malos por ser Ruby y sufren los mismos problemas, aunque Ruby tiene la diferencia de que durante décadas tuvo un solo sistema de gestión de paquetes
    • Los notebooks Jupyter siempre me han parecido un poco forzados como hack para usarlos como terminal, así que me gustaría probar esto
    • Me surge exactamente la misma pregunta
      Por lo general, siento que Jupyter ofrece tanto scripting flexible como soporte para comandos del sistema operativo
      También se puede con !/% u os.system()

  • Esto se ve muy parecido a https://runme.dev

    • Soy co-creador de Runme
      Me encantan los documentos ejecutables, y creo que todavía no hay suficientes

  • Se ve interesante
    Hace poco empecé a usar https://marimo.io/ como alternativa a notebooks Jupyter, tiene varias mejoras y esto también parece ir en una dirección parecida

  • Si es local-first, ya está sujeto a la podredumbre (rot)
    Eso aplica si no ejecutas todo en contenedores; y si lo ejecutas en contenedores, el hecho de que sea local no importa
    Si quieres documentar un runbook, simplemente documenta el runbook
    Hay incontables maneras: archivos de texto, documentos de Confluence, grabaciones de pantalla, scripts de shell, etc.
    La gente ya no lo está haciendo, y una UI más bonita no hará que de pronto lo hagan más
    Personalmente, no quiero pasarme todo el día escribiendo código o documentación para dejar un sistema en el estado X
    Quiero llevarlo manualmente al estado X, luego volcar ese estado con una herramienta y, más tarde, volver a ejecutar esa herramienta para crear o imponer ese estado
    No quiero describir en código cómo debe llegar la computadora a ese estado, ni quiero usar configuración declarativa, que no deja de ser código con otro nombre
    Quiero hacerlo directamente, tomar una snapshot y reproducirla
    Debería funcionar en cualquier lugar y en cualquier sistema, sin depender de cosas como vigilar comandos de Bash shell

    • ¿Entonces no terminarías con solo un bloque binario de estado, sin documentación de por qué llegó a ese estado? No suena mantenible
      Un Dockerfile es, en efecto, algo parecido, pero documenta en un archivo los pasos que se siguieron para llegar a ese estado
    • Lo que quieres parece más cercano a autoexpect
      https://linux.die.net/man/1/autoexpect
    • Ese tipo de procedimientos suele tener poca portabilidad y hay que repetirlo para cada sistema distinto
      Para ese punto, sería mejor contar ya con una descripción declarativa que pueda convertirse automáticamente en los pasos necesarios para llegar al estado X
    • Eso era la declaración de Docker
    • Lo que describes parece más cercano a Ansible
      Usa módulos para tareas comunes, como verificar que un paquete esté instalado, que un archivo exista o que tenga cierto contenido, y es declarativo e idempotente

  • Me pregunto si esto también será open source, como el CLI de Atuin y el servidor de sincronización
    ¿Está pensado para convertirse en producto?

  • No termino de entender por qué esto es necesario
    ¿Alguien puede explicarme qué me estoy perdiendo? ¿Por qué debería usar esto en vez de un simple script de shell?

    • Mi experiencia con runbooks fue así
      Estás en un equipo responsable de varias cosas; algunas las conoces muy bien y las tocas seguido, pero de otras apenas sabes que existen y casi nunca las manejas
      X, que cae en este último grupo, se rompe
      Todas las personas que realmente conocen X están de vacaciones/muertas/en una reunión
      Por suerte, hay documentación que explica qué hacer en esta situación
      Pero, de alguna manera, esa documentación resulta ser un milagro de mala información: vieja y equivocada
      Ese es el problema que intenta resolver
      Por lo que he hablado un poco con el creador, la intención se parece más a crear algo a medio camino entre Jupyter Notebooks y Ansible Tower
      Es una forma de tener documentación, scripts y métricas cerca entre sí para que sea más fácil entender qué salió mal, cómo arreglarlo y si el arreglo funcionó
      [1] Divulgación: ayudo a operar el Discord de atuin
    • Parece programación literaria para scripts de shell
      Por eso es “Runbooks That Run”
    • Porque está escrito en Rust y esto es Hacker News
    • ¿Cuál es el propósito de que los despliegues suelan configurarse con herramientas como Ansible o Deployer? ¿Y por qué empaquetar además scripts de Python que realizan tareas comunes y ponerlo todo en un repositorio Git?
      A algunas personas les gusta cierto flujo de trabajo o de herramientas, así que simplemente lo construyen
      Si le sirve a suficiente gente, puede que tenga mercado o puede que no
      En proyectos personales uso un proceso de despliegue en PHP solo porque quiero, y resuelve el 60% del trabajo sin que yo tenga que hacerlo aparte
      El runbook para eso son tareas incorporadas en la herramienta y está en el mismo repositorio Git que todo el despliegue del servidor
      No quiero ponerlo en un lugar arbitrario ni en un script de shell para el que tenga que recordar un comando aparte
      Para un programador, el código se vuelve esencialmente autodocumentado si se evita la complejidad y se mantiene un estilo funcional simple
      Solo hace falta comentar de vez en cuando las partes que no sean flujos simples, como “crear un usuario de MySQL, rotar la contraseña, reflejar la nueva combinación de usuario/contraseña en los servicios relacionados y eliminar al usuario anterior cuyas credenciales podría tener un empleado despedido, por si falló el bloqueo de la VPN”

  • La herramienta con la que sueño es una donde todas las herramientas ofrezcan una interfaz de terminal, para poder crear un libro enorme con todo el contexto que tengo en la cabeza
    Algo como reunir Jira, Datadog, GitHub, etc. en una sola pantalla

    • Personalmente, también me gustaría una TUI un poco más amigable
      Imagínate tener un framework interno de TUI con componentes para cada servicio interno, y poder ensamblarlos como piezas de Lego para crear un dashboard TUI personalizado
      Suena como algo que valdría la pena hacer como proyecto lateral en una empresa; sería un trabajo enorme, pero interesante
    • Con que haya una API alcanza, y encima de eso se pueden construir herramientas
      En un mundo ideal, todos los servicios, herramientas y aplicaciones ofrecerían una API que yo pudiera usar
      Por ejemplo, si la puerta del refrigerador queda abierta demasiado tiempo, detectarlo mediante polling de la API o un webhook, y mandar al Roomba a cerrarla usando la API de Roomba
      ¿Por qué no? Es el mundo de las API
    • GitHub y Datadog ya tienen herramientas CLI oficiales
    • Puede que te refieras a algo como wtfutil
      Parece que el desarrollo lleva un año detenido, pero la idea va por ahí
      https://wtfutil.com/
    • Entonces quizá te guste MCP