Faire fonctionner MariaDB

Progression d’apprentissage0 / 404

0 / 32 validations dans ce chapitre

Réinitialiser la progression

Configurer le runtime, les secrets et l’initialisation de la base.

Dans ce chapitre : 8 étapes et 32 preuves de validation.

Étape 37 — Écrire les variables non secrètes de MariaDB

Objectif. MariaDB recevra le nom de la base et de l’utilisateur sans les coder dans l’image.

État du projet avant cette étape. Compose sait construire l’image, mais le service ne connaît encore aucun réglage d’exécution.

Comprendre le changement

srcs/.env contient des valeurs de configuration lisibles : login, nom de base et nom d’utilisateur. Les mots de passe n’y vont pas ; ils restent dans secrets/.

Exigence du sujet · p. 7

L’usage de variables d’environnement et d’un fichier .env est obligatoire.

Faire une seule chose

Écris les trois lignes proposées en remplaçant votrelogin. Ces valeurs seront chargées dans le container à l’étape 29.

Fichiers ou emplacements concernés

• srcs/.env

À ÉCRIRE DANSFichier srcs/.env · remplace votrelogin

Copier

LOGIN=votrelogin
MYSQL_DATABASE=wordpress
MYSQL_USER=wp_user

Ce que fait chaque partie

1. LOGIN servira aux chemins de volumes.
2. MYSQL_DATABASE est le nom de la base WordPress.
3. MYSQL_USER est le compte utilisé par WordPress.
4. Aucune ligne ne contient un mot de passe.

Résultat attendu

Le fichier contient trois lignes non confidentielles.

Si cela échoue

N’ajoute pas PASSWORD ici ; les mots de passe vont dans secrets/.

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.

LOGIN contient ton vrai login 42.MYSQL_DATABASE et MYSQL_USER ne sont pas vides.Aucun mot de passe n’apparaît dans srcs/.env.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 38 — Remplir les deux secrets MariaDB

Objectif. Deux mots de passe locaux seront prêts sans apparaître dans Git.

État du projet avant cette étape. Les fichiers secrets existent mais sont encore vides.

Comprendre le changement

db_password est le mot de passe du compte utilisé par WordPress. db_root_password protège le compte root de MariaDB. Ils doivent être différents et rester uniquement sur la VM.

Repère pédagogique · pp. 7, 10

Aucun credential ne doit être trouvé dans Git ; Docker secrets est fortement recommandé pour le confidentiel.

Faire une seule chose

Ouvre chaque fichier avec ton éditeur dans la VM et saisis une valeur forte. Ne copie pas la valeur dans le terminal, le Dockerfile, .env ou ce guide. Ferme ensuite les permissions avec chmod.

Fichiers ou emplacements concernés

• secrets/db_password.txt
• secrets/db_root_password.txt

À EXÉCUTER DANSDans la VM · racine du repository · après avoir rempli les fichiers dans un éditeur

Copier

chmod 700 secrets
chmod 600 secrets/*.txt
git status --short --ignored

Ce que fait chaque partie

1. chmod 700 limite l’accès au dossier.
2. chmod 600 limite chaque fichier à son propriétaire.
3. git status --ignored confirme que secrets est ignoré sans afficher les valeurs.

Résultat attendu

Les fichiers sont ignorés et aucune valeur n’est imprimée.

Si cela échoue

Si secrets apparaît comme fichier suivi, arrête-toi : .gitignore doit être corrigé avant tout commit.

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.

Les deux fichiers MariaDB sont non vides.Les deux mots de passe sont différents.git status indique que secrets/ est ignoré.Aucune commande de contrôle n’affiche les valeurs.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 39 — Faire lire les secrets au script

Objectif. L’entrypoint pourra récupérer les mots de passe au démarrage du container.

État du projet avant cette étape. Le script provisoire ne lit encore aucune configuration.

Comprendre le changement

Compose montera chaque secret comme un petit fichier sous /run/secrets. Le script reçoit le chemin dans une variable se terminant par _FILE, puis lit le contenu avec cat.

Exigence du sujet · p. 7

Aucun mot de passe ne doit être présent dans le Dockerfile ; les variables d’environnement sont obligatoires.

Faire une seule chose

Remplace le contenu provisoire de l’entrypoint par la première partie proposée. Ne démarre toujours pas MariaDB : on complète d’abord l’initialisation.

Fichiers ou emplacements concernés

• srcs/requirements/mariadb/tools/entrypoint.sh

À ÉCRIRE DANS📄 srcs/requirements/mariadb/tools/entrypoint.sh · première partie

Copier

#!/bin/sh
set -eu

: "${MYSQL_DATABASE:?MYSQL_DATABASE manquant}"
: "${MYSQL_USER:?MYSQL_USER manquant}"
: "${MYSQL_PASSWORD_FILE:?MYSQL_PASSWORD_FILE manquant}"
: "${MYSQL_ROOT_PASSWORD_FILE:?MYSQL_ROOT_PASSWORD_FILE manquant}"

MYSQL_PASSWORD="$(cat "$MYSQL_PASSWORD_FILE")"
MYSQL_ROOT_PASSWORD="$(cat "$MYSQL_ROOT_PASSWORD_FILE")"
test -n "$MYSQL_PASSWORD"
test -n "$MYSQL_ROOT_PASSWORD"

Ce que fait chaque partie

1. set -eu : arrête sur erreur et variable non définie.
2. : "${VAR:?…}" : échoue avec un message précis si une variable manque.
3. $(cat …) : lit le contenu du secret monté au runtime.
4. test -n : refuse un secret vide.

Résultat attendu

Un secret absent ou vide arrête immédiatement le container avec une erreur lisible.

Si cela échoue

Si cat indique no such file, comparez le nom du secret Compose et le chemin *_FILE. N’affichez jamais les valeurs dans les logs.

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 script vérifie MYSQL_DATABASE et MYSQL_USER.Les deux mots de passe sont lus depuis des chemins *_FILE.Aucune valeur de mot de passe n’est écrite dans le script.Un fichier secret vide provoque une erreur.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 40 — Initialiser un dossier de base vide

Objectif. Le premier démarrage préparera MariaDB ; les suivants conserveront ce qui existe.

État du projet avant cette étape. Le script connaît les variables mais /var/lib/mysql peut encore être vide.

Comprendre le changement

mariadb-install-db crée les tables internes nécessaires au serveur. Le test [ ! -d /var/lib/mysql/mysql ] évite de recommencer si ces tables sont déjà présentes.

Exigence du sujet · p. 6

La base doit vivre dans un stockage persistant et supporter la recréation des containers.

Faire une seule chose

Ajoute ce bloc après la lecture des secrets. Lis le if comme une phrase : « si le dossier système mysql n’existe pas, initialise ; sinon, ne touche pas aux données ».

Fichiers ou emplacements concernés

• srcs/requirements/mariadb/tools/entrypoint.sh

À ÉCRIRE DANS📄 srcs/requirements/mariadb/tools/entrypoint.sh · après la lecture des secrets

Copier

mkdir -p /run/mysqld /var/lib/mysql
chown -R mysql:mysql /run/mysqld /var/lib/mysql

if [ ! -d /var/lib/mysql/mysql ]; then
  mariadb-install-db --user=mysql --datadir=/var/lib/mysql
  FIRST_START=1
else
  FIRST_START=0
fi

Ce que fait chaque partie

1. mkdir/chown : prépare socket et datadir pour l’utilisateur mysql.
2. test -d : détecte les tables système persistantes.
3. mariadb-install-db : initialise uniquement un datadir vide.
4. FIRST_START : mémorise si la création métier est nécessaire.

Résultat attendu

Au premier lancement, les tables système sont créées ; aux suivants, elles sont conservées.

Si cela échoue

Si permission denied vise /var/lib/mysql, inspectez le propriétaire réel du volume. Ne supprimez pas le volume pour masquer l’erreur si vous testez la persistance.

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 script crée /run/mysqld et /var/lib/mysql.mariadb-install-db se trouve uniquement dans le cas où le dossier système est absent.Le cas else ne supprime aucune donnée.Tu peux expliquer le mot idempotent avec cet exemple.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 41 — Créer la base et le compte WordPress

Objectif. Le premier démarrage créera exactement les objets dont WordPress aura besoin.

État du projet avant cette étape. MariaDB peut créer ses tables internes, mais la base wordpress et le compte wp_user n’existent pas encore.

Comprendre le changement

Le script lance brièvement MariaDB sans réseau, attend au maximum 30 secondes, exécute le SQL de création, puis arrête cette instance temporaire. Cette opération n’a lieu que lors de FIRST_START.

Exigence du sujet · pp. 6–7

Le projet doit fournir une base WordPress sans publier de mot de passe dans Git.

Faire une seule chose

Ajoute le bloc SQL proposé. Repère les trois actions : CREATE DATABASE, CREATE USER, GRANT. WordPress utilisera ce compte limité, pas root.

Fichiers ou emplacements concernés

• srcs/requirements/mariadb/tools/entrypoint.sh

À ÉCRIRE DANS📄 srcs/requirements/mariadb/tools/entrypoint.sh · bloc d’initialisation

Copier

if [ "$FIRST_START" -eq 1 ]; then
  mariadbd --user=mysql --skip-networking --socket=/run/mysqld/mysqld.sock &
  temp_pid=$!
  ready=0
  for attempt in $(seq 1 30); do
    if mariadb-admin --socket=/run/mysqld/mysqld.sock ping --silent; then
      ready=1
      break
    fi
    sleep 1
  done
  [ "$ready" -eq 1 ] || { kill "$temp_pid"; echo "MariaDB init timeout" >&2; exit 1; }

  mariadb --socket=/run/mysqld/mysqld.sock -uroot <<EOSQL
CREATE DATABASE IF NOT EXISTS `${MYSQL_DATABASE}`;
CREATE USER IF NOT EXISTS '${MYSQL_USER}'@'%' IDENTIFIED BY '${MYSQL_PASSWORD}';
GRANT ALL PRIVILEGES ON `${MYSQL_DATABASE}`.* TO '${MYSQL_USER}'@'%';
ALTER USER 'root'@'localhost' IDENTIFIED BY '${MYSQL_ROOT_PASSWORD}';
FLUSH PRIVILEGES;
EOSQL
  mariadb-admin --socket=/run/mysqld/mysqld.sock -uroot -p"$MYSQL_ROOT_PASSWORD" shutdown
  wait "$temp_pid"
fi

Ce que fait chaque partie

1. --skip-networking : empêche toute connexion réseau pendant le bootstrap.
2. for … seq 1 30 : attente bornée, pas une boucle infinie.
3. CREATE DATABASE/USER : crée l’espace et l’identité WordPress.
4. GRANT : limite les droits à la seule base WordPress.
5. shutdown/wait : ferme proprement l’instance temporaire.

Résultat attendu

La base et l’utilisateur sont créés une seule fois, sans loguer les mots de passe.

Si cela échoue

Les quotes dans un secret nécessitent un échappement SQL robuste. Validez et échappez les entrées ; ne les concaténez jamais depuis une entrée non maîtrisée.

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.

L’attente utilise un maximum de 30 essais.Le SQL crée la base indiquée par MYSQL_DATABASE.Le compte MYSQL_USER reçoit des droits seulement sur cette base.Le serveur temporaire est arrêté avant la suite.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 42 — Lancer le vrai serveur MariaDB

Objectif. Le container restera vivant parce que MariaDB tourne, pas grâce à une commande factice.

État du projet avant cette étape. L’initialisation est complète. Il manque la commande finale du script.

Comprendre le changement

exec remplace le shell par mariadbd. –console garde le serveur au premier plan. Docker voit alors le vrai processus, lui envoie les signaux d’arrêt et détecte un crash.

Interdit par le sujet · p. 7

Les boucles infinies, tail -f, bash et sleep infinity sont interdits ; le sujet demande de comprendre PID 1.

Faire une seule chose

Ajoute la dernière ligne. Le script MariaDB est maintenant complet. Reconstruis l’image pour que cette nouvelle version entre dans l’image.

Fichiers ou emplacements concernés

• srcs/requirements/mariadb/tools/entrypoint.sh

À ÉCRIRE DANS📄 Dernière ligne de srcs/requirements/mariadb/tools/entrypoint.sh

Copier

exec mariadbd --user=mysql --console

Ce que fait chaque partie

1. exec : remplace le shell par MariaDB.
2. --user=mysql : abandonne les privilèges root.
3. --console : garde le serveur au premier plan et envoie les logs à Docker.

Résultat attendu

docker top mariadb montre mariadbd comme processus principal.

Si cela échoue

Si le container sort, lisez docker compose logs mariadb ; n’ajoutez pas tail -f.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose -f srcs/docker-compose.yml build mariadb

Ce que fait chaque partie

1. Compose reconstruit l’image afin d’y copier le script final.

Résultat attendu

Le build se termine et remplace mariadb:inception.

Si cela échoue

Si le script n’est pas exécutable, relance chmod +x puis le build.

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.

La dernière ligne commence par exec mariadbd.Aucun tail, sleep infinity ou while true n’existe.L’image a été reconstruite après la modification.Tu peux expliquer pourquoi le vrai serveur reste au premier plan.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 43 — Relier la configuration runtime dans Compose

Objectif. Compose donnera à MariaDB son .env, ses deux secrets et sa politique de redémarrage.

État du projet avant cette étape. L’image est complète, mais le service Compose ne monte encore aucun secret et ne charge aucune variable.

Comprendre le changement

env_file injecte les valeurs de srcs/.env. environment donne au script les chemins des secrets. secrets autorise leurs montages. restart demande à Docker de relancer le container après un crash.

Exigence du sujet · pp. 6–7

Les variables et .env sont obligatoires ; les containers doivent redémarrer après un crash.

Faire une seule chose

Complète le service mariadb sans ajouter encore de volume ni de réseau. Ajoute aussi la section secrets au niveau global, tout à gauche du fichier.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · état complet à ce moment du cours

Copier

services:
  mariadb:
    image: mariadb:inception
    build:
      context: ./requirements/mariadb
      dockerfile: Dockerfile
    env_file: .env
    environment:
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
    secrets:
      - db_password
      - db_root_password
    restart: unless-stopped

secrets:
  db_password:
    file: ../secrets/db_password.txt
  db_root_password:
    file: ../secrets/db_root_password.txt

Ce que fait chaque partie

1. env_file charge les variables non secrètes.
2. environment transmet les chemins attendus.
3. secrets du service monte les fichiers autorisés.
4. secrets global indique les sources locales.
5. restart relance après un crash.

Résultat attendu

Compose décrit toujours un seul service, maintenant prêt à recevoir ses valeurs runtime.

Si cela échoue

Utilise docker compose config après chaque changement d’indentation.

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.

Compose contient toujours un seul service mariadb.Le service charge .env et deux secrets.La section secrets globale est au niveau de services.restart vaut unless-stopped.Aucun volume et aucun réseau ne sont encore présents.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.

Étape 44 — Démarrer le premier container du projet

Objectif. MariaDB tournera réellement sous le contrôle de Compose.

État du projet avant cette étape. Compose sait construire et configurer MariaDB. Le service n’a toujours pas de volume : c’est volontaire.

Comprendre le changement

up -d crée puis démarre le container. ps montre son état. logs montre ce que le processus écrit. On ne continue que si l’état reste Up.

Exigence du sujet · p. 6

MariaDB doit tourner seul dans un container dédié.

Faire une seule chose

Lance MariaDB, attends quelques secondes, puis regarde ps et les logs. À ce stade, seul MariaDB doit exister.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose --env-file srcs/.env -f srcs/docker-compose.yml up -d --build mariadb
docker compose -f srcs/docker-compose.yml ps
docker compose -f srcs/docker-compose.yml logs --tail=60 mariadb

Ce que fait chaque partie

1. up crée et démarre le service.
2. -d rend le terminal.
3. --build garde l’image à jour.
4. ps affiche l’état.
5. logs montre le démarrage.

Résultat attendu

mariadb reste Up et les logs indiquent que le serveur accepte les connexions.

Si cela échoue

Si le service redémarre, lis la première erreur : secret absent, permission ou syntaxe.

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.

docker compose ps montre seulement mariadb.Le statut reste Up après quelques secondes.Les logs ne révèlent aucun secret.Aucun port 3306 n’est publié.

Question de soutenance — Pourquoi l’initialisation doit-elle être idempotente ?

Elle ne doit pas recréer ni écraser la base lorsque des données existent déjà.