Un conteneur applicatif est une unité logicielle qui exécute typiquement un seul processus. C’est une forme sans état, centrée sur les services ou les microservices, qui favorise l’infrastructure immuable et éphémère. Quand vous devez mettre à jour ce que le conteneur exécute, vous ne corrigez pas le conteneur en marche — vous construisez un nouveau conteneur à partir d’une nouvelle image et remplacez l’instance en cours d’exécution.
En quoi ils diffèrent des conteneurs système
Les conteneurs système se comportent comme des VM légères : ils sont avec état, ils démarrent un userland complet et ils exécutent n’importe quel nombre de processus à l’intérieur. Les conteneurs applicatifs font l’inverse — ils sont réduits à un processus et ils traitent le système de fichiers comme étant en lecture seule à l’exécution.
Le compromis :
- Les conteneurs système conviennent aux applications traditionnelles qui s’attendent à un environnement Unix familier avec plusieurs processus coopérants.
- Les conteneurs applicatifs conviennent aux services mis à l’échelle horizontalement où chaque instance fait une tâche et tout état persistant vit ailleurs.
État et persistance
Les conteneurs applicatifs ne conservent pas d’état. Tout ce qui doit survivre à un redémarrage — fichiers téléversés, données de session, configuration applicative, journaux, contenu de base de données — doit vivre sur du stockage externe. La plateforme fournit plusieurs motifs pour cela :
- Volumes persistants montés depuis le système de fichiers local, des conteneurs de données dédiés, des conteneurs maîtres de couche ou des serveurs NFS externes.
- Niveaux de bases de données gérés auxquels d’autres conteneurs applicatifs se connectent sur le réseau interne.
- Stockage partagé de type objet pour les téléversements de fichiers et les blobs binaires.
- Expédition centralisée des journaux pour garder les journaux hors du système de fichiers du conteneur.
Cette séparation du code et de l’état est ce qui fait fonctionner l’infrastructure éphémère — vous pouvez reconstruire n’importe quel conteneur à tout moment sans perdre ce qui importe aux utilisateurs.
Pourquoi l’adoption initiale a été lente
Aux premiers jours des conteneurs applicatifs, le modèle avait de réelles frictions. L’isolation entre conteneurs était plus faible qu’aujourd’hui, certaines technologies (notamment les runtimes Java et les moteurs de bases de données) ne se comportaient pas bien en tant que conteneurs mono-processus, et les développeurs devaient apporter des changements significatifs pour adapter des applications existantes au modèle.
La plupart de ces frictions ont disparu. Les runtimes de conteneurs sont matures, l’isolation s’est améliorée et l’écosystème d’outils de support — planificateurs, maillages de services, observabilité, gestionnaires de secrets — rend l’exploitation à grande échelle praticable.
Implémentations et le choix de la plateforme
Plusieurs runtimes de conteneurs applicatifs sont en développement actif : Docker, CRI-O, containerd et autres. Stack Harbor PaaS utilise Docker, qui est le plus largement adopté de l’ensemble. La plateforme superpose à Docker ce qui ne fait pas partie de Docker lui-même : l’automatisation du déploiement, le provisionnement rapide de conteneurs, le support des instantanés et sauvegardes, les gestionnaires de journaux et de configuration, et un endroit pour mettre l’état que vos conteneurs ne devraient pas conserver.
Quand les conteneurs système restent le meilleur choix
Certaines charges de travail ne migrent toujours pas bien vers les conteneurs applicatifs. Surveillez :
- Les applications qui s’attendent à plusieurs processus coopérants (services de style
systemd, arborescences supervisord, démons cron tournant à côté du processus principal). - Les applications qui ont besoin de root ou de changements au niveau du noyau à l’exécution.
- Les bases de données avec état ou les files de messages où l’histoire de stockage et de réplication n’est pas résolue dans un modèle mono-processus.
- Les exigences d’isolation lourdes qui dépassent ce que fournissent les conteneurs applicatifs.
Pour celles-ci, les conteneurs système de la plateforme — ou ses piles gérées certifiées construites sur eux — conviennent généralement mieux. Pour tout le reste, les conteneurs applicatifs (Docker ou Kubernetes) vous donnent une mise à l’échelle plus rapide et une histoire de déploiement plus propre.