Docker é estranho

Artigo original ↗ Discussão no Hacker News ↗

Engenheiros analisam por que o Docker parece “estranho”, traçando como ele empacota primitivos do Linux como namespaces e cgroups na ilusão de máquinas autossuficientes e como escolhas iniciais de design — como um daemon executado como root, um runtime em Go e a sintaxe do Dockerfile — moldaram tanto sua força quanto suas peculiaridades. Os participantes contrastam o Docker com alternativas como Podman, Incus e Firecracker, debatendo operação rootless, modelos de rede e a adequação de Go versus C ou Rust para trabalho de baixo nível com containers. Há amplo consenso de que as verdadeiras inovações do Docker foram a experiência do desenvolvedor, as camadas de imagem e o registro central, que mudaram fundamentalmente como o software é empacotado e implantado, mesmo com o ecossistema tendo avançado para runtimes mais leves ou mais seguros.

Origem, história e impacto do Docker

  • O Docker surgiu de anos de experimentação com vserver/openvz/LXC e sistemas de arquivos em camadas dentro de uma empresa de PaaS, depois fez pivot a partir desse PaaS.
  • Inovações importantes destacadas: Dockerfiles e camadas de imagem (builds rápidos e cacheáveis), um registro centralizado de imagens e evangelização e demonstrações incessantes.
  • Muitos comentaristas dizem que ele transformou suas carreiras e fluxos de trabalho, substituindo Vagrant, configurações artesanais de LXC/Zones, longos guias de configuração e problemas de “funciona na minha máquina”.
  • Alguns argumentam que o principal valor foi tornar primitivos do kernel (namespaces, cgroups, chroot) trivialmente acessíveis; outros enfatizam o registro e o impulso do ecossistema.

Escolha da linguagem e design do runtime

  • O projeto original usava Python; o Docker depois escolheu Go por binários estáticos, adoção entre “tribos” diferentes e facilidade para contribuidores.
  • O criador e outros concordam que Go era desajeitado para trabalho de baixo nível com containers (clone, namespaces), exigindo shims em C e contornos, mas ainda assim foi o trade-off certo na época.
  • O comportamento de threading e goroutines causou bugs sutis (por exemplo, namespaces não limpos, dificuldade com syscalls dependentes de thread).
  • Debate sobre Rust: alguns dizem que hoje escolheriam Rust ou C para um runtime; outros argumentam que a velocidade de desenvolvimento do Rust e o borrow checker o tornam impraticável para muitas equipes.

Daemon, root e modelo de permissões

  • O modelo cliente-servidor com daemon do Docker é fortemente debatido:
    • Críticos: complica permissões, faz o socket do Docker ≈ root, entra em conflito com firewalls, é desajeitado em sistemas multiusuário.
    • Defensores: nos primórdios do Linux/containers, era a forma pragmática de permitir que usuários sem root gerenciassem containers e unificar a experiência de Mac/Windows/Linux.
  • Modos rootless agora existem, mas chegaram tarde; Podman e outros ganharam tração por serem daemonless/rootless por padrão.

Rede e terminologia

  • Há forte discordância sobre as redes “bridge” do Docker:
    • Administradores de rede argumentam que o termo é enganoso em relação a bridging tradicional e domínios de broadcast, e que os padrões (NAT, ajustes de DNS) surpreendem equipes de operações.
    • Outros insistem que a terminologia corresponde aos dispositivos Linux bridge subjacentes e que as redes do Docker são principalmente para conectividade entre containers, com NAT apenas como conveniência.

Comercialização e ecossistema

  • Vários comentários analisam as dificuldades de negócio do Docker: divisão cultural entre equipes de open source e enterprise, falta de um “ditador” único e forte para o produto, e monetização difícil de uma ferramenta central para desenvolvedores.
  • Alguns acreditam que ignorar certas necessidades corporativas abriu espaço para concorrentes; outros dizem que esses problemas não foram os verdadeiros bloqueadores comerciais.

Uso atual, alternativas e evolução

  • O Docker continua central em muitos fluxos de trabalho de desenvolvimento e CI, especialmente via Compose.
  • Alguns usuários migraram para Podman, Incus, LXC/systemd-nspawn ou configurações baseadas em Firecracker para melhor isolamento ou propriedades de segurança mais simples.
  • Novas ferramentas (por exemplo, Dagger, Range) se apoiam em ideias de containers/imagens para otimizar CI e execução sob demanda sem daemons ou registros tradicionais.

Aprendizado e educação

  • Visões divididas sobre ensinar Docker: alguns dizem que a sintaxe do Dockerfile é trivial e pode ser facilmente delegada a ferramentas/LLMs; outros enfatizam entender containers versus VMs, namespaces, camadas e cache como o verdadeiro valor educacional.