Proxmox VE — Conteneurs LXC

Conteneurs LXC — la virtualisation légère qui change la donne

Dans un datacenter ou un homelab, chaque Go de RAM et chaque cycle CPU comptent. Les machines virtuelles KVM offrent une isolation maximale, mais elles emportent un kernel complet, un init system, et un overhead non négligeable. Les conteneurs LXC prennent le problème à l’envers : ils partagent le noyau de l’hôte et n’isolent que l’espace utilisateur.

Le résultat ? Un conteneur LXC démarre en 1 à 2 secondes, consomme quelques dizaines de Mo de RAM, et offre des performances I/O natives. Là où tu placerais 10 VMs, tu peux faire tourner 50 conteneurs — avec le même matériel.

🔥 Cas réel : Un MSP (Managed Service Provider) gère 200 clients sur un cluster Proxmox de 3 nœuds. Chaque client a un conteneur LXC dédié pour son DNS, son reverse proxy et son monitoring. Coût par conteneur : 256 Mo de RAM et 2 Go de disque. Avec des VMs, il faudrait 10 fois plus de matériel.

L’intérêt en DevOps est clair : les conteneurs LXC sont parfaits pour tous les services d’infrastructure Linux qui n’ont pas besoin d’un kernel dédié — DNS, reverse proxy, monitoring, CI runners, serveurs de dev.

LXC vs Docker — deux philosophies, un même socle

C’est la question incontournable. Les deux utilisent les mêmes technologies Linux (namespaces, cgroups), mais l’approche est fondamentalement différente.

LXC = conteneur système. Il virtualise un système Linux complet avec systemd, plusieurs services, des utilisateurs, cron, syslog. C’est une VM légère que tu gères comme un serveur classique avec apt upgrade.

Docker = conteneur applicatif. Il isole un processus unique dans une image immuable et stateless. Tu rebuild l’image pour mettre à jour et tu orchestres avec Compose ou Kubernetes.

Concrètement :

• Un Pi-hole, un serveur Nginx multi-sites, un Prometheus → LXC
• Une API Node.js, un worker Python, un microservice Go → Docker
• Docker dans Proxmox → Docker dans un conteneur LXC (avec nesting=1) ou dans une VM dédiée

💡 Tip DevOps : Docker peut tourner à l’intérieur d’un conteneur LXC. Il suffit d’activer le nesting : pct set 200 --features nesting=1,keyctl=1. C’est parfait pour le dev/test. En production, certaines équipes préfèrent une VM dédiée pour l’isolation supplémentaire.

🧠 À retenir : LXC et Docker ne sont pas concurrents — ils répondent à des besoins différents. Dans une infra Proxmox bien conçue, tu utilises les deux.

Créer un conteneur — templates, interface et CLI

Télécharger un template

Proxmox maintient un catalogue de templates officiels pour toutes les distributions majeures. Le téléchargement se fait en une commande :

# Lister les templates système disponibles
pveam available --section system

# Télécharger les templates courants
pveam download local debian-12-standard_12.7-1_amd64.tar.zst
pveam download local ubuntu-24.04-standard_24.04-2_amd64.tar.zst
pveam download local alpine-3.20-default_20240908_amd64.tar.xz

Alpine Linux mérite une mention spéciale : un conteneur Alpine consomme moins de 30 Mo de RAM. Pour un service comme Pi-hole ou un reverse proxy Caddy, c’est le choix optimal.

Créer via la CLI

La commande pct create offre un contrôle total sur la configuration :

# Conteneur Debian non-privilégié avec IP statique
pct create 200 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname debian-srv \
  --cores 2 \
  --memory 1024 \
  --swap 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.1.20/24,gw=192.168.1.1 \
  --nameserver 1.1.1.1 \
  --password \
  --start true \
  --unprivileged true \
  --features nesting=1

Chaque paramètre a son importance, mais le plus critique est --unprivileged true.

Privilégié vs non-privilégié — le choix de sécurité

Dans un conteneur non-privilégié (le défaut recommandé), le root du conteneur est mappé vers un UID élevé sur l’hôte (100000+). Même si un attaquant s’échappe du conteneur, il n’a aucun droit sur le système hôte.

Dans un conteneur privilégié, le root du conteneur est le vrai root de l’hôte (UID 0). Plus de compatibilité — certaines applications legacy ou les montages NFS l’exigent — mais le risque de sécurité est réel.

⚠️ Attention : Un conteneur privilégié compromis peut potentiellement accéder au système hôte. Utilise toujours --unprivileged true sauf si une contrainte technique spécifique t’y oblige (NFS, certains modules kernel).

Gérer les conteneurs au quotidien

Commandes essentielles

La CLI pct est l’équivalent de qm pour les VMs. Voici les commandes que tu utiliseras tous les jours :

# Cycle de vie
pct start 200
pct shutdown 200    # arrêt propre via systemd
pct stop 200        # arrêt forcé (dernier recours)

# Accès direct — pas besoin de SSH
pct enter 200
pct exec 200 -- apt update && apt upgrade -y

# Transfert de fichiers
pct push 200 /root/config.txt /etc/app/config.txt
pct pull 200 /var/log/app.log /tmp/debug.log

# Info et config
pct config 200
pct list

pct enter et pct exec sont des raccourcis puissants : tu accèdes au conteneur directement depuis l’hôte, sans SSH, sans mot de passe. Parfait pour le troubleshooting rapide.

Modification à chaud et réseau

Les conteneurs LXC supportent le redimensionnement disque à chaud. Pour la RAM et le CPU, un reboot est nécessaire :

# Redimensionner le disque à chaud
pct resize 200 rootfs +5G

# Modifier RAM et CPU (nécessite reboot)
pct set 200 --memory 2048 --cores 4

# Configuration réseau — IP statique, VLAN, rate limiting
pct set 200 --net0 name=eth0,bridge=vmbr0,ip=192.168.1.20/24,gw=192.168.1.1
pct set 200 --net1 name=eth1,bridge=vmbr1,tag=100,ip=10.0.0.20/24

Bind mounts — partager des données avec l’hôte

Les points de montage permettent de partager un dossier de l’hôte directement dans le conteneur :

# Monter un dossier de l'hôte
pct set 200 --mp0 /mnt/data,mp=/data

# En lecture seule
pct set 200 --mp0 /mnt/shared,mp=/shared,ro=1

⚠️ Attention : Avec les conteneurs non-privilégiés, les permissions posent souvent problème. Le root du conteneur (UID 0) est mappé vers UID 100000 sur l’hôte. Pour que le conteneur puisse écrire : chown -R 100000:100000 /mnt/data.

Sécurité et bonnes pratiques

La sécurité des conteneurs LXC repose sur plusieurs couches complémentaires.

AppArmor — Proxmox applique automatiquement un profil AppArmor aux conteneurs non-privilégiés, limitant les syscalls et les accès filesystem. Ne le désactive pas sans bonne raison.

Limites de ressources — Empêche un conteneur de monopoliser le serveur :

# Limiter le CPU (max 1.5 cores)
pct set 200 --cpulimit 1.5

# Poids CPU relatif entre conteneurs
pct set 200 --cpuunits 1024

Checklist sécurité conteneurs :

• ✅ Toujours non-privilégié sauf nécessité absolue
• ✅ Nesting activé uniquement si Docker est nécessaire
• ✅ Pas de montage /dev depuis l’hôte
• ✅ Templates et conteneurs mis à jour régulièrement
• ✅ Firewall Proxmox activé pour contrôler le trafic

🔥 Cas réel : Un conteneur LXC privilégié hébergeant un service web est compromis via une faille applicative. L’attaquant obtient root dans le conteneur — et comme c’est un conteneur privilégié, il escalade vers l’hôte Proxmox. Résultat : tout le cluster est compromis. Avec un conteneur non-privilégié, l’attaquant aurait été confiné à un UID sans pouvoir sur l’hôte.

Snapshots, backups et clones

Snapshots et restauration

Comme pour les VMs, les snapshots capturent l’état du conteneur à un instant T :

# Snapshot avant mise à jour
pct snapshot 200 before-update

# Quelque chose a cassé → rollback
pct rollback 200 before-update

# Backup complet avec vzdump
vzdump 200 --storage local --mode snapshot --compress zstd

# Restaurer vers un nouveau CT
pct restore 210 /var/lib/vz/dump/vzdump-lxc-200-*.tar.zst --storage local-lvm

Clones — duplication rapide

# Clone complet (indépendant)
pct clone 200 210 --hostname clone-test --full true

# Clone lié (rapide, partage le disque de base)
pct clone 200 210 --hostname clone-test --full false

💡 Tip DevOps : Les clones liés sont parfaits pour créer rapidement des environnements de test éphémères. Clone, teste, détruis — en quelques secondes.

Résumé

Les conteneurs LXC sont l’alternative légère aux VMs pour tous les services Linux d’infrastructure. Ils partagent le kernel de l’hôte, démarrent en secondes, et consomment une fraction des ressources d’une VM.

LXC vs Docker n’est pas un choix exclusif : LXC pour les services système (DNS, proxy, monitoring), Docker pour les applications cloud-native (microservices, CI/CD). Les deux cohabitent parfaitement dans une infra Proxmox.

La règle d’or : toujours non-privilégié. L’isolation userspace des conteneurs non-privilégiés, combinée avec AppArmor, offre un niveau de sécurité largement suffisant pour la plupart des workloads.

🧠 À retenir : Un conteneur LXC Alpine avec un reverse proxy Caddy consomme 30 Mo de RAM et 2 Go de disque. La même fonction dans une VM : 512 Mo de RAM minimum et 10 Go de disque. À l’échelle, cette différence se chiffre en milliers d’euros de matériel économisé.