Atuin Desktop: Runbooks executáveis

 (blog.atuin.sh)
1 pontos por GN⁺ 2025-04-23 | 1 comentários | Compartilhar no WhatsApp
  • O Atuin Desktop oferece um editor de runbooks executáveis com foco local para executar fluxos de trabalho de terminal
  • É possível gerenciar blocos de script, terminal embutido, cliente de banco de dados e gráficos do Prometheus em um só lugar
  • Torna os fluxos de trabalho repetíveis e confiáveis por meio da prevenção da deterioração da documentação e de automação reutilizável
  • Permite sincronização e compartilhamento via Atuin Hub e oferece autocompletar com base no histórico real do shell
  • Há planos para reforçar as operações colaborativas com contas de equipe e a criação de runbooks a partir do histórico do shell

Introdução ao Atuin Desktop

  • O Atuin Desktop é um editor de runbooks executáveis que torna fluxos de trabalho reais de terminal repetíveis, compartilháveis e confiáveis
  • Impede que a documentação se deteriore assim que é escrita e oferece runbooks dinâmicos com templates no estilo Jinja
  • Oferece autocompletar a partir do histórico real do shell, permitindo recordação imediata
  • É local-first, baseado em CRDT, e tudo o que roda no terminal também roda nos runbooks
  • Pode manter tudo sincronizado e compartilhado entre dispositivos e equipes por meio do Atuin Hub

Como está sendo usado atualmente

  • Fluxos de trabalho reais estão sendo executados com o Atuin Desktop
    • Releases do Atuin CLI
    • Migração segura de infraestrutura entre ambientes
    • Configuração confiante de ambientes de staging ou produção
    • Gerenciamento e colaboração em consultas de banco de dados em tempo real

Planos futuros

  • Contas de equipe: operações realmente colaborativas
  • Criação de runbooks a partir do histórico do shell: fluxos de trabalho que se escrevem sozinhos

Leituras relacionadas

1 comentários

 
GN⁺ 2025-04-23
Comentários no Hacker News

  • Para quem se interessa por Emacs, dá para fazer algo parecido usando org-babel

  • Tentei essa ideia há cerca de 7 anos: https://nurtch.com/

    • Essa ideia tem muito valor
    • Fiz uma apresentação relacionada na JupyterCon Paris 2023: https://www.youtube.com/watch?v=TUYY2kHrTzs
    • Se a documentação inclui código executável, eu gostaria de aplicar o fluxo de revisão de PR também à documentação
    • Isso exige mais investimento da equipe do que editar uma wiki
    • Boa sorte

  • Se for local-first, então já está sujeito à corrupção. Local não importa, a menos que tudo rode em contêineres

    • Se você quer registrar runbooks, isso pode ser feito de várias formas: arquivos de texto, documentos no Confluence, gravações de tela, scripts de shell etc.
    • As pessoas já não fazem isso, e uma UI mais chamativa não vai fazer com que de repente passem a fazer mais
    • Pessoalmente, eu não quero escrever código (ou documentação) para colocar um sistema em um estado específico
    • Quero criar o estado manualmente, usar ferramentas para despejar esse estado e depois executar a ferramenta de novo mais tarde para criar (ou impor) esse estado
    • Não quero escrever em código como o computador deve chegar a esse estado
    • Não quero escrever "configuração declarativa". Isso é só código com outro nome
    • Quero fazer o trabalho manualmente, tirar um snapshot e reproduzi-lo
    • Quero que isso funcione em qualquer lugar, em todos os sistemas. Quero despejar o estado e reaplicá-lo depois sem depender de monitoramento de shell Bash para os comandos

  • Era exatamente isso que eu queria para a nossa equipe quando estava na AWS

    • Há muitas versões de operações que são um pouco arriscadas para automatizar
    • Isso oferece um caminho para construir isso de forma incremental
    • Parabéns

  • Fico me perguntando como isso difere de um notebook Jupyter local

    • Será que não dá para fazer isso em um .ipynb usando ! ou %?
    • Pergunta sincera. Não conheço esta empresa nem este produto CLI

  • Parece interessante

    • Recentemente comecei a usar marimo.io para substituir notebooks Jupyter
    • Tem várias melhorias excelentes, e isso parece um movimento nessa direção

  • Parabéns pelo lançamento

    • Tenho acompanhado a Atuin um pouco e, embora eu não seja o público-alvo desse recurso de runbook, é bom ver pessoas criando algo novo e divertido

  • Nossa equipe usava notebooks polyglot: https://marketplace.visualstudio.com/items/…

    • Com C# como linguagem principal, podíamos ter runbooks usando código compartilhado via pacotes nuget
    • Isso permitia interagir com nossas próprias APIs e aplicações como qualquer outro código executado em produção
    • Não era a melhor experiência para revisão, mas funcionava para nós

  • Isso parece muito parecido com runme.dev: https://runme.dev

  • Não entendi bem essa proposta. Gostaria que alguém explicasse o que estou deixando passar

    • Fico me perguntando por que eu deveria usar isso em vez de um simples script de shell