Ce qui suit a été réalisé sur une distribution Debian 13 en tant que serveur web (une VM), et j’accédais au site wordpress depuis mon laptop windows.

Techniquement ça sera la même démarche que le serveur web soit un windows ou une distribution linux.

Installer docker

Se référer à la documentation officielle pour installer docker.
Vous allez probablement travailler avec un utilisateur non root, dans ce cas il faut ajouter l’utilisateur au group docker afin qu’il puisse exécuter des commandes docker (car certains fichiers manipulés par docker requiert le groupe docker).

usermod -aG docker <your_user>

Récupérez un dump de votre base de données et une copie des source de votre site

Dans mon cas mon site web est hébergé chez OVH, mais le principe reste le même chez la plupart des hébergeurs :

  • Récupération d’un backup de la base de données (fichier avec l’extension .sql)
  • Récupération de l’intégralité des source wordpress via FTP (le plus simple est de créer un zip depuis l’hébergeur et récupérer le zip si l’option est disponible, sinon il suffit de récupérer l’intégralité du dossier contenant les sources)

Build d’une image d’un container docker avec apache + php

Dans le cas présent j’ai choisit la version php 8.2 (une version donc récente), avec un apache récent.

Fichier Dockerfile que j’ai nommé Dockerfile_apache-php8.2 :

FROM php:8.2-apache

# Installe les extensions nécessaires pour WordPress
# l’extension mysql (ancienne API PHP) a été supprimée depuis PHP 7.0 ;
# WordPress 5.2 n’utilise pas mysql_connect() directement, mais appelle parfois des fonctions via un vieux plugin ou un ancien fichier de compatibilité ;
# ton image PHP n’a pas d’extensions MySQLi ni PDO MySQL installées par défaut, et WordPress a besoin au minimum de mysqli.
# Ce qui suit est peut être optionnel, j'ai du installé ce éléments pour un vieux wordpress mais je n'ai pas testé pour un plus récent
RUN docker-php-ext-install mysqli pdo pdo_mysql

# Variables d'environnement pour ton domaine
ENV SERVER_NAME=codetodevops.com

# Active les modules Apache nécessaires
RUN a2enmod ssl rewrite headers

# Crée les dossiers nécessaires pour SSL
RUN mkdir -p /etc/apache2/ssl

# Génère un certificat auto-signé valable 365 jours
RUN openssl req -x509 -nodes -days 365 \
    -newkey rsa:2048 \
    -keyout /etc/apache2/ssl/selfsigned.key \
    -out /etc/apache2/ssl/selfsigned.crt \
    -subj "/C=FR/ST=France/L=Paris/O=LocalDev/CN=${SERVER_NAME}"

# Copie la configuration HTTPS personnalisée
COPY ./apache/ssl/ssl.conf /etc/apache2/sites-available/000-default-ssl.conf

# Active la configuration SSL
RUN a2ensite 000-default-ssl

# Expose le port HTTPS
EXPOSE 443

# Lancement du serveur Apache
CMD ["apache2-foreground"]

Au niveau du dossier contenant ce Dockerfile, j’ai créé un dossier apache/ssl dans lequel j’ai créé le fichier ssl.conf suivant :

<VirtualHost *:443>
    ServerName codetodevops.com
    ServerAlias www.codetodevops.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/selfsigned.crt
    SSLCertificateKeyFile /etc/apache2/ssl/selfsigned.key

    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/ssl-error.log
    CustomLog ${APACHE_LOG_DIR}/ssl-access.log combined
</VirtualHost>

DNS local pour accéder la VM locale depuis le nom de domaine du site

L’objectif est ici de ne pas taper dans un DNS public, et donc de ne pas taper sur le site publié, mais seulement sur la version locale du site.

Pour accéder au site codetodevops.com depuis mon laptop windows sans que ça aille taper sur le serveur OVH mais sur ma VM linux, j’ai édité le fichier hosts de windows (l’équivalent de /etc/hosts sur linux). Ce fichier se trouve dans le Disque local (C:), sélectionnez le dossier Windows > System32 > drivers > etc et vous trouverez le fichier hosts. L’IP de ma VM est 192.168.1.17, j’ai donc du ajouter les 2 lignes suivantes :

192.168.1.17 codetodevops.com
192.168.1.17 www.codetodevops.com

Docker compose : création d’un container apache+php et d’un container de base de données mariadb

Fichier docker-compose-apache-php8.2.yml :

services:
  wordpress:
    depends_on:
      db:
        condition: service_healthy
    image: my-php8.2-apache:v1
    build:
      context: .
      dockerfile: Dockerfile_apache-php8.2
    container_name: wp_local
    ports:
      - "443:443"
    volumes:
      - ./directory_source_codetodevops:/var/www/html
      - ./wait-for-it.sh:/wait-for-it.sh
    entrypoint: ["/wait-for-it.sh", "db:3306", "--", "apache2-foreground"]
    environment:
      - WORDPRESS_DB_HOST=db        # nom du service de base de données (ci-dessous)
      - WORDPRESS_DB_USER=U3541441  # Nom d'utilisateur de la base de données
      - WORDPRESS_DB_PASSWORD=xxxxx # Mot de passe de l'utilisateur de base de données
      - WORDPRESS_DB_NAME=DB3541441 # Nom de ma base de données
    networks:
      - wp-net

  db:
    image: mariadb:10.1
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 5s
      timeout: 5s
      retries: 5
    ulimits: # Pour résoudre bug d'utilisation excessive de la RAM
      nofile:
        soft: "65536"
        hard: "65536"
    container_name: wp_db
    environment:
      MYSQL_DATABASE: DB3541441
      MYSQL_USER: U3541441
      MYSQL_PASSWORD: xxxxx
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - ${PWD}/db_codetodevops/data:/var/lib/mysql
      - ${PWD}/db_codetodevops/init_scripts:/docker-entrypoint-initdb.d
    networks:
      - wp-net
      
networks:
  wp-net:
    driver: bridge
  • dossier db_codetodevops/data –> dossier qui contiendra les données de la base (persistence des données)
  • dossier db_codetodevops/init_scripts –> dossier dans lequel j’ai mis le backup de ma base de données (tous les fichiers .sql de ce dossier seront exécutés lors de la création du container de base de données)
  • dossier directory_source_codetodevops –> dossier dans lequel j’ai mis les sources du site wordpress
  • wait-for-it.sh –> est un petit script open source qui permet de scruter la base de données pour déterminer quand elle est disponible, et quand le container wp_local peut y accéder (source code ici)

Démarrage / Arrêt des containers

docker compose -f docker-compose-apache-php8.2.yml up -d
# Pour arrêter les containers :
docker compose down

Faites une sauvegarde de votre base de données depuis le container wp_db

docker exec wp_db mysqldump -u YourUserWordpress -pYourPasswordWordpress DBYOURWORDPRESSDB > ./dump_yourwebsite_w5.2_php7.3.sql

A l’inverse pour importer un dump mysql (par exemple une sauvegarde) dans votre container de base de données

docker exec -i wp_db mysql -u YourUserWordpress -pYourPasswordWordpress DBYOURWORDPRESSDB < ./dump_yourwebsite_w5.2_php7.3.sql

Rebuilder manuellement son image docker lorsqu’on change l’image Dockerfile_apache-php<version>

On peut rebuilder manuellement l’image d’un container précis, par exemple ici rebuild l’image du container qui contient wordpress…

docker image build -f Dockerfile_apache-php8.2 --no-cache -t my-php8.2-apache:v1 .

wordpress est le nom de service définit dans le docker-compose-apache-php8.2.yml juste après ‘services:’.

A noter qu’il n’est pas nécessaire de rebuilder manuellement l’image. Car celle-ci l’est automatiquement via le fichier de configuration de docker compose via l’instruction ‘build’, et le ‘context’ qui indique où chercher le dockerfile.

build:
  context: .
  dockerfile: Dockerfile_apache-php8.2

Différence entre une image docker de type wordpress:5.2-php7.3-apache et php:7.3-apache

La première contient un docker-entrypoint.sh qui va au lancement du container pour la première fois, copier les source de wordpress 5.2.
Egalement, il se trouve que cette image contenait quelques paquets linux indispensables au fonctionnement de wordpress 5.2 : mysqli pdo pdo_mysql
Donc cette image contient tout le nécessaire pour pouvoir faire tourner la version wordpress choisit (ici 5.2).
Tandis que l’image php:7.3-apache contient à peu près tout pareil, sauf qu’il n’y a pas d’installation de wordpress évidemment, mais également les paquets nécessaires pour une version de wordpress ancienne ne sont pas nécessairement installés.

Mise à jour manuelle de wordpress vs mise à jour automatique

La mise à jour manuelle de wordpress peut être intéressante pour faire des mises à jour par palier. Par exemple lorsque vous récupérez un vieux site wordpress tournant sur php 7 et wordpress 5.2, il sera peut être ambitieux de lancer directement une mise à jour vers la dernière version de wordpress.

Aussi lorsqu’on télécharge wordpress il n’y pas de questions à se poser concernant la langue, car celle-ci est indépendante du zip d’installation. Ainsi c’est seulement dans l’administration wordpress que vous pourrez choisir la langue.

Voici un exemple d’une mise à jour de wordpress 5.2 vers wordpress 5.9.12 (mise à jour par palier) :

sudo rm -rf source_directory_codetodevops/wp-includes
sudo rm -rf source_directory_codetodevops/wp-admin
sudo cp -R wordpress-5.9.12/wp-includes source_directory_codetodevops/
sudo cp -R wordpress-5.9.12/wp-admin source_directory_codetodevops/
sudo cp -R wordpress-5.9.12/wp-content/* source_directory_codetodevops/wp-content/
sudo cp wordpress-5.9.12/*.* source_directory_codetodevops/ # ceci copie uniquement les fichiers à la racines du dossier wordpress
sudo chown -R www-data: source_directory_codetodevops

Une erreur que j’ai eu sur un vieux wordpress : failed to open stream: No such file or directory in /var/www/html/wp-content/advanced-cache.php : cette erreur empêche d’accéder à l’administration

sudo rm -f source_directory_codetodevops/wp-content/advanced-cache.php

advanced-cache.php est un fichier qui a été copié lors de l’installation.

Suite à une mise à jour des sources de wordpress il se peut que wordpress ait besoin de mettre à jour sa base de données. Et dans ce cas il le proposera juste en affichant la page qui suit :