Neste artigo
Porquê Utilizar um Gerador de Dockerfile
Escrever um Dockerfile de raiz requer conhecer a imagem base correta, a ordem certa das instruções e dezenas de boas práticas para cache de camadas, segurança e tamanho da imagem. Uma única instrução COPY mal posicionada pode invalidar todo o cache de build, e a falta de um build multi-stage pode inflacionar a imagem de produção para gigabytes. Para equipas que enviam contentores diariamente, estes detalhes são extremamente importantes.
Um gerador de Dockerfile cria um Dockerfile pronto para produção com base no tipo de projeto, runtime da linguagem e requisitos de implantação. Em vez de copiar fragmentos da documentação e do Stack Overflow, obtém um Dockerfile completo e otimizado que segue as boas práticas atuais — builds multi-stage, utilizadores não-root, ordenação adequada de camadas e imagens finais mínimas. É especialmente valioso para programadores novos na containerização ou equipas que estão a padronizar o seu processo de build.
Como Utilizar o Gerador de Dockerfile
O Gerador de Dockerfile do CheckTown cria Dockerfiles otimizados adaptados ao stack e requisitos do seu projeto.
- Selecione a sua imagem base e runtime — escolha entre Node.js, Python, Go, Rust, Java, Ruby, PHP e mais, com seleção de versão
- Configure as definições de build — especifique o diretório de trabalho, portas expostas, comandos de build e ponto de entrada da sua aplicação
- Ative builds multi-stage para separar o ambiente de build da imagem de produção, reduzindo drasticamente o tamanho da imagem final
- Copie o Dockerfile gerado para a raiz do seu projeto e faça build com docker build -t myapp . para criar a sua imagem de contentor
Experimente gratuitamente — sem cadastro
Gerar um Dockerfile →Boas Práticas para Dockerfile
Seguir as boas práticas de Dockerfile reduz o tempo de build, o tamanho da imagem e a superfície de ataque de segurança. Estas dicas aplicam-se à maioria das aplicações em contentores.
- Ordene as instruções da menos para a mais frequentemente alterada — coloque a instalação de dependências antes da cópia do código-fonte para que o Docker possa fazer cache da camada de dependências
- Utilize builds multi-stage para manter as ferramentas de build fora da sua imagem final — o seu contentor de produção só precisa do binário compilado ou dos assets empacotados, não do compilador
- Execute a sua aplicação como utilizador não-root — adicione uma instrução USER para evitar executar processos como root dentro do contentor, o que limita os danos de potenciais explorações
Perguntas Frequentes
O que é um Dockerfile multi-stage?
Um Dockerfile multi-stage utiliza múltiplas instruções FROM para criar fases de build separadas. A primeira fase instala as dependências e compila a sua aplicação, e a fase final copia apenas os artefactos construídos para uma imagem base mínima. Isto significa que a sua imagem de produção não contém compiladores, ferramentas de build ou código-fonte — apenas o necessário para executar a aplicação.
Que imagem base devo escolher?
Escolha a imagem mais pequena que suporte o seu runtime. As imagens baseadas em Alpine são as mais pequenas (cerca de 5 MB), mas utilizam musl libc, o que pode causar problemas de compatibilidade com alguns módulos nativos. As variantes slim de imagens baseadas em Debian são um bom meio-termo — são mais pequenas que as imagens completas mas utilizam glibc para maior compatibilidade. Para Go ou Rust, pode até utilizar imagens scratch ou distroless, uma vez que o binário compilado não tem dependências de runtime.
Como manter as minhas imagens Docker pequenas?
Comece com uma imagem base mínima, utilize builds multi-stage, combine instruções RUN para reduzir camadas, adicione um ficheiro .dockerignore para excluir ficheiros desnecessários do contexto de build e remova caches do gestor de pacotes na mesma camada onde instala os pacotes. Estes passos podem facilmente reduzir o tamanho das imagens em 80 por cento ou mais em comparação com Dockerfiles ingénuos.