- Cours pratique
- FSE
- Informatique
Formation Docker : Maîtriser Docker
Créer et administrer des conteneurs d'applications - Déployer, gérer et sécuriser les hôtes Docker

- Durée
- 5 jours
- Niveau
- Intermédiaire
- Modalités
- Présentiel / Distanciel
Description de la formation Docker

Objectifs pédagogiques
À l'issue de cette formation Docker : Maîtriser Docker, vous aurez acquis les connaissances nécessaires pour :
- Comprendre l'écosystème Docker et ses composants.
- Créer et administrer des conteneurs et des images, et les distribuer via des registres.
- Créer et gérer des volumes et des réseaux Docker.
- Déployer des applications multi-conteneurs avec Docker Compose.
- Sécuriser, optimiser et superviser des conteneurs en production.
- Comprendre les principes de l'orchestration et l'architecture de Kubernetes.
- Déployer, exposer et mettre à jour des applications sur Kubernetes.
- Gérer la configuration, les secrets, le stockage et les applications avec état.
- Déployer des applications complexes avec Helm et situer les outils de l'écosystème Kubernetes.
Objectifs opérationnels
Savoir créer, administrer et sécuriser des conteneurs Docker, puis déployer et exploiter des applications conteneurisées sur Kubernetes.
Programme
Contenu du cours, module par module
20 modules
- Virtualisation et conteneurs : différences et cas d'usage
- Docker dans la démarche DevOps et l'Infrastructure as Code
- Les mécanismes du noyau Linux : namespaces et cgroups
- L'écosystème : Docker Engine, containerd, runc, standard OCI, Docker Desktop, Compose, registres
Travaux pratiques
Description :Les participants installent Docker Engine et lancent leurs premiers conteneurs. Ils observent depuis l'hôte les processus et l'isolation mise en place par les namespaces. Ils comparent le temps de démarrage et l'empreinte d'un conteneur avec ceux d'une machine virtuelle. Qu'est-ce qui distingue fondamentalement un conteneur d'une machine virtuelle ? Un QCM rapide valide les acquis.
- Client, daemon et API Docker
- Images, couches et principe de la copie sur écriture
- Les options de docker run : ports, variables, ressources, redémarrage
- Inspecter, se connecter, consulter les logs, arrêter et supprimer un conteneur
Travaux pratiques
Description :Les participants déploient un serveur web conteneurisé avec différentes options d'exécution. Ils inspectent sa configuration, se connectent à l'intérieur et consultent ses logs. Ils configurent une politique de redémarrage automatique et la testent. Pourquoi un conteneur doit-il être considéré comme jetable ? La manipulation correcte de toutes les étapes du cycle de vie sert de validation.
- Nommage, tags et versions des images
- Pull, push, history et gestion du cache local
- Docker Hub et registre privé avec Harbor
- Créer une image depuis un conteneur, et pourquoi l'éviter
- Nettoyage des images et ressources inutilisées
Travaux pratiques
Description :Les participants récupèrent des images officielles et analysent leurs couches. Ils retaguent une image et la poussent vers un registre privé Harbor. Ils nettoient ensuite les images et ressources inutilisées de leur hôte. Quelle convention de tag permet de garantir la traçabilité des versions déployées ? L'image retrouvée et réutilisée depuis le registre valide l'exercice.
- Les instructions du Dockerfile : FROM, RUN, COPY, ENV, ARG, EXPOSE
- ENTRYPOINT et CMD : rôles et combinaisons
- Fichier .dockerignore et contexte de build
- Sondes de santé avec HEALTHCHECK
Travaux pratiques
Description :Les participants écrivent le Dockerfile d'une application web à partir de son code source. Ils paramètrent l'image avec des arguments de build et des variables d'environnement. Ils ajoutent une sonde de santé et vérifient son état. Quelle différence de comportement observe-t-on entre ENTRYPOINT et CMD ? L'application fonctionnelle dans son conteneur valide l'exercice.
- Les pilotes réseau : bridge, host, none, overlay
- Réseaux définis par l'utilisateur et résolution DNS interne
- Publication de ports et exposition des services
- Isolation et segmentation des communications entre conteneurs
Travaux pratiques
Description :Les participants créent plusieurs réseaux pour une application en trois tiers. Ils vérifient la résolution des noms entre conteneurs d'un même réseau. Ils confirment l'impossibilité de communiquer entre réseaux séparés. Pourquoi éviter le réseau bridge par défaut en production ? Les tests de connectivité attendus servent de validation.
- Le problème de la persistance dans les conteneurs
- Volumes, bind mounts et tmpfs : usages et différences
- Pilotes de volumes et stockage distant
- Sauvegarde, restauration et identification des volumes orphelins
Travaux pratiques
Description :Les participants déploient une base de données avec un volume nommé. Ils suppriment puis recréent le conteneur et vérifient la conservation des données. Ils sauvegardent le volume et le restaurent sur un nouveau conteneur. Dans quel cas un bind mount est-il préférable à un volume ? La restauration réussie des données valide l'exercice.
- Le format compose.yaml : services, réseaux, volumes
- Dépendances entre services et conditions de santé
- Commandes docker compose : démarrage, logs, mise à l'échelle, arrêt
- Mise à jour d'un service sans reconstruire la pile
Travaux pratiques
Description :Les participants décrivent une pile web, application et base de données dans un fichier Compose. Ils définissent les réseaux, les volumes et l'ordre de démarrage conditionné aux sondes de santé. Ils mettent à jour un service sans interrompre les autres. Comment garantir qu'un service ne démarre que lorsque sa base de données est prête ? La pile opérationnelle après mise à jour valide l'exercice.
- Variables, fichier .env et surcharge de configuration
- Profils et environnements multiples
- Gestion des secrets
- Construction d'images depuis Compose, labels et journalisation
Travaux pratiques
Description :Les participants externalisent la configuration de leur pile dans des variables et un fichier .env. Ils créent un profil de développement et un profil de production. Les mots de passe sont déplacés dans des secrets. Comment éviter qu'une information sensible se retrouve dans le dépôt Git ? Le déploiement de la même pile sur deux environnements valide l'exercice.
- Choisir ses images de base : officielles, minimales, distroless
- Exécuter avec un utilisateur non root
- Analyse du Dockerfile avec Hadolint
- Scan de vulnérabilités et SBOM avec Docker Scout et Trivy
- Signature et vérification des images
Travaux pratiques
Description :Les participants analysent le Dockerfile écrit le premier jour et en corrigent les mauvaises pratiques. Ils scannent l'image, interprètent les vulnérabilités détectées et changent d'image de base. Ils comparent le nombre de vulnérabilités avant et après correction. Quelle mesure réduit le plus la surface d'attaque d'une image ? Le rapport de scan final sans vulnérabilité critique valide l'exercice.
- Surface d'attaque : daemon, socket Docker, noyau partagé
- Mode rootless et remappage des utilisateurs
- Capabilities Linux, profils seccomp et AppArmor
- Système de fichiers en lecture seule et option no-new-privileges
- Bonnes pratiques d'administration de l'hôte Docker
Travaux pratiques
Description :Les participants tentent plusieurs actions dangereuses depuis un conteneur lancé avec ses droits par défaut. Ils retirent ensuite les capabilities inutiles, passent le système de fichiers en lecture seule et appliquent un profil seccomp. Ils rejouent les mêmes tentatives et constatent leur blocage. Pourquoi l'accès au socket Docker équivaut-il à un accès root sur l'hôte ? Le conteneur durci et toujours fonctionnel valide l'exercice.
- Builds multi-étapes et réduction de la taille des images
- Ordre des couches, cache de build et BuildKit
- Images multi-architectures avec buildx pour la portabilité
- Limites de CPU et de mémoire, pilote de stockage overlay2
Travaux pratiques
Description :Les participants transforment leur Dockerfile en build multi-étapes et réorganisent les couches pour exploiter le cache. Ils mesurent la taille de l'image et le temps de construction avant et après. Ils produisent une image pour deux architectures et fixent des limites de ressources. Quel gain de taille le build multi-étapes apporte-t-il sur l'application fil rouge ? La comparaison chiffrée avant et après optimisation valide l'exercice.
- Configuration du daemon Docker
- Pilotes de journalisation et centralisation des logs
- Supervision : docker stats, docker events, cAdvisor
- Limites de Docker seul et apport d'un orchestrateur : Swarm, Kubernetes
Travaux pratiques
Description :Les participants configurent le daemon avec un pilote de journalisation et une rotation des logs. Ils déploient cAdvisor et observent la consommation de leur pile Compose sous charge. Ils identifient un conteneur qui dépasse ses limites et corrigent sa configuration. À partir de quel moment Docker seul ne suffit-il plus et faut-il un orchestrateur ? Le tableau de bord de supervision opérationnel sert de validation.
- De Docker à l'orchestrateur : haute disponibilité, mise à l'échelle, auto-réparation
- Architecture d'un cluster : plan de contrôle, nœuds, kubelet, runtime containerd
- Le client kubectl et les manifestes YAML
- Namespaces et organisation des ressources
Travaux pratiques
Description :Les participants se connectent à leur cluster et explorent ses nœuds et ses composants. Ils créent un namespace de travail et y déploient une première ressource à partir d'un manifeste YAML. Ils comparent l'approche impérative et l'approche déclarative. Pourquoi l'approche déclarative est-elle privilégiée en production ? Un QCM rapide valide les acquis.
- Le pod, unité de déploiement : un ou plusieurs conteneurs
- Sondes de vivacité, de disponibilité et de démarrage
- Requêtes et limites de CPU et de mémoire
- Cycle de vie et redémarrage des pods
Travaux pratiques
Description :Les participants déploient sous forme de pod l'application conteneurisée pendant les trois premiers jours. Ils y ajoutent des sondes et des limites de ressources. Ils provoquent une défaillance et observent le redémarrage automatique. Quelle différence de comportement entre une sonde de vivacité et une sonde de disponibilité ? Le pod qui se rétablit seul valide l'exercice.
- La ressource Deployment et les ReplicaSets
- Réplication et mise à l'échelle des pods
- Mises à jour progressives, historique et retour arrière
- Stratégies de déploiement
Travaux pratiques
Description :Les participants transforment leur pod en Deployment répliqué. Ils augmentent puis réduisent le nombre de réplicas. Ils déploient une nouvelle version, observent la mise à jour progressive puis effectuent un retour arrière. Comment Kubernetes garantit-il la continuité de service pendant une mise à jour ? La mise à jour et le retour arrière réussis valident l'exercice.
- La ressource Service : ClusterIP, NodePort, LoadBalancer
- Découverte de services et DNS interne
- Exposition par URL avec les Ingress et les contrôleurs Traefik ou NGINX
- Communication entre applications au sein du cluster
Travaux pratiques
Description :Les participants exposent leur base de données en interne avec un service ClusterIP. Ils exposent ensuite l'application par NodePort, puis par une URL via un Ingress. Ils vérifient la répartition de charge entre les réplicas. Quel type de service choisir pour une application qui ne doit pas sortir du cluster ? L'accès à l'application par son URL valide l'exercice.
- ConfigMaps : externaliser la configuration
- Secrets : stocker les informations sensibles
- Injection par variables d'environnement ou par volumes
- Mise à jour de la configuration et redéploiement
Travaux pratiques
Description :Les participants externalisent la configuration de l'application dans une ConfigMap. Ils déplacent les identifiants de la base de données dans un Secret. Ils modifient ensuite la configuration et redéploient l'application. Pourquoi un Secret Kubernetes ne suffit-il pas à lui seul à protéger une donnée sensible ? L'application reconfigurée sans reconstruction d'image valide l'exercice.
- Volumes Kubernetes, PersistentVolumes et PersistentVolumeClaims
- Provisionnement dynamique avec les StorageClasses
- La ressource StatefulSet et les applications avec état
- Exemple d'une base PostgreSQL en cluster
Travaux pratiques
Description :Les participants créent une demande de stockage dynamique et l'associent à leur base de données. Ils redéploient la base sous forme de StatefulSet. Ils suppriment un pod et vérifient que les données sont conservées. Qu'apporte un StatefulSet par rapport à un Deployment pour une base de données ? La persistance des données vérifiée valide l'exercice.
- Le rôle de Helm : charts, valeurs et releases
- Installer, mettre à jour et désinstaller une release
- Dépôts de charts et réutilisation de charts publics
- Créer son propre chart
Travaux pratiques
Description :Les participants installent un chart public pour découvrir l'outil. Ils créent ensuite le chart de leur application à partir des manifestes de la formation. Ils le paramètrent pour deux environnements, puis effectuent une mise à jour et un retour arrière. Quel intérêt présente Helm par rapport à des manifestes appliqués un par un ? Le déploiement de l'application par son chart valide l'exercice.
- Panorama des projets de la CNCF
- Supervision avec Prometheus et Grafana
- Réseaux maillés avec Istio
- Stockage distribué avec Rook et Ceph
- Déploiement GitOps avec Argo CD
Travaux pratiques
Description :Les participants déploient Prometheus et Grafana avec Helm et observent les métriques de leur application. Le formateur présente en démonstration un réseau maillé Istio. Le groupe discute ensuite des briques de l'écosystème utiles à son propre contexte. Quel outil de l'écosystème apporterait le plus de valeur à votre production ? Le tableau de bord de supervision opérationnel clôture la formation.
Travaux pratiques
Travaux réalisés avec Docker Engine, Docker Compose, BuildKit, Harbor, Docker Scout et Trivy, puis sur un cluster Kubernetes avec kubectl, Helm, Prometheus et Grafana. Environ 60 % du temps est consacré aux travaux pratiques.
Programme mis à jour le 11/12/2023
Public concerné
Ingénieurs DevOps, administrateurs, responsables de production, architectes et développeurs souhaitant maîtriser Docker et franchir le pas de l'orchestration avec Kubernetes.

Prérequis
Une pratique de la ligne de commande Linux est nécessaire, car tous les travaux pratiques se font avec les CLI Docker et kubectl. Une connaissance de Git et des bases de la démarche DevOps permet de situer les conteneurs dans la chaîne de livraison. Aucune expérience préalable de Docker ou de Kubernetes n'est requise.
J’évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Faire le testFinancement
Cette formation peut être prise en charge par votre entreprise, seule ou avec l’appui de son opérateur de compétences. Nous fournissons le devis et les pièces attendues par l’OPCO.
4,8/5
20 avis
« Mon avis sur le contenu du stage : "J'ai trouvé que l'on a rapidement fait le tour de Docker et de son écosystème, et qu'on a finalement passé plus de temps sur Kubernetes. J'en ai parfaitement compris la raison : c'est vraiment le présent et l'avenir des containers en production. Cependant je pense qu'il faudrait mettre à jour le descriptif de la formation pour coller à ce que nous avons réellement fait." Mon avis sur le formateur : "Formateur très intéressant, pertinent, et les exercices étaient variés. Tous les exercices étaient très guidés. Peut-être manque-t-il un exercice "final" où l'on aurait tout à faire de A à Z, en reprenant les notions (et certainement des portions de code) déjà abordés dans les exercices précédents ?" Ce que j'ai le plus apprécié : "La pratique des exercices et les échanges avec le formateur. Vraiment top." Ce que j'ai le moins apprécié : "Lors de démonstrations, il est arrivé que des fichiers manquent, mais rien de bloquant : on avait le temps de faire les choses tranquillement. Tout petit bémol." »
COUPE Christophe « Mon avis sur le contenu du stage : "Tous les éléments nécessaires à la prise en main et à l'utilisation de Docker ont été abordés et détaillés en pratique." Mon avis sur le formateur : "Animateur qui maîtrise parfaitement son sujet et sait aborder les différents points avec pédagogie." Ce que j'ai le plus apprécié : "Tout le nécessaire a été communiqué suffisamment en avance avant la formation, et tous les outils et accès étaient opérationnels le jour J." Ce que j'ai le moins apprécié : "Dans un monde idéal, un mail unique avant la formation contenant toutes les infos serait encore mieux." »
BL « Mon avis sur le formateur : "Très bonnes connaissances et adaptation constante aux besoins spécifiques" Mon avis sur la salle de formation : "Note : la formation s'est déroulée dans nos propres locaux. Les petits soucis rencontrés (qualité du réseau, température de la salle) sont uniquement locaux." Ce que j'ai le plus apprécié : "Préparation en avance de phase des machines de tests individuelles, accessibles à distance. Très très pratique" Ce que j'ai le moins apprécié : "n/a" »
LONCAN MartineBULL SAS
Les avis figurant ci-dessus sont issus des fiches d’évaluation que remplissent les participants à la fin de la formation. Ils sont ensuite publiés automatiquement si les personnes ont explicitement accepté que nous les diffusions.
Formations liées
- Docker avancé : déployer ses conteneurs sur KubernetesRéf. UDMB2 joursAvancéProchaine session : 10 déc.1 590 €
- Gestion des conteneurs avec PodmanRéf. GDCP3 joursFondamentalProchaine session : 23 nov.2 090 €
- Kubernetes : Utilisation AvancéeRéf. KUAA2 joursIntermédiaireProchaine session : 19 nov.1 700 €
- Kubernetes mise en œuvre Réf. KTOC2 joursIntermédiaireProchaine session : 26 nov.1 590 €