Gerador de Dockerfile

Dockerfile
Resultados

Um Dockerfile é um daqueles ficheiros que parecem curtos até nos lembrarmos dos detalhes: a ordem das camadas importa para a cache, COPY package.json vem antes de RUN npm install, e as linguagens compiladas beneficiam de um build multi-stage. Este gerador escreve um Dockerfile pronto a usar para a tecnologia que escolher, com o padrão de cache já correto.

Como gerar um Dockerfile

  1. 1

    Escolha a tecnologia

    Node.js, Python, PHP, Go ou Rust. Cada modelo usa uma imagem base adequada à linguagem e o comando correto para instalar dependências.

  2. 2

    Defina o diretório de trabalho e a porta

    Escolha o WORKDIR e a porta em que a sua aplicação escuta; ambos ficam registados no ficheiro gerado.

  3. 3

    Revise o Dockerfile

    Confirme que a linha EXPOSE e o comando de arranque correspondem à sua aplicação. Os modelos Go e Rust usam um build multi-stage.

  4. 4

    Copie o Dockerfile

    Copie o resultado e cole-o na raiz do seu repositório, depois construa a imagem.

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:

Variante Tamanho típico Quando escolher
full 300-900 MB Imagens de desenvolvimento, dependências de sistema invulgares
slim 80-200 MB Padrão de produção para a maioria das linguagens
alpine 30-100 MB Imagens pequenas, cuidado com problemas glibc vs musl
distroless 20-80 MB Segurança máxima; sem shell, sem gestor de pacotes

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/*.

Perguntas frequentes

Slim é um padrão mais seguro porque continua a ser baseado em glibc, como a maioria das wheels pré-compiladas das bibliotecas. Alpine usa musl e causa ocasionalmente erros de execução misteriosos em Python (pandas, numpy) ou Node (módulos nativos node-gyp). Escolha alpine quando o tamanho da imagem for crítico e já tiver testado a stack.

Sim, adicione um ao seu projeto. Sem ele, o Docker envia todo o seu repositório ao daemon como contexto de build: histórico git, node_modules, ficheiros .env locais, testes. É lento, desperdiça cache e expõe segredos.

Sim. Use docker buildx com a opção --platform para compilar para ambas as arquiteturas ao mesmo tempo. As imagens base usadas pelos modelos publicam variantes arm64.

Não. A tecnologia, o diretório de trabalho e a porta escolhidos servem apenas para gerar o Dockerfile nesta página; nada é guardado ou partilhado.

Ferramentas relacionadas

Ferramenta disponível em outros idiomas