📋 Plan détaillé
en 3 modules

Une petite entreprise vient de mettre son site en ligne : un WordPress hérité du cours de serveur. Cent visiteurs par jour, tout roule. Mais l'application vit sans armure sur la machine : fragile, difficile à déplacer, impossible à cloner. Premier réflexe de pro : l'emballer dans des conteneurs, le web d'un côté, la base de données de l'autre.

Le succès commence à pointer le bout de son nez : vingt mille visiteurs par jour. Deux conteneurs à démarrer dans le bon ordre, des ports, des montages, des mots de passe : les commandes s'allongent. L'entreprise écrit tout dans une partition unique : un fichier qui décrit l'application entière, prête à se lever d'une seule commande, ici ou n'importe où.

C'est face à la charge naissante que l'entreprise décide de séparer les rôles. Pour anticiper la croissance et éviter d'empiler tous les services sur une seule machine, elle apprend dans son laboratoire à distribuer son architecture. Chacun monte son propre essaim de trois nœuds (locaux ou virtuels) et y orchestre les rôles spécialisés (le gestionnaire, les travailleurs, le web et la base de données), observant WordPress se répliquer.

Le bouche-à-oreille explose : cinquante mille visiteurs se ruent sur le site. L'unique serveur fatigue et les menaces rôdent. L'entreprise s'équipe d'yeux (surveillance), de serrures (sécurisation) et d'un filet (sauvegardes et restauration), puis pivote vers une machine élastique de production plus grosse dans le nuage. Le déménagement se fait en quelques minutes... mais le répit est trompeur. Comme le savent les administrateurs chevronnés : sur un serveur plus gros, l'application met simplement plus de temps à s'asphyxier et à crasher. Le vertical a un plafond physique, et toute la production repose encore sur un point de faille unique.

L'encyclopédie et les fiches de règles deviennent virales : des centaines de milliers de lectures des mêmes pages fixes. Plutôt que de laisser WordPress recalculer sans cesse la même réponse, on place un cache Varnish devant le site : la réponse toute prête, servie instantanément. Le même site, servi cinq fois plus vite.

Les Guildes ouvrent : profils de membres, carnets et points calculés en temps réel - du contenu personnalisé que le cache ne peut pas servir. On applique les concepts d'orchestration pour séparer physiquement la base de données et le serveur web sur des machines dédiées. Et pour la première fois, on mesure scientifiquement l'effet de cette séparation par un test de charge.

Tout est balancé, tout est en cache... et tout passe par la passerelle : si elle tombe, tout tombe. L'entreprise traque ses points de faille et les double un à un : deux passerelles, une adresse IP virtuelle qui bascule toute seule, de la redondance de bout en bout.

Fini le simulé : en équipe, on assemble un vrai cluster de Raspberry Pi, de vraies machines qu'on peut toucher, brancher, et débrancher en pleine charge pour voir l'architecture tenir. Tout ce que la session a construit tourne maintenant sur du matériel qui tient dans une main.

Lancement du grand œuvre en équipe. Conception de la topologie haute-disponibilité complète de plus de 12 VM et écriture du plan d'adressage détaillé. Validation obligatoire du plan avant le montage.

Mise en place de l'infrastructure locale de virtualisation (clones liés, machines maîtres minimales, démarrage headless) et rappels conceptuels sur les clusters Raspberry Pi et l'essaim Swarm.

Sécurisation des accès, configuration des pare-feu de chaque service, et mise en place de la redondance et de la réplication active de la base de données et du trafic.

Derniers préparatifs, tests de charge intensifs et simulation de pannes matérielles. Répétition générale de la démonstration d'infrastructure en vue de l'épreuve finale.