Laboratoires · Application conteneurisée

Le scénario

La petite entreprise emballe son site

La petite entreprise vient de mettre son site en ligne : un WordPress installé à la main, hérité du cours de serveur. Il fonctionne, mais il vit sans armure sur sa machine : fragile, impossible à déplacer, impossible à cloner. Pendant que les visiteurs se multiplient, l'entreprise apprend le geste fondateur du métier : emballer l'application dans des conteneurs, la décrire dans une partition, puis la faire jouer par tout un essaim de machines.

Ces laboratoires suivent la même application à travers trois déploiements : un seul conteneur, un conteneur par service, puis un essaim. La même application, de plus en plus solide.

Votre mission

La même application, trois déploiements

1

WordPress et MySQL sur un seul conteneur

➜

2

Un conteneur par service, avec Docker Compose

➜

3

WordPress répliqué sur un Docker Swarm

➜

+

Expérimentation : un conteneur from scratch

À chaque étape, la preuve vivante est la même : votre WordPress répond dans le navigateur de la machine hôte, avec un article illustré publié dedans.

Nouveau cette année

Vos instances, votre choix d'infrastructure

Chaque noeud de ces laboratoires est une instance. Vous choisissez le substrat qui la fournit, au lieu que VirtualBox soit imposé :

Machines virtuelles VirtualBox

La voie de référence : cloner UbuntuServerAlpha en DockerAlpha (Ubuntu Server, 2 Go de mémoire vive, 12 Go de disque) et y installer Docker et Docker Compose. Hors ligne et gratuit; le plan d'adressage historique s'applique tel quel.

Conteneurs DinD

Docker dans Docker : chaque noeud est un conteneur sur votre machine. Léger, rapide, gratuit, hors ligne. Idéal si votre poste manque de mémoire vive pour cinq machines virtuelles.

VPS infonuagiques

De vrais serveurs loués à l'heure (Linode), dans la même région, clés SSH et pare-feu obligatoires (ports de l'essaim 2377, 7946 et 4789 restreints à vos noeuds). Le plus authentique, pour quelques cents l'heure.

Le TP est exactement le même dans les trois cas : mêmes gestes Docker, mêmes livrables, même évaluation. L'orchestrateur se moque du substrat, c'est d'ailleurs une leçon du cours.
Le choix pèse surtout au laboratoire 3 : l'essaim demande cinq noeuds.
Justifiez votre choix en quelques phrases dans le README.md (coût, mémoire disponible, réalisme, dépendance au réseau). Analyser avant de monter, c'est déjà le métier.

Option VPS : des instances qui dorment coûtent des sous. « Conserver ses instances » signifie alors : être capable de les recréer et de les reconfigurer en quelques minutes par script, grâce aux configurations gardées dans Git. À la démonstration, vous devez pouvoir relever l'ensemble rapidement, devant témoin. Détruisez vos instances en fin de séance.

Le matériel

Environnement informatique

Toutes les activités se réalisent avec votre propre ordinateur Linux : Kubuntu 24.04 ou Debian 12 avec KDE.
Les outils suivants doivent être installés : un navigateur (Chrome, Brave ou Firefox), Konsole et Dolphin.
Chaque étudiante dispose d'un compte Linode (ou OVH ou Hetzner) en règle pour le déploiement.
Le noyau Linux 6.17 doit être en markhold. C'est le noyau 6.14 qui est obligatoire pour le projet (jusqu'à indication contraire) et la commande de mise à jour (sudo apt update && sudo apt upgrade) doit passer sans erreur ni forcer l'installation du nouveau noyau.

La VM de référence : UbuntuServerAlpha, clonée en DockerAlpha (2 Go de mémoire, 12 Go de disque).
Clonage permis pour sauver du temps : nouvelle adresse MAC, nouveau nom d'hôte, nouvelle adresse IP.

Les règles du jeu

Le processus de travail

Le travail se réalise en laboratoire présentiel. Le laboratoire sert exclusivement aux activités du cours (pas d'autres devoirs ou activités pendant ces séances). Toute autre activité doit se faire à l'extérieur du local.
La majorité du laboratoire se réalise dans la séance de 4h, environ 80% du travail.
Si tu es bloqué(e) ou en difficulté, tu dois demander de l'aide PENDANT la séance du bon laboratoire.
Tu as ensuite 7 jours pour finaliser ta remise.
Chaque étudiant remet une solution originale, différente de celles des autres étudiants, qu'il maîtrise.
Utilisation de l'IA en chatbot web est permise mais l'étudiant doit rédiger ses propres scripts.

Les règles du jeu

Remise et Examen pratique

versionnement dockerfile ligne par ligne dans l'ordre de developpement

L'ordre n'est pas l'ordre des lignes (ex: lignes de test qui disparaissent)

La remise

Remise individuelle, incrémentale, d'une solution originale (différente des autres).
7 jours au maximum pour finaliser la remise de chaque labo, AVANT le labo suivant.
L'examen pratique est obligatoire pour recevoir une note.

L'examen pratique

Les instances sont fonctionnelles AVANT l'examen pratique.
Chaque ligne devra pouvoir être expliquée sur demande.
Des modifications seront demandées au moment de l'examen pratique.

⚠️ Note de 0 % si on ne te voit pas travailler sur chaque labo et bien l'expliquer !

Travailler avec l'IA

Utilisation de l'IA

⚠️ Note de 0 % si on ne te voit pas travailler sur chaque labo et bien l'expliquer !

Bonne utilisation

Demander des explications sur les concepts du cours.
Demander des exemples de scripts similaires.
Demander des explications d'exemples typiques.
Copier-coller à l'IA des messages d'erreur pour aider à résoudre des problèmes.

Mauvaise utilisation

Copier-coller de grandes sections de script dans son travail et tenter de l'utiliser tel quel.

La bonne méthode : vous pouvez copier une seule ligne de configuration à la fois fournie par une IA, la tester, et faire un commit de chaque ligne.

Signes que tu utilises mal l'IA

Ne pas participer au laboratoire ou faire autre chose pendant le labo.
Absences aux laboratoires et vouloir faire les travaux à la maison.
Refus ou incapacité de subir l'examen pratique.

Structure attendue

Architecture de remise

Votre dépôt Git doit respecter scrupuleusement l'arborescence suivante :

📁 votre-depot-git/

├── 📄 README.md

├── 📁 docker/

│ ├── 📄 Dockerfile

│ └── 📄 README.md

├── 📁 compose/

│ ├── 📄 Dockerfile

│ └── 📄 README.md

└── 📁 swarm/

├── 📄 Dockerfile

└── 📄 README.md

Les 3 dossiers docker/, compose/, et swarm/ correspondent aux laboratoires.
Un fichier Dockerfile et un fichier README.md sont exigés dans chaque dossier.
Le README.md à la racine sert de présentation globale.

Laboratoire 1 · Semaine 2

WordPress et MySQL sur un seul conteneur

4 points Tutoriel : diaporama et guide du laboratoire

Mettre en place, en fonction du matériel de cours, une instance (VirtualBox de référence : DockerAlpha, clone d'UbuntuServerAlpha avec Docker et Docker Compose, 2 Go de mémoire vive, 12 Go de disque) où la boutique de Cornucopia renaît dans une image LAMP maison, construite depuis l'image officielle PHP, en quatre étapes :

SERVEUR : construire l'image LAMP à partir de php:8.2-apache, MariaDB ajouté à la main, script de démarrage maison.
SITE : redéployer le site de cornucopia.projet.autos (fichiers et base de données), déposer Adminer pour inspecter la base.
LIEN : constater la perte des données à la destruction du conteneur, puis la corriger avec un volume.
CHARGE : tester la tenue en charge avec JMeter.

Suivre le diaporama du laboratoire et son guide pas-à-pas.

Barème :

SERVEUR : l'image LAMP maison se construit, une page web du conteneur s'ouvre depuis la machine hôte (1 point)
SITE : la boutique de Cornucopia est redéployée, tableau de bord et Adminer accessibles (1 point)
LIEN : un article ajouté survit à la destruction et à la recréation du conteneur (1 point)
CHARGE : rapport JMeter contre le conteneur (1 point)

🧺 Télécharger la sauvegarde Cornucopia (code + SQL + README)

Laboratoire 2 · Semaine 3

WordPress avec un conteneur par service

10 points Docker Compose Tutoriel : diaporama et laboratoire de la semaine 3

Sur une instance aux mêmes caractéristiques, installer WordPress avec un conteneur par service : un service HTTP et un service MySQL, décrits dans un fichier docker-compose.yml (ports 8082 et 8083 pour phpMyAdmin, volumes de données, réseau interne).

Barème :

Installation de Docker Compose (1 point)
Création d'un répertoire pour la configuration de WordPress avec Docker Compose (1 point)
Configuration de Docker Compose pour WordPress (1 point)
Exécution de WordPress avec Docker Compose (1 point)
Accéder à votre serveur WordPress à partir de votre machine hôte (1 point)
Ajout d'un article et d'une illustration dans WordPress sur Docker Compose (4 points)
Arrêter et redémarrer WordPress sur Docker Compose et visualiser le nouvel article illustré (1 point)

Laboratoire 3 · Semaine 4

WordPress sur un Docker Swarm

10 points 5 noeuds Tutoriel : diaporama et laboratoire de la semaine 4

Préparer cinq noeuds selon votre choix d'infrastructure, nommés swarm-node01 à swarm-node05. Référence VirtualBox : cinq clones de DockerAlpha (2 Go, 12 Go) avec les adresses 192.168.56.10, .20, .30, .40 et .50, les noms d'hôtes et le fichier hosts ajustés sur chaque machine. En DinD ou VPS : cinq noeuds équivalents, plan d'adressage documenté dans le README.md.

Créer le cluster Docker Swarm (init, join) et un réseau interne overlay.
Lancer le proxy inverse Traefik.
Lancer WordPress (service web répliqué, base MySQL ancrée).
Afficher l'essaim dans le visualiseur.

Barème (état affiché dans le visualiseur) :

1 conteneur Traefik (2 points)
3 conteneurs WordPress (2 points)
1 conteneur MySQL (2 points)
1 conteneur Visualiseur (2 points)
Ajouter un article avec une image et l'afficher dans le navigateur (2 points)

Les instructions détaillées sont répétées dans le tutoriel : respectez-les à la lettre, surtout l'adressage. Le premier déploiement peut être long (téléchargement des images sur chaque noeud); les journaux vous disent où ça en est.

Expérimentation · Semaine 1 · En classe

Conteneurs from scratch

Semaine 1 1 point Une période de 4 heures

C'est le laboratoire du premier jour, avant Docker : on construit soi-même ce que Docker automatisera. La présence en classe pour le réaliser sur une seule période de travail (4 heures) est évaluée seulement. Le fonctionnement correct final est souhaitable, mais pas nécessaire.

Mettre en place un conteneur from scratch (à la main, sans Docker : prison chroot, montages, isolation) qui permet d'exécuter une commande simple autre que nano.
Suivre le diaporama laboratoire de la semaine 1 : il reprend le tutoriel jusqu'à la diapositive 67 seulement (la fermeture du conteneur).

C'est l'occasion de voir ce que Docker fait pour vous : après avoir monté une prison à la main, docker run ne sera plus jamais magique.

Semaine 5

La démonstration

En classe, à la semaine 5, chaque étudiant :

fait la démonstration de chaque laboratoire sur son poste de travail : les trois déploiements répondent, l'article illustré s'affiche;
présente ses configurations conservées dans Git;
peut expliquer chaque commande utilisée : l'IA a pu aider, mais c'est votre tête qui répond.

Rappel : la démonstration est nécessaire à la correction. Une partie non démontrée n'est pas évaluée.

La grille

Récapitulatif des points

Laboratoire	Points
1 · WordPress et MySQL sur un seul conteneur	4
2 · WordPress avec un conteneur par service (Compose)	10
3 · WordPress sur un Docker Swarm	10
Expérimentation · Conteneurs from scratch	1

Total : 25 points · 25 % de la session