Aller au contenu
English
Compte : non connecté, synchronisation possible Mon apprentissage
Selectionner le thème
English

Tutoriel Docker : le guide pour apprendre de A à Z

  • 25 min

Par mis à jour le

Améliorer cette page

Logo Docker

Docker est la plateforme de référence de conteneurisation : elle vous permet d'empaqueter une application et ses dépendances dans une image, un artefact immuable, puis de l'exécuter partout à l'identique sous forme de conteneur, un processus isolé et léger qui démarre en quelques secondes. Cela règle le fameux « ça marche sur ma machine » : le conteneur embarque tout ce qu'il faut pour tourner, du code aux bibliothèques système.

Cette page ouvre la formation Docker : elle vous explique comment elle est organisée, module par module, puis vous donne une référence rapide pour revenir sur une commande ou un choix.

La formation Docker suppose que vous savez déjà ce qu'est un conteneur et que vous êtes à l'aise dans un terminal Linux. Le premier acquis vient de la formation Introduction à la conteneurisation, le second de la formation Linux.

La formation Introduction à la conteneurisation vous fait comprendre qu'un conteneur est un processus ordinaire de la machine, à qui le noyau donne une vue restreinte du système. Les namespaces isolent ce qu'il voit, et les cgroups plafonnent ce qu'il consomme : vous les créez à la main dans Un conteneur à la main avec unshare et nsenter puis Limiter un conteneur : cgroups v2 et capabilities. Vous y apprenez aussi la différence avec une machine virtuelle : celle-ci émule un ordinateur complet avec son propre noyau, alors qu'un conteneur partage le noyau de l'hôte, ce qui explique son démarrage en quelques secondes.

Une image OCI est une archive standardisée qui fournit le système de fichiers et la configuration de départ d'un conteneur. Elle s'étudie avec Comprendre OCI : image, distribution et runtime et Lire une image OCI et vérifier son digest.

Un runtime comme runc exécute ensuite cette image en reproduisant les gestes du noyau vus plus tôt, dans Exécuter un bundle OCI avec runc. La leçon Runtime, moteur, orchestrateur : qui fait quoi situe ensuite Docker par rapport à lui.

Côté Linux, la formation Docker n'utilise qu'un socle réduit, que la page d'accueil de la formation Linux détaille : naviguer et éditer des fichiers dans un terminal, lire et modifier les droits d'un fichier et d'un utilisateur, afficher et arrêter des processus, et comprendre le réseau de base (adresse IP, port, résolution de nom). Ces notions reviennent dans les modules sur les volumes, l'arrêt propre d'un conteneur et la publication de ports.

Si ces acquis vous manquent, suivez d'abord la formation Introduction à la conteneurisation, puis reprenez les modules de Linux qui correspondent à ce qui vous bloque, avant de revenir ici.

La formation compte quatorze modules d'enseignement, répartis en trois niveaux : « Utiliser Docker » (lancer, construire, publier, observer, relier et persister), « Composer et exploiter une application » (Compose), puis « Fabriquer, durcir et industrialiser » (images avancées, moteur, durcissement, chaîne d'images). Les modules suivent un ordre de lecture conseillé, et votre avancement leçon par leçon se suit sur la page Mon parcours.

Toutes les commandes de la formation sont mesurées sur Docker Engine 29.9.2, Compose 5.6.1 et Buildx 0.38.1, installés sur Debian 13.

Les durées citées plus bas sont celles du programme : chaque leçon porte la sienne, et un module annonce la somme de ses leçons publiées. Toutes les leçons et épreuves du programme ont une page publiée. Cette page ne lie que les leçons publiées.

Ce premier module (environ 2 h 45) pose ce qu'est un conteneur avant d'en lancer un. La leçon Conteneurs ou machines virtuelles : que choisir ? compare les deux modèles, puis Images, conteneurs et registres : l'anatomie retrace le chemin d'une commande docker jusqu'au processus. Vous installez ensuite Docker Engine 29 et prouvez qu'il fonctionne, puis vous apprenez à lancer un conteneur et à choisir ce qu'il exécute. L'épreuve « mettre un service en marche » clôt le module.

Un conteneur part d'une image, et ce module (environ 3 h 25) vous apprend à la fabriquer puis à la publier. Il commence par Écrire un Dockerfile, puis choisir et maintenir une image de base. Il enchaîne avec Docker USER, qui explique comment exécuter une image en non-root sans la casser, et avec l'organisation des couches et le cache de construction. La leçon Publier et récupérer une image vous fait nommer l'image, vous connecter avec un jeton à droits limités, puis la pousser et la récupérer par tag ou par digest. L'épreuve « livrer une première image » vérifie le tout.

Ce module (environ 2 h 20) sert à comprendre pourquoi un conteneur s'arrête, redémarre ou refuse de démarrer. Le cycle de vie, le PID 1 et l'arrêt propre expliquent les états et les codes 137 et 143. Inspecter un conteneur en marche donne quatre commandes pour quatre questions, et Lire un échec de démarrage apprend à interpréter les codes 125, 126 et 127 et les boucles de redémarrage. L'épreuve « remettre trois conteneurs en service » vous met en situation.

Ce module (environ 2 h 10) traite de ce qui est ouvert, et à qui. Publier un port sans exposer tout l'hôte distingue les trois formes de -p. Ensuite, le réseau par défaut ou un réseau à soi montre que seul un réseau créé par vous résout les noms de conteneurs, et isoler un conteneur du réseau compare none et le réseau interne. L'épreuve « exposer une application sans exposer sa base » en fait la preuve.

Un conteneur recréé perd ses fichiers : ce module (environ 1 h 35) vous apprend à les garder. La leçon Volumes Docker compare volume nommé, bind mount et tmpfs. Celle sur les droits d'un volume départage les trois causes d'un accès refusé. Vous terminez par l'épreuve « remettre un conteneur en service ».

Ce module (environ 3 h 15) ouvre le deuxième niveau : vous passez de plusieurs docker run à un fichier unique. La leçon Décrire une application avec Compose pose deux services, un réseau et un volume. Elle est suivie de l'interpolation et des fichiers d'environnement, de l'organisation des réseaux d'une stack et de la persistance des données d'une stack recréée. L'épreuve « remettre une stack en service » conclut.

Une stack qui démarre n'est pas encore une stack fiable, et ce module (environ 3 h 45) s'en occupe. Vous y injectez des secrets en connaissant leurs limites, vous réglez le démarrage, la disponibilité et la santé, vous encadrez ressources et redémarrage, puis vous écrivez des variantes explicites pour le développement et le déploiement. L'épreuve « fiabiliser une stack » vérifie ces réglages.

Ce module (environ 2 h 45) termine le deuxième niveau. Il apprend à lire les journaux et à attribuer une saturation, à sauvegarder et restaurer une application, puis à mettre à jour une stack et revenir en arrière sans perdre les données. L'épreuve « exploiter et restaurer une stack » clôt le module et le niveau.

Le troisième niveau s'ouvre sur ce module (environ 6 h 15), qui reprend la fabrication d'images là où le premier niveau s'est arrêté. Vous commencez par lire une image OCI et son identité : tag, index, manifeste, digest et plateforme. Vous apprenez ensuite à changer de socle sans casser l'application, puis à séparer construction et exécution avec un build multi-étapes. La leçon BuildKit : secrets de build et accès privé traite des secrets de build, et celle sur le multi-architecture de buildx et de l'émulation. L'épreuve « reconstruire une image pour deux architectures » vérifie le résultat.

Ce module apprend à décider qu'une image est prête, puis à la livrer. Ses cinq leçons et son épreuve représentent environ 5 h 35. Vous testez le contrat d'une image avec un script qui la refuse si elle est inutilisable, puis vous optimisez sa taille. Vous servez ensuite un registre de confiance et vous vous y authentifiez, vous épinglez un socle et vous livrez hors ligne par docker save, puis vous exportez une image sans démon avec Skopeo. L'épreuve « livrer une image utilisable ailleurs » vérifie qu'un client vierge exécute votre livraison.

Ce module explique ce qui se passe réellement quand un conteneur démarre. Ses quatre leçons et son épreuve représentent environ 2 h 50. Vous commencez par mesurer l'isolation d'un conteneur avec les namespaces et les cgroups, puis vous suivez la chaîne d'exécution du client docker jusqu'à runc. La leçon Brider un conteneur règle ensuite le processeur, les ulimits et la mémoire partagée, et Plafonner la mémoire et le nombre de tâches apprend à poser ces deux plafonds, à lire leur effet dans le cgroup et à reconnaître un OOM ou une saturation de tâches. L'épreuve « contenir un conteneur gourmand » clôt le module.

Le démon Docker est l'élément que toutes vos applications partagent, et ce module vous apprend à le tenir. Ses six leçons publiées et son épreuve représentent environ 5 h. La leçon Administrer le démon et ses contextes (environ 35 min) montre où le démon lit sa configuration, modifie daemon.json par fusion avec jq puis dockerd --validate sans casser le démon, distingue reload et restart, ferme une écoute TCP posée par une surcharge systemd, puis administre un hôte distant par un contexte SSH et prouve qu'une clé non autorisée est refusée. La leçon Interposer un proxy devant l'API Docker (environ 40 min) montre pourquoi monter docker.sock en :ro ne protège pas.

La leçon Faire tourner les journaux, et reprendre du disque (environ 30 min) borne les journaux d'un conteneur, prouve que la rotation a lieu, mesure l'espace par catégorie et libère un système de fichiers plein sans recréer le conteneur. La leçon Mettre à jour le moteur et sauvegarder sa configuration (environ 35 min) monte Docker Engine d'une version à l'autre sur un hôte dont les paquets sont retenus, avec live-restore et une donnée témoin, puis revient en arrière. La leçon Retirer les accès directs au moteur (environ 45 min) inventorie qui peut parler au socket Docker, par le groupe docker, une ACL ou un montage dans un conteneur, puis retire chaque accès et vérifie qu'il est vraiment fermé. La leçon Exécuter Docker en rootless (environ 55 min) installe un moteur sous un compte sans privilège à côté du moteur système, lit la correspondance des UID, mesure ce qui change pour le réseau, les ressources et AppArmor, puis garde le démon actif sans session ouverte. L'épreuve « reprendre un hôte Docker » (environ 60 min) clôt le module : un hôte laissé sans suivi, à reprendre sans perdre ses volumes nommés.

Ce module vise à réduire ce qu'un conteneur compromis peut faire. Ses six leçons publiées et son épreuve représentent environ 5 h 20. La leçon Durcir le runtime : capabilities et privilèges (environ 30 min) retire toutes les capabilities avec --cap-drop ALL, retrouve et justifie la seule exception dont le service a besoin, bloque les gains de privilèges avec no-new-privileges, n'ouvre qu'un périphérique avec --device au lieu de --privileged, et liste les réglages à ne jamais poser. La leçon Garder un secret hors de l'environnement (environ 25 min) montre pourquoi -e se lit dans docker inspect et dans /proc/1/environ, puis fournit le secret par un fichier monté en lecture seule, la convention _FILE et un secret Compose de type file. Les secrets de build se traitent dans BuildKit : secrets de build et accès privé. La leçon Racine en lecture seule, et arrêt sans perte (environ 50 min) fige la racine d'un conteneur PostgreSQL avec --read-only, borne ses tmpfs, prépare son volume, puis compare docker stop et docker kill sur une transaction en cours. La leçon Retrouver des données orphelines sans tout effacer (environ 60 min) retrouve un volume qui n'est plus attaché, le lit sans risque et le sauvegarde, le rattache à Compose après un changement de nom de projet, puis ne supprime que ce qui est jetable. La leçon Confiner par profils : seccomp et AppArmor (environ 60 min) lit les profils actifs d'un conteneur, attribue un refus à sa couche, dérive un profil seccomp du profil par défaut et écrit un profil AppArmor qui laisse encore le service s'arrêter proprement et survit au redémarrage. La leçon Diagnostiquer réseau et pare-feu (environ 35 min) suit un paquet jusqu'au conteneur, localise le saut et la règle qui le refusent, corrige une seule règle et le prouve par des sondes positives et négatives, sans jamais désactiver le pare-feu. L'épreuve « durcir sans casser » (environ 60 min) clôt le module.

Le dernier module met la fabrication d'images en production. La leçon Automatiser build, tests et publication (environ 40 min) écrit un script de CI qui construit l'image d'un commit, la teste avec Compose, puis publie une archive avec sa provenance. La leçon Partager le cache de build en CI, et promouvoir une image entre registres (environ 35 min) exporte le cache par un registre, choisit entre les modes min et max sur des mesures, puis copie une image d'un registre à l'autre sans la reconstruire. Elle ne couvre pas la promotion entre environnements : la leçon Promouvoir le même artefact entre deux environnements (environ 55 min) la traite, en transférant une archive vers un second hôte et en déployant avec --no-build --pull never pour qu'aucun environnement ne reconstruise l'image.

La leçon Vérifier ce que contient une image, et qui l'a signée (environ 50 min) scanne une image avec Trivy, écrit une barrière qui refuse une CVE nommée, puis signe une archive avec une autorité locale et vérifie la chaîne, l'identité et la signature ; Cosign et DOCKER_CONTENT_TRUST n'y sont que situés.

La leçon Préparer l'exploitation, et reconnaître les limites d'un mono-hôte (environ 40 min) mesure un SLO, relie les alertes aux signaux que Docker expose, chronomètre une restauration, puis vérifie la reprise du service après le redémarrage de l'hôte, et ce qu'un seul hôte ne peut pas garantir. L'épreuve finale « reprendre un service inconnu » (environ 3 h) clôt la formation : une application à livrer, durcir, faire tomber et rétablir de bout en bout, notée sur l'état final. Le module représente environ 6 h 40.

Vous voulez une page "réponse immédiate" ? Cette section est faite pour ça.

Concepts (image/conteneur/layers), ce qu'il faut retenir
  • Image : artefact immuable (comme un binaire buildé ou un paquet).
  • Conteneur : process isolé (comme un service systemd) + FS éphémère.
  • Layer : diff (comme un commit Git) empilé et cacheable.
  • Volume : stockage persistant (comme un PVC local, mais côté Docker).
  • Réseau bridge : réseau NAT isolé (comme une VRF "par défaut" Docker).

→ Guide Concepts

CLI, les commandes qui comptent vraiment
  • "Je lance" : docker run …
  • "Je vois" : docker ps, docker images
  • "Je comprends" : docker logs, docker inspect
  • "J'entre" : docker exec -it … sh
  • "Je nettoie" : docker rm, docker rmi, docker system prune

→ Guide CLI

Volumes, choix rapide
  • Bind mount : dev / code local / debug rapide.
  • Volume nommé : prod / données applicatives / DB.
  • tmpfs : secret temporaire / perf / rien sur disque.

→ Guide Volumes

Réseaux, choix rapide
  • bridge : cas standard (app multi-conteneurs sur 1 hôte).
  • host : perf max, isolation réseau minimale.
  • overlay : multi-hôtes (Swarm) / réseau distribué.

→ Guide Réseaux

Dépannage, "je fais quoi quand ça marche pas"
  • Si ça crash : exit code + logs + inspect (ordre fixe).
  • Si ça ne répond pas : ports publish + IP/route + DNS + healthcheck.
  • Si ça ne pull pas : auth registry + DNS + proxy + certs.

→ Guide Dépannage

Sécurité, règles simples
  • Évitez root (rootless si possible).
  • Retirez les capabilities inutiles, read-only FS si possible.
  • Scannez les images, mettez à jour régulièrement.
  • Secrets hors image + hors variables exposées.

→ Durcir le runtime : capabilities et privilèges → Garder un secret hors de l'environnement

La frise se lit de haut en bas, de 2010 à 2024 : elle place les dates qui expliquent pourquoi l'écosystème ne dépend plus d'un seul outil, avec en relief la dépréciation de dockershim par Kubernetes en 2020 (Kubernetes 1.20), suivie de son retrait en 2022 (Kubernetes 1.24).

Repères sur l'évolution de l'écosystème Docker : dotCloud en 2010, Docker open source en 2013, adoption explosive en 2014, création de l'OCI en 2015, containerd chez la CNCF en 2017, dépréciation de dockershim par Kubernetes en 2020, BuildKit par défaut dans Docker 23.0 en 2023, standard OCI en 2024.2010 · dotCloudSolomon Hykes2013 · Docker open sourceBuild once, run anywhere2014 · Adoption explosiveGCP, AWS, Azure2015 · OCI fondéeOpen Container Initiative2017 · containerd → CNCFKubernetes l'adopte2020 · Kubernetes déprécie dockershim→ containerd2023 · Docker 23.0BuildKit par défaut2024 · Des millions d'utilisateursStandard OCI
Source · SVG
Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 %

Ce projet vous est utile ?

Je prends le temps de rédiger ces guides, de tester les commandes et de vérifier les labs pour que vous puissiez apprendre gratuitement. Si ce travail vous aide, offrez-moi un café. C'est une façon simple de contribuer à la suite du projet.

Offrir un café (nouvel onglet) Soutenir chaque mois (nouvel onglet) En savoir plus

Suivez aussi le projet sur LinkedIn