- Um artigo da ACM que destaca o processo de evolução técnica do Docker, que desde seu primeiro lançamento em 2013 mudou fundamentalmente a forma como desenvolvedores fazem build, deploy e execução de aplicações, organizando décadas de pesquisa em sistemas escondidas por trás de uma CLI aparentemente simples
- A base técnica central do Docker é a forma de alcançar isolamento de processos sem máquinas virtuais usando namespaces do Linux; ao combinar os 7 tipos de namespaces adicionados gradualmente desde 2001, ele implementa contêineres leves
- Para oferecer suporte a macOS e Windows, adotou uma arquitetura contraintuitiva ao embutir um library virtual machine monitor (HyperKit) dentro do app desktop, executando Linux dentro de um processo de usuário em vez de seguir a abordagem tradicional com hypervisor
- Hoje, oferece suporte a hardware heterogêneo como ARM e RISC-V e a workloads de IA, consolidando-se como infraestrutura padrão de desenvolvimento em nuvem, desktop e edge
- Com a ascensão dos workloads de IA, o gerenciamento de dependências de GPU surgiu como um novo desafio, e a evolução do Docker continua com suporte a GPU por meio do CDI (Container Device Interface) e integração com TEE (ambiente de execução confiável)
Origens técnicas
- No início dos anos 2000, era comum instalar manualmente inúmeras dependências em distribuições Linux e compilar e configurar software diretamente, e esse processo ficou ainda mais complexo com a ascensão da computação em nuvem em 2010
- O Docker simplificou isso ao permitir que desenvolvedores empacotassem a aplicação e todas as dependências como uma imagem de sistema de arquivos ("contêiner"), capaz de rodar em qualquer máquina com Docker instalado
- Diferentemente de uma máquina virtual, ele pode ser executado com apenas alguns comandos, sem instalar um sistema operacional completo
Fluxo de trabalho típico
- Quando o desenvolvedor escreve um Dockerfile, define um processo de build em etapas com base em sintaxe de shell
- Exemplo de site em Python: começa com
FROM python:3 e descreve em um único arquivo a instalação de dependências, cópia do código, exposição de portas e comando de execução
- Usa-se
docker build para criar a imagem do contêiner e docker push para enviá-la ao Docker Hub
- A execução é feita com opções como
docker run -v data:/app/data -p 80:80, especificando montagem de volumes de dados e exposição de portas de rede
- Desde 2013, a CLI foi bastante expandida e o backend foi totalmente redesenhado, mas o fluxo básico de Dockerfile →
docker build → docker run permaneceu consistente
- Mais de 3,4 milhões de Dockerfiles foram encontrados na raiz de repositórios públicos no GitHub
Como funciona por dentro: namespaces do Linux
- O kernel do sistema operacional isola a memória dos processos, mas muitos recursos do sistema, como sistema de arquivos, arquivos de configuração e bibliotecas dinâmicas, continuam compartilhados
- É muito difícil instalar vários apps na mesma máquina quando eles têm requisitos conflitantes de bibliotecas dinâmicas
- Também pode haver interferência indesejada entre processos, como conflitos de portas de rede
- Executar cada app em uma máquina virtual (VM) separada resolve isso, mas é muito pesado por causa de kernels, sistemas de arquivos, caches e redes em bridge duplicados
- Como cada sistema operacional convidado funciona de forma independente, também é difícil eliminar duplicação de armazenamento e memória
- O
chroot() do Unix v7, em 1978, permitia um sistema de arquivos raiz separado, mas não dava suporte à composição de sistemas de arquivos para múltiplos apps
- Nix e Guix resolvem isso com reempacotamento por diretório de app + ligação dinâmica, mas são difíceis de aplicar a software proprietário e não resolvem conflitos de portas de rede
- O Docker escolheu os namespaces do Linux: cada processo pode controlar individualmente como acessa recursos compartilhados, como arquivos e diretórios
- Exemplo: dois processos em namespaces diferentes podem interpretar
/etc/passwd de formas distintas, como /alice/etc/passwd e /bob/etc/passwd
- O namespace é aplicado apenas no momento de abrir o recurso; depois disso, o file descriptor funciona como um recurso normal do kernel, sem overhead adicional
- Histórico da introdução dos namespaces
- 2001, Linux 2.5.2: mount namespace
- 2006, Linux 2.6.19: IPC namespace
- 2007, Linux 2.6.24: namespace da pilha de rede
- Suporte total a 7 tipos de namespaces
- Diferentemente do Plan 9, os namespaces não foram projetados desde o início, mas adicionados gradualmente, o que os tornava de baixo nível e difíceis de usar
- Recursos semelhantes em FreeBSD e Solaris também não chegaram ao uso popular
- A principal contribuição do Docker em 2013: encontrar um equilíbrio prático entre o isolamento pesado das VMs e a facilidade de uso dos elementos nativos do sistema operacional
Estrutura de execução de contêineres Linux no Docker
- O Docker tem uma estrutura cliente-servidor, composta por um daemon de servidor executado no host (
dockerd) e um cliente CLI que envia requisições por meio de uma API RESTful
- Por volta de 2015, o daemon monolítico foi dividido e reorganizado em componentes especializados
- BuildKit: montagem da imagem de sistema de arquivos
- containerd: instancia imagens como contêineres em execução e gerencia recursos de rede e armazenamento
Imagens de contêiner
- Ao chamar
docker build, é criada uma imagem de sistema de arquivos em camadas que representa os executáveis e dados definidos no Dockerfile
- Camada mais baixa: uma distribuição de sistema operacional como Debian ou Alpine Linux (ou montagem manual a partir de um arquivo tar)
- Camadas seguintes: diferenças no sistema de arquivos geradas pelo resultado da execução de cada comando individual do Dockerfile
- Armazenadas em um sistema de storage com endereçamento por conteúdo: a chave é o hash da imagem do sistema de arquivos
- Deduplicação eficiente, garantia de imutabilidade e verificação de adulteração por hash
- Em 2016, a Open Container Initiative (OCI) padronizou o formato de imagem, e hoje existem várias implementações independentes
- Usa recursos de sistemas de arquivos Linux como overlayfs, btrfs e ZFS para snapshot e clone eficientes de camadas copy-on-write
- Suporte a lazy-pulling de imagens por meio do snapshotter de storage
stargz
Instâncias de contêiner
- Ao chamar
docker run, são alocados recursos do sistema para criar, a partir de uma imagem OCI, um processo isolado por namespaces (o "contêiner")
- O
containerd configura dinamicamente os namespaces necessários para cada contêiner e executa tarefas como:
- Definir cgroups (grupos de controle) de processos para isolamento de recursos e limitação de velocidade de I/O
- Remapear portas de rede locais dentro do contêiner para portas expostas externamente na interface do host
- Conectar volumes de armazenamento mutável do sistema de arquivos do host para manter o estado persistente da aplicação
- Isolar a árvore de processos do contêiner com PID namespace
- Mapear, com user namespace, UIDs locais dentro do contêiner para UIDs diferentes no host (ex.: UID 1000 dentro do contêiner → UID 12345 ou 23456 no host)
- Há um pequeno overhead na configuração dos namespaces, mas muito menor do que iniciar uma VM Linux completa, e na maioria dos casos leva menos de 1 segundo
- O kernel Linux faz a coleta de lixo dos contêineres encerrados como se fossem processos comuns
Além do Linux: suporte a macOS e Windows
- Graças à arquitetura cliente-servidor, a CLI pode enviar comandos a instâncias remotas do Docker por uma conexão de rede segura
- Em 2015, embora o Docker já fosse amplamente adotado no desenvolvimento em Linux, surgiu uma barreira de usabilidade para desenvolvedores de macOS e Windows que não conseguiam executar contêineres Linux
- A maioria dos desenvolvedores usa macOS ou Windows como ambiente principal de desenvolvimento, mas as imagens de sistema de arquivos do Docker só podem ser executadas em kernels Linux
- Com a ascensão da nuvem pública, o Linux passou a ser o ambiente preferido para deploy
Construção do aplicativo Docker for Mac
- Restrição principal: para desenvolvedores acostumados ao Docker na versão Linux, precisava funcionar sem configuração adicional e executar as mesmas imagens Docker
- Revertendo a abordagem anterior (executar o Linux separadamente ao lado do SO de desktop), o hipervisor foi embutido dentro de um app em espaço de usuário do macOS/Windows, e o Linux passou a rodar ali dentro
- Inspiração em pesquisas de unikernel: provaram que componentes de SO podem ser embutidos de forma flexível dentro de aplicações maiores
- HyperKit: um VMM em forma de biblioteca que usa extensões de virtualização de hardware das CPUs Intel para executar o kernel Linux em um processo comum de usuário
- O kernel Linux embutido executa o daemon do Docker, que gerencia os contêineres e atua como um endpoint de servidor Docker normal
- Todos os detalhes de administração do Linux ficam ocultos dentro do app de desktop →
docker build e docker run no desktop são encaminhados para a instância Linux embutida e "simplesmente funcionam"
- Essa abordagem também foi adotada por outros sistemas de contêiner, como o Podman, e se tornou o padrão para executar contêineres em macOS/Windows
LinuxKit: distribuição Linux customizada e embarcada
- Uma distribuição Linux customizada projetada para ser embutida como componente de outros apps, e não para funcionar de forma independente
- Para minimizar o tempo de inicialização do app, foi criado um espaço de usuário customizado contendo apenas os componentes mínimos necessários para executar contêineres Docker
- Cada componente individual roda dentro de um contêiner, de modo que nada roda no namespace raiz usado na inicialização
- Aproveita o mesmo sistema de arquivos copy-on-write e namespaces de rede usados pelos contêineres Docker
- A combinação de LinuxKit + HyperKit permite iniciar processos Linux em velocidade quase igual à de processos nativos do macOS
- Lançado em 2016 nos apps Docker for Mac e Windows
Problemas de rede e a solução com SLIRP
- A conexão de rede entre contêineres Linux embutidos e macOS/Windows acabou sendo um problema inesperadamente difícil
- O método tradicional de ponte Ethernet exigia gerenciamento de rede complexo, e firewalls e antivírus em desktops corporativos detectavam isso como tráfego potencialmente malicioso, gerando milhares de relatórios de bugs de usuários beta
- Solução com SLIRP: ferramenta usada originalmente em meados dos anos 1990 para conectar o Palm Pilot PDA à internet
- Durante o handshake TCP do contêiner, quadros Ethernet são enviados ao host via memória compartilhada usando o protocolo virtio
- Bibliotecas unikernel do MirageOS são usadas para converter solicitações de rede do Linux em chamadas de socket nativas do macOS/Windows
- A pilha TCP/IP em espaço de usuário vpnkit, escrita em OCaml, recebe isso no SO hospedeiro e chama a syscall
connect() do macOS
- Do ponto de vista das políticas de VPN, o tráfego de saída é reconhecido como tendo sido gerado pelo app Docker, e não por uma máquina separada
- Depois da distribuição do vpnkit no beta de 2016, os relatórios de bugs de usuários corporativos caíram mais de 99%
- A abordagem SLIRP depois também foi adotada na área de cloud serverless, mostrando como uma técnica antiga de rede dial-up foi usada para resolver um novo problema de gerenciamento de contêineres
Tratamento do tráfego de rede de entrada
- Quando um contêiner Linux escuta em uma porta, ele não é exposto automaticamente à internet a menos que isso seja solicitado explicitamente na CLI (ex.:
docker run -p 80:80 nginx)
- Experiência ideal para o usuário: a porta do contêiner aparece diretamente no IP do desktop, acessível no navegador via
http://localhost:8080
- Soluções anteriores de virtualização para desktop, como o VMware Fusion, expunham um IP intermediário temporário em vez de
localhost
- Um programa eBPF customizado foi instalado no kernel do LinuxKit → isso dispara a criação de um socket em escuta correspondente no host desktop → ativa o encaminhador de portas
- Resultado: ao executar um contêiner Linux no Mac, ele fica imediatamente acessível via
localhost, oferecendo a mesma experiência de desenvolvimento de uma máquina Linux nativa
Armazenamento
- O desenvolvedor precisa editar o código localmente enquanto executa o código e os testes dentro do contêiner
- No Linux, o acesso em tempo real aos arquivos é feito com bind mount via
docker run -v /host:/container
- No macOS e no Windows isso não funciona, porque os kernels são diferentes
- O Docker usa o protocolo de memória compartilhada virtio-fs, derivado do hipervisor KVM, para enviar operações de sistema de arquivos ao host (no formato de requisições FUSE)
- O host recebe essas requisições e chama as syscalls correspondentes
open, read e write
- O código e os dados do desenvolvedor permanecem no sistema de arquivos do host, podendo ser acessados por ferramentas de backup e busca como o Time Capsule e o Spotlight da Apple
Windows Services for Linux (WSL)
- Em 2017, a Microsoft lançou o WSL: execução direta de apps Linux no Windows
- A primeira versão usava uma abordagem de SO-biblioteca que convertia dinamicamente as chamadas de sistema de binários Linux em chamadas de sistema do Windows, em vez de virtualização
- Teve sucesso com muitos apps, mas não tinha chamadas de sistema suportadas suficientes para executar contêineres Docker
- Em 2018, o WSL2 foi lançado: redesenhado para executar uma VM Linux completa em segundo plano, de forma semelhante ao Docker for Mac
- O Docker no WSL2 executa o daemon e os contêineres de usuário dentro da distribuição LinuxKit WSL
- O próprio Windows e outras distribuições Linux lidam com a API do Docker e o encaminhamento de portas de rede
- A arquitetura central que tornou possível a evolução multiplataforma dos contêineres Docker: uma abordagem de SO-biblioteca que reaproveita o que tradicionalmente era “código exclusivo do kernel” como bibliotecas em espaço de usuário embutidas em outros apps
- O sucesso dessa arquitetura se comprova pelo fato de ser invisível e onipresente: milhões de desenvolvedores usam Docker todos os dias sem se preocupar com em qual SO ele está rodando
Novo fluxo de trabalho para desenvolvedores: múltiplas arquiteturas de CPU
- No início do Docker, a maior parte das cargas de trabalho em nuvem era baseada na arquitetura Intel
- A situação mudou com o lançamento do processador Amazon Graviton ARM em 2018 e da CPU Apple M1 ARM em 2020
- Executar cargas de trabalho em ARM pode trazer redução de custos e ganho de desempenho
- Passou a ser necessário oferecer suporte, dentro da mesma imagem Docker, a múltiplas arquiteturas de CPU, como Intel, ARM, POWER e RISC-V
- No lado do servidor, o formato de imagem OCI foi expandido com multiarch manifests
- Para criar imagens para várias arquiteturas de CPU em um único host, usa-se o recurso
binfmt_misc do Linux
- O QEMU faz a tradução transparente entre binários ARM e Intel
- O overhead ocorre principalmente só na etapa de build; a imagem multiarquitetura resultante roda nativamente em qualquer host
- A Apple introduziu, com o Rosetta, suporte de hardware e software para tradução entre conjuntos de instruções de CPU → isso foi facilmente integrado à arquitetura do Docker
- Hoje, executar contêineres Intel e ARM lado a lado é um fluxo de trabalho comum para desenvolvedores
Gerenciamento de segredos com ambientes de execução confiáveis (TEE)
- Em ambientes de contêiner, o gerenciamento de segredos, como senhas e chaves de API, sempre foi um desafio
- Eles precisam ser injetados dinamicamente, sem serem embutidos na imagem do sistema de arquivos
- O Docker oferece suporte a encaminhamento de socket, permitindo montar sockets de domínio local dentro do contêiner
- No caso do Docker for Mac/Windows, o socket é encaminhado até a VM Linux
- Isso permite usar, dentro do contêiner, sistemas de gerenciamento de chaves como o
ssh-agent sem expor diretamente as chaves
- O encaminhamento de socket fornece um nível básico de proteção, mas são necessárias mais camadas de defesa contra malware em uma cadeia de suprimentos de software cada vez maior
- A proteção do hipervisor é aplicada diretamente no runtime de contêiner para aumentar o nível de proteção entre contêineres
- Ambientes de Execução Confiáveis (TEE): recursos de hardware de CPUs modernas permitem criar VMs confidenciais capazes de proteger dados secretos até mesmo do SO hospedeiro
- É possível aplicar restrições de acesso a dados além das fronteiras do app, do kernel e do hipervisor
- Porém, configurar e usar TEE também traz uma complexidade operacional semelhante à da virtualização de SO
- O grupo de trabalho Confidential Containers está desenvolvendo apps executados dentro de TEE e gerenciados com Docker
- O Docker CLI faz encaminhamento de mensagens criptografadas do TEE local no desktop, passando pelo host, até ambientes remotos de TEE na nuvem
- Isso permite que desenvolvedores se autentiquem em ambientes sensíveis na nuvem sem ir fisicamente ao local, com as credenciais armazenadas com segurança no enclave do desktop
Suporte a GPGPU para cargas de trabalho de IA
- A ascensão das cargas de trabalho de IA trouxe um desafio totalmente novo: a maioria das cargas de trabalho de machine learning roda em GPU
- Problema central: cargas de trabalho em GPU exigem drivers de GPU do kernel e bibliotecas em espaço de usuário exatamente compatíveis, enquanto vários contêineres rodam sobre um único kernel compartilhado
- Se dois apps exigirem versões diferentes do mesmo driver de GPU no kernel, surge o mesmo conflito fundamental que o Docker originalmente tentou resolver
- Desde março de 2023, o Docker oferece suporte a CDI (Container Device Interface)
- Ele personaliza a imagem do sistema de arquivos no momento da inicialização do contêiner
- Faz bind mount dos arquivos de dispositivo da GPU e das bibliotecas dinâmicas específicas da GPU, além de recriar o cache do
ld.so
- O CDI garante portabilidade de imagens entre determinadas classes e fornecedores de GPU, mas ainda não é totalmente transparente entre diferentes SOs e marcas de hardware
- As bibliotecas dinâmicas adicionadas pelo CDI definem APIs diferentes, portanto não há nada comparável à tradicional interface estável dos contêineres, a ABI de system calls do Linux
- Motivo pelo qual apps para GPUs Nvidia têm dificuldade para rodar em CPUs Apple série M: o suporte de virtualização de GPU ainda não amadureceu a ponto de traduzir instruções vetoriais entre hardwares distintos
- Em colaboração com a comunidade de contêineres e fabricantes de GPU, estão sendo desenvolvidas formas mais flexíveis e seguras de gerenciar dependências relacionadas a GPU
- A expectativa é que a iniciativa de interfaces portáveis chegue a um consenso
Conclusão
- O Docker começou em 2013 com o objetivo de ajudar desenvolvedores a criar, compartilhar e executar apps com mais facilidade
- Hoje está profundamente integrado aos fluxos de trabalho padrão de desenvolvimento em nuvem e desktop, sendo usado diariamente por milhões de desenvolvedores no mundo todo e processando dezenas de bilhões de requisições por mês
- Um objetivo consistente tem sido manter uma comunidade open source ativa e diversa que constrói padrões para interoperabilidade
- A CNCF (Cloud Native Computing Foundation) atua como mantenedora de vários componentes centrais
- A Open Container Initiative (da Linux Foundation) é a mantenedora do formato de imagem
- Hoje existem implementações ativas de muitos desses elementos, com crescimento de implantações em ambientes de borda como nuvem, desktop, automóveis, dispositivos móveis e espaçonaves
- Em 2025, o fluxo de trabalho típico de desenvolvedores integra testes e implantação contínuos, language servers em IDEs e suporte de IA por meio de agentic coding
- Na visão do Docker, o fluxo central de “build and run” continua muito parecido com o de 10 anos atrás, mas o suporte do sistema para reduzir atritos em ambientes diversos foi amplamente reforçado
- O objetivo é tornar o Docker um companheiro invisível que ajuda desenvolvedores a implantar código mais rápido, com design escalável para se adaptar aos fluxos modernos de programação com IA
1 comentários
Comentários do Hacker News
Quando o Docker apareceu pela primeira vez, eu já estava cansado de ouvir falar de mais uma "revolução"
Eu detestava NoSQL meio pronto, microsserviços impostos a qualquer custo e a moda de transformar toda chamada de função em RPC
Mas hoje uso com frequência justamente por causa da simplicidade
Ainda assim, os contêineres de outras pessoas continuam sendo um inferno. Eu pelo menos tento manter tudo simples, mas tem gente que enfia coisa demais ali dentro e dá a sensação de que nem ela mesma entende o processo de deploy
Agora parece que vivemos uma era em que, graças aos LLMs, está chovendo código que o próprio desenvolvedor nunca chegou a olhar
Houve inúmeras tentativas, mas no fim o Dockerfile sobreviveu por causa da flexibilidade
A estrutura de copiar arquivos e executar comandos era familiar, como nos modos tradicionais de operação
Parece algo tosco à primeira vista, mas essa flexibilidade simples deve continuar dominante por muito tempo
Se todo mundo usasse Nix ou Bazel, talvez
docker buildtivesse virado motivo de piadaSe hashes diferem entre builds, não dá para confiar; então, enquanto elementos como horário de modificação de arquivo entrarem no hash, consistência total continuará difícil
Pessoalmente gosto do mkosi, mas nem todo mundo quer começar a partir de um template de SO vazio
Na maioria dos casos, você faz pull de um registry público e push para um privado, então imagens locais quase não são usadas
É um pouco ineficiente, mas aparentemente não o bastante para motivar uma mudança
Lembro do primeiro anúncio público do Docker na PyCon US Santa Clara em 2013
Se você assistir ao vídeo da apresentação no YouTube, é um momento histórico
Parece que houve alguma confusão entre a data de publicação do artigo e a data real da apresentação, mas estamos falando de algo de cerca de 13 anos atrás
“A decade of Docker” soava mais natural do que “Twelve years of Docker containers”
Eu me lembro do post original no HN
Na época eu já estava cansado de alternativas como LXC ou Vagrant, e o Docker realmente parecia um salvador
Acho interessante que o Docker tenha reutilizado o SLIRP, uma ferramenta de acesso discado dos anos 1990, para atravessar firewalls
Ele não aceitava conexões de entrada, mas já era uma espécie de precursor do NAT
Eu queria usar Docker, mas sempre que tentava faltava alguma funcionalidade de que eu precisava
Provavelmente porque eu usava uma stack técnica pouco comum
A grandeza do Docker foi transformar o “na minha máquina funciona” em padrão da indústria
Agora vivemos a era de "entregar" a própria máquina em produção
Antes, deploy era um procedimento enorme; agora você pode implantar o sistema de arquivos diretamente
A atual revolução dos agentes de programação me parece uma virada cultural parecida
Se dá para reproduzir o ambiente com um script de 10 linhas, então “implantar a máquina” também não parece tão ruim
Vale a pena se perguntar por que essa abordagem é tão atraente
Abstrações sempre vencem porque corrigir o problema na raiz é difícil demais
Não entendo muito de rede, mas queria que contêineres no Mac tivessem um endereço IP separado
Queria acessar com
container_ip:80sem fazer mapeamento de portaNo Linux isso era possível, mas no Mac fica complicado porque precisa passar por uma VM
Já tentei o método baseado em WireGuard, mas quebra a cada atualização do Docker
Seria bom ter uma forma oficialmente suportada
A Tailscale Docker Extension cuida da configuração automaticamente
Se o motivo para evitar mapeamento de portas for o uso de portas dinâmicas, eu recomendaria testar a opção
--net=hoste ativar a configuração de Host Networking2013 foi um ano de colheita farta em empacotamento, com Docker, Guix e NixOS surgindo todos naquele período
Descobri isso ao escrever um artigo relacionado
Fiquei curioso se já houve outro ano em que tantos projetos excelentes surgiram ao mesmo tempo
Guix e Nix continuam restritos a um grupo pequeno de usuários
Com ML e IA em toda parte, o tamanho das imagens está ficando exponencialmente maior
Só o torch já ocupa vários GB
Sinto falta das antigas imagens de 30 MB
Como não há compartilhamento de arquivos entre camadas, o desperdício é enorme
Por isso estou criando meu próprio registry alternativo com suporte a deduplicação em nível de arquivo
Achei muito interessante o fato de o Docker ter se disfarçado de VPN para enganar softwares corporativos de segurança
Como história técnica, também é um caso muito curioso