Uma lição sobre dockerizar scripts de shell

Artigo original ↗ Discussão no Hacker News ↗

Esforços para reduzir uma imagem Docker para uma ferramenta bash de 500 linhas destacam a troca entre tamanhos mínimos de imagem e manutenção de longo prazo. Comentadores alertam que copiar manualmente binários e bibliotecas compartilhadas para uma imagem `scratch` ou baseada em Alpine pode criar containers frágeis e difíceis de depurar, que quebram com atualizações do sistema operacional, por uma economia de espaço apenas marginal em relação a uma base simples de 30 MB. A conversa se amplia para quando faz sentido containerizar scripts shell simples, abordando alternativas como binários estáticos, BusyBox, Nix e gerenciadores de pacotes tradicionais, além de ferramentas para analisar e otimizar imagens.

Tamanho da imagem vs. complexidade

  • Muitos acham que a imagem inicial de ~31 MB já é “pequena o suficiente”; reduzir mais para ~17 MB não valeria a complexidade extra na maioria dos usos em produção.
  • Vários comentaristas preferem aceitar uma imagem de 30–40 MB a manter um Dockerfile frágil e altamente ajustado.
  • Outros gostam do exercício de otimização como ferramenta de aprendizado e apreciam a exploração do que é minimamente necessário para executar o script.

Cópia de binários e bibliotecas compartilhadas

  • Crítica forte a copiar binários e arquivos .so diretamente de uma imagem Alpine para outra (ou para scratch) e sobrescrever caminhos de sistema lib/bin.
  • Preocupações: divergência de versões, links simbólicos quebrados, incompatibilidades sutis conforme as imagens base evoluem, e imagens frágeis que podem quebrar silenciosamente depois.
  • Alguns argumentam que isso é parcialmente mitigado quando a origem e o destino usam a mesma versão base, mas outros veem o padrão como uma reinvenção “anti‑gerenciador de pacotes”.

Alpine, reprodutibilidade e pinning

  • Alpine é descrito como hostil ao pinning de versões e a builds reprodutíveis de longo prazo: pacotes e índices desaparecem rapidamente.
  • Recomendação: não use Alpine se você precisa de builds Docker reprodutíveis e amigáveis ao cache; imagens Debian baseadas em snapshots são citadas como uma direção mais promissora.

Alternativas para imagens pequenas

  • As sugestões incluem:
    • Binários estáticos ou builds com BusyBox em vez de copiar muitas ferramentas individuais.
    • Usar Nix para definir imagens de forma declarativa; funciona, pode ser muito pequeno, mas frequentemente traz fechamentos grandes (por exemplo, gitMinimal ainda é grande) e adiciona complexidade.
    • Reescrever a ferramenta em uma linguagem compilada com um único binário estático, se alguém estiver disposto a investir esforço.

Segurança, confiança e auditoria

  • Debate sobre se “scripts shell aleatórios” ou “imagens Docker aleatórias” são mais seguros.
  • Pontos a favor dos scripts: mais fáceis de ler e de passar por ferramentas como ShellCheck.
  • Pontos a favor dos containers: isolamento via namespaces e controles de volume/rede, com ferramentas como Dive para inspecionar o conteúdo.
  • Contraponto: containers não são barreiras fortes de segurança; existem escapes, e auditar imagens inteiras mais camadas base não é trivial.

Utilidade de dockerizar um script de shell

  • Alguns consideram containerização exagerada para um script bash de 500 linhas que só precisa de ferramentas padrão.
  • Outros argumentam que containers simplificam o gerenciamento de dependências e tornam as ferramentas reproduzíveis em muitas máquinas.
  • Preocupações práticas levantadas: ainda é preciso um wrapper (script/alias/compose) para montar o diretório de trabalho e tornar o uso ergonômico.