Prouver et automatiser

Progression d’apprentissage0 / 404

0 / 26 validations dans ce chapitre

Réinitialiser la progression

Prouver la persistance puis encapsuler les commandes comprises.

Dans ce chapitre : 6 étapes et 26 preuves de validation.

Étape 91 — Prouver que WordPress partage bien son volume

Objectif. Tu verras que NGINX et PHP-FPM lisent les mêmes fichiers persistants.

État du projet avant cette étape. La stack complète tourne. Le site n’a pourtant de sens que si NGINX et WordPress voient le même /var/www/html.

Comprendre le changement

Un volume nommé peut être monté dans plusieurs containers. WordPress écrit les fichiers ; NGINX les lit pour servir les ressources et transmettre les scripts PHP.

Exigence du sujet · p. 7

Un volume doit contenir les fichiers de la base WordPress et un autre ceux du site.

Faire une seule chose

Crée un petit fichier témoin depuis WordPress puis lis-le depuis NGINX. Supprime ensuite ce témoin.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose -f srcs/docker-compose.yml exec wordpress sh -c 'echo volume-ok > /var/www/html/volume-test.txt'
docker compose -f srcs/docker-compose.yml exec nginx cat /var/www/html/volume-test.txt
docker compose -f srcs/docker-compose.yml exec wordpress rm /var/www/html/volume-test.txt

Ce que fait chaque partie

1. La première commande écrit dans le volume depuis WordPress.
2. La deuxième lit le même chemin depuis NGINX.
3. La dernière nettoie le fichier de test.

Résultat attendu

La commande cat affiche exactement volume-ok.

Si cela échoue

Si le fichier est absent dans NGINX, compare le nom du volume et le chemin de montage des deux services.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

NGINX lit le fichier créé par WordPress.Les deux services montent le même volume nommé wordpress_data.Le fichier de test a été supprimé.Je peux expliquer pourquoi ce partage ne fusionne pas les containers.

Question de soutenance — Pourquoi créer le Makefile à la fin ?

Il automatise un processus Compose déjà construit, testé et compris.

Étape 92 — Supprimer les containers sans perdre le site

Objectif. Tu prouveras la persistance au lieu de la supposer.

État du projet avant cette étape. Les deux volumes sont utilisés. Il reste à montrer que leur durée de vie dépasse celle des containers.

Comprendre le changement

docker compose down supprime les containers et le réseau, mais conserve les volumes sans option -v. Au prochain up, de nouveaux containers retrouvent les mêmes données.

Exigence du sujet · p. 7

Les données WordPress et MariaDB doivent persister grâce aux volumes dédiés.

Faire une seule chose

Note le titre du site et les utilisateurs, exécute down puis up, et vérifie que ces informations n’ont pas changé.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

Copier

docker compose -f srcs/docker-compose.yml exec wordpress sh -c 'date > /var/www/html/persistence-test.txt'
docker compose -f srcs/docker-compose.yml down
docker compose -f srcs/docker-compose.yml up -d --build
docker compose -f srcs/docker-compose.yml exec wordpress cat /var/www/html/persistence-test.txt
docker compose -f srcs/docker-compose.yml exec wordpress wp user list --allow-root --path=/var/www/html

Ce que fait chaque partie

1. exec … date : crée une donnée témoin dans le volume WordPress.
2. down : supprime les containers et le réseau, pas les volumes sans -v.
3. up -d --build : reconstruit et recrée.
4. cat/wp user list : vérifie les fichiers et les données MariaDB.

Résultat attendu

Le marqueur et les deux utilisateurs existent encore après la recréation.

Si cela échoue

Si les données disparaissent, vérifiez que down n’a pas reçu -v, que les montages utilisent les mêmes noms et que l’entrypoint n’écrase rien.

Prouver que c’est correct

Preuves de validation 0 / 5

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

down a supprimé les containers sans supprimer les volumes.up a créé de nouveaux containers.Le site conserve son titre et son contenu.Les deux utilisateurs WordPress existent encore.Je sais pourquoi down -v aurait rendu ce test destructif.

Question de soutenance — Pourquoi créer le Makefile à la fin ?

Il automatise un processus Compose déjà construit, testé et compris.

Étape 93 — Tester le redémarrage après un crash

Objectif. Tu vérifieras la politique de redémarrage avec un incident contrôlé.

État du projet avant cette étape. La persistance est prouvée ; la stack doit aussi se relever si un processus principal s’arrête anormalement.

Comprendre le changement

Quand le PID 1 meurt, le container s’arrête. La politique on-failure ou équivalente demande alors à Docker de le relancer.

Exigence du sujet · p. 6

Les containers doivent redémarrer en cas de crash.

Faire une seule chose

Relève le compteur de redémarrage de MariaDB, tue son PID 1, attends, puis relève de nouveau son état et le compteur.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

Copier

docker compose -f srcs/docker-compose.yml exec wordpress sh -c 'echo defense > /var/www/html/defense-marker.txt'
docker compose -f srcs/docker-compose.yml exec wordpress sh -c 'kill -9 1'
sleep 5
docker inspect "$(docker compose -f srcs/docker-compose.yml ps -q wordpress)" --format 'status={{.State.Status}} restarts={{.RestartCount}}'
docker compose -f srcs/docker-compose.yml down
docker compose --env-file srcs/.env -f srcs/docker-compose.yml up -d
docker compose -f srcs/docker-compose.yml exec wordpress cat /var/www/html/defense-marker.txt
docker compose -f srcs/docker-compose.yml exec wordpress wp user list --allow-root --path=/var/www/html

Ce que fait chaque partie

1. kill -9 1 depuis le container : simule le crash du processus principal sans dépendre d’un nom de container fixe.
2. RestartCount : montre la reprise par la politique.
3. down/up sans -v : remplace les containers mais garde les volumes.
4. cat/wp : contrôle les deux stockages.

Résultat attendu

WordPress revient Up avec un compteur augmenté ; marqueur et comptes persistent après down/up.

Si cela échoue

Si le container ne revient pas, vérifiez restart. Si les données disparaissent, inspectez les noms/montages et cherchez toute suppression dans les entrypoints.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

Le container MariaDB repasse Up après le test.Son compteur RestartCount a augmenté.La base et le site répondent encore après le redémarrage.Je distingue un crash d’un arrêt volontaire avec compose down.

Question de soutenance — Pourquoi créer le Makefile à la fin ?

Il automatise un processus Compose déjà construit, testé et compris.

Étape 94 — Faire de make la commande d’entrée

Objectif. Tu rendras le démarrage reproductible depuis la racine.

État du projet avant cette étape. La stack fonctionne avec une longue commande Docker Compose exécutée à la main.

Comprendre le changement

Le Makefile ne remplace pas Compose : il mémorise le chemin du fichier, le fichier d’environnement et la préparation des dossiers hôte.

Exigence du sujet · p. 5

Un Makefile à la racine doit construire toute l’application via docker-compose.yml.

Faire une seule chose

Crée un Makefile dont la cible par défaut prépare /home/<login>/data puis exécute compose up -d –build.

Fichiers ou emplacements concernés

• Makefile

À ÉCRIRE DANS📄 Makefile · première partie

Copier

include srcs/.env

COMPOSE = docker compose --env-file srcs/.env -f srcs/docker-compose.yml

.PHONY: all prepare build up down clean fclean re ps logs

all: up

prepare:
	mkdir -p /home/$(LOGIN)/data/mariadb /home/$(LOGIN)/data/wordpress

build:
	$(COMPOSE) build

up: prepare
	$(COMPOSE) up -d --build

Ce que fait chaque partie

1. include srcs/.env : charge LOGIN et les variables Make non sensibles.
2. COMPOSE : centralise les chemins lancés depuis la racine.
3. .PHONY : évite qu’un fichier nommé up bloque la cible.
4. all: up : make sans argument lance tout.
5. prepare : crée les dossiers hôte requis.
6. up : construit et démarre les trois services.

Résultat attendu

make exécute prepare puis Compose up --build.

Si cela échoue

missing separator signifie presque toujours que des espaces remplacent la tabulation avant une recette.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

Le fichier s’appelle exactement Makefile à la racine.La première cible utile permet à make sans argument de démarrer le projet.Les commandes Compose utilisent srcs/docker-compose.yml et srcs/.env.Les dossiers /home/<login>/data sont préparés avant le démarrage.

Question de soutenance — Pourquoi créer le Makefile à la fin ?

Il automatise un processus Compose déjà construit, testé et compris.

Étape 95 — Ajouter les commandes de maintenance

Objectif. Tu sauras précisément ce que chaque cible conserve ou supprime.

État du projet avant cette étape. make sait démarrer le projet. Il doit aussi rendre les opérations quotidiennes prévisibles.

Comprendre le changement

down retire les containers ; clean ajoute le nettoyage des images du projet ; fclean peut supprimer les volumes et données, mais doit annoncer clairement son caractère destructif ; re reconstruit.

Repère pédagogique · p. 5

Le PDF impose make pour construire ; les noms up, down, clean, fclean et re sont une convention recommandée, pas une liste imposée mot pour mot.

Faire une seule chose

Ajoute les cibles réellement utiles à ton projet, avec une aide qui distingue arrêt, reconstruction et suppression des données.

Fichiers ou emplacements concernés

• Makefile

À ÉCRIRE DANS📄 Makefile · seconde partie

Copier

down:
	$(COMPOSE) down

clean: down

fclean:
	$(COMPOSE) down --rmi local --volumes --remove-orphans

re: down up

ps:
	$(COMPOSE) ps

logs:
	$(COMPOSE) logs --tail=100

Ce que fait chaque partie

1. down/clean : supprime containers et réseau, conserve les volumes.
2. fclean : supprime aussi les volumes et images locales ; les données sont perdues.
3. re : recrée sans effacer les données persistantes.
4. ps/logs : diagnostic rapide.

Résultat attendu

make down puis make up conserve le contenu ; make fclean remet volontairement à zéro.

Si cela échoue

Ne liez pas re à fclean si vous voulez préserver les données. Documentez clairement l’effet destructeur de fclean.

Prouver que c’est correct

Preuves de validation 0 / 4

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

make help décrit chaque cible disponible.make down ne supprime pas les volumes.La cible destructive mentionne explicitement la perte de données.make re reconstruit sans cacher les erreurs Compose.

Question de soutenance — Pourquoi créer le Makefile à la fin ?

Il automatise un processus Compose déjà construit, testé et compris.

Étape 96 — Tester le Makefile comme un nouvel utilisateur

Objectif. Tu vérifieras que la commande demandée fonctionne seule.

État du projet avant cette étape. Les cibles sont écrites, mais une faute de tabulation ou de chemin peut encore les rendre inutilisables.

Comprendre le changement

Un évaluateur lancera le projet depuis la racine. Le meilleur test consiste à arrêter proprement puis à utiliser exactement make, sans commande préparatoire cachée.

Exigence du sujet · p. 5

Le Makefile racine doit permettre de mettre en place l’application entière.

Faire une seule chose

Exécute make down, puis make. Termine par make ps et ouvre les logs si un service n’est pas Up.

À EXÉCUTER DANS🖥️ Dans la VM · 📁 racine du repository

Copier

make down
make
make ps

Ce que fait chaque partie

1. make down : retire l’exécution actuelle en conservant les données.
2. make : appelle la première cible all, donc up.
3. make ps : vérifie les trois services.

Résultat attendu

Les trois images sont disponibles et les trois services restent Up ; NGINX publie 443.

Si cela échoue

Si LOGIN est vide dans prepare, ajoutez include srcs/.env au Makefile ou calculez la valeur explicitement. Si permission denied, contrôlez la propriété de votre home.

Prouver que c’est correct

Preuves de validation 0 / 5

Une case correspond à une preuve observée ou expliquée, pas simplement à une commande copiée.

make down termine sans supprimer les données.make reconstruit et démarre les trois services.make ps montre trois services Up.Le site conserve ses données après ce cycle.Aucune étape manuelle non documentée n’est nécessaire avant make.

Question de soutenance — Pourquoi créer le Makefile à la fin ?

Il automatise un processus Compose déjà construit, testé et compris.