Exécuter les tests finaux

Tester l’infrastructure et le parcours utilisateur comme un évaluateur.

Dans ce chapitre : 2 étapes et 12 preuves de validation.

Étape 108 — Faire l’inventaire technique final

Objectif. Tu vérifieras ce que Docker exécute réellement, pas seulement les fichiers.

État du projet avant cette étape. Le projet et sa documentation sont terminés. La soutenance commence par des faits observables sur la VM.

Comprendre le changement

ps prouve les services et les ports ; images prouve les images locales ; inspect prouve les montages, le réseau, les redémarrages et les PID 1.

Faire une seule chose

Relance avec make puis rassemble les sorties utiles. Pour chaque ligne, prépare une phrase qui explique ce qu’elle prouve.

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

docker compose -f srcs/docker-compose.yml ps
docker compose -f srcs/docker-compose.yml images
docker network inspect inception
for service in mariadb wordpress nginx; do docker inspect "$(docker compose -f srcs/docker-compose.yml ps -q "$service")" --format '{{.Name}} | image={{.Config.Image}} | restart={{.HostConfig.RestartPolicy.Name}} | ports={{json .NetworkSettings.Ports}}'; done

Ce que fait chaque partie

ps : état et ports.
images : association service/image.
network inspect : membres du réseau.
inspect format : image, restart et ports de chaque container.

Résultat attendu

Trois Up ; trois images aux mêmes noms que services ; trois membres réseau ; restart configuré ; seul NGINX mappe 443.

Si cela échoue

Un nom réel préfixé par Compose peut nécessiter docker compose ps -q <service> au lieu d’un nom fixe dans docker inspect.

À EXÉCUTER DANS🖥️ Client pour curl/OpenSSL · VM pour Compose

Avant de copier : remplacez <login></dev/null 2> par vos valeurs.

curl -kI https://<login>.42.fr
curl -kI https://<login>.42.fr/wp-admin/
openssl s_client -connect <login>.42.fr:443 -tls1_2 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'
openssl s_client -connect <login>.42.fr:443 -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'
docker compose -f srcs/docker-compose.yml exec wordpress wp user list --allow-root --path=/var/www/html

Ce que fait chaque partie

curl -I : vérifie les statuts sans télécharger la page.
OpenSSL : prouve chaque protocole.
wp user list : vérifie rôles et noms dans la base réelle.

Résultat attendu

Site et /wp-admin répondent ; TLS 1.2/1.3 négocient ; deux comptes au minimum apparaissent.

Si cela échoue

502 = liaison NGINX/PHP-FPM ; Error DB = WordPress/MariaDB ; redirection vers mauvais domaine = DOMAIN_NAME ou options WordPress.

Prouver que c’est correct

Preuves de validation 0 / 6

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

Trois containers dédiés sont Up.Trois images de service construites localement existent.Seul nginx publie 443.Deux volumes nommés et un réseau explicite existent.Les données hôte sont sous /home/<login>/data.Je peux expliquer le PID 1 et la politique de redémarrage de chaque service.

Question de soutenance — Pourquoi ps ne suffit-il pas ?

Un container Up peut encore servir une mauvaise configuration ou ne pas préserver les données.

Étape 109 — Rejouer les tests visibles de l’application

Objectif. Tu vérifieras l’expérience que l’évaluateur reproduira.

État du projet avant cette étape. L’inventaire Docker est cohérent. Il reste à refaire les tests fonctionnels depuis la machine cliente.

Comprendre le changement

Une stack Up n’est pas forcément correcte : le domaine, le certificat, les versions TLS, WordPress, les comptes et la persistance doivent tous être observés.

Faire une seule chose

Teste le site et wp-admin, les deux comptes, TLS positif et négatif, l’absence du port 80, puis refais un cycle down/up sans perte de contenu.

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

git status --short
git ls-files | sort
git check-ignore -v secrets/db_password.txt
test -f Makefile && test -f README.md && test -f USER_DOC.md && test -f DEV_DOC.md && test -f srcs/docker-compose.yml
make down
make

Ce que fait chaque partie

ls-files : inventaire exact rendu.
check-ignore : prouve la règle qui protège le secret.
test -f : vérifie les cinq fichiers critiques.
make : valide le chemin officiel après arrêt.

Résultat attendu

Tous les fichiers obligatoires sont suivis, secrets ignorés, aucune donnée/VM committée, make relance tout.

Si cela échoue

Un fichier untracked obligatoire ne sera pas rendu. Un secret tracked doit être révoqué et retiré de l’historique, pas seulement ignoré.

Prouver que c’est correct

Preuves de validation 0 / 6

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

https://<login>.42.fr affiche le site./wp-admin permet une connexion avec l’administrateur conforme.Le second utilisateur existe et n’est pas l’administrateur.TLS 1.2 et 1.3 réussissent ; les anciennes versions échouent.HTTP sur le port 80 n’est pas servi.Le contenu et les comptes survivent à down puis up.

Question de soutenance — Pourquoi ps ne suffit-il pas ?

Un container Up peut encore servir une mauvaise configuration ou ne pas préserver les données.