WordPress : Architecture pod, volumes et workflow K3s

Le deploiement WordPress sur K3s repose sur une architecture pod multi-containers avec separation stricte des responsabilites. Cet article detaille la structure du pod, la gestion des volumes, les ConfigMaps et le workflow de mise a jour.

Architecture du pod

Chaque pod WordPress contient quatre containers et un initContainer :

flowchart TD
    subgraph pod ["Pod WordPress"]
        direction TB
        INIT["initContainer<br/>wordpress-files<br/>Copie WP core"] --> EMPTY["emptyDir<br/>wordpress-data"]
        EMPTY --> NGX["nginx<br/>Serveur web"]
        EMPTY --> PHP["php-fpm<br/>Runtime PHP"]
        NGX --- NGXEXP["nginx-exporter<br/>Metriques Prometheus"]
        PHP --- PHPEXP["phpfpm-exporter<br/>Metriques Prometheus"]
    end
    PVC["PVC Longhorn<br/>wp-content"] --> NGX
    PVC --> PHP
    CM["ConfigMaps<br/>wp-config, php.ini,<br/>www.conf, nginx.conf"] --> NGX
    CM --> PHP
    style INIT fill:#3498db,color:#fff
    style EMPTY fill:#9b59b6,color:#fff
    style PVC fill:#e67e22,color:#fff
    style CM fill:#1abc9c,color:#fff

Pourquoi un initContainer ?

L'image php-fpm-hardened est construite FROM scratch : elle ne contient ni shell, ni cp, ni aucun utilitaire systeme. Il est donc impossible de copier les fichiers WordPress core au demarrage du container PHP.

L'image wordpress-files (basee sur Alpine) sert d'initContainer : elle contient le code source WordPress pre-extrait et un shell pour copier les fichiers dans le volume partage emptyDir avant que les containers principaux ne demarrent.

# Extrait du Deployment
initContainers:
- name: wordpress-files
  image: jbsky/wordpress-files:6.8.3
  command: ["sh", "-c", "cp -a /usr/src/wordpress/. /var/www/html/"]
  volumeMounts:
  - name: wordpress-data
    mountPath: /var/www/html

Strategie de volumes

Deux types de volumes coexistent avec des roles distincts :

emptyDir : wordpress-data

Volume ephemere cree a chaque demarrage du pod. L'initContainer y copie les fichiers core WordPress (wp-admin, wp-includes, index.php, etc.). Ce volume est partage entre les containers nginx et php-fpm. Son contenu est recree a chaque redemarrage, ce qui garantit que le code core est toujours celui de l'image.

PVC Longhorn : wp-content

Volume persistant gere par Longhorn pour le repertoire wp-content/ qui contient les donnees specifiques au site :

themes/ : themes WordPress installes
plugins/ : extensions installees et configurees
uploads/ : medias uploades par les utilisateurs
cache/ : fichiers de cache generes

Ce volume survit aux redemarrages et aux mises a jour de l'image WordPress.

ConfigMaps et subPath

Les fichiers de configuration sont injectes via ConfigMaps avec des montages subPath :

volumeMounts:
- name: wp-config
  mountPath: /var/www/html/wp-config.php
  subPath: wp-config.php
- name: php-config
  mountPath: /usr/local/etc/php/php.ini
  subPath: php.ini
- name: fpm-config
  mountPath: /usr/local/etc/php-fpm.d/www.conf
  subPath: www.conf

Gotcha subPath : contrairement aux montages de volume classiques, les fichiers montes avec subPath sont figes a la creation du pod. kubelet met bien a jour le contenu de la ConfigMap sur le node (~1 minute), mais le fichier monte dans le container garde sa valeur initiale. Un rollout restart du deployment est obligatoire apres chaque modification de ConfigMap.

Configuration WordPress specifique

FS_METHOD=direct

Sans cette constante dans wp-config.php, WordPress tente d'utiliser FTP pour installer les plugins et themes. Avec FS_METHOD a direct, WordPress ecrit directement sur le filesystem -- ce qui est possible grace au fsGroup: 1999 qui donne au processus PHP les droits d'ecriture sur le PVC.

AUTOMATIC_UPDATER_DISABLED

Les mises a jour automatiques de WordPress sont desactivees. Le code core vit dans l'image Docker (immutable) et les mises a jour passent par un rebuild de l'image wordpress-files. Laisser wp-admin mettre a jour le core creerait une incoherence : les fichiers modifies dans le emptyDir seraient perdus au prochain redemarrage du pod.

Cache Varnish

Un cache Varnish est place devant le pod WordPress pour absorber le trafic de lecture. Le healthcheck Kubernetes pointe vers /healthcheck (endpoint dedie) et non vers / (page d'accueil) pour eviter de polluer le cache avec des requetes internes.

flowchart LR
    A["Traefik"] --> B["Varnish<br/>Cache HTTP"]
    B -- "Cache HIT" --> C["Reponse directe"]
    B -- "Cache MISS" --> D["nginx<br/>Serveur web"]
    D --> E["php-fpm<br/>Execution PHP"]
    E --> F["MariaDB"]
    style B fill:#9b59b6,color:#fff
    style C fill:#27ae60,color:#fff

Securite du pod

Le pod applique des contraintes de securite strictes :

securityContext:
  runAsUser: 1999
  runAsGroup: 1999
  fsGroup: 1999
  runAsNonRoot: true

Tous les containers s'executent sous l'UID 1999 (non-root). Le fsGroup garantit que les fichiers du PVC Longhorn sont accessibles en lecture/ecriture par le processus PHP. L'initContainer wordpress-files s'execute egalement en non-root.

Workflow de mise a jour WordPress

flowchart TD
    A["Nouvelle version WordPress"] --> B["Build image<br/>wordpress-files:X.Y.Z"]
    B --> C["Push Docker Hub"]
    C --> D["Patch Deployment<br/>initContainer image tag"]
    D --> E["rollout restart"]
    E --> F["initContainer copie<br/>nouveau WP core"]
    F --> G["Containers demarrent<br/>avec nouveau code"]
    G --> H{"Verification"}
    H -- "OK" --> I["Site mis a jour"]
    H -- "KO" --> J["rollback image tag<br/>precedent"]
    style I fill:#27ae60,color:#fff
    style J fill:#e74c3c,color:#fff

La mise a jour est atomique : soit le nouveau pod demarre avec le nouveau code, soit il echoue et Kubernetes conserve l'ancien pod. Le PVC wp-content n'est pas impacte par la mise a jour du core.

Articles lies

Image PHP-FPM hardened et WordPress FROM scratch : construction des images Docker
Cluster K3s Kubernetes homelab : infrastructure du cluster