Services VS Containers

DOCKER : Service VS Container

Si vous suivez mes aventures, vous savez que je me forme à Docker Swarm depuis quelques jours (semaines bientôt).

Ce qui m'a le plus épaté à ce stade de mon apprentissage, c'est l'approche par services.

Comprendre la distinction entre un service et un container est essentiel pour maîtriser l'orchestration Swarm.

Ces deux concepts opèrent à des niveaux d'abstraction différents et servent des objectifs distincts dans la gestion des applications conteneurisées.

Le container : l'unité d'exécution fondamentale

Un container docker représente une instance en cours d'exécution d'une image.

On parle de l'unité de base de la conteneurisation : un processus isolé qui s'exécute sur un système hôte avec ses propres ressources système virtualisées.

Caractéristiques du container

Un container possède un cycle de vie propre : il démarre, s'exécute, puis s'arrête.

Chaque container dispose de son propre système de fichiers, de ses variables d'environnement et de son espace réseau isolé.

Cette isolation garantit qu'un container ne peut pas interférer directement avec un autre, même s'ils partagent le même système hôte.

Lorsque vous exécutez la commande 'docker run nginx', vous créez et démarrez un container unique basé sur l'image nginx.

Il s'exécute avec une configuration spécifique, écoute sur des ports définis, et dispose de ressources allouées selon les paramètres fournis.

Gestion individuelle

Chaque container est géré individuellement.

Vous pouvez l'arrêter, le redémarrer, consulter ses logs ou ajuster ses ressources de manière isolée.

Si ce container s'arrête pour une raison quelconque, il ne redémarre pas automatiquement sauf configuration explicite.

---

Le service : l'abstraction de déploiement

Un service docker représente une définition déclarative d'une application à déployer.

Plutôt que de gérer des containers individuels, vous définissez l'état souhaité de votre application, et docker swarm se charge de maintenir cet état.

La déclaration d'intention

Quand vous créez un service, vous ne lancez pas directement un container.

Vous déclarez une intention : "je veux que 3 instances de nginx soient toujours en cours d'exécution sur mon cluster, réparties selon ces contraintes, avec cette configuration réseau."

Cette approche déclarative transforme fondamentalement la gestion des applications.

Au lieu de micro-gérer chaque container, vous exprimez le résultat souhaité et laissez l'orchestrateur s'occuper de l'implémentation.

Gestion automatisée

Le service assure la réconciliation continue entre l'état actuel et l'état désiré.

Si un container d'un service s'arrête inopinément, le service en relance automatiquement un nouveau.
Si un nœud du cluster tombe en panne, les containers hébergés sur ce nœud sont automatiquement redistribués sur les nœuds disponibles.

Allez prenons l'exemple concret d'un serveur web nginx pour illustrer cette différence.

Approche container

docker run -d --name mon-nginx -p 80:80 nginx

Cette commande crée et démarre un seul container nginx. Si ce container s'arrête, votre site devient inaccessible.

Pour le relancer, vous devez intervenir manuellement.

Si vous voulez plusieurs instances pour répartir la charge, vous devez créer et gérer chaque container séparément.

Approche service

docker service create --name nginx-service --replicas 3 -p 80:80 nginx

Cette commande crée un service qui maintient 3 répliques de nginx en permanence.

Docker swarm gère automatiquement ces 3 containers, les redistribue si nécessaire, et maintient toujours 3 instances actives.

Le service inclut également un load balancer intégré qui répartit le trafic entre les 3 instances.

Impact opérationnel

La différence devient évidente lors d'une panne.

Quand un container tombe en panne, c'est une interruption de service jusqu'à intervention manuelle.

Quand la panne concerne un service, une instance est automatiquement compensée par le redémarrage d'un nouveau container sur un nœud disponible.

Montons en complexité et considérons une application web classique composée d'un frontend, d'une api et d'une base de données.

Communication

Communication entre containers

Les containers communiquent via des adresses ip ou des liens explicites. Si un container redémarre, son adresse ip peut changer, cassant potentiellement les connexions. La configuration réseau doit être gérée manuellement.

Communication entre services

Les services bénéficient d'un dns automatique. Un service nommé api-service reste accessible via ce nom, indépendamment des containers sous-jacents. Quand des instances s'arrêtent et redémarrent, le nom de service reste constant, assurant une connectivité transparente.

Surveillance et maintenance

Monitoring des containers

Chaque container doit être surveillé individuellement. Vous devez implémenter vos propres mécanismes de health check, de log aggregation, et de metrics collection. La gestion des mises à jour nécessite l'arrêt et le redémarrage manuel de chaque container.

Monitoring des services

Les services offrent des capacités de surveillance intégrées. Docker swarm surveille automatiquement la santé des containers via des health checks configurables. Les mises à jour peuvent être déployées de manière progressive avec rollback automatique en cas de problème.

Mise à jour et déploiement

Rolling updates

Cette différence devient particulièrement évidente lors des déploiements. Avec des containers individuels, vous devez orchestrer manuellement les mises à jour pour éviter les interruptions de service.

Les services supportent nativement les rolling updates. Quand vous mettez à jour un service, docker swarm met à jour progressivement les containers un par un, maintenant la disponibilité du service pendant toute la durée de l'opération.

'docker service update --image nginx:1.21 nginx-service'

Cette commande met à jour le service vers la nouvelle version d'image en remplaçant graduellement chaque container, sans interruption de service.

Choix de l'approche

Quand utiliser des containers

Les containers individuels conviennent pour le développement local, les tests rapides, ou les applications monolithiques simples où la haute disponibilité n'est pas critique.

Ils offrent une simplicité opérationnelle pour des cas d'usage basiques.

Quand utiliser des services

Les services deviennent indispensables pour les environnements de prod, les applications distribuées, ou tout contexte qui demande de la haute disponibilité, de la scalabilité automatiqu et une gestion simplifiée des déploiements.

Conclusion

La distinction entre service et container reflète deux philosophies de gestion des applications conteneurisées.

Les containers offrent un contrôle granulaire adapté aux environnements simples, tandis que les services fournissent l'abstraction et l'automatisation nécessaires aux déploiements complexes.

Maîtriser cette différence vous permet de choisir l'approche appropriée selon votre contexte et de progresser naturellement des déploiements simples vers l'orchestration avancée.

Cette compréhension forme la base de l'expertise en gestion d'infrastructures conteneurisées modernes.