Atuin Desktop: Runbooks executáveis

 (blog.atuin.sh)
1 pontos por GN⁺ 2025-04-23 | 1 comentários | Compartilhar no WhatsApp
  • O Atuin Desktop é um editor de runbooks local-first que parece um documento, mas é executado como um terminal; é uma ferramenta para transformar procedimentos operacionais repetitivos em fluxos de trabalho compartilháveis
  • Ele lida com comandos de shell, consultas a bancos de dados e requisições HTTP juntos em blocos de script, terminal integrado, cliente de banco de dados e gráficos do Prometheus
  • Se o Atuin CLI oferecia um histórico de shell sincronizável e pesquisável, o Desktop expande isso para documentos executáveis, para que o conhecimento da equipe não fique apenas na memória individual ou no histórico
  • A equipe do Atuin já o usa em releases do CLI, migrações de infraestrutura entre ambientes, execuções em staging/prod e gerenciamento e colaboração em consultas a bancos de dados em produção
  • Como próximos passos, estão planejados Team accounts e um recurso para criar runbooks a partir do histórico de shell; o early access já está sendo distribuído

Documentar procedimentos operacionais que dependiam da memória individual

  • Muitas tarefas de infraestrutura, quando há uma falha, dependem de alguns comandos que alguém lembra, e a documentação tende a não existir ou a ficar desatualizada
  • As pistas reais para a solução podem estar espalhadas em threads do Slack, documentos do Notion e históricos de shell pessoais
  • O Atuin CLI resolveu parte desse problema com um histórico de shell sincronizado e pesquisável, mas equipes precisam de fluxos de trabalho compartilháveis que vão além do histórico
  • O Atuin Desktop é um editor de runbooks executáveis criado a partir da premissa de que “runbooks devem ser executados”
  • O download está disponível na página de download

Fluxos de trabalho de terminal executados dentro do documento

  • O Atuin Desktop foi projetado para executar fluxos de trabalho reais de terminal dentro de uma interface de documento

  • Elementos de trabalho reunidos em um só lugar

    • Blocos de script
    • Terminal integrado
    • Cliente de banco de dados
    • Gráficos do Prometheus

  • Recursos oferecidos

    • Menos troca de contexto: conecta comandos de shell, consultas a bancos de dados e requisições HTTP
    • Documentos que não apodrecem: mantêm-se atualizados ao serem executados diretamente no documento
    • Automação reutilizável: cria runbooks dinâmicos com templates no estilo Jinja
    • Recordação imediata: oferece autocomplete a partir do histórico real de shell
    • Local-first, com CRDT: o que roda no terminal também roda no runbook
    • Sincronização e compartilhamento com Atuin Hub: mantém tudo atualizado entre dispositivos e equipes

Casos reais de uso e status de distribuição

  • A equipe do Atuin já usa o Atuin Desktop em trabalhos reais
    • Releases do Atuin CLI
    • Migrações de infraestrutura entre ambientes
    • Execuções em staging ou prod
    • Gerenciamento e colaboração em consultas a bancos de dados em produção
  • Entre os próximos recursos estão previstos Team accounts e a criação de runbooks a partir do histórico de shell
  • Ele está em distribuição atualmente, e é possível participar pela lista de early access

Leituras relacionadas

1 comentários

 
GN⁺ 2025-04-23
Opiniões no Hacker News

  • Quem tiver curiosidade sobre Emacs pode fazer algo parecido com org-babel
    Um único arquivo de texto puro pode ser ao mesmo tempo um programa e documentação/notebook/site, e é um exemplo convincente de programação literária
    Há uma boa explicação aqui: https://osem.seagl.org/conferences/seagl2019/program/proposa...

    • Em termos de recursos, org-babel está entre os sistemas de programação literária mais poderosos, e talvez seja o mais forte de todos
      Ele me ajudou muito ao estudar com livros de programação, e, quando volto depois àquele programa literário, retomo o entendimento muito mais rápido do que quando li o livro pela primeira vez
      A parte literária responde às perguntas “bobas” que surgem porque não lembro 100% do raciocínio ou do que eu estava pensando na época
      Claro que há uma curva de aprendizado, então não serve para quem não quer aprender esse tipo de coisa
    • org-babel se encaixa bem nesse trabalho e permite criar uma documentação excelente
      Também dá para ver o vídeo da apresentação[0] e um repositório Git[1] com uma demonstração mais avançada
      [0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
      [1]: https://gitlab.com/spudlyo/orgdemo2
    • Os Shell Worksheets do BBEdit também são parecidos: dá para misturar texto explicativo com comandos que podem ser executados com uma única tecla

  • Tentei fazer isso há cerca de 7 anos: https://nurtch.com/
    A ideia em si tem muitos méritos, e também fiz uma apresentação relacionada na JupyterCon Paris 2023: https://www.youtube.com/watch?v=TUYY2kHrTzs
    Quando há código executável dentro da documentação, as pessoas passam a querer aplicar também à documentação um fluxo de revisão de PR, e isso exige um investimento maior da equipe do que editar uma wiki

    • Minha primeira reação também foi “por que não Jupyter?”, e fico feliz de ver que alguém pensou o mesmo

  • Era exatamente o que eu queria para a nossa equipe quando estava na AWS
    Há muitas tarefas operacionais que são um pouco arriscadas para automatizar totalmente, e isto oferece um caminho para transformar isso em automação de forma iterativa

    • É apenas uma opinião pessoal, não a posição do meu empregador
      Fiquei curioso para saber quando você esteve na AWS
      Nos últimos anos, a AWS criou um serviço interno de plataforma que ajuda a codificar runbooks operacionais e executá-los automaticamente com segurança para reduzir o trabalho operacional repetitivo
      O Atuin Desktop é parecido com esse serviço em alguns aspectos, mas o serviço interno tinha muito mais recursos
    • Quando eu estava na AWS, criei algo que podia ser executado diretamente a partir da wiki
      A ideia era executar consultas do CloudWatch, comandos da AWS CLI e coisas do tipo com entradas do usuário, mas eliminar a carga de configuração de buscar as credenciais corretas com segurança e formatar as entradas
      Depois refiz isso para executar diretamente no GitHub; há aqui um exemplo de chamada de uma função Lambda a partir de uma wiki do GitHub com entradas do usuário em 4 linhas de código: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
    • Se foi no período pré-Covid em que você esteve na Amazon, acho que Eider poderia ter sido usado para esse tipo de finalidade
      Era um notebook hospedado com integração ao IAM

  • Fico curioso sobre como isso difere de um notebook Jupyter local
    Não dá para fazer isso em um .ipynb com ! ou %?
    Pergunto sinceramente, porque não conheço bem esta empresa nem o produto de CLI

    • O maior motivo que me faz evitar notebooks Jupyter quando não se trata de usar exclusivamente Python é o próprio Python
      O fluxo que começa com pipenv/pyenv/conda/poetry/uv/dependencies.txt e “ah, preciso atualizar o Python para executar este notebook… ok” e, duas semanas depois, vira “essa atualização quebrou um Ansible antigo e agora não consigo consertar 15 servidores que já estavam se segurando por pouco” é um inferno
      Tento manter Python longe da automação de base
      Os projetos Python com que lido quebram pelo menos uma vez por ano por problemas de dependências ou de runtime, e isso também vale para Ansible, pipelines de build, coisas como deploy.py
      Notebooks Jupyter trazem uma árvore enorme de dependências e requisitos, então eu não os usaria para automações importantes e fundamentais desse tipo
      Claro, meu trabalho me faz lidar com uma quantidade exagerada de codebases, e só nos últimos dois meses houve pelo menos 6 projetos Python
      Alguns exigem Python 2.7, outros exigem uma versão descartada de lib-something.h, outros estão na vanguarda, e outros não são documentados, mas na prática são extremamente rígidos, do tipo “funciona desde que ninguém atualize nada na máquina de um único desenvolvedor responsável”
      Puppet e Chef também são igualmente ruins por serem Ruby e sofrem dos mesmos problemas, mas há a diferença de que Ruby teve essencialmente um único sistema de gerenciamento de pacotes por décadas
    • Notebooks Jupyter sempre pareceram um pouco uma gambiarra forçada para uso como terminal, então quero experimentar isto
    • Tenho exatamente a mesma pergunta
      Em geral, Jupyter parece oferecer tanto scripting flexível quanto suporte a comandos do sistema operacional
      Também dá para fazer com !/% ou os.system()

  • Isto parece muito semelhante a https://runme.dev

    • Sou cocriador do Runme
      Gosto de documentação executável e acho que ainda não há o suficiente disso

  • Parece interessante
    Recentemente comecei a usar https://marimo.io/ como alternativa aos notebooks Jupyter, e ele traz várias melhorias; isto também parece um movimento em uma direção parecida

  • Se for local-first, já está sujeito a rot
    A menos que tudo rode em contêineres; se rodar em contêineres, o fato de ser local não importa
    Se quiser registrar um runbook, basta registrar um runbook
    Há inúmeras formas: arquivo de texto, documento no Confluence, gravação de tela, script de shell etc.
    As pessoas já não fazem isso, e uma UI mais bonita não vai fazê-las passar a fazer de repente
    Pessoalmente, não quero passar o dia inteiro escrevendo código ou documentação para deixar um sistema no estado X
    Quero criar manualmente o estado X, depois despejar esse estado com uma ferramenta e, mais tarde, executar a ferramenta de novo para criar ou impor esse estado
    Não quero descrever em código como o computador chega a esse estado, nem usar configuração declarativa, que é código com outro nome
    Quero fazer diretamente, tirar um snapshot e reproduzir
    Deve funcionar em qualquer lugar e em qualquer sistema, sem depender de algo como monitorar comandos do shell Bash

    • Então você não ficaria apenas com um blob binário de estado, sem documentação sobre por que aquele estado existe? Não parece manutenível
      Um Dockerfile é, na prática, parecido com isso, mas documenta em um arquivo as etapas percorridas para chegar àquele estado
    • O que você quer parece mais próximo de autoexpect
      https://linux.die.net/man/1/autoexpect
    • Esse tipo de procedimento geralmente tem baixa portabilidade e precisa ser repetido em cada sistema diferente
      A essa altura, é melhor já ter uma descrição declarativa que possa ser convertida automaticamente nas etapas necessárias para chegar ao estado X
    • Isso era a declaração Docker
    • O que você está descrevendo parece mais próximo do Ansible
      Para tarefas comuns, como verificar se um pacote está instalado, se um arquivo existe ou se tem determinado conteúdo, você usa módulos; é declarativo e idempotente

  • Fico curioso se isto também será open source, como o Atuin CLI e o servidor de sincronização
    A ideia é transformá-lo em produto?

  • Não entendo muito bem por que isso é necessário
    Alguém pode explicar o que estou perdendo? Por que eu deveria usar isso em vez de um simples script de shell?

    • Minha experiência com runbooks foi assim
      Você está em uma equipe responsável por várias coisas; algumas conhece muito bem e mexe com frequência, outras você só sabe vagamente que existem e quase nunca toca
      X, que está no segundo grupo, quebra
      Todas as pessoas que realmente conhecem X estão de férias/mortas/em reunião
      Felizmente, há um documento explicando o que fazer nessa situação
      Mas, de alguma forma, esse documento é um milagre de informação ruim: desatualizado e errado
      Esse é o problema que isto tenta resolver
      Pelo que conversei um pouco com o criador, a intenção é algo mais próximo de criar um meio-termo entre Jupyter Notebooks e Ansible Tower
      Documentação, scripts e métricas ficam próximos entre si, facilitando entender o que deu errado, como corrigir e se a correção funcionou
      [1] Divulgação: ajudo a administrar o Discord do atuin
    • Parece programação literária para scripts de shell
      Por isso “Runbooks That Run”
    • Porque foi escrito em Rust e isto é o Hacker News
    • Qual é o objetivo de normalmente estruturar deploys com ferramentas como Ansible ou Deployer? E por que empacotar scripts Python adicionais para tarefas comuns e colocar tudo em um repositório Git?
      Algumas pessoas gostam de certos workflows ou fluxos de ferramentas e simplesmente os criam
      Se servir para gente suficiente, pode ou não haver mercado
      Em projetos pessoais, uso um processo de deploy em PHP só porque quero, e ele faz 60% do trabalho sem que eu precise fazer separadamente
      O runbook para isso são tarefas embutidas na ferramenta e ficam no mesmo repositório Git do deploy completo do servidor
      Não quero colocar isso em algum lugar arbitrário nem em um script de shell para o qual eu precise lembrar um comando separado
      Para programadores, código se torna essencialmente autodocumentado quando evita complexidade e mantém um estilo funcional simples
      Só é preciso comentar ocasionalmente as partes que não são fluxos simples, como “criar um usuário MySQL, rotacionar a senha, refletir a nova combinação usuário/senha nos serviços relacionados e remover o usuário antigo cujas credenciais um funcionário demitido tinha, caso o bloqueio da VPN tenha falhado”

  • A ferramenta dos meus sonhos é uma em que todas as ferramentas ofereçam uma interface de terminal, permitindo criar um grande livro com todo o contexto que está na minha cabeça
    Algo como reunir Jira, Datadog, GitHub etc. em uma única tela

    • Pessoalmente, também gosto de uma TUI um pouco mais amigável
      Imagine um framework interno de TUI com componentes para cada serviço interno, que possam ser montados como Lego para criar dashboards TUI personalizados
      Parece algo que daria para fazer como projeto paralelo na empresa; seria um trabalho enorme, mas interessante
    • Só ter APIs já é suficiente; dá para criar ferramentas em cima delas
      Em um mundo ideal, todos os serviços, ferramentas e aplicativos ofereceriam uma API que eu pudesse usar
      Por exemplo, se a porta da geladeira ficar aberta por tempo demais, detectar isso por polling da API ou por webhook e usar a API do Roomba para mandá-lo fechá-la
      Por que não? É o mundo das APIs
    • GitHub e Datadog já têm ferramentas CLI oficiais
    • Talvez você esteja falando de algo como o wtfutil
      Parece que o desenvolvimento está parado há um ano, mas a ideia é mais ou menos essa
      https://wtfutil.com/
    • Nesse caso, talvez você goste de MCP