Laboratoires
Application
distribuée

Quatre laboratoires et une démonstration pour faire passer le site de Cornucopia du simple serveur à la grappe qui ne tombe jamais.

Cornucopia passe à l'échelle régionale

Le site de Cornucopia a bien résisté au Module 1 : conteneurisé, composé, essaimé, sauvegardé. Mais l'expansion régionale bat son plein : dix mille visiteurs et des milliers de paniers personnalisés pointent à l'horizon, et une seule machine ne suffit plus.

Flora et Hazel doivent se résoudre à grandir en largeur : séparer le web et la base de données, mettre en cache Varnish, balancer avec HAProxy, doubler les points de faille avec des IP virtuelles, et prouver chaque étage avec un vrai test de charge.

Un étage à la fois, chiffres à l'appui

La boutique de Cornucopia respire sur son unique instance quand le guide des semis gratuit de Flora devient viral : 500 000 visiteurs par jour, chaque page recalculée pour rien - un cache s'impose. Puis la Guilde des Jardiniers réclame ses pages personnalisées, que le cache ne sait pas servir : un million de requêtes frappent la base de données - on sépare les services pour mesurer et soulager. La vente flash rareté du lundi 7 h ne pardonne aucune panne : un balanceur et deux caches encaissent, une IP virtuelle survit à la mort d'un serveur en pleine vente. Enfin la facture cloud tombe, astronomique : tout rapatrier sur la grappe de Raspberry Pi - deux millions de connexions, jour et nuit, sur du matériel qu'on peut toucher.

Un étage à la fois, chiffres à l'appui

À chaque étage, un test de charge BRUTAL avec JMeter documente ce que le montage encaisse : les chiffres racontent la croissance.

Note : L'énoncé de tout le projet est composé des énoncés de chacun de ces 4 laboratoires.
En cas de conflit entre la version « une page » et la version « diapo », la version des diapositives prévaut.

Le processus de travail

Exécution du laboratoire

• 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.
• Si tu es bloqué(e) ou en difficulté, tu dois demander de l'aide PENDANT la séance du bon laboratoire.

Ligne du temps

• La majorité du laboratoire se réalise dans la séance de 4h, environ 80% du travail.
• Tu as ensuite 7 jours pour finaliser ta remise.

Originalité

• 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.

Remise et Examen pratique

La remise

• Remise en équipe, incrémentale, d'une solution originale (différente des autres équipes).
• 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.

Utilisation de l'IA

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.

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 étudiant 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).
• Nom d'hôte : SERVICE_PRINCIPAL + 3 derniers chiffres de l'adresse (mysql10, http20, varnish30 et 31, haproxy40 et 41, IP virtuelle .49).
• Clonage permis pour sauver du temps : nouvelle adresse MAC, nouveau nom d'hôte, nouvelle adresse IP.

Vos instances, votre choix d'infrastructure

Chaque serveur est une instance : VPS Linode, conteneurs DinD, ou VM VirtualBox. Comme au laboratoire de l'essaim du module 1, vous choisissez l'environnement parmi les choix suivants :

• Les labos sont exactement les mêmes dans les trois cas : mêmes services, mêmes tests, mêmes livrables, même évaluation. L'infrastructure change, l'architecture reste.
• Votre essaim du module 1 peut resservir : les noeuds que vous savez déjà monter font d'excellentes instances.

Varnish : la cache en avant

• Partie 1 : HTTP (apache2) et MySQL sur une seule instance. WordPress avec au moins 2 articles (image et texte), thème une page, accessible depuis l'hôte.
• Partie 2 : une instance de cache Varnish en avant de votre serveur HTTP. L'URL d'accès de WordPress modifiée pour l'adresse de Varnish.
• Pour chaque partie : test BRUTAL, captures top à 10 s et 60 s, tableau.

Barème : guide (2) · configurations (1) · tableau (1) · captures (1). Minimum 2 commits en classe; terminé pour la semaine 7.

Varnish

La séparation : 1 service = 1 instance

• Partie 3 : chaque service principal sur son instance (mysql10, http20). Votre Varnish reste en avant : la base de données déménage derrière le cache.
• Test BRUTAL, captures top à 10 s et 60 s de toutes les instances actives, tableau (valeur id + temps moyen JMeter).

Barème : guide (2) · configurations (1) · tableau (1) · captures (1). Minimum 2 commits en classe; terminé pour la semaine 8.

1 service = 1 serveur (VM)

HAproxy et Heartbeat

• Partie HAproxy : un second Varnish, puis une instance de balancement HAproxy en avant des deux. URL de WordPress sur HAproxy. Mesures partie 4.
• Partie Heartbeat : un second HAproxy, Heartbeat sur les deux, IP virtuelle pour la grappe. URL de WordPress sur l'IP virtuelle. Mesures partie 5.
• L'épreuve : test BRUTAL, éteindre le HAproxy maître, WordPress doit continuer de répondre. Reproduit en classe pour l'évaluation.

Barème : guide (4) · configurations (2) · tableau (2) · captures (2). Minimum 2 commits en classe; terminé pour la semaine 9.

HAproxy

Heartbeat

Installation sur matériel réel

• Avec le meilleur guide de l'équipe : installer l'ensemble des services sur la grappe de Raspberry Pi.
• Rédiger un nouveau guide avec les modifications nécessaires : le passage au matériel laisse toujours des traces.
• Tests BRUTAL, tableau, .PDF unique d'équipe. Démonstration par l'affichage de WordPress dans un navigateur.
• Des commits significatifs de CHAQUE membre dans le nouveau guide, sinon pas de points pour ce participant. Minimum 4 commits d'équipe en classe (au moins 1 par étudiant).

Barème : guide d'équipe (2) · configurations (1) · tableau (1) · captures (1).

Le tableau des performances à remplir

Pour chaque partie, notez la valeur id (processeur inactif) donnée par top pour chaque instance active, et le temps moyen de réponse indiqué par JMeter. Une copie de ce tableau, remplie, par étudiant, en .PDF dans Git.

La question qui vaut de l'or, à discuter dans votre README : d'un étage à l'autre, qu'est-ce qui s'est amélioré, et qu'est-ce que ça a coûté ?

Architecture de remise

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

• Les 4 dossiers cache/, separation/, balancement/ et materiel/ correspondent aux laboratoires A à D.
• Dans chaque dossier : un README.md (guide d'installation) et un sous-dossier par instance avec ses fichiers de configuration.
• Le README.md à la racine sert de présentation globale avec les noms de l'équipe.

Démonstration · En classe à la semaine 10

• Chaque équipe fait la démonstration du laboratoire d'installation sur matériel.
• Chaque étudiant fait la démonstration de tous les autres laboratoires sur son poste de travail, un à la fois.

Rappel : sans démonstration conforme, chaque laboratoire n'est pas évalué. L'épreuve du HAproxy maître éteint sous charge sera rejouée devant tout le monde : c'est le moment de gloire de votre grappe.

La démonstration, et comment se joue la note

• Chaque étudiant démontre unitairement tous les laboratoires virtuels au projecteur. Si un étudiant ne peut démontrer les laboratoires A-B-C ou expliquer certaines lignes de configuration, il aura 0 pour chaque laboratoire concerné. Il partage les liens des guides, configurations, tableau et captures dans l'espace de discussions le jour même de la démo.
• Chaque équipe démontre l'installation matérielle sur cluster Pi.
• L'épreuve du HAproxy maître éteint sous charge est rejouée devant tout le monde, pour le cluster ET pour l'installation individuelle : c'est le test final.

Option VPS : « conserver ses instances » = savoir les recréer et les restaurer en minutes, par script et sauvegardes. À la démonstration, vous relevez l'ensemble devant témoin.

La question qui vaut de l'or, au README :
d'un étage à l'autre, qu'est-ce qui s'est amélioré, et qu'est-ce que ça a coûté ?

Récapitulatif des points

Total : 25 points · 25 % de la session

Récap

• Réalisé en équipe de 4 (inscrire votre nom et votre identifiant Git dans le README.md du dépôt).
• Chaque laboratoire doit être réalisé en partie en classe, et la démonstration finale aura lieu à la semaine 4.
• Assignment Git : [LIEN]
• La démonstration et les fichiers dans Git sont nécessaires à la correction.