Gerador de Dockerfile

Porquê builds multi-stage

Um Dockerfile ingénuo instala toda a cadeia de ferramentas do compilador na imagem final. Os builds multi-stage dão-lhe um estágio “builder” que compila e um estágio final que só transporta o artefacto compilado:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

A imagem final elimina todas as dependências de desenvolvimento, os ficheiros de código e a cache de build, reduzindo muitas vezes o tamanho da imagem em 60-80 por cento.

Variantes da imagem base

Os modelos usam imagens slim ou alpine sempre que possível. Se ajustar a imagem base por conta própria, estas são as opções típicas:

Regras da cache de camadas

O Docker coloca em cache cada linha; quando uma camada muda, tudo o que está abaixo é reconstruído. Ordem do menos ao mais volátil:

1. Imagem base FROM (muda raramente).
2. Pacotes do sistema (apt-get install), alterações raras.
3. Manifestos de dependências (package.json, requirements.txt, composer.json).
4. Passo de instalação das dependências. Só é executado quando o manifesto muda.
5. Cópia do código-fonte. A camada mais ativa; tudo o que vem a seguir é reconstruído em cada commit.
6. Compilação e CMD final.

Quebrar esta ordem é a causa mais comum de builds de CI lentos.

Lista de verificação de segurança

• Executar como não root. Coloque USER appuser (ou USER 1000) perto do fim.
• Fixar versões. python:3.12.7-slim vence python:3.12, que vence python:latest.
• Defina um WORKDIR explícito em vez de depender de /.
• Use COPY e não ADD para ficheiros locais; ADD tem efeitos secundários de extração automática.
• Adicione um HEALTHCHECK para que os orquestradores detetem um processo preso.
• Limpe as caches de pacotes na mesma linha RUN: apt-get install ... && rm -rf /var/lib/apt/lists/*.