2026 : comment mettre à jour les conteneurs à partir d’images OCI dans Proxmox VE 9.2 ?

Une nouvelle version est disponible dans le dépôt, mais le conteneur en service continue d’exécuter l’ancienne image.

Décision rapide — adapté à une application simple dont les données et la restauration sont maîtrisées ; à éviter comme substitut direct à Docker si le service exige des mises à jour fréquentes, plusieurs conteneurs coordonnés ou un cycle de déploiement élaboré. Dans Proxmox VE 9.2, vérifiez d’abord les opérations documentées pour votre version, sauvegardez les données, puis préparez et validez une nouvelle instance avant de basculer.

Ce guide s’adresse aux administrateurs qui testent les conteneurs OCI dans Proxmox VE et cherchent une méthode de mise à jour vérifiable.
Il concerne aussi les équipes MSP qui maintiennent plusieurs services et doivent rendre leurs changements reproductibles.
Les responsables d’applications hébergées sur un serveur dédié y trouveront les contrôles à prévoir pour les données persistantes et le retour arrière.

Dernière mise à jour : 26 octobre 2026. Les versions et les limites fonctionnelles sont vérifiées à partir des annonces officielles de Proxmox VE 9.1 et 9.2 et des documents de gestion des conteneurs. Les discussions communautaires citées plus loin signalent des questions d’utilisateurs ; elles ne constituent pas une garantie de fonctionnement.

Vérifier d’abord la version et le périmètre OCI

Proxmox VE 9.1, publié le 19 novembre 2025, a ajouté la possibilité de créer des conteneurs LXC à partir d’images OCI. Proxmox VE 9.2 a été publié le 21 mai 2026. Ces repères confirment l’introduction de la capacité et la version examinée ici, mais ne suffisent pas à conclure qu’un conteneur existant peut être « mis à jour sur place » comme un service Docker. Les dates et la capacité annoncée figurent dans les notes de version de 9.1 et de 9.2.

Commencez par relever la version installée, ainsi que l’identifiant et la configuration du conteneur. Sur l’hôte, la commande suivante affiche les versions des composants Proxmox :

pveversion -v

Pour consulter la configuration d’un conteneur, pct config <CTID> est une vérification utile ; remplacez <CTID> par son identifiant. Conservez le résultat hors de l’instance que vous envisagez de modifier. Comparez ensuite ces informations avec la documentation applicable à votre version, plutôt qu’avec une commande trouvée dans une discussion consacrée à une autre version.

Il faut distinguer quatre opérations qui sont souvent confondues :

• Obtenir une image depuis un registre ne modifie pas, à lui seul, le conteneur déjà lancé.
• Traiter ou convertir une image, si le flux de travail concerné l’exige, est une opération distincte de la récupération de l’image.
• Créer une nouvelle instance à partir d’une image disponible prépare un nouveau conteneur ; cela ne déplace pas automatiquement les données de l’ancien.
• Remplacer l’instance active implique une décision sur les données, la configuration réseau, le démarrage du service et la possibilité de revenir en arrière.

La documentation de Proxmox décrit la gestion des conteneurs et les opérations disponibles ; elle doit primer sur une extrapolation à partir du comportement d’un moteur Docker. Le format OCI définit les éléments d’une image, notamment son manifeste, mais ne garantit pas qu’un hôte transforme toute image en mise à jour automatique d’une instance en cours. La spécification du manifeste OCI aide à comprendre le format ; elle ne décrit pas le cycle de mise à jour propre à Proxmox.

Distinguer le téléchargement du remplacement

Une étiquette plus récente dans un registre indique qu’une version d’image est disponible. Elle ne prouve ni que Proxmox l’a téléchargée, ni qu’une instance existante l’utilise, ni que les fichiers écrits dans cette instance seront conservés lors de son remplacement. Pour éviter toute ambiguïté, consignez séparément la référence de l’image actuelle, la référence envisagée, l’identifiant du conteneur et les paramètres dont dépend l’application.

Les discussions de la communauté Proxmox sur les images OCI et sur la mise à jour d’un conteneur OCI illustrent les questions rencontrées par des utilisateurs. Ces témoignages ne démontrent pas qu’une méthode particulière est officiellement prise en charge dans toutes les versions, ni que les limites signalées constituent une règle générale.

La règle opérationnelle est donc simple : si la documentation correspondant à l’installation ne décrit pas explicitement une mise à jour en place pour le cas considéré, ne fabriquez pas une commande en supposant que « tirer » une image remplacera le système de fichiers du conteneur. Préparez une instance distincte, testez-la et gardez l’ancienne intacte tant que la nouvelle n’a pas passé les contrôles. Une fonction de création depuis une image n’équivaut pas à une expérience complète de gestion d’images, de déploiement et d’orchestration.

Comparer les deux voies de déploiement

Le choix dépend moins de la seule présence d’une image OCI que du mode de maintenance que l’application exige. Le tableau suivant constitue un outil de décision : il oppose les voies selon les tâches que l’équipe doit réellement prendre en charge, sans prétendre qu’une solution est toujours plus performante.

Un LXC applicatif issu d’une image OCI peut être pertinent pour une application unique et bien délimitée, à condition que son démarrage, ses ports, ses variables et son stockage soient documentés. À l’inverse, un flux reposant sur des fichiers de composition, des déploiements coordonnés et une gestion éprouvée des volumes doit être évalué dans une VM avec le moteur de conteneurs adapté. L’isolation et le modèle d’administration d’une VM ne sont pas identiques à ceux d’un LXC ; le choix doit répondre aux dépendances de l’application, pas à une promesse abstraite de vitesse.

Questions fréquentes sur les conteneurs OCI

Quelle est la méthode prudente pour passer un conteneur OCI à une nouvelle image dans Proxmox ?
Vérifiez d’abord la version de Proxmox VE et les opérations OCI documentées pour cette version. Recensez la configuration et les données persistantes, puis sauvegardez ces dernières hors du conteneur. Préparez une nouvelle instance de test avec l’image voulue, validez le service et ne basculez qu’après avoir défini une marche arrière. Ne supposez pas qu’un téléchargement d’image met à jour l’instance en cours.

Les fichiers de l’application restent-ils après la reconstruction d’un conteneur OCI ?
Pas nécessairement. Un fichier écrit dans le système de fichiers du conteneur peut disparaître lorsque l’instance est recréée ou remplacée. La conservation dépend de l’emplacement des données et de la configuration des points de montage. Identifiez notamment bases de données, téléversements et fichiers de configuration, puis testez leur restauration avant toute intervention sur le service de production.

Un conteneur OCI de Proxmox convient-il à un service de production permanent ?
Cela peut convenir à une application simple dont le démarrage, les données et la restauration ont été vérifiés, mais la prise en charge de la création depuis une image OCI ne garantit pas un cycle de vie comparable à celui d’un moteur Docker complet. Pour des déploiements fréquents, plusieurs services coordonnés ou une gestion élaborée des volumes, évaluez plutôt un moteur de conteneurs dans une VM.

En quoi un conteneur OCI créé par Proxmox diffère-t-il de Docker dans une VM ?
Proxmox VE permet de créer un conteneur LXC à partir d’une image OCI ; cette capacité ne signifie pas que l’hôte fournisse l’ensemble des outils, commandes et pratiques d’orchestration d’un moteur Docker. Dans une VM, l’administrateur peut installer le moteur et les outils de son choix, au prix de la gestion d’un système invité supplémentaire. Le choix dépend surtout du flux de déploiement et de la persistance attendue.

Séparer les données de l’instance remplaçable

Avant de préparer une image de remplacement, établissez la liste des fichiers et paramètres qui doivent survivre à la reconstruction. Les données ne se limitent pas aux bases de données : configuration de l’application, fichiers téléversés, certificats, tâches planifiées, secrets, variables d’environnement, comptes locaux et paramètres réseau peuvent être nécessaires au redémarrage. Notez pour chacun son emplacement, son propriétaire, ses permissions et la procédure prévue pour le restaurer.

Un fichier stocké uniquement dans le système de fichiers de l’instance ne doit pas être considéré comme persistant par défaut. Vérifiez dans la configuration du conteneur quels points de montage sont utilisés et comment ils sont reliés au stockage de l’hôte. Le comportement à attendre dépend de ce montage et du chemin de remplacement retenu ; confirmez-le sur un conteneur de test plutôt que de déduire la conservation des données du seul fait qu’une image a été téléchargée.

La sauvegarde doit pouvoir être restaurée, pas seulement apparaître comme une tâche terminée. La documentation officielle de sauvegarde et restauration avec vzdump décrit les fonctions concernées. Elle ne dispense pas de vérifier que les éléments importants pour votre application sont inclus et que la restauration fonctionne depuis l’emplacement choisi. La sauvegarde de l’hôte et la persistance attendue par l’application sont deux sujets à rapprocher avant l’intervention.

Avertissement — avant toute modification en production : planifiez une fenêtre de maintenance, vérifiez la sauvegarde des données persistantes et préparez une procédure de restauration. Si aucun retour arrière n’a été testé, ne supprimez pas l’ancienne instance et ne réalisez pas le remplacement en une seule opération irréversible. Proxmox VE ne fournit pas, dans le cadre de ce guide, une prestation de sauvegarde, de restauration ou d’exploitation administrée ; ces éléments doivent être organisés et contrôlés par l’équipe responsable.

Appliquer un remplacement contrôlé

Le déroulement ci-dessous sépare la préparation du changement de la bascule. Les libellés et capacités de l’interface, ainsi que les commandes disponibles, peuvent évoluer selon la version ; utilisez la documentation applicable à votre installation et ne substituez pas une commande issue d’un billet communautaire à une opération officiellement documentée.

1. Consigner l’état existant. Relevez la version de Proxmox VE, l’identifiant du conteneur, la référence de l’image connue, les paramètres de démarrage, les montages, les ressources attribuées et la configuration réseau. Conservez cette fiche hors de l’instance.
2. Inventorier les données. Distinguez les fichiers recréables des données irremplaçables, puis vérifiez que les points de montage annoncés sont ceux réellement utilisés par l’application. Un simple relevé de configuration ne prouve pas que l’application écrit au bon endroit.
3. Sauvegarder et restaurer en test. Faites une sauvegarde selon la procédure adaptée à la version et au stockage, puis testez sa restauration sur un environnement qui ne dessert pas le trafic de production. Consignez les fichiers absents ou les permissions incorrectes avant d’aller plus loin.
4. Vérifier l’image et le chemin de création. Enregistrez le nom ou la référence exacte de l’image, sa version et sa provenance. Consultez la documentation Proxmox VE correspondant à la version installée pour vérifier comment créer l’instance. Le format OCI organise des informations d’image, mais il ne valide ni la compatibilité applicative ni les données externes à l’image.
5. Créer une instance de test distincte. Préparez la configuration nécessaire sans réutiliser une adresse ou un point de montage de production de manière à créer un conflit. Utilisez des données de test ou une copie restaurée et gardez l’ancienne instance disponible.
6. Valider le service avant la bascule. Contrôlez le démarrage, les journaux, les connexions attendues, les permissions, les accès réseau et les fonctions de l’application qui manipulent les données. Vérifiez aussi que l’instance redémarre correctement après un arrêt contrôlé.
7. Basculer avec une marche arrière écrite. Notez l’ordre des opérations, les critères d’acceptation et la condition qui déclenche le retour à l’ancienne instance. Ne supprimez pas celle-ci tant que la nouvelle n’a pas été observée en fonctionnement et que le chemin de restauration n’a pas été confirmé.

À chaque étape, le résultat doit être reproductible par une autre personne de l’équipe. Une fiche qui mentionne seulement « image mise à jour » est insuffisante : elle ne dit ni quel identifiant a été modifié, ni quelle configuration a été reprise, ni comment rétablir l’ancienne version.

Valider la remise en service et le retour arrière

Avant de considérer le changement terminé, cochez les contrôles suivants :

• [ ] La version de Proxmox VE et la référence de l’image prévue sont consignées.
• [ ] Le nouveau conteneur démarre avec la configuration attendue et ne signale pas d’erreur bloquante dans ses journaux.
• [ ] L’application répond depuis le chemin d’accès prévu, et les connexions nécessaires fonctionnent.
• [ ] Les données attendues sont présentes après le redémarrage du conteneur ; ce contrôle a porté sur les fichiers réellement utilisés, pas seulement sur l’existence d’un point de montage.
• [ ] Les tâches planifiées, certificats, permissions, variables et accès aux services dépendants ont été testés.
• [ ] La restauration d’une sauvegarde a été répétée en environnement isolé et le résultat a été inspecté.
• [ ] L’identifiant de l’ancienne instance, la référence de son image, les montages et les étapes de retour arrière sont consignés.

Ce contrôle évite de confondre un démarrage réussi avec une mise à jour validée. Une application peut écouter sur le bon port tout en ayant perdu un fichier de configuration, en écrivant dans un emplacement temporaire ou en ne pouvant plus accéder à ses données après redémarrage. Pour un service avec état, la vérification de la persistance est donc aussi importante que l’ouverture de la page ou de l’interface de santé.

Les questions fréquentes officielles de Proxmox VE peuvent aider à clarifier des points généraux sur la plateforme, mais elles ne remplacent pas les essais de restauration et de fonctionnement propres à l’application. En cas d’écart entre une commande rapportée par un utilisateur et la documentation de la version installée, suspendez le changement et vérifiez le comportement sur une instance non critique.

Choisir l’environnement adapté au rythme de maintenance

Un service statique, simple et déjà validé peut être candidat à un conteneur créé depuis une image OCI, dès lors que l’équipe comprend la procédure de remplacement et sait protéger ses données. En revanche, une application dont les composants évoluent séparément, qui exige des déploiements coordonnés ou s’appuie sur un flux Docker existant nécessite d’évaluer une VM dédiée à son moteur de conteneurs. La différence centrale est le modèle de gestion et de maintenance, pas une supériorité universelle de performance.

Pour l’indépendant serveur virtualisé, le choix doit également intégrer la capacité à exploiter les invités et à conserver des sauvegardes indépendantes. Plusieurs conteneurs dans une même machine partagent les ressources physiques ; leur nombre acceptable dépend de leur consommation réelle, de leurs périodes de pointe et des marges nécessaires au système hôte. Sans mesures des charges de travail, il serait trompeur de promettre un nombre fixe d’instances ou un débit donné.

Lorsque les applications sont déjà validées et doivent fonctionner durablement, comparez les besoins en mémoire, stockage et accès réseau à la configuration d’un serveur dédié, plutôt que de choisir uniquement selon le coût initial d’une VM partagée. Les environnements mutualisés peuvent introduire une contention entre voisins, des ressources CPU partagées et des règles de stockage ou de facturation différentes ; à l’inverse, un serveur physique dédié demande de prévoir soi-même l’administration, les sauvegardes et le retour arrière. Une charge légère ou temporaire peut rester mieux adaptée à une petite instance flexible.

Pour vérifier si un serveur dédié convient au projet, examinez les options actuelles de Proxmox VE, de mémoire et de stockage dans la présentation de SFP Cloud, puis comparez les ressources et le cycle de facturation indiqués sur la page des offres. La décision doit suivre les besoins mesurés des VM et des conteneurs, et non une capacité théorique supposée : l’hébergement matériel ne remplace ni la validation des images OCI, ni l’organisation des données persistantes, ni les essais de restauration.

Questions fréquentes

1. Q
   Quelle est la méthode prudente pour passer un conteneur OCI à une nouvelle image dans Proxmox ?

   Vérifiez d’abord la version de Proxmox VE et les opérations OCI documentées pour cette version. Recensez la configuration et les données persistantes, puis sauvegardez ces dernières hors du conteneur. Préparez une nouvelle instance de test avec l’image voulue, validez le service et ne basculez qu’après avoir défini une marche arrière. Ne supposez pas qu’un téléchargement d’image met à jour l’instance en cours.

2. Q
   Les fichiers de l’application restent-ils après la reconstruction d’un conteneur OCI ?

   Pas nécessairement. Un fichier écrit dans le système de fichiers du conteneur peut disparaître lorsque l’instance est recréée ou remplacée. La conservation dépend de l’emplacement des données et de la configuration des points de montage. Identifiez notamment bases de données, téléversements et fichiers de configuration, puis testez leur restauration avant toute intervention sur le service de production.

3. Q
   Un conteneur OCI de Proxmox convient-il à un service de production permanent ?

   Cela peut convenir à une application simple dont le démarrage, les données et la restauration ont été vérifiés, mais la prise en charge de la création depuis une image OCI ne garantit pas un cycle de vie comparable à celui d’un moteur Docker complet. Pour des déploiements fréquents, plusieurs services coordonnés ou une gestion élaborée des volumes, évaluez plutôt un moteur de conteneurs dans une VM.

4. Q
   En quoi un conteneur OCI créé par Proxmox diffère-t-il de Docker dans une VM ?

   Proxmox VE permet de créer un conteneur LXC à partir d’une image OCI ; cette capacité ne signifie pas que l’hôte fournisse l’ensemble des outils, commandes et pratiques d’orchestration d’un moteur Docker. Dans une VM, l’administrateur peut installer le moteur et les outils de son choix, au prix de la gestion d’un système invité supplémentaire. Le choix dépend surtout du flux de déploiement et de la persistance attendue.