🥇Blue-Green Deployment på minimalisme

I denne artikkelen skal vi bash, ssh, docker og nginx organisere sømløs distribusjon av et webapplikasjon. Blue-green deployment er en teknikk som gjør det mulig å oppdatere applikasjonen umiddelbart uten å avvise noen forespørsel. Det er en av strategiene for zero downtime deployment og passer best for applikasjoner med én instans, men muligheten til å laste opp en annen klar instans ved siden av.

La oss si at du har en webapplikasjon som mange kunder aktivt bruker, og den kan ikke stoppes selv i et par sekunder. Men du må oppdatere et bibliotek, fikse en feil eller legge til en ny kul funksjon. I en vanlig situasjon må du stoppe applikasjonen, erstatte den og starte den på nytt. I Docker kan du først erstatte, deretter starte på nytt, men det vil likevel være en periode der forespørslene til applikasjonen ikke blir behandlet, siden applikasjonen vanligvis trenger litt tid for å laste inn. Og hvis den startes opp, men viser seg å være ikke-fungerende? La oss finne en elegant løsning på dette problemet med minimale midler.

DISCLAIMER: Det meste av artikkelen presenteres i et eksperimentelt format – som en opptak av en konsolløkt. Jeg håper det ikke blir for vanskelig å forstå, og at koden dokumenterer seg selv i tilstrekkelig grad. For atmosfærens skyld, forestill deg at dette ikke bare er kodeutdrag, men papirer fra en 'jern'-teletype.

Interessante teknikker som er vanskelige å finne ved å lese koden, er beskrevet i begynnelsen av hver seksjon. Hvis noe er uklart – søk på nettet og sjekk på explainshell (heldigvis fungerer det igjen etter gjenåpningen av Telegram). Det som ikke kan googles – spør i kommentarene. Jeg vil gjerne legge til den relevante seksjonen 'Interessante teknikker'.

La oss begynne.

$ mkdir blue-green-deployment && cd $_

Tjeneste

La oss lage en testtjeneste og plassere den i en container.

Interessante teknikker

cat < file-name (Here Document + I/O Redirection) – er en metode for å opprette en flerlinjefil med én kommando. Alt som bash leser fra /dev/stdin etter denne linjen og til linjen EOF vil bli skrevet til file-name.
wget -qO- URL (explainshell) – for å skrive ut dokumentet hentet via HTTP til /dev/stdout (tilsvarende curl URL).

Utskrift

Jeg deler bevisst oppsnippets for å inkludere lyssetting for Python. Det vil være et annet slikt stykke til slutt. Tenk på at papiret ble klippet i disse områdene for å overføres til høylysingsavdelingen (hvor koden ble farget manuelt med høylysere), og deretter ble disse bitene limt tilbake.

$ cat < uptimer.py

fra http.server import BaseHTTPRequestHandler, HTTPServer
fra tid 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 == '':
            prøv:
                t = monotonic() - server_start
                if t &lt; loading_seconds:
                    self.send_error(503)
                ellers:
                    self.send_response(200)
                    self.send_header(&#039;Content-Type&#039;, &#039;text/html&#039;)
                    self.end_headers()
                    response = f&#039;<h2>{app_name} kjører i {t:3.1f} sekunder.</h2>n'
                    self.wfile.write(response.encode('utf-8'))
            unntak Exception:
                self.send_error(500)
        ellers:
            self.send_error(404)

httpd = HTTPServer(('', 8080), Handler)
server_start = monotonic()
print(f'{app_name} (laster i {loading_seconds} sek.) startet.')
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
 ---&gt; 8ecf5a48c789
Step 2\/4 : EXPOSE 8080
 ---&gt; Using cache
 ---&gt; cf92d174c9d3
Step 3\/4 : COPY uptimer.py app.py
 ---&gt; a7fbb33d6b7e
Step 4\/4 : CMD [ "python", "-u", ".\/app.py" ]
 ---&gt; Running in 1906b4bd9fdf
Removing intermediate container 1906b4bd9fdf
 ---&gt; 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-&gt;8080\/tcp   uptimer

$ docker logs uptimer
Uptimer v1.0 (loads in 10 sec.) started.

$ wget -qSO- http:\/\/localhost:8080
  HTTP\/1.0 503 Service Unavailable
  Server: BaseHTTP\/0.6 Python\/3.8.3
  Date: Sat, 22 Aug 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: Sat, 22 Aug 2020 19:52:45 GMT
  Content-Type: text\/html
<h2>Uptimer v1.0 har kørt i 15.4 sekunder.</h2>

$ docker rm --force uptimer
uptimer

Reverse proxy

For at applikasjonen vår skal kunne byttes ut usynlig, må det være en annen enhet foran den som skjuler erstatningen. Dette kan være en webserver nginx i i reverse proxy-modus. Reverse proxy plasseres mellom klienten og applikasjonen. Den tar imot forespørselene fra klientene og videresender dem til applikasjonen, og svarene fra applikasjonen sendes tilbake til klientene.

Applikasjonen og reverse proxy kan kobles sammen i Docker ved hjelp av docker network. Slik kan ikke containeren med applikasjonen engang måtte eksponere porten i verts-systemet, noe som maksimerer isolasjonen av applikasjonen fra trusler utenfra.

Hvis reverse proxy vil bo på en annen vert, må du gi opp docker network og koble applikasjonen til reverse proxy via vertsnettet ved å videresende porten. applikasjoner parameter --publish, som ved første oppstart og som ved reverse proxy.

Reverse proxy vil kjøre på port 80, fordi det er nettopp denne enheten som skal lytte til det eksterne. Hvis port 80 er opptatt på din testvert, endre parameteren --publish 80:80 En funksjon har blitt --publish ANY_FREE_PORT:80.

Interessante teknikker

«I brukergenererte Docker-nettverk kan man koble til containere ikke bare via IP-adresse. Navnet på containeren kan også løses opp til dens IP-adresse» (artikkelen «Networking with standalone containers», delen «Use user-defined bridge networks», punkt 5 i Docker-manifestet).

Utskrift

$ 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 kjører i 11,5 sekunder.</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 seconds ago       Up 25 seconds       0.0.0.0:80-&gt;80/tcp   reverse-proxy
a1105f1b583d        uptimer             "python -u ./app.py"     About a minute ago   Up About a minute   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 kjører i 104,1 sekunder.</h2>

Sømløs distribusjon

Vi vil rulle ut en ny versjon av applikasjonen (med to ganger ytelsesforbedring ved oppstart) og prøve å distribuere den sømløst.

Interessante teknikker

echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt' — Skriv inn tekst my text into the file /my-file.txt inne i containeren my-container.
cat > /my-file.txt — Skriv inn standard innganginnhold til filen /dev/stdin.

Utskrift

$ sed -i "s/app_version = 1/app_version = 2/" uptimer.py

$ docker build --tag uptimer .
Sending build context to Docker daemon  39.94kB
Step 1/4 : FROM python:alpine
 ---&gt; 8ecf5a48c789
Step 2/4 : EXPOSE 8080
 ---&gt; Using cache
 ---&gt; cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
 ---&gt; 3eca6a51cb2d
Step 4/4 : CMD [ "python", "-u", ".\/app.py" ]
 ---&gt; Running in 8f13c6d3d9e7
Removing intermediate container 8f13c6d3d9e7
 ---&gt; 1d56897841ec
Successfully built 1d56897841ec
Successfully tagged uptimer:latest

$ docker run --detach --rm --name uptimer_BLUE --network web-gateway uptimer
96932d4ca97a25b1b42d1b5f0ede993b43f95fac3c064262c5c527e16c119e02

$ docker logs uptimer_BLUE
Uptimer v2.0 (lastes in 5 sek.) starta.

$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer_BLUE:8080
<h2>Uptimer v2.0 har kjørt i 23,9 sekunder.</h2>

$ sed s/uptimer/uptimer_BLUE/ uptimer.conf | docker exec --interactive reverse-proxy sh -c 'cat &gt; /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: signal process started

$ wget -qO- http://localhost
<h2>Uptimer v2.0 har kjørt i 63,4 sekunder.</h2>

$ docker rm -f uptimer
uptimer

$ wget -qO- http://localhost
<h2>Uptimer v2.0 har kjørt i 84,8 sekunder.</h2>

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                NAMES
96932d4ca97a        uptimer             "python -u .\/app.py"     For omtrent et minutt siden   Opp 
For omtrent et minutt   8080/tcp             uptimer_BLUE
80695a822c19        nginx:alpine        "\/docker-entrypoint.…"   8 minutter siden        Opp 8 minutter        0.0.0.0:80-&gt;80/tcp   reverse-proxy

På dette stadiet bygges bildet direkte på serveren, noe som krever at kildekoden til applikasjonen er der, samt belastningen av serveren med unødvendig arbeid. Neste steg vil være å skille byggeprosessen av bildet til en egen maskin (for eksempel i CI-systemet) med påfølgende overføring til serveren.

Nedlastning av bilder

Dessverre er det meningsløst å overføre bilder fra localhost til localhost, så denne delen kan bare utforskes hvis du har to verter med Docker tilgjengelig. I minimumskonfigurasjonen ser det omtrent slik ut:

$ 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.9MB

Laget docker save lagrer bildeinformasjonen i en .tar-arkiv, som betyr at den veier omtrent 1.5 ganger mer enn den ville gjort i komprimert form. Så la oss komprimere den for å spare tid og båndbredde:

$ docker image save uptimer | gzip | ssh production-server 'zcat | docker image load'
Loaded image: uptimer:latest

Og du kan også overvåke overføringsprosessen (men for dette trenger du et tredjepartsverktøy):

$ docker image save uptimer | gzip | pv | ssh production-server 'zcat | docker image load'
25,7MiB 0:01:01 [ 425KiB/s] [                       ]
Loaded image: uptimer:latest

Tips: Hvis du trenger mange parametere for å koble til serveren via SSH, er det mulig at du ikke bruker filen ~/.ssh/config.

Overføring av bilder ved hjelp av docker image save/load er den mest minimalistiske metoden, men ikke den eneste. Det finnes flere:

Container Registry (bransjestandard).
Koble til Docker-demonen på serveren fra en annen vert:
1. Miljøvariabel DOCKER_HOST.
2. Kommando-linjeparameter -H eller --host verktøyet docker-compose.
3. docker context

Den andre metoden (med tre forskjellige implementeringsalternativer) er godt beskrevet i artikkelen How to deploy on remote Docker hosts with docker-compose.

`deploy.sh`

Nå skal vi samle alt vi har gjort manuelt i et skript. Vi begynner med toppnivåfunksjonen, og deretter ser vi på de andre som brukes i den.

Interessante teknikker

${parameter?err_msg} er en av fortryllelse i bash-magien (aka parameter substitution). Hvis parameter ikke er angitt, skriv ut err_msg og avslutt med kode 1.
docker --log-driver journald er som standard loggdriveren til Docker en tekstfil uten rotasjon. Med denne tilnærmingen fylles loggene raskt opp på disken, så for produksjonsmiljøet trenger du å bytte loggdriver til en mer intelligent.

Utdeploymentskript

deploy() {
    local usage_msg="Usage: ${FUNCNAME[0]} image_name"
    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 "Deploying '$NEW' in place of '$OLD'..."
    docker run 
        --detach 
        --restart always 
        --log-driver journald 
        --name $NEW 
        --network web-gateway 
        $image_name || return 3
    echo "Container started. Checking health..."
    for i in {1..20}
    do
        sleep 1
        if get-service-status $image_name $new_slot
        then
            echo "New '$NEW' service seems OK. Switching heads..."
            sleep 2  # Ensure service is ready
            set-active-slot $image_name $new_slot || return 4
            echo "'$NEW' service is live!"
            sleep 2  # Ensure all requests were processed
            echo "Killing '$OLD'..."
            docker rm -f $OLD
            docker image prune -f
            echo "Deployment successful!"
            return 0
        fi
        echo "New '$NEW' service is not ready yet. Waiting ($i)..."
    done
    echo "New '$NEW' service did not raise, killing it. Failed to deploy T_T"
    docker rm -f $NEW
    return 5
}

Brukte funksjoner:

ensure-reverse-proxy — Forsikrer at revers proxy fungerer (nyttig ved første distribusjon)
get-active-slot service_name — Bestemmer hvilken slot som er aktiv for den angitte tjenesten (BLÅ eller GRØNN)
get-service-status service_name deployment_slot — Sjekker om tjenesten er klar til å håndtere innkommende forespørsel
set-active-slot service_name deployment_slot — Endrer nginx-konfigurasjonen i revers proxy-konteineren

I rekkefølge:

ensure-reverse-proxy() {
    is-container-up reverse-proxy && return 0
    echo "Deploying 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?"Usage: ${FUNCNAME[0]} container_name"}

    [ -n "$(docker ps -f name=${container} -q)" ]
    return $?
}

get-active-slot() {
    local service=${1?"Usage: ${FUNCNAME[0]} service_name"}

    if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then
        echo "Collision detected! Stopping ${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="Usage: ${FUNCNAME[0]} service_name deployment_slot"
    local service=${1?usage_msg}
    local slot=${2?$usage_msg}

    case $service in
        # Add specific healthcheck paths for your services here
        *) local health_check_port_path=":8080/" ;;
    esac
    local health_check_address="http://${service}_${slot}${health_check_port_path}"
    echo "Requesting '$health_check_address' within the 'web-gateway' docker network:"
    docker run --rm --network web-gateway alpine 
        wget --timeout=1 --quiet --server-response $health_check_address
    return $?
}

set-active-slot() {
    local usage_msg="Usage: ${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
}

kan get-active-slot krever små forklaringer:

Hvorfor returnerer den et tall, i stedet for å skrive ut en streng?

Uansett, i den påkallende funksjonen sjekker vi resultatet av arbeidet dens, og det er mye enklere å sjekke exit-kode med bash enn en streng. I tillegg er det veldig enkelt å hente en streng fra den:
get-active-slot service && echo BLUE || echo GREEN.

Er tre betingelser virkelig nok til å skille alle tilstander?

To er tilstrekkelig; den siste er bare for å være grundig, for ikke å måtte skrive else.

Kun funksjonen som returnerer nginx-konfigurasjoner er fortsatt uavklart: get-nginx-config service_name deployment_slot. For likhetens skyld med helsesjekken, her kan man spesifisere hvilken som helst konfigurasjon for hvilken som helst tjeneste. Det eneste interessante er bare cat <<- EOF, noe som lar deg fjerne alle faner i begynnelsen. Men prisen for pent formatering er blandede faner med mellomrom, noe som i dag anses som svært dårlig stil. Men bash tvinger faner, og i nginx-konfigurasjonen ville det vært fint å ha en normal formatering. Kort sagt, å blande faner med mellomrom ser ut til å være den beste løsningen av de dårlige. Men, i snippene nedenfor ser du ikke dette, ettersom Habr 'gjør det bra', ved å endre alle faner til 4 mellomrom og gjøre EOF ugyldig. Her er det merkbart.

For å unngå å gjøre dette to ganger, vil jeg straks fortelle om cat << 'EOF', som vil bli presentert igjen senere. Hvis du skriver bare cat << EOF, så foregår det en interpolering av strengen inne i heredoc (variabler blir utvidet ($foo), kommandokall ($(bar)) osv.), men hvis du omgir slutttegnene med enkle anførselstegn, deaktiveres interpoleringen, og tegnet $ skrives ut som det er. Det er akkurat det som trengs for å sette inn et skript inne i et annet skript.

get-nginx-config() {
    local usage_msg="Bruk: ${FUNCNAME[0]} tjenestenavn distribusjonsplass"
    local service=${1?$usage_msg}
    local slot=${2?$usage_msg}
    [ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1

    local container_name=${service}_${slot}
    case $service in
        # Legg til spesifikke nginx-konfigurasjoner for tjenestene dine her
        *) nginx-config-simple-service $container_name:8080 ;;
    esac
}

nginx-config-simple-service() {
    local usage_msg="Bruk: ${FUNCNAME[0]} proxy_pass"
    local proxy_pass=${1?$usage_msg}

cat << EOF
server {
    listen 80;
    location / {
        proxy_pass http://$proxy_pass;
    }
}
EOF
}

Dette er hele skriptet. Og her er gisten med dette skriptet for nedlasting via wget eller curl.

Utføre parameteriserte skript på en ekstern server

Det er på tide å koble til den målrettede serveren. Denne gangen localhost vil være helt passende:

$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: prøver å logge inn med den nye nøkkelen(e), for å filtrere ut eventuelle som allerede er installert
/usr/bin/ssh-copy-id: INFO: 1 nøkkel(e) gjenstår å bli installert - hvis du blir bedt om det nå, er det for å installere de nye nøklene
himura@localhost's passord: 

Antall nøkkel(e) lagt til: 1

Nå prøv å logge inn på maskinen, med:   "ssh 'localhost'"
og sjekk for å være sikker på at bare de nøklene du ønsket ble lagt til.

Vi har skrevet et deploy-script som overfører et forhåndsbygget bilde til målserveren og sømløst bytter ut tjenestecontaineren, men hvordan kan vi kjøre det på en ekstern maskin? Scriptet har argumenter, ettersom det er universelt og kan implementere flere tjenester under én reverse proxy (med nginx-configurasjoner kan vi løse hvilken URL som tilhører hvilken tjeneste). Scriptet kan ikke lagres på serveren fordi vi da ikke kan oppdatere det automatisk (for feilretting og tillegg av nye tjenester), og generelt er state = ondsinnet.

Løsning 1: Lagre scriptet på serveren, men kopier det hver gang gjennom scp. Deretter koble til via ssh og kjøre scriptet med nødvendige argumenter.

Ulemper:

To handlinger i stedet for én
Steder hvor du kopierer kan være utilgjengelige, eller du kan mangle tilgang, eller scriptet kan kjøres på tidspunktet for bytte.
Det er ønskelig å rydde opp etter seg (slette scriptet).
Allerede tre handlinger.

Løsning 2:

Bare holde definisjonene av funksjoner i scriptet og ikke kjøre noe
Ved hjelp av sed legge til et kall til funksjonen på slutten
Sende alt dette direkte til shh gjennom pipe (|)

Fordeler:

Ekte stateless
Ingen boilerplate-enheter
Føles bra

La oss bare la være med Ansible. Ja, alt er allerede oppfunnet. Ja, sykkelen. Se, hvilken enkel, elegant og minimalistisk sykkel:

$ 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_SCRIPT

EOF

$ chmod +x deploy.sh

$ ./deploy.sh localhost magic-porridge-pot
Connecting to localhost...
Yay! 'deploy'-funksjonen kjører på 'hut' med argumentet 'magic-porridge-pot'

Men vi kan ikke være sikre på at den eksterne verten har en tilstrekkelig bash, så vi legger til en liten sjekk i starten (dette i stedet for shellbang):

if [ "$SHELL" != "/bin/bash" ]
then
    echo "$SHELL-skal er ikke støttet av 'deploy.sh'. Sett en '/bin/bash' shell for '$USER@$HOSTNAME'."
    exit 1
fi

Og nå er alt ekte:

$ 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
Sending gzipped image 'uptimer' to 'localhost' via ssh...
Loaded image: uptimer:latest
Connecting to 'localhost' via ssh to seamlessly deploy 'uptimer'...
Deploying 'uptimer_GREEN' in place of 'uptimer_BLUE'...
06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18a
Container started. Checking health...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
  HTTP/1.0 503 Service Unavailable
wget: server returned error: HTTP/1.0 503 Service Unavailable
New 'uptimer_GREEN' service is not ready yet. Waiting (1)...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
  HTTP/1.0 503 Service Unavailable
wget: server returned error: HTTP/1.0 503 Service Unavailable
New 'uptimer_GREEN' service is not ready yet. Waiting (2)...
Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:
  HTTP/1.0 200 OK
  Server: BaseHTTP/0.6 Python/3.8.3
  Date: Sat, 22 Aug 2020 20:15:50 GMT
  Content-Type: text/html

New 'uptimer_GREEN' service seems OK. Switching heads...
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
2020/08/22 20:15:54 [notice] 97#97: signal process started
The 'uptimer_GREEN' service is live!
Killing 'uptimer_BLUE'...
uptimer_BLUE
Total reclaimed space: 0B
Deployment successful!

Nå kan du åpne http://localhost/ i nettleseren, kjøre distribusjonsprosessen en gang til og bekrefte at den skjer sømløst ved å oppdatere siden kontinuerlig under distribusjonen.

Husk å rydde opp etter deg :3

$ docker rm -f uptimer_GREEN reverse-proxy 
uptimer_GREEN
reverse-proxy

$ docker network rm web-gateway 
web-gateway

$ cd ..

$ rm -r blue-green-deployment

Kilde: habr.com