[LINUX] Mise à jour continue pour Docker Swarm
introduction
Cet article décrit les mises à jour progressives réalisées avec Docker Swarm.
Kubernetes vous permet d'effectuer des mises à jour progressives de votre application sans mises à jour de temps d'arrêt.
Dans l'opération pendant la maintenance dans le système sur site conventionnel, un modèle de conception consistait à préparer un serveur désolé, à le séparer un par un du LB, à le mettre à jour, puis à l'installer à nouveau une fois la mise à jour terminée.
À l'ère du cloud natif, les avantages des mises à jour progressives sont considérables et continueront d'être la norme de facto. Dans cet article, nous expliquerons la méthode de fonctionnement pour réduire autant que possible les temps d'arrêt dans l'environnement Docker Swarm.
Mise à jour continue
Cet article suppose que vous avez créé un environnement de cluster avec Docker Swarm et configuré le registre Docker localement.
Pour plus d'informations sur la création d'un environnement de cluster avec Docker Swarm, consultez Service mesh appris avec Docker Swarm.
Construire le travail
Par exemple, si vous créez un conteneur sans mises à jour propagées, vous devrez arrêter le conteneur et le reconstruire car les ports seront dupliqués. Par conséquent, les temps d'arrêt du service ne peuvent pas être évités dans une seule configuration.
Cependant, les mises à jour progressives peuvent être créées en premier, ce qui peut gagner du temps avec les versions d'application.
Tout d'abord, déployez les actifs sur le serveur qui met à jour l'application.
** Le point lors d'une mise à jour progressive est de changer la version de l'image dans le fichier Docker-compose. ** **
Dans l'exemple d'extrait de fichier Docker-compose suivant, le nom de balise spécifié par ** image ** est modifié.
--Avant la mise à jour
version: '3'
networks:
MyApp:
services:
app:
deploy:
replicas: 2
image: 127.0.0.1:5000/stackdemo
- Au moment de la mise à jour
version: '3'
networks:
MyApp:
services:
app:
deploy:
replicas: 2
image: 127.0.0.1:5000/stackdemo_v2
Le résultat de l'exécution de la commande docker images avant la mise à jour est le suivant.
REPOSITORY TAG IMAGE ID CREATED SIZE
127.0.0.1:5000/stackdemo latest 1f25d780708a 4 minutes ago 878MB
redis latest 4cdbec704e47 2 weeks ago 98.2MB
registry <none> 708bc6af7e5e 2 months ago 25.8MB
node 12.2-alpine f391dabf9dce 11 months ago 77.7MB
Exécutez la commande suivante pour générer.
# docker-compose build
WARNING: Some services (app, redis) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
redis uses an image, skipping
Building app
Step 1/10 : FROM node:12.2-alpine
---> f391dabf9dce
(Omis)
Successfully built f03dc959d289
Successfully tagged 127.0.0.1:5000/stackdemo_v2:lates
Exécutez la commande docker images et vérifiez qu'une nouvelle image a été créée.
REPOSITORY TAG IMAGE ID CREATED SIZE
127.0.0.1:5000/stackdemo_v2 latest f03dc959d289 3 minutes ago 879MB
127.0.0.1:5000/stackdemo latest 1f25d780708a 10 minutes ago 878MB
redis latest 4cdbec704e47 2 weeks ago 98.2MB
registry <none> 708bc6af7e5e 2 months ago 25.8MB
node 12.2-alpine f391dabf9dce 11 months ago 77.7MB
Poussez vers votre registre Docker local.
# docker-compose push
WARNING: Some services (app, redis) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.
Pushing app (127.0.0.1:5000/stackdemo_v2:latest)...
The push refers to repository [127.0.0.1:5000/stackdemo_v2]
6b65a73c07f0: Pushed
647209689cbb: Pushed
a5bda7b4ef65: Pushed
80f6c9bc1a2c: Pushed
76e5dca151d7: Mounted from stackdemo
917da41f96aa: Mounted from stackdemo
7d6e2801765d: Mounted from stackdemo
f1b5933fe4b5: Mounted from stackdemo
latest: digest: sha256:84ee56656dc9a9e87d4058bba2c98ebdd3615629258f13c4ac81ff56def69b11 size: 2002
Déployer par service
Pour déployer avec la commande docker service update, exécutez la commande suivante. Les arguments spécifiés par des options telles que --update-delay sont des exemples.
# docker service update --update-delay 5s --update-parallelism 1 --image 127.0.0.1:5000/stackdemo_v2 stackdemo_app
overall progress: 2 out of 2 tasks
1/2: running [==================================================>]
2/2: running [==================================================>]
verify: Service converged
Déployer par pile
Pour déployer avec la commande docker stack, exécutez la commande suivante. C'est le même que le déploiement normal de la pile.
# docker stack deploy --compose-file docker-compose.yml stackdemo
Rétrogradation de l'application
Accédez au répertoire où se trouvent les actifs d'origine et déployez-les avec la commande docker service update ou docker stack. Voici un exemple de la commande docker stack.
# docker stack deploy --compose-file docker-compose.yml stackdemo
connaissance
Sur la base du système de configuration minimum, il est souhaitable que le nombre de ** répliques ** spécifié dans le fichier Docker-compose.yml avant la mise à jour soit de 2 ou plus.
Vous pouvez définir un intervalle de mise à jour en spécifiant l'option --update-delay 60s de la commande docker service update. L'effet de downdim peut être localisé en définissant deux conteneurs ou plus pour qu'ils fonctionnent pour un serveur.
Voici le comportement lors de l'exécution de la mise à jour progressive avec la commande docker service update.
Cet article se compose d'un maître et d'un nœud. Puisque le nombre de ** répliques ** spécifié dans le fichier docker-compose.yml est de 2, deux conteneurs d'application seront créés sur chaque hôte.
Après avoir exécuté la mise à jour progressive, la mise à jour de l'application démarre pour chaque conteneur.
stackdemo_app
overall progress: 1 out of 4 tasks
1/4: running [==================================================>]
2/4:
3/4:
4/4:
L'option --update-delay 60s de la commande docker service update provoque les mises à jour de l'application à intervalles de 60 secondes.
stackdemo_app
overall progress: 2 out of 4 tasks
1/4: running [==================================================>]
2/4: running [==================================================>]
3/4:
4/4:
À titre d'exemple, l'API de cette application renvoie des informations de version en tant que réponse. Voici la réponse pour accéder au nom DNS de LB, {" version ":" 1.0 "} et {" version ":" 1.1 "} sont renvoyés en alternance, de sorte que l'application est mise à jour séquentiellement. Vous pouvez voir qu'il a été cassé.
{"version":"1.0"}
{"version":"1.1"}
{"version":"1.0"}
{"version":"1.1"}
{"version":"1.0"}
{"version":"1.1"}
overall progress: 3 out of 4 tasks
1/4: running [==================================================>]
2/4: running [==================================================>]
3/4: running [==================================================>]
4/4:
Les mises à jour progressives pour tous les conteneurs sont terminées.
overall progress: 4 out of 4 tasks
1/4: running [==================================================>]
2/4: running [==================================================>]
3/4: running [==================================================>]
4/4: running [==================================================>]
verify: Service converged
Si vous exécutez la commande docker container ps -a, vous pouvez voir que le conteneur dans lequel l'ancienne application était en cours d'exécution est arrêté et un conteneur pour la nouvelle application est en cours de création. En ce qui concerne le mouvement au moment de la mise à jour progressive, le conteneur de l'ancienne application est arrêté en premier et un nouveau conteneur est créé.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
52db94935164 127.0.0.1:5000/stackdemo_v2:latest "/bin/sh -c 'yarn st…" 38 minutes ago Up 38 minutes 3001/tcp stackdemo_app.4.j5vgh0f7azp88zal6rd7gveny
8ea68352da6c 127.0.0.1:5000/stackdemo_v2:latest "/bin/sh -c 'yarn st…" 41 minutes ago Up 41 minutes 3001/tcp stackdemo_app.2.zc2pzhd2xkbc8obvc4apvg7qh
4733dd99b9f4 127.0.0.1:5000/stackdemo:latest "/bin/sh -c 'yarn st…" 43 minutes ago Exited (1) 41 minutes ago stackdemo_app.2.s0lq2qx6zkj5v51mdnfrl4ygr
fee3bf216379 127.0.0.1:5000/stackdemo:latest "/bin/sh -c 'yarn st…" 43 minutes ago Exited (1) 38 minutes ago stackdemo_app.4.uymqss60i5ac4ozxa05xfgaw4
4ef0610778f0 redis:latest "docker-entrypoint.s…" 43 minutes ago Up 43 minutes 6379/tcp stackdemo_redis.2.ls88b5nb1h5qeo0todl6lc7dn
867d0cadeeea registry:2 "/entrypoint.sh /etc…" About an hour ago Up About an hour 5000/tcp registry.1.wspi67ubshjo47af8b55kvz10
Si vous augmentez le nombre de ** réplicas ** spécifiés dans le fichier Docker-compose.yml, la sortie du journal par Docker sera augmentée par le conteneur.
Le but de la conception de Docker Swarm est que nous avons considéré les temps d'arrêt mais pas le stockage, donc si le journal Docker manque de disque, ce sera écrasant. Dans ce cas, il est nécessaire de concevoir comme séparer la zone de disque utilisée par Docker.
en conclusion
Docker Swarm est une technologie qui peut être utilisée dans un environnement de production, mais il est souhaitable de prendre en compte la sortie du journal par Docker et de la faire fonctionner après avoir supprimé la couverture des risques car le comportement peut être instable.