Ajouter WordPress à Compose

Progression d’apprentissage0 / 404

0 / 27 validations dans ce chapitre

Réinitialiser la progression

Ajouter le deuxième service sans mélanger build, secrets, réseau et volume.

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

Étape 66 — Ajouter les valeurs WordPress locales

Objectif. Compose disposera des noms publics dans .env et des mots de passe dans secrets.

État du projet avant cette étape. L’image WordPress est prête, mais ses valeurs runtime ne sont pas encore écrites.

Comprendre le changement

Le domaine, le titre, les noms et les emails ne sont pas secrets : ils vont dans .env. Les deux mots de passe restent dans leurs fichiers locaux ignorés.

Interdit par le sujet · pp. 7, 10

Les variables d’environnement et .env sont obligatoires ; les credentials réels ne doivent pas être dans Git.

Faire une seule chose

Ajoute les six variables proposées dans srcs/.env. Remplis ensuite wp_admin_password.txt et wp_user_password.txt avec ton éditeur, sans afficher leur contenu.

Fichiers ou emplacements concernés

• srcs/.env
• secrets/wp_admin_password.txt
• secrets/wp_user_password.txt

À ÉCRIRE DANSFichier srcs/.env · remplace les valeurs d’exemple

Copier

DOMAIN_NAME=votrelogin.42.fr
WP_TITLE=Inception
WP_ADMIN_USER=site_owner
WP_ADMIN_EMAIL=owner@example.test
WP_USER=editor42
WP_USER_EMAIL=editor@example.test

Ce que fait chaque partie

1. DOMAIN_NAME est le futur nom local.
2. WP_ADMIN_USER respecte la règle car il ne contient pas admin.
3. Les emails peuvent être locaux pour le projet.
4. Aucun mot de passe n’est présent.

Résultat attendu

Les six variables sont ajoutées sans valeur confidentielle.

Si cela échoue

Ne nomme pas le compte admin42 : la sous-chaîne admin est interdite.

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.

DOMAIN_NAME utilise ton vrai login.WP_ADMIN_USER ne contient ni admin ni administrator.Les deux fichiers secrets WordPress sont non vides.Aucun mot de passe WordPress n’apparaît dans .env.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 67 — Déclarer l’identité et le build WordPress

Objectif. Compose passera de un à deux services sans lancer le nouveau.

État du projet avant cette étape. L’image est définie et les valeurs locales existent. Compose connaît toujours seulement MariaDB.

Comprendre le changement

Le premier morceau WordPress contient uniquement son nom, son image et son Dockerfile. Les variables, secrets, réseau et volume seront ajoutés séparément.

Exigence du sujet · p. 6

WordPress + PHP-FPM doit tourner dans un container dédié construit localement.

Faire une seule chose

Ajoute ce squelette sous mariadb dans services.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

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

Copier

  wordpress:
    image: wordpress:inception
    build:
      context: ./requirements/wordpress
      dockerfile: Dockerfile

Ce que fait chaque partie

1. wordpress est le deuxième nom de service.
2. image respecte le même nom.
3. build pointe vers le deuxième Dockerfile.

Résultat attendu

Compose décrit deux services et deux builds.

Si cela échoue

wordpress doit être sous services, pas imbriqué dans mariadb.

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.

wordpress est aligné avec mariadb.L’image s’appelle wordpress:inception.Le contexte vise requirements/wordpress.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 68 — Transmettre les variables et chemins de secrets

Objectif. Le futur entrypoint recevra les noms publics et les chemins confidentiels.

État du projet avant cette étape. Compose sait construire WordPress, mais son script ne recevrait aucune valeur au démarrage.

Comprendre le changement

env_file charge les valeurs non secrètes. environment transmet les chemins /run/secrets attendus. secrets autorise le montage de ces trois fichiers dans ce service.

Exigence du sujet · pp. 7, 10

Variables et .env sont obligatoires ; les vrais credentials doivent rester hors de Git.

Faire une seule chose

Ajoute ces blocs sous build. Ne déclare pas encore les sources globales des deux nouveaux secrets.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · dans wordpress

Copier

    env_file: .env
    environment:
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
      WP_ADMIN_PASSWORD_FILE: /run/secrets/wp_admin_password
      WP_USER_PASSWORD_FILE: /run/secrets/wp_user_password
    secrets:
      - db_password
      - wp_admin_password
      - wp_user_password

Ce que fait chaque partie

1. env_file charge srcs/.env.
2. environment contient seulement des chemins, pas les mots de passe.
3. secrets limite les fichiers montés dans WordPress.

Résultat attendu

Le service reçoit trois variables *_FILE et trois secrets.

Si cela échoue

N’écris jamais la valeur d’un mot de passe après les deux-points.

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.

env_file vaut .env.Les trois valeurs environment sont des chemins.Aucun mot de passe en clair n’apparaît.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 69 — Déclarer les deux secrets WordPress

Objectif. Compose saura quels fichiers locaux monter.

État du projet avant cette étape. Le service cite wp_admin_password et wp_user_password, mais la section secrets globale ne les définit pas encore.

Comprendre le changement

La déclaration globale associe un nom Compose à un fichier local ignoré par Git. Elle ne place pas la valeur dans le YAML.

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

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

Faire une seule chose

Ajoute les deux entrées à la section secrets existante, à côté des secrets MariaDB.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml
• secrets/

À ÉCRIRE DANSFichier srcs/docker-compose.yml · dans la section secrets globale

Copier

  wp_admin_password:
    file: ../secrets/wp_admin_password.txt
  wp_user_password:
    file: ../secrets/wp_user_password.txt

Ce que fait chaque partie

1. Chaque nom correspond exactement au nom cité par le service.
2. Les chemins partent du dossier srcs vers ../secrets.
3. Seul le chemin est versionné, pas la valeur.

Résultat attendu

Quatre secrets globaux existent au total.

Si cela échoue

undefined secret signifie que le nom du service et le nom global ne sont pas identiques.

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.

Les deux secrets WordPress sont déclarés globalement.Les chemins pointent vers le dossier secrets local.git status ne propose pas ces fichiers.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 70 — Connecter WordPress au réseau

Objectif. Le deuxième service pourra résoudre mariadb par son nom.

État du projet avant cette étape. MariaDB appartient au réseau inception ; WordPress n’est relié à aucun réseau explicite.

Comprendre le changement

Deux containers ne communiquent par leur nom que s’ils partagent un réseau Docker. Le nom stable à utiliser est mariadb, pas l’IP observée.

Exigence du sujet · p. 6

Un réseau Docker doit relier les containers ; ils doivent redémarrer après un crash.

Faire une seule chose

Ajoute inception au service WordPress puis une politique de redémarrage et depends_on pour l’ordre de création.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · dans wordpress

Copier

    networks:
      - inception
    depends_on:
      - mariadb
    restart: unless-stopped

Ce que fait chaque partie

1. networks place WordPress avec MariaDB.
2. depends_on ordonne la création mais ne garantit pas que MariaDB soit prête.
3. L’entrypoint garde donc son attente bornée.
4. restart traite un arrêt anormal.

Résultat attendu

WordPress partage inception et dépend de mariadb.

Si cela échoue

N’ajoute ni links, ni network_mode: host, ni IP fixe.

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.

WordPress rejoint inception.depends_on cite mariadb.restart est présent.Aucun link ou réseau hôte n’existe.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 71 — Déclarer le volume WordPress

Objectif. Tu créeras le deuxième stockage nommé sans encore l’attacher.

État du projet avant cette étape. Le service est configuré, mais /var/www/html serait encore interne au container.

Comprendre le changement

wordpress_data est un autre objet volume, avec un autre dossier hôte. Il ne doit jamais réutiliser mariadb_data.

Exigence du sujet · p. 6

Un deuxième volume nommé doit conserver les fichiers du site sous /home/login/data.

Faire une seule chose

Ajoute wordpress_data dans la section volumes globale existante.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · dans volumes global

Copier

  wordpress_data:
    name: wordpress_data
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /home/${LOGIN}/data/wordpress

Ce que fait chaque partie

1. wordpress_data est distinct de mariadb_data.
2. device vise le dossier wordpress de la VM.

Résultat attendu

Deux volumes globaux distincts apparaissent dans config.

Si cela échoue

Vérifie que le dossier /home/$USER/data/wordpress existe avant le démarrage.

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.

Deux volumes globaux existent.wordpress_data utilise le dossier wordpress.Il ne pointe jamais vers /var/lib/mysql.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 72 — Attacher le volume à WordPress

Objectif. Les fichiers du site sortiront du cycle de vie du container.

État du projet avant cette étape. wordpress_data existe dans le plan mais le service ne le monte pas.

Comprendre le changement

/var/www/html contient le cœur WordPress, wp-config.php, thèmes et extensions. C’est cette destination qui doit survivre.

Exigence du sujet · p. 6

Le deuxième volume doit contenir les fichiers du site WordPress.

Faire une seule chose

Ajoute le montage nommé dans le service WordPress.

Fichiers ou emplacements concernés

• srcs/docker-compose.yml

À ÉCRIRE DANSFichier srcs/docker-compose.yml · dans wordpress

Copier

    volumes:
      - wordpress_data:/var/www/html

Ce que fait chaque partie

1. La source est le volume nommé.
2. La destination est le dossier de travail WordPress.

Résultat attendu

WordPress monte wordpress_data sur /var/www/html.

Si cela échoue

Un chemin /home/... placé ici créerait un bind mount direct interdit.

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 service monte wordpress_data.La destination vaut /var/www/html.Aucun chemin hôte direct n’apparaît dans le service.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.

Étape 73 — Valider puis démarrer deux services

Objectif. Tu observeras la première communication réelle entre containers.

État du projet avant cette étape. Compose contient MariaDB et WordPress, leurs secrets, leurs volumes et le réseau.

Comprendre le changement

config vérifie le plan complet avant action. up construit et démarre les deux services. getent depuis WordPress prouve ensuite que le DNS Docker résout mariadb.

Exigence du sujet · pp. 6–7

WordPress et MariaDB doivent fonctionner dans deux containers dédiés reliés par le réseau.

Faire une seule chose

Valide, construis, démarre puis teste le DNS et les comptes WordPress. N’ajoute pas encore NGINX.

À EXÉCUTER DANSDans la VM · racine du repository

Copier

docker compose --env-file srcs/.env -f srcs/docker-compose.yml config
docker compose --env-file srcs/.env -f srcs/docker-compose.yml up -d --build mariadb wordpress
docker compose -f srcs/docker-compose.yml ps
docker compose -f srcs/docker-compose.yml exec wordpress getent hosts mariadb
docker compose -f srcs/docker-compose.yml exec wordpress wp user list --allow-root --path=/var/www/html

Ce que fait chaque partie

1. config valide avant de modifier l’exécution.
2. up construit puis démarre les deux services seulement.
3. ps montre leur stabilité.
4. getent teste le DNS interne.
5. wp user list interroge l’installation réelle.

Résultat attendu

Deux services restent Up, mariadb résout vers une IP privée et deux utilisateurs sont listés.

Si cela échoue

Si WordPress redémarre, lis d’abord ses logs puis ceux de MariaDB ; ne masque pas la panne avec une boucle infinie.

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 et WordPress sont Up.getent hosts mariadb retourne une adresse.Deux utilisateurs WordPress existent.Aucun port 3306 ou 9000 n’est publié.

Question de soutenance — Comment WordPress contacte-t-il la base ?

Par mariadb:3306 dans le réseau Docker partagé.