Containers e Docker

As decisões de uma imagem são cinco: qual imagem base usar, como construir sem levar ferramentas para produção, como aproveitar o cache, como rodar com segurança e como versionar.

A imagem base

Para a maioria das aplicações, slim é o ponto de partida mais seguro. Alpine quando o tamanho importa e as dependências funcionam com musl. Distroless quando a segurança pesa mais que a conveniência de depurar.

Em Go, Rust e outras linguagens que geram binários estáticos, a imagem final pode ser distroless ou scratch. No teste, uma API Go ficou com 14 MB numa base distroless, sem shell dentro: uma tentativa de executar sh no container falhou porque ele não existe.

Construção em estágios

A imagem final não precisa das ferramentas que construíram a aplicação. A construção em estágios (multi-stage build) usa uma imagem para compilar e outra, enxuta, para rodar:

# Estágio 1: tem compilador e ferramentas
FROM golang:1.24-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /api .

# Estágio 2: só o binário
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /api /api
ENTRYPOINT ["/api"]

Só o último estágio vira a imagem publicada. O compilador, o código-fonte e os arquivos intermediários ficam para trás.

Aproveitar o cache

O .dockerignore merece atenção especial. Sem ele, COPY . . leva para dentro da imagem a pasta .git, o node_modules local, arquivos de teste e, no pior caso, um .env com senhas.

.git
node_modules
.env*
coverage
tests
*.log
Dockerfile*

Executar com segurança

O processo principal e o sinal de encerramento

O primeiro processo do container (PID 1) é quem recebe o SIGTERM quando o container é parado. Se esse processo for um shell, o sinal fica nele e não chega à aplicação.

No teste, com CMD npm start na forma de texto, o PID 1 era /bin/sh -c npm start. O docker stop esperou os 10 segundos do limite padrão e matou o container à força, sem que a aplicação recebesse o sinal. Com CMD ["node", "server.js"], o PID 1 era o próprio Node, que recebeu o sinal, encerrou e o docker stop levou 0,1 segundo.

Se um script de entrada for necessário, ele deve terminar com exec node server.js, que troca o shell pela aplicação. Aplicações que criam processos filhos se beneficiam de um init mínimo como tini ou da opção --init do Docker.

Versionar as imagens

Fixar a base e reconstruir periodicamente parecem contraditórios. Não são: fixar garante que cada construção seja reproduzível, e a atualização da base vira uma mudança explícita, revisada e testada.

Resumo da decisão

1. Base: slim por padrão; alpine ou distroless quando tamanho e segurança pesam mais.
2. Construção em estágios: ferramentas no estágio de construção, só o necessário na imagem final.
3. Cache: dependências antes do código, arquivo de trava, .dockerignore.
4. Execução: usuário sem privilégios, CMD em forma de lista, sem segredos, com limites.
5. Versões: etiquetas imutáveis por versão ou commit, base fixada e atualizada de propósito.

O próximo nível mostra Dockerfiles completos para Node e Go, a aplicação preparada para container nas cinco linguagens e um ambiente local com Docker Compose.