Rechercher dans la communauté

IT-Connect Publié le 9 mars 2026 Par Florian BURNEL it-connect.fr Environ 9 minutes de lecture Proxmox VE 9.1 a introduit une nouveauté attendue pour les conteneurs LXC : la possibilité de lancer des images de conteneurs applicatifs (provenant de Docker Hub ou GitHub), sans passer par une machine virtuelle intermédiaire ni installer Docker. La raison : la prise en charge des images OCI. Dans notre tutoriel sur la prise en main des conteneurs LXC, nous avons vu comment déployer des "conteneurs systèmes" (une Debian ou une Ubuntu complète). Aujourd'hui, nous allons apprendre à exploiter l'intégration native des images OCI (Open Container Initiative). Cette fonctionnalité permet, par exemple, de déployer une solution de monitoring comme Uptime Kuma ou un serveur web Nginx très rapidement, en piochant dans la bibliothèque d'images existantes, tout en bénéficiant de la légèreté de LXC. Vous pouvez aussi lire mes précédents tutoriels dédiés à Proxmox VE : Bien débuter avec Proxmox VE : le guide complet Proxmox VE : comment créer une machine virtuelle Windows 11 ? Proxmox VE : la gestion des snapshots La configuration du réseau avec Proxmox VE : le guide pour bien débuter OCI sur LXC : ce que ça change Pour bien saisir ce que change cette nouveauté (encore considérée comme étant en préversion), il faut s'intéresser à la différence entre un conteneur système et un conteneur applicatif. Jusqu'ici, pour faire tourner une application "dockerisée" sur Proxmox VE, l'administrateur devait effectuer les actions suivantes : Créer une machine virtuelle ou un conteneur LXC standard (Debian). Installer le moteur Docker au sein de la VM ou du conteneur. Lancer le conteneur via docker run ou Docker Compose. Avec la prise en charge native des images OCI, Proxmox supprime l'intermédiaire, c'est-à-dire ce besoin de créer un conteneur LXC ou une machine virtuelle. L'hyperviseur est capable de télécharger l'image et de l'exécuter directement avec le moteur LXC. Pour autant, il est important de comprendre que Proxmox VE n'a pas de moteur Docker ! Vous exécutez l'image nginx:alpine ou uptime-kuma directement sur le noyau de Proxmox via un conteneur LXC. Pas de Daemon Docker, pas de VM, juste les couches de l'image OCI. Zoom sur les images OCI : au-delà de Docker Avant de manipuler ces images en pratique sur Proxmox VE, il me semble important de démystifier le terme images OCI. Une image OCI n'est pas - obligatoirement - une image Docker. OCI signifie Open Container Initiative Il s'agit d'une norme commune adoptée par les géants de la tech (Docker, Google, Red Hat, IBM) pour les images de conteneurs. Ce standard est important pour éviter une guerre entre les standards des uns et des autres qui aurait fragmenté le marché. Pour faire une analogie simple : imaginez que l'image OCI soit au conteneur ce que le format MP3 est à la musique. Peu importe que vous utilisiez VLC, Windows Media Player ou iTunes (le Runtime) pour écouter la musique, tant que le fichier est au format MP3 (le Standard), il sera lu correctement. Docker sait lire des images OCI, tout comme Proxmox VE. Chacun à sa façon, mais le résultat est là. De quoi est composée une image OCI ? Concrètement, quand vous téléchargez une image Docker (qui est en fait une image OCI), vous récupérez une archive structurée contenant trois éléments clés : Le manifeste (Manifest) : il liste les fichiers à télécharger et l'architecture CPU cible (amd64, arm64). Les couches (Layers) : c'est le système de fichiers, sous la forme d'un millefeuille de couches empilées permettant de former, ensemble, l'image. Par exemple, une couche pour l'OS de base (Alpine), une couche pour les binaires Python, une couche pour votre application. La configuration : un fichier JSON qui dit "Au démarrage, lance la commande /app/start.sh" . C'est grâce à cette standardisation que Proxmox VE est capable de faire opérer la magie de "lire" les images OCI. On peut imaginer que Proxmox VE effectue les étapes suivantes : Télécharger les couches depuis le Docker Hub. Les décompresser et les assembler. Les "donner à manger" à son propre moteur LXC, sans avoir besoin d'installer le moteur Docker. LXC reste donc le composant clé et Docker inexistant dans ce processus. Création d'un conteneur LXC avec une image OCI Dans le cadre de cette démonstration, nous allons prendre pour exemple l'outil de surveillance Uptime Kuma. Il est léger, moderne et parfait pour ce contexte d'utilisation. Télécharger une image applicative La première étape consiste à télécharger l'image OCI. Il n'est pas nécessaire de déclarer le Docker Hub comme dépôt, car il est déjà déclaré dans Proxmox VE. Depuis l'interface Web de Proxmox VE, suivez ces étapes : Allez dans votre stockage (par exemple : local). Cliquez sur la section "CT Templates", comme pour les templates LXC classiques. Cliquez sur le bouton "Pull from OCI Registry" situé à côté des autres boutons (si vous ne le voyez pas, c'est que vous devez mettre à jour PVE). Vous devez ensuite compléter le formulaire pour spécifier l'image OCI à télécharger. Dans le champ "Reference", saisissez le nom de l'image de façon explicite. Utilisez la syntaxe proprietaire/image ou repository/proprietaire/image. Ici, cela donnerait louislam/uptime-kuma ou alors de façon plus précise : Pour Docker Hub : docker.io/louislam/uptime-kuma Pour GitHub (GHCR) : ghcr.io/louislam/uptime-kuma Vous devez ensuite cliquer sur "Query tags", et si l'image a été trouvée, la liste des tags (et versions) sera affichée. Ici, je sélectionne le tag 2 pour récupérer la dernière version de la V2 d'Uptime Kuma. Lancez le téléchargement et patientez un instant. L'image OCI apparaît dans la bibliothèque aux côtés des autres modèles déjà téléchargés. Création et configuration du conteneur La création du conteneur est très similaire à celle d'un LXC classique. Une fois l'image téléchargée, cliquez sur le bouton "Créer CT". Onglet Général Donnez un ID, par exemple 303, et un nom comme lxc-oci-uptime-kuma. Décochez "Unprivileged container" si vous rencontrez des soucis de droits, bien que dans notre cas, Uptime Kuma fonctionnera bien dans un conteneur non-privilégié. Onglet Template Sélectionnez l'image louislam/uptime-kuma que vous venez de télécharger, même si elle apparaît avec le nom de l'archive. Onglets Disques/CPU/Mémoire Allouez les ressources. Ici, il convient d'adapter en fonction des besoins de l'application. Uptime Kuma avec peu de sondes n'a pas besoin de beaucoup de ressources. Le fait d'associer un disque au conteneur implique que son stockage sera persistant. Onglet réseau La mise en réseau du conteneur est différente selon si l'image OCI est exécutée via LXC ou Docker. En effet, avec Docker, vous feriez un mappage de port (-p 3001:3001), tandis qu'avec LXC, le conteneur a sa propre adresse IP sur votre réseau (via le pont vmbr0 ou une autre interface sélectionnée). Vous avez le choix entre le DHCP ou la configuration d'une adresse IP statique. Configurez le DNS si nécessaire. Confirmez pour lancer la création du conteneur. Patientez le temps que la magie opère côté Proxmox. Personnaliser les variables d'environnement Avant d'exécuter un conteneur, vous pouvez personnaliser sa configuration en ajustant les variables d'environnement. En effet, dans le cas de l'utilisation d'une image OCI sur Proxmox VE en mode natif, il n'est pas possible de jouer sur les arguments de la commande docker run ou d'utiliser les directives d'un Docker Compose. De ce fait, c'est via cette méthode que l'on peut tenter de personnaliser la configuration d'une application. Dans la section "Options" du conteneur, double-cliquez sur "Environment". Une fenêtre avec les variables d'environnement définies dans l'image OCI va s'afficher. Vous pouvez en configurer d'autres, en fonction de ce qui est pris en charge par l'application déployée (consultez la documentation de la solution en question). Dans le cas d'Uptime Kuma, il existe de nombreuses variables d'environnement. Par exemple, la variable UPTIME_KUMA_PORT sert à personnaliser le port pour accéder à l'interface Web. Cela pourrait permettre de préciser 3002 à la place de 3001 (port par défaut). Une fois vos modifications effectuées, validez. C'est éditable à tout moment, mais la prise en charge des nouvelles valeurs implique un redémarrage du conteneur. Premier démarrage du conteneur Effectuez un clic droit sur le conteneur pour le démarrer via le bouton "Start". Cliquez sur l'onglet "Network" pour afficher l'adresse IP du conteneur. Ce sera utile pour récupérer l'adresse IP dans le cas où la carte réseau est configurée en DHCP. De plus, sur ce type de conteneurs applicatifs, vous n'avez pas toujours un shell interactif complet, donc l'onglet "Console" ne sera pas d'une grande utilité (cela varie d'une image à l'autre). Ouvrez un navigateur et spécifiez l'adresse IP du conteneur suivie du port 3001 (ou 3002 si la variable avec le port personnalisé a été appliquée). Voilà, l'interface de l'application apparaît à l'écran. Il ne reste plus qu'à faire la configuration initiale et profiter de cette application conteneurisée ! Pour le reste, c'est propre à l'application Uptime Kuma en elle-même, notamment pour la création de sondes. Conclusion L'intégration des images OCI dans Proxmox VE 9.1 marque une étape importante en matière de maturité pour les conteneurs LXC avec cet hyperviseur open source. Elle offre une méthode alternative, située à mi-chemin entre Docker et LXC, bien que ce dernier soit utilisé directement, pour exécuter des conteneurs applicatifs. Cette fonctionnalité est idéale pour des applications comme Uptime Kuma, Home Assistant, Pi-hole, etc.... puisque cela évite d'utiliser un conteneur avec un système complet ou même une machine virtuelle. Néanmoins, ce n'est pas encore adapté pour les projets avec plusieurs conteneurs (comme une stack Docker Compose basée sur un ensemble de microservices). La mise à jour des conteneurs LXC basés sur une image OCI semble être également une opération délicate, que j'aborderai dans un prochain article. Ai-je besoin d'installer Docker sur mon Proxmox pour utiliser les images OCI ? Non, absolument pas. C'est tout l'intérêt. Proxmox utilise LXC pour exécuter le contenu de l'image OCI. Le moteur Docker n'est pas présent. Puis-je utiliser des fichiers docker-compose.yml ? Non. Cette fonctionnalité ne gère que des conteneurs unitaires. Vous ne pouvez pas orchestrer plusieurs conteneurs avec un fichier YAML comme avec Docker Compose. À voir si une future version de Proxmox VE apporte des améliorations à ce sujet. Est-ce que Portainer peut gérer ces conteneurs LXC ? Non. Portainer parle à l'API Docker. Ici, il n'y a pas d'API Docker. Vous devez gérer ces conteneurs via l'interface web de Proxmox ou la commande pct. Les images "Alpine" fonctionnent-elles bien ? Oui, très bien. Elles sont extrêmement légères et démarrent quasi instantanément dans un conteneur LXC. Elles sont plus légères qu'une image Debian, Ubuntu ou autre. Quelle est la différence de consommation RAM par rapport à une VM Docker ? Elle est significative. Une VM Linux consomme minimum 512 Mo à 1 Go juste pour le système d'exploitation et le moteur Docker. Un conteneur OCI sur LXC ne consomme que la RAM du processus applicatif (parfois quelques méga-octets seulement). C'est un gain énorme. Le réseau fonctionne-t-il comme le "Bridge" de Docker ? Non. Par défaut, le conteneur est relié au pont de Proxmox (vmbr0, par exemple). Il se comporte comme une machine connectée sur votre réseau local (il demande une adresse IP à votre routeur/DHCP ou utilise une IP statique). Puisque docker logs n'existe pas, vous devez consulter la console du conteneur dans Proxmox, ou regarder directement les fichiers de logs dans /var/log (si l'application écrit dedans). Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 9 mars 2026 Par Florian BURNEL it-connect.fr Environ 16 minutes de lecture L’utilisation des conteneurs LXC sur Proxmox VE représente une méthode efficace pour exécuter plusieurs environnements Linux sur un même noyau, sans la lourdeur liée à l'utilisation de machines virtuelles complètes. Ce tutoriel vous explique pas à pas comment créer vos premiers conteneurs LXC sur Proxmox VE. Si vous avez régulièrement besoin d'exécuter des services légers qui ne nécessitent pas une machine virtuelle complète, alors le conteneur LXC (Linux Container) est la réponse adaptée. La raison : il offre des performances quasi natives. Il y a trois façons d'exécuter des conteneurs avec Proxmox VE : Exécuter un conteneur LXC à partir d'une image d'un système d'exploitation Linux de base Exécuter un conteneur LXC à partir d'une image OCI Exécuter un conteneur via Docker par l'intermédiaire d'une machine virtuelle ou d'un conteneur LXC dédié (ce qui est vrai aussi avec Podman) Les deux premières méthodes évoquées ci-dessus sont natives, tandis que la troisième méthode repose sur l'utilisation de Docker comme composant additionnel. Vous pouvez aussi lire mes précédents tutoriels dédiés à Proxmox VE : Bien débuter avec Proxmox VE : le guide complet Proxmox VE : comment créer une machine virtuelle Windows 11 ? Proxmox VE : la gestion des snapshots La configuration du réseau avec Proxmox VE : le guide pour bien débuter Comprendre l'architecture LXC vs KVM Avant de manipuler Proxmox VE pour créer votre premier conteneur, il est nécessaire de bien comprendre l'architecture de Proxmox VE. Celle-ci repose sur deux technologies : KVM et LXC. Contrairement à une VM KVM qui émule du matériel (carte mère, BIOS, disque) et charge son propre noyau (Kernel complet et indépendant), un conteneur LXC partage le noyau de l'hyperviseur (Proxmox VE). C'est une différence majeure entre une machine virtuelle et un conteneur. L'isolation, quant à elle, est assurée par deux mécanismes du noyau Linux : Les Namespaces : ils isolent les groupes de processus et de ressources les uns des autres. Le conteneur LXC "pense" être seul sur la machine. Les Cgroups (Control Groups) : ils limitent et mesurent l'utilisation des ressources (CPU, RAM, I/O) pour éviter qu'un conteneur ne sature l'hôte. En comparaison des machines virtuelles, les conteneurs ont deux avantages majeurs : ils démarrent très rapidement et l'empreinte mémoire est réduite (moins de RAM, moins d'espace disque). Néanmoins, il est à noter que les conteneurs LXC sont limités à l'exécution de distributions Linux (donc pas de Windows). La dépendance vis-à-vis du noyau du système d'exploitation hôte (Debian utilisé par Proxmox VE) s'avère être une contrainte dans certains cas. Autrement dit, certaines applications ne pourront pas s'exécuter dans un conteneur LXC (c'est d'autant plus vrai si vous utilisez un LXC pour exécuter des conteneurs Docker). Enfin, LXC n'est pas une technologie développée par Proxmox. Vous pouvez créer des conteneurs LXC sur Linux sans utiliser Proxmox VE. Quelques mots d'histoire : LXC est utilisé par Proxmox VE depuis la version 4.0, tandis qu'auparavant, il s'appuyait sur OpenVZ. Proxmox VE - Conteneur LXC vs Machine virtuelle Ci-dessous un comparatif permettant de bien comprendre les différences majeures entre un conteneur LXC et une machine virtuelle au niveau des fonctionnalités. Fonctionnalité Conteneur LXC Machine virtuelle Noyau Partagé (Hôte) Indépendant OS Supportés Linux uniquement Windows, Linux, BSD... Sauvegarde ✅ Oui ✅ Oui Instantané (Snapshot) ⚠️ Partiel (pas la RAM) ✅ Complet Migration à chaud ❌ Non (contrairement à LXD, qui ne doit pas être confondu avec LXC) ✅ Oui Pare-feu ✅ Oui ✅ Oui Modification de la RAM et du CPU à chaud ✅ Oui ✅ Hotplug (configuration de la VM et prise en charge par l'OS invité) Docker (Imbrication) ⚠️ Possible (option "Nesting") ✅ Natif Sécurité / Isolation Moyenne (namespace) Élevée (matériel virtuel) Créer son premier conteneur LXC sur Proxmox VE Gestion des modèles de conteneurs LXC Pour créer un conteneur, vous n'utilisez pas une image ISO d'installation classique, mais un Template (modèle). C'est une archive pré-installée et prête à l'emploi d'une distribution. Voyons comment importer un premier modèle. Connectez-vous à l'interface web de Proxmox. Dans l'arborescence à gauche, sélectionnez votre stockage (par défaut nommé local). Cliquez sur la section "CT Templates". Cliquez sur le bouton "Templates" dans la barre d'outils. Une liste de modèles officiels apparaît (Debian, Ubuntu, Alpine, CentOS, AlmaLinux, etc.). Recherchez le mot clé debian afin d'installer le modèle Debian 13 intitulé debian-13-standard. Sélectionnez-le et cliquez sur le bouton "Download". Je vous recommande Debian pour une raison simple : le conteneur LXC aura la même base que l'hôte Proxmox VE, ce dernier étant basé sur Debian. Et aussi, je dois l'avouer, j'apprécie beaucoup cette distribution. L'opération est relativement rapide car les fichiers sont légers (une centaine de mégaoctets pour une Debian sans interface graphique). Le modèle de conteneur est téléchargé. Il est prêt à l'emploi. La liste des modèles disponibles sur Proxmox VE contient un ensemble de modèles Turnkey Linux. Il s'agit d'images pré-configurées avec des applications prêtes à l'emploi, comme WordPress, Apache Tomcat, etc... Il y a des dizaines de modèles applicatifs prêts à l'emploi. Cela peut s'avérer pratique pour déployer rapidement une application à des fins de tests. Création d'un conteneur LXC Une fois le modèle récupéré, nous pouvons passer à la création d'un premier conteneur LXC basé sur celui-ci. Au sein de l'interface de Proxmox VE, cliquez sur le bouton bleu "Create CT" situé en haut à droite. Un assistant étape par étape similaire à celui disponible pour créer une machine virtuelle s'affiche à l'écran. Onglet Général Node : sélectionnez votre serveur Proxmox. CT ID : l'identifiant unique de ce conteneur, vous pouvez laisser Proxmox VE gérer. Hostname : le nom du conteneur, mais aussi du système dans le conteneur (par exemple : lxc-deb-01). Privileged vs Unprivileged : par défaut, la case "Unprivileged container" est cochée. Pour des raisons de sécurité, il est recommandé de conserver cette option cochée. Dans un conteneur non privilégié, l'utilisateur root à l'intérieur du conteneur est mappé vers un utilisateur sans privilèges sur l'hôte. Cela empêche le conteneur LXC de pouvoir impacter le système hôte (évasion du conteneur). Nesting : décochez cette option, sauf si vous souhaitez exécuter un conteneur dans ce conteneur (via Docker, par exemple). Néanmoins, elle est aussi nécessaire pour certains systèmes, comme Debian 13 (à cause de Systemd), donc ici nous devons cocher l'option, sinon le conteneur sera inutilisable. Password : définissez le mot de passe root du futur conteneur LXC. Vous pouvez aussi charger une clé SSH publique pour l'authentification par clé (recommandé) Onglet Template Sélectionnez ici le stockage où vous avez téléchargé votre template, puis choisissez l'image Debian 13 téléchargée précédemment. Onglet Disks Définissez la taille du disque virtuel. Pour un service web simple, 8 Go peuvent suffire. Ici, tout dépend de vos besoins en fonction de la finalité du conteneur LXC. Onglet CPU Spécifiez le nom de cœur de CPU alloué à ce conteneur. Adaptez éventuellement par la suite en fonction de la charge de ce conteneur. Onglet Memory Définissez la RAM, par exemple 512 Mo et le Swap. Contrairement aux VMs, la mémoire non utilisée par le conteneur reste disponible pour l'hôte. C'est aussi l'un des avantages de LXC. Onglet Network C'est ici que vous définissez la configuration réseau de votre conteneur. Bien souvent, une adresse IP sera allouée s'il s'agit d'un conteneur destiné à la production. Sinon, vous pouvez conserver le mode DHCP. Veillez également à sélectionner la bonne interface réseau (Bridge) et, si besoin ajoutez un numéro de VLAN. Onglet DNS Par défaut, le nom de domaine du serveur Proxmox et le même serveur DNS seront utilisés. Si besoin, adaptez ces valeurs ici. Lancez la création du conteneur, puis patientez un instant. Une fois le conteneur LXC créé, il apparaît dans l'inventaire de votre hôte. Vous remarquerez que les conteneurs ont un icône différent de celui des machines virtuelles. Pour démarrer le conteneur, effectuez un clic droit sur son nom, puis cliquez sur "Start". Utilisation du conteneur LXC Pour commencer à configurer ce conteneur LXC, utilisez la même méthode que pour l'administration d'une machine virtuelle : la console. L'accès SSH est aussi une option, même s'il faudra commencer par récupérer l'adresse IP du conteneur s'il est en DHCP (via l'onglet "Network" ou la ligne de commande). Via la console, connectez-vous à partir du mot de passe précisé lors de la configuration du conteneur. Le service SSH est déjà installé et configuré par défaut. La suite des opérations vous appartient ! Administration des conteneurs LXC avec pct Pour l'administration des conteneurs Proxmox VE, vous pouvez utiliser un outil en ligne de commande : Proxmox Container Toolkit. Il est accessible via la commande pct, et celle-ci s'exécute directement sur l'hôte Proxmox VE (et non dans le conteneur). Découvrons ensemble quelques commandes. Gestion des modèles LXC La commande pct contient les options nécessaires pour parcourir les modèles et effectuer le téléchargement d'un modèle. Nous aurions pu télécharger le modèle précédent à l'aide de cette commande. # Mettre à jour la liste des modèles pveam update # Lister les modèles Debian pveam available --section system | grep debian # Télécharger le modèle (aidez-vous de l'autocomplétion pour le nom) pveam download local debian-13-standard_13.1-2_amd64.tar.zst Vous pouvez ensuite lister les modèles de conteneurs disponibles sur l'espace de stockage, c'est-à-dire ceux déjà téléchargés. pveam list local NAME SIZE local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst 123.70MB Lister les conteneurs pct list # Exemple de sortie VMID Status Lock Name 301 running lxc-deb-01 302 running lxc-wordpress 303 running lxc-oci-uptime-kuma Afficher la configuration d'un conteneur LXC pct config <ID> # Exemple pct config 301 arch: amd64 cores: 1 features: nesting=0 hostname: lxc-deb-01 memory: 1024 net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:CF:75:CF,ip=dhcp,tag=10,type=veth ostype: debian rootfs: local-lvm:vm-301-disk-0,size=8G swap: 512 tags: lxc unprivileged: 1 Sachez que vous pouvez également consulter la configuration en allant lire directement le fichier brut (le nom du fichier correspond à l'ID du conteneur) : cat /etc/pve/lxc/301.conf Entrer dans un conteneur depuis l'hôte (sans SSH) C'est une fonction très pratique si vous avez perdu le mot de passe root, coupé l'accès réseau du conteneur ou simplement pour éviter d'exposer un accès distant. pct enter 301 # Exemple root@pve-01:~# pct enter 301 root@lxc-deb-01:~# root@lxc-deb-01:~# hostname lxc-deb-01 Dans la commande ci-dessus, remplacez 301 par l'ID de votre conteneur. Arrêter un conteneur proprement pct shutdown <ID> pct shutdown 301 Démarrer un conteneur LXC pct start <ID> pct start 301 Modifier la configuration du conteneur Vous pouvez modifier la configuration d'un conteneur à chaud, c'est-à-dire avec le conteneur en cours d'exécution. Si vous procédez via la commande pct, voici la syntaxe à respecter : p ct set <id> [OPTIONS] Si vous souhaitez ajouter de la RAM sans passer par l'interface graphique, vous pouvez utiliser cette technique. Voici comment passer à 1 024 Mo de RAM sur le conteneur avec l'ID 301. pct set 301 -memory 1024 Vous pourriez aussi décider de configurer, comme par exemple l'option "Nesting" directement via la ligne de commande. pct set 301 --features nesting=1 Créer un conteneur LXC en ligne de commande La commande pct est également capable de créer un conteneur LXC sur votre hôte Proxmox. Cela permet d'automatiser la création de conteneurs ! De ce fait, cette commande tout-en-un accepte énormément d'arguments lorsqu'il est question de créer et configurer un conteneur en une seule fois. La commande ci-dessous permet de créer et de configurer un conteneur sur le même principe que ce qui a été fait via l'interface graphique. À savoir, un conteneur avec l'image Debian 13, 512 Mo de RAM, 1 cœur de CPU, 8 Go de disque et une interface réseau en DHCP avec un tag sur le VLAN 10. En complément, l'option --start 1 permet de démarrer automatiquement le conteneur dès qu'il est prêt. pct create 304 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \ --hostname lxc-deb-04 \ --cores 1 \ --memory 512 \ --swap 512 \ --rootfs local-lvm:8 \ --net0 name=eth0,bridge=vmbr0,firewall=1,ip=dhcp,tag=10,type=veth \ --unprivileged 1 \ --features nesting=0 \ --tags lxc \ --password <MOT_DE_PASSE> \ --start 1 Suite à l'exécution de cette commande, un conteneur nommé lxc-deb-04 avec l'ID 304 a été créé. Exemple de sortie : Creating filesystem with 2097152 4k blocks and 524288 inodes Filesystem UUID: 17312070-d712-442d-9317-d0d98d72f201 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 extracting archive '/var/lib/vz/template/cache/debian-13-standard_13.1-2_amd64.tar.zst' Total bytes read: 551505920 (526MiB, 430MiB/s) Detected container architecture: amd64 Creating SSH host key 'ssh_host_rsa_key' - this may take some time ... done: SHA256:BLCIFdoaZ9M2aD8ammlmpvK8vI9c1GsvB5mPUPMUyD4 root@lxc-deb-04 Creating SSH host key 'ssh_host_ed25519_key' - this may take some time ... done: SHA256:Ivil+To1toVQMFRBFywn+mmdsM1A/6Sg7q2CDD6u2M8 root@lxc-deb-04 Creating SSH host key 'ssh_host_ecdsa_key' - this may take some time ... done: SHA256:MF9qEM33I+yRINHylGAumllD2i2Jdui+LHYPwgygyLU root@lxc-deb-04 WARN: Systemd 257 detected. You may need to enable nesting. WARN: Systemd 257 detected. You may need to enable nesting. Task finished with 2 warning(s)! Task finished with 1 warning(s)! Dans la sortie de cette commande, cette ligne est intéressante : WARN: Systemd 257 detected. You may need to enable nesting.. Elle laisse sous-entendre que ce conteneur a besoin du mode Nesting pour fonctionner, notamment à cause de Systemd qui a besoin de pouvoir utiliser la fonction de namespaces. C'est un avertissement qui est lié à Debian 13 (et à sa version de Systemd), comme je l'évoquais précédemment. Le mode Nesting doit être activé dans le conteneur. Je vous rappelle que c'est possible d'éditer la configuration du conteneur en ligne de commande : pct set 304 --features nesting=1 Grâce à un script Bash, notamment avec une boucle for et quelques variables, vous pourriez créer un script pour automatiser la création d'un ensemble de conteneurs. Supprimer un conteneur LXC Pour supprimer un conteneur LXC directement depuis le Terminal, vous devez l'arrêter puis le supprimer. Mais, attention, cette action est irréversible. Cette commande supprime le conteneur, sa configuration et son disque. pct stop <ID> && pct destroy <ID> --purge # Exemple : pct stop 304 && pct destroy 304 --purge Logical volume "vm-304-disk-0" successfully removed. purging CT 304 from related configurations.. Gestion avancée du stockage : bind mounts Si vous souhaitez partager un dossier de l'hôte Proxmox directement dans le conteneur LXC, c'est envisageable. C'est ce qu'on appelle un Bind Mount. On peut citer les cas d'usage suivants : Accéder à votre répertoire personnel (home) dans le système invité du conteneur, Accéder au contenu d'un périphérique USB dans le système invité du conteneur, Accéder aux données d'un partage NFS monté sur l'hôte dans le système invité du conteneur. Pour effectuer la configuration, vous avez deux options : éditer le fichier de configuration du conteneur (par exemple : /etc/pve/lxc/301.conf) ou utiliser la commande pct. Bien que cette pratique soit possible techniquement, elle a un impact au niveau de la sécurité. Avec un conteneur Unprivileged, vous rencontrerez des problèmes de permission. Pour corriger cela, il est nécessaire de basculer le conteneur en Privileged ou d'ajuster les permissions avec un mapping au niveau des ID... Une méthode est détaillée sur ce GitHub et, comme vous le verrez, cela implique de créer des groupes sur l'hôte Docker, puis d'ajuster la configuration dans le conteneur LXC, le tout sans passer le conteneur en Privileged. Dans le cas où le dossier doit être accessible uniquement en lecture seule dans le conteneur, cette contrainte n'existe pas. Imaginez que vous disposiez d'une banque de données sur l'hôte Proxmox dans /var/lib/vz/partage et que vous souhaitiez que votre conteneur puisse lire ces fichiers. Connectez-vous en SSH sur votre serveur Proxmox (l'hôte) et créez un dossier avec un fichier de test : mkdir -p /var/lib/vz/partage echo "Ceci est un fichier de démo pour IT-Connect" > /var/lib/vz/partage/demo.txt Vous devez ensuite configurer le point de montage. Nous allons utiliser la commande pct set pour ajouter ce point de montage à la configuration du conteneur. Nous utilisons l'option -ro 1 (Read-Only) pour garantir que le conteneur ne pourra pas supprimer ou modifier les données de l'hôte (lecture seule). Exécutez cette commande sur l'hôte (remplacez 301 par l'ID de votre conteneur) : pct set 301 -mp0 /var/lib/vz/partage,mp=/mnt/partage_pve,ro=1 Pour vous expliquer cette commande : mp0 : définit le premier point de montage (Mount Point 0). /var/lib/vz/partage : le chemin source sur l'hôte Proxmox. mp=/mnt/partage_pve : le chemin de destination à l'intérieur du conteneur. ro=1 : active le mode lecture seule. Redémarrez le conteneur pour appliquer les changements, puis connectez-vous à l'intérieur : pct reboot 301 pct enter 301 cat /mnt/partage_pve/demo.txt # Résultat : root@pve-01:~# pct enter 301 root@lxc-deb-01:~# cat /mnt/partage_pve/demo.txt Ceci est un fichier de démo pour IT-Connect Vous devriez voir le contenu du fichier créé sur l'hôte Proxmox ! Note : si vous avez besoin que votre conteneur puisse écrire dans ce dossier, la configuration se complexifiera ! Comme je l'expliquais précédemment, vous devrez soit basculer votre conteneur en mode "Privileged" (moins sécurisé), soit configurer un "ID Mapping" (mappage des utilisateurs) pour faire correspondre les droits de l'utilisateur du conteneur avec ceux du dossier de l'hôte. Privilégiez les montages en lecture seule ou l'utilisation de volumes de stockage dédiés directement sur les conteneurs. Sauvegarder et restaurer des conteneurs LXC La protection des données ne doit jamais être négligée, et cela est également vrai pour les conteneurs. La bonne nouvelle : Proxmox VE intègre un outil de sauvegarde pour les LXC. Le moteur de sauvegarde utilisé est vzdump. Il existe trois modes principaux pour les conteneurs : Mode Workflow Interruption de service Stop Arrêt complet du conteneur ➔ Sauvegarde ➔ Redémarrage. Longue (le temps de la copie !) Suspend 1er rsync (à chaud) ➔ Suspension ➔ 2ème rsync (différentiel) ➔ Reprise. Minimale (le temps de copier les différences) Snapshot Suspension ➔ Snapshot stockage ➔ Reprise immédiate ➔ Archivage en arrière-plan. Très faible (quasi imperceptible) Le mode "Stop" est très utile pour les services critiques où la cohérence des données doit être parfaite (une application qui pourrait y être sensible). Pour compléter ce tableau, voici deux informations à prendre en considération (ce qui fait notamment écho à la notion évoquée précédemment) : Les "Bind Mounts" sont exclus : Proxmox ne sauvegarde jamais le contenu des dossiers montés depuis l'hôte (les fameux Bind Mounts). C'est à vous de gérer leur sauvegarde séparément, côté hôte. Exclusion de volumes : si vous utilisez le mode Snapshot, tous les volumes du conteneur doivent supporter les snapshots. Si vous avez un disque spécifique qui ne le supporte pas, vous devez l'exclure de la sauvegarde en définissant une option sur le point de montage : backup=no. Pour réaliser une sauvegarde, vous avez deux options : une sauvegarde manuelle et immédiate directement depuis la section "Backup" du conteneur à sauvegarder, une sauvegarde planifiée via une tâche créée dans la section "Backup" du Datacenter. Pour programmer une sauvegarde automatique : Allez dans Datacenter > Backup. Créez un nouveau job. Sélectionnez l'heure, le stockage de destination et les conteneurs concernés. Sélectionnez le mode de sauvegarde (référez-vous au tableau ci-dessus). Validez la création du job. Un article complet sur la fonction de sauvegarde native de Proxmox VE sera publié prochainement. Conclusion En suivant ce guide, vous devriez être en mesure de créer vos premiers conteneurs LXC sur un hyperviseur Proxmox VE ! Pour aller plus loin, consultez l'article dédié à l'utilisation des images OCI avec les conteneurs LXC : Proxmox VE : exécuter des images OCI (Docker) nativement dans LXC Pour rappel, bien que les conteneurs soient isolés, ils partagent le même noyau que l'hôte physique. Voici quelques règles à respecter pour limiter l'impact au niveau sécurité : Privilèges : utilisez des conteneurs "Unprivileged" autant que possible. Nesting : activez l'option "Nesting" uniquement si nécessaire, SSH : si vous autorisez SSH dans le conteneur, interdisez le login root par mot de passe et préférez les clés SSH, exactement comme sur une VM ou un serveur physique. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet