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 :
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.
FAQ : les images OCI sur Proxmox
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.