À la fin de cette page pilier, vous saurez pourquoi Docker reste le socle avant Kubernetes, expliquer container vs machine virtuelle, installer Docker Engine sur Ubuntu 24.04, lancer un premier conteneur, puis suivre le parcours images → Dockerfile → volumes → réseau → Compose → Swarm.

Niveau : Débutant → Intermédiaire · Temps estimé : 50–70 min · Versions cibles : Docker Engine 27+ · Compose v2 · Ubuntu 24.04 LTS · Dernière vérification : 2026-09-13

Prérequis

• Une machine Linux (Ubuntu 24.04 LTS recommandée) ou WSL2, avec sudo
• Notions de terminal et de Git
• (Optionnel) un projet Maven à packager plus tard — Maven Build Tool
• Coût estimé : 0 € en lab local

Ce hub absorbe le parcours live /docker/ (fondations, images, storage, Compose, Swarm) et le densifie en français pédagogique. Ce n’est pas un lab unique de 200 lignes : c’est la carte du menu Docker, avec un quickstart pour ne pas rester spectateur.

Ce que nous allons construire

Hub Docker (menu DevOps)
  ├── Pourquoi Docker en 2026 (packaging, pas « VM légère »)
  ├── Concepts : image, layers, container, registry
  ├── Quickstart Ubuntu 24.04 : install + premier nginx
  ├── Carte du parcours (leçons live)
  ├── Erreurs fréquentes + FAQ (5)
  └── Suite : Compose vs Kubernetes, puis le cluster

Étape 1 — Pourquoi Docker en 2026

Docker n’est pas « une VM légère ». C’est un outil de packaging et d’exécution : vous construisez une image (modèle en lecture seule), vous la lancez comme conteneur isolé, vous la composez en stack, puis vous l’orchestrez. En 2026, presque chaque pipeline DevOps (Jenkins, GitHub Actions, Azure Pipelines) produit une image ; Kubernetes ne fait qu’orchestrer ce que Docker (ou un runtime compatible) sait déjà exécuter.

Sans image reproductible, le Capstone banking et les jobs Jenkins deviennent du théâtre : « ça marche sur mon laptop ». Avec une image taguée, le même artefact part du laptop vers l’agent CI, puis vers la prod.

Idée reçue	Réalité 2026
Docker = petite machine virtuelle	Isolation processus + namespaces/cgroups, noyau partagé
Un Dockerfile suffit pour la prod	Il faut aussi registry, tags, scan, non-root, healthcheck
Swarm est mort, inutile de l’apprendre	Utile pour comprendre services/réplicas avant Kubernetes
Compose remplace Kubernetes	Compose = laptop / CI ; K8s = cluster et réconciliation

Choisir Docker d’abord si vous débutez. Ajouter Kubernetes ensuite, pas l’inverse. Le site a une page Compose vs Kubernetes pour trancher.

Étape 2 — Concepts : image, conteneur, layers, registry

Une image est un empilement de couches plus des métadonnées (commande par défaut, ports, utilisateur). Un conteneur est une instance avec une couche writable éphémère par-dessus. Un tag (comme nginx:1.27-alpine) est un pointeur humain ; le digest est l’empreinte immuable.

Le registry (Docker Hub, GitHub Container Registry, registre privé) stocke et sert les images. En équipe, vous poussez après le build CI et tirez en prod : vous ne reconstruisez pas « à la main » sur le serveur, sauf lab.

Analogie utile : l’image est la recette figée ; le conteneur est l’assiette servie. Jeter l’assiette (stop / rm) ne détruit pas la recette. C’est pour cela que les données durables vont dans un volume, pas dans le système de fichiers du conteneur.

Trois commandes de lecture avant d’écrire un Dockerfile :

• lister ce qui est déjà là ;
• inspecter une image officielle (historique des couches) ;
• lancer un process et le jeter pour vérifier le réseau.

Les leçons sœurs détaillent chaque brique : images, conteneurs, Dockerfile, registry, Docker Hub.

Étape 3 — Quickstart lab (Ubuntu 24.04)

Installez le moteur depuis le dépôt officiel (keyring moderne, pas l’ancienne méthode dépréciée), puis vérifiez le daemon.

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg 
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] 
  https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" 
  | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker "$USER"
docker version

Fermez et rouvrez la session pour le groupe docker. Premier conteneur :

docker run --rm -d --name lab-nginx -p 8080:80 nginx:1.27-alpine
curl -sS -o /dev/null -w "%{http_code}n" http://127.0.0.1:8080
docker logs lab-nginx --tail 20
docker stop lab-nginx

Attendu : code HTTP 200, logs nginx, puis conteneur arrêté et supprimé (--rm). Détail install : Installation Docker. Overview : Docker overview.

Mini Dockerfile de lab (à la racine d’un dépôt, jamais de secret en clair) :

FROM eclipse-temurin:17-jre-jammy
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
USER 10001
ENTRYPOINT ["java","-jar","/app/app.jar"]

Vous buildez après mvn -B package. C’est le pont Maven → Docker du menu DevOps.

Étape 4 — Storage, réseau, Compose, Swarm

Avant Compose, tenez deux sujets : persistance et communication. Un volume nommé survit au rm du conteneur. Un réseau utilisateur donne un DNS interne (le service web joint db par le nom). Leçons : storage, networking.

Compose v2 (plugin docker compose, plus l’ancien binaire v1) décrit une stack dans un seul YAML : services, réseaux, volumes, healthcheck. C’est l’outil du laptop et de beaucoup de jobs CI. Leçon : Docker Compose.

Swarm reste utile pédagogiquement : nœuds, services, replicas, stacks, backup. Vous y apprenez le vocabulaire d’orchestration sans encore installer etcd. Leçons : Swarm, setup, services, stacks, backup.

Carte du parcours Docker (liens live)

01 — Fondations

Pourquoi Docker, containers vs machines virtuelles, techno sous-jacente, installation et premier overview.

• Docker overview
• Containers et machines virtuelles
• Technologie sous-jacente
• Installation Docker

02 — Images et containers

Cycle de vie, images, Dockerfile, images custom, save/load, registry et Docker Hub.

• Docker containers
• Docker images
• Dockerfile
• Images custom
• Save / load images
• Docker registry
• Docker Hub

03 — Storage et networking

Persistance des données et communication entre containers — indispensable avant Compose.

• Docker storage
• Docker networking

04 — Compose et Swarm

Multi-services, puis cluster Swarm.

• Docker Compose
• Docker Swarm
• Swarm setup
• Swarm services
• Swarm stacks
• Swarm backup et restore

Suite logique : Kubernetes, Compose vs Kubernetes, cloud (AWS, Terraform). Hub parent : DevOps.

Habitudes qui rendent Docker tenable en équipe

Le quickstart suffit pour « voir un nginx ». L’équipe, elle, échoue souvent plus tard : tags flottants, images reconstruites sur le serveur, secrets copiés dans un fichier, couches qui explosent le temps de CI. Adoptez quatre habitudes dès le deuxième lab.

Premièrement, nommez ce que vous poussez. Un tag qui contient la branche et le numéro de build (ou le SHA Git court) permet de répondre à « quelle image tourne en staging ? » sans ouvrir le daemon. « latest » est un surnom de laptop, pas un contrat de production.

Deuxièmement, séparez build et run. Le stage CI compile (Maven, tests) puis construit l’image. La prod tire cette image. Rebuilder sur le serveur « parce que c’est plus simple » réintroduit le « ça marche chez moi » que Docker était censé tuer. Le registry n’est pas un luxe : c’est le bus entre Jenkins et la machine cible.

Troisièmement, traitez le Dockerfile comme du code lu en revue. Ordre des couches (dépendances avant sources), utilisateur non root, pas de tokens en clair, un healthcheck quand le process écoute HTTP. Une revue de Dockerfile évite plus d’incidents qu’un scan lancé trop tard.

Quatrièmement, nettoyez. Les images dangling et les caches de build remplissent le disque de l’agent. Un prune documenté (pas un rm -rf paniqué) fait partie du runbook Jenkins. Sur un lab Ubuntu, surveillez docker system df après une semaine de tests.

Ces habitudes se retrouvent dans le Capstone : image taguée à chaque changement, conteneur recréé, pas de secret dans le dépôt BankingMicroservice. Elles préparent aussi Kubernetes : un Deployment ne fait que réconcilier des images déjà saines.

Comment utiliser ce hub au quotidien

Lisez dans l’ordre 01 → 04 si vous construisez votre première base. Sinon, sautez à la leçon qui bloque votre journée : un volume qui disparaît, un réseau qui ne résout pas le nom, un Compose qui refuse de démarrer. Chaque lien de la carte pointe vers une page déjà publiée.

Sur mobile, privilégiez overview + installation + images avant Swarm. Socle recommandé : Linux. Ensuite le menu parent DevOps (Git → Maven → Docker → Kubernetes → Ansible → Jenkins → Capstone).

Vous n’avez pas besoin d’un cluster de production. Un laptop et une VM jetable suffisent. L’objectif n’est pas de « tout Docker » en un week-end : c’est de tenir un fil image → conteneur → stack → (plus tard) orchestrateur sans perdre les données ni les tags.

De l’image au pipeline (pont DevOps)

Docker n’existe pas tout seul dans ce site : il est le troisième module du menu après Git et Maven, et le prérequis de Kubernetes. Un commit Git propre sans image n’est qu’un historique. Un JAR Maven sans Dockerfile n’est qu’un artefact laptop. Une image sans tag de build n’est pas auditable. C’est pourquoi le hub insiste sur le registry et le même artefact du job Jenkins jusqu’à la machine cible.

Quand vous enchaînerez Jenkins, le stage Docker reprend exactement ce quickstart : build, tag, (plus tard) push. Quand vous enchaînerez le Capstone, le brief ABC demande une nouvelle image à chaque changement pertinent et un conteneur avec la dernière image — d’abord en lab, puis sur la prod Linux. Ansible installe Java et Apache à côté ; il ne remplace pas l’image.

Gardez une discipline simple : un Dockerfile à la racine du dépôt, un utilisateur non privilégié, aucun secret, un port documenté. Si vous devez expliquer Docker à un collègue en dix minutes, montrez ce hub, le premier nginx, puis la carte 01→04. Le reste est de la pratique, pas un autre manifeste marketing.

Erreurs fréquentes

Symptôme	Cause probable	Correction
permission denied socket Docker	Utilisateur hors groupe	usermod -aG docker puis nouvelle session
Image « latest » différente demain	Tag flottant	Épingler version + digest en prod
Données perdues après rm	Écriture dans le conteneur	Volume nommé ou bind mount documenté
Port déjà utilisé	Collision 8080 / 80	Autre hôte, ou docker ps pour voir qui écoute
Build lent / couche inutile	Mauvais ordre Dockerfile	Copier le manifeste des deps avant le code
CI verte, prod cassée	Rebuild sur le serveur	Registry + pull du même tag

FAQ

1. Faut-il apprendre Swarm avant Kubernetes ?
Non, ce n’est pas obligatoire. Swarm accélère le vocabulaire (service, replica, overlay). Si le temps manque, Compose puis le hub Kubernetes suffisent.

2. Docker Desktop ou Engine Linux ?
Pour ce parcours, Engine sur Ubuntu 24.04 (ou une VM) est le plus proche de la prod. Desktop convient en dépannage Windows/macOS.

3. Où mettre les secrets ?
Jamais dans l’image ni dans un commit. Fichiers hors dépôt, variables d’environnement injectées par CI, ou un coffre. Le Jenkinsfile du hub Jenkins montre withCredentials.

4. Compose suffit-il pour le Capstone ?
Pour un seul nœud, oui. Le Capstone demande surtout une image taguée et un conteneur. Kubernetes vient après, quand vous voulez réplicas et self-healing.

5. Pourquoi parler de registry.k8s.io plus tard ?
Quand vous passerez à Kubernetes, les images système officielles vivent sur ce registre, plus l’ancien nom déprécié. Docker Hub reste le registre des images applicatives de lab.

Points clés à retenir

• Docker package et exécute ; Kubernetes orchestre.
• Image (couches + tag) ≠ conteneur (instance éphémère).
• Install Ubuntu : dépôt officiel, groupe docker, premier nginx sur 8080.
• Parcours : fondations → images → storage/réseau → Compose → Swarm.
• En CI : même Dockerfile, tag de build, push registry — pas de rebuild artisanal en prod.

Pour aller plus loin

• Multi-stage Dockerfile et scan (Trivy) dans la leçon avancée du menu
• Non-root, read-only rootfs, healthcheck
• Pont vers Jenkins (stage Docker) et Capstone

Maillage série DevOps

← Connexe	Maven · Git
→ Suite	Kubernetes · Compose vs Kubernetes
Aussi	Jenkins · Ansible · DevOps

Ressources liées

• Docker Swarm Visualizer
• Docker Swarm Service Commands