În acest articol, vom organiza , , și implementarea fără întreruperi a aplicației web. — este o tehnică care permite actualizarea instantanee a aplicației, fără a respinge nicio solicitare. Este una dintre strategiile zero downtime deployment și se potrivește cel mai bine aplicațiilor cu o singură instanță, dar cu posibilitatea de a încărca o a doua instanță, pregătită pentru utilizare.
Să presupunem că aveți o aplicație web cu care lucrează activ mulți clienți și nu poate fi oprită pentru câteva secunde. Dar aveți nevoie urgentă să implementați o actualizare a bibliotecii, o corecție de bug sau o nouă funcționalitate interesantă. În situația obișnuită, ar fi necesar să opriți aplicația, să o înlocuiți și apoi să o reporniți. În cazul Docker, puteți să înlocuiți întâi, apoi să reporniți, dar tot va exista o perioadă în care solicitările către aplicație nu vor fi procesate, deoarece, de obicei, aplicația necesită ceva timp pentru încărcarea inițială. Și dacă se va porni, dar se va dovedi a fi nefuncțională? Haideți să abordăm această problemă folosind cele mai simple și elegante metode.
DISCLAIMER: Cea mai mare parte a articolului este prezentată într-un format experimental — sub forma unei sesiuni de consolă. Sper că nu va fi prea greu de înțeles și că acest cod se documentează singur într-o măsură suficientă. Pentru a crea atmosfera, imaginați-vă că acestea nu sunt doar snippeturi de cod, ci hârtie dintr-un "teletip" metalic.
Tehnici interesante, care sunt greu de găsit doar citind codul, sunt descrise la începutul fiecărui capitol. Dacă nu înțelegeți ceva încă — căutați pe Google și verificați în (de bine, funcționează din nou, având în vedere deblocarea Telegramului). Ceea ce nu poate fi găsit pe Google — întrebați în comentarii. Voi completa cu plăcere secțiunea corespunzătoare „Tehnici interesante”.
Să începem.
$ mkdir blue-green-deployment && cd $_Serviciu
Vom crea un serviciu de testare și îl vom plasa într-un container.
Tehnici interesante
cat < file-name( + ) — o metodă de a crea un fișier multi-linie cu o singură comandă. Tot ce bash va citi din/dev/stdindupă această linie și până la liniaEOFva fi scris înfile-name.wget -qO- URL() — pentru a afișa documentul obținut prin HTTP în/dev/stdout(analogcurl URL).
Printare
Am rupt fragmentele intenționat pentru a include evidențierea pentru Python. La sfârșit va fi încă o bucată de acest fel. Considerați că în aceste locuri hârtia a fost tăiată pentru a fi trimisă la departamentul de evidențiere (unde codul a fost colorat manual cu markere), iar apoi aceste bucăți au fost lipite înapoi.
$ cat < uptimer.pyde la http.server import BaseHTTPRequestHandler, HTTPServer
din time import monotonic
versiunea_aplicației = 1
numele_aplicației = f'Uptimer v{versiunea_aplicației}.0'
timp_de_așteptare = 15 - versiunea_aplicației * 5
clasa Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path == '':
try:
t = monotonic() - server_start
if t < timp_de_așteptare:
self.send_error(503)
else:
self.send_response(200)
self.send_header('Content-Type', 'text/html')
self.end_headers()
răspuns = f'<h2>{numele_aplicației} rulează de {t:3.1f} secunde.</h2>n'
self.wfile.write(răspuns.encode('utf-8'))
except Exception:
self.send_error(500)
else:
self.send_error(404)
httpd = HTTPServer(('', 8080), Handler)
server_start = monotonic()
print(f'{numele_aplicației} (se încarcă în {timp_de_așteptare} sec.) a început.')
httpd.serve_forever()EOF
$ cat << EOF > Dockerfile
FROM python:alpine
EXPOSE 8080
COPY uptimer.py app.py
CMD [ "python", "-u", ".\/app.py" ]
EOF
$ docker build --tag uptimer .
Sending build context to Docker daemon 39.42kB
Step 1\/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2\/4 : EXPOSE 8080
---> Using cache
---> cf92d174c9d3
Step 3\/4 : COPY uptimer.py app.py
---> a7fbb33d6b7e
Step 4\/4 : CMD [ "python", "-u", ".\/app.py" ]
---> Running in 1906b4bd9fdf
Removing intermediate container 1906b4bd9fdf
---> c1655b996fe8
Successfully built c1655b996fe8
Successfully tagged uptimer:latest
$ docker run --rm --detach --name uptimer --publish 8080:8080 uptimer
8f88c944b8bf78974a5727070a94c76aa0b9bb2b3ecf6324b784e782614b2fbf
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8f88c944b8bf uptimer "python -u .\/app.py" 3 seconds ago Up 5 seconds 0.0.0.0:8080->8080\/tcp uptimer
$ docker logs uptimer
Uptimer v1.0 (se încarcă în 10 sec.) a fost pornit.
$ wget -qSO- http:\/\/localhost:8080
HTTP\/1.0 503 Serviciu indisponibil
Server: BaseHTTP\/0.6 Python\/3.8.3
Data: Sat, 22 Aug 2020 19:52:40 GMT
Conexiune: close
Content-Type: text\/html;charset=utf-8
Content-Length: 484
$ wget -qSO- http:\/\/localhost:8080
HTTP\/1.0 200 OK
Server: BaseHTTP\/0.6 Python\/3.8.3
Data: Sat, 22 Aug 2020 19:52:45 GMT
Content-Type: text\/html
<h2>Uptimer v1.0 rulează de 15.4 secunde.</h2>
$ docker rm --force uptimer
uptimerReverse proxy
Pentru ca aplicația noastră să aibă capacitatea de a se schimba discret, este necesar să existe o altă entitate în fața sa care să ascundă înlocuirea acesteia. Acesta poate fi un server web în . Reverse proxy este plasat între client și aplicație. El primește cererile de la clienți și le redirecționează către aplicație, în timp ce răspunsurile aplicației sunt direcționate către clienți.
Aplicația și reverse proxy pot fi conectate în interiorul Docker-ului folosind . Astfel, containerului cu aplicația nu trebuie să-i fie expus portul în sistemul gazdă, ceea ce permite izolarea maximă a aplicației de amenințările externe.
Dacă reverse proxy își va desfășura activitatea pe un alt gazdă, va trebui să renunțăm la docker network și să conectăm aplicația cu reverse proxy prin rețeaua gazdă, expunând portul myapp parametrul --publish, ca la prima rulare și ca pentru reverse proxy.
Reverse proxy va fi lansat pe portul 80, deoarece aceasta este entitatea care ar trebui să asculte de exterior. Dacă portul 80 este ocupat pe gazda dvs. de test, schimbați parametrul --publish 80:80 pe --publish ANY_FREE_PORT:80.
Tehnici interesante
- „În rețelele Docker create de utilizator, containerele pot fi conectate nu doar prin adresa IP. Numele containerului este, de asemenea, rezolvat în adresa sa IP” (, punctul 5 din codul Docker).
Printare
$ docker network create web-gateway
5dba128fb3b255b02ac012ded1906b7b4970b728fb7db3dbbeccc9a77a5dd7bd
$ docker run --detach --rm --name uptimer --network web-gateway uptimer
a1105f1b583dead9415e99864718cc807cc1db1c763870f40ea38bc026e2d67f
$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer:8080
<h2>Uptimer v1.0 rulează de 11,5 secunde.</h2>
$ docker run --detach --publish 80:80 --network web-gateway --name reverse-proxy nginx:alpine
80695a822c19051260c66bf60605dcb4ea66802c754037704968bc42527bf120
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
80695a822c19 nginx:alpine "\/docker-entrypoint.…" acum 27 secunde Up 25 secunde 0.0.0.0:80->80\/tcp reverse-proxy
a1105f1b583d uptimer "python -u .\/app.py" acum aproximativ un minut Up aproximativ un minut 8080\/tcp uptimer
$ cat << EOF > uptimer.conf
server {
listen 80;
location \/ {
proxy_pass http:\/\/uptimer:8080;
}
}
EOF
$ docker cp .\/uptimer.conf reverse-proxy:\/etc\/nginx\/conf.d\/default.conf
$ docker exec reverse-proxy nginx -s reload
2020\/06\/23 20:51:03 [notice] 31#31: signal process started
$ wget -qSO- http:\/\/localhost
HTTP\/1.1 200 OK
Server: nginx\/1.19.0
Date: Sat, 22 Aug 2020 19:56:24 GMT
Content-Type: text\/html
Transfer-Encoding: chunked
Connection: keep-alive
<h2>Uptimer v1.0 rulează de 104,1 secunde.</h2>Dezvoltare fără întreruperi
Vom lansa o nouă versiune a aplicației (cu un boost dublu al performanței la startup) și vom încerca să o desfășurăm fără întreruperi.
Tehnici interesante
echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt'— Scrie textulmy textîn fișier/my-file.txtîn interiorul containeruluimy-container.cat > /my-file.txt— Scrie în fișier conținutul din stdin/dev/stdin.
Printare
$ sed -i "s/app_version = 1/app_version = 2/" uptimer.py
$ docker build --tag uptimer .
Trimiterea contextului de construire către daemonul Docker 39.94kB
Pasul 1/4 : FROM python:alpine
---> 8ecf5a48c789
Pasul 2/4 : EXPOSE 8080
---> Folosind cache
---> cf92d174c9d3
Pasul 3/4 : COPY uptimer.py app.py
---> 3eca6a51cb2d
Pasul 4/4 : CMD [ "python", "-u", ".\/app.py" ]
---> Se execută în 8f13c6d3d9e7
Se îndepărtează containerul intermediar 8f13c6d3d9e7
---> 1d56897841ec
Construire reușită 1d56897841ec
Etichetare reușită uptimer:latest
$ docker run --detach --rm --name uptimer_BLUE --network web-gateway uptimer
96932d4ca97a25b1b42d1b5f0ede993b43f95fac3c064262c5c527e16c119e02
$ docker logs uptimer_BLUE
Uptimer v2.0 (se încarcă în 5 sec.) a început.
$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer_BLUE:8080
<h2>Uptimer v2.0 rulează de 23.9 secunde.</h2>
$ sed s/uptimer/uptimer_BLUE/ uptimer.conf | docker exec --interactive reverse-proxy sh -c 'cat > /etc/nginx/conf.d/default.conf'
$ docker exec reverse-proxy cat /etc/nginx/conf.d/default.conf
server {
listen 80;
location / {
proxy_pass http://uptimer_BLUE:8080;
}
}
$ docker exec reverse-proxy nginx -s reload
2020/06/25 21:22:23 [notice] 68#68: procesul semnal a început
$ wget -qO- http://localhost
<h2>Uptimer v2.0 rulează de 63.4 secunde.</h2>
$ docker rm -f uptimer
uptimer
$ wget -qO- http://localhost
<h2>Uptimer v2.0 rulează de 84.8 secunde.</h2>
$ docker ps
ID CONTAINER IMAGINE COMANDĂ CREAT STATUS PORTURI NUME
96932d4ca97a uptimer "python -u .\/app.py" Acum aproximativ un minut Activ timp de aproximativ un minut 8080/tcp uptimer_BLUE
80695a822c19 nginx:alpine "\/docker-entrypoint.…" acum 8 minute Activ timp de 8 minute 0.0.0.0:80->80/tcp reverse-proxyÎn această etapă, imaginea este construită direct pe server, ceea ce necesită prezența surselor aplicației acolo și, de asemenea, încarcă serverul cu muncă suplimentară. Pasul următor va fi atribuirea construirii imaginii pe o mașină separată (de exemplu, într-un sistem CI) cu transferul ulterioară pe server.
Transfer de imagini
Din păcate, transferul imaginilor de pe localhost pe localhost nu are sens, așa că această secțiune poate fi explorată numai având la dispoziție două gazde cu Docker. Pe scurt, arată cam așa:
$ ssh production-server docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
$ docker image save uptimer | ssh production-server 'docker image load'
Loaded image: uptimer:latest
$ ssh production-server docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
uptimer latest 1d56897841ec 5 minutes ago 78.9MBComanda docker save salvează datele imaginii într-un arhiv .tar, adică are o dimensiune cu aproximativ 1,5 ori mai mare decât ar avea în format comprimat. Așadar, să-l comprimăm în numele economisirii de timp și lățime de bandă:
$ docker image save uptimer | gzip | ssh production-server 'zcat | docker image load'
Loaded image: uptimer:latestDe asemenea, se poate observa procesul de transfer (cu toate că este necesară o unealtă externă pentru aceasta):
$ docker image save uptimer | gzip | pv | ssh production-server 'zcat | docker image load'
25,7MiB 0:01:01 [ 425KiB/s] [ ]
Loaded image: uptimer:latestSfatură: Dacă pentru a te conecta la serverul prin SSH ai nevoie de o mulțime de parametrii, este posibil că nu folosești fișierul
~/.ssh/config.
Transferul imaginii prin docker image save/load este cea mai minimalistă metodă, dar nu singura. Există și altele:
- Container Registry (standardul din industrie).
- Conectează-te la daemon-ul Docker al serverului de pe o altă gazdă:
- Variabila de mediu
DOCKER_HOST. - Parametrul de linie de comandă
-Hsau--hostinstrumentuldocker-compose. docker context
- Variabila de mediu
A doua metodă (cu trei variante de implementare) este bine descrisă în articolul .
deploy.sh
Acum să adunăm tot ceea ce am făcut manual într-un singur script. Să începem cu funcția de top-level, apoi vom examina celelalte funcții utilizate în aceasta.
Tehnici interesante
${parameter?err_msg}este una dintre formulele magiei bash (aka ). Dacăparametrulnu este setat, să se afișezeerr_msgși să se iasă cu codul 1.docker --log-driver journald— în mod implicit, driverul de logare Docker este un fișier text fără nicio rotație. Cu acest lucru, jurnalele umplu rapid întregul disc, așa că pentru un mediu de producție este necesar să schimbi driverul cu unul mai inteligent.
Scriptul de deploy
deploy() {
local usage_msg="Utilizare: ${FUNCNAME[0]} nume_imagine"
local image_name=${1?$usage_msg}
ensure-reverse-proxy || return 2
if get-active-slot $image_name
then
local OLD=${image_name}_BLUE
local new_slot=GREEN
else
local OLD=${image_name}_GREEN
local new_slot=BLUE
fi
local NEW=${image_name}_${new_slot}
echo "Implementând '$NEW' în locul lui '$OLD'..."
docker run
--detach
--restart always
--log-driver journald
--name $NEW
--network web-gateway
$image_name || return 3
echo "Containerul a fost pornit. Verificând starea..."
for i in {1..20}
do
sleep 1
if get-service-status $image_name $new_slot
then
echo "Noul serviciu '$NEW' pare OK. Schimbând capetele..."
sleep 2 # Asigură-te că serviciul este gata
set-active-slot $image_name $new_slot || return 4
echo "Serviciul '$NEW' este activ!"
sleep 2 # Asigură-te că toate cererile au fost procesate
echo "Oprind '$OLD'..."
docker rm -f $OLD
docker image prune -f
echo "Implementare reușită!"
return 0
fi
echo "Serviciul '$NEW' nu este încă gata. Aștept ($i)..."
done
echo "Serviciul '$NEW' nu a pornit, îl omor. Implementarea a eșuat T_T"
docker rm -f $NEW
return 5
}Funcțiile utilizate:
ensure-reverse-proxy— Se asigură că reverse proxy-ul funcționează (util la prima implementare)get-active-slot nume_serviciu— Determină care este slotul activ pentru serviciul dat (BLUEsauGREEN)get-service-status nume_serviciu slot_de_implementare— Determină dacă serviciul este pregătit să proceseze cereri de intrareset-active-slot nume_serviciu slot_de_implementare— Schimbă configurația nginx în containerul reverse proxy
În ordine:
ensure-reverse-proxy() {
is-container-up reverse-proxy && return 0
echo "Dezvoltarea reverse-proxy..."
docker network create web-gateway
docker run
--detach
--restart always
--log-driver journald
--name reverse-proxy
--network web-gateway
--publish 80:80
nginx:alpine || return 1
docker exec --interactive reverse-proxy sh -c "> /etc/nginx/conf.d/default.conf"
docker exec reverse-proxy nginx -s reload
}
is-container-up() {
local container=${1?"Utilizare: ${FUNCNAME[0]} nume_container"}
[ -n "$(docker ps -f name=${container} -q)" ]
return $?
}
get-active-slot() {
local service=${1?"Utilizare: ${FUNCNAME[0]} nume_serviciu"}
if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then
echo "Coliziune detectată! Oprire ${service}_GREEN..."
docker rm -f ${service}_GREEN
return 0 # BLUE
fi
if is-container-up ${service}_BLUE && ! is-container-up ${service}_GREEN; then
return 0 # BLUE
fi
if ! is-container-up ${service}_BLUE; then
return 1 # GREEN
fi
}
get-service-status() {
local usage_msg="Utilizare: ${FUNCNAME[0]} nume_serviciu slot_deployare"
local service=${1?usage_msg}
local slot=${2?$usage_msg}
case $service in
# Adăugați căile specifice pentru verificarea stării serviciilor aici
*) local health_check_port_path=":8080/" ;;
esac
local health_check_address="http://${service}_${slot}${health_check_port_path}"
echo "Solicitând '$health_check_address' în cadrul rețelei docker 'web-gateway':"
docker run --rm --network web-gateway alpine
wget --timeout=1 --quiet --server-response $health_check_address
return $?
}
set-active-slot() {
local usage_msg="Utilizare: ${FUNCNAME[0]} nume_serviciu slot_deployare"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
get-nginx-config $service $slot | docker exec --interactive reverse-proxy sh -c "cat > /etc/nginx/conf.d/$service.conf"
docker exec reverse-proxy nginx -t || return 2
docker exec reverse-proxy nginx -s reload
}Funcția get-active-slot necessită câteva explicații:
De ce returnează un număr și nu afișează un șir?
Totuși, în funcția apelantă verificăm rezultatul muncii sale, iar verificarea codului de ieșire prin bash este mult mai simplă decât a unui șir. În plus, obținerea unui șir din el este foarte simplă:
get-active-slot service && echo BLUE || echo GREEN.
Sunt suficiente cele trei condiții pentru a distinge toate stările?
Chiar și două sunt suficiente, ultimul este pur și simplu pentru completitudine, ca să nu scrii altfel.
Funcția care returnează configurațiile nginx a rămas nedefinită: get-nginx-config service_name deployment_slot. Prin analogie cu healthcheck-ul, aici se poate defini orice config pentru orice serviciu. Din ceea ce este interesant — doar cat <<- EOF, ceea ce permite eliminarea tuturor taburilor de la început. Cu toate acestea, prețul unei formatare convenabile este amestecul de taburi cu spații, ceea ce este considerat astăzi un obicei foarte prost. Însă bash forțează taburile, iar în configurația nginx ar fi bine să avem un format corect. În concluzie, amestecul de taburi cu spații pare a fi cu adevărat cea mai bună soluție dintre cele rele. Cu toate acestea, în snippetul de mai jos nu veți vedea asta, deoarece habr „face bine”, schimbând toate taburile în 4 spații și făcând EOF invalid. .
Ca să nu repet, vă voi spune imediat despre
cat << 'EOF', care va mai apărea mai departe. Dacă scrieți simplucat << EOF, atunci în interiorul heredoc se face interpolarea șirului (se deschid variabilele ($foo), apelurile de comenzi ($(bar)) etc., dar dacă închideți semnul de sfârșit al documentului în ghilimele simple, atunci interpolarea este dezactivată și simbolul$este afișat așa cum este. Asta e ceea ce trebuie pentru a insera un script în interiorul altui script.
get-nginx-config() {
local usage_msg="Utilizare: ${FUNCNAME[0]} nume_serviciu slot_de_deploy"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
local container_name=${service}_${slot}
case $service in
# Adăugați configurații nginx specifice pentru serviciile dvs. aici
*) nginx-config-simple-service $container_name:8080 ;;
esac
}
nginx-config-simple-service() {
local usage_msg="Utilizare: ${FUNCNAME[0]} proxy_pass"
local proxy_pass=${1?$usage_msg}
cat << EOF
server {
listen 80;
location / {
proxy_pass http://$proxy_pass;
}
}
EOF
}Aceasta este întreaga script. Și iată pentru descărcare prin wget sau curl.
Executarea scripturilor parametrizate pe un server la distanță
A sosit momentul să ne conectăm la serverul țintă. De data aceasta localhost se potrivește perfect:
$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: încercând să vă conectați cu cheia nouă(nouă), pentru a filtra orice cheie deja instalată
/usr/bin/ssh-copy-id: INFO: 1 cheie(e) rămân de instalat - dacă vi se solicită acum, este pentru a instala noile chei
himura@localhost's password:
Numărul de chei adăugate: 1
Acum încercați să vă conectați la mașină, cu: "ssh 'localhost'"
și verificați pentru a vă asigura că doar cheile dorite au fost adăugate.Am scris un script de deployare care transferă o imagine compilată pe serverul țintă și îndeplinește în mod fluid schimbarea containerului serviciului, dar cum îl poți rula pe o mașină la distanță? Scriptul are argumente, deoarece este versatil și poate să deploieze mai multe servicii sub un singur reverse proxy (cu config-uri Nginx se poate rezolva ce URL va avea fiecare serviciu). Scriptul nu poate fi stocat pe server, deoarece în acest caz nu-l putem actualiza automat (în scopuri de corectare a erorilor și adăugarea de noi servicii), și, în general, state = rău.
Soluția 1: Atunci să stocăm scriptul pe server, dar să-l copiem de fiecare dată prin scp. Apoi să ne conectăm prin ssh și să executăm scriptul cu argumentele necesare.
Dezavantaje:
- Două acțiuni în loc de una
- Locul în care copiază poate să nu existe, sau să nu aibă acces, sau scriptul poate fi executat în momentul în care se face schimbarea.
- Este de preferat să arunci după tine (să ștergi scriptul).
- Deja trei acțiuni.
Soluția 2:
- În script să păstrezi doar definițiile funcțiilor și să nu rulezi deloc
- Folosind
sedsă adaugi la sfârșit apelul funcției - Să trimiți totul direct în shh prin pipe (
|)
Pro:
- Cu adevărat fără stare
- Fără entități boilerplate
- Se simte grozav
Dar să nu vorbim de Ansible. Da, totul a fost deja gândit. Da, bicicleta. Uită-te ce bicicletă simplă, elegantă și minimalistă:
$ cat < deploy.sh#!/bin/bash
usage_msg="Usage: $0 ssh_address local_image_tag"
ssh_address=${1?$usage_msg}
image_name=${2?$usage_msg}
echo "Connecting to '$ssh_address' via ssh to seamlessly deploy '$image_name'..."
( sed "$a deploy $image_name" | ssh -T $ssh_address ) << 'END_OF_SCRIPT'
deploy() {
echo "Yay! The '${FUNCNAME[0]}' function is executing on '$(hostname)' with argument '$1'"
}
END_OF_SCRIPTEOF
$ chmod +x deploy.sh
$ ./deploy.sh localhost magic-porridge-pot
Conectându-se la localhost...
Yay! Funcția 'deploy' se execută pe 'hut' cu argumentul 'magic-porridge-pot'Cu toate acestea, nu putem fi siguri că pe gazda la distanță este un bash adecvat, așa că să adăugăm la început o mică verificare (asta în loc de ):
if [ "$SHELL" != "/bin/bash" ]
then
echo "Shell-ul '$SHELL' nu este acceptat de 'deploy.sh'. Setează un shell '/bin/bash' pentru '$USER@$HOSTNAME'."
exit 1
fiȘi acum totul pe bune:
$ docker exec reverse-proxy rm /etc/nginx/conf.d/default.conf
$ wget -qO deploy.sh https://git.io/JUURc
$ chmod +x deploy.sh
$ ./deploy.sh localhost uptimer
Trimiterea imaginii comprimate 'uptimer' către 'localhost' prin ssh...
Imagine încărcată: uptimer:latest
Conectare la 'localhost' prin ssh pentru a desfășura 'uptimer' fără probleme...
Desfășurarea 'uptimer_GREEN' în locul 'uptimer_BLUE'...
06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18a
Container pornit. Verificarea sănătății...
Solicitare 'http://uptimer_GREEN:8080/' în rețeaua docker 'web-gateway':
HTTP/1.0 503 Serviciu indisponibil
wget: serverul a returnat eroare: HTTP/1.0 503 Serviciu indisponibil
Noua servire 'uptimer_GREEN' nu este încă gata. Așteptare (1)...
Solicitare 'http://uptimer_GREEN:8080/' în rețeaua docker 'web-gateway':
HTTP/1.0 503 Serviciu indisponibil
wget: serverul a returnat eroare: HTTP/1.0 503 Serviciu indisponibil
Noua servire 'uptimer_GREEN' nu este încă gata. Așteptare (2)...
Solicitare 'http://uptimer_GREEN:8080/' în rețeaua docker 'web-gateway':
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.8.3
Dată: Sat, 22 Aug 2020 20:15:50 GMT
Tip conținut: text/html
Noua servire 'uptimer_GREEN' pare a fi OK. Schimbând capetele...
nginx: fișierul de configurare /etc/nginx/nginx.conf are sintaxa corectă
nginx: testul fișierului de configurare /etc/nginx/nginx.conf este reușit
2020/08/22 20:15:54 [anunț] 97#97: procesul semnalizat a început
Serviciul 'uptimer_GREEN' este activ!
Împușcând 'uptimer_BLUE'...
uptimer_BLUE
Total spațiu recuperat: 0B
Desfășurarea a fost reușită!Acum poți deschide în browser, să repornești desfășurarea din nou și să te asiguri că aceasta se desfășoară fără probleme actualizând pagina în mod constant în timpul desfășurării.
Să nu uităm să facem curățenie după muncă :3
$ docker rm -f uptimer_GREEN reverse-proxy
uptimer_GREEN
reverse-proxy
$ docker network rm web-gateway
web-gateway
$ cd ..
$ rm -r blue-green-deploymentSursa: habr.com
