Pourquoi j'ai choisi LXC plutôt que Docker pour héberger 500 sites WordPress

Quand on gère des centaines de sites WordPress avec des clients qui ont besoin d’un accès SSH et SFTP, le choix de la technologie de conteneurisation devient crucial. Voici pourquoi LXC s’est imposé comme la meilleure solution dans mon cas.

En bref

Pour notre agence qui gère plus de 500 sites WordPress, LXC nous offre des conteneurs qui se comportent comme de vraies machines virtuelles légères. L’accès SSH/SFTP est natif (via un bastion pour le routage), la répartition sur plusieurs serveurs nous permet de dépasser les limites de notre ancien mutualisé (200 sites max), et les coûts restent maîtrisés (~2,30 €/site/mois). Docker, conçu pour des applications stateless et éphémères, aurait complexifié inutilement notre infrastructure pour ce cas d’usage.

Le contexte

Je travaille pour une agence web qui maintient 500 sites WordPress en production. Avant LXC, nous utilisions un hébergement mutualisé classique qui plafonnait à 200 sites et n’offrait aucune isolation : un plugin mal codé pouvait faire tomber tous les sites du serveur, une attaque bruteforce saturait MySQL pour tout le monde, et impossible d’avoir des versions PHP différentes par client.

Il nous fallait une isolation stricte entre chaque site, avec un accès SSH/SFTP, une persistance native des données, une capacité de croissance au-delà de 200 sites, et des coûts maîtrisés.

Docker vs LXC : la comparaison rapide

LXC crée des conteneurs système complets : chaque conteneur dispose de son propre init, ses propres services, et se comporte comme une VM légère. Docker crée des conteneurs d’application conçus pour exécuter un seul processus. L’approche est immutable : on ne modifie pas un conteneur, on le reconstruit.

Le critère décisif : SSH/SFTP

Nos clients et développeurs ont besoin de se connecter en SSH (WP-CLI) et SFTP (transfert de fichiers). Avec LXC, chaque conteneur a son serveur SSH intégré. Nous utilisons un bastion SSH avec ProxyJump qui route les connexions vers le bon conteneur en fonction du domaine :

# Le client se connecte simplement :
ssh [email protected]
sftp [email protected]

Avec Docker, il faut bricoler : ajouter SSH dans l’image, utiliser docker exec, ou monter un conteneur SSH dédié avec volumes partagés. Tout ça va à contre-courant de Docker.

Notre architecture

500 sites répartis sur 3 serveurs (~170 sites chacun), avec Nginx en reverse proxy sur chaque hôte et une stack ELK + Filebeat pour centraliser les logs des 500 conteneurs.

Pourquoi un Nginx par serveur plutôt qu’un seul en frontal ? Le DNS de chaque domaine pointe directement vers l’IP du serveur qui héberge ses conteneurs. Chaque Nginx ne gère que ses propres sites et communique avec les conteneurs LXC via le réseau local (bridge). Résultat : pas de bottleneck central, pas de single point of failure, et pas de latence réseau inutile.

                                    Internet
                                        │
        ┌───────────────────────────────┼───────────────────────────────┐
        │                               │                               │
        ▼                               ▼                               ▼
┌───────────────────┐       ┌───────────────────┐       ┌───────────────────┐
│   Node 1 (LXD)    │       │   Node 2 (LXD)    │       │   Node 3 (LXD)    │
│                   │       │                   │       │                   │
│ ┌───────────────┐ │       │ ┌───────────────┐ │       │ ┌───────────────┐ │
│ │ Nginx Reverse │ │       │ │ Nginx Reverse │ │       │ │ Nginx Reverse │ │
│ │ Proxy + SSL   │ │       │ │ Proxy + SSL   │ │       │ │ Proxy + SSL   │ │
│ └───────┬───────┘ │       │ └───────┬───────┘ │       │ └───────┬───────┘ │
│         │         │       │         │         │       │         │         │
│ ┌───────▼───────┐ │       │ ┌───────▼───────┐ │       │ ┌───────▼───────┐ │
│ │ ~170 sites WP │ │       │ │ ~170 sites WP │ │       │ │ ~170 sites WP │ │
│ └───────────────┘ │       │ └───────────────┘ │       │ └───────────────┘ │
└─────────┬─────────┘       └─────────┬─────────┘       └─────────┬─────────┘
          │                           │                           │
          └───────────────────────────┼───────────────────────────┘
                                      │
                          ┌───────────▼───────────┐
                          │    Logs centralisés   │
                          │   (ELK + Filebeat)    │
                          └───────────────────────┘

Ce n’est pas de la haute disponibilité : les données restent locales à chaque serveur. En cas de panne, nous restaurons depuis les sauvegardes quotidiennes externalisées. Ce choix privilégie la simplicité, la performance I/O et le coût.

Les coûts

3 serveurs dédiés (32 cores, 128 Go RAM) + backups externalisés + stack ELK self-hosted. LXC/LXD est open source, pas de coût de licence.

Quand Docker serait meilleur

Docker reste le meilleur choix pour les architectures microservices, le CI/CD, les environnements de dev (Docker Compose), les applications stateless, et l’orchestration Kubernetes. Pour un hébergement WordPress mutualisé mais isolé avec accès client SSH, ce n’était pas le bon outil.

Conclusion

Le choix entre LXC et Docker est une question d’adéquation au besoin. Pour héberger 500 sites WordPress avec accès SSH/SFTP, LXC s’est imposé : conteneurs qui se comportent comme de vrais serveurs, coûts maîtrisés, logs centralisés, et pas de vendor lock-in. Choisissez vos outils en fonction de votre contexte, pas en fonction des tendances.