Meilleures pratiques de construction

Utiliser les constructions multi-étapes

Les constructions multi-étapes vous permettent de réduire la taille de votre image finale, en créant une séparation plus nette entre la construction de votre image et la sortie finale. Divisez vos instructions Dockerfile en étapes distinctes pour vous assurer que la sortie résultante ne contient que les fichiers nécessaires pour exécuter l'application.

L'utilisation de plusieurs étapes peut également vous permettre de construire plus efficacement en exécutant les étapes de construction en parallèle.

Voir Constructions multi-étapes pour plus d'informations.

Créer des étapes réutilisables

Si vous avez plusieurs images avec beaucoup en commun, envisagez de créer une étape réutilisable qui inclut les composants partagés, et de baser vos étapes uniques sur celle-ci. Docker n'a besoin de construire l'étape commune qu'une seule fois. Cela signifie que vos images dérivées utilisent la mémoire sur l'hôte Docker plus efficacement et se chargent plus rapidement.

Il est également plus facile de maintenir une étape de base commune ("Ne vous répétez pas"), que d'avoir plusieurs étapes différentes faisant des choses similaires.

Choisir la bonne image de base

La première étape pour obtenir une image sécurisée est de choisir la bonne base image. Lors du choix d'une image, assurez-vous qu'elle est construite à partir d'une source fiable et gardez-la petite.

• Images officielles Docker sont une collection organisée qui a une documentation claire, promeut les meilleures pratiques, et est régulièrement mise à jour. Elles fournissent un point de départ fiable pour de nombreuses applications.

• Les images Éditeur vérifié sont des images de haute qualité publiées et maintenues par les organisations partenaires de Docker, avec Docker vérifiant l'authenticité du contenu dans leurs référentiels.

• Open Source sponsorisé par Docker sont publiés et maintenus par des projets open source sponsorisés par Docker par le biais d'un programme open source.

Lorsque vous choisissez votre image de base, recherchez les badges indiquant que l'image fait partie de ces programmes.

Lorsque vous construisez votre propre image à partir d'un Dockerfile, assurez-vous de choisir une base minimale image qui correspond à vos besoins. Une image de base plus petite offre non seulement la portabilité et des téléchargements rapides, mais réduit également la taille de votre image et minimise le nombre de vulnérabilités introduites par les dépendances.

Vous devriez également envisager d'utiliser deux types d'image de base : une pour la construction et les tests unitaires, et une autre (généralement plus mince) pour la production. Dans les dernières étapes du développement, votre image peut ne pas nécessiter d'outils de construction tels que des compilateurs, des systèmes de construction et des outils de débogage. Une petite image avec un minimum de dépendances peut considérablement réduire la surface d'attaque.

Reconstruisez vos images souvent

Les images Docker sont immuables. Construire une image, c'est prendre un instantané de cette image à ce moment-là. Cela inclut toutes les images de base, bibliothèques ou autres logiciels que vous utilisez dans votre construction. Pour garder vos images à jour et sécurisées, assurez-vous de reconstruire votre image souvent, avec des dépendances mises à jour.

Pour vous assurer que vous obtenez les dernières versions des dépendances dans votre construction, vous pouvez utiliser l'option --no-cache pour éviter les accès au cache.

$ docker build --no-cache -t my-image:my-tag .

Le Dockerfile suivant utilise la balise 24.04 de l'image ubuntu. Au fil du temps, cette balise peut résoudre à une version sous-jacente différente de l'image ubuntu, car l'éditeur reconstruit l'image avec de nouveaux correctifs de sécurité et des bibliothèques mises à jour . En utilisant --no-cache, vous pouvez éviter les accès au cache et assurer un téléchargement frais des images de base et des dépendances.

# syntax=docker/dockerfile:1
FROM ubuntu:24.04
RUN apt-get -y update && apt-get install -y --no-install-recommends python3

Envisagez également de épingler les versions de l'image de base.

Exclure avec .dockerignore

Pour exclure les fichiers non pertinents pour la construction, sans restructurer votre référentiel source , utilisez un fichier .dockerignore. Ce fichier prend en charge les modèles d'exclusion similaires aux fichiers .gitignore.

Par exemple, pour exclure tous les fichiers avec l'extension .md :

*.md

Pour plus d'informations sur la création d'un, voir Fichier Dockerignore.

Créer des conteneurs éphémères

L'image définie par votre Dockerfile doit générer des conteneurs aussi éphémères que possible. Éphémère signifie que le conteneur peut être arrêté et détruit, puis reconstruit et remplacé avec un minimum absolu de configuration et .

Référez-vous à Processus sous la méthodologie The Twelve-factor App pour avoir une idée des motivations de l'exécution de conteneurs de manière aussi apatride.

N'installez pas de paquets inutiles

Évitez d'installer des paquets supplémentaires ou inutiles simplement parce qu'ils pourraient être agréables à avoir. Par exemple, vous n'avez pas besoin d'inclure un éditeur de texte dans une image de base de données.

Lorsque vous évitez d'installer des paquets supplémentaires ou inutiles, vos images ont une complexité réduite, des dépendances réduites, des tailles de fichier réduites et des temps de construction réduits.

Découpler les applications

Chaque conteneur ne doit avoir qu'une seule préoccupation. Le découplage des applications en plusieurs conteneurs facilite la mise à l'échelle horizontale et la réutilisation des conteneurs. Par exemple, une pile d'applications Web peut être composée de trois conteneurs distincts , chacun avec sa propre image unique, pour gérer l'application Web, la base de données et un cache en mémoire de manière découplée.

Limiter chaque conteneur à un seul processus est une bonne règle de base, mais ce n'est pas une règle absolue. Par exemple, non seulement les conteneurs peuvent être lancés avec un processus d'initialisation, certains programmes peuvent lancer des processus supplémentaires de leur propre chef. Par exemple, Celery peut lancer plusieurs processus de travail et Apache peut créer un processus par requête.

Utilisez votre meilleur jugement pour garder les conteneurs aussi propres et modulaires que possible. Si les conteneurs dépendent les uns des autres, vous pouvez utiliser les réseaux de conteneurs Docker pour vous assurer que ces conteneurs peuvent communiquer.

Trier les arguments multilignes

Dans la mesure du possible, triez les arguments multilignes alphanumériquement pour faciliter la maintenance. Cela aide à éviter la duplication de paquets et à rendre la liste beaucoup plus facile à mettre à jour. Cela rend également les PR beaucoup plus faciles à lire et à examiner. L'ajout d'un espace avant une barre oblique inverse (\) aide également.

Voici un exemple de l'image buildpack-deps :

RUN apt-get update && apt-get install -y --no-install-recommends \
  bzr \
  cvs \
  git \
  mercurial \
  subversion \
  && rm -rf /var/lib/apt/lists/*

Tirer parti du cache de construction

Lors de la construction d'une image, Docker parcourt les instructions de votre Dockerfile, en exécutant chacune dans l'ordre spécifié. Pour chaque instruction, Docker vérifie s'il peut réutiliser l'instruction du cache de construction.

Comprendre comment fonctionne le cache de construction et comment se produit l'invalidation du cache est essentiel pour garantir des constructions plus rapides. Pour plus d'informations sur le cache de construction Docker et comment optimiser vos constructions, voir Cache de construction Docker.

Épingler les versions de l'image de base

Les balises d'image sont mutables, ce qui signifie qu'un éditeur peut mettre à jour une balise pour pointer vers une nouvelle image. C'est utile car cela permet aux éditeurs de mettre à jour les balises pour pointer vers des versions plus récentes d'une image. Et en tant que consommateur d'images, cela signifie que vous obtenez automatiquement la nouvelle version lorsque vous reconstruisez votre image.

Par exemple, si vous spécifiez FROM alpine:3.21 dans votre Dockerfile, 3.21 se résout à la dernière version de correctif pour 3.21.

# syntax=docker/dockerfile:1
FROM alpine:3.21