Jour 1 · TP1 · Support détaillé participant

Lab 1 — Premiers conteneurs Docker

Étapes guidées, questions de vérification et corrigés dépliables — à votre rythme.

Durée indicative50 minutes
Pré-requisWSL2 + Docker Desktop opérationnels
ModeAutonomie, avec corrigés à dérouler
0

Vérifier votre environnement

Avant toute manipulation : s'assurer que Docker répond correctement depuis votre terminal WSL2.

# Dans un terminal WSL2 (Ubuntu)
$ docker --version
Résultat attendu Une ligne du type Docker version 26.x.x, build ... — peu importe le numéro exact, l'important est qu'aucune erreur ne s'affiche.
Si ça ne fonctionne pas Vérifiez que Docker Desktop est bien lancé (icône dans la barre des tâches Windows) et que l'intégration WSL2 est activée (Settings → Resources → WSL Integration). Si le problème persiste, signalez-le immédiatement plutôt que d'avancer seul.
1

Premier conteneur

Lancer un conteneur de test, puis un conteneur interactif avec un terminal à l'intérieur.

# Un conteneur de test, juste pour vérifier que Docker fonctionne
$ docker run hello-world

# Un conteneur interactif, avec un terminal à l'intérieur
$ docker run -it ubuntu bash
Résultat attendu Pour hello-world : un message de confirmation expliquant que Docker fonctionne correctement. Pour ubuntu bash : votre prompt change (il devient quelque chose comme root@a1b2c3d4:/#) — vous êtes maintenant à l'intérieur du conteneur.

Tapez exit pour sortir du conteneur et revenir à votre terminal habituel.

Question de vérification

Pourquoi votre prompt change-t-il quand vous entrez dans le conteneur Ubuntu ?

▸ Voir le corrigé
Corrigé Vous n'êtes plus dans le shell de votre machine WSL2, mais dans un shell qui s'exécute à l'intérieur du conteneur Ubuntu — un environnement isolé, avec son propre système de fichiers, ses propres processus, indépendant de votre machine hôte (même s'il en partage le noyau). Le changement de prompt est le signal visuel le plus simple que vous avez changé de contexte d'exécution.
2

Lister les conteneurs et les images

Distinguer ce qui est actif de ce qui existe en mémoire, et les images des conteneurs.

$ docker ps
# puis
$ docker ps -a
# puis
$ docker images
Résultat attendu docker ps : probablement une liste vide (vous n'avez plus de conteneur actif). docker ps -a : vous voyez apparaître hello-world et ubuntu, marqués "Exited". docker images : vous voyez les images hello-world et ubuntu téléchargées localement.
Question de vérification

Quelle est la différence entre une image et un conteneur ? Essayez de formuler votre propre réponse avant de dérouler le corrigé.

▸ Voir le corrigé
Corrigé Une image est un modèle figé, immuable — comparable à une recette de cuisine. Un conteneur est une instance en cours d'exécution (ou arrêtée) de cette image — le plat préparé à partir de la recette. On peut lancer plusieurs conteneurs différents à partir d'une seule et même image, exactement comme on peut cuisiner plusieurs plats à partir de la même recette.
3

Lancer un service concret et persistant

Lancer un vrai serveur web (nginx) en arrière-plan, et observer son résultat dans le navigateur.

$ docker run -d -p 8080:80 nginx

Ouvrez maintenant un navigateur et allez sur localhost:8080.

Résultat attendu La page d'accueil par défaut de nginx, avec le titre "Welcome to nginx!". C'est la première fois dans ce TP que vous voyez physiquement le résultat d'un conteneur dans votre navigateur.
Question de vérification

Dans la commande -p 8080:80, que représentent le nombre 8080 et le nombre 80 respectivement ?

▸ Voir le corrigé
Corrigé 8080 est le port de votre machine (l'hôte) — celui que vous tapez dans votre navigateur. 80 est le port à l'intérieur du conteneur, sur lequel nginx écoute par défaut (le port web standard). La syntaxe est toujours -p port_hôte:port_conteneur — c'est un mappage entre l'extérieur et l'intérieur du conteneur.
Piège fréquent Si vous obtenez une erreur "port already in use" (port déjà utilisé), c'est probablement qu'un autre conteneur tourne déjà sur ce port — passez à l'étape 4 pour vérifier avec docker ps, ou changez de port (par exemple -p 8081:80).
4

Explorer le conteneur en cours d'exécution

Consulter les logs et entrer dans un conteneur déjà démarré (sans le redémarrer).

# D'abord, repérez l'identifiant ou le nom de votre conteneur nginx
$ docker ps

# Puis consultez ses logs (remplacez <id> par l'ID ou le nom affiché)
$ docker logs <id>

# Et entrez dedans, sans l'arrêter
$ docker exec -it <id> bash
Résultat attendu Les logs affichent une ligne par requête HTTP reçue (notamment celle générée par votre navigateur à l'étape 3). Avec exec, vous obtenez un nouveau prompt, à l'intérieur du conteneur nginx déjà en cours d'exécution.
Question de vérification

Quelle différence essentielle entre docker run -it ubuntu bash (étape 1) et docker exec -it <id> bash (cette étape) ?

▸ Voir le corrigé
Corrigé docker run crée et démarre un nouveau conteneur à partir d'une image. docker exec entre dans un conteneur déjà existant et déjà en cours d'exécution, sans en créer un nouveau. C'est exactement ce que vous venez de faire avec votre conteneur nginx déjà lancé à l'étape 3 : vous n'avez pas créé un second nginx, vous êtes entré dans celui qui tournait déjà.
5

Nettoyer son environnement

Arrêter puis supprimer le conteneur nginx, pour repartir propre.

# Sortir du conteneur si vous y êtes encore (depuis l'étape 4)
$ exit

# Arrêter le conteneur
$ docker stop <id>

# Le supprimer
$ docker rm <id>

# Vérifier qu'il n'apparaît plus, même parmi les arrêtés
$ docker ps -a
Résultat attendu Le conteneur nginx n'apparaît plus du tout dans docker ps -a. Notez que l'image nginx, elle, reste présente dans docker images — supprimer un conteneur ne supprime pas l'image dont il provient.
Question de vérification

Si vous retapez docker run -d -p 8080:80 nginx maintenant, Docker doit-il retélécharger l'image depuis Internet ?

▸ Voir le corrigé
Corrigé Non. L'image nginx est déjà présente localement (visible dans docker images), donc Docker va directement créer un nouveau conteneur à partir de cette image déjà téléchargée, sans repasser par Internet. C'est ce qui rend le redémarrage d'un conteneur quasi instantané une fois l'image en cache localement.
À retenir de ce Lab

Ce que vous venez de manipuler

Gardez ce support sous la main : c'est la base à partir de laquelle vous pourrez construire votre propre mini-TP lors de l'atelier final du Jour 2.