Projet
haute-
disponibilité

Le grand oeuvre : concevoir, monter, sécuriser, documenter et démontrer une infrastructure complète qui encaisse la charge et la panne.

Cent mille visiteurs, zéro excuse

Cent mille visiteurs, des clients payants, zéro excuse. 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 petite entreprise 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.

Votre application, vos technologies

• Une application ou un site web servi en HTTP, avec des données dans une base de données.
• Par exemple votre application web transactionnelle d'un autre cours, un site Drupal, ou un projet approuvé par le professeur.
• WordPress n'est pas permis : la session vous l'a donné, le projet vous demande de généraliser.
• Technologies au choix : des instances et des services comme au module 2, ou des instances et des conteneurs en essaim comme au module 1. Inspirez-vous de tout ce que vous avez appris.
• Obligations : la base de données séparée du service web; la base en haute disponibilité; un serveur de fichiers en haute disponibilité pour les médias téléversés.

Onze machines dans chaque poste

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

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

Le plan du projet, approuvé

Un diagramme technique intuitif et facile à lire (format légal 8,5 x 14 paysage, .png, boîtes, traits, légendes, icônes, couleurs), présenté et approuvé par le professeur :

• Toutes les machines, services et noeuds : identification (nom, adresse) (2) et fonction avec protocoles (1)
• Leurs relations, en traits sur le diagramme (1)
• Les points de faille prévus et leurs causes probables (2)
• Les éléments de haute disponibilité, brièvement expliqués (2)
• L'échelle d'usage des machines (la plus à la moins utilisée) (1) et l'adresse d'accès à l'application (1)

GitHub : /plan/Projet.png. Un plan sans réalisation suffisamment avancée ne sera pas évalué.

Maîtrise de Docker pour les développeurs

Votre application vit dans un environnement complexe. Pour accueillir les nouveaux développeurs de l'équipe : une image Docker de votre création qui déploie l'application et ses dépendances sur n'importe quelle machine.

• Configuration par variables Docker ou fichiers de configuration des services (2)
• Image publiée sur le Docker Hub (2)
• Guide d'installation et d'utilisation, texte et illustrations (3)
• Démonstration dans une VM : installation et test de l'application conteneurisée (5), partie publique accessible depuis l'hôte (1)
• GitHub /test-app : README.md, fichiers de création de l'image, Dockerfile (2)

Ici, tout-en-un permis : tous les services dans la même image, pas de haute disponibilité. C'est l'image des développeurs, pas celle de la production.

L'infrastructure de haute disponibilité

Le coeur du projet : votre application déployée sur la topologie de 11 machines (l'image des développeurs n'est pas permise ici).

• Topologie complète montée et fonctionnelle, points de faille doublés (5)
• Guide d'installation de l'infrastructure, texte et illustrations (4)
• Test de charge BRUTAL : usage de chaque machine et temps d'attente moyen à 10 et 60 secondes (1)
• Diagramme du projet mis à jour (2) et diagramme des différences côte à côte, format légal paysage (2)
• Démonstrations depuis l'hôte : partie publique (1), ajout d'un item dans l'application (2), haute disponibilité sous panne (2)
• Sécurité.md : les mesures en place et les améliorations possibles, sources citées (4)
• GitHub /infrastructure : README, fichiers, diagrammes, Test-charge.md, captures (2)

La démonstration finale

• Sur l'ordinateur de chaque étudiant : l'infrastructure complète répond, encaisse le test de charge, et survit à la panne qu'on provoque devant public.
• Les fichiers dans GitHub et la démonstration sont nécessaires à la correction.
• 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 petite entreprise de la semaine 1 est devenue grande. L'infrastructure qui tourne devant la classe, c'est quinze semaines d'histoire, et c'est vous qui l'avez bâtie.

10 + 15 + 25 = 50

Total : 50 points · 50 % de la session. Assignment GitHub : lien remis en classe. La version une page de cet énoncé détaille chaque critère.