⚠️ Traduction non officielle - Cette documentation est une traduction communautaire non officielle de Docker.

Comment fonctionnent les services

Pour déployer une image d'application quand Docker Engine est en mode Swarm, vous créez un service. Fréquemment, un service est l'image pour un microservice dans le contexte d'une application plus large. Des exemples de services pourraient inclure un serveur HTTP, une base de données, ou tout autre type de programme exécutable que vous souhaitez exécuter dans un environnement distribué.

Lorsque vous créez un service, vous spécifiez quelle image de conteneur utiliser et quelles commandes exécuter à l'intérieur des conteneurs en cours d'exécution. Vous définissez également des options pour le service incluant :

  • Le port où le swarm rend le service disponible à l'extérieur du swarm
  • Un réseau overlay pour que le service se connecte à d'autres services dans le swarm
  • Les limites et réservations de CPU et mémoire
  • Une politique de mise à jour progressive
  • Le nombre de répliques de l'image à exécuter dans le swarm

Services, tâches et conteneurs

Lorsque vous déployez le service dans le swarm, le gestionnaire swarm accepte votre définition de service comme l'état désiré pour le service. Ensuite, il planifie le service sur des nœuds dans le swarm comme une ou plusieurs tâches de réplique. Les tâches s'exécutent indépendamment les unes des autres sur des nœuds dans le swarm.

Par exemple, imaginez que vous voulez équilibrer la charge entre trois instances d'un écouteur HTTP. Le diagramme ci-dessous montre un service d'écouteur HTTP avec trois répliques. Chacune des trois instances de l'écouteur est une tâche dans le swarm.

 Service d'écouteur HTTP avec trois répliques

Un conteneur est un processus isolé. Dans le modèle du mode Swarm, chaque tâche invoque exactement un conteneur. Une tâche est analogue à un "slot" où le planificateur place un conteneur. Une fois que le conteneur est actif, le planificateur reconnaît que la tâche est dans un état en cours d'exécution. Si le conteneur échoue aux vérifications de santé ou se termine, la tâche se termine.

Tâches et planification

Une tâche est l'unité atomique de planification au sein d'un swarm. Lorsque vous déclarez un état de service désiré en créant ou mettant à jour un service, l'orchestrateur réalise l'état désiré en planifiant des tâches. Par exemple, vous définissez un service qui instruit l'orchestrateur de garder trois instances d'un écouteur HTTP en cours d'exécution en permanence. L'orchestrateur répond en créant trois tâches. Chaque tâche est un slot que le planificateur remplit en générant un conteneur. Le conteneur est l'instanciation de la tâche. Si une tâche d'écouteur HTTP échoue par la suite à sa vérification de santé ou plante, l'orchestrateur crée une nouvelle tâche de réplique qui génère un nouveau conteneur.

Une tâche est un mécanisme unidirectionnel. Elle progresse de manière monotone à travers une série d'états : assignée, préparée, en cours d'exécution, etc. Si la tâche échoue, l' orchestrateur supprime la tâche et son conteneur et crée ensuite une nouvelle tâche pour la remplacer selon l'état désiré spécifié par le service.

La logique sous-jacente du mode Swarm de Docker est un planificateur et orchestrateur généraliste. Les abstractions de service et de tâche elles-mêmes ne sont pas conscientes des conteneurs qu'elles implémentent. Hypothétiquement, vous pourriez implémenter d'autres types de tâches comme des tâches de machine virtuelle ou des tâches de processus non-conteneurisés. Le planificateur et l'orchestrateur sont agnostiques quant au type de la tâche. Cependant, la version actuelle de Docker ne supporte que les tâches de conteneur.

Le diagramme ci-dessous montre comment le mode Swarm accepte les demandes de création de service et planifie les tâches aux nœuds travailleurs.

Flux des services

Services en attente

Un service peut être configuré de manière à ce qu'aucun nœud actuellement dans le swarm ne puisse exécuter ses tâches. Dans ce cas, le service reste dans l'état pending. Voici quelques exemples de quand un service pourrait rester dans l'état pending.

Tip

Si votre seule intention est d'empêcher un service d'être déployé, mettez le service à l'échelle à 0 au lieu d'essayer de le configurer de manière à ce qu'il reste en pending.

  • Si tous les nœuds sont en pause ou drainés, et que vous créez un service, il est en attente jusqu'à ce qu'un nœud devienne disponible. En réalité, le premier nœud à devenir disponible obtient toutes les tâches, donc ce n'est pas une bonne chose à faire dans un environnement de production.

  • Vous pouvez réserver une quantité spécifique de mémoire pour un service. Si aucun nœud dans le swarm n'a la quantité requise de mémoire, le service reste dans un état en attente jusqu'à ce qu'un nœud soit disponible qui peut exécuter ses tâches. Si vous spécifiez une très grande valeur, comme 500 GB, la tâche reste en attente pour toujours, à moins que vous n'ayez vraiment un nœud qui peut la satisfaire.

  • Vous pouvez imposer des contraintes de placement sur le service, et les contraintes peuvent ne pas pouvoir être honorées à un moment donné.

Ce comportement illustre que les exigences et la configuration de vos tâches ne sont pas étroitement liées à l'état actuel du swarm. En tant qu'administrateur d'un swarm, vous déclarez l'état désiré de votre swarm, et le gestionnaire travaille avec les nœuds dans le swarm pour créer cet état. Vous n'avez pas besoin de micro-gérer les tâches sur le swarm.

Services répliqués et globaux

Il y a deux types de déploiements de service, répliqués et globaux.

Pour un service répliqué, vous spécifiez le nombre de tâches identiques que vous voulez exécuter. Par exemple, vous décidez de déployer un service HTTP avec trois répliques, chacune servant le même contenu.

Un service global est un service qui exécute une tâche sur chaque nœud. Il n'y a pas de nombre pré-spécifié de tâches. Chaque fois que vous ajoutez un nœud au swarm, l' orchestrateur crée une tâche et le planificateur assigne la tâche au nouveau nœud. De bons candidats pour les services globaux sont les agents de surveillance, les scanners antivirus ou d'autres types de conteneurs que vous voulez exécuter sur chaque nœud dans le swarm.

Le diagramme ci-dessous montre une réplique de trois services en gris et un service global en noir.

Services globaux vs répliqués

En savoir plus

  • Lisez comment les nœuds du mode Swarm fonctionnent.
  • Apprenez comment PKI fonctionne en mode Swarm.