Projet haute-disponibilité - Version une page

Le scénario

Cent mille visiteurs, zéro excuse

Cornucopia est désormais une coopérative régionale majeure avec cent mille visiteurs, des paniers bio livrés quotidiennement et zéro tolérance à la panne. Six semaines, une équipe, onze machines virtuelles dans chaque poste : concevoir, monter, sécuriser, documenter et démontrer une infrastructure complète à haute disponibilité, qui encaisse la croissance, la panne, et la démonstration devant public. Tout ce que la ferme de Flora et Hazel vous a appris, enfin réuni dans une seule architecture.

Cette fois, l'application est la vôtre : le projet quitte WordPress et le connu. C'est votre pièce de portfolio : celle qu'on montre en entrevue.

Le choix du sujet et des technologies

Votre application, vos technologies

Vous devez mettre en place, documenter et démontrer la haute disponibilité pour une application ou un site web servi en HTTP avec des données provenant d'une base de données. Vous devez limiter les points de faille au minimum.

Vous pouvez prendre, par exemple, le site web transactionnel que vous avez développé, un site Drupal, ou un autre projet approuvé par le professeur.
Vous pouvez utiliser des instances et des services comme aux laboratoires du module 2, ou des instances et des conteneurs en essaim comme au module 1.
Vous pouvez vous inspirer de tous les composants appris, mais il n'est pas permis d'utiliser WordPress.
Le service ou conteneur de base de données doit être différent de celui qui sert les pages web.
La base de données doit être en haute disponibilité.
Un serveur de fichiers en haute disponibilité pour les médias téléversés.

Les critères de sélection des projets seront précisés en classe. Faites approuver votre sujet avant d'investir vos soirées.

L'infrastructure

Onze machines dans chaque poste

La topologie complète vit en 11 machines virtuelles VirtualBox instanciées dans le poste de chaque membre de l'équipe. C'est la richesse de la topologie qui compte, et la méthode la rend vivable :

Une VM maître minimale, clonée en clones liés : onze machines pour l'espace disque de deux.
Démarrage headless : pas d'écran, tout en SSH, comme en production.
Le plan d'adressage écrit d'avance : qui porte quelle adresse, quel rôle, quel port. C'est un livrable : la documentation d'infrastructure commence avant la première machine.

Partie 1

Le plan du projet

10 points Git : /plan/Projet.png

Présenter et faire approuver par le professeur un plan de votre projet :

Une illustration de l'ensemble des machines virtuelles, services et noeuds, en format légal (8,5 po x 14 po), orientation paysage, .png (1 point)
Leur identification : nom et adresse quand disponible (1 point)
Leur fonction : rôle, brève description et protocoles utilisés (1 point)
Leur relation : lignes sur le diagramme (1 point)
Les points de faille prévus et quelques causes probables pour chacun (2 points)
Les éléments permettant la haute disponibilité, brièvement expliqués (2 points)
L'échelle des machines les plus utilisées vers les moins utilisées (1 point)
L'adresse utilisée pour accéder à l'application (1 point)

Utilisez des boîtes, des traits, des légendes, des icônes et des couleurs : c'est un diagramme technique, mais il doit être intuitif et facile à lire.

Un plan sans sa contrepartie de réalisation suffisamment avancée ne sera pas évalué.

Partie 2

Maîtrise de Docker pour les développeurs

15 points Git : /test-app

Votre application vit dans un environnement complexe. Pour aider l'intégration des nouveaux développeurs à votre équipe, mettez en place une image Docker de votre création qui déploie sur n'importe quelle machine votre application et ses dépendances. Au besoin, l'utilisateur finalise l'installation par des pages web seulement.

Les informations de configuration sont des variables du fichier de configuration Docker ou inscrites dans les fichiers de configuration des services (2 points)
L'image est publiée sur le Docker Hub (2 points)
Guide d'installation et d'utilisation de l'image, avec du texte et des illustrations (3 points)
Démonstration dans une VM de l'installation et du test de l'application conteneurisée (5 points)
Accès à la partie publique de l'application depuis la machine hôte (1 point)
Dépôt Git /test-app : README.md (le guide), tous les fichiers utiles à la création de l'image, le Dockerfile (2 points)

À cette étape, tout-en-un permis : tous les services dans la même image, base de données incluse. Pas de point de faille ni de haute disponibilité ici : c'est l'image des développeurs, pas celle de la production. Docker Compose non requis.

Partie 3

L'infrastructure de haute disponibilité

25 points Git : /infrastructure

Le coeur du projet : votre application déployée sur la topologie de 11 machines, avec ou sans conteneurs. Il n'est pas permis d'utiliser l'image Docker des développeurs.

Topologie complète montée et fonctionnelle, points de faille doublés (5 points)
Guide d'installation de l'infrastructure, texte et illustrations (4 points)
Test de charge BRUTAL : niveau d'usage de chaque machine et temps d'attente moyen après 10 et 60 secondes (1 point)
Diagramme du projet mis à jour (2 points)
Explication des différences dans un diagramme côte à côte, format légal paysage .png (2 points)
Démonstration de l'accès à la partie publique depuis l'hôte (1 point)
Démonstration de l'ajout d'un item dans votre application depuis l'hôte (2 points)
Démonstration de la haute disponibilité : la panne provoquée, le service qui tient (2 points)
Identification des éléments de sécurité en place et des améliorations possibles dans Sécurité.md, sources citées (4 points)
Dépôt Git /infrastructure : README.md (le guide), tous les fichiers nécessaires, Projet.png, Projet-différences.png, Test-charge.md, captures d'écran (2 points)

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

⚠️ 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

├── 📁 partie1/

│ ├── 📄 (diagrammes et fichiers)

│ └── 📄 README.md

├── 📁 partie2/

│ ├── 📄 (fichiers docker)

│ └── 📄 README.md

└── 📁 partie3/

├── 📄 (fichiers de config)

└── 📄 README.md (guide final)

Les 3 dossiers partie1/, partie2/, et partie3/ correspondent aux étapes du projet.
Les fichiers de configuration et un fichier README.md sont exigés dans chaque dossier.
Le README.md à la racine sert de présentation globale avec les noms de l'équipe.

Semaine 15

La démonstration finale

La démonstration sur l'ordinateur de chaque étudiant et les fichiers dans Git sont nécessaires à la correction.
L'infrastructure répond, encaisse le test de charge, et survit à la panne provoquée devant public.
Chaque membre peut expliquer chaque composant : l'IA a pu aider (des prompts d'accompagnement sont fournis pour les parties avancées), c'est votre tête qui répond.

La grille

Récapitulatif des points

Partie	Points
1 · Le plan du projet, approuvé et illustré	10
2 · L'image Docker des développeurs	15
3 · L'infrastructure de haute disponibilité	25

Total : 50 points · 50 % de la session

Assignment Git : lien remis en classe.