La question revient à chaque nouveau service : conteneur ou machine virtuelle ? Les comparatifs répondent par des chiffres de consommation, et concluent invariablement que le conteneur est plus léger. C'est vrai, et c'est rarement ce qui devrait décider.
Le mauvais choix ne se manifeste pas au démarrage. Il se manifeste six mois plus tard, quand il faut monter un partage réseau, charger un module noyau, ou isoler pour de bon un service qui a mal tourné.
La différence qui explique tout le reste
Un conteneur LXC partage le noyau de l'hôte. Il n'isole que l'espace utilisateur : processus, réseau, système de fichiers. Il n'y a pas de démarrage de noyau, pas de couche de virtualisation matérielle, donc un conteneur démarre en une seconde et ne consomme que ce que ses processus consomment réellement.
Une VM embarque son propre noyau sur du matériel virtualisé. Elle démarre plus lentement, réserve de la mémoire, et coûte quelques pourcents de performance. En échange, elle est réellement indépendante de l'hôte.
Tout le reste découle de là. Chaque avantage du conteneur et chaque limite du conteneur sont des conséquences directes de ce noyau partagé.
Les cas où la VM est la seule réponse
Quatre situations tranchent immédiatement, sans discussion :
- Un autre système d'exploitation. Windows, BSD, un pare-feu applicatif dédié : le noyau partagé rend le conteneur impossible par construction.
- Un module noyau ou un accès matériel bas niveau. Le conteneur n'a pas son propre noyau : il ne peut rien y charger.
- Une frontière de sécurité réelle. Service exposé à l'internet, données sensibles, code peu fiable : une faille d'élévation de privilèges dans le noyau franchit un conteneur, pas une VM.
- Docker. Imbriquer un moteur de conteneurs dans un conteneur fonctionne parfois, casse régulièrement, et pousse à activer des options qui annulent l'isolation. Une VM règle définitivement la question.
Les cas où le conteneur gagne largement
À l'inverse, le LXC est le bon défaut pour tout ce qui est un service Linux simple, sous votre contrôle : un serveur web, une base de données, un service de supervision, un outil interne. Vous gagnez un démarrage instantané, une empreinte mémoire proportionnelle à l'usage réel, et une densité qui permet de faire tourner des dizaines de services là où quelques VM saturaient déjà la machine.
Le conteneur a aussi un avantage souvent ignoré sur le partage de matériel. Un GPU passé en passthrough à une VM est retiré à l'hôte et dédié à cette seule VM. Le même GPU peut en revanche être utilisé simultanément par plusieurs conteneurs et par l'hôte. Pour du transcodage ou de l'inférence partagée, c'est décisif.
Privilégié ou non privilégié : ne cédez pas
Un conteneur non privilégié applique un mappage d'UID : l'utilisateur root du conteneur correspond à un utilisateur sans droits sur l'hôte. Une évasion aboutit à un compte inoffensif plutôt qu'à un root réel. C'est le défaut, et il doit le rester.
Le scénario qui fait tout basculer est toujours le même. Un montage réseau refuse de fonctionner dans le conteneur, une recherche rapide suggère de passer en privilégié, ça marche, on passe à autre chose. On vient d'échanger l'isolation contre cinq minutes de confort.
Ce que le choix change en exploitation
Deux différences pratiques pèsent lourd sur la durée.
La migration à chaud d'abord : une VM se déplace d'un nœud à l'autre sans interruption perceptible, un conteneur doit être arrêté. Si vous prévoyez des maintenances matérielles sans coupure, c'est un argument concret.
La sauvegarde ensuite. Les deux se sauvegardent, mais un conteneur produit des archives nettement plus compactes et plus rapides, parce qu'il n'embarque ni noyau ni image disque complète. Sur un homelab qui sauvegarde tous les jours, l'écart de volume et de durée devient très visible.
La règle en une phrase
Conteneur par défaut, VM dès que le service touche au noyau ou doit être réellement isolé.
Formulé autrement : si le service est un programme Linux ordinaire que vous maîtrisez, prenez un conteneur. S'il exige son propre noyau, un autre système, du matériel dédié, ou s'il est exposé à des tiers, prenez une VM. Et si vous hésitez sincèrement sur un service exposé, prenez la VM : le surcoût est marginal, la marge de sécurité ne l'est pas.
Commentaires