Docker 015 – Dockerfile : 25 bonnes pratiques pour vos images

TL;DR

Un bon Dockerfile réduit la surface d’attaque, rend le build reproductible et place les opérations stables avant les opérations fréquemment modifiées pour exploiter le cache. Dans cet épisode, l’objectif est clair: produire des images petites, maintenables, vérifiables et exécutées sans privilèges inutiles. La vidéo est intégrée directement dans cet article et les commandes ci-dessous permettent de reproduire puis vérifier le comportement présenté.

La vidéo Docker de référence

Vidéo: https://www.youtube.com/watch?v=rVJMH9iuelA

Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWq0iz59-px2z-qjDdZKEvWd

Cet article correspond à la vidéo 15 sur 36 de la formation Docker. Le dépôt Xavki fournit les fichiers pratiques de ce chapitre: 15-dockerfile-python/.dockerignore, 15-dockerfile-python/Dockerfile, 15-dockerfile-python/app.py, 15-dockerfile-python/code.sh, 15-dockerfile-python/requirements.txt.

Définition simple : Dockerfile : 25 bonnes pratiques pour vos images

Un bon Dockerfile réduit la surface d’attaque, rend le build reproductible et place les opérations stables avant les opérations fréquemment modifiées pour exploiter le cache.

Le modèle mental utile consiste à séparer trois niveaux: ce qui est déclaré, ce qui est créé par Docker et ce qui est réellement observable sur l’hôte. Une commande réussie n’est qu’un premier signal. Il faut ensuite inspecter l’objet, lire son état et tester son comportement depuis le bon point de vue.

Quel problème cet épisode résout-il ?

Le besoin concret consiste à produire des images petites, maintenables, vérifiables et exécutées sans privilèges inutiles. Sans cette distinction, on finit souvent par appliquer une option au hasard, masquer un problème de permissions ou exposer une ressource plus largement que prévu.

La démarche recommandée reste la même: créer un exemple minimal, observer son état avec la CLI, provoquer un changement contrôlé, puis vérifier le résultat. Ce cycle court rend Docker beaucoup plus prévisible qu’une succession de commandes copiées sans diagnostic.

Les notions essentielles à retenir

• épingler une version ou un digest de base
• utiliser .dockerignore et un utilisateur non root
• reconstruire régulièrement pour intégrer les correctifs

Ces points constituent aussi une grille de lecture pour les épisodes suivants. Docker assemble images, processus, stockage, réseau et sécurité; une erreur visible dans une couche peut venir d’une configuration située dans une autre.

Commandes pratiques

docker buildx build --pull --check=error=true --load -t xavki/app:1.0.0 .
docker run --rm -i hadolint/hadolint < Dockerfile
docker image history xavki/app:1.0.0

Exécutez ces commandes sur un environnement de lab. Avant une suppression, une modification de daemon ou une ouverture réseau, inspectez les objets concernés et conservez une commande de retour arrière.

Méthode de vérification et de diagnostic

1. Vérifier le client et le daemon avec docker version puis docker info.
2. Inspecter l’objet ciblé avec docker inspect ou la sous-commande spécialisée.
3. Lire les logs du conteneur et ceux du daemon lorsque le cycle de vie échoue.
4. Contrôler le résultat depuis l’hôte puis, si nécessaire, depuis un autre conteneur.
5. Reproduire avec l’exemple minimal de cet épisode avant de revenir à l’application complète.

Cette méthode évite de confondre symptôme et cause. Une application inaccessible peut venir du processus, du port d’écoute, du réseau Docker, de la publication, du firewall ou du DNS. Un volume vide peut venir du chemin monté, de l’UID, de l’application ou d’un nouveau volume créé par erreur.

Pièges fréquents

• placer un secret dans une couche puis le supprimer plus tard
• installer des outils de debug inutiles en production
• penser que –no-cache met aussi à jour l image FROM

La plupart de ces erreurs sont faciles à prévenir avec des noms explicites, des versions fixées, une inspection avant suppression et un test de restauration ou de redémarrage.

Bonnes pratiques pour un environnement durable

• versionner Dockerfiles, scripts et configurations du daemon;
• utiliser des tags explicites et conserver les digests déployés;
• exécuter les applications sans root lorsque c’est possible;
• limiter CPU, mémoire, capabilities, montages et ports publiés;
• centraliser les logs sans oublier rotation et backpressure;
• sauvegarder les données persistantes et tester leur restauration;
• relire les dépréciations Docker avant chaque mise à niveau majeure.

Mini-lab conseillé

Reproduisez les commandes de l’épisode dans un environnement isolé. Notez l’état initial avec docker inspect, réalisez une seule modification, puis comparez l’état final. Terminez en supprimant les objets du lab et en vérifiant avec docker system df qu’aucune ressource inattendue ne reste présente.

Liens utiles

• Vidéo YouTube de cet épisode
• Playlist Docker complète
• Dépôt Xavki tutorials-docker
• Documentation officielle: /build/building/best-practices
• Documentation officielle: /reference/build-checks
• Code du chapitre: 15-dockerfile-python/.dockerignore
• Code du chapitre: 15-dockerfile-python/Dockerfile
• Code du chapitre: 15-dockerfile-python/app.py
• Code du chapitre: 15-dockerfile-python/code.sh
• Code du chapitre: 15-dockerfile-python/requirements.txt

Continuer la formation Docker

• Épisode précédent: Docker 014 – Layers Docker : comprendre les couches d’une image
• Épisode suivant: Docker 016 – CMD vs ENTRYPOINT : quelle différence dans un Dockerfile ?

FAQ

Cette commande fonctionne-t-elle avec Docker Desktop et Docker Engine ?

La CLI est largement commune, mais le daemon Docker Desktop s’exécute dans une VM sur macOS et Windows. Les chemins hôte, permissions, interfaces réseau, systemd et fichiers comme /etc/docker/daemon.json peuvent donc se comporter différemment d’un Docker Engine Linux natif.

Faut-il utiliser le tag latest dans les exemples ?

Pour un test ponctuel, latest est pratique mais reste un alias mutable. Pour un lab reproductible ou un déploiement, utilisez une version explicite et, lorsque l’immuabilité est nécessaire, un digest.

Où regarder lorsqu’une commande Docker échoue ?

Commencez par le message complet, docker version, docker info, docker inspect et docker logs. Sur Linux, consultez aussi journalctl -u docker. Pour le réseau, vérifiez l’adresse d’écoute de l’application avant les règles de publication.

Le dépôt GitLab suffit-il pour suivre la formation ?

Le dépôt contient les scripts et exemples de plusieurs chapitres, mais pas tous les épisodes de la playlist. La vidéo explique la démarche et la documentation officielle précise le comportement de la version actuelle. Les trois sources sont complémentaires.

Conclusion

Cet épisode 15/36 apporte une brique précise à la formation Docker: Dockerfile : 25 bonnes pratiques pour vos images. Retenez le modèle mental, reproduisez le lab, puis cherchez une preuve observable plutôt qu’un simple message de succès. C’est cette discipline qui transforme une commande Docker en compétence exploitable.