Proxmox en Linux-Containers: wanneer LXC te gebruiken in plaats van een virtuele machine

Proxmox VE est devenu l’une des plateformes les plus populaires auprès des administrateurs système, des laboratoires domestiques et des entreprises recherchant une solution de virtualisation ouverte. Son attrait ne réside pas uniquement dans la capacité à créer des machines virtuelles avec KVM, mais aussi dans la possibilité de combiner, dans une même interface, plusieurs blocs d’infrastructure : calcul, stockage, réseau, clusters, sauvegardes et conteneurs Linux.

Parmi ces composants, les Linux Containers, plus connus sous le nom de LXC, occupent une place particulière. Ils ne sont ni des machines virtuelles traditionnelles ni des conteneurs applicatifs type Docker. Il s’agit de conteneurs de système d’exploitation : des environnements Linux isolés partageant le kernel de l’hôte, tout en disposant de leur propre système de fichiers, processus, réseau, utilisateurs et services. Dans Proxmox, cette approche permet de déployer des charges très légères, rapides à démarrer et faciles à gérer depuis la même console que celle consacrée aux machines virtuelles.

Qu’est-ce que LXC dans Proxmox ?

LXC est une technologie de virtualisation au niveau du système d’exploitation. Contrairement à une machine virtuelle complète, qui émule le matériel et exécute son propre noyau, un conteneur LXC partage le kernel du nœud Proxmox. Cette différence technique explique presque toutes ses avantages et limitations.

Un conteneur LXC consomme moins de ressources qu’une VM car il n’a pas besoin de lancer un système d’exploitation entier depuis zéro. Il n’y a pas de BIOS virtuel, pas de kernel invité indépendant, et pas toute une couche de virtualisation du matériel. En conséquence, il démarre plus rapidement, utilise moins de mémoire et permet une densité accrue de services par nœud.

Proxmox simplifie grandement l’utilisation de LXC. Depuis l’interface web, il est possible de télécharger des templates, créer des conteneurs, attribuer CPU, mémoire, disque, réseau, DNS, mot de passe, clés SSH et stockage. En ligne de commande, la commande principale est pct, qui permet de créer, démarrer, arrêter, cloner, migrer, faire des snapshots ou accéder à un conteneur.

Chaque conteneur repose sur une template. Celle-ci contient le système de fichiers d’une distribution Linux, comme Debian, Ubuntu, AlmaLinux, Rocky Linux, Fedora ou Alpine, selon la disponibilité. Lors de la création, Proxmox clone cette template sur le stockage choisi, générant ainsi un environnement Linux autonome en quelques secondes.

Voici un exemple simplifié de création via la ligne de commande :

pct create 101 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname web-lxc-01 \
  --cores 2 \
  --memory 2048 \
  --rootfs local-lvm:20 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --unprivileged 1

Le conteneur peut ensuite être démarré avec :

pct start 101

Et accessible via :

pct enter 101

Cette simplicité est l’une des principales raisons pour lesquelles LXC s’intègre si bien avec Proxmox. Un administrateur peut déployer en quelques minutes un serveur Nginx, un proxy, un DNS interne, un conteneur de monitoring, un petit service PHP, une base de données légère ou un outil administratif sans réserver les ressources qu’impliquerait une VM complète.

Privé et non-privilégié : le choix de sécurité

L’un des choix majeurs lors de la création d’un conteneur LXC dans Proxmox concerne sa nature privilégiée ou non. En général, dans les environnements modernes, il est conseillé de privilégier les conteneurs non privilégiés chaque fois que possible.

Dans un conteneur privilégié, l’utilisateur root du conteneur a une correspondance plus directe avec le root de l’hôte, ce qui facilite certaines opérations comme les montages spécifiques ou l’accès à certains dispositifs. Cependant, cela augmente aussi l’impact potentiel en cas de compromission. À l’inverse, dans un conteneur non privilégié, Proxmox utilise des user namespaces pour mapper les utilisateurs internes du conteneur à des identifiants sans privilèges réels sur l’hôte. Le root à l’intérieur du conteneur ne correspond donc pas directement au root du nœud.

La recommandation générale est claire : privilégier les conteneurs non privilégiés pour les services standards et réserver les privilégiés aux cas nécessitant des fonctionnalités spécifiques. Si un service requiert des permissions particulières, accès à des dispositifs, montages NFS/SMB ou l’exécution de Docker dans LXC, il convient de réfléchir si un conteneur ou une VM offre une meilleure sécurité.

L’utilisation de Docker dans un LXC mérite une mention spéciale. Il est techniquement possible de faire tourner Docker à l’intérieur d’un conteneur, mais ce n’est pas toujours la meilleure architecture. Docker utilise aussi namespaces, cgroups et mécanismes d’isolation du kernel. Le faire tourner dans un LXC peut empiler plusieurs couches de conteneurisation et poser des problèmes de permissions, AppArmor, cgroups, stockage overlay ou mises à jour. En production, beaucoup d’administrateurs préfèrent exécuter Docker dans une VM dédiée, notamment si la charge est critique.

Cas d’usage : quand LXC est particulièrement adapté

LXC est idéal quand il s’agit de déployer rapidement de nombreux services Linux légers et bien délimités. Il ne remplace pas toutes les machines virtuelles, mais peut réduire la consommation de ressources et simplifier la gestion dans de nombreux scénarios.

Pour les laboratoires et petites infrastructures, LXC permet d’isoler les services sans gaspiller de ressources. Un nœud avec 64 Go de RAM peut héberger bien plus de charges légères en conteneurs qu’en VM, à condition que le stockage, le réseau et les sauvegardes soient bien planifiés.

En entreprise, il faut utiliser LXC de façon plus stratégique. C’est idéal pour les services auxiliaires, outils internes, composants d’infrastructure ou charges Linux contrôlées. Pour des applications critiques, des environnements régulés, multi-locataires, bases de données sensibles ou systèmes nécessitant une forte isolation, les VM restent souvent la meilleure option.

Le stockage doit aussi être anticipé car il impacte snapshots, réplication, performance et migration. Proxmox permet d’utiliser différents backends pour les rootfs, tels que LVM, ZFS, Ceph, NFS ou des répertoires locaux, selon la conception du cluster. Par exemple, ZFS facilite les snapshots instantanés et clones locaux, tandis que Ceph peut être pertinent dans des clusters distribuant le stockage, à condition d’un bon design.

Les sauvegardes intégrées sont également un atout. Proxmox offre le backup des conteneurs via vzdump, avec le Proxmox Backup Server proposant déduplication, compression, chiffrement et sauvegardes incrémentielles. Cela permet d’assurer une protection efficace pour de nombreux petits services sans dédier des scripts dispersés.

Côté réseau, on connecte généralement le conteneur à un pont comme vmbr0, à l’image d’une VM. Il peut utiliser DHCP ou une IP fixe, VLANs, règles de firewall. En contexte segmenté, il est conseillé d’en faire une unité de sécurité autonome : n’attribuer que le réseau nécessaire, limiter l’exposition, activer le firewall lorsque cela est pertinent, et éviter de partager des répertoires du host sans raison impérieuse.

Bonnes pratiques pour la production

LXC ne doit pas être considéré comme une solution rapide pour déployer n’importe quoi sur un serveur. Sa finesse peut conduire à créer trop de conteneurs sans stratégie, ce qui complique la maintenance, les mises à jour et la sécurité. L’approche recommandée consiste à définir le rôle de chaque conteneur et à la documenter comme pour une VM.

Une bonne pratique consiste à utiliser des templates à jour, privilégier les conteneurs non privilégiés par défaut, limiter les ressources allouées, séparer stockage et données persistantes, configurer les sauvegardes dès le début, et surveiller les logs de Proxmox ainsi que ceux du système invité. Il faut aussi éviter de créer des conteneurs « mascotte » pleins de services hétérogènes. Si un conteneur devient trop chargé, il doit être divisé ou transformé en VM mieux définie.

La différence entre LXC et VM ne doit pas être vue comme une guerre technique, mais comme deux outils complémentaires. LXC offre rapidité, densité et efficacité pour les charges Linux. KVM propose un isolement plus fort, une compatibilité avec plus de systèmes d’exploitation, et une frontière claire entre hôte et invité. La plateforme Proxmox permet de combiner ces deux options pour un environnement optimal.

Dans un environnement structuré, on utilisera généralement les VM pour les charges critiques, Windows, appliances, bases de données importantes ou applications nécessitant un isolement renforcé. Les conteneurs LXC, quant à eux, exécuteront des services Linux auxiliaires, des applications légères, des proxies, du monitoring, DNS, automatisation ou outils internes. Cette complémentarité optimise l’utilisation du matériel sans sacrifier le contrôle opérationnel.

Proxmox et LXC offrent une solution particulièrement pertinente car ils rapprochent la conteneurisation de système d’exploitation à des administrateurs qui ne veulent pas tout gérer par Kubernetes ou Docker. Pour beaucoup d’entreprises, le pas logique n’est pas de microserviceiser chaque application ni déployer un cluster sophistiqué, mais de bien différencier les charges Linux, réduire la consommation de ressources, et maintenir une gestion simple. Là où LXC a beaucoup de sens.

L’essentiel est de savoir où ne pas l’utiliser. Un conteneur n’est pas une VM miniature. Il partage le kernel, hérite de certains paramètres du host, et demande une bonne compréhension des permissions, namespaces, stockage et sécurité. Utilisé avec cette conscience, il devient un outil très efficace. Mal utilisé comme un raccourci, il peut engendrer plus de problèmes qu’il n’en résout.

Questions fréquentes

Qu’est-ce que LXC dans Proxmox ?
LXC est une technologie de conteneurs Linux permettant d’exécuter des systèmes Linux isolés dans Proxmox, en partageant le kernel du nœud hôte.

En quoi LXC diffère-t-il d’une machine virtuelle ?
Une VM virtualise le matériel et utilise son propre kernel. Un conteneur LXC partage le kernel de l’hôte, consomme moins de ressources, démarre plus vite, mais offre une isolation moindre.

Peut-on faire tourner Windows dans un conteneur LXC ?
Non. LXC sous Proxmox est conçu pour des distributions Linux. Pour Windows, BSD ou autres OS, il faut utiliser une machine virtuelle.

Est-il sécurisé d’utiliser LXC en production ?
Oui, à condition d’utiliser des conteneurs non privilégiés, de limiter les permissions, de planifier les sauvegardes et de segmenter le réseau correctement. Pour des charges critiques ou multi-locataires, une VM reste souvent plus adaptée.