In questo articolo organizzeremo , , e un'implementazione senza interruzioni di un'applicazione web. è una tecnica che consente di aggiornare un'applicazione istantaneamente senza rifiutare alcuna richiesta. È una delle strategie di zero downtime deployment e si adatta meglio ad applicazioni con un'istanza, ma con la possibilità di caricarne un'altra secondaria, pronta per essere operativa.
Supponiamo di avere un'applicazione web che viene utilizzata attivamente da molti clienti e non può assolutamente subire nemmeno una breve interruzione. E avete davvero bisogno di rilasciare un aggiornamento della libreria, una correzione di bug o una nuova funzionalità interessante. In una situazione normale, sarebbe necessario fermare l'applicazione, sostituirla e poi riavviarla. Nel caso di Docker, si può prima sostituirla e poi riavviarla, ma ci sarà comunque un periodo in cui le richieste all'applicazione non verranno processate, perché di solito è necessario del tempo per un avvio iniziale. E se si avviasse, ma risultasse non funzionante? Ecco una sfida, risolviamola con i mezzi minimi e nel modo più elegante possibile.
DISCLAIMER: La maggior parte dell'articolo è presentata in un formato sperimentale — come una registrazione di sessione della console. Spero che non sia troppo difficile da comprendere e che questo codice si documenti da solo in misura sufficiente. Per dare un'idea, immaginate che non siano solo snippet di codice, ma carta da un teletype 'ferro'.
Tecniche interessanti che sono difficili da trovare semplicemente leggendo il codice sono descritte all'inizio di ogni sezione. Se c'è qualcos'altro che non è chiaro — cercate e controllate su (per fortuna, è di nuovo operativo, grazie alla riattivazione di Telegram). Se non riuscite a trovare qualcosa tramite ricerca — chiedete nei commenti. Sarò lieto di aggiungere il relativo punto nella sezione 'Tecniche interessanti'.
Iniziamo.
$ mkdir blue-green-deployment && cd $_Servizio
Creeremo un servizio di prova e lo metteremo in un contenitore.
Tecniche interessanti
cat < file-name( + ) — è un modo per creare un file multilinea con un solo comando. Tutto ciò che bash leggerà da/dev/stdindopo questa riga e fino alla rigaEOFverrà scritto infile-name.wget -qO- URL() — per stampare il documento ricevuto in HTTP in/dev/stdout(simile acurl URL).
Stampa
Sto appositamente rompendo lo snippet per attivare l'evidenziazione per Python. Alla fine ci sarà un altro pezzo simile. Considerate che in questi punti la carta è stata tagliata per la trasmissione al dipartimento di evidenziazione (dove il codice è stato colorato a mano con gli evidenziatori), e poi questi pezzi sono stati incollati di nuovo.
$ cat < uptimer.pyda http.server importare BaseHTTPRequestHandler, HTTPServer
from time import monotonic
app_version = 1
app_name = f'Uptimer v{app_version}.0'
loading_seconds = 15 - app_version * 5
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path == '':
try:
t = monotonic() - server_start
if t < loading_seconds:
self.send_error(503)
else:
self.send_response(200)
self.send_header('Content-Type', 'text/html')
self.end_headers()
response = f'<h2>{app_name} è in esecuzione da {t:3.1f} secondi.</h2>n'
self.wfile.write(response.encode('utf-8'))
except Exception:
self.send_error(500)
else:
self.send_error(404)
httpd = HTTPServer(('', 8080), Handler)
server_start = monotonic()
print(f'{app_name} (carica in {loading_seconds} sec.) avviato.')
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 .
Invio del contesto di build al demone Docker 39.42kB
Step 1/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2/4 : EXPOSE 8080
---> Utilizzando la cache
---> cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
---> a7fbb33d6b7e
Step 4/4 : CMD [ "python", "-u", ".\/app.py" ]
---> Esecuzione in 1906b4bd9fdf
Rimozione del contenitore intermedio 1906b4bd9fdf
---> c1655b996fe8
Costruito con successo c1655b996fe8
Taggato correttamente 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 secondi fa Eseguito 5 secondi fa 0.0.0.0:8080->8080/tcp uptimer
$ docker logs uptimer
Uptimer v1.0 (carica in 10 sec.) avviato.
$ wget -qSO- http:\/\/localhost:8080
HTTP\/1.0 503 Servizio non disponibile
Server: BaseHTTP\/0.6 Python\/3.8.3
Date: Sab, 22 Ago 2020 19:52:40 GMT
Connection: 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
Date: Sab, 22 Ago 2020 19:52:45 GMT
Content-Type: text\/html
<h2>Uptimer v1.0 è in esecuzione da 15,4 secondi.</h2>
$ docker rm --force uptimer
uptimerReverse proxy
Perché la nostra applicazione possa cambiare in modo invisibile, è necessario che ci sia un'altra entità davanti a essa che nasconda il suo cambiamento. Questo può essere un server web in . Il reverse proxy si colloca tra il cliente e l'applicazione. Riceve richieste dai clienti e le inoltra all'applicazione, mentre le risposte dell'applicazione vengono indirizzate ai clienti.
L'applicazione e il reverse proxy possono essere collegati all'interno di Docker utilizzando . In questo modo, al contenitore dell'applicazione non è nemmeno necessario inoltrare una porta nel sistema host, il che consente di isolare al massimo l'applicazione dalle minacce esterne.
Se il reverse proxy si trova su un altro host, dovrai rinunciare a docker network e collegare l'applicazione al reverse proxy tramite la rete dell'host, inoltrando la porta dell'applicazione parametro --publish, come alla prima esecuzione e come nel reverse proxy.
Eseguiremo il reverse proxy sulla porta 80, poiché è proprio questa entità che dovrebbe ascoltare l'esterno. Se la porta 80 è occupata sul tuo host di test, cambia il parametro --publish 80:80 in --publish ANY_FREE_PORT:80.
Tecniche interessanti
- "Nelle reti Docker create dall'utente, i contenitori possono essere collegati non solo tramite indirizzo IP. Anche il nome del contenitore viene risolto nel suo indirizzo IP" (, punto 5 del codice di Docker).
Stampa
$ 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 è in esecuzione da 11,5 secondi.</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.…" 27 secondi fa Up 25 secondi 0.0.0.0:80->80/tcp reverse-proxy
a1105f1b583d uptimer "python -u ./app.py" Circa un minuto fa Up Circa un minuto 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: Sab, 22 Aug 2020 19:56:24 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
<h2>Uptimer v1.0 è in esecuzione da 104,1 secondi.</h2>Deployment senza interruzioni
Rilasceremo una nuova versione dell'applicazione (con un doppio incremento delle prestazioni di avvio) e cercheremo di implementarla senza interruzioni.
Tecniche interessanti
echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt'— Scrivere il testomy textnel file/my-file.txtall'interno del contenitoremy-container.cat > /my-file.txt— Scrivere nel file il contenuto dell'input standard/dev/stdin.
Stampa
$ sed -i "s\/app_version = 1\/app_version = 2\/" uptimer.py
$ docker build --tag uptimer .
Invio del contesto di build al demone Docker 39.94kB
Step 1\/4 : FROM python:alpine
---> 8ecf5a48c789
Step 2\/4 : EXPOSE 8080
---> Uso della cache
---> cf92d174c9d3
Step 3\/4 : COPY uptimer.py app.py
---> 3eca6a51cb2d
Step 4\/4 : CMD [ "python", "-u", ".\/app.py" ]
---> Esecuzione in 8f13c6d3d9e7
Rimozione del container intermedio 8f13c6d3d9e7
---> 1d56897841ec
Costruito con successo 1d56897841ec
Taggato con successo uptimer:latest
$ docker run --detach --rm --name uptimer_BLUE --network web-gateway uptimer
96932d4ca97a25b1b42d1b5f0ede993b43f95fac3c064262c5c527e16c119e02
$ docker logs uptimer_BLUE
Uptimer v2.0 (carico in 5 sec.) avviato.
$ docker run --rm --network web-gateway alpine wget -qO- http:\/\/uptimer_BLUE:8080
<h2>Uptimer v2.0 è in esecuzione da 23.9 secondi.</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: segnala che il processo è avviato
$ wget -qO- http:\/\/localhost
<h2>Uptimer v2.0 è in esecuzione da 63.4 secondi.</h2>
$ docker rm -f uptimer
uptimer
$ wget -qO- http:\/\/localhost
<h2>Uptimer v2.0 è in esecuzione da 84.8 secondi.</h2>
$ docker ps
ID CONTAINER IMMAGINE COMANDO CREATO STATO PORTI NOME
96932d4ca97a uptimer "python -u .\/app.py" Circa un minuto fa In esecuzione da circa un minuto 8080\/tcp uptimer_BLUE
80695a822c19 nginx:alpine "\/docker-entrypoint.…" 8 minuti fa In esecuzione da 8 minuti 0.0.0.0:80->80\/tcp reverse-proxyIn questa fase, l'immagine viene costruita direttamente sul server, il che richiede la presenza dei sorgenti dell'applicazione e appesantisce il server con lavoro extra. Il passo successivo sarà quello di dedicare la costruzione dell'immagine a una macchina separata (ad esempio in un sistema CI) con successivo trasferimento al server.
Trasferimento delle immagini
Sfortunatamente, non ha senso trasferire immagini da localhost a localhost, quindi questa sezione può essere esplorata solo se si dispone di due host con Docker. In termini minimi, appare più o meno così:
$ 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.9MBTeam docker save salva i dati dell'immagine in un archivio .tar, quindi pesa circa 1,5 volte di più di quanto potrebbe pesare in forma compressa. Quindi compriamolo per risparmiare tempo e traffico:
$ docker image save uptimer | gzip | ssh production-server 'zcat | docker image load'
Loaded image: uptimer:latestInoltre, è possibile monitorare il processo di trasferimento (anche se è necessaria un'utilità di terze parti):
$ docker image save uptimer | gzip | pv | ssh production-server 'zcat | docker image load'
25,7MiB 0:01:01 [ 425KiB/s] [ ]
Loaded image: uptimer:latestConsiglio: Se hai bisogno di molti parametri per connetterti al server via SSH, potrebbe essere che non stai utilizzando il file
~/.ssh/config.
Trasferimento dell’immagine tramite docker image save/load è il metodo più minimalista, ma non l'unico. Ce ne sono altri:
- Container Registry (standard del settore).
- Connettersi al daemon docker del server da un altro host:
- Variabile d'ambiente
DOCKER_HOST. - Parametro della riga di comando
-Ho--hoststrumentodocker-compose. docker context
- Variabile d'ambiente
Un secondo metodo (con tre varianti di attuazione) è ben descritto nell'articolo .
deploy.sh
Ora raccoglieremo tutto ciò che abbiamo fatto manualmente in uno script. Iniziamo con la funzione principale, poi daremo un'occhiata alle altre utilizzate in essa.
Tecniche interessanti
${parameter?err_msg}è uno degli incantesimi della magia bash (aka ). Separameternon è settato, visualizzaerr_msged esci con codice 1.docker --log-driver journaldper impostazione predefinita, il driver di registrazione di Docker è un file di testo senza alcuna rotazione. Con questo approccio, i log riempiono rapidamente intero disco, quindi in un ambiente di produzione è necessario cambiare il driver con uno più intelligente.
Script di deploy
deploy() {
local usage_msg="Utilizzo: ${FUNCNAME[0]} nome_immagine"
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 "Distribuendo '$NEW' al posto di '$OLD'..."
docker run
--detach
--restart always
--log-driver journald
--name $NEW
--network web-gateway
$image_name || return 3
echo "Container avviato. Controllo della salute..."
for i in {1..20}
do
sleep 1
if get-service-status $image_name $new_slot
then
echo "Il nuovo servizio '$NEW' sembra OK. Switching heads..."
sleep 2 # Assicurati che il servizio sia pronto
set-active-slot $image_name $new_slot || return 4
echo "Il servizio '$NEW' è attivo!"
sleep 2 # Assicurati che tutte le richieste siano state elaborate
echo "Terminando '$OLD'..."
docker rm -f $OLD
docker image prune -f
echo "Distribuzione avvenuta con successo!"
return 0
fi
echo "Il nuovo servizio '$NEW' non è ancora pronto. Attesa ($i)..."
done
echo "Il nuovo servizio '$NEW' non è stato avviato, terminandolo. Fallimento della distribuzione T_T"
docker rm -f $NEW
return 5
}Funzioni utilizzate:
ensure-reverse-proxy— Verifica che il reverse proxy sia attivo (utile per il primo deployment)get-active-slot nome_servizio— Determina quale slot è attivo per il servizio specificato (BLUEoGREEN)get-service-status nome_servizio slot_distribuzione— Determina se il servizio è pronto a gestire le richieste in arrivoset-active-slot nome_servizio slot_distribuzione— Cambia la configurazione di nginx nel container del reverse proxy
In ordine:
ensure-reverse-proxy() {
is-container-up reverse-proxy && return 0
echo "Distribuzione 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?"Uso: ${FUNCNAME[0]} container_name"}
[ -n "$(docker ps -f name=${container} -q)" ]
return $?
}
get-active-slot() {
local service=${1?"Uso: ${FUNCNAME[0]} service_name"}
if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then
echo "Collision detected! Arresto di ${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="Uso: ${FUNCNAME[0]} service_name deployment_slot"
local service=${1?usage_msg}
local slot=${2?$usage_msg}
case $service in
# Aggiungi percorsi di healthcheck specifici per i tuoi servizi qui
*) local health_check_port_path=":8080/" ;;
esac
local health_check_address="http://${service}_${slot}${health_check_port_path}"
echo "Richiesta '$health_check_address' all'interno della rete 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="Uso: ${FUNCNAME[0]} service_name deployment_slot"
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
}La funzione get-active-slot richiede alcune spiegazioni:
Perché restituisce un numero e non stampa una stringa?
In ogni caso, nella funzione chiamante verifichiamo il risultato del suo lavoro, e controllare il codice di uscita con bash è molto più semplice che una stringa. Inoltre, ottenere una stringa da essa è molto facile:
get-active-slot service && echo BLUE || echo GREEN.
Bastano davvero tre condizioni per distinguere tutti gli stati?
Bastano anche due, l'ultima è qui solo per completezza, così da non dover scrivere else.
Resta indeterminata solo la funzione che restituisce le configurazioni nginx: get-nginx-config service_name deployment_slot. Analogamente all'healthcheck, qui si può impostare qualsiasi configurazione per qualsiasi servizio. Tra le cose interessanti c'è solo cat <<- EOF, che consente di rimuovere tutte le tabulazioni all'inizio. Tuttavia, il prezzo di una formattazione rispettabile è la mescolanza di tab e spazi, che oggi è considerata un cattivo gusto. Ma bash fornisce tabulazioni, e anche nel file di configurazione di nginx sarebbe utile avere una formattazione adeguata. In breve, qui la mescolanza di tab e spazi sembra davvero la migliore soluzione tra le peggiori. Tuttavia, nel frammento qui sotto non lo vedrete, poiché habr "fa bene", cambiando tutte le tabulazioni in 4 spazi e rendendo EOF non valido. .
Per non dover ripetere, vi racconterò subito di
cat << 'EOF', che incontreremo più avanti. Se si scrive semplicementecat << EOF, all'interno dell'heredoc viene eseguita l'interpolazione della stringa (vengono espanse le variabili ($foo), vengono chiamati comandi ($(bar)) e così via), e se si racchiude il segno di fine documento tra apici singoli, l'interpolazione viene disattivata e il simbolo$viene visualizzato così com'è. Questo è necessario per inserire uno script all'interno di un altro script.
get-nginx-config() {
local usage_msg="Uso: ${FUNCNAME[0]} nome_servizio slot_deployment"
local service=${1?$usage_msg}
local slot=${2?$usage_msg}
[ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1
local container_name=${service}_${slot}
case $service in
# Aggiungi configurazioni nginx specifiche per i tuoi servizi qui
*) nginx-config-simple-service $container_name:8080 ;;
esac
}
nginx-config-simple-service() {
local usage_msg="Uso: ${FUNCNAME[0]} proxy_pass"
local proxy_pass=${1?$usage_msg}
cat << EOF
server {
listen 80;
location / {
proxy_pass http://$proxy_pass;
}
}
EOF
}Questo è l'intero script. Ecco per il download tramite wget o curl.
Esecuzione di script parametrizzati su un server remoto
È ora di collegarsi al server di destinazione. Questa volta localhost va bene:
$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: tentando di accedere con la nuova chiave(i), per filtrare quelle già installate
/usr/bin/ssh-copy-id: INFO: 1 chiave(e) rimangono da installare -- se ora vengono richieste, è per installare le nuove chiavi
himura@localhost's password:
Numero di chiave(e) aggiunta(e): 1
Ora prova a collegarti alla macchina, con: "ssh 'localhost'"
e controlla di assicurarti che siano state aggiunte solo le chiave(e) che volevi.Abbiamo scritto uno script di deploy che trasferisce un'immagine precompilata sul server di destinazione e sostituisce senza soluzione di continuità il contenitore del servizio, ma come eseguirlo su una macchina remota? Lo script ha degli argomenti, poiché è universale e può fare il deploy di più servizi sotto un unico reverse proxy (con i configuratori nginx si può decidere quale servizio andrà su quale URL). Non possiamo conservare lo script sul server, poiché in questo caso non potremmo aggiornarlo automaticamente (per correggere bug e aggiungere nuovi servizi) e, in generale, lo stato = male.
Soluzione 1: Conservare lo script sul server, ma copiarlo ogni volta tramite scp. Poi collegarsi tramite ssh ed eseguire lo script con gli argomenti necessari.
Contro:
- Due azioni invece di una
- Il posto dove copi si potrebbe non trovare, o potrebbe non essere accessibile, oppure lo script potrebbe eseguirsi nel momento della sostituzione.
- È auspicabile rimuoverlo (eliminare lo script).
- Già tre azioni.
Soluzione 2:
- Nello script mantenere solo le definizioni delle funzioni e non eseguire nulla
- Utilizzando
sedaggiungere alla fine la chiamata alla funzione - Inviare tutto questo direttamente in shh tramite pipe (
|)
Pro:
- Veramente stateless
- Nessuna entità boilerplate
- Sembra figo
Diciamo solo di stare lontano da Ansible. Sì, è già stato inventato. Sì, è un ciclo. Guarda che bicicletta semplice, elegante e minimalista:
$ 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
Collegandosi a localhost...
Eviva! La funzione 'deploy' sta eseguendo su 'hut' con l'argomento 'magic-porridge-pot'Tuttavia, non possiamo essere certi che sull'host remoto ci sia un bash adeguato, quindi aggiungiamo all'inizio un piccolo controllo (questo invece di ):
if [ "$SHELL" != "/bin/bash" ]
then
echo "Il shell '$SHELL' non è supportato da 'deploy.sh'. Imposta un shell '/bin/bash' per '$USER@$HOSTNAME'."
exit 1
fiE ora tutto per davvero:
$ 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
Inviando immagine gzipped 'uptimer' a 'localhost' tramite ssh...
Immagine caricata: uptimer:latest
Collegamento a 'localhost' tramite ssh per implementare senza soluzione di continuità 'uptimer'...
Implementando 'uptimer_GREEN' al posto di 'uptimer_BLUE'...
06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18a
Container avviato. Controllo stato...
Richiesta 'http://uptimer_GREEN:8080/' all'interno della rete docker 'web-gateway':
HTTP/1.0 503 Servizio non disponibile
wget: server ha restituito errore: HTTP/1.0 503 Servizio non disponibile
Il nuovo servizio 'uptimer_GREEN' non è ancora pronto. Attesa (1)...
Richiesta 'http://uptimer_GREEN:8080/' all'interno della rete docker 'web-gateway':
HTTP/1.0 503 Servizio non disponibile
wget: server ha restituito errore: HTTP/1.0 503 Servizio non disponibile
Il nuovo servizio 'uptimer_GREEN' non è ancora pronto. Attesa (2)...
Richiesta 'http://uptimer_GREEN:8080/' all'interno della rete docker 'web-gateway':
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.8.3
Date: Sab, 22 Ago 2020 20:15:50 GMT
Content-Type: text/html
Il nuovo servizio 'uptimer_GREEN' sembra OK. Cambio teste...
nginx: il file di configurazione /etc/nginx/nginx.conf ha sintassi corretta
nginx: test del file di configurazione /etc/nginx/nginx.conf avvenuto con successo
2020/08/22 20:15:54 [avviso] 97#97: processo di segnale avviato
Il servizio 'uptimer_GREEN' è attivo!
Terminazione 'uptimer_BLUE'...
uptimer_BLUE
Spazio totale reclamato: 0B
Implementazione riuscita!Ora puoi aprire nel browser, avviare nuovamente il deployment e verificare che avvenga senza problemi aggiornando la pagina di continuo durante la distribuzione.
Non dimentichiamo di pulire dopo il lavoro :3
$ docker rm -f uptimer_GREEN reverse-proxy
uptimer_GREEN
reverse-proxy
$ docker network rm web-gateway
web-gateway
$ cd ..
$ rm -r blue-green-deploymentFonte: habr.com
