Commence ici
Ton premier conteneur
L'équipe marketing fait tourner la page des soldes de printemps dans un conteneur sur le serveur de la boutique, mais personne n'arrive à l'ouvrir. Fais-la répondre sur le port 8080 du serveur.
Commencer l'exerciceConteneurs : Docker, Compose et Swarm
Chaque exercice exécute tes fichiers et tes commandes sur un serveur simulé, puis le teste comme en production : redémarrages, mises à jour, trafic et attaques.
Débutant gratuit
Lancer, configurer et diagnostiquer des conteneurs, garder les données d'un redémarrage à l'autre, et faire revenir seul un service après un plantage ou un redémarrage.
0 sur 9 réussis
- Ton premier conteneur L'équipe marketing fait tourner la page des soldes de printemps dans un conteneur sur le serveur de la boutique, mais personne n'arrive à l'ouvrir. Fais-la répondre sur le port 8080 du serveur. ConteneurPublication de portsCycle de vie d'un conteneur
- Image ou conteneur ? La page d'accueil affichait « Welcom ». Un collègue a corrigé avec docker exec, directement dans le conteneur qui tourne, et la page s'affiche bien. Cette nuit à 3 h, la maintenance du serveur recrée tous les conteneurs à partir de leur image. Fais en sorte que la correction survive. Image ou conteneurCouche inscriptibleTags d'image
- Ton premier Dockerfile L'API des commandes doit être livrée dans un conteneur. Un premier Dockerfile se construit bien, mais le conteneur s'arrête une seconde après son démarrage. Fais répondre l'API sur le port 3000 du serveur. DockerfileCMD et ENTRYPOINTProcessus principal (PID 1)
- Configurer par l'environnement L'API de paiement refuse de démarrer : elle plante avec le code de sortie 1. Il lui faut la clé du prestataire de paiement, et quelqu'un a proposé de l'écrire dans le Dockerfile. Démarre l'API sans graver le secret dans l'image. Variables d'environnementGarder les secrets hors des imagesJournaux de conteneur
- Lire les logs, entrer dans le conteneur Depuis la mise en production de ce matin, le service des commandes redémarre en boucle. Trouve pourquoi avec ses logs, regarde dans l'image, et fais-le tourner une heure sans un seul redémarrage. Journaux de conteneurdocker execPolitiques de redémarrage
- Les données survivent-elles ? La base des commandes tourne dans un conteneur. Cette nuit à 2 h, l'exploitation met PostgreSQL à jour en remplaçant ce conteneur par un conteneur de postgres:16.4. Fais en sorte qu'aucune commande ne soit perdue. VolumesCouche inscriptibleImage ou conteneur
- Redémarrer tout seul La nuit dernière, le serveur a redémarré à 3 h pour une mise à jour du noyau et la boutique est restée coupée jusqu'à l'arrivée de quelqu'un à 9 h. Fais revenir la boutique toute seule, quoi qui l'arrête. Politiques de redémarrageCycle de vie d'un conteneurCodes de sortie
- Deux conteneurs qui se parlent L'API qui compte les visites garde ses compteurs dans Redis. Les deux tournent dans des conteneurs, mais l'API ne trouve pas « redis » et plante sans cesse. Quelqu'un a proposé de publier Redis sur le serveur... ne le fais pas. Fais joindre Redis par son nom, en gardant Redis invisible depuis Internet. Réseaux créés par l'utilisateurRéseau bridge par défautPublication de ports
- Faire de la place Le disque du serveur d'intégration continue est presque plein et les builds échouent avec « no space left on device ». Libère de la place sans toucher au volume ci-history, qui garde deux ans d'historique de builds. Espace disque de DockerImages orphelines (dangling)Volumes
Intermédiaire
Construire des images légères, rapides et sûres, et faire tourner une stack Compose qui démarre dans l'ordre, respecte ses limites et sépare le développement de la production.
- Le cache de build Chaque modification d'une ligne de l'API des commandes coûte quatre minutes de npm ci en CI. Réordonne le Dockerfile pour qu'un changement de code se reconstruise en moins de 20 secondes. Cache de buildCouches d'imageDockerfile
- Une image de 1 Go Le service catalogue est un petit programme Go, et pourtant son image pèse 1,1 Go : toute la chaîne de compilation Go part en production. Fais passer l'image sous 100 Mo avec un build multi-étapes. Builds multi-étapesImages de baseBinaires statiques
- Le contexte de build Construire le service des comptes envoie 420 Mo à Docker à chaque fois, le conteneur plante sur le serveur avec « invalid ELF header », et un scan de sécurité vient de trouver le fichier .env de production dans l'image. Corrige le contexte de build. Contexte de build.dockerignoreGarder les secrets hors des images
- Ne plus tourner en root Un audit de sécurité signale le service média : son processus tourne en root, une faille dans l'application donnerait donc root à un attaquant dans le conteneur. Fais-le tourner avec un utilisateur sans privilèges... et garde les envois de photos fonctionnels. Ne pas tourner en rootDroits des fichiers dans les conteneursVolumes
- Démarré ne veut pas dire prêt À presque chaque déploiement, l'API des commandes plante une fois : elle se connecte avant que PostgreSQL accepte les connexions. depends_on est déjà dans compose.yaml. Fais réussir chaque démarrage de la stack. Ordre de démarrageHealthchecksDocker Compose
- Ta première stack Compose La boutique fait tourner un front (nginx), une API, PostgreSQL et Redis. Un premier compose.yaml démarre tout, mais il publie la base et le cache sur l'adresse publique du serveur. Seul le front doit être joignable depuis Internet, et le front ne doit même pas voir la base. Docker ComposeRéseaux ComposeEXPOSE ou publier
- Limites de ressources Chaque après-midi, la boutique devient d'une lenteur terrible : le worker de vignettes fuit de la mémoire, le serveur se met à swapper et la latence de l'API explose. La fuite ne peut pas être corrigée aujourd'hui. Fais en sorte qu'elle ne pénalise que le worker. Limites de ressourcesOOM killerSwap
- Développement et production L'équipe développe avec docker compose up : le code est monté pour le rechargement à chaud et le débogueur Node.js écoute sur le port 9229. La production lance docker compose -f compose.yaml -f compose.prod.yaml up -d... et récupère le même montage et le débogueur ouvert. Rends la production propre sans casser l'environnement des développeurs. Fichiers de surcharge ComposeParité dev/prodMontages de dossier (bind mounts)
Avancé
Livrer via un registre, déployer sans coupure, garder journaux et disques sous contrôle, et mettre à jour des services avec état sans perdre de données.
- Livrer par le registre La production a toujours construit la boutique depuis les sources avec docker compose up --build, directement sur le serveur. Le nouveau serveur de production ne reçoit plus de code source : seulement compose.prod.yaml et .env. Construis la version 1.4.0 ici, sur le serveur de CI, publie-la dans le registre de l'entreprise, et fais tourner exactement ces images par compose.prod.yaml. Registres d'imagesTags d'imageConstruire une fois, déployer partout
- Le tag qui a bougé La semaine dernière, la boutique est tombée à 3 h 00. La tâche de nuit a tiré à nouveau registry.shop.internal/shop/api:1.4.0, et a reçu le back-office à la place : une chaîne de CI mal configurée avait poussé son image sous ce tag précis. L'API qui tourne en ce moment est la bonne. Fais en sorte que la tâche de nuit, et tout nouveau serveur construit à partir de ces fichiers, ne puissent démarrer que cette API exacte. Digests d'imagesRegistres d'imagesTags d'image
- Les journaux qui ont rempli le disque Deux fois ce mois-ci, la boutique a cessé de prendre des commandes en pleine nuit : PostgreSQL ne pouvait plus écrire car le disque était plein. docker system df ne montrait rien d'anormal. Le coupable est le service des webhooks de paiement, qui journalise au niveau debug pour une enquête en cours. Garde ces journaux, mais fais en sorte qu'aucun conteneur ne puisse plus jamais remplir le disque avec ses journaux. Rotation des journauxEspace disque de DockerJournaux de conteneur
- Bad Gateway après chaque livraison L'équipe livre l'API plusieurs fois par jour avec docker compose up -d --build. Après chaque livraison, la boutique répond 502 Bad Gateway, jusqu'à ce que quelqu'un redémarre le conteneur nginx à la main. L'API elle-même va bien : un curl depuis l'intérieur du réseau fonctionne. Fais en sorte que les livraisons cessent de casser la boutique. Proxys et adresses des conteneursRéseaux ComposeDocker Compose
- Tué en plein virement Le worker des virements envoie l'argent des vendeurs à la banque par lots. À chaque déploiement, docker compose attend dix secondes, puis le tue : certains virements partent deux fois, d'autres jamais, et la comptabilité rapproche tout à la main. Le worker sait déjà s'arrêter proprement quand il reçoit SIGTERM. Fais en sorte que chaque déploiement le laisse finir son lot. Arrêt propreProcessus principal (PID 1)CMD et ENTRYPOINT
- PostgreSQL 16 vers 17, toutes les commandes gardées La base de la boutique doit passer de PostgreSQL 16 à 17 ce soir. Le plan du ticket dit : changer le tag dans compose.yaml et lancer docker compose up -d. Fais la mise à jour de façon que chacune des 48 210 commandes soit toujours là ensuite, et que la boutique reprenne les commandes. Mettre à jour un conteneur de base de donnéesVolumesdocker exec
- Le jeton dans chaque image Le service de facturation installe @shop/invoice-pdf depuis le registre npm privé de l'entreprise, son build a donc besoin du NPM_TOKEN de la CI. Il est passé en argument de build, et un scan vient de trouver ce jeton dans l'historique de chaque image de facturation jamais poussée. Le jeton a été changé ; fais maintenant en sorte que les prochaines images ne portent pas le nouveau, tout en gardant l'installation du paquet privé. Secrets de buildGarder les secrets hors des imagesCouches d'image
- Verrouiller les conteneurs exposés Le test d'intrusion est revenu : par une faille dans une dépendance, les testeurs ont écrit un fichier dans le conteneur de l'API en marche, et ils relèvent que les deux conteneurs exposés à Internet gardent les capacités par défaut de Docker. Durcis frontend et api : un système de fichiers racine en lecture seule, toutes les capacités retirées, et aucun moyen d'obtenir de nouveaux privilèges. La boutique doit rester en ligne. Système de fichiers racine en lecture seuleCapacités LinuxNe pas tourner en root
Expert
Exploiter Docker Swarm sur plusieurs nœuds : services, mises à jour progressives, secrets, réseaux overlay et pannes de nœud.
- Seul le manager a l'image Le mois dernier, la boutique est passée d'un seul serveur à un Docker Swarm de trois nœuds. docker service ls indique que shop_api tourne en 3/3 et la boutique répond. Demain à 10 h 00, manager-1 est vidé (drain) pour son correctif de noyau, comme le prévoit RUNBOOK.md : ses tâches doivent partir sur les workers. Fais en sorte que la boutique survive à cette fenêtre de maintenance. Services et tâchesLe mode SwarmRegistres d'images
- Chaque version perd des requêtes La boutique tourne sur Docker Swarm, avec deux répliques de l'API, et pourtant chaque livraison casse le paiement pendant une minute environ. Aujourd'hui la CI livre la 1.5.0, qui met environ 25 secondes à démarrer, puis la 1.5.1 un peu plus tard. Rends les livraisons invisibles pour les clients : pas une seule requête en échec pendant le déploiement de la nouvelle version. Mises à jour progressivesHealthchecksRéseaux overlay et routing mesh
- La version qui avait l'air bonne Les livraisons ne perdent plus de requêtes : les healthchecks et start-first ont réglé ça. Mais le mois dernier, la 1.4.2 a convergé, tout le monde est rentré chez soi, et ses tâches ont planté toutes les quarante secondes toute la nuit (ops/postmortem-1.4.2.md). Aujourd'hui à 0 h 30, la CI livre la 1.6.0. Quelle que soit la qualité de la 1.6.0, la boutique doit finir sur une version qui marche, sans que personne ne tape de commande. Retour arrière automatiqueMises à jour progressivesHealthchecks
- Le mot de passe dans docker service inspect L'audit de sécurité est clair (security/audit-2026-10.md) : le mot de passe de la base est dans stack.yaml, dans docker service inspect et dans l'environnement de chaque conteneur. Fais-le sortir de tous ces endroits. Le mot de passe lui-même ne change pas aujourd'hui, et la boutique doit continuer à servir ses 48 210 commandes. Les secrets SwarmVariables d'environnementGarder les secrets hors des images
- La base de données qui a déménagé Mardi dernier, en préproduction, un worker a redémarré et toutes les commandes ont disparu, puis de nouvelles sont apparues de nulle part (ops/staging-incident.md). La production tourne avec le même stack.yaml, et 48 210 vraies commandes. Un nœud tombera un jour : ce jour-là, la boutique a le droit d'être indisponible tant que le nœud est absent (la réplication de la base est le projet du prochain trimestre), mais elle ne doit jamais perdre une commande. Contraintes de placementVolumesServices et tâches
- Deux managers, aucune majorité Le mois dernier, l'équipe a promu manager-2 pour que le cluster survive à la perte d'un manager. La supervision indique maintenant que l'alimentation de manager-1 va lâcher, et la pièce de rechange n'arrive que demain. Quand manager-1 tombera, le cluster doit continuer à se gérer seul : une tâche qui s'arrête doit toujours être remplacée. Prépare le cluster. Managers et quorumLe mode SwarmServices et tâches
Architecte
Concevoir une plateforme de conteneurs : sécurité de la chaîne d'approvisionnement, images multi-architectures, planification de capacité et exercices de reprise.
- Le miroir empoisonné Le compte de push de notre miroir d'images a fuité (security/advisory.md). Jusqu'à sa rotation à 3 h 00, n'importe qui peut écraser registry.shop.internal/mirror/node:20-alpine ou mirror/postgres:16 avec une copie piégée qui fonctionne parfaitement. Cette nuit, la tâche de nuit reconstruit et redéploie sur les dernières images du miroir. Fais en sorte qu'elle ne puisse utiliser que les images sur lesquelles tourne la boutique en ce moment, et qu'elle réussisse quand même. Digests d'imagesImages de baseRegistres d'images
- Les nœuds arm64 qui ne font rien Pour réduire les coûts, deux des trois workers sont maintenant des machines arm64 (ops/capacity.md). Sur le papier, le cluster tient largement les six répliques de l'API dont le Black Friday a besoin. Pourtant l'API ne tourne jamais que sur worker-1. À 0 h 30, la CI passe shop_api à 6 répliques : fais en sorte que les six tournent, sans surcharger aucun nœud. Images multi-plateformesContraintes de placementLimites de ressources
- De la capacité pour la campagne La campagne de la semaine prochaine double les répliques de l'API et de la recherche (ops/capacity-report.md). Le métier veut une promesse : perdre n'importe quel worker pendant la campagne ne doit ni ralentir la boutique ni retirer une réplique, et l'index de recherche ne doit jamais partir en swap. Planifie la capacité et fais en sorte que le cluster place ses tâches en conséquence. Planification de capacitéLimites de ressourcesSwap
- L'exercice de reprise Deux fois par an, un exercice reconstruit la boutique de zéro dans une autre région en exécutant recovery/restore.sh sur un cluster tout neuf, sans personne au clavier. Le runbook a été écrit pour l'ancienne installation Compose sur un seul serveur, et n'a jamais été testé depuis. Fais réussir l'exercice : moins de 15 minutes après le début, le nouveau cluster sert la boutique avec toutes les commandes de la sauvegarde de la nuit dernière. Exercices de reprise après sinistreLes secrets SwarmContraintes de placement