[LINUX] Rollendes Update für Docker Swarm
Einführung
Dieser Artikel beschreibt die fortlaufenden Updates, die mit Docker Swarm erzielt wurden.
Mit Kubernetes können Sie fortlaufende Updates Ihrer Anwendung ohne Ausfallzeiten durchführen.
Während des Betriebs während der Wartung in dem herkömmlichen lokalen System bestand ein Entwurfsmuster darin, einen traurigen Server vorzubereiten, ihn einzeln von der LB zu trennen, ihn zu aktualisieren und ihn nach Abschluss des Updates erneut zu installieren.
In der Cloud-nativen Ära sind die Vorteile fortlaufender Updates groß und werden weiterhin der De-facto-Standard sein. In diesem Artikel wird die Betriebsmethode erläutert, um Ausfallzeiten in der Docker Swarm-Umgebung so weit wie möglich zu reduzieren.
Rollendes Update
In diesem Artikel wird davon ausgegangen, dass Sie mit Docker Swarm eine Clusterumgebung erstellt und die Docker-Registrierung lokal eingerichtet haben.
Informationen zum Erstellen einer Clusterumgebung mit Docker Swarm finden Sie unter Mit Docker Swarm erlerntes Dienstnetz.
Arbeit bauen
Wenn Sie beispielsweise einen Container ohne fortlaufende Aktualisierungen erstellen, müssen Sie den Container stoppen und erneut erstellen, da die Ports dupliziert werden. Daher können Ausfallzeiten von Diensten in einer einzigen Konfiguration nicht vermieden werden.
Es können jedoch zuerst fortlaufende Updates erstellt werden, was bei Anwendungsversionen Zeit sparen kann.
Stellen Sie zunächst die Assets auf dem Server bereit, der die Anwendung aktualisiert.
** Wenn Sie ein fortlaufendes Update durchführen, müssen Sie die Image-Version in der Docker-Compose-Datei ändern. ** **.
Im folgenden Beispiel für einen Docker-Compose-Dateiauszug wird der durch ** image ** angegebene Tag-Name geändert.
- Vor dem Update
version: '3'
networks:
MyApp:
services:
app:
deploy:
replicas: 2
image: 127.0.0.1:5000/stackdemo
- Zum Zeitpunkt der Aktualisierung
version: '3'
networks:
MyApp:
services:
app:
deploy:
replicas: 2
image: 127.0.0.1:5000/stackdemo_v2
Das Ergebnis der Ausführung des Befehls "Docker-Images" vor dem Update ist wie folgt.
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
Führen Sie den folgenden Befehl zum Erstellen aus.
# 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
(Weggelassen)
Successfully built f03dc959d289
Successfully tagged 127.0.0.1:5000/stackdemo_v2:lates
Führen Sie den Befehl "Docker-Images" aus und stellen Sie sicher, dass ein neues Image erstellt wurde.
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
Push zu Ihrer lokalen Docker-Registrierung.
# 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
Bereitstellung nach Dienst
Führen Sie den folgenden Befehl aus, um die Bereitstellung mit dem Befehl "Docker Service Update" durchzuführen. Die in Optionen wie "--update-delay" angegebenen Argumente sind Beispiele.
# 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
Bereitstellung nach Stapel
Führen Sie den folgenden Befehl aus, um mit dem Befehl "Docker Stack" bereitzustellen. Dies entspricht der normalen Stapelbereitstellung.
# docker stack deploy --compose-file docker-compose.yml stackdemo
Anwendungs-Downgrade
Wechseln Sie in das Verzeichnis, in dem sich die ursprünglichen Assets befinden, und stellen Sie sie mit dem Befehl "Docker Service Update" oder "Docker Stack" bereit. Das Folgende ist ein Beispiel für den Befehl "Docker Stack".
# docker stack deploy --compose-file docker-compose.yml stackdemo
Wissen
Basierend auf dem Mindestkonfigurationssystem ist es wünschenswert, dass die Anzahl der ** Replikate **, die in der Datei Docker-compose.yml angegeben sind, vor dem Aktualisieren 2 oder mehr beträgt.
Sie können ein Aktualisierungsintervall festlegen, indem Sie die Option "--update-delay 60s" des Befehls "Docker Service Update" angeben. Der Effekt von downdim kann lokalisiert werden, indem zwei oder mehr Container für einen Server eingestellt werden.
Das folgende Verhalten tritt auf, wenn das fortlaufende Update mit dem Befehl "Docker Service Update" ausgeführt wird. Dieser Artikel besteht aus einem Master und einem Node. Da die Anzahl der in der Datei "docker-compose.yml" angegebenen ** Replikate ** 2 beträgt, werden auf jedem Host zwei Anwendungscontainer erstellt.
Nach dem Ausführen des fortlaufenden Updates wird das Anwendungsupdate für jeden Container gestartet.
stackdemo_app
overall progress: 1 out of 4 tasks
1/4: running [==================================================>]
2/4:
3/4:
4/4:
Die Option "--update-delay 60s" des Befehls "Docker Service Update" bewirkt, dass Anwendungsaktualisierungen in Intervallen von 60 Sekunden erfolgen.
stackdemo_app
overall progress: 2 out of 4 tasks
1/4: running [==================================================>]
2/4: running [==================================================>]
3/4:
4/4:
Beispielsweise gibt die API dieser Anwendung Versionsinformationen als Antwort zurück. Das Folgende ist die Antwort auf den Zugriff auf den DNS-Namen von LB, "{" version ":" 1.0 "}" und "{" version ":" 1.1 "}" werden abwechselnd zurückgegeben, sodass die Anwendung nacheinander aktualisiert wird. Sie können sehen, dass es kaputt ist.
{"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:
Die fortlaufenden Aktualisierungen für alle Container wurden abgeschlossen.
overall progress: 4 out of 4 tasks
1/4: running [==================================================>]
2/4: running [==================================================>]
3/4: running [==================================================>]
4/4: running [==================================================>]
verify: Service converged
Wenn Sie den Befehl docker container ps -a ausführen, können Sie sehen, dass der Container, in dem die alte Anwendung ausgeführt wurde, gestoppt ist und ein Container für die neue Anwendung erstellt wird. Bei der Bewegung zum Zeitpunkt der fortlaufenden Aktualisierung wird zuerst der Container der alten Anwendung gestoppt und ein neuer Container erstellt.
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
Wenn Sie die Anzahl der in der Datei "Docker-compose.yml" angegebenen ** Replikate ** erhöhen, wird die von Docker ausgegebene Protokollausgabe um den Container erhöht.
Der Sinn des Docker Swarm-Designs besteht darin, dass wir Ausfallzeiten, aber keinen Speicher in Betracht gezogen haben. Wenn das Docker-Protokoll nicht mehr über genügend Festplatten verfügt, ist dies überwältigend. In diesem Fall ist es erforderlich, beispielsweise den von Docker verwendeten Festplattenbereich zu trennen.
abschließend
Docker Swarm ist eine Technologie, die in einer Produktionsumgebung verwendet werden kann. Es ist jedoch wünschenswert, die Protokollausgabe von Docker zu berücksichtigen und nach Unterdrückung der Risikoabsicherung zu betreiben, da das Verhalten möglicherweise instabil ist.