Atuin Desktop: Runbooks ejecutables

 (blog.atuin.sh)
1 puntos por GN⁺ 2025-04-23 | 1 comentarios | Compartir por WhatsApp
  • Atuin Desktop ofrece un editor de runbooks ejecutables con enfoque local-first para ejecutar flujos de trabajo de terminal
  • Permite gestionar bloques de scripts, terminal embebida, cliente de base de datos y gráficas de Prometheus en un solo lugar
  • Hace que los flujos de trabajo sean repetibles y confiables mediante la prevención de que la documentación se vuelva obsoleta y la automatización reutilizable
  • Permite sincronización y compartición a través de Atuin Hub, y ofrece autocompletado a partir del historial real del shell
  • Planea reforzar las operaciones colaborativas mediante cuentas de equipo y la función de crear runbooks desde el historial del shell

Introducción a Atuin Desktop

  • Atuin Desktop es un editor de runbooks ejecutables que hace que los flujos de trabajo reales de terminal sean repetibles, compartibles y confiables
  • Evita que la documentación se vuelva obsoleta en cuanto se escribe, y ofrece runbooks dinámicos usando plantillas estilo Jinja
  • Ofrece autocompletado a partir del historial real del shell, lo que permite una recuperación inmediata
  • Con enfoque local-first y basado en CRDT, todo lo que se ejecuta en la terminal también puede ejecutarse en los runbooks
  • A través de Atuin Hub, puede mantenerse sincronizado y compartirse entre dispositivos y equipos

Cómo lo usan actualmente

  • Ya están ejecutando flujos de trabajo reales con Atuin Desktop
    • Lanzamientos de Atuin CLI
    • Migrar infraestructura de forma segura entre entornos
    • Configurar entornos de staging o producción con confianza
    • Gestionar y colaborar en consultas de base de datos en tiempo real

Próximos planes

  • Cuentas de equipo: operaciones verdaderamente colaborativas
  • Crear runbooks desde el historial del shell: flujos de trabajo que se escriben solos

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-04-23
Comentarios en Hacker News

  • Para quienes estén interesados en Emacs, se puede hacer algo parecido usando org-babel

  • Probé esta idea hace unos 7 años: https://nurtch.com/

    • Esta idea tiene mucho valor
    • Di una charla relacionada en JupyterCon Paris 2023: https://www.youtube.com/watch?v=TUYY2kHrTzs
    • Si la documentación incluye código ejecutable, también me gustaría aplicar a la documentación el flujo de revisión de PR
    • Esto requiere más inversión del equipo que editar un wiki
    • Mucha suerte

  • Si es local-first, ya está sujeto a corrupción. Lo local no importa a menos que todo se ejecute en contenedores

    • Si quieres registrar runbooks, se puede de muchas maneras: archivos de texto, documentos de Confluence, grabaciones de pantalla, scripts de shell, etc.
    • La gente ya no hace eso, y porque la UI sea más vistosa no van a hacerlo de repente mucho más
    • Personalmente, no quiero escribir código (o documentación) para llevar un sistema a cierto estado
    • Quiero crear el estado manualmente, usar herramientas para volcar ese estado y luego volver a ejecutar la herramienta más tarde para crear (o imponer) ese estado
    • No quiero escribir en código cómo la computadora debe llegar a ese estado
    • No quiero escribir una "configuración declarativa". Eso es solo código con otro nombre
    • Quiero hacer el trabajo manualmente, tomar una instantánea y reproducirla
    • Quiero que esto funcione en cualquier sistema y en cualquier lugar. Quiero volcar el estado y volver a aplicarlo después, sin depender de monitoreo del shell Bash para los comandos

  • Esto es exactamente lo que quería para nuestro equipo cuando estaba en AWS

    • Hay muchas versiones de operaciones que son un poco riesgosas para automatizar
    • Esto ofrece un camino para construirlas gradualmente
    • Felicidades

  • Me pregunto en qué se diferencia de un Jupyter notebook local

    • Me pregunto si no se puede hacer esto en un .ipynb usando ! o %
    • Pregunto con toda sinceridad. No conozco esta empresa ni este producto CLI

  • Se ve interesante

    • Hace poco empecé a usar marimo.io para reemplazar Jupyter notebooks
    • Tiene varias mejoras excelentes y parece un movimiento en esta dirección

  • Felicidades por el lanzamiento

    • He seguido un poco a Atuin y, aunque no soy el público objetivo de esta función de runbooks ejecutables, me gusta ver a la gente creando cosas nuevas e interesantes

  • Nuestro equipo usó polyglot notebooks: https://marketplace.visualstudio.com/items/…

    • Como usábamos C# como lenguaje principal, podíamos tener runbooks usando código compartido como paquetes nuget
    • Eso nos permitía interactuar con nuestras propias API y aplicaciones como cualquier otro código que se ejecuta en producción
    • No era la mejor experiencia para revisar, pero nos funcionó

  • Esto se parece mucho a runme.dev: https://runme.dev

  • No entiendo este punto. Me pregunto si alguien puede explicarme qué me estoy perdiendo

    • Me pregunto por qué debería usar esto en vez de un simple script de shell