Docker pour WordPress : Pourquoi les conteneurs isolés changent tout

L'hébergement WordPress traditionnel place plusieurs sites sur un même serveur. Ils partagent PHP, l'accès au système de fichiers et souvent un serveur de base de données. Cela fonctionne jusqu'à ce que cela ne fonctionne plus – et quand cela ne fonctionne plus, c'est un problème sérieux.

PAGEnza provisionne chaque site WordPress dans son propre conteneur Docker. Cet article explique ce que cela signifie en pratique et pourquoi c'est important pour les agences gérant plusieurs sites clients.

Le problème de l'hébergement mutualisé

Sur un plan d'hébergement mutualisé typique ou même un VPS basique avec plusieurs installations WordPress :

Contention de ressources : un site subissant un pic de trafic ralentit tous les autres sites sur le serveur. Un plugin mal optimisé sur le site A dégrade les performances du site B.

Fuite de sécurité : si une installation WordPress est compromise – via un plugin vulnérable, un mot de passe faible ou une version obsolète du cœur – un attaquant qui obtient un accès au système de fichiers peut souvent lire les fichiers d'autres sites sur le même serveur.

Conflits de versions PHP : le site A a besoin de PHP 7.4 pour un ancien plugin. Le site B a besoin de PHP 8.2 pour un plus récent. Sur l'hébergement mutualisé, vous devez choisir.

Exposition de la base de données : les serveurs de bases de données partagés impliquent qu'une mauvaise configuration des permissions utilisateur peut exposer les données d'autres sites.

Les conteneurs Docker résolvent tous ces problèmes au niveau de l'infrastructure.

Qu'est-ce qu'un conteneur en réalité

Un conteneur Docker est un processus léger et isolé qui possède son propre :

• Système de fichiers (le conteneur ne peut pas voir les fichiers en dehors de ses limites)

• Pile réseau (sa propre adresse IP, ses propres ports)

• Espace de processus (il ne peut pas voir les processus des autres conteneurs)

• Limites de ressources (plafonds CPU et mémoire)

Il partage le noyau de l'hôte avec d'autres conteneurs, mais tout ce qui est au-dessus du noyau est isolé. Ce n'est pas une machine virtuelle complète – elle démarre en quelques secondes, pas en minutes, et utilise une fraction des ressources.

Pour WordPress, un seul conteneur exécute : Nginx, PHP-FPM et les fichiers WordPress. La base de données s'exécute dans un conteneur séparé, connecté uniquement à ce conteneur WordPress spécifique.

Comment PAGEnza provisionne un site

Lorsque vous créez un nouveau site client dans PAGEnza, voici ce qui se passe en moins de 45 secondes :

1. Un nouveau conteneur Docker est lancé à partir d'une image WordPress de base
2. WordPress est configuré avec une nouvelle base de données sur l'instance MariaDB partagée (isolée aux identifiants de ce conteneur)
3. Le plugin PAGEnza est automatiquement installé et activé
4. Un hôte virtuel Nginx est configuré avec le sous-domaine du client
5. SSL est émis via Let's Encrypt
6. Le conteneur est enregistré dans le proxy inverse avec les règles de routage correctes

Le client obtient une URL comme clientname.pagenza.com qui est en ligne dans les 45 secondes suivant le clic sur "Créer le site". Aucune configuration manuelle du serveur, aucun SSH, aucun temps d'attente DNS (pour le sous-domaine – la propagation DNS du domaine personnalisé est séparée).

Isolation des conteneurs en pratique

Limites de mémoire : chaque conteneur a un plafond de mémoire configurable. Si un plugin défaillant provoque un pic de mémoire sur le site d'un client, il ne peut pas consommer la mémoire allouée aux autres conteneurs. Le site peut ralentir ou renvoyer une erreur 503 – mais cela n'affectera pas les autres clients.

Isolation du système de fichiers : les fichiers WordPress du client A sont complètement invisibles pour le conteneur du client B. Un plugin compromis sur le site du client A n'a aucun chemin vers les fichiers du client B.

Isolation réseau : les conteneurs communiquent uniquement via des ponts réseau définis. Le conteneur de base de données du client A n'accepte que les connexions du conteneur WordPress du client A – pas de tout autre conteneur sur le système.

PHP par conteneur : comme chaque conteneur exécute sa propre instance PHP-FPM, vous pouvez exécuter différentes versions de PHP pour différents clients. Le plugin hérité du client A qui nécessite PHP 7.4 fonctionne parfaitement aux côtés de la pile moderne du client B sur PHP 8.2.

Domaines personnalisés

La configuration par défaut donne à chaque client un sous-domaine *.pagenza.com. Pour les clients qui souhaitent leur propre domaine, le processus est le suivant :

1. Le client pointe l'enregistrement A de son domaine vers l'adresse IP du serveur PAGEnza
2. Dans le tableau de bord PAGEnza, vous saisissez le domaine personnalisé
3. La configuration du proxy inverse est mise à jour automatiquement
4. SSL est émis pour le domaine personnalisé via Let's Encrypt

Les options siteurl et home de WordPress sont mises à jour en conséquence. Du point de vue du client, son site fonctionne simplement à son domaine – pas de redirection, pas de sous-domaine visible pour les visiteurs.

Ce que cela signifie pour les agences

L'avantage pratique pour les agences gérant plusieurs sites clients :

Vitesse d'intégration : le provisionnement d'un nouveau site client prend moins d'une minute. Pas de configuration de serveur, pas de cPanel, pas d'installation manuelle de WordPress.

Séparation des clients : le site de chaque client est véritablement isolé. Un client qui installe un plugin problématique n'affecte que son propre site.

Scalabilité : l'ajout d'un nouveau client ne nécessite pas le provisionnement d'un nouveau serveur. L'infrastructure de conteneurs s'adapte à la capacité de l'hôte, et l'ajout de capacité supplémentaire est une question d'ajout de nœuds hôtes.

Reprise après sinistre : comme chaque site est conteneurisé, la sauvegarde et la restauration s'opèrent au niveau du conteneur. La restauration du site d'un seul client n'affecte aucun autre client.

Le compromis est que l'hébergement par conteneurs coûte plus cher par site que l'hébergement mutualisé. Mais pour les agences où la fiabilité du site et la séparation des clients sont non négociables, l'économie est rentable – surtout lorsque les gains de temps de provisionnement sont pris en compte.