O que é um container, de verdade

Um container não é uma máquina virtual pequena: é um processo do host executando com visões isoladas de processos, rede, usuários e sistema de arquivos. Ele compartilha o kernel do host; por isso a imagem não contém um sistema operacional completo nem torna a aplicação automaticamente segura.

O isolamento e o limite são mecanismos diferentes

Namespaces dão a ilusão de estar sozinho: PID mostra outra árvore de processos, network tem interfaces e rotas próprias, mount vê outro conjunto de montagens e user pode mapear IDs. Cgroups controlam consumo de CPU, memória, processos e I/O. Um namespace impede que um processo veja outro; um cgroup impede que ele consuma recursos sem limite.

docker run --rm --name limite --memory=256m --cpus=0.5 nginx:stable
docker inspect limite --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
docker stats limite --no-stream

Sem limite de memória, um processo com vazamento pode pressionar todo o nó. Com limite, ele pode ser terminado pelo kernel (OOMKilled), o que é preferível a derrubar vizinhos, mas ainda exige corrigir a causa e configurar a recuperação no orquestrador.

Imagem, camada e runtime

Uma imagem OCI é um manifesto que referencia camadas imutáveis de filesystem e uma configuração de execução. Ao iniciar, o runtime monta essas camadas como base somente leitura e adiciona uma camada gravável efêmera. Nada que a aplicação escreva ali deve ser considerado persistente; use volume, banco ou object storage para estado.

docker image inspect nginx:stable --format '{{json .RootFS.Layers}}'
docker run --rm nginx:stable cat /etc/os-release

OCI separa formato de imagem, runtime e distribuição. Assim Docker, containerd, CRI-O e Kubernetes podem executar a mesma imagem; comandos específicos do Docker não são parte do contrato de produção.

O que containers não resolvem

Eles não substituem patching da imagem, IAM, backup, TLS, observabilidade ou limites de aplicação. Rodar como root dentro do container continua perigoso, especialmente quando há volume sensível, socket do Docker ou capabilities extras. Evite --privileged, montagem de /var/run/docker.sock e capabilities além da necessidade; esses atalhos removem boa parte do isolamento.

Próximo passo: construa uma imagem pequena, reprodutível e não-root em Dockerfile em produção. Depois publique por digest, não apenas por tag.