Containers e Docker

O problema: funciona na minha máquina

A aplicação roda no computador do desenvolvedor com Node 24, uma biblioteca de imagens instalada no sistema e uma variável de ambiente que ninguém lembra de ter configurado. No servidor, o Node é outra versão, a biblioteca falta e a variável não existe. O deploy falha, ou pior, funciona com um comportamento diferente.

Antes dos containers, as soluções eram documentar a instalação passo a passo, manter servidores configurados à mão ou criar uma máquina virtual inteira para cada aplicação. As três são lentas, frágeis ou caras.

Um container resolve empacotando a aplicação junto com o ambiente de que ela precisa: o sistema de arquivos com as bibliotecas, o interpretador, as dependências e a configuração de execução. O pacote roda igual em qualquer máquina que tenha um mecanismo de containers.

Container não é máquina virtual

Um container é, por dentro, um processo comum da máquina hospedeira, com recursos do núcleo do Linux que o fazem enxergar só o próprio mundo:

• namespaces dão ao processo a sua própria visão de processos, rede, sistema de arquivos e usuários;
• cgroups limitam quanta CPU e memória ele pode usar.

Por isso um container inicia tão rápido: não há sistema operacional para ligar, só um processo para iniciar. E por isso o isolamento é menor que o de uma máquina virtual: uma falha no núcleo afeta todos os containers da máquina.

Imagem e container

Dois termos que se confundem:

• Imagem: o pacote congelado, que não muda. Contém o sistema de arquivos e a instrução de qual processo iniciar. É o que se constrói, versiona e publica.
• Container: uma imagem em execução. Da mesma imagem saem quantos containers forem necessários, todos iguais.

A analogia mais próxima é a de uma classe e seus objetos, ou de um instalador e o programa instalado.

docker build -t loja/api:1.4.2 .     # constrói a imagem a partir do Dockerfile
docker run -p 3000:3000 loja/api:1.4.2   # inicia um container a partir dela

O Dockerfile e as camadas

A imagem é descrita num Dockerfile, uma receita com uma instrução por linha:

# Parte de uma imagem com Node já instalado
FROM node:24-alpine
WORKDIR /app

# Instala as dependências
COPY package.json package-lock.json ./
RUN npm ci --omit=dev

# Copia o código
COPY . .

# O processo que o container inicia
CMD ["node", "server.js"]

Cada instrução gera uma camada, e a imagem é a pilha dessas camadas. As camadas são guardadas em cache: se uma instrução e tudo o que vem antes dela não mudaram, a reconstrução reaproveita a camada pronta.

Essa regra tem uma consequência prática enorme. O exemplo acima copia primeiro só os arquivos de dependências e instala, e só depois copia o código. Uma mudança no código invalida apenas as últimas camadas, e as dependências vêm do cache.

Medimos a diferença com uma aplicação Node pequena. Depois de mudar uma linha de código, a reconstrução levou 5,4 segundos com um Dockerfile que copia tudo antes de instalar, e 0,4 segundo com as dependências numa camada separada. Em projetos reais, com centenas de dependências, a diferença passa de minutos.

Por que o tamanho e o usuário importam

No mesmo teste, a imagem montada do jeito mais simples (imagem base completa, dependências de desenvolvimento incluídas) ficou com 1,73 GB. A versão com uma imagem base enxuta e só as dependências de produção ficou com 236 MB. Uma aplicação Go compilada como binário estático, sobre uma imagem mínima, ficou com 14 MB.

E, por padrão, o processo dentro do container roda como root. Se alguém explorar uma falha da aplicação, ganha o máximo de poder dentro do container, e fica mais perto de escapar para a máquina hospedeira. A versão simples do teste rodava como root; a cuidadosa, como um usuário sem privilégios.

Por que isso importa quando a IA escreve o código

Pedir "crie um Dockerfile para este projeto" gera um arquivo que funciona. Ele quase sempre tem estes problemas:

• COPY . . antes da instalação das dependências, refazendo tudo a cada mudança de código.
• A imagem base completa, com compiladores e ferramentas que a produção não usa.
• Dependências de desenvolvimento e arquivos de teste dentro da imagem final.
• Nenhum .dockerignore, levando node_modules, .git e até arquivos .env com segredos para dentro da imagem.
• O processo rodando como root.
• CMD npm start na forma de texto, que impede o processo de receber o sinal de encerramento.

O próximo nível compara as escolhas de imagem base, de construção e de execução.