Combinaison de plusieurs commandes en une seule instruction RUN afin de réduire la taille de l'image

Dans cet exemple, vous devez installer le logiciel dans l'image du conteneur, par exemple, Node.js. Utilisez les images de base pour Node.js afin de générer une application Node.js .

Pour installer manuellement Node.js, vous pouvez utiliser l'exemple de fichier Dockerfile suivant :

FROM ubuntu

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

Dans cet exemple, plusieurs instructions RUN sont utilisées pour la mise à jour, la mise à niveau, l'installation de Node.js, le nettoyage et la suppression du cache des fichiers. Bien que cette séquence d'instructions soit correcte, l'utilisation de plusieurs instructions RUN n'est pas le meilleur moyen de l'implémenter. Lorsqu'un fichier Dockerfile est traité, chaque instruction du fichier Dockerfile crée une couche. Chaque couche contient les fichiers qui ont été créés ou mis à jour ainsi que des informations sur ce qui a été supprimé. Une image de conteneur est la collection de toutes les couches. Si un fichier est ajouté dans une instruction et supprimé dans une autre, l'image obtenue contient toujours le fichier dans la couche de la première instruction, et le marque comme supprimé dans la seconde couche.

Pour sauvegarder l'espace disque, indiquez une seule instruction RUN pour créer une seule couche pour ce jeu de commandes :

FROM ubuntu

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

Pour conserver un fichier Dockerfile lisible avec une ligne par commande, ajoutez des retours à la ligne à votre code :

FROM ubuntu

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

L'utilisation de ce type d'instruction vous permet de réduire la taille de l'image de conteneur de 174 Mo à environ 147 Mo. Notez que les tailles de vos exemples peuvent différer car l'image de base Ubuntu et le package Node.js peuvent changer.

Ce type de meilleure pratique s'applique non seulement aux installations de packages, mais également à des tâches similaires. Dans l'exemple suivant, le téléchargement et l'extraction d'un progiciel, à nouveau Node.js, peuvent ressembler à l'exemple suivant :

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

La commande rm supprime le package nodejs téléchargé, mais les nombreuses instructions RUN créent à nouveau des couches distinctes. En outre, pour télécharger le package nodejs, le package curl est temporairement installé. Bien que le package curl lui-même soit supprimé ultérieurement, ses dépendances qui ont été implicitement installées sont toujours présentes. Un meilleur fichier Dockerfile ressemble à l'exemple suivant :

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

Les commandes connexes sont combinées en une seule instruction RUN et la commande apt auto-remove est ajoutée pour supprimer les dépendances. Cet exemple réduit la taille de l'image de 222 Mo à environ 162 Mo.

Utilisation d'une petite image de base

Les exemples précédents utilisent Ubuntu comme image de base. Bien que cette image contienne de nombreux utilitaires utiles, plus il y a d'utilitaires dans une image de base, plus la taille de cette dernière est grande. De plus, en incluant plus d'utilitaires, vous augmentez le risque de faille de sécurité, vous obligeant à régénérer votre image. Pour éviter ces deux problèmes, utilisez une image de base plus petite. Par exemple :

• Alpine est une image Docker officielle de petite taille. Pour les environnements de programmation tels que Java ou Node.js, vous trouverez souvent des balises basées sur Alpine.

• Les images Distroless de Google Container Tools ne contiennent aucun outil de système d'exploitation mais l'environnement d'exécution nécessaire pour différents langages tels que Java et Node.js.

Comparez ces images de base en générant une image de conteneur qui exécute un programme Node.js dans un fichier program.js. Pour Ubuntu, le fichier Dockerfile ressemble à l'exemple suivant :

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"]

Pour Alpine, l'image est prise directement à partir de Node.js :

FROM node:16-alpine

COPY program.js /app/program.js

WORKDIR /app

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

Pour Distroless, utilisez l'exemple suivant :

FROM gcr.io/distroless/nodejs:16

COPY program.js /app/program.js

WORKDIR /app

CMD ["program.js"]

Alors que l'image basée sur Ubuntu fait 147 Mo, l'image basée sur Alpine fait 90 Mo et l'image basée sur Distroless 94 Mo.

Ne pas inclure de sources et d'outils de génération pour réduire la taille de l'image

Dans les exemples précédents basés sur Node.js, un seul fichier source est ajouté à l'image de conteneur. Cet exemple peut utiliser un fichier source unique car aucune compilation n'était nécessaire. Toutefois, si une compilation est requise, utilisez les outils nécessaires à la génération uniquement, mais ne les incluez pas à l'image obtenue. Par exemple, indiquez une application Java qui utilise Maven comme exemple. Un fichier Dockerfile mal codé ressemble à l'exemple suivant :

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"]

L'image de conteneur qui en résulte contient tout le code source et tous les fichiers intermédiaires de Maven (tels que le cache d'artéfacts, les fichiers de classe qui sont ensuite intégrés dans un fichier JAR) ainsi que l'outil de génération Maven. De plus, le kit Java Development Kit (JDK) est également inclus lorsqu'un environnement JRE beaucoup plus petit est requis à l'exécution. En conséquence, la taille de l'image est de 466 Mo.

Pour réduire la taille de l'image, utilisez une fonctionnalité dite de générations à plusieurs étapes. Chaque étape d'une génération de fichier Docker possède sa propre image de base et peut exécuter des commandes à son étape. A la fin, une image finale est générée et copie les artefacts des étapes précédentes. Pour générer une image de conteneur à partir du code source, un modèle commun doit avoir deux étapes :

1. L'étape de génération qui utilise une image de base qui contient tous les outils nécessaires pour compiler le code source dans le fichier binaire de l'environnement d'exécution.
2. L'étape d'exécution, qui utilise une image de base avec l'environnement d'exécution nécessaire pour exécuter le fichier binaire. Le fichier binaire de l'étape de génération est copié dans cette étape.

Pour le projet Maven, le résultat ressemble à l'exemple suivant :

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"]

Dans cet exemple, l'étape de génération utilise l'image de base Maven pour générer le fichier JAR de l'application. L'étape d'exécution utilise l'image de base JRE plus petite. L'utilisation de la commande COPY --from=STAGE_NAME permet de copier le fichier JAR de l'étape de génération à l'étape d'exécution. L'image obtenue a une taille de 242 Mo, permettant d'économiser environ 48 %.

Ce modèle peut également être utilisé pour d'autres langages de programmation dans lesquels une compilation doit être effectuée.

• Des applications de noeud nécessitant une génération, par exemple une génération Angular ou React. Ici, les images de base de génération et d'exécution peuvent finir par être identiques (pour les deux noeuds), mais tous les artefacts et sources de temps de génération n'ont pas besoin d'être copiés dans l'image d'exécution.
• Tout langage de programmation qui compile du code source dans un exécutable natif qui s'exécute sans environnement d'exécution, par exemple Go ou Rust.

Pour les langages qui produisent un exécutable natif et qui n'ont pas du tout besoin d'un environnement d'exécution, utilisez une autre fonctionnalité Docker pour l'étape d'exécution : Scratch. Scratch peut être utilisé en tant que base dans la commande FROM, mais il ne s'agit pas d'une image de conteneur finale. Au lieu de cela, il indique à la génération de fichier Docker de ne pas du tout utiliser d'image de base. Sans aucun fichier de système d'exploitation provenant d'une image de base, l'image obtenue peut ne contenir qu'un seul fichier : votre fichier binaire copié à partir de l'étape de génération. Notez qu'en fonction du langage de programmation et de votre code, vous devrez peut-être effectuer d'autres ajustements sur les options de compilation car les fichiers binaires peuvent dépendre de certains fichiers du système d'exploitation.

Garder votre image propre

Lorsque vous développez pour la première fois votre fichier Dockerfile et que vous le déboguez, vous pouvez installer certains outils temporaires ou appliquer d'autres charges de travail qui ne doivent pas nécessairement figurer dans l'image de conteneur finale. La suppression de ces fichiers temporaires et charges de travail permet de garder votre image propre, petite et plus sécurisée.