Dagger Shell - um novo shell para a era dos contêineres

• O shell Unix é usado há mais de 50 anos e sempre foi uma ferramenta poderosa de computação, capaz de combinar operações complexas com comandos simples
  • Porém, a stack moderna de software ficou muito mais complexa, e o shell tradicional tem dificuldade para lidar com tudo isso
  • Inspirado por Docker, make, PowerShell, Nix e outros, surgiu a necessidade de um shell moderno com suporte nativo a contêineres, segredos, endpoints de serviço, execução declarativa, cache e sandboxing
• Dagger Shell é um frontend baseado na sintaxe do bash para o Dagger Engine, podendo ser usado em várias tarefas de automação, como build, testes, deploy e ambientes temporários
• Em vez de substituir o shell do sistema, ele funciona como uma ferramenta complementar, ajudando a montar workflows complexos por meio da combinação simples de módulos

  container |  
    from alpine |  
    with-exec apk add git |  
    terminal  
  

• Só shell e código já bastam

  • Em vez de aprender uma DSL esquisita para lidar com scripts complexos, é possível escrever em uma linguagem de programação de verdade
  • Há SDKs disponíveis para Go, Python, Typescript, Java, PHP e outras linguagens
  • Também é possível expandir funções escritas nessas linguagens como novos primitivos do Dagger

• Um shell conectado à API

  • O Dagger Shell atua como cliente da API do Dagger, com acesso a objetos tipados, documentação e ao ecossistema de módulos reutilizáveis (Daggerverse)
  • Por exemplo, é possível carregar e executar o módulo de varredura de segurança Trivy

• Ambiente de sandbox por padrão

  • Todos os comandos são executados em sandbox por padrão, e o acesso a arquivos, segredos e serviços precisa ser especificado explicitamente. Fica um pouco mais verboso, mas ganha em reprodutibilidade e segurança

    container |  
      from alpine |  
      with-secret-variable POSTGRES_PASSWORD op://dev/db-password/credential |  
      with-directory /src ~/src/myapp |  
      with-service-binding db tcp://localhost:5432 |  
      terminal  
    

• Build simples de contêiner

  • Dá para criar um contêiner baseado em Alpine, inserir um arquivo de texto, configurar a saída de uma mensagem e até fazer push para um registro temporário em uma única execução
  • Tudo isso sem precisar alternar de contexto entre escrever o Dockerfile, rodar o comando de build e fazer o push

    # Build a wolfi linux container with curl, then test connection to stable and dev docs  
    github.com/dagger/dagger/modules/wolfi | container --packages=curl |  
      with-service-binding docs-stable $(github.com/dagger/dagger/docs@v0.17.1 | server) |  
      with-service-binding docs-dev $(github.com/dagger/dagger/docs@main | server) |  
      with-exec curl http://docs-stable |  
      with-exec curl http://docs-dev  
    

• Configuração de ambiente de testes

  • Também é possível lidar de forma simples com a configuração de ambientes de teste, um problema frequente em CI
  • Com suporte nativo a service binding, dá para conectar várias instâncias ativas e testar com facilidade

    repo=$(git https://github.com/dagger/hello-dagger | head | tree)  
    
    env=$(container | from node:23 | with-directory /app $repo | with-workdir /app)  
    
    build=$($env | with-exec npm install | with-exec npm run build | directory ./dist)  
    
    container | from nginx | with-directory /usr/share/nginx/html $build | terminal --cmd=/bin/bash  
    

• Builds em múltiplos estágios (Multi-Stage Builds)

  • É possível implementar pipelines de build complexos com uma sintaxe clara e modular
  • Ao declarar cada etapa em variáveis, fica mais fácil depurar e reutilizar

    container |  
      from golang:latest |  
      with-directory /src $(git https://github.com/dagger/dagger | head | tree) |  
      with-workdir /src |  
      with-exec go build ./cmd/dagger |  
      file ./dagger |  
      export ./dagger  
    

[winterjung]

Só para constar, o link foi alterado para https://dagger.io/blog/…

[GN⁺]

Comentários do Hacker News

• Ultimamente, parece cada vez mais difícil entender para que o Dagger serve de fato

  • No começo, havia a expectativa de que ele pudesse substituir o Jenkins
  • Oferecia uma alternativa para executar e depurar pipelines de CI localmente
  • Era escrito em Golang e permitia importar o que fosse necessário
  • Agora a direção parece dispersa: quer substituir o Docker, virar um novo shell e, de forma estranha, parece querer virar o Langchain também
  • Os novos argumentos de CLI não parecem melhores do que scripts de shell existentes ou um Jenkinsfile
  • É uma pena que o projeto pareça ter se afastado do objetivo original

• Costumo combinar Dockerfile e scripts de shell para montar várias imagens

  • É preciso executar de forma diferente dependendo do ambiente, como máquina de desenvolvedor, robô ou CI
  • Parece que essa ferramenta pode resolver essa complexidade
  • Gosto do fato de ser possível referenciar a saída do build sem precisar lidar com tags

• Não tinha percebido que o Dagger está tentando substituir o Docker

  • É uma visão grandiosa
  • É uma tentativa ambiciosa, mas difícil acreditar que consiga substituir as ferramentas existentes já agora
  • É uma pena que tenham escolhido compatibilidade com Bash
  • Acho que já passou da hora de deixar para trás a sintaxe e os problemas do Bash

• Já existe uma interface web que permite escrever scripts do Dagger Shell em formato de notebook

  • Muito interessante, recomendo conferir

• Fiquei curioso ao ver a descrição na página inicial do Dagger

  • "Motor de composição multiplataforma"
  • Construa ambientes de software poderosos com componentes modulares e funções simples
  • Adequado para builds complexos e fluxos de trabalho de IA
  • É genérico demais, então não ajuda em nada
  • Tudo é um motor de composição. Javascript também é, macOS também é um motor de composição

• Autopromoção relacionada

  • Docker shell container: https://github.com/jrz/container-shell

• O objetivo é fazer trabalho de desenvolvimento dentro de contêineres?

  • Isso me lembra o Devbox da Jetify e o Flox.dev

• Em termos claros, o que dá para fazer com essa ferramenta?

  • Em que tipo de atividade ela ajuda?
  • Que programa ela pode substituir?
  • O que faz um "sistema operacional de DevOps"?

• A primeira impressão é de que fica em algum ponto intermediário entre Dockerfile e definir/configurar software com código de verdade

  • Como alguém que usa muito Nix, isso não me parece atraente

• O Dagger mudou a direção do produto?

  • Lembro que o principal argumento de venda era ser um serviço independente de pipeline-as-code
  • Agora parece estar tentando reconfigurar o Docker