Combinar vários comandos em uma única instrução RUN para reduzir o tamanho da imagem

Neste exemplo, deve-se instalar o software na imagem do contêiner, por exemplo, Node.js. Use as imagens de base para Node.js para construir um aplicativo Node.js.

Para instalar manualmente o Node.js, é possível usar o exemplo de Dockerfile a seguir,

FROM ubuntu

RUN apt update
RUN apt upgrade -y
RUN apt install -y nodejs
RUN apt clean
RUN rm -rf /var/lib/apt/lists/\*

Neste exemplo, várias instruções RUN são usadas para atualizar, fazer upgrade, instalar o Node.js, limpar e remover o cache de arquivos. Embora essa sequência de instruções esteja correta, o uso de múltiplas instruções RUN não é a melhor maneira de implementá-lo. Quando um Dockerfile é processado, cada uma de suas instruções cria uma camada. Cada camada contém os arquivos que foram criados ou atualizados e também informações sobre o que foi excluído. Uma imagem de contêiner é a coleção de todas as camadas. Se um arquivo for incluído em uma instrução e excluído em uma segunda, a imagem resultante ainda o conterá na camada da primeira instrução, mas o marcará como excluído na segunda camada.

Para salvar o espaço em disco, especifique uma única instrução RUN para criar uma camada única para esse conjunto de comandos,

FROM ubuntu

RUN apt update && apt upgrade -y && apt install -y nodejs && apt clean && rm -rf /var/lib/apt/lists/\*

Para manter um Dockerfile legível com uma linha por comando, inclua quebras de linha em seu código,

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y nodejs && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

Ao usar esse tipo de instrução, é possível reduzir o tamanho da imagem do contêiner de cerca de 174 MB para aproximadamente 147 MB. Observe que os seus tamanhos de exemplo podem diferir, assim como a imagem base do Ubuntu e o pacote Node.js podem mudar.

Esse tipo de melhor prática se aplica não apenas a instalações de pacotes, mas também a tarefas semelhantes. No próximo exemplo, o download e a extração de um pacote de software, novamente Node.js, podem ser semelhantes ao exemplo a seguir,

FROM ubuntu

RUN apt update
RUN apt upgrade -y
RUN apt install -y curl
RUN curl https://nodejs.org/dist/v16.14.2/node-v16.14.2-linux-x64.tar.gz -o /tmp/nodejs.tar.gz
RUN mkdir /opt/node
RUN tar -xzf /tmp/nodejs.tar.gz -C /opt/node --strip 1
RUN rm /tmp/nodejs.tar.gz
RUN apt remove -y curl
RUN apt clean
RUN rm -rf /var/lib/apt/lists/\*

O comando rm remove o pacote nodejs transferido por download, mas as múltiplas instruções RUN novamente criam camadas separadas. Além disso, para fazer o download do pacote nodejs, o pacote curl é instalado temporariamente. Enquanto o pacote curl em si é removido posteriormente, suas dependências que estavam implicitamente instaladas ainda estão lá. Um Dockerfile melhor se parece com o exemplo a seguir,

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y curl && \
    curl https://nodejs.org/dist/v16.14.2/node-v16.14.2-linux-x64.tar.gz -o /tmp/nodejs.tar.gz && \
    mkdir /opt/node && \
    tar -xzf /tmp/nodejs.tar.gz -C /opt/node --strip 1 && \
    rm /tmp/nodejs.tar.gz && \
    apt remove -y curl && \
    apt auto-remove -y && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

Os comandos relacionados são combinados em uma única instrução RUN e o comando apt auto-remove é incluído para remover as dependências. Este exemplo reduz o tamanho da imagem de cerca de 222 MB para aproximadamente 162 MB.

Usar uma imagem base minúscula

Os exemplos anteriores usam o Ubuntu como uma imagem base. Enquanto essa imagem contém muitos utilitários úteis, quanto mais utilitários estão em uma imagem base, maior é o seu tamanho. Além disso, ao incluir mais utilitários, você aumenta a chance de poder encontrar uma vulnerabilidade de segurança, exigindo que você reconstrua sua imagem. Para evitar esses dois problemas, considere usar uma imagem base menor. Por exemplo,

• Alpine é uma imagem oficial do Docker com tamanho pequeno. Para ambientes de programação, como Java ou Node.js, tags baseadas em Alpine são frequentemente localizadas.

• Imagens distroless do Google Container Tools não contêm ferramentas de sistema operacional de forma alguma, mas o ambiente de tempo de execução necessário para diferentes idiomas, como Java e Node.js.

Compare essas imagens base construindo uma imagem de contêiner que execute um programa Node.js em um arquivo program.js. Para o Ubuntu, o Dockerfile é semelhante ao exemplo a seguir,

FROM ubuntu

RUN \
    apt update && \
    apt upgrade -y && \
    apt install -y nodejs && \
    apt clean && \
    rm -rf /var/lib/apt/lists/\*

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

Para Alpine, a imagem é obtida diretamente do Node.js,

FROM node:16-alpine

COPY program.js /app/program.js

WORKDIR /app

ENTRYPOINT ["node", "program.js"]

Para distroless, use o exemplo a seguir,

FROM gcr.io/distroless/nodejs:16

COPY program.js /app/program.js

WORKDIR /app

CMD ["program.js"]

Enquanto a imagem baseada em Ubuntu é de 147 MB, a imagem que é baseada no Alpine é de 90 MB, e a imagem baseada em distroless é de 94 MB.

Não inclua origens e ferramentas de construção para reduzir o tamanho da imagem

Nos exemplos baseados no Node.js anteriores, um único arquivo de origem é incluído na imagem do contêiner. Esse exemplo pode usar um único arquivo de origem porque nenhuma compilação foi necessária. No entanto, se uma compilação for necessária, use as ferramentas necessárias apenas para a construção, mas não as inclua na imagem resultante. Por exemplo, especifique um aplicativo Java que use o Maven como exemplo. Um Dockerfile mal codificado é semelhante ao exemplo a seguir,

FROM maven:3-jdk-11-openj9

WORKDIR /app
COPY . /app

RUN mvn package

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/target/java-application-1.0-SNAPSHOT-fat.jar"]

A imagem de contêiner resultante contém todo o código-fonte e todos os arquivos intermediários do Maven (como o seu cache de artefato, arquivos de classe que são posteriormente empacotados em um arquivo JAR), assim como a ferramenta de construção Maven. Além disso, o Java Development Kit (JDK) também será incluído quando um Java Runtime Environment (JRE) muito menor for requerido no tempo de execução. Como resultado, o tamanho da imagem é 466 MB.

Para tornar a imagem menor, use um recurso chamado construções de vários estágios. Cada estágio em uma construção do Docker tem sua própria imagem base e pode executar comandos em seu estágio. No fim, é construída uma imagem final que copia em artefatos de estágios anteriores. Para construir uma imagem de contêiner por meio do código-fonte, um padrão comum é ter dois estágios:

1. O estágio do construtor que usa uma imagem base que contém todas as ferramentas necessárias para compilar o código-fonte no binário para o tempo de execução.
2. O estágio de tempo de execução que usa uma imagem base com o ambiente de tempo de execução necessário para executar o binário. O binário do estágio do construtor é copiado nesse estágio.

Para o projeto Maven, o resultado é semelhante ao exemplo a seguir,

FROM maven:3-jdk-11-openj9 AS builder

WORKDIR /app
COPY . /app

RUN mvn package

FROM adoptopenjdk:11-jre-openj9

WORKDIR /app
COPY --from=builder /app/target/java-application-1.0-SNAPSHOT-fat.jar /app/java-application.jar

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "/app/java-application.jar"]

Neste exemplo, o estágio do construtor usa a imagem base do Maven para construir o arquivo JAR do aplicativo. O estágio de tempo de execução usa a imagem base do JRE menor. Ao usar o comando COPY --from=STAGE_NAME, o arquivo JAR é copiado do estágio do construtor no estágio de tempo de execução. A imagem resultante tem um tamanho de 242 MB, economizando em torno de 48%.

Esse padrão também pode ser usado para outras linguagens de programação nas quais uma compilação precisa ser executada.

• Os aplicativos de nó que requerem uma construção, por exemplo, uma construção Angular ou React. Aqui, a imagem base do construtor e do tempo de execução pode acabar sendo a mesma (ambos os nós), mas nem todos os artefatos e origens do momento da criação precisam ser copiados na imagem de tempo de execução.
• Qualquer linguagem de programação que compile o código-fonte em um executável nativo que é executado sem um ambiente de tempo de execução, por exemplo, Go ou Rust.

Para aquelas linguagens que produzem um executável nativo e não precisam de um ambiente de tempo de execução de forma alguma, use outro recurso do Docker para o estágio de tempo de execução: utilizável. O utilizável pode ser usado como base no comando FROM, mas não é uma imagem de contêiner final. Em vez disso, ele informa à construção do Docker para não usar uma imagem base de forma alguma. Sem nenhum arquivo de sistema operacional proveniente de uma imagem base, a imagem de resultado pode conter apenas um único arquivo: o seu binário que é copiado por meio do estágio do construtor. Observe que, dependendo da linguagem de programação e de seu código, pode ser necessário fazer ajustes adicionais nas opções do compilador, pois os arquivos binários podem contar com alguns arquivos do sistema operacional para existir.

Manter sua imagem limpa

Quando você estiver desenvolvendo o seu Dockerfile pela primeira vez e depurando o funcionamento dele, será possível instalar algumas ferramentas temporárias ou aplicar outras cargas de trabalho que não tenham de estar na imagem final do contêiner. A remoção desses arquivos temporários e cargas de trabalho mantém a sua imagem limpa, pequena e mais segura.