How Docker Works Under the Hood

Watch what really happens when you run docker run -p 8080:80 nginx, one layer at a time. Step down the whole stack: the CLI, the daemon, the registry pull, containerd, the OCI runtime bundle, runc, the running container, and the shared Linux kernel. Every stage shows the real low-level command you can run yourself, so it doubles as a tour of the primitives that make a container: namespaces, cgroups, and runc. A container is not a small VM, and this shows you why.

O que você vai aprender

O que realmente acontece quando você roda docker run -p 8080:80 nginx, camada por camada
Por que o CLI do docker é só um cliente REST que conversa com o daemon por um socket
Como o dockerd delega ao containerd, e o que o containerd faz com as camadas da imagem
O que é um bundle de runtime OCI: um config.json mais um rootfs
Como o runc transforma esse bundle num processo em execução usando namespaces e cgroups
Por que um container é um processo normal do host, não uma pequena máquina virtual

Este simulador interativo requer JavaScript para funcionar. Por favor, habilite o JavaScript no seu navegador para usar esta ferramenta.

// simulador

How Docker Works Under the Hood

Internamente no container · o caminho real de um docker run

O que acontece quando você roda um container

$docker run -p 8080:80 nginx

nginx já foi baixado

REST sobre um socket UnixPasso 1 / 8

Você roda um comando

O CLI do docker é só um pequeno cliente REST. Ele transforma seu comando numa requisição HTTP e a envia ao daemon do Docker por um socket local. O CLI nunca cria um container sozinho.

$ curl --unix-socket /var/run/docker.sock http://localhost/v1.45/info

O CLI conversa com o dockerd exatamente assim por baixo dos panos.

O ponto central: um container não é uma pequena VM. É um processo do host que o kernel mantém em seus próprios namespaces e cgroups. Cada passo acima é algo que você pode rodar você mesmo numa máquina Linux real.

Sobre este simulador de "como o Docker funciona"

O que você vai aprender

O caminho completo do seu terminal até o kernel Linux
As funções reais do CLI, dockerd, containerd e runc, e por que existem quatro deles
O que é baixado de um registry, e que só camadas faltando são baixadas
Como o bundle OCI (config.json + rootfs) descreve o container antes dele existir
Quais features do kernel fazem o isolamento real: namespaces, cgroups, rede, mounts
O comando real em cada passo, para você reproduzir tudo você mesmo

A pilha, de cima a baixo

docker CLI: transforma seu comando numa chamada de API sobre /var/run/docker.sock
dockerd: o motor; checa a imagem, prepara a config, baixa se necessário
containerd: desempacota camadas, rastreia estado, prepara o bundle de runtime
runc: cria os namespaces e o cgroup, depois faz exec do seu processo
o kernel: o kernel compartilhado do host é a fronteira real

Um container não é uma pequena VM

A ideia mais importante do simulador é o último passo. Uma VM inicializa um sistema operacional convidado inteiro sobre hardware virtual. Um container não: o nginx é um processo normal no seu host, e a única coisa separando ele de tudo mais é um conjunto de features do kernel. Namespaces controlam o que ele pode ver, cgroups controlam o que ele pode usar, e os dois são só o kernel do host fazendo contabilidade. É por isso que um container inicia em milissegundos enquanto uma VM leva segundos.

Experimente num host real

Todo comando no simulador é real. A forma limpa de mexer com namespaces e cgroups sem tocar no seu laptop é uma máquina Linux descartável: suba um droplet da DigitalOcean, rode o container nginx, depois use lsns, runc list, e cat /sys/fs/cgroup para observar as mesmas peças que o simulador mostra. Delete o droplet quando terminar.

Vá mais fundo

O post relacionado, How Docker Really Works, From docker run to the Kernel, percorre o mesmo caminho em profundidade com os comandos para rodar num host real, e explica por que a divisão entre dockerd, containerd e runc existe.