Semaine 5 · Laboratoire

Des yeux,
des serrures,
un filet

Surveiller son serveur, le verrouiller, le sauvegarder... puis le détruire pour prouver qu'on sait le ressusciter.

420-5A4-MT · Acte 4 · Le pivot vertical

La mission du jour

À la fin de la séance, vous aurez :

Un tableau de bord de surveillance qui montre vos conteneurs en direct.
Un serveur verrouillé : pare-feu actif, SSH par clés.
Une sauvegarde automatisée de votre WordPress (base + fichiers).
Réussi le crash-test : site détruit, site restauré, chronomètre en main.

Prérequis : votre WordPress composé de la semaine 3, fonctionnel. C'est lui qu'on équipe... et qu'on détruira volontairement.

Étape 1 · Des yeux

Installer la surveillance

# le minimum vital, deja fourni par Docker :

sudo docker stats

CONTAINER CPU % MEM USAGE / LIMIT NET I/O

# puis un vrai tableau de bord... en conteneur, evidemment :

sudo docker run -d --name surveillance -p 19999:19999 [image du tableau de bord fournie en classe]

Ouvrez le tableau de bord et identifiez vos conteneurs WordPress.
Générez du trafic sur votre site et regardez les courbes réagir.
Question du jour : lequel de vos services consomme le plus de mémoire ? Est-ce celui que vous pensiez ?

Étape 2 · Des serrures

Verrouiller le serveur

# le pare-feu : ne laisser entrer que le necessaire

sudo ufw allow 22

sudo ufw allow 80

sudo ufw enable

sudo ufw status

# les mises a jour de securite, sans humain :

sudo apt install unattended-upgrades

Vérifiez votre accès SSH par clés (hérité du cours de serveur) : le mot de passe ne devrait plus servir.
Piège classique : Docker publie ses ports en contournant UFW. On en discute en classe, retenez le principe : vérifier de l'extérieur ce qui est réellement ouvert.

Étape 3 · Un filet

La sauvegarde automatisée

# l'export de la base, sans arreter le site :

sudo docker compose exec basededonnees mysqldump -u root -p... wordpress > sauvegarde-base.sql

# l'archive des fichiers du site :

tar czf sauvegarde-fichiers.tar.gz ./wordpress

# puis un script qui fait les deux, planifie chaque nuit :

crontab -e

0 3 * * * /home/etudiant/sauvegarder-wordpress.sh

Écrivez le script, exécutez-le à la main une fois, et vérifiez que les deux fichiers existent et ont une taille sensée. Une sauvegarde de zéro octet est un mensonge rassurant.

Étape 4 · Le crash-test

Détruire, restaurer, chronométrer

Vendredi soir, l'attaque : un rançongiciel chiffre le serveur de la petite entreprise. Tout est perdu ? Non : la partition est dans le dépôt, les sauvegardes sont à l'abri. Jouons la scène.

# demarrer le chronometre, puis l'irreparable :

sudo docker compose down --volumes

# la resurrection :

sudo docker compose up -d

cat sauvegarde-base.sql | sudo docker compose exec -T basededonnees mysql -u root -p... wordpress

tar xzf sauvegarde-fichiers.tar.gz

# arreter le chronometre quand l'article et son image reapparaissent

Notez votre temps de restauration : c'est LE chiffre du jour, celui qui fait dormir les fondatrices d'entreprise.

Avant de partir

Vérifications et fin du module 1

Preuve du jour : tableau de bord vivant, pare-feu actif, et votre temps de restauration noté.
Le pivot en pensée : avec ces outils, déménager sur une machine plus grosse = rejouer exactement ces gestes ailleurs. C'est la scalabilité verticale conteneurisée.
Devoir : terminer le laboratoire; il clôt les laboratoires du module 1 (25 % de la note).

La suite : le module 2. Dix mille visiteurs en vue, et une certitude : même la plus grosse machine ne suffira plus. La semaine 6, l'entreprise sépare la base de données du web, et on mesure tout avec les premiers tests de charge.

Version de départ · ce diaporama va s'enrichir