Ajouter le volume MariaDB

Progression d’apprentissage0 / 404

0 / 20 validations dans ce chapitre

Réinitialiser la progression

Déclarer puis attacher un volume nommé, une ligne à la fois.

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

Étape 45 — Observer l’absence de stockage externe

Objectif. Tu constateras le problème avant d’ajouter sa solution.

État du projet avant cette étape. MariaDB tourne correctement, mais aucun volume n’est déclaré.

Comprendre le changement

Sans montage sur /var/lib/mysql, les écritures appartiennent au filesystem du container. Supprimer ce container supprimerait ces écritures.

Exigence du sujet · p. 6

La base WordPress doit être stockée dans un volume Docker nommé.

Faire une seule chose

Inspecte les montages sans arrêter MariaDB. La liste ne doit pas encore contenir /var/lib/mysql avec Type=volume.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker inspect "$(docker compose -f srcs/docker-compose.yml ps -q mariadb)" --format '{{json .Mounts}}'

Ce que fait chaque partie

1. compose ps -q récupère l’identifiant du container MariaDB.
2. docker inspect lit sa configuration réelle.
3. .Mounts limite la sortie aux stockages montés.

Résultat attendu

Aucun montage Type=volume ne cible /var/lib/mysql.

Si cela échoue

Un identifiant vide signifie que MariaDB n’est pas Up ; corrige le service avant de parler de volume.

Prouver que c’est correct

Preuves de validation 0 / 3

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

Je peux montrer que /var/lib/mysql n’est pas protégé.Je comprends qu’une image ne contient pas les nouvelles données du container.Je sais pourquoi la prochaine modification est nécessaire.

Question de soutenance — Que prouve Type=volume ?

Le service monte un objet volume Docker nommé et non un chemin hôte directement.

Étape 46 — Vérifier le dossier physique demandé

Objectif. Tu prépareras la destination hôte avant de configurer Docker.

État du projet avant cette étape. Le volume n’existe pas encore. Le PDF impose cependant son emplacement physique sous /home/<login>/data.

Comprendre le changement

Le dossier est sur l’hôte Docker, donc dans la VM. Il n’est ni dans le repository ni dans le container.

Exigence du sujet · pp. 6–7

Les deux volumes nommés doivent stocker leurs données sous /home/login/data sur la machine hôte.

Faire une seule chose

Vérifie le dossier MariaDB créé pendant la préparation du repository. Crée-le seulement s’il manque, avec ton vrai login.

Fichiers ou emplacements concernés

• /home/<login>/data/mariadb

À EXÉCUTER DANSDans la VM · n’importe quel dossier

Copier

echo "login=$USER"
sudo mkdir -p "/home/$USER/data/mariadb"
sudo chown "$USER:$USER" "/home/$USER/data/mariadb"
ls -ld "/home/$USER/data/mariadb"

Ce que fait chaque partie

1. $USER fournit le login de la session.
2. mkdir -p garantit que le chemin existe.
3. chown donne initialement le dossier à ton utilisateur.
4. ls affiche le chemin et son propriétaire.

Résultat attendu

Le chemin /home/ton_login/data/mariadb existe sur la VM.

Si cela échoue

Si $USER n’est pas ton login 42, utilise explicitement ton vrai login demandé par le sujet.

Prouver que c’est correct

Preuves de validation 0 / 3

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

Le chemin contient mon vrai login.Le dossier existe dans la VM, hors du repository.Je sais que Docker écrira les données à cet endroit.

Question de soutenance — Que prouve Type=volume ?

Le service monte un objet volume Docker nommé et non un chemin hôte directement.

Étape 47 — Déclarer le volume nommé

Objectif. Compose connaîtra le stockage, sans encore le monter dans MariaDB.

État du projet avant cette étape. Le dossier hôte existe. docker-compose.yml ne contient aucune section volumes globale.

Comprendre le changement

La section globale crée un objet Docker nommé mariadb_data. Les options du pilote local indiquent son emplacement physique. À ce stade, aucun service ne l’utilise encore.

Exigence du sujet · p. 6

Le stockage MariaDB doit être un volume nommé et vivre sous /home/login/data.

Faire une seule chose

Ajoute uniquement la section globale, au même niveau que services. Valide le YAML.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · section globale en bas du fichier

Copier

volumes:
  mariadb_data:
    name: mariadb_data
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /home/${LOGIN}/data/mariadb

Ce que fait chaque partie

1. volumes est aligné avec services.
2. mariadb_data est le nom logique dans Compose.
3. name fixe le nom visible dans Docker.
4. driver_opts configure le pilote local.
5. device utilise LOGIN chargé depuis .env.

Résultat attendu

compose config affiche une section volumes mariadb_data.

Si cela échoue

Si LOGIN est vide dans config, relance avec --env-file srcs/.env et vérifie la variable.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose --env-file srcs/.env -f srcs/docker-compose.yml config

Ce que fait chaque partie

1. --env-file fournit LOGIN pour l’interpolation.
2. config valide sans créer le volume.

Résultat attendu

La sortie montre le chemin complet avec ton login, sans placeholder.

Si cela échoue

Une erreur additional property volumes signifie que la section est mal alignée.

Prouver que c’est correct

Preuves de validation 0 / 3

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

volumes est au même niveau que services.Le volume global s’appelle mariadb_data.config remplace LOGIN par mon vrai login.

Question de soutenance — Que prouve Type=volume ?

Le service monte un objet volume Docker nommé et non un chemin hôte directement.

Étape 48 — Attacher le volume à MariaDB

Objectif. Tu relieras l’objet Docker au dossier de données du service.

État du projet avant cette étape. Le volume est déclaré mais le service MariaDB ne l’utilise pas encore.

Comprendre le changement

La syntaxe nom:destination donne à MariaDB l’objet nommé. Le service ne reçoit jamais directement le chemin /home/… : inspect devra montrer Type=volume.

Interdit par le sujet · p. 6

Les bind mounts directs sont interdits pour ce stockage ; le service doit monter un volume Docker nommé.

Faire une seule chose

Ajoute les deux lignes sous le service mariadb, au même niveau que environment, secrets et restart.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · dans le service mariadb

Copier

    volumes:
      - mariadb_data:/var/lib/mysql

Ce que fait chaque partie

1. volumes du service ouvre ses montages.
2. mariadb_data référence la déclaration globale.
3. /var/lib/mysql est le datadir configuré de MariaDB.

Résultat attendu

Le service référence le nom mariadb_data, jamais un chemin hôte.

Si cela échoue

N’écris pas /home/...:/var/lib/mysql dans le service : ce serait un bind mount direct.

Prouver que c’est correct

Preuves de validation 0 / 3

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

Le montage est sous le service mariadb.La source est mariadb_data.La destination est /var/lib/mysql.

Question de soutenance — Que prouve Type=volume ?

Le service monte un objet volume Docker nommé et non un chemin hôte directement.

Étape 49 — Recréer MariaDB avec le volume

Objectif. Tu vérifieras le type de montage réellement appliqué.

État du projet avant cette étape. Le fichier déclare et attache le volume, mais le container existant a été créé avant cette modification.

Comprendre le changement

down supprime l’ancien container. up en crée un nouveau avec le montage. inspect doit ensuite prouver Type=volume et la bonne destination.

Exigence du sujet · p. 6

Le stockage doit être un volume nommé disponible sous /home/login/data.

Faire une seule chose

Valide, recrée, puis inspecte. Cette première recréation peut réinitialiser les données de test car elles n’étaient pas encore protégées.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose --env-file srcs/.env -f srcs/docker-compose.yml config
docker compose -f srcs/docker-compose.yml down
docker compose --env-file srcs/.env -f srcs/docker-compose.yml up -d
docker inspect "$(docker compose -f srcs/docker-compose.yml ps -q mariadb)" --format '{{range .Mounts}}{{.Type}} | {{.Name}} | {{.Destination}}{{println}}{{end}}'

Ce que fait chaque partie

1. config contrôle le plan final de cette étape.
2. down retire le container sans volume attaché.
3. up crée le volume et un nouveau container.
4. inspect affiche type, nom et destination du montage.

Résultat attendu

La sortie contient volume | mariadb_data | /var/lib/mysql.

Si cela échoue

Si le type vaut bind, le service utilise probablement un chemin hôte direct au lieu du nom du volume.

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.

MariaDB est Up.inspect affiche Type=volume.Le nom est mariadb_data.La destination est /var/lib/mysql.

Question de soutenance — Que prouve Type=volume ?

Le service monte un objet volume Docker nommé et non un chemin hôte directement.

Étape 50 — Prouver la persistance avec une donnée témoin

Objectif. Tu vérifieras une vraie ligne de base après remplacement du container.

État du projet avant cette étape. MariaDB utilise maintenant le volume nommé.

Comprendre le changement

Une base portant le même nom pourrait être recréée automatiquement. Une ligne témoin permet une preuve plus forte : elle n’existera après down/up que si le volume a conservé les données.

Exigence du sujet · p. 6

La base WordPress doit persister dans son volume dédié.

Faire une seule chose

Crée une table et la valeur 42, remplace le container sans -v, puis lis à nouveau cette valeur.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose -f srcs/docker-compose.yml exec mariadb sh -c 'mariadb -uroot -p"$(cat /run/secrets/db_root_password)" "$MYSQL_DATABASE" -e "CREATE TABLE IF NOT EXISTS persistence_probe (id INT PRIMARY KEY); INSERT IGNORE INTO persistence_probe VALUES (42);"'
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 mariadb sh -c 'mariadb -uroot -p"$(cat /run/secrets/db_root_password)" "$MYSQL_DATABASE" -e "SELECT id FROM persistence_probe;"'

Ce que fait chaque partie

1. exec lance le client dans le container.
2. Le mot de passe est lu depuis le secret sans être affiché.
3. CREATE TABLE et INSERT créent la preuve.
4. down remplace le container mais ne supprime pas le volume.
5. SELECT lit la donnée après recréation.

Résultat attendu

Le dernier SELECT affiche la valeur 42.

Si cela échoue

N’utilise pas down -v : cette option supprime précisément le volume que tu cherches à tester.

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 a été supprimé puis recréé.Le SELECT final affiche 42.Le volume mariadb_data existe toujours.Je peux expliquer pourquoi cette preuve est plus forte qu’un simple statut Up.

Question de soutenance — Que prouve Type=volume ?

Le service monte un objet volume Docker nommé et non un chemin hôte directement.