~/questoes/devops

O que acontece na segunda etapa de um Dockerfile multi-stage?

Responda, confira o feedback e use o resultado para orientar sua revisão.

Questão 1 Não respondida

O que acontece na segunda etapa de um Dockerfile multi-stage?

Infraestrutura e DevOps Multi-stage build Intermediario

Para fixar

A Segunda Etapa do Dockerfile Multi-stage: Production Stage

Conceito central

Um Dockerfile multi-stage divide o processo de construção em duas etapas: a primeira compila a aplicação (build stage) e a segunda apenas copia os arquivos prontos para um servidor mais leve (production stage). Isso reduz drasticamente o tamanho final da imagem Docker.

Por que essa resposta faz sentido

Na segunda etapa, apenas os arquivos estáticos compilados (HTML, CSS e JavaScript) são copiados para o diretório do NGINX. Como a imagem do NGINX é muito mais enxuta que a do Node.js completo, a imagem final fica muito menor e mais eficiente.

Armadilhas comuns

Achar que você precisa instalar Node.js novamente na segunda etapa para garantir compatibilidade. Na verdade, Node.js já foi usado na primeira etapa; na segunda, só precisa do NGINX.
Confundir o objetivo do multi-stage: ele não é apenas limpar dependências, mas sim criar uma imagem final bem menor usando apenas uma imagem base leve (NGINX) em vez de uma completa (Node.js).
Pensar que o multi-stage faz upload automático para Docker Hub. O push é um passo manual adicional que você escolhe fazer depois que a imagem está pronta localmente.

Entenda as alternativas

Na production stage, você copia apenas os arquivos estáticos gerados na primeira etapa para o diretório de servição do NGINX (geralmente /usr/share/nginx/html). Isso mantém a imagem final enxuta, pois não inclui o Node.js nem as dependências de desenvolvimento.

O Node.js não é instalado novamente na segunda etapa. Na verdade, essa é uma das principais vantagens do multi-stage: você evita ter Node.js na imagem final. A segunda etapa usa apenas a imagem do NGINX, que já vem com o que é necessário para servir os arquivos estáticos.

O Docker não faz push automático para Docker Hub durante a construção da imagem. O push é um comando manual que você executa depois, se decidir compartilhar a imagem. Além disso, isso não acontece especificamente na segunda etapa.

As dependências de desenvolvimento não são limpas na segunda etapa porque elas nunca foram copiadas para lá. A segunda etapa começa com uma imagem nova do NGINX, sem nenhuma dependência Node.js. A limpeza acontece implicitamente por não incluir essas dependências.