A Maldição do Docker

Artigo original ↗ Discussão no Hacker News ↗

Desenvolvedores e operadores avaliam os benefícios do Docker em simplificar a implantação contra seu papel crescente como uma ferramenta grosseira de empacotamento para software de servidor. Muitos elogiam os containers por setups reprodutíveis, experimentação mais fácil e redução de problemas de “funciona na minha máquina”, mas criticam a proveniência das imagens, a configuração opaca, a segurança com root por padrão e o peso de aplicar patches em muitos sistemas base separados. Alternativas como pacotes tradicionais de distros, Nix, VMs e práticas de containerização mais disciplinadas são mencionadas como formas de recuperar controle sobre dependências e manutenção de longo prazo.

Escopo da Crítica: Docker como Distribuição vs Implantação

  • Muitos comentaristas dizem que o artigo trata, na verdade, do Docker sendo mal utilizado como mecanismo de distribuição (como um formato de pacote), e não sobre containers para implantação.
  • Reclamação: enviar apenas uma imagem Docker (ou uma stack docker‑compose) esconde dependências e torna mais difícil a integração com a infraestrutura existente (bancos de dados, backups, monitoramento, autenticação, TLS).
  • Defesa: para apps complexos (por exemplo, muitos serviços como BD, cache, filas), docker compose up reduz drasticamente a barreira para experimentar e executar software, especialmente para entusiastas e pequenas equipes.

Confiança, Proveniência e “Imagens Aleatórias da Internet”

  • Preocupação: as pessoas executam imagens de terceiros casualmente, sem pensar muito em manutenção, suporte, garantias de atualização, suporte a arquiteturas ou disponibilidade de longo prazo.
  • Alguns argumentam que imagens “oficiais” de organizações (por exemplo, Bitnami, linuxserver.io) ainda são, na prática, binários aleatórios da internet, a menos que você tenha uma relação comercial ou garantias claras.
  • Outros respondem que todas as stacks de software envolvem confiança (distros, hardware, nuvem), e que containers são apenas mais uma camada de confiança.

Segurança, Root e Atualizações

  • Problema amplamente observado: executar containers como root é algo normalizado, e tornar imagens sem root/somente leitura é trabalhoso, então os padrões inseguros vencem.
  • Foram levantadas dúvidas sobre como as organizações realmente gerenciam atualizações de segurança de imagens base e bibliotecas em muitos containers; alguns dizem que rebuilds em CI + scanners e ferramentas (por exemplo, estilo Watchtower) tornam isso um problema “resolvido”, outros dizem que, na prática, a maioria não faz isso bem.

Configuração, Sistemas de Arquivos e Rede

  • Pontos de dor frequentes:
    • Montagens de arquivos/volumes e mapeamento de UID são complicados; copiar arquivos para dentro e para fora de containers muitas vezes quebra por causa de permissões.
    • A rede do Docker e o Docker Compose se tornam frágeis em hosts complexos; a rede do podman também foi apontada como problemática por alguns.
    • Geradores de configuração/scripts de entrypoint e configuração em várias camadas (Helm → variáveis de ambiente → imagem → app) podem tornar a depuração muito opaca.

Alternativas e Debate Mais Amplo sobre Empacotamento

  • Nix/NixOS é repetidamente citado como uma resposta melhor para reprodutibilidade, isolamento de dependências e controle da cadeia de suprimentos; outros observam que ele ainda tem binários fechados e complexidade.
  • Alguns defendem empacotamento tradicional de sistemas operacionais, binários estáticos (Go, musl) ou modelos simples de “um único EXE/zip” (como no Windows), por serem mais limpos que o Docker.
  • Meta-tema: o Docker é visto tanto como uma enorme melhoria prática em relação ao caos pré-containers quanto como uma ferramenta que perpetua preguiça, complexidade e stacks opacas.