Dans cet article, vous allez créer un cluster avec Docker Swarm et découvrir les maillages de service.
L'environnement utilise ELB (Elastic Load Balancing) d'AWS et deux instances EC2 (Amazon EC2) pour créer un cluster Docker Swarm.
L'avantage du déploiement de Docker Swarm par rapport à Kubernetes est son faible coût de déploiement. Docker Swarm a moins d'obstacles que Kubernetes, donc je pense qu'il est idéal pour les systèmes qui essaient de mettre en production la technologie des conteneurs.
** Découvrez l'importance du maillage de service via Docker Swarm. ** **
Docker Swarm Docker Swarm est un outil d'orchestration fourni par Docker. Avec Docker Swarm, vous pouvez regrouper plusieurs hôtes et déployer et faire évoluer facilement vos conteneurs.
Docker Swarm se compose de gestionnaires et de nœuds, où ** Swarm ** signifie swarm. Pour créer un cluster Docker Swar, vous devez effectuer les opérations suivantes:
--Règles autorisées par le pare-feu
numéro de port | Utilisation |
---|---|
2377/tcp | Communication pour la gestion des clusters |
4789/udp | Réseau de superposition |
7946/tcp | Communication inter-nœuds |
7946/udp | Communication inter-nœuds |
Le maillage de services présuppose une architecture de microservices et fournit un mécanisme pour contrôler la communication entre les applications. Cette communication contrôlée est tissée comme un maillage, ce qui améliore la fiabilité.
Par exemple, dans le cas d'un hôte à deux unités, le chemin d'accès normal est le suivant.
Lorsque le nom DNS de l'équilibreur de charge est accessible avec un navigateur, l'équilibreur de charge qui reçoit la requête HTTP distribue la requête HTTP sur le port public de l'hôte qui est le back-end en round robin.
Par exemple, même si l'un des hôtes échoue et que le conteneur tombe en panne, le service peut être poursuivi par l'itinéraire suivant.
En résumé, si vous avez simplement une configuration où les applications sont séparées au niveau de l'hôte, vous ne pourrez pas fournir de services si l'un des hôtes échoue. Par conséquent, il est possible d'éliminer un seul obstacle en utilisant la technologie des conteneurs et en en faisant un maillage de service.
Cette section décrit la procédure de création de Docker Swarm. Pour créer Docker Swarm, travaillez dans l'ordre du gestionnaire et du nœud.
Dans l'exemple de cet article, web1 est le gestionnaire et web2 est le nœud, et nous déployons à l'aide de l'image Nginx.
Comme condition préalable, Docker est déjà installé et le pare-feu décrit ci-dessus est également autorisé. De plus, puisque cet article utilise la configuration minimale, il y aura un gestionnaire et un nœud.
Tout d'abord, initialisez Docker Swarm. ** Le mode Swarm ** est activé en exécutant la commande docker swarm init
.
Si vous avez plusieurs adresses IP, spécifiez l'adresse IP de l'interface utilisée pour la communication avec les autres nœuds dans l'argument de ʻadvertise-addr`.
--Initialisation de Docker Swarm
# docker swarm init --advertise-addr <adresse IP>
Swarm initialized: current node (zirc78nsch77ox8di6021ux4n) is now a manager.
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-459p0pkyqgxgkhaggjhavd419ldujenqttm1mqmwup0qz9m5qv-1kj3jy6ozwrr2fkj1qvas294a <Adresse IP du responsable>:2377
To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
Après avoir exécuté la commande, notez le résultat de sortie docker swarm join --token SWMTKN-1- (abréviation) <adresse IP du gestionnaire>: 2377
.
# docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce
Pour les managers, ** Leader ** est envoyé vers MANAGER STATUS.
--Vérification du réseau
# docker network ls
NETWORK ID NAME DRIVER SCOPE
53703efd3d07 bridge bridge local
aacf6f5e0eb4 docker_gwbridge bridge local
1f0d0e4ae3e7 host host local
xip5tlqmokpb ingress overlay swarm
2d36f1c8c80f none null local
Lorsque Swarm est initialisé, deux nouveaux réseaux (docker_gwbridge, ingress) seront créés.
Ensuite, pour joindre le nœud au cluster Docker Swarm, exécutez la commande suivante du côté nœud.
La valeur utilisée comme argument de --token
est un exemple. Vous pouvez copier et coller la sortie de la commande docker swarm init
ci-dessus.
Vous pouvez également réafficher le jeton en exécutant la commande docker swarm join-token worker
côté gestionnaire.
# docker swarm join --token SWMTKN-1- (Omis) <Adresse IP du gestionnaire>: 2377
This node joined a swarm as a worker.
Pour confirmation côté gestionnaire, exécutez à nouveau la commande docker node ls
pour confirmer que le nœud est reconnu.
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce
n2o22ptdmyhan8qg0ijmo0qn5 web2 Ready Active 18.09.9-ce
Dans cet article, nous allons déployer avec docker-commpose, qui est facile à gérer.
Vous pouvez également déployer avec la commande docker service create
. Je vais omettre l'explication du service et de la pile.
Le travail de déploiement se fait côté manager.
Déplacez-vous vers n'importe quel répertoire et créez le fichier docker-commpose.yml
suivant.
version: "3"
services:
web:
image: nginx
deploy:
replicas: 2
#resources:
# limits:
# cpus: "0.1"
# memory: 100M
restart_policy:
condition: on-failure
ports:
- "80:80"
networks:
- webnet
networks:
webnet:
Après avoir créé le fichier docker-commpose.yml
, exécutez la commande suivante pour le déployer.
test
est un exemple, alors spécifiez n'importe quel nom.
# docker stack deploy -c docker-commpose.yml test
Updating service test_web (id: egubeieuri00rzmm9imsna93o)
Après le déploiement, vous pouvez vérifier l'état du service avec la commande suivante. Puisque ** REPLICAS ** vaut 2, deux conteneurs sont en cours d'exécution.
# docker service ls
ID NAME MODE REPLICAS IMAGE PORTS
r04mfg1se3nh test_web replicated 2/2 nginx:latest *:80->80/tcp
Si vous exécutez la commande docker container ps -a
côté gestionnaire et côté nœud, vous pouvez voir que le conteneur est en cours d'exécution.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4a26c3ca6df7 nginx:latest "nginx -g 'daemon of…" 3 seconds ago Up 2 seconds 80/tcp test_web.1.mnnz40tdykzd2intwz5hf68bs
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
614c19349bf0 nginx:latest "nginx -g 'daemon of…" 2 minutes ago Up 2 minutes 80/tcp test_web.2.6om5oazbavassohd4akucbum2
Vérifiez le fonctionnement de Docker Swarm.
Accédez au nom DNS de l'équilibreur de charge depuis votre navigateur et vérifiez que la charge est répartie normalement.
--Accédez au nom DNS de l'équilibreur de charge
Si vous vérifiez le journal du conteneur, vous pouvez voir que la charge est distribuée par round robin.
Vérifiez le ** CONTAINER ID ** avec la commande docker container ps -a
.
# docker logs -f <CONTAINER ID>
10.255.0.3 - - [06/Feb/2020:14:20:51 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" "<IP globale de la source d'accès>"
À titre de test, arrêtez le conteneur en cours d'exécution sur web2 (côté nœud).
# docker stop <CONTAINER ID>
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
423f673b0513 nginx:latest "nginx -g 'daemon of…" 19 hours ago Exited (0) 5 seconds ago test_web.2.kc7yypyasgvjtolsb1zwmhjoy
Pour le moment, le conteneur ne s'exécute pas sur web2. Assurez-vous que vous pouvez accéder au nom DNS de l'équilibreur de charge.
A titre d'exemple, accédez à l'adresse IP publique de web2 arrêtée depuis le navigateur.
Vous pouvez vérifier l'accès à l'adresse IP publique du web2 arrêté (nœud) dans le journal d'accès du conteneur sur Web1 (gestionnaire).
10.255.0.3 - - [07/Feb/2020:02:19:01 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" "-"
Vous pouvez accéder au conteneur à partir du site Web2 arrêté (côté nœud) local en exécutant la commande suivante.
# curl localhost 80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
curl: (7) Couldn't connect to server
Dans le journal de web1 (gestionnaire), il est affiché comme suit.
10.255.0.2 - - [07/Feb/2020:02:41:47 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"
Si vous videz le port 4789 dans web1 (gestionnaire) et le regardez, vous pouvez voir la communication du réseau de superposition.
# tcpdump -nli eth0 port 4789 -Av
Vous pouvez mettre à l'échelle en exécutant la commande suivante alors que le service est déjà en cours d'exécution. La commande suivante modifie le nombre de conteneurs à 4 conteneurs.
# docker service scale test_web=4
test_web scaled to 4
overall progress: 4 out of 4 tasks
1/4: running [==================================================>]
2/4: running [==================================================>]
3/4: running [==================================================>]
4/4: running [==================================================>]
verify: Service converged
Après la mise à l'échelle, exécutez la commande docker container ps -a
et vous verrez que le nombre de conteneurs augmente.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
41962946aa48 nginx:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 80/tcp test_web.4.pytl36ejcd81ybthisxfo47br
423f673b0513 nginx:latest "nginx -g 'daemon of…" 7 hours ago Up 7 hours 80/tcp test_web.2.kc7yypyasgvjtolsb1zwmhjoy
** Lors du déploiement, il n'est pas nécessaire de remplacer les ressources d'application pour chaque serveur, juste un gestionnaire. ** **
Docker Swarm est égal.
Plus précisément, Docker Swarm gère un nombre spécifié de répliques, donc si l'un des hôtes en cluster tombe en panne, le conteneur sera démarré sur cet hôte.
Voici la sortie de la commande docker container ps -a
.
Par exemple, web1 et web2 ont des conteneurs en cours d'exécution respectivement.
e5ccbfa9739b nginx:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 80/tcp test_web.1.mrgkhbd7juer72v6bv0l42fxq
4820c7bbe9c1 nginx:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 80/tcp test_web.2.wfe1n11s8940rdl8r1c47o6nc
L'hôte web2 s'est arrêté. Lorsqu'il détecte que web2 est en panne, il crée un conteneur sur web1.
0a88f53039a3 nginx:latest "nginx -g 'daemon of…" 5 seconds ago Created test_web.2.p06zas3c3kt9ekjojhhfnl3co
e5ccbfa9739b nginx:latest "nginx -g 'daemon of…" 4 minutes ago Up 4 minutes 80/tcp test_web.1.mrgkhbd7juer72v6bv0l42fxq
Deux conteneurs s'exécutent sur web1.
0a88f53039a3 nginx:latest "nginx -g 'daemon of…" 37 seconds ago Up 31 seconds 80/tcp test_web.2.p06zas3c3kt9ekjojhhfnl3co
e5ccbfa9739b nginx:latest "nginx -g 'daemon of…" 5 minutes ago Up 5 minutes 80/tcp test_web.1.mrgkhbd7juer72v6bv0l42fxq
Décrit comment annuler Docker Swarm.
Tout d'abord, exécutez la commande suivante côté gestionnaire pour supprimer le service.
# docker service rm test_web
test_web
Ensuite, travaillez sur le nœud, puis sur le gestionnaire.
# docker swarm leave
Node left the swarm.
Confirmez que l'état du nœud est ** DOWN **.
# docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce
n2o22ptdmyhan8qg0ijmo0qn5 web2 Down Active 18.09.9-ce
Supprimez le nœud. Spécifiez le nom du nœud dans l'argument facultatif.
# docker node rm --force web2
web2
Confirmez que le nœud n'est plus reconnu par le gestionnaire.
# docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION
zirc78nsch77ox8di6021ux4n * web1 Ready Active Leader 18.09.9-ce
Enfin, déconnectez le gestionnaire lui-même.
# docker swarm leave --force
Node left the swarm.
Si vous n'utilisez pas Docker Swarm, procédez comme suit du côté du gestionnaire:
Assurez-vous que le nœud n'existe pas.
# docker node ls
Error response from daemon: This node is not a swarm manager. Use "docker swarm init" or "docker swarm join" to connect this node to swarm and try again.
Confirmez que le réseau créé par Docker Swarm a été supprimé. Le réseau docker_gwbridge demeure.
# docker network ls
NETWORK ID NAME DRIVER SCOPE
987cfc73d87c bridge bridge local
aacf6f5e0eb4 docker_gwbridge bridge local
1f0d0e4ae3e7 host host local
2d36f1c8c80f none null local
Exécutez la commande suivante pour supprimer toutes les ressources inutilisées.
# docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N] y
Deleted Networks:
docker_gwbridge
Deleted Images:
untagged: nginx@sha256:ad5552c786f128e389a0263104ae39f3d3c7895579d45ae716f528185b36bc6f
deleted: sha256:2073e0bcb60ee98548d313ead5eacbfe16d9054f8800a32bedd859922a99a6e1
deleted: sha256:a3136fbf38691346715cac8360bcdfca0fff812cede416469653670f04e2cab0
deleted: sha256:99360ffcb2da18fd9ede194efaf5d4b90e7aee99f45737e918113e6833dcf278
deleted: sha256:488dfecc21b1bc607e09368d2791cb784cf8c4ec5c05d2952b045b3e0f8cc01e
untagged: nginx@sha256:70821e443be75ea38bdf52a974fd2271babd5875b2b1964f05025981c75a6717
deleted: sha256:5ad3bd0e67a9c542210a21a3c72f56ef6387cf9b7f4c2506d2398d55a2593ed0
deleted: sha256:b69e2ed46519bc33e7c887967e4f61a2ee53aef165b70f75e208937fb42e7b4c
deleted: sha256:4cb7f732537bf0f65cd9f8f7b63bbe71abcf9d0df396f58621ef3be0b2487b27
deleted: sha256:556c5fb0d91b726083a8ce42e2faaed99f11bc68d3f70e2c7bbce87e7e0b3e10
Total reclaimed space: 253.4MB
Lors de l'utilisation de Docker Swarm, la version qui peut être utilisée avec docker-commpose est ** 3 **.
Une image est requise lors de la construction (empilement) avec docker-commpose.
À partir de la référence du fichier Compose version 3
Remarque: (Version 3) Cette option est ignorée lors du déploiement de la pile en mode Swarm à l'aide du fichier Compose. Cette commande docker stack n'accepte que les images prédéfinies.
Par conséquent, l'environnement du ** registre Docker ** est requis.
Pour plus d'informations sur la configuration locale du registre Docker, reportez-vous à l'URL officielle ci-dessous.
À titre d'exemple, si vous spécifiez la génération et exécutez le déploiement comme indiqué ci-dessous,
version: '3'
services:
app:
build: ./src
Le message d'erreur suivant s'affiche et il n'est pas possible de déployer.
failed to create service stackdemo_backend: Error response from daemon: rpc error: code = InvalidArgument desc = ContainerSpec: image reference must be provided
Par exemple, si vous déployez sur deux hôtes avec la valeur ** replicas ** dans le fichier docker-commpose.yml définie sur 2, il est essentiellement distribué dans un conteneur pour un hôte.
Si deux conteneurs sont démarrés sur un hôte pendant le déploiement, il est possible qu'une erreur se soit produite et que les conteneurs n'aient pas pu être démarrés sur un hôte. Pour Linux, l'erreur peut être confirmée à partir du journal syslog.
Le résultat de la vérification avec la configuration de cet article (1 Master et 1 Node) est décrit à titre de rappel.
En termes simples, un maître et un nœud ne peuvent pas réaliser une véritable redondance.
Pour améliorer encore la fiabilité, il est nécessaire de faire une redondance avec deux maîtres. Il existe une description officielle de la redondance principale.
** Comportement lorsqu'un conteneur est arrêté ou supprimé dans la configuration de cet article (1 Master et 1 Node) **
Si vous arrêtez ou supprimez l'un des conteneurs Master et Node, il se régénérera automatiquement jusqu'à ce qu'il atteigne le nombre défini dans ** replicas ** dans le fichier docker-compose.yml
. Vous pouvez également accéder à l'adresse IP publique via le maillage de services pendant cette interruption momentanée. Cependant, s'il est local, une interruption momentanée se produira.
** Comportement lorsque l'hôte Node lui-même est arrêté dans la configuration de cet article (1 Master et 1 Node) **
Les conteneurs exécutés sur Node seront créés du côté maître jusqu'à ce que le nombre défini dans ** répliques ** du fichier docker-compose.yml
soit atteint. (Le mouvement est similaire à Vmotion de Vmware, mais la réalité est différente.)
Après cela, même si Node est démarré, le conteneur exécuté sur Node ne sera pas automatiquement restauré, une action manuelle est donc requise. En passant, si vous arrêtez ou supprimez le conteneur créé précédemment dans Master, le conteneur sera de nouveau créé du côté Node.
** Comportement lorsque l'hôte maître lui-même est arrêté dans la configuration de cet article (1 maître et 1 nœud) ** Master of Docker Swarm est arrêté, mais il peut être poursuivi en tant qu'application car il est accessible par le service mesh.
Les outils d'orchestration sont une technologie essentielle pour le développement d'applications modernes, où l'incertitude et des changements rapides sont nécessaires.
En tant qu'application, la technologie sans serveur peut être utilisée pour définir des seuils pour les ressources CPU et mémoire, et lorsque les seuils sont dépassés, le serveur peut être mis à l'échelle.
Recommended Posts