Chapitre 1311 minIntermédiaire
Docker sur Proxmox VE : dans une VM ou dans un conteneur LXC ?
Par Josselyn C., prof de BTS SIO. Mis à jour le .
À la fin de ce chapitre, tu sauras
- comparer VM, conteneur LXC et conteneur OCI pour faire tourner des conteneurs ;
- créer une VM Docker dans Proxmox VE 9 avec les bons réglages ;
- configurer un conteneur LXC pour Docker sans le rendre privilégié ;
- sauvegarder une VM Docker sans perdre la cohérence de ses bases ;
- placer la VM Docker sous haute disponibilité et dire ce que cela garantit.
4 exercices corrigés1 schéma
Sur Proxmox VE, on peut faire tourner Docker de trois façons : dans une machine virtuelle (la méthode recommandée), dans un conteneur LXC avec l'imbrication activée, ou, depuis Proxmox VE 9.1, sans Docker du tout, en créant un conteneur LXC directement à partir d'une image OCI. Ce chapitre compare les trois, crée la VM Docker de Sorbier pas à pas dans l'interface de Proxmox VE 9, puis explique comment la sauvegarder sans perdre la cohérence des bases de données.
Trois façons de faire
| Méthode | Principe | Isolation | Avantages | Inconvénients |
|---|---|---|---|---|
| VM avec Docker Engine | Une VM Debian 13 dans laquelle on installe Docker, comme sur un serveur physique | Forte : noyau propre à la VM | Fonctionne exactement comme la documentation de Docker le décrit ; migration à chaud entre nœuds ; sauvegarde complète par Proxmox | Un peu plus de mémoire et de disque (un système complet) |
| Conteneur LXC avec Docker | Un conteneur système Proxmox (CT), dans lequel on installe Docker ; il faut l'option d'imbrication (nesting) | Plus faible : le CT et ses conteneurs Docker partagent le noyau de l'hôte Proxmox | Léger, démarrage rapide | Imbrication de deux technologies de conteneurs : comportements surprenants (stockage, AppArmor, mises à jour du noyau de l'hôte) ; pas de migration à chaud |
| Conteneur d'application OCI (Proxmox VE 9.1 et suivants) | Proxmox télécharge une image OCI (celle de Docker Hub, par exemple) et en fait un CT, sans Docker | Celle d'un CT LXC | Aucun moteur Docker à maintenir, intégration à l'interface de Proxmox | Aperçu technologique : pas pour la production ; pas de Compose, pas de réseaux ni de volumes Docker |
La documentation de Proxmox VE le dit clairement : pour l'isolation maximale et la migration à chaud, faire tourner les conteneurs dans une VM reste la pratique recommandée. C'est le choix de Sorbier : srv-gestion est une VM.
Créer la VM Docker dans Proxmox VE 9
Dans l'interface web de Proxmox VE, bouton Create VM en haut à droite. L'assistant compte huit onglets :
- General : le nœud, un identifiant (VM ID) et le nom
srv-gestion. - OS : l'image ISO de Debian 13 (téléversée au préalable dans le stockage
local, rubrique ISO Images), type Linux, version 6.x - 2.6 Kernel. - System : laisse le contrôleur VirtIO SCSI single et coche Qemu Agent.
- Disks : le disque système (32 Go), bus SCSI, cases Discard et IO thread cochées ; ajoute un second disque de 50 Go pour
/var/lib/docker. - CPU : 2 cœurs ; le type par défaut,
x86-64-v2-AES, convient, ouhostsi tous les nœuds du cluster ont le même processeur. - Memory : 4096 Mo.
- Network : le pont
vmbr0, VLAN Tag20(le VLAN serveurs), modèle VirtIO (paravirtualized). - Confirm : relis et valide.
Installe ensuite Debian 13 (installation minimale avec le serveur SSH), donne-lui son adresse fixe, puis installe l'agent invité, qui permet à Proxmox d'arrêter proprement la VM et de figer ses systèmes de fichiers pendant une sauvegarde :
sudo apt install qemu-guest-agent
sudo systemctl start qemu-guest-agent
Il ne reste qu'à installer Docker Engine comme au chapitre 2. Les notions d'hyperviseur, de pont, de VLAN taggé et de stockage de Proxmox sont dans le cours Virtualisation.
Docker dans un conteneur LXC
Si tu choisis tout de même un CT, pour un laboratoire ou un service peu critique, crée-le non privilégié (case Unprivileged container, cochée par défaut), puis vérifie dans Options > Features que nesting est activé, et active keyctl, dont Docker a besoin dans un CT non privilégié. En ligne de commande, sur l'hôte Proxmox (ici pour le CT 120) :
pct set 120 --features nesting=1,keyctl=1
pct reboot 120
Les options d'un CT ne s'appliquent qu'à son démarrage, d'où le redémarrage. Installe ensuite Docker dans le CT comme dans une VM.
Les conteneurs d'application OCI de Proxmox VE 9
Depuis la version 9.1, Proxmox VE sait récupérer une image OCI dans un registre et l'utiliser comme modèle de conteneur. Dans un stockage qui accepte les modèles (par exemple local), rubrique CT Templates, le bouton Pull from OCI registry télécharge une image (docker.io/library/nginx:1.30-alpine, par exemple). L'assistant Create CT la propose ensuite comme modèle. Selon l'image, Proxmox crée un conteneur système complet ou un conteneur d'application, qui ne lance que le programme de l'image ; on peut lui passer des variables d'environnement.
C'est pratique pour un service isolé, mais la documentation le classe en aperçu technologique : réserve-le aux essais. Il ne remplace pas Docker pour une application de plusieurs services : pas de fichier Compose, pas de réseau privé entre services, pas de volumes nommés.
Sauvegarder une VM Docker
La sauvegarde de la VM par Proxmox (tâche planifiée dans Datacenter > Backup, vers un stockage de sauvegarde ou un Proxmox Backup Server) emporte tout : le système, Docker, les images, les volumes. Avec l'agent invité, Proxmox demande à la VM de figer ses systèmes de fichiers pendant l'instantané : les fichiers sont cohérents sur le disque.
Pour une base de données, ce n'est pas une garantie suffisante : MySQL peut avoir des transactions en mémoire au moment du gel. La bonne pratique combine les deux niveaux :
| Niveau | Outil | Sert à |
|---|---|---|
| La VM entière | Sauvegarde Proxmox VE (vzdump, Proxmox Backup Server) | Reconstruire srv-gestion après une panne ou une erreur grave |
| Les données applicatives | Export logique planifié (mysqldump dans le conteneur, chapitre 6), copié hors du serveur | Restaurer une base précise, à une date précise, sans toucher au reste |
| La configuration | compose.yaml, Caddyfile, scripts dans Git | Redéployer à l'identique sur un autre serveur |
Les politiques de sauvegarde, la règle 3-2-1 et le plan de reprise sont traités dans le cours Sauvegarde et PRA.
Relancer srv-gestion sur un autre nœud : la haute disponibilité
La sauvegarde protège les données, pas la disponibilité : si le serveur physique qui porte srv-gestion tombe, l'application reste arrêtée jusqu'à ce qu'on restaure la VM ailleurs. Dans un cluster Proxmox VE, le gestionnaire de haute disponibilité redémarre lui-même la VM sur un nœud survivant. Il lui faut :
- un cluster d'au moins trois nœuds (ou deux nœuds et un arbitre externe, le QDevice), pour que la majorité, le quorum, décide sans ambiguïté qui est en panne ;
- le disque de la VM sur un stockage partagé (Ceph, NFS ou iSCSI d'un NAS) ou répliqué entre les nœuds, pour qu'un autre nœud puisse le lire ;
- un réseau de cluster fiable, séparé si possible du trafic des VM.
Pour placer srv-gestion sous haute disponibilité, dans l'interface web : Datacenter > HA, section Resources, bouton Add, choisis la VM, laisse l'état demandé (Request State) sur started et valide. En ligne de commande, sur un nœud du cluster, ha-manager add vm:<VMID> --state started fait la même chose, et ha-manager status affiche l'état des ressources.
Pour Docker, rien ne change : la VM redémarre sur l'autre nœud comme après une coupure de courant, le démon démarre, et les conteneurs en restart: unless-stopped repartent. C'est un redémarrage, pas une continuité de service : compte quelques minutes d'interruption, le temps que le cluster constate la panne, isole le nœud perdu et relance la VM. Le cluster, le quorum, l'isolement d'un nœud en panne (fencing) et les autres formes de redondance sont expliqués dans le cours Haute disponibilité, au chapitre Haute disponibilité des VM.
Exercices
Exercice 1 sur 4 Choisir l'hébergement Réussi À revoir
Pour chaque besoin, propose la méthode d'hébergement sur le Proxmox de Sorbier et justifie.
- L'application
sorbier-frais(quatre conteneurs, données personnelles des salariés). - Un essai d'une heure d'un outil de tableau de bord publié sous forme d'image OCI.
- Un service DNS de test pour un TP, sans données.
Voir la réponseMasquer la réponse de l'exercice 1
- Une VM avec Docker Engine : application de production, avec des données personnelles, plusieurs services (Compose, réseaux, secrets) ; la VM offre l'isolation la plus forte, la migration à chaud et une sauvegarde complète.
- Un conteneur d'application OCI (aperçu technologique) ou un conteneur dans la VM Docker de test : pour un essai sans données, la simplicité prime ; on supprime tout après.
- Un CT LXC non privilégié ou un conteneur dans une VM de laboratoire : sans données ni enjeu, la légèreté d'un CT convient. Pour un service DNS, un CT système classique (sans Docker) est d'ailleurs le plus simple.
Tu avais trouvé ?
Exercice 2 sur 4 La sauvegarde incomplète Réussi À revoir
L'administrateur affirme : « srv-gestion est sauvegardé chaque nuit par Proxmox, donc la base de sorbier-frais est protégée. » Nuance cette affirmation et complète le dispositif.
Voir la réponseMasquer la réponse de l'exercice 2
La sauvegarde de la VM contient bien les fichiers de la base (le volume Docker est sur le disque de la VM). Mais :
- même avec l'agent invité qui fige les systèmes de fichiers, une base en cours d'écriture n'est pas garantie cohérente : une restauration peut demander une récupération, voire échouer ;
- restaurer une base seule (par exemple après une suppression accidentelle de lignes) oblige à restaurer toute la VM, ou à fouiller dans la sauvegarde ;
- si la sauvegarde reste sur le même stockage que la VM, une panne ou un rançongiciel peut emporter les deux.
Compléments : un export logique planifié de la base (mysqldump --single-transaction dans le conteneur), copié hors de srv-gestion ; une copie des sauvegardes hors site (règle 3-2-1) ; et surtout un test de restauration régulier, consigné.
Tu avais trouvé ?
Exercice 3 sur 4 Le CT qui refuse Docker Réussi À revoir
Un technicien a installé Docker dans un CT non privilégié. docker run hello-world échoue avec une erreur de permission. Il propose de cocher « privilégié ». Que réponds-tu ?
Voir la réponseMasquer la réponse de l'exercice 3
Non : un CT privilégié donne au root du conteneur les droits du root de l'hyperviseur, et tout conteneur Docker compromis à l'intérieur atteindrait Proxmox et toutes les VM. Il faut d'abord vérifier les options du CT : nesting et keyctl doivent être activés (Options > Features), puis redémarrer le CT. Si le service est destiné à la production, la bonne réponse est de l'installer dans une VM, la méthode recommandée par la documentation de Proxmox VE.
Tu avais trouvé ?
Exercice 4 sur 4 Haute disponibilité ou sauvegarde ? Réussi À revoir
Le directeur de Sorbier a lu que srv-gestion est « en haute disponibilité » dans le cluster Proxmox à trois nœuds. Il en conclut que les sauvegardes de la VM ne servent plus à rien, et qu'une panne d'un nœud ne coupera jamais l'application de notes de frais. Corrige ses deux affirmations.
Voir la réponseMasquer la réponse de l'exercice 4
- Les sauvegardes restent indispensables. La haute disponibilité relance la VM sur un autre nœud quand un nœud tombe ; elle ne protège ni contre une suppression de données, ni contre un rançongiciel, ni contre une mise à jour ratée, ni contre la perte du stockage partagé : la VM redémarrerait avec les mêmes données abîmées. Seule une sauvegarde, copiée hors du cluster et testée, permet de revenir en arrière.
- Une panne coupe l'application quelques minutes. La VM n'est pas dupliquée en temps réel : le cluster doit constater la panne, isoler le nœud perdu, puis redémarrer la VM ailleurs. Le système démarre, le démon Docker relance les conteneurs (
restart: unless-stopped), et le service revient. Les requêtes en cours au moment de la panne sont perdues.
Tu avais trouvé ?