Bonjour tous,
j'ai une question à poser aux connaisseurs (ce n'est pas mon cas) de Docker ou Podman.
j'ai un serveur Centos 6 sur lequel tourne une application dont la version ne peut être installée sur un OS plus récent.
Vous semble-t-il possible de "containériser" cette application pour la faire tourner sur un OS plus récent du genre Almalinux 9 ou 10 ?
Si par hasard la réponse est positive, quels sont les problèmes auxquels je peux être confronté ?
Dans le pire des cas, est-ce possible de "containériser" tout l'OS avec l'appli ?
Merci d'avance de vos éclairages.
P.S : j'ai un peu chercher mais les IA me donnent des réponses un peu contradictoires alors je demande à des humains.
# fuis
Posté par BAud (site web personnel) . Évalué à 1 (+2/-3). Dernière modification le 04 mars 2026 à 10:37.
EOL https://endoflife.date/centos security support Ended 5 years ago (30 Nov 2020)
elle n'a pas besoin d'IE 6 côté poste de travail non plus ?
si ton appli ne peut pas évoluer c'est qu'elle ne répond à aucun besoin avéré, autant l'abandonner, sinon il y aurait un remplacement envisagé et le budget associé
[^] # Re: fuis
Posté par tontonrico . Évalué à 2 (+1/-0).
Ah ben le problème c'est que l'appli a bien évolué (heureusement) mais le client a contractuellement spécifié que cette version de l'appli doit être utilisée jusqu'à la fin du projet (qui est très long :)). Nous sommes obligés de continuer à bosser avec des OS EOL et des softs "anciens".
Sinon on a aussi des systèmes à jour avec des appli à jour mais le taf est compliqué et on est souvent obligé de supporter ce cas de figure.
Merci tout de même pour la réponse !
[^] # Re: fuis
Posté par BAud (site web personnel) . Évalué à 0 (+0/-2).
n'importe quel audit de sécurité annulera toute clause de support éventuel, quand bien même serait-il rémunéré : il est naturellement conditionné par la résolution de toutes les CVE apparues depuis l'EOL.
Il mettra en lumière les risques portés par le client, en fonction des données traitées.
La conteneurisation ne va pas continuer à faire fonctionner magiquement tel quel une appli rétive aux évolutions techniques ; au pire une VM trouée par le 1er audit d'intrusion n'y pourvoira pas non plus.
La diminution du support va avec l'augmentation de son coût malgré la réduction de périmètre de responsabilité, permettant d'arbitrer une version technique aux dépends d'une version fonctionnelle. C'est de la gestion du changement basique. Quelles versions de RHEL les équipes de ton client acceptent de gérer par leurs propres moyens ?
[^] # Re: fuis
Posté par tontonrico . Évalué à 1 (+0/-0).
j'aime bien ta réponse et tes arguments qui se tiennent tout à fait, mais je ne sais pas si le responsable du projet comprendrait la problématique. C'est à creuser quoi qu'il en soit…
Quant à la dernière question, nous ne connaissons pas les équipes de nos clients et ce qu'ils utilisent/supportent.
Merci !
[^] # Re: fuis
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1).
bin il vous manque un architecte technique dans l'équipe pour épauler le responsable projet.
Une appli ce n'est pas que du dév', on livre et le client se débrouille avec : il a des coûts de déploiement et d'exploitation de son côté aussi.
pour 30 j.h de dév' facturés, il y a 365 j/an à faire fonctionner l'appli aussi.
# ça dépend
Posté par Benoît Sibaud (site web personnel) . Évalué à 8 (+5/-0).
La réponse habituelle : ça dépend.
On peut faire tourner des vieux trucs dans un conteneur Docker ou LXC.
Est-ce que c'est une bonne idée ? Non pas vraiment, ça serait mieux d'avoir une appli récente et qui soit prévue pour tourner dans un conteneur. Mais bon on ne fait pas toujours ce que l'on voudrait ou ce qui serait souhaitable.
On ne sait pas si l'appli peut facilement être mise en conteneur ou pas. Ça dépend si elle a des dépendances fortes sur le noyau et ses ABI, sur par exemple les cgroups (possiblement un changement de version cgroups v1 vs v2 entre une CentOS6 et une AlmaLinux 9 ?), sur Systemd, si elle a besoin de capabilities particulières ou non, etc.
(nb: pour LinuxFr.org, on a déplacé des conteneurs LXC Debian 9, créés initialement sur des Ubuntu 14, vers du Debian 12, mis à jour en Debian 13 ensuite, et on a rencontré une partie de ces problèmes. Bref c'est possible, mais ce n'est pas la fête quand même)
[^] # Re: ça dépend
Posté par NeoX . Évalué à 7 (+4/-0).
probleme similaire ici
un conteneur avec du Zimbra8 sur ubuntu18 ou ubuntu20
un proxmox en v5, monter en version successive vers v6, v7 …
puis à un moment, ca marche plus
à cause de ces capabilities plus supportées, etc
bilan on regarde pour le remonter dans une VM,
au pire la VM reste "trouée" car ubuntu20 et zimbra8, mais elle est independante du systeme qui porte le serveur principal
car il ne fait pas oublié qu'une docker/lxc/whatever conteneur, va utiliser le kernel et la RAM du serveur principal, donc il doit pouvoir causer avec les ABI et autres…. qui ont peu etre depréciées avec le temps
[^] # Re: ça dépend
Posté par tontonrico . Évalué à 2 (+1/-0).
Merci de ta réponse, ça conforte mon opinion de départ.
# Petite précision qui n'arrange rien
Posté par tontonrico . Évalué à 3 (+2/-0).
Ah j'avais oublié de préciser que l'appli en question n'est pas nôtre et que les sources sont fermées :)
Est-ce que ça joue dans la création d'un container le fait que l'appli soit "fermée"?
[^] # Re: Petite précision qui n'arrange rien
Posté par Marc Quinton . Évalué à 3 (+1/-0). Dernière modification le 06 mars 2026 à 16:46.
non, pas du tout. Il te suffit de créer un projet avec :
suite au build de l'image, tu passes ensuite en "run". Bon courage et bonnes lectures.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.