Docker é estranho: o que há por trás de um container runtime

O texto parte de um experimento: o autor está escrevendo o próprio container runtime e conta o que descobriu sobre o Docker. A tese central é que container não é um recurso único do Linux. Segundo ele, são 5 recursos do kernel combinados. Namespaces escondem o que host e container enxergam, cgroups limitam o uso de recursos, e há uma camada de rede para isolar o container. O processo continua rodando no kernel do host e dá para encontrá-lo em /proc, o que difere de uma VM.

As imagens, na descrição dele, são pastas que o Docker usa como novo diretório raiz do processo, via chroot (ou pivot_root). O ponto mais técnico é o runc, escrito em Go. O runtime multithread do Go complica syscalls que precisam de ambiente single-thread, então o runc tem um módulo em C que roda antes da inicialização do runtime do Go. Go também não tem fork, e o runc contorna isso executando /proc/self/exe com um argumento especial que marca o processo como filho. Por fim, muitas APIs do kernel exigiam root, por isso o daemon costuma rodar como root. Em runtimes rootless, a rede parece exigir reimplementar a pilha em userspace.

A cobertura anterior toca o mesmo tema, mas sem um fato novo que evolua. Em 9 de março de 2026, o CEVIU noticiou "Uma Década de Contêineres Docker", citando namespaces Linux e imagens em camadas como base do Docker. Em 8 de maio de 2026, em "O Que É um Container Padrão: Aprofundando na Especificação de Runtime da OCI", o foco foi a padronização do runtime. O texto de agora desce um nível e mostra como esses conceitos aparecem na prática ao implementar um runtime.

Para quem usa Docker no dia a dia, a leitura é que entender o que está embaixo ajuda a depurar. Saber que container é processo com restrições explica por que ele aparece no host e por que segurança depende do daemon e de privilégios. Para quem pensa em rootless, vale esperar trabalho extra na rede.