ProHoster > Blog > Administrimi > Blue-Green Deployment në nivel minimal

Blue-Green Deployment në nivel minimal

Në këtë artikull, ne do bash, ssh, docker dhe nginx organizojmë një publikim pa ndërprerje të aplikacionit web. Publikimi blue-green është një teknikë që lejon përditësimin e aplikacionit në mënyrë të menjëhershme, pa ndaluar asnjë kërkesë. Ajo është një prej strategjive të publikimit pa kohë ndalesë dhe përshtatet më së miri për aplikacionet me një instancë, por me mundësinë e ngarkimit të një instancë të dytë, gati për punë.

Supozoni se keni një aplikacion web, me të cilin punojnë aktive shumë klientë, dhe nuk mund të ndalet as për pak sekonda. Dhe ju duhet të publikoni një përditësim të bibliotekës, një korrigjim gabimi ose një veçori të re emocionuese. Në situatën normale, do të duhet të ndaloni aplikacionin, ta zëvendësoni dhe ta filloni sërish. Në rastin e Docker, mund ta zëvendësoni së pari, pastaj ta ribllokoni, por gjithsesi do të ketë një periudhë, në të cilën kërkesat për aplikacionin nuk do të përpunohen, pasi zakonisht aplikacionit i nevojitet një farë kohe për ngarkimin fillestar. Dhe nëse ai starton, por doli të jetë i papërshtatshëm? Kjo është një detyrë, le të zgjidhim atë me mjete minimale dhe maksimalisht elegante.

DISCLAIMER: Pjesa mĂ« e madhe e artikullit Ă«shtĂ« e paraqitur nĂ« njĂ« format eksperimental — si njĂ« seancĂ« konsolĂ« e regjistruar. Shpresoj qĂ« kjo tĂ« mos jetĂ« shumĂ« e vĂ«shtirĂ« pĂ«r t'u kuptuar, dhe ky kod e dokumenton veten nĂ« njĂ« masĂ« tĂ« mjaftueshme. PĂ«r atmosferĂ«n, imagjinoni se kĂ«to nuk janĂ« thjesht kodsnipete, por letĂ«r nga telegrafi 'metalik'.

Blue-Green Deployment në nivel minimal

Teknika interesante, tĂ« cilat janĂ« tĂ« vĂ«shtira pĂ«r t'u gjetur thjesht duke lexuar kodin, janĂ« pĂ«rshkruar nĂ« fillim tĂ« çdo seksioni. NĂ«se ndonjĂ« gjĂ« nuk kuptohet, kĂ«rkoni nĂ« explainshell (fatmirĂ«sisht, ai po funksionon sĂ«rish, pĂ«r shkak tĂ« zhbllokimit tĂ« Telegramit). ÇfarĂ« nuk gjen dot — pyetni nĂ« komente. E gĂ«zoj tĂ« plotĂ«soj seksionin pĂ«rkatĂ«s 'Teknika interesante'.

Le të fillojmë.

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

Shërbimi

Le të krijojmë një shërbim për prova dhe ta vendosim në një konteiner.

Teknika interesante

  • cat < file-name (Dokument i BrendshĂ«m + ShkĂ«putja e I/O) — njĂ« mĂ«nyrĂ« pĂ«r tĂ« krijuar njĂ« skedĂ« shumĂ« rreshtash me njĂ« komandĂ«. Çdo gjĂ« qĂ« bash do tĂ« lexojĂ« nga /dev/stdin pas kĂ«saj rreshti dhe deri nĂ« rreshtin EOF do tĂ« shkruhet nĂ« file-name.
  • wget -qO- URL (explainshell) — pĂ«r tĂ« shfaqur dokumentin e marrĂ« pĂ«rmes HTTP nĂ« /dev/stdout (analog curl URL).

Shkarkimi

Unë e ndaj veçorin, që të përfshihet theksimi për Python. Në fund do të ketë edhe një copë të tillë. Më konsideroni se në këto raste letra është prerë për t'u kaluar në departamentin e theksimit (ku kodi ishte ngjyrosur me dorë me penka), dhe pastaj këto copa u ngjitën përsëri.

$ cat < uptimer.py
nga http.server importo BaseHTTPRequestHandler, HTTPServer
nga kohë importo monotonic

versioni_aplikacionit = 1
emri_aplikacionit = f'Uptimer v{versioni_aplikacionit}.0'
loading_seconds = 15 - versioni_aplikacionit * 5

klasa Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == '/':
            përpiqu:
                t = monotonic() - server_start
                if t &lt; loading_seconds:
                    self.send_error(503)
                else:
                    self.send_response(200)
                    self.send_header(&#039;Content-Type&#039;, &#039;text/html&#039;)
                    self.end_headers()
                    përgjigje = f&#039;<h2>{emri_aplikacionit} po funksionon për {t:3.1f} sekonda.</h2>n'
                    self.wfile.write(përgjigje.encode('utf-8'))
            përjashtim tjetër:
                self.send_error(500)
        else:
            self.send_error(404)

httpd = HTTPServer(('', 8080), Handler)
server_start = monotonic()
print(f'{emri_aplikacionit} (ngarkon në {loading_seconds} sek.) është nisur.')
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 (ngarko në 10 sek.) u nis.

$ wget -qSO- http://localhost:8080
  HTTP/1.0 503 Shërbimi i Pa Disponueshëm
  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 po funksionon për 15.4 sekonda.</h2>

$ docker rm --force uptimer
uptimer

Proxy-a për rikthim

Për të gjithë aplikacionin tonë të ketë mundësinë të ndryshojë pa u vënë re, është e nevojshme që para tij të ketë një entitet tjetër, i cili do ta fshehë zëvendësimin e tij. Kjo mund të jetë një server web nginx në në modin e rikthimit të proxy-it.Proxy-i i rikthimit vendoset midis klientit dhe aplikacionit. Ai merr kërkesat nga klientët dhe i drejton ato në aplikacion, ndërsa përgjigjet e aplikacionit i dërgon klientëve.

Aplikacioni dhe proxy-i i rikthimit mund të lidhen brenda Dockerit përmes docker network.Kështu, kontejnerit me aplikacionin nuk i nevojitet të hapëport në sistemin e host-it, kjo lejon maksimalisht ti izolojë aplikacionin nga kërcënimet nga jashtë.

Nëse proxy-i i rikthimit do të jetojë në një host tjetër, do t'ju duhet të hiqni dorë nga docker network dhe të lidhni aplikacionin me proxy-in e rikthimit përmes rrjetit të host-it, duke publikuar portin aplikacione parametrin --publish, siç është në fillimin e parë dhe si te proxy-i i rikthimit.

Ne do të ekzekutojmë proxy-in e rikthimit në portin 80, sepse kjo është entiteti që duhet të dëgjojë nga jashtë. Nëse porta 80 në host-in tuaj të provës është e zënë, ndryshoni parametrin --publish 80:80 në --publish ANY_FREE_PORT:80.

Teknika interesante

Shkarkimi

$ 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 po punon për 11.5 sekonda.</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 po punon për 104.1 sekonda.</h2>

Publikimi pa ndërprerje

Do ta publikojmë një version të ri të aplikacionit (me një rritje të dyfish të performancës së fillimit) dhe do të përpiqemi ta publikojmë pa ndërprerje.

Teknika interesante

  • echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt' — Shkruani tekstin my text nĂ« skedarin /my-file.txt brenda kontejnerit my-container.
  • cat > /my-file.txt — Shkruani nĂ« skedĂ« pĂ«rmbajtjen e hyrjes standarde. /dev/stdin.

Shkarkimi

$ 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 (loads in 5 sec.) started.

$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer_BLUE:8080
<h2>Uptimer v2.0 është duke funksionuar për 23.9 sekonda.</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 është duke funksionuar për 63.4 sekonda.</h2>

$ docker rm -f uptimer
uptimer

$ wget -qO- http://localhost
<h2>Uptimer v2.0 është duke funksionuar për 84.8 sekonda.</h2>

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                NAMES
96932d4ca97a        uptimer             "python -u ./app.py"     About a minute ago   Up About a minute   8080/tcp             uptimer_BLUE
80695a822c19        nginx:alpine        "/docker-entrypoint.…"   8 minutes ago        Up 8 minutes        0.0.0.0:80-&gt;80/tcp   reverse-proxy

Në këtë fazë, imazhi po ndërtohet direkt në server, që kërkon që të ketë burimet e aplikacionit atje, si dhe ngarkon serverin me punë të panevojshme. Hapi tjetër do të jetë ndarja e ndërtimit të imazhit në një makinë të veçantë (p.sh., në sistemin CI) me kalimin e mëvonshëm në server.

Kopjimi i imazheve

Fatkeqësisht, kopjimi i imazheve nga localhost në localhost nuk ka kuptim, kështu që ky seksion mund të provoni vetëm duke pasur dy hoste me Docker. Në minimum, kjo duket pak si kështu:

$ 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

Ekipa docker save ruan të dhënat e imazhit në arkiv .tar, pra ai ka një peshë prej rreth 1.5 herë më shumë se sa mund të peshojë në format të kompresuar. Prandaj le të kompresojmë atë në emër të kursimit të kohës dhe trafikut:

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

Dhe gjithashtu, mund të vëzhgoni procesin e transferimit (nuk bie në këtë rast që është e nevojshme një utilitar i tretë):

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

Këshillë: Nëse ju nevojiten shumë parametra për t'u lidhur me serverin përmes SSH, ndoshta nuk jeni duke përdorur skedarin ~/ .ssh / config.

Transferimi i imazhit pĂ«rmes docker image save / load – Ă«shtĂ« metoda mĂ« minimale, por jo e vetmja. Ka edhe tĂ« tjera:

  1. Container Registry (standardi i industrisë).
  2. Lidhuni me docker daemon-in e serverit nga një host tjetër:
    1. Variabla e ambientit DOCKER_HOST.
    2. Parametri i komandës -H ose --host instrumenti docker-compose.
    3. docker context

Mënyra e dytë (me tre variante të realizimit të saj) është përshkruar mirë në artikullin How to deploy on remote Docker hosts with docker-compose.

deploy.sh

Tani le të mblidhnim gjithçka që kemi bërë manualisht në një skenar. Të fillojmë me funksionin kryesor, pastaj të shikojmë mbi të tjerët që e përdorin atë.

Teknika interesante

  • ${parameter?err_msg} – njĂ« nga magjitĂ« bash (aka zĂ«vendĂ«simi i parametrave). NĂ«se parametri nuk Ă«shtĂ« i specifikuar, shfaq err_msg dhe dal me kodin 1.
  • docker --log-driver journald – me parazgjedhje, drejtuesi i regjistrimit tĂ« docker-it Ă«shtĂ« njĂ« skedar tekstual pa ndonjĂ« rotacion. Me kĂ«tĂ« qasje, logjet shpejt mbushin tĂ« gjithĂ« diskun, prandaj pĂ«r ambientin production Ă«shtĂ« e nevojshme tĂ« ndryshoni drejtuesin nĂ« njĂ« mĂ« tĂ« zgjuar.

Skenari i deponimit

deploy() {
    local usage_msg="PĂ«rdorimi: ${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 "Duke e vendosur '$NEW' në vend të '$OLD'..."
    docker run 
        --detach 
        --restart always 
        --log-driver journald 
        --name $NEW 
        --network web-gateway 
        $image_name || return 3
    echo "Kontejneri u nis. Kontrollimi i shëndetit..."
    for i in {1..20}
    do
        sleep 1
        if get-service-status $image_name $new_slot
        then
            echo "Shërbimi i ri '$NEW' duket si në rregull. Ndërrimi i kokave..."
            sleep 2  # Sigurohuni që shërbimi është gati
            set-active-slot $image_name $new_slot || return 4
            echo "Shërbimi '$NEW' është aktiv!"
            sleep 2  # Sigurohuni që të gjitha kërkesat janë procesuar
            echo "Duke e ndaluar '$OLD'..."
            docker rm -f $OLD
            docker image prune -f
            echo "Vendosja e realizuar me sukses!"
            return 0
        fi
        echo "Shërbimi i ri '$NEW' nuk është gati ende. Duke pritur ($i)..."
    done
    echo "Shërbimi i ri '$NEW' nuk është ngritur, duke e ndaluar. Dështoi të vendoset T_T"
    docker rm -f $NEW
    return 5
}

Funksionet e përdorura:

  • ensure-reverse-proxy – Sigurohet qĂ« reverse-proxy nuk funksionon (e dobishme pĂ«r deponimin e parĂ«)
  • get-active-slot service_name – PĂ«rcakton se cili slot Ă«shtĂ« aktualisht aktiv pĂ«r shĂ«rbimin e dhĂ«nĂ« (BLUE ose GREEN)
  • get-service-status service_name deployment_slot – PĂ«rcakton nĂ«se shĂ«rbimi Ă«shtĂ« gati pĂ«r tĂ« trajtuar kĂ«rkesat e ardhshme
  • set-active-slot service_name deployment_slot – Ndryshon konfigurimin e nginx nĂ« konteinerin reverse-proxy

Radhazi:

ensure-reverse-proxy() {
    is-container-up reverse-proxy && return 0
    echo "Duke vendosur 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?"PĂ«rdorimi: ${FUNCNAME[0]} container_name"}

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

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

    if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then
        echo "Kolizion e zbuluar! Duke e ndaluar ${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="PĂ«rdorimi: ${FUNCNAME[0]} service_name deployment_slot"
    local service=${1?usage_msg}
    local slot=${2?$usage_msg}

    case $service in
        # Shtoni rrugët specifike të kontrollit shëndetësor për shërbimet tuaja këtu
        *) local health_check_port_path=":8080/" ;;
    esac
    local health_check_address="http://${service}_${slot}${health_check_port_path}"
    echo "Duke kërkuar '$health_check_address' brenda rrjetit 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="PĂ«rdorimi: ${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
}

Funksioni get-active-slot ka nevojë për disa sqarime:

Përse ajo ktheu një numër dhe jo një varg?

Sidoqoftë, në funksionin që e thërret ne kontrollojmë rezultatin e punës së saj, dhe të kontrollosh kodin exit me mjete bash është shumë më e lehtë sesa vargu. Për më tepër, është shumë e lehtë të marrësh një varg prej saj:
get-active-slot service && echo BLUE || echo GREEN.

Dhe a ka mjaft kushte për të dalluar të gjitha gjendjet?

Blue-Green Deployment në nivel minimal

Një çift është mjaft, e fundit është këtu thjesht për plotësi, për të mos shkruar else.

Pika e vetme e paqartĂ« mbetet funksioni qĂ« kthen konfigurimet e nginx: get-nginx-config service_name deployment_slot. Siç Ă«shtĂ« mĂ«suar me health check, kĂ«tu mund tĂ« vendosni çdo konfigurim pĂ«r çdo shĂ«rbim. Nga e veçanta — vetĂ«m cat <<- EOF, qĂ« lejon heqjen e tĂ« gjitha tab-eve nĂ« fillim. MegjithatĂ«, çmimi i formatimit tĂ« shkĂ«lqyer — tab-tĂ« e pĂ«rziera me hapĂ«sira, qĂ« sot konsiderohet njĂ« shenjĂ« shumĂ« e keqe. Por bash e detyron pĂ«rdorimin e tab-eve, dhe gjithashtu do tĂ« ishte mirĂ« qĂ« nĂ« konfigurimin e nginx tĂ« kishte njĂ« formatim tĂ« mirĂ«. Pra, kĂ«tu, pĂ«rzierja e tab-eve me hapĂ«sira duket se Ă«shtĂ« zgjidhja mĂ« e mirĂ« nga zgjidhjet mĂ« tĂ« kĂ«qija. MegjithatĂ«, nĂ« snippet-in mĂ« poshtĂ« nuk do ta shihni kĂ«tĂ«, pasi Habra «bĂ«n mirë», duke e ndĂ«rruar tĂ« gjitha tab-et me 4 hapĂ«sira dhe duke e bĂ«rĂ« EOF-in tĂ« pavlefshĂ«m. E kĂ«tu Ă«shtĂ« e dukshme.

Për të mos e bërë dy herë, do të flas menjëherë për cat << 'EOF', që do të takoni më vonë. Nëse shkruani thjesht cat << EOF, brenda heredoc bëhet interpolimi i stringut (variablat zbulohen ($foo), thirrjet e komandave ($(bar)) etj.), dhe nëse e mbyllni shenjën e fundit të dokumentit me thonjza të vetme, atëherë interpolimi çaktivizohet dhe simboli $ shfaqet siç është. Kjo është e nevojshme për të futur një skript brenda një skripti tjetër.

get-nginx-config() {
    local usage_msg="PĂ«rdorimi: ${FUNCNAME[0]} service_name deployment_slot"
    local service=${1?$usage_msg}
    local slot=${2?$usage_msg}
    [ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1

    local container_name=${service}_${slot}
    case $service in
        # Shtoni konfigurimet e veçanta të nginx për shërbimet tuaja këtu
        *) nginx-config-simple-service $container_name:8080 ;;
    esac
}

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

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

Ky është gjithsej skripti. Dhe tani gist me këtë skript për ta shkarkuar përmes wget ose curl.

Ekzekutimi i skripteve parametrizuara në një server të largët

Ka ardhur koha për t'u lidhur me serverin e synuar. Këtë herë localhost është plotësisht e përshtatshme:

$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: përpiqet të hyjë me çelësin(e) e reja, për të filtruara çdo që tashmë është instaluar
/usr/bin/ssh-copy-id: INFO: 1 çelësi(m) mbetet për t'u instaluar - nëse ju kërkohet tani është për të instaluar çelësat e rinj
himura@localhost's password: 

Numri i çelësave(e) shtuar: 1

Tani provoni të hyni në makinën, me:   "ssh 'localhost'"
dhe kontrolloni për të parë nëse vetëm çelësat e dëshiruara janë shtuar.

Kemi shkruar një skript implementimi, i cili transferon imazhin e përgatitur më parë në serverin e synuar dhe ndërron pa probleme kontejnerin e shërbimit, por si ta ekzekutojmë atë në makinën e largët? Skripti ka argumente, pasi është universale dhe mund të implementojë disa shërbime nën një reverse-proxy (konfiguratat e nginx mund të rregullojnë se për cilin url do të jetë shërbimi). Skripti nuk mund të ruhet në server, pasi në këtë rast nuk mund ta përditësojmë automatikisht (për qëllime korrigjimi të gabimeve dhe shtimin e shërbimeve të reja), dhe gjithashtu, state = e keqe.

Zgjidhja 1: Të mbani skriptin në server, por ta kopjoni atë çdo herë nëpërmjet scp. Pastaj lidhuni përmes ssh dhe ekzekutoni skriptin me argumentet e nevojshme.

Disavantazhet:

  • Dy veprime nĂ« vend tĂ« njĂ«
  • Vendet ku e kopjoni mund tĂ« mos jenĂ«, ose tĂ« mos keni akses, ose skripti mund tĂ« ekzekutohet nĂ« momentin e ndĂ«rrimit.
  • Preferohet tĂ« pastroni pas vetes (tĂ« fshini skriptin).
  • Tani janĂ« tri veprime.

Zgjidhja 2:

  • NĂ« skript mbani vetĂ«m pĂ«rkufizimet e funksioneve dhe asgjĂ« tĂ« ekzekutuar
  • Me sed shtoni nĂ« fund thirrjen e funksionit
  • DĂ«rgoni gjithçka direkt nĂ« shh pĂ«rmes pipĂ«s (|)

Përparësitë:

  • ShtetĂ«sia vĂ«rtetĂ«
  • Nuk ka entitete boilerplate
  • Ndiheni cool

Tani le letë pa Ansible. Po, gjithçka është marrë parasysh. Po, biçikleta. Shikoni, sa e thjeshtë, elegante dhe minimaliste është kjo biçikletë:

$ 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
Duke u lidhur me localhost...
Yay! Funksioni 'deploy' po ekzekutohet në 'hut' me argumentin 'magic-porridge-pot'

Megjithatë, nuk mund të jemi të sigurt se në hostin e largët ka një bash adekuat, kështu që do të shtojmë në fillim një kontroll të vogël (kjo është në vend të shellbang):

if [ "$SHELL" != "/bin/bash" ]
then
    echo "Shëmbuj '$SHELL' nuk mbështetet nga 'deploy.sh'. Vendosni një shell '/bin/bash' për '$USER@$HOSTNAME'."
    exit 1
fi

Dhe tani, gjithçka siç duhet:

$ 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
Dërgimi i imazhit gzipped 'uptimer' në 'localhost' përmes ssh...
Imazhi i ngarkuar: uptimer:latest
Duke u lidhur me 'localhost' përmes ssh për të implementuar pa probleme 'uptimer'...
Implementimi i 'uptimer_GREEN' në vend të 'uptimer_BLUE'...
06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18a
Kontejneri u nis. Kontrollimi i shëndetit...
Duke kërkuar 'http://uptimer_GREEN:8080/' brenda rrjetit docker 'web-gateway':
  HTTP/1.0 503 Shërbimi i Pa Disponueshëm
wget: serveri u kthye me gabim: HTTP/1.0 503 Shërbimi i Pa Disponueshëm
Shërbimi i ri 'uptimer_GREEN' ende nuk është gati. Duke pritur (1)...
Duke kërkuar 'http://uptimer_GREEN:8080/' brenda rrjetit docker 'web-gateway':
  HTTP/1.0 503 Shërbimi i Pa Disponueshëm
wget: serveri u kthye me gabim: HTTP/1.0 503 Shërbimi i Pa Disponueshëm
Shërbimi i ri 'uptimer_GREEN' ende nuk është gati. Duke pritur (2)...
Duke kërkuar 'http://uptimer_GREEN:8080/' brenda rrjetit docker 'web-gateway':
  HTTP/1.0 200 OK
  Server: BaseHTTP/0.6 Python/3.8.3
  Data: Sat, 22 Aug 2020 20:15:50 GMT
  Content-Type: text/html

Shërbimi i ri 'uptimer_GREEN' duket OK. Duke ndërruar kokat...
nginx: skedari i konfigurimit /etc/nginx/nginx.conf sintaksa është në rregull
ginx: skedari i konfigurimit /etc/nginx/nginx.conf test është i suksesshëm
2020/08/22 20:15:54 [notice] 97#97: procesi i sinjalit filloi
Shërbimi 'uptimer_GREEN' është aktiv!
Duke vrarë 'uptimer_BLUE'...
uptimer_BLUE
Hapësira e rikuperuar totale: 0B
Implementimi i suksesshëm!

Tani mund tĂ« hapim http://localhost/ nĂ« shfletues, rindezni implementimin dhe sigurohuni qĂ« ai kalon pa ndjenja duke ridĂ«gjuar faqen me KД gjatĂ« lançimit.

Mos harroni të pastroni pas punës :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

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster