Dockerfile, couches, cache et multi-stage

Comprendre le mécanisme

Chaque étape d’un Dockerfile participe à la construction d’une image et à son cache. Copier les fichiers de dépendances avant le code changeant peut éviter de recalculer une installation coûteuse. Un build multi-stage nomme plusieurs étapes puis copie uniquement les artefacts nécessaires vers le runtime. Un fichier supprimé dans une couche ultérieure peut rester récupérable dans une couche antérieure : supprimer un secret après COPY ne suffit pas.

Raisonner et vérifier

Réduisez le contexte avec .dockerignore et fournissez les secrets de build par un mécanisme temporaire adapté. Le processus de build ne doit pas recopier le secret dans un artefact ou un log. Une image petite n’est pas une preuve de sûreté ; vérifiez aussi provenance, dépendances, permissions et fonctionnement. N’exécutez pas une résolution libre de versions si vous recherchez un artefact reproductible.

Séparer construction et exécution

Un build multi-stage permet de placer l’outillage de construction dans une étape puis de copier les artefacts utiles vers une étape runtime. Cette copie ciblée peut réduire ce qui est distribué. Elle ne doit pas oublier les dépendances nécessaires à l’exécution. Décrivez le contenu attendu de chaque étape et testez l’image finale seule ; un succès dans l’étape de build ne prouve pas qu’elle contient le bon livrable runtime.

Réduire le contexte envoyé au build

Le contexte peut inclure des fichiers locaux inutiles ou sensibles avant même les instructions du Dockerfile. .dockerignore aide à en exclure des éléments selon son contrat. Vérifiez les chemins réellement envoyés et évitez de compter seulement sur une suppression ultérieure. Un répertoire de développement peut contenir logs, sauvegardes et credentials qui n’appartiennent pas au périmètre de distribution du code.

Une suppression tardive ne retire pas toute trace

Copier un secret dans une couche puis le supprimer dans une instruction ultérieure ne garantit pas qu’il a disparu de l’historique d’image. La vue finale n’est pas toute l’archive distribuée. La bonne question est de savoir où la capacité a été exposée et quelles copies existent. Si le secret a réellement fuité, changer le build futur doit accompagner une procédure de retrait et de rotation.

Utiliser un mécanisme de secret adapté au build

Les montages de secrets ou mécanismes SSH prévus pour la construction peuvent exposer temporairement une capacité à l’instruction qui en a besoin. ARG et ENV ne constituent pas un coffre universel. Configurez l’entrée du secret et son usage sans le recopier dans l’artefact ou les logs. Un outil de build peut toujours divulguer une valeur qu’un script imprime ; le mécanisme demande donc une utilisation cohérente.

Verrouiller les dépendances utiles

Des manifestes et versions verrouillées aident à reproduire les dépendances installées. Une résolution flottante peut changer l’image alors que le code applicatif paraît identique. Conservez les versions, l’outil de construction et la plateforme. Cette reproductibilité ne démontre pas l’absence de défauts : elle rend leur identification et la comparaison de deux builds plus précises.

Organiser les étapes pour le cache

L’ordre des instructions influence les possibilités de réutilisation du cache. Copier les manifestes de dépendances avant le code qui change souvent peut éviter de réinstaller tout lorsque ces manifestes restent identiques. Cette stratégie doit conserver le bon contrat : une entrée réellement nécessaire ne doit pas être cachée hors du calcul. Mesurez le gain et vérifiez que l’artefact contient effectivement la version attendue.

Conserver les besoins du runtime

Copier un binaire ou un répertoire ne prouve pas que toutes les bibliothèques, fichiers de configuration et ressources utiles sont présents. Les dépendances dynamiques et la plateforme comptent. Lancez la dernière étape sans les répertoires du poste ni les outils de build, puis exercez le parcours utile. Une image plus petite n’est une amélioration que si elle conserve les capacités prévues.

Construire n’est pas tester la santé

Le succès de docker build indique que les instructions ont abouti dans le contexte de construction. Il ne prouve pas que la base est joignable, que le serveur accepte les demandes ou que l’application expose la bonne release. Ajoutez une exécution contrôlée et un health check représentatif. Le diagnostic doit distinguer erreur de construction, configuration runtime et panne de dépendance.

Choisir la plateforme cible

Une image et ses artefacts doivent correspondre à l’architecture et aux capacités de l’environnement d’exécution. Un build réalisé sur une machine ne prouve pas une exécution native sur toutes les autres. Documentez la plateforme demandée et celle réellement servie, notamment avec les images multi-plateformes. Les tests hors de l’IDE doivent vérifier l’artefact destiné au déploiement, pas seulement un assemblage local différent.

Inspecter sans exposer les secrets

Le contenu final et les métadonnées d’image doivent pouvoir être revus avec des fixtures publiques de laboratoire. Cherchez fichiers inattendus, logs et traces de credentials selon le périmètre de votre outil. Une absence dans la vue courante ne prouve pas toute l’histoire des couches. Les preuves doivent montrer la propriété recherchée et ses limites sans publier elles-mêmes la capacité que la revue voulait protéger.

Atelier guidé : lire, expliquer et vérifier le code

FROM composer:2 AS build
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts
FROM php:8.4-cli
COPY --from=build /app/vendor /app/vendor

La dernière étape de l’exemple copie seulement le répertoire vendor issu de build. Elle ne reçoit pas automatiquement tout le système de fichiers de cette étape. L’extrait montre une séparation et une sélection d’artefact, mais ne suffit pas à démarrer un service HTTP complet : le code applicatif, ses ressources et sa commande doivent encore être définis selon le produit.

Construisez une image de laboratoire avec un fichier témoin présent uniquement dans l’étape de build. Vérifiez qu’il n’apparaît pas dans la dernière étape si aucune copie ne le sélectionne. Examinez ensuite les besoins runtime réels et lancez le livrable dans un environnement propre. Une copie ciblée est une technique de distribution, pas une garantie automatique de complétude ni de sécurité du contenu copié.

Secrets de build : une suppression ultérieure ne retire pas la couche

Une image est construite à partir de couches et de métadonnées. Copier un token dans une couche puis le supprimer dans une instruction ultérieure peut le laisser récupérable dans l’historique de construction ou les artefacts intermédiaires.

Utilisez un secret de build monté temporairement à l’étape qui en a besoin. Le montage évite son inscription automatique comme fichier de l’image, mais la commande exécutée pourrait toujours le recopier dans une sortie, un cache ou un log. Contrôlez donc le comportement du gestionnaire de dépendances et les fichiers conservés dans l’image finale.

Vérifiez également contexte de build et fichiers exclus : un secret ne doit pas être envoyé inutilement au builder. Testez avec une valeur factice identifiable et examinez image finale, couches et logs selon votre pipeline. Si une valeur réelle a déjà été publiée, corriger le Dockerfile traite les prochains builds ; la capacité exposée demande séparément retrait et rotation.

Points de vigilance : Base64 ne protège pas un secret récupérable dans une couche. Le montage fournit le secret à l’étape nécessaire sans l’inscrire automatiquement dans l’image ; l’étape ne doit pas le divulguer. ARG et une copie vers l’image ne constituent pas un mécanisme approprié pour les secrets. Le contrôle du registre limite l’accès, mais ne supprime pas les octets des couches.