Accueil/Réseaux, Systèmes & Cybersécurité /Chapitre 19 /TP — bonus

WSL Containers — le TP

Dix-sept questions à faire sur un PC Windows. Les corrections donnent la commande et ce qu'elle doit produire. Le cours · La fiche

⚠️ Il faut un poste Windows

wslc est un composant de Windows. Sur un Mac ou un serveur Linux, faites plutôt le TP du chapitre 18 : les notions sont les mêmes, et c'est celui qui est au programme.

Les corrections viennent de la documentation de Microsoft, relevée le 14 octobre 2026. L'outil est récent : si votre machine répond autre chose, c'est elle qui a raison. Notez l'écart, il vaut la peine d'être signalé.

1Mettre en place

1Savoir si la machine est prête Facile

1.1 Dans PowerShell, afficher la version de WSL installée. Est-elle suffisante pour les conteneurs ?

1.2 Mettre WSL à jour, puis redémarrer le PC.

1.3 Vérifier que le moteur de conteneurs répond.

✅ Correction

powershell

wsl --version
wsl --update
wslc version

Il faut WSL 2.9.3 au minimum. La version stable publiée fin septembre 2026 porte le numéro 3.0.1 ; les deux chiffres circulent et ne se contredisent pas — 2.9.3 est le plancher annoncé par Microsoft, 3.0.1 est ce qu'on installe aujourd'hui.

wsl --version dit si la commande est là. wslc version dit si le moteur de conteneurs répond : c'est celui-ci qui compte, exactement comme docker info au chapitre 18.

2Si WSL n'a jamais été installé Facile

2.1 Quelle commande installe WSL, et dans quelle condition particulière faut-il la lancer ?

2.2 Un camarade a tapé la commande, elle a échoué, et il n'y a aucun message clair. Quelle est la cause la plus probable, et où se règle-t-elle ?

✅ Correction

powershell

wsl --install     # dans une console OUVERTE EN ADMINISTRATEUR

2.2 La virtualisation désactivée dans le BIOS/UEFI. WSL 2 fait tourner un vrai noyau Linux dans une machine virtuelle légère : sans le support matériel, rien ne démarre.

Et cela ne se règle pas depuis Windows : il faut redémarrer, entrer dans le BIOS, et activer VT-x (Intel) ou SVM (AMD). C'est le blocage le plus fréquent en salle de TP.

3Se débrouiller seul Moyen

3.1 Afficher la liste de toutes les commandes de wslc.

3.2 Afficher le détail d'une seule d'entre elles, run.

3.3 Pourquoi cette habitude est-elle plus importante ici que pour un outil ancien ?

✅ Correction

powershell

wslc --help
wslc run --help

3.3 Parce que l'outil a quelques semaines. wslc --help est plus récent que ce cours, plus récent que n'importe quel tutoriel et que n'importe quelle vidéo : il décrit la version installée sur votre machine, pas celle d'il y a un mois.

2Le premier conteneur

4Hello world Facile

4.1 Lancer un conteneur jetable à partir de l'image hello-world.

4.2 Énumérer, dans l'ordre, les quatre choses qui se passent.

4.3 Relancer la même commande. Pourquoi est-ce bien plus rapide ?

✅ Correction

powershell

wslc run --rm hello-world

4.2 L'image est téléchargée (elle n'est pas là) → un conteneur est créé → il est démarré, affiche son message et son processus se termine → --rm le détruit.

4.3 L'image est maintenant en cache local : la première exécution était presque entièrement du téléchargement. Un conteneur démarre, lui, en quelques dizaines de millisecondes.

5Un conteneur qui fait quelque chose Facile

5.1 Lancer une commande echo dans un conteneur Ubuntu jetable, avec un terminal.

5.2 Que fait chacune des options employées ?

✅ Correction

powershell

wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"

`--rm`	détruire le conteneur à la sortie
`-i`	garder l'entrée standard ouverte
`-t`	allouer un terminal
`ubuntu:latest`	l'image et son tag
`bash -c "…"`	ce qu'on exécute dans le conteneur

-i et -t vont presque toujours ensemble : un terminal sans entrée ne sert à rien.

6Le tag Moyen

6.1 Que vaut ubuntu sans tag ?

6.2 Pourquoi latest est-il un mauvais choix pour un serveur qui doit se comporter pareil dans six mois ?

✅ Correction

6.1 ubuntu vaut ubuntu:latest : sans tag, c'est latest qui est pris.

6.2 Parce que latest n'est pas une version : c'est une étiquette, et l'auteur de l'image la déplace à chaque publication. La même commande peut donc donner deux images différentes à six mois d'écart.

Très bien pour essayer. Très mauvais en production, où l'on écrit le numéro.

3Un serveur web

7Publier un port Moyen

7.1 Lancer nginx en arrière-plan, sous le nom web, joignable depuis Windows sur le port 8080.

7.2 Vérifier qu'il répond, sans ouvrir de navigateur.

7.3 Justifier l'ordre des deux nombres de -p.

✅ Correction

powershell

wslc run -d --rm -p 8080:80 --name web nginx
curl localhost:8080

7.3 -p 8080:80 se lit hôte : conteneur. Le 8080 de la machine mène au 80 du conteneur, où nginx écoute.

Moyen de ne plus se tromper : on écrit en premier l'adresse qu'on va taper. localhost:8080 → -p 8080:…

8Voir ce qui tourne Facile

8.1 Lister les conteneurs en cours d'exécution.

8.2 Lister aussi ceux qui sont arrêtés.

8.3 Lire ce que le conteneur web a écrit.

✅ Correction

powershell

wslc container list
wslc container list --all
wslc container logs web

Équivalents Docker : docker ps, docker ps -a, docker logs web.

9Entrer dans le conteneur Moyen

9.1 Afficher, depuis le conteneur web, le contenu de /etc/os-release. Sur quelle distribution l'image nginx est-elle bâtie ?

9.2 Ouvrir un shell interactif dans ce même conteneur.

9.3 Un camarade tape wslc run -it nginx bash pour « entrer dans son serveur ». Que se passe-t-il réellement ?

✅ Correction

powershell

wslc exec web cat /etc/os-release
wslc exec -it web bash

9.3 run crée un deuxième conteneur, tout neuf, à partir de l'image. Il n'a aucun des fichiers ni aucune des modifications du premier, et il ne publie aucun port. On cherche alors longtemps pourquoi « son » serveur est vide.

La règle : run part d'une image, exec entre dans un conteneur.

10Arrêter proprement Facile

10.1 Arrêter le conteneur web.

10.2 Le retrouver dans la liste. Pourquoi n'y est-il pas ?

✅ Correction

powershell

wslc container stop web
wslc container list --all

10.2 Il avait été lancé avec --rm : il a donc été détruit en s'arrêtant, et il n'apparaît même pas dans --all. Sans --rm, il y serait, à l'état arrêté.

4Construire son image

11Écrire le Containerfile Moyen

11.1 Écrire un Containerfile pour une application Python qui part de l'image python:3, travaille dans /app, installe ses dépendances depuis requirements.txt, copie le projet, annonce le port 8000 et lance le serveur Django.

11.2 Pourquoi copier requirements.txt avant le reste du projet ?

✅ Correction

dockerfile

FROM python:3
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

11.2 Pour le cache de construction. Chaque ligne produit une couche réutilisée tant que ce qu'elle copie n'a pas changé. En copiant d'abord le seul requirements.txt, l'installation des dépendances — la ligne la plus lente — n'est refaite que si les dépendances changent. Copier tout le projet d'abord la referait à chaque virgule modifiée dans le code.

12Construire et lancer Moyen

12.1 Construire l'image sous le nom helloworld-django, depuis le dossier du projet.

12.2 Vérifier qu'elle est bien là.

12.3 La lancer en arrière-plan sur le port 8000, sous le nom django, et lire ses journaux.

12.4 Prouver, en une commande, que le programme tourne bien sur un noyau Linux.

✅ Correction

powershell

wslc build -t helloworld-django .
wslc image list
wslc run -d --rm -p 8000:8000 --name django helloworld-django
wslc container logs django
wslc exec django uname

12.4 wslc exec django uname répond Linux. C'est la preuve la plus courte : on est sous Windows, on n'a installé aucun moteur de conteneurs, et le programme s'exécute pourtant sur le noyau Linux de WSL 2.

Le point final de wslc build -t nom . est le contexte : le dossier qui contient le Containerfile et les fichiers à copier. L'oublier est l'erreur classique.

13RUN, CMD et EXPOSE Exigeant

13.1 Un camarade a écrit RUN python manage.py runserver à la place du CMD. Que produit sa construction, et que fait son conteneur au démarrage ?

13.2 Il a aussi retiré le -p en disant qu' EXPOSE 8000 suffit. A-t-il raison ?

13.3 Où faut-il ranger les fichiers du projet, et pourquoi ?

✅ Correction

13.1 RUN s'exécute pendant la construction. Le serveur démarrerait donc au milieu du build — et comme il ne rend jamais la main, la construction resterait bloquée. Et quand bien même elle aboutirait : l'image n'aurait aucun CMD, donc le conteneur ne lancerait rien au démarrage.

13.2 Non. EXPOSE documente le port : c'est une indication écrite dans l'image, lisible par les humains et les outils. Elle ne publie rien. Seul -p ouvre réellement le passage vers la machine hôte.

13.3 Du côté Linux (\\wsl$), pas sur le disque Windows. Les deux mondes se voient, mais chaque accès traverse une passerelle — et un build lit des milliers de fichiers. Microsoft le recommande explicitement.

5Surveiller et nettoyer

14Regarder travailler le moteur Moyen

14.1 Ouvrir une seconde console et y lancer le journal des événements. Dans la première, relancer wslc run --rm hello-world.

14.2 Quelles étapes voit-on défiler ?

14.3 Afficher la consommation des conteneurs en cours, puis l'état général de l'environnement.

✅ Correction

powershell

wslc events          # console de gauche, on la laisse tourner
wslc stats
wslc system info

14.2 La séquence complète d'un conteneur jetable : création → connexion au réseau → démarrage → arrêt → déconnexion du réseau → destruction. La dernière étape n'est là que parce qu'on a mis --rm.

C'est le meilleur exercice du TP : la liste des événements explique le cycle de vie d'un conteneur mieux qu'un paragraphe.

15Reprendre de la place Facile

15.1 Supprimer tous les conteneurs arrêtés, puis toutes les images que plus aucun conteneur n'emploie.

15.2 Des deux, laquelle libère le plus d'espace ?

✅ Correction

powershell

wslc container prune
wslc image prune

15.2 Les images, de très loin. Un conteneur arrêté ne pèse que sa couche d'écriture — souvent quelques kilooctets. Une image python:3 pèse plusieurs centaines de mégaoctets, et une dizaine d'essais occupent déjà un gigaoctet.

6Traduire du Docker

16Six lignes à transposer Moyen

Réécrire ces commandes Docker en wslc :

bash

docker run --rm -it alpine sh
docker ps -a
docker images
docker exec -it api bash
docker logs api
docker build -t monapi .

✅ Correction

powershell

wslc run --rm -it alpine sh
wslc container list --all
wslc image list
wslc exec -it api bash
wslc container logs api
wslc build -t monapi .

Les options ne changent pas : --rm, -it, -d, -p, -t se lisent pareil. Ce qui change, c'est que wslc met l'objet avant le verbe — container list, container logs — là où Docker accepte ses raccourcis historiques ps et images.

C'est en réalité la forme moderne de Docker, celle que sa propre documentation recommande. Prenez l'habitude de docker container ls et docker image ls : les deux outils vous obéiront.

17Savoir quoi en dire Exigeant

17.1 En entretien, on vous demande pourquoi une entreprise sous Windows regarderait wslc. Donner trois arguments.

17.2 On vous demande ensuite pourquoi cela ne remplace pas Docker. Donner trois limites.

17.3 Que répondre à « c'est au programme du BTS ? »

✅ Correction

17.1 Rien à installer — c'est un composant de Windows, donc rien à déployer ni à maintenir sur un parc. Pas de licence à acheter au-delà d'une certaine taille d'entreprise. Mêmes images et presque même syntaxe : les compétences et les fichiers existants se transposent.

17.2 Windows seulement : sur un Mac ou un serveur Linux, il faut autre chose. Pas d'interface graphique. L'écosystème — tutoriels, intégration continue, extensions d'éditeur — parle encore docker, et la traduction se fait à la main.

17.3 Non, et c'est assumé : ce chapitre est un bonus. La bonne réponse est « Docker est ce que j'apprends, wslc est ce que je surveille » — elle montre qu'on sait distinguer ce qui est établi de ce qui est nouveau, ce qui vaut mieux que de citer un outil de trois semaines comme s'il était un standard.