Guide · WordPress et MySQL sur un seul conteneur

Vue d'ensemble

Le parcours en quatre étapes

La grande idée : deux processus tournent dans le même conteneur. MySQL en arrière-plan, Apache en avant-plan, un script de démarrage maison fait l'orchestration. Et au lieu d'installer un WordPress vide, vous redéployez un site qui existe vraiment : la boutique en ligne de Cornucopia.

Étape 01 · Serveur

Construire l'image LAMP

Étape 02 · Site

Redéployer le WordPress de Cornucopia

Étape 03 · Lien

Perdre les données, puis les protéger avec un volume

Étape 04 · Charge

Tester la charge avec JMeter

Construire l'image : une base officielle, MySQL ajouté à la main

Serveur

Partir de l'image officielle php:8.2-apache de Docker Hub et y ajouter MariaDB, pour obtenir une pile LAMP complète dans une seule image que vous maîtrisez de bout en bout.

Pour mieux comprendre

Un conteneur démarre en exécutant un seul programme : ce que dit le CMD ou le ENTRYPOINT du Dockerfile. Quand ce programme se termine, le conteneur s'arrête. Pour faire cohabiter Apache et MariaDB, le ENTRYPOINT sera un script bash qui lance MariaDB en arrière-plan puis garde Apache en avant-plan (le PID 1). Ce pattern « tout-en-un » est détaillé dans le guide PHP, Apache et MariaDB et son laboratoire Web et données : même recette, application différente.

Indications - le serveur web

Image de base : php:8.2-apache, l'image officielle maintenue par l'équipe PHP.
Compléter le Dockerfile : copier demarrer-services.sh dans /usr/local/bin/, le rendre exécutable, le déclarer comme ENTRYPOINT.
Exposer le port 80 dans le Dockerfile (EXPOSE 80) et le « forwarder » au port 8080 avec l'option -p "8080:80" au lancement du conteneur.
Activer la réécriture d'adresses pour les permaliens : a2enmod rewrite, et autoriser les fichiers .htaccess en passant AllowOverride à All pour /var/www/html.

Indications - la base de données

Installer MariaDB via apt : apt-get update && apt-get install -y --no-install-recommends mariadb-server mariadb-client.
WordPress parle à sa base avec l'extension mysqli : docker-php-ext-install mysqli. Cette commande est fournie par les images officielles PHP.
Nettoyer le cache apt après l'installation : apt-get clean && rm -rf /var/lib/apt/lists/*.

Squelette à compléter :

Dockerfile - squelette

FROM image-de-base

ENV DEBIAN_FRONTEND=noninteractive

# Installer MariaDB, l'extension mysqli, activer la réécriture
RUN apt-get update \
    && apt-get install -y --no-install-recommends paquets \
    && docker-php-ext-install extension \
    && a2enmod rewrite \
    && sed -ri 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Script de démarrage
COPY demarrer-services.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/demarrer-services.sh

# Préparer le dossier de données MariaDB
RUN mkdir -p /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql

EXPOSE 80

ENTRYPOINT ["/usr/local/bin/demarrer-services.sh"]

Et le script de démarrage, coeur du pattern tout-en-un :

demarrer-services.sh - squelette

#!/bin/bash
set -e

# 1. Démarrer MariaDB en arrière-plan
service mariadb start

# 2. Attendre que MariaDB réponde
until commande-de-ping; do
    sleep 1
done

# 3. Premier démarrage : préparer la base (voir l'étape 02)

# 4. Apache en avant-plan = PID 1 du conteneur
exec commande-apache

Sans exec devant apache2-foreground, le script bash reste PID 1 et Apache devient son enfant : lors d'un docker stop, le signal d'arrêt n'atteint pas Apache proprement. Avec exec, Apache remplace le script et reçoit les signaux directement.

L'image se construit sans erreur avec docker build -t boutique-cornucopia:1.0 . et un conteneur lancé avec -p "8080:80" affiche une page (même vide ou une erreur PHP : c'est normal, le site arrive à l'étape 02).

🐳Dockerfile
étape 01

Les vraies valeurs de la démonstration en classe (La Table Ronde). Pour votre Cornucopia, reprenez la structure et adaptez les valeurs à votre sauvegarde.

Dockerfile - état à la fin de l'étape 01

# Démonstration - La Table Ronde sur un seul conteneur
FROM php:8.2-apache

ENV DEBIAN_FRONTEND=noninteractive

# Installer MariaDB, l'extension mysqli, activer la réécriture d'adresses
RUN apt-get update \
    && apt-get install -y --no-install-recommends mariadb-server mariadb-client \
    && docker-php-ext-install mysqli \
    && a2enmod rewrite \
    && sed -ri 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# PHP de php:8.2-apache ne connaît pas le socket de MariaDB Debian :
# sans ces deux lignes, WordPress avec DB_HOST=localhost répond
# « Erreur lors de la connexion à la base de données » (piège classique).
RUN { \
        echo "mysqli.default_socket=/run/mysqld/mysqld.sock"; \
        echo "pdo_mysql.default_socket=/run/mysqld/mysqld.sock"; \
    } > /usr/local/etc/php/conf.d/socket-mariadb.ini

# Script de démarrage : MariaDB en arrière-plan, Apache en avant-plan
COPY demarrer-services.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/demarrer-services.sh

# Préparer le dossier de données MariaDB
RUN mkdir -p /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql

EXPOSE 80

ENTRYPOINT ["/usr/local/bin/demarrer-services.sh"]

demarrer-services.sh - état à la fin de l'étape 01

#!/bin/bash
set -e

# 1. Démarrer MariaDB en arrière-plan
service mariadb start

# 2. Attendre que MariaDB réponde
until mysqladmin ping --silent; do
    sleep 1
done

# 3. Premier démarrage : préparer la base (viendra à l'étape 02)

# 4. Apache en avant-plan = PID 1 du conteneur
exec apache2-foreground

Redéployer le site : Cornucopia renaît dans votre conteneur

Site

Pas d'installation de WordPress : vous redéployez un site qui existe déjà. Les fichiers et la base de données de cornucopia.projet.autos reprennent vie dans votre conteneur, articles et boutique compris.

Pour mieux comprendre

Un site WordPress, c'est exactement deux choses : des fichiers (le coeur WordPress, le thème, les extensions, les images téléversées) et une base de données (articles, pages, réglages, comptes). Qui possède ces deux morceaux peut faire renaître le site n'importe où : c'est la transplantation d'un site vivant, une opération que les administrateurs systèmes font constamment (migration de serveur, environnement de test, reprise après sinistre).

Indications - les fichiers

Déballez sauvegarde-cornucopia-web.zip dans votre répertoire de travail : vous obtenez fichiers-wordpress/ et base-de-donnees.sql à côté de votre Dockerfile.
Dans le Dockerfile : COPY fichiers-wordpress/ /var/www/html/, puis COPY base-de-donnees.sql /docker-entree/ pour le script de démarrage.
Terminez par chown -R www-data:www-data /var/www/html : Apache doit pouvoir écrire (téléversements, mises à jour).
Ouvrez fichiers-wordpress/wp-config.php et notez trois valeurs : DB_NAME, DB_USER, DB_PASSWORD. Le README.md de la sauvegarde les récapitule. Votre MariaDB locale devra offrir exactement cette base et ce compte.

Indications - la base de données

Dans demarrer-services.sh, au premier démarrage seulement (fichier témoin, comme au laboratoire Web et données) :

demarrer-services.sh - bloc d'initialisation

cheminFichierTemoin="/var/lib/mysql/initialise.flag"

if [ ! -f "$cheminFichierTemoin" ]; then
    # Créer la base et le compte attendus par wp-config.php
    mysql -e "CREATE DATABASE nom-de-la-base;
        CREATE USER 'utilisateur'@'localhost' IDENTIFIED BY 'mot-de-passe';
        GRANT ALL PRIVILEGES ON nom-de-la-base.* TO 'utilisateur'@'localhost';"

    # Importer la sauvegarde de la base de Cornucopia
    mysql nom-de-la-base < /docker-entree/base-de-donnees.sql

    touch "$cheminFichierTemoin"
fi

Indications - inspecter la base avec Adminer

phpMyAdmin ne vient pas avec l'image officielle; on utilise Adminer, le même genre d'outil en un seul fichier PHP.

Télécharger adminer.php (un seul fichier) depuis adminer.org et le déposer dans /var/www/html/ (par le Dockerfile, ou avec docker cp dans un conteneur en marche).
Ouvrir http://localhost:8080/adminer.php et se connecter avec les valeurs de wp-config.php (serveur localhost).
Explorer : la table wp_posts contient les articles, wp_users les comptes, wp_options les réglages du site.

Adminer affiche les tables de la base cornucopia et on retrouve les articles de la boutique dans wp_posts.

Indications - l'adresse du site

La base importée croit que le site vit à https://cornucopia.projet.autos. Il faut le convaincre qu'il habite maintenant http://localhost:8080 : c'est le repointage vu à la démonstration en classe, complété par un remplacement en masse de l'ancienne adresse dans le contenu (liens et images des articles). Dans demarrer-services.sh, juste après l'import :

demarrer-services.sh - à la suite de l'import

# Repointer l'adresse du site (réglages), puis remplacer l'ancienne adresse partout dans le contenu
mysql nom-de-la-base -e "UPDATE wp_options SET option_value='http://localhost:8080'
        WHERE option_name IN ('siteurl','home');
    UPDATE wp_posts SET post_content = REPLACE(post_content,
        'https://cornucopia.projet.autos', 'http://localhost:8080');
    UPDATE wp_posts SET guid = REPLACE(guid,
        'https://cornucopia.projet.autos', 'http://localhost:8080');"

Sans ce remplacement, le site s'affiche quand même... mais ses liens et ses images pointent encore vers cornucopia.projet.autos : en cliquant, vous passez sans vous en apercevoir sur le site en ligne (le vrai) au lieu du vôtre. Vérifiez l'adresse dans la barre du navigateur avant de conclure que « ça marche ».

Les administrateurs de sites WordPress font ce remplacement avec wp search-replace (outil WP-CLI), qui parcourt TOUTES les tables et respecte les données sérialisées de WordPress. Nos trois requêtes couvrent l'essentiel pour le laboratoire; retenez surtout que le remplacement en masse de l'adresse est l'étape incontournable de toute transplantation d'un site WordPress.

Sur http://localhost:8080, la boutique de Cornucopia s'affiche avec ses articles et ses images, servie par votre conteneur.

🐳Dockerfile
étape 02

Les vraies valeurs de la démonstration en classe (base tableronde, compte alice). Pour votre Cornucopia : les valeurs de wp-config.php de VOTRE sauvegarde, et l'ancienne adresse https://cornucopia.projet.autos dans les remplacements.

Dockerfile - état à la fin de l'étape 02

# Démonstration - La Table Ronde sur un seul conteneur
# Contexte de construction attendu (le zip extrait à côté de ce Dockerfile) :
#   fichiers-wordpress/    le code du site
#   base-de-donnees.sql    l'export de la base
FROM php:8.2-apache

ENV DEBIAN_FRONTEND=noninteractive

# Installer MariaDB, l'extension mysqli, activer la réécriture d'adresses
RUN apt-get update \
    && apt-get install -y --no-install-recommends mariadb-server mariadb-client \
    && docker-php-ext-install mysqli \
    && a2enmod rewrite \
    && sed -ri 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# PHP de php:8.2-apache ne connaît pas le socket de MariaDB Debian :
# sans ces deux lignes, WordPress avec DB_HOST=localhost répond
# « Erreur lors de la connexion à la base de données » (piège classique).
RUN { \
        echo "mysqli.default_socket=/run/mysqld/mysqld.sock"; \
        echo "pdo_mysql.default_socket=/run/mysqld/mysqld.sock"; \
    } > /usr/local/etc/php/conf.d/socket-mariadb.ini

# Le site de départ : fichiers copiés, Apache doit pouvoir écrire
COPY fichiers-wordpress/ /var/www/html/
RUN chown -R www-data:www-data /var/www/html

# La base de données de départ, importée au premier démarrage
COPY base-de-donnees.sql /site-de-depart/base-de-donnees.sql

# Script de démarrage : MariaDB en arrière-plan, Apache en avant-plan
COPY demarrer-services.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/demarrer-services.sh

# Préparer le dossier de données MariaDB
RUN mkdir -p /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql

EXPOSE 80

ENTRYPOINT ["/usr/local/bin/demarrer-services.sh"]

demarrer-services.sh - état à la fin de l'étape 02

#!/bin/bash
set -e

# 1. Démarrer MariaDB en arrière-plan
service mariadb start

# 2. Attendre que MariaDB réponde
until mysqladmin ping --silent; do
    sleep 1
done

# 3. Premier démarrage seulement : créer la base, le compte d'Alice,
#    importer le site de départ, repointer l'adresse et remplacer
#    l'ancienne adresse partout dans le contenu
if [ ! -d /var/lib/mysql/tableronde ]; then
    mysql <<'FIN_SQL'
CREATE DATABASE tableronde;
CREATE USER 'alice'@'localhost' IDENTIFIED BY 'taverne-2026';
GRANT ALL PRIVILEGES ON tableronde.* TO 'alice'@'localhost';
FLUSH PRIVILEGES;
FIN_SQL
    mysql tableronde < /site-de-depart/base-de-donnees.sql
    adresseInstance="${ADRESSE_INSTANCE:-http://localhost:8080}"
    mysql tableronde -e "UPDATE wp_options SET option_value='${adresseInstance}'
        WHERE option_name IN ('siteurl','home');"
    mysql tableronde -e "UPDATE wp_posts SET post_content = REPLACE(post_content,
        'https://table-ronde.projet.autos', '${adresseInstance}');"
    mysql tableronde -e "UPDATE wp_posts SET guid = REPLACE(guid,
        'https://table-ronde.projet.autos', '${adresseInstance}');"
fi

# 4. Apache en avant-plan = PID 1 du conteneur
exec apache2-foreground

Le lien manquant : perdre les données, puis les protéger

Lien

Vivre le problème avant d'apprendre le remède : détruire le conteneur, constater la perte, puis introduire le volume qui relie les données du conteneur au monde extérieur.

Démarche - d'abord, la catastrophe

Site en marche, connectez-vous au tableau de bord et laissez une trace : publiez un court article (« Journal de bord du laboratoire ») ou modifiez le slogan du site.
Vérifiez que votre changement est visible sur le site.
Détruisez le conteneur : docker rm -f suivi du nom de votre conteneur.
Relancez un conteneur neuf avec le même docker run qu'avant.
Rechargez la page. La boutique est là... mais votre article a disparu.

Pour mieux comprendre

Le conteneur neuf est reparti de l'image, et l'image contient la sauvegarde de Cornucopia telle que fournie : tout ce qui a été écrit APRÈS le premier démarrage (votre article, dans les fichiers de données de MariaDB) vivait dans la couche du conteneur détruit. docker stop puis docker start du même conteneur aurait tout gardé; c'est docker rm qui a jeté la couche d'écriture. Or détruire et recréer les conteneurs, c'est la vie normale d'une application conteneurisée : mise à jour de l'image, changement de configuration, déplacement de serveur.

Démarche - ensuite, le remède

Créez un répertoire de travail sur la machine hôte, par exemple ~/conteneur/mysql.
Relancez le conteneur en reliant ce répertoire au dossier de données de MariaDB :

Terminal - le volume entre en scène

$ docker run -d --name "cornucopia-en-marche" \
    -p "8080:80" \
    -v "${PWD}/mysql:/var/lib/mysql" \
    nom-image

Republiez votre article de test.
Détruisez le conteneur (docker rm -f), relancez avec la même commande.
Rechargez : cette fois, l'article a survécu à la destruction du conteneur.

Le répertoire hôte monté sur /var/lib/mysql masque ce que l'image contenait à cet endroit. Si votre initialisation de la base se faisait au build (dans le Dockerfile), elle disparaît sous le volume : c'est pour cela que le guide la fait au démarrage, dans demarrer-services.sh, avec le fichier témoin posé DANS /var/lib/mysql. Premier lancement avec volume : le répertoire est vide, le script initialise. Lancements suivants : le témoin est là, on n'écrase rien.

Vous savez démontrer le cycle complet : article publié, conteneur détruit et recréé sans volume = article perdu; avec volume = article conservé. C'est exactement la démonstration de persistance exigée dans l'évaluation.

🐳Dockerfile
étape 03

Le Dockerfile et demarrer-services.sh ne changent pas à cette étape : le volume se joue au lancement du conteneur. Le test du premier démarrage ([ ! -d /var/lib/mysql/tableronde ]) fait office de fichier témoin : premier lancement avec volume, le répertoire est vide, le script initialise; lancements suivants, la base est là, on n'écrase rien.

Terminal - le lancement complet de la démonstration

$ docker build -t boutique-table-ronde:1.0 .
$ mkdir -p mysql
$ docker run -d --name "boutique" \
    -p "8080:80" \
    -v "${PWD}/mysql:/var/lib/mysql" \
    boutique-table-ronde:1.0

Dockerfile - état à la fin de l'étape 03 (identique à l'étape 02)

# Démonstration - La Table Ronde sur un seul conteneur
# Contexte de construction attendu (le zip extrait à côté de ce Dockerfile) :
#   fichiers-wordpress/    le code du site
#   base-de-donnees.sql    l'export de la base
FROM php:8.2-apache

ENV DEBIAN_FRONTEND=noninteractive

# Installer MariaDB, l'extension mysqli, activer la réécriture d'adresses
RUN apt-get update \
    && apt-get install -y --no-install-recommends mariadb-server mariadb-client \
    && docker-php-ext-install mysqli \
    && a2enmod rewrite \
    && sed -ri 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# PHP de php:8.2-apache ne connaît pas le socket de MariaDB Debian
RUN { \
        echo "mysqli.default_socket=/run/mysqld/mysqld.sock"; \
        echo "pdo_mysql.default_socket=/run/mysqld/mysqld.sock"; \
    } > /usr/local/etc/php/conf.d/socket-mariadb.ini

# Le site de départ : fichiers copiés, Apache doit pouvoir écrire
COPY fichiers-wordpress/ /var/www/html/
RUN chown -R www-data:www-data /var/www/html

# La base de données de départ, importée au premier démarrage
COPY base-de-donnees.sql /site-de-depart/base-de-donnees.sql

# Script de démarrage : MariaDB en arrière-plan, Apache en avant-plan
COPY demarrer-services.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/demarrer-services.sh

# Préparer le dossier de données MariaDB
RUN mkdir -p /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql

EXPOSE 80

ENTRYPOINT ["/usr/local/bin/demarrer-services.sh"]

Tester la charge : le conteneur sous pression

Charge

Cette partie ne change pas : les mêmes tests de charge que d'habitude, cette fois pointés sur votre WordPress conteneurisé.

Indications

Suivez le laboratoire Test de charge : installation de JMeter, plan de test, montée en charge progressive.
Cible des tests : http://localhost:8080/, la page d'accueil de votre Cornucopia conteneurisée.
Relevez les mêmes indicateurs que d'habitude : temps de réponse moyen, débit, taux d'erreur selon le nombre d'utilisateurs simultanés.

Indications - le tableau des mesures 10 s / 60 s

Pendant que JMeter frappe, prenez deux instantanés : à 10 secondes et à 60 secondes de charge. La consommation du conteneur s'observe avec docker stats (colonne CPU %), le temps moyen de réponse vient du rapport JMeter. Cliquez dans les cellules pour inscrire vos mesures : elles restent enregistrées dans votre navigateur.

secondes / mesure	CPU du conteneur (docker stats)	temps moyen de réponse (seconde)
10 secondes
60 secondes

Vous avez un rapport JMeter contre le conteneur et le tableau 10 s / 60 s est rempli, avec vos observations : à partir de combien d'utilisateurs simultanés le temps de réponse se dégrade-t-il ? Gardez ces chiffres, ils serviront de point de comparaison pour la suite du cours.

🐳Dockerfile
final

Les tests de charge ne touchent pas à l'image : le Dockerfile final est celui de l'étape 03. Le voici en un seul morceau, l'état complet que votre dépôt Git doit contenir (avec demarrer-services.sh de l'étape 02).

Dockerfile - état final du laboratoire

# Démonstration - La Table Ronde sur un seul conteneur
# Contexte de construction attendu (le zip extrait à côté de ce Dockerfile) :
#   fichiers-wordpress/    le code du site
#   base-de-donnees.sql    l'export de la base
FROM php:8.2-apache

ENV DEBIAN_FRONTEND=noninteractive

# Installer MariaDB, l'extension mysqli, activer la réécriture d'adresses
RUN apt-get update \
    && apt-get install -y --no-install-recommends mariadb-server mariadb-client \
    && docker-php-ext-install mysqli \
    && a2enmod rewrite \
    && sed -ri 's/AllowOverride None/AllowOverride All/' /etc/apache2/apache2.conf \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# PHP de php:8.2-apache ne connaît pas le socket de MariaDB Debian
RUN { \
        echo "mysqli.default_socket=/run/mysqld/mysqld.sock"; \
        echo "pdo_mysql.default_socket=/run/mysqld/mysqld.sock"; \
    } > /usr/local/etc/php/conf.d/socket-mariadb.ini

# Le site de départ : fichiers copiés, Apache doit pouvoir écrire
COPY fichiers-wordpress/ /var/www/html/
RUN chown -R www-data:www-data /var/www/html

# La base de données de départ, importée au premier démarrage
COPY base-de-donnees.sql /site-de-depart/base-de-donnees.sql

# Script de démarrage : MariaDB en arrière-plan, Apache en avant-plan
COPY demarrer-services.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/demarrer-services.sh

# Préparer le dossier de données MariaDB
RUN mkdir -p /var/lib/mysql && chown -R mysql:mysql /var/lib/mysql

EXPOSE 80

ENTRYPOINT ["/usr/local/bin/demarrer-services.sh"]

WordPress et MySQL
dans un seul conteneur

Pré-requis

Le parcours en quatre étapes

Construire l'image : une base officielle, MySQL ajouté à la main

Pour mieux comprendre

Indications - le serveur web

Indications - la base de données

Redéployer le site : Cornucopia renaît dans votre conteneur

Pour mieux comprendre

Indications - les fichiers

Indications - la base de données

Indications - inspecter la base avec Adminer

Indications - l'adresse du site

Le lien manquant : perdre les données, puis les protéger

Démarche - d'abord, la catastrophe

Pour mieux comprendre

Démarche - ensuite, le remède

Tester la charge : le conteneur sous pression

Indications

Indications - le tableau des mesures 10 s / 60 s

Le Dockerfile final, d'un seul tenant

Défis facultatifs