Docker sur Proxmox : VM, LXC natif ou Docker-in-LXC ? Le guide pour choisir
Trois approches coexistent pour faire tourner des conteneurs sur Proxmox VE. Deux sont légitimes, une est un piège. Ce guide compare performance, sécurité, isolation et cas d'usage pour vous aider à choisir — sans dogme, mais avec un avis tranché.
Docker sur Proxmox : trois approches, un seul bon choix
Quand on administre un cluster Proxmox, la question finit toujours par arriver : où faire tourner Docker ? Sur une VM classique ? Directement dans un conteneur LXC ? Ou — et c'est là que ça se complique — en imbriquant Docker dans un LXC ?
La tentation est compréhensible : LXC consomme moins de RAM qu'une VM, démarre en quelques secondes, et partage le kernel du host. Pourquoi « gaspiller » des ressources avec une VM complète quand on peut tout faire en LXC ?
La réponse courte : parce que l'isolation, la sécurité et la maintenabilité comptent plus que quelques centaines de Mo de RAM. Et parce que Docker-in-LXC, malgré les tutoriels qui circulent, est un anti-pattern qui finit toujours par poser problème en production.
Cet article passe en revue les trois approches — VM KVM + Docker, LXC natif (sans Docker), et Docker-in-LXC avec nesting — avec des comparatifs concrets sur la performance, la sécurité, et les cas d'usage réels.
Architecture comparée : les 3 modèles
Avant de plonger dans les détails, visualisons comment chaque approche empile les couches :
VM KVM + Docker
Recommandé en production
LXC natif (sans Docker)
Propre pour services simples
Docker-in-LXC (nesting)
Anti-pattern — à éviter
La différence fondamentale : dans une VM KVM, Docker tourne sur son propre kernel isolé, exactement comme sur un serveur dédié. Dans un LXC, tout partage le kernel du host — y compris Docker si on l'y installe, avec tous les risques que cela implique.
Performance
L'argument principal en faveur du LXC est la performance. Voyons ce qu'il en est réellement :
| Critère | VM KVM + Docker | LXC natif | Docker-in-LXC |
|---|---|---|---|
| Overhead CPU | 1–3 % (VT-x) | < 1 % | < 1 % |
| I/O disque | Natif (virtio-scsi) | Natif | Overhead overlay2 |
| Réseau | ~Natif (virtio-net) | Natif (veth) | Double NAT possible |
| Démarrage | 15–30 s | 1–3 s | 5–15 s (LXC + Docker daemon) |
| Empreinte RAM | +256–512 Mo (kernel guest) | Minimal | +100–200 Mo (Docker daemon) |
En pratique : Sur du matériel moderne avec VT-x/VT-d, l'overhead d'une VM KVM est négligeable pour la plupart des workloads. La différence se mesure en pourcentages à un chiffre. L'argument « LXC est plus rapide » est vrai sur le papier, mais rarement décisif en production. En revanche, la RAM supplémentaire du kernel guest (256–512 Mo) est le vrai coût — un prix acceptable pour l'isolation totale.
Sécurité et isolation
C'est ici que les différences deviennent critiques. La performance est un compromis, la sécurité est un impératif.
| Critère | VM KVM | LXC natif | Docker-in-LXC |
|---|---|---|---|
| Isolation kernel | Complète (kernel dédié) | Partielle (kernel host) | Faible (kernel host + nesting) |
| Surface d'attaque | Minimale (QEMU + virtio) | Moyenne (syscalls host) | Large (syscalls + nesting) |
| AppArmor | Non nécessaire | Actif par défaut | Souvent désactivé |
| Live migration | Oui (à chaud) | Non (arrêt requis) | Non (arrêt requis) |
| Escape container → host | Extrêmement difficile | Possible (CVE kernel) | Risque accru |
| Multi-tenant | Oui — isolation totale | Risqué | Dangereux |
VM KVM : isolation matérielle
Une VM KVM exécute son propre kernel dans un espace mémoire isolé par le processeur (Intel VT-x / AMD-V). Un exploit dans un conteneur Docker atteint au maximum le kernel guest — pas le host. De plus, la live migration permet de déplacer une VM entre nœuds du cluster sans interruption de service, ce qui est impossible avec LXC.
Docker-in-LXC : pourquoi c'est un anti-pattern en production
Docker dans un LXC cumule les faiblesses : le conteneur Docker partage le kernel du host via le LXC, le nesting affaiblit les protections de namespace, et les contournements nécessaires (désactivation d'AppArmor, permissions étendues) élargissent considérablement la surface d'attaque. Un exploit Docker peut remonter directement jusqu'au host Proxmox — sans la barrière du kernel guest qu'offre une VM.
Docker-in-LXC : pourquoi ça pose problème
Pour faire tourner Docker dans un conteneur LXC Proxmox, il faut activer le nesting — l'imbrication de namespaces Linux. Concrètement, voici ce que ça implique :
Configuration requise dans le LXC
# /etc/pve/lxc/<CTID>.conf
# Activer le nesting (obligatoire pour Docker)
features: nesting=1,keyctl=1
# Parfois nécessaire pour overlay2
features: nesting=1,keyctl=1,fuse=1
# Si ça ne marche toujours pas... (danger)
lxc.apparmor.profile: unconfined
lxc.cgroup2.devices.allow: a
lxc.cap.drop:
lxc.mount.auto: proc:rw sys:rwChaque ligne ajoutée affaiblit un peu plus l'isolation du conteneur. Les quatre dernières lignes reviennent à désactiver quasiment toute la sécurité du LXC.
Nesting = affaiblissement de l'isolation
Le flag nesting=1 autorise la création de namespaces imbriqués. Docker crée alors des sous-namespaces dans un espace déjà partagé avec le host. La frontière entre « conteneur » et « host » devient floue.
AppArmor souvent désactivé
Docker et AppArmor du LXC entrent régulièrement en conflit. La « solution » la plus courante sur les forums : lxc.apparmor.profile: unconfined. Cela désactive le Mandatory Access Control — la dernière ligne de défense entre le conteneur et le host.
Problèmes avec cgroups v2 et overlay2
Proxmox utilise cgroups v2 par défaut depuis la version 7. Certaines configurations Docker-in-LXC nécessitent des workarounds supplémentaires pour le driver de stockage overlay2, voire un fallback sur vfs — nettement moins performant.
keyctl et FUSE : permissions élargies
L'activation de keyctl=1 et fuse=1 donne au conteneur LXC un accès à des syscalls normalement restreints. Chaque permission supplémentaire est un vecteur potentiel d'escalade de privilèges vers le host.
Le résultat final : pour faire tourner Docker dans un LXC, on désactive progressivement les protections qui justifient l'existence du LXC. On obtient un conteneur qui n'est ni aussi sécurisé qu'un LXC standard, ni aussi isolé qu'une VM — le pire des deux mondes.
LXC natif : quand c'est le bon choix
Attention : le problème n'est pas LXC en lui-même — c'est Docker dans LXC. Utilisé nativement, un conteneur LXC Proxmox est un outil légitime pour certains cas d'usage :
LXC brille pour les services simples
- Reverse proxy (nginx, HAProxy) — léger, pas besoin de Docker
- DNS récursif (Unbound, Pi-hole) — service unique, configuration système
- Petit serveur web statique — Apache/nginx servant des fichiers
- Monitoring léger — agents de collecte, exporters Prometheus
- Outils système — VPN, bastion SSH, jumpbox
Limites du LXC natif
Dès que vous avez besoin de docker-compose, d'un pipeline CI/CD, d'images OCI ou d'un écosystème d'orchestration, LXC natif atteint ses limites. Il n'y a pas de docker pull, pas de Dockerfile, pas de volumes Docker. Pour ces usages, une VM avec Docker est la bonne réponse. Et rappel important : la live migration n'est pas disponible en LXC — un déplacement entre nœuds nécessite l'arrêt et le redémarrage du conteneur.
Cas d'usage : quand choisir quoi
| Scénario | Recommandation |
|---|---|
| Production avec Docker | VM KVM + Docker — isolation, live migration, standard |
| Microservices / docker-compose | VM KVM + Docker — écosystème complet |
| CI/CD (GitLab Runner, Jenkins) | VM KVM + Docker — builds isolés, DinD natif |
| Multi-tenant / clients isolés | VM KVM — isolation totale obligatoire |
| Service simple (DNS, proxy, web statique) | LXC natif — léger et propre, sans Docker |
| Dev/test rapide avec Docker | Docker-in-LXC acceptable — si jetable et non exposé |
| Application legacy sans Docker | LXC natif ou VM selon l'isolation requise |
Le verdict honnête
VM + Docker
Le choix production
- Isolation totale (kernel dédié)
- Docker standard, pas de hack
- Live migration entre nœuds
- Snapshots et backup PBS
LXC natif
Propre pour le simple
- Démarrage instantané
- Minimal en ressources
- Pas de Docker / pas d'OCI
- Pas de live migration
Docker-in-LXC
Le piège à éviter
- Sécurité affaiblie (nesting)
- Contournements fragiles
- Fausse économie de RAM
- Pas de live migration
Notre approche chez RDEM Systems
Chez RDEM Systems, nous avons fait un choix clair : 100 % VM KVM, aucun LXC dans notre infrastructure de production. Voici pourquoi.
Pourquoi 100 % VM chez RDEM Systems
Isolation client complète
Chaque client dispose de VM dédiées avec leur propre kernel. Aucun partage de kernel entre tenants — une compromission dans l'environnement d'un client ne peut pas affecter les autres.
Docker fonctionne sans hack
docker-compose, volumes, overlay2, les builders multi-stage — tout fonctionne nativement dans une VM, sans nesting, sans workaround, sans surprises après une mise à jour Proxmox.
Live migration entre hyperviseurs
Nous déplaçons les VM entre nœuds du cluster sans interruption de service — pour la maintenance, l'équilibrage de charge ou les mises à jour d'hyperviseurs. C'est impossible avec LXC, qui nécessite un arrêt et un redémarrage.
Snapshots et backups PBS propres
Les VM bénéficient de snapshots cohérents (avec qemu-guest-agent pour le fsfreeze) et de sauvegardes PBS avec déduplication — notre stratégie de sauvegarde 3-2-1 s'appuie entièrement sur des VM.
Le coût : oui, chaque VM consomme 256–512 Mo de RAM de plus qu'un LXC équivalent pour le kernel guest. Sur un cluster avec des centaines de Go de RAM, c'est un prix marginal pour une isolation totale, la live migration et une maintenance sereine.
Decouvrez nos VPS et VDS Proxmox infogeres : toutes nos VM de production sont deployees avec Docker sur KVM, backup PBS et live migration inclus.
Bonnes pratiques
Checklist Docker sur VM Proxmox
- Installer qemu-guest-agent dans chaque VM : permet à Proxmox de communiquer avec la VM (fsfreeze pour les snapshots, shutdown propre)
- Stockage Docker séparé : dédier un disque virtio-scsi au répertoire
/var/lib/docker— évite de saturer le rootfs et facilite le dimensionnement - cgroups v2 activé : Proxmox et Docker supportent nativement cgroups v2 — ne passez pas en v1 pour contourner un problème LXC
- Limiter les ressources : configurez les limites CPU et RAM dans Proxmox et dans les contraintes Docker (deploy.resources)
- Backup régulier avec PBS : planifiez des sauvegardes quotidiennes avec vérification (verify jobs) — les conteneurs Docker sont éphémères, mais les volumes ne le sont pas
- Réseau bridge ou VLAN : utilisez les bridges Proxmox ou les VLANs plutôt que le NAT Docker par défaut pour un réseau propre et performant
- Monitoring Docker + VM : surveillez les métriques des deux niveaux — une VM qui swap ou un Docker daemon OOM ne se voit pas au niveau Proxmox seul
Questions fréquentes
Documentation officielle
Pour approfondir les concepts abordés dans cet article :
Articles connexes
Notre stratégie de sauvegarde 3-2-1
PBS, déduplication, verify jobs et protection ransomware sur 4 datacenters.
NTP public sur VM Proxmox
Clock drift, Chrony, VM vs bare-metal : retour d'expérience RDEM Systems.
Migrer de VMware à Proxmox
Guide complet : méthodologie, outils et pièges à éviter.
Proxmox infogéré par RDEM Systems
Supervision, sauvegardes, mises à jour — on gère votre infrastructure.