Docker Swarm

Orchestration de conteneurs
• Les conteneurs sont éphémères par nature.
• Ils s'arrêtent lorsque le processus qu'ils contiennent se termine ou en
raison d'une erreur.
• Un seul conteneur par service peut ne pas suffire pour gérer le trafic
croissant de l'application.

• Dans tous les scénarios ci-dessus, nous avons besoin d'un outil capable
de redémarrer les conteneurs arrêtés ou d'en créer de nouveaux pour
gérer le trafic croissant et garantir l'équilibrage de charge (Load
balancing) et la haute disponibilité de l'application en permanence.

• C'est là qu'intervient l'orchestration des conteneurs !

Orchestration de conteneurs
• Qu'est-ce que l'orchestration des conteneurs ?
• L'orchestration des conteneurs consiste à gérer le cycle de
vie des conteneurs, en particulier dans les environnements
volumineux et dynamiques.
• Approvisionnement et déploiement des conteneurs
• Mise à l'échelle ou suppression des conteneurs pour répartir la
charge de l'application de manière uniforme sur l'infrastructure de
l'hôte.
• Déplacement des conteneurs d'un hôte à un autre s'il y a une
pénurie de ressources sur un hôte ou si un hôte tombe en panne.
• Équilibrage de charge de la découverte des services entre les
conteneurs.
Docker Swarm
• Swarm est la solution d'orchestration de conteneurs intégrée à Docker.
• Son objectif principal est de gérer les conteneurs dans un cluster, c'est-à-
dire un ensemble de machines connectées qui fonctionnent ensemble.
• Lorsqu'une nouvelle machine rejoint le cluster, elle devient un nœud dans
ce swarm.
• À l'aide de Docker Swarm, nous pouvons obtenir une haute disponibilité,
un équilibrage de charge et un accès décentralisé de nos applications.
• Swarm est intégré au moteur Docker. Vous n'avez pas besoin d'installer
quoi que ce soit pour commencer.
Docker Swarm
• Que peut-on faire en utilisant Docker Swarm ?
• Déployer de nouveaux conteneurs pour remplacer ceux qui sont tombés en
panne
• Mettre à l'échelle le nombre de conteneurs pour l'équilibrage de charge
• Déployer les mises à jour des applications parmi les conteneurs de manière
progressive
• Revenir en arrière sur les applications vers les versions antérieures
• Arrêter un nœud pour maintenance sans interruption de l'application
Architecture Docker Swarm
• Manager: gère le cluster
• Worker: exécute les tâches attribuées par le
planificateur
• Schedule: planifie les conteneurs sur les nœuds
en fonction des règles et des filtres
• Discovery Service: aide le gestionnaire Swarm à
découvrir de nouveaux nœuds et à extraire les
nœuds disponibles
• Store: stocke l'état du cluster, comme les
informations sur le cluster et les services Swarm.
Essentiellement, une base de données clé-valeur.
Docker Swarm : Overlay driver
• Les réseaux de pont (Bridge Network) s'appliquent aux conteneurs qui s'exécutent sur le même démon Docker
hôte.
• Pour la communication entre les conteneurs qui s'exécutent sur des hôtes de démon Docker différents, comme
dans swarm, il faut utiliser un réseau overlay.
• Si vous créez des services Swarm et que vous ne spécifiez pas de réseau, ils sont connectés au réseau ingress par
défaut, qui est également de type superposition.
• Le réseau superposé (overlay) s'étend sur l'ensemble du cluster Swarm, ce qui permet la communication entre
les conteneurs sur plusieurs nœuds.
 Docker Swarm : Démarrer un
cluster
• docker swarm init --advertise-addr IP_DU_GESTIONNAIRE
• root@docker-master # docker swarm init --advertise-addr 192.168.0.100

• Pour ajouter un Worker or Manager à ce swarm, exécutez la commande suivante :

docker swarm join --token SWMTKN-1-
3kabuqlekspyqdk02vj0strami9mcysj8lw4klp5cwmh3wm4ej-9rlom6m90chce1tgi0ke58t4l
192.168.0.100:2377

• Obtenir le jeton:
• docker swarm join-token manager
• docker swarm join-token worker
Docker Swarm
Service Docker
• Pour déployer une image d'application lorsque le moteur Docker est en mode swarm, vous créez
un service.
• Un service est l'image d'un microservice comme 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é.
• Un service a besoin d'une image de conteneur à utiliser, du port où le swarm met le service à
disposition à l'extérieur du swarm, d'un réseau superposé pour que le service se connecte à d'autres
services dans le swarm et du nombre de réplicas de l'image à exécuter dans le swarm.

• Créer un service
Service Docker
Visualiseur Docker Swarm
• Déployer un visualiseur (visualizer)
• docker service create
--name=viz
--publish=8080:8080/tcp
--constraint=node.role==manager
--mount=type=bind,src=/var/run/docker.sock,dst=/var/run/
docker.sock
dockersamples/visualizer

• Le tableau de bord est disponible à l'adresse http://<ip-du-

nœud>:8080
• ip-du-nœud : toute IP de nœud participant au cluster
• Bien que le pod soit lié au maître, il est accessible depuis tous les
nœuds en raison du maillage de routage ingress (ingress routing
mesh).
Service Docker
Service Docker
Service Docker
• Mettre à l'échelle un service
• docker service scale <nom_du_service>=8
• docker service scale web=10

• Mettre à jour un service

• docker service update --image <nom_de_l'image>:<version> <nom_du_service>
• docker service update --image nginx:1.18 web

• Mise à jour progressive

• docker service update --image <nouvelle_image> --update-parallelism 2 --update-delay 10s
<nom_du_service>
• docker service update --image nginx:1.18 --update-parallelism 2 --update-delay 10s web
Service Docker
• Imaginons qu'un nœud tombe en panne en raison d'un problème.
• Dans ce cas, les conteneurs affectés sur ce nœud sont recréés sur les
nœuds disponibles dans le cluster.
Service Docker
• Imaginons qu'un nœud doit être arrêté pour maintenance.
• Dans ce cas, nous vidons un nœud de ses charges de travail vers d'autres nœuds pour une terminaison
en douceur.
• Vider (drain) un nœud : docker node update --availability drain <nom_du_nœud>
• Remettre (undrain) un nœud en service : docker node update --availability active <nom_du_nœud>

• Imaginons que le nœud est de nouveau opérationnel après maintenance.

• Par défaut, Swarm ne redéploie pas les conteneurs que le nœud exécutait précédemment. Nous
devons forcer le cluster à partager la charge entre les nœuds disponibles.
• Forcer l'équilibrage de charge des charges de travail :
• docker service update --force <nom_du_service>
• Revenir en arrière sur une mise à jour : docker service update --rollback <nom_du_service>
• Supprimer un service : docker service rm <nom_du_service>
Docker Swarm : Overlay driver
• Créer un réseau overlay
• docker network create --driver overlay mon_reseau
• docker service create --replicas 5 -p 80:80 --network mon_reseau --name web nginx
Docker Swarm: Demo Swarm
service
• Pour utiliser une image personnalisée dans un cluster
Swarm:
• assurez-vous de pousser cette image sur Docker Hub ou dans un
dépôt privé afin que les nœuds Swarm puissent la récupérer.
• Sinon, veillez à ce que cette image soit disponible localement
sur tous les nœuds en la construisant manuellement à partir du
Dockerfile sur chaque nœud.
• Swarm ne programmera pas les conteneurs sur les nœuds qui
ne parviennent pas à récupérer l'image ou qui ne l'ont pas
localement !

• docker build –t <username>/flask-app .

• docker push <username>/flask-app
Docker Swarm: Demo Swarm
service
• docker service create --replicas 5 -p 80:5000 --name web
myusername/sampleflask:v2
• Visitez http://<node-ip>:80 et actualisez la page pour observer l'effet
de load balancing
Docker Networking : Ingress
network
• Est-il possible d'exécuter 2 conteneurs avec le même port
d'hôte publié en mode non swarm ?
• docker run –d –p 80:5000 --name web1 flask
• docker run –d –p 80:5000 --name web2 flask
• Non ! Cela provoque un conflit de port. Le démon Docker
n'autorise pas le même port d'hôte pour plusieurs
conteneurs en mode non swarm.
• Alors, comment Docker permet-il d'exécuter plusieurs
instances de la même application (avec le même mappage de
port d'hôte) sur un nœud à l'intérieur d'un cluster Swarm ?
• docker service create --replicas 5 -p 80:5000 --name web flask
• Maillage de routage ingress (Ingress Routing Mesh)
Docker Networking: Ingress
Network
• Le réseau ingress dispose d'un équilibrage de
charge intégré qui redirige le trafic du port publié
sur l'hôte vers les ports des conteneurs mappés.
• Cela permet à plusieurs conteneurs à l'intérieur
d'un hôte Docker d'utiliser le même port d'hôte
sans conflit de port.
• Aucune configuration externe n'est nécessaire,
l'équilibrage de charge fonctionne immédiatement
avec le réseau ingress.
• docker service create --replicas 5 -p 80:5000 --name
web flask
Docker Networking: Ingress
Routing Mesh
• Le maillage de réseau interne du swarm permet à chaque nœud du cluster d'accepter les
connexions vers n'importe quel port de service publié dans le swarm en acheminant toutes
les requêtes entrantes vers les nœuds disponibles qui hébergent un service avec le port
publié.
• docker service create --replicas 2 -p 80:5000 --name web flask
Docker Service: Ingress Routing
Mesh
• Tous les nœuds participent à un maillage de routage
ingress.
• Le maillage de routage permet à chaque nœud du
swarm d'accepter des connexions sur les ports publiés
pour tout service qui s'exécute dans le swarm, même
s'il n'y a pas de tâche en cours d'exécution sur le nœud.
• Le maillage de routage achemine toutes les
requêtes entrantes vers les ports publiés sur les
nœuds disponibles vers un conteneur actif.
• Dans ce scénario, nous avons 3 nœuds et 4 réplicas
de conteneurs web. Les conteneurs web sont
planifiés uniquement sur l'hôte 1 et l'hôte 2. Mais
nous pouvons toujours accéder aux services web à
partir de l'hôte 3 en raison du maillage de routage
du swarm.
Service Docker: Load Balancer (ingress
routing mesh)
• Le réseau ingress est un réseau
superposé spécial qui facilite
l'équilibrage de charge entre
les nœuds d'un service.
• Lorsqu'un nœud Swarm reçoit
une requête sur un port
publié, il transfère la requête à
un module appelé IPVS.
• IPVS conserve un suivi de
toutes les adresses IP qui
participent à ce service, en
sélectionne une et achemine la
requête vers celle-ci, sur le
réseau ingress.
 Docker Swarm: Persistent Storage
• Le stockage persistant consiste à stocker les données du conteneur au-delà de son cycle de
vie.
• Pour les conteneurs à hôte unique, les montages de liaison ou nommés fonctionnent bien,
mais pour partager des volumes de stockage entre plusieurs hôtes Docker, comme un
cluster Swarm, nous avons besoin d'un FS distribué ou d'un FS réseau.
• Utilisation de FS distribué/réseau
• Étant donné que les programmes qui s'exécutent sur votre
cluster ne sont pas garantis de s'exécuter sur un nœud
spécifique, les données ne peuvent pas être enregistrées à un
emplacement arbitraire dans le système de fichiers.
• Si un programme tente d'enregistrer des données dans un
fichier pour une utilisation ultérieure, mais est ensuite
relocalisé sur un nouveau nœud, le fichier ne sera plus à
l'endroit où le programme s'attend à le trouver.
• Un FS distribué/réseau permet aux applications d'avoir un
volume de stockage commun pour stocker et récupérer les
données au-delà de leur cycle de vie.
Docker Swarm: Persistent Storage in
single node
• Named Mount
• Bind Mount

• Le répertoire sur l'hôte est créé en dehors de Docker Engine's context.

• Les modifications contournent le backend et sont effectuées directement sur le volume de données.
• Les données sont partagées entre les conteneurs. Les données des conteneurs ne sont pas supprimées lorsque les conteneurs sont supprimés.
• Ces modifications de données ne seront pas incluses lors des mises à jour d'image.
Docker Swarm: Persistent Storage across
cluster
• Nécessite un système de fichiers
distribué/réseau:
• NFS
• GlusterFS
• Ceph
• Convoy
• RexRay
• PortWorx
• StorageOS
Docker Stacks
• Les piles Docker sont utilisées pour déployer une pile d'applications
complète sur le swarm.
• Docker-compose de qualité production
• Docker-compose est plus adapté aux scénarios de développement et
à un hôte unique
• Utilisent la même syntaxe que le fichier docker-compose, mais avec
une nouvelle section deploy ajoutée au fichier manifeste
• Les piles Docker ignorent les instructions build. Vous ne pouvez pas
créer de nouvelles images à l'aide des commandes de la pile. Il faut
des images pré-construites pour qu'elles fonctionnent.
Docker Stacks
 Docker Stacks
Déployer une stack : docker stack deploy -c <compose.yml>
<nom-de-la-stack>
Lister les stacks : docker stack ls
Lister les processus : docker stack ps <nom-de-la-stack>
Lister les services : docker service ls
Supprimer une stack : docker stack rm <nom-de-la-stack>
Docker Swarm: LoadBalancing
• L'un des principaux avantages de Docker Swarm est d'accroître la disponibilité des applications par le biais de
la redondance.
• L'application est accessible depuis tous les nœuds disponibles du cluster à l'aide de <ip-du-nœud>:<port>.
• Mais comment un utilisateur final accède-t-il à cette application via un point de terminaison commun, c'est-à-
dire un nom DNS ? Cela se fait par le biais d'un équilibrage de charge externe/proxy inverse.
• HAProxy achemine le trafic externe vers le cluster et assure l'équilibrage de charge entre les nœuds
disponibles.
• D'autres équilibrages de charge populaires incluent Nginx et Traefik.
Docker Swarm: HAProxy
LoadBalancing
Docker Swarm: HAProxy
LoadBalancing
Démonstration
• Créer un service de 5 réplicas Flask
• docker service create --replicas 5 -p 80:5000 --name web myusern/sampleflask:v2

• Créer de fausses entrées DNS

• Étant donné que nous n'avons pas de serveur DNS, nous mettrons à jour le fichier /etc/hosts
sur n'importe quelle machine, à l'extérieur ou à l'intérieur du cluster, avec un nom DNS factice
qui pointe vers l'IP du serveur HAProxy. Nous utiliserons ce nom pour accéder à l'application
Flask.

• 3 VM sont utilisées pour le cluster Swarm et 1 VM pour exécuter HAProxy. Ce ne sont

que des considérations de démonstration. Non destiné à la production.