9. Conteneurs LXC : comprendre avant de faire

9.1 La virtualisation par isolation — comprendre avant de faire

Avant de créer notre premier conteneur, il est utile de s'arrêter une minute sur ce que signifie "virtualiser par isolation". Vous avez sans doute déjà entendu parler de machines virtuelles — avec KVM ou VMware, on émule un ordinateur complet, avec son propre noyau, ses propres pilotes, son BIOS virtuel.

C'est puissant, mais cela a un coût : chaque VM doit démarrer un système d'exploitation entier. Cela prend du temps, de la mémoire et des ressources processeur, même quand la VM ne fait rien d'utile.

La virtualisation par isolation repose sur un principe radicalement différent. Plutôt que d'émuler un ordinateur complet, on partage le noyau de la machine hôte entre plusieurs environnements isolés. Ces environnements s'appellent des conteneurs.

Chacun voit son propre système de fichiers, son propre réseau, ses propres processus. Mais tous utilisent le même noyau Linux, celui qui tourne sur l'hôte physique.

Le gain est immédiat : un conteneur démarre en quelques secondes (parfois moins), consomme quelques dizaines de mégaoctets de RAM au repos, et peut être créé ou détruit en un instant. C'est pourquoi LXC est idéal pour héberger des services légers : un serveur web, une base de données, un reverse proxy. On ne gaspille pas les ressources que réclamerait une VM complète pour le même service.

La contrepartie est tout aussi claire : tous les conteneurs partagent le même noyau. On ne peut donc pas faire tourner Windows dans un conteneur LXC.

On ne peut pas non plus charger des modules noyau arbitraires depuis l'intérieur d'un conteneur non-privilégié. LXC est Linux pour Linux.

Un conteneur est un système Linux complet, isolé des autres, qui s'exécute sur le noyau du nœud. Deux mécanismes du noyau assurent cette isolation : les namespaces et les cgroups.

Terme	Ce que c'est	Dans le laboratoire
Machine virtuelle	Un ordinateur simulé qui démarre son propre noyau	Aucune à ce stade
Conteneur LXC	Un système Linux complet (services, utilisateurs, réseau) qui tourne sur le noyau du nœud	Le CT 200 `cache-apt`, créé à l'atelier 6
Noyau de l'hôte	Le noyau `-pve` du nœud, partagé par tous les conteneurs	`uname -r` dans le Shell du nœud
Namespaces	Ce que le conteneur voit : ses processus, son réseau, ses fichiers, son nom (§9.2)	Le PID (Process ID, numéro de processus) 1 du conteneur, vu par l'hôte avec un autre numéro (§9.2)
cgroups	Ce que le conteneur peut consommer : processeur, mémoire, disque (§9.2)	La mémoire et les cœurs d'un conteneur, réglés à chaud au §12.3
Template	Le système de fichiers d'une distribution, prêt à copier (§11)	Le template Debian téléchargé au §11.2

Le noyau partagé étant un noyau Linux, un conteneur ne peut faire tourner que Linux : pas de Windows dans un conteneur. Le schéma interactif du §9.2 montre les namespaces (ce que le conteneur voit) et les cgroups (ce qu'il consomme).

Où voir un conteneur sur votre nœud :

Notion	Où la voir
Le conteneur	L'arborescence à gauche, sous le nœud : l'icône de cube ; `pct list`
Sa configuration	`/etc/pve/lxc/<id>.conf` (celle d'une VM : `/etc/pve/qemu-server/<id>.conf`) ; `pct config <id>`
Le noyau partagé	`pct exec 200 -- uname -r` donne la même version que `uname -r` sur le nœud
Ses limites	L'onglet Resources du conteneur (mémoire, cœurs)
Ses processus vus de l'hôte	§9.2 : le `systemd` du conteneur, avec son PID côté hôte

9.2 LXC — histoire et mécanismes noyau

9.2.1 Origine et place dans l'écosystème

LXC — Linux Containers — a été développé en 2008 par Daniel Lezcano chez IBM (constructeur informatique américain). C'est une interface de haut niveau vers les primitives d'isolation que le noyau Linux avait progressivement intégrées depuis le milieu des années 2000.

Docker est apparu cinq ans plus tard, avec une couche d'abstraction supplémentaire orientée application. LXC, lui, reste proche du noyau : c'est une virtualisation légère de système, pas de processus.

Proxmox VE intègre LXC via son propre outil, pct — le Proxmox Container Toolkit. pct est la commande qui fait le lien entre l'interface graphique Proxmox, l'API, et les primitives LXC sous-jacentes. Quand vous créez un conteneur depuis l'interface web, c'est pct create qui s'exécute en coulisses.

9.2.2 Les deux piliers : namespaces et cgroups

L'isolation dans LXC repose sur deux mécanismes du noyau Linux. Ce sont eux qui définissent à la fois ce qu'un conteneur sait faire, et ses limites.

Les namespaces sont la brique d'isolation : ils définissent ce que le conteneur voit. LXC utilise les six historiques :

pid — le conteneur voit ses propres processus ; son premier processus a le PID 1 de son point de vue ;
net — sa propre pile réseau : interfaces, routes, pare-feu ; c'est ce qui lui donne une adresse IP indépendante ;
mnt — son propre système de fichiers, ancré dans un répertoire dédié sur l'hôte ;
uts — son propre nom d'hôte ;
ipc — l'isolation des communications entre processus ;
user — le remappage des identifiants, clé des conteneurs non privilégiés (§10.1).

Les cgroups v2 (control groups) sont la brique de limitation : ils définissent combien le conteneur peut consommer (CPU, mémoire, disque). Chaque conteneur a son groupe dans /sys/fs/cgroup/lxc/<id>/.

La différence qui compte face à une VM : ces limites ne réservent rien. Un conteneur plafonné à 4 Go n'immobilise pas 4 Go : il n'utilise que ce dont il a besoin, et le reste profite aux autres. C'est pourquoi un même hôte porte bien plus de conteneurs que de VM.

C'est aussi ce qui rend le réglage modifiable à chaud : pct set 200 --memory 2048 change la limite d'un conteneur en marche, sans redémarrage. Deux options se confondent souvent :

--cores 2 dit combien de processeurs le conteneur voit et peut occuper en parallèle ;
--cpulimit 1.5 dit combien de temps de calcul au total il peut consommer, tous cœurs confondus : ici, l'équivalent d'un processeur et demi.

Dans un conteneur Proxmox, free -m affiche la limite du conteneur, et nproc le nombre de cœurs attribués : Proxmox recalcule ces informations pour chaque conteneur.

Limite importante : tous les conteneurs LXC partagent le noyau de l'hôte. Si ce noyau comporte une faille de sécurité, un conteneur compromis peut potentiellement l'exploiter pour sortir de l'isolation. C'est pourquoi les mises à jour du noyau de l'hôte Proxmox restent critiques, même quand on n'utilise que des conteneurs.

9.3 Comparatif technique : Conteneurs système (LXC) vs Conteneurs d'application (Docker)

Deux questions reviennent très souvent en formation.

"Puisque Docker est de la conteneurisation et LXC aussi, pourquoi ne pas utiliser Docker directement dans Proxmox ?"
"Quelle est la différence concrète entre un conteneur LXC et un conteneur Docker ?"

Pour bien comprendre, il faut distinguer deux philosophies de la conteneurisation : la conteneurisation système (LXC) et la conteneurisation d'application (Docker). Bien qu'ils s'appuient tous deux sur les mêmes briques du noyau Linux (namespaces et cgroups), ils les exploitent de manière radicalement différente pour répondre à des besoins distincts.

Voici un tableau comparatif complet pour vous aider à y voir clair :

Critère de comparaison	Conteneurs Système (LXC / Proxmox)	Conteneurs d'Application (Docker)
Philosophie	Simuler une machine physique complète (Virtualisation légère). Le conteneur se comporte comme une VM.	Isoler un seul processus applicatif (Micro-services). Le conteneur ne vit que pour exécuter sa commande.
Processus d'initialisation	Exécute un gestionnaire d'initialisation complet (comme `systemd` ou `init`) en tant que PID 1.	Exécute directement l'application cible (ex: `nginx`, `python myscript.py`) en tant que PID 1.
Gestion des services	Permet de faire tourner de multiples services en parallèle (cron, syslog, sshd, bases de données) gérés par systemd.	Conçu pour ne faire tourner qu'un seul processus. Pas de démon système par défaut, pas de sshd ni de cron.
Gestion du réseau	Intégration réseau de niveau OS (système d'exploitation) avec IP dédiée, configuration dans `/etc/network/interfaces` ou par DHCP, pontage direct (`vmbr`).	Réseau géré par le moteur Docker (souvent via un réseau NAT interne `docker0` avec translation de ports).
Persistance des données	Persistance par défaut sur le système de fichiers du conteneur (comme sur un disque dur classique).	Éphémère par défaut. Les données doivent être montées via des volumes ou des bind-mounts pour persister.
Cycle de vie	Longue durée. On met à jour le conteneur en se connectant dessus (via `apt upgrade`), on l'arrête, on le redémarre.	Éphémère et jetable. Pour mettre à jour, on détruit le conteneur et on en recrée un nouveau à partir d'une image mise à jour.
Outil de gestion	`pct` sous Proxmox VE, CLI `lxc` sous Linux.	CLI `docker`, `docker compose`.
Cas d'usage idéaux	Hébergement de serveurs web traditionnels, bases de données classiques, serveurs de fichiers, environnements de test multi-services.	Déploiements micro-services cloud-native, pipelines CI (Continuous Integration) et CD (Continuous Deployment), applications découplées à scalabilité horizontale.

À retenir : un conteneur LXC partage le noyau du nœud : les namespaces l'isolent, les cgroups limitent ce qu'il consomme. Il démarre en une seconde et ne pèse presque rien, mais il ne peut faire tourner que du Linux. LXC fait un système complet ; Docker, une application.