最低賃金でのブルーグリーン雇用

この記事で使用するのは、 bash, ssh, ドッカー и nginx Webアプリケーションのシームレスなレイアウトを整理します。 ブルーグリーン展開 は、リクエストを XNUMX つも拒否せずにアプリケーションを即座に更新できるようにする技術です。 これは、ダウンタイムゼロのデプロイメント戦略の XNUMX つであり、インスタンスが XNUMX つあるものの、すぐに実行できる XNUMX 番目のインスタンスを近くにロードできるアプリケーションに最適です。

多くのクライアントがアクティブに動作している Web アプリケーションがあり、それが数秒間停止することは絶対にありえないとします。 そして、ライブラリの更新、バグ修正、または新しい優れた機能を実際に展開する必要があります。 通常の状況では、アプリケーションを停止し、置き換えて、再度起動する必要があります。 docker の場合、最初に置き換えてから再起動できますが、通常、アプリケーションの最初のロードには時間がかかるため、アプリケーションへのリクエストが処理されない期間が残ります。 起動はしたものの、動作不能になった場合はどうなりますか? これが問題です。最小限の手段で、できるだけエレガントに解決しましょう。

免責事項: 記事の大部分は実験的な形式、つまりコンソール セッションの記録の形式で提供されています。 これが理解するのがそれほど難しくなく、コード自体が十分に文書化されることを願っています。 雰囲気として、これらが単なるコードの断片ではなく、「鉄の」テレタイプの紙であると想像してください。

コードを読むだけではググるのが難しい興味深いテクニックが各セクションの冒頭で説明されています。 他に不明な点がある場合は、Google で調べてください。 説明シェル (幸いなことに、電報のブロックが解除されたため、再び機能します)。 Google で検索できない場合は、コメントで質問してください。 対応するセクション「興味深いテクニック」に追加させていただきます。

始めましょう

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

サービス

実験的なサービスを作成してコンテナに配置してみましょう。

興味深いテクニック

• cat << EOF > file-name (ヒアドキュメント + I / Oリダイレクト) は、XNUMX つのコマンドで複数行のファイルを作成する方法です。 bash が読み取るすべてのもの /dev/stdin この行の後とこの行の前 EOF に記録されます file-name.
• wget -qO- URL (説明シェル) - HTTP 経由で受信したドキュメントを出力します。 /dev/stdout （アナログ curl URL).

印刷する

特にスニペットを分割して、Python の強調表示を有効にします。 最後にはこんな作品も登場します。 これらの場所では、ハイライト部門に送るために紙がカットされ (コードがハイライターで手で色付けされます)、その後これらの部分が貼り付けられたと考えてください。

$ cat << EOF > uptimer.py

from http.server import 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} is running for {t:3.1f} seconds.</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} (loads in {loading_seconds} sec.) started.')
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 (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 is running for 15.4 seconds.</h2>

$ docker rm --force uptimer
uptimer

リバースプロキシ

アプリケーションが気づかれないように変更できるようにするには、アプリケーションの前に、その置き換えを隠す別のエンティティが存在する必要があります。 Webサーバーである可能性があります nginx в リバースプロキシモード。 リバース プロキシは、クライアントとアプリケーションの間に確立されます。 クライアントからのリクエストを受け入れてアプリケーションに転送し、アプリケーションの応答をクライアントに転送します。

アプリケーションとリバース プロキシは、次を使用して Docker 内でリンクできます。 Dockerネットワーク。 したがって、アプリケーションを含むコンテナはホスト システム上のポートを転送する必要さえなく、これによりアプリケーションを外部の脅威から最大限に隔離することができます。

リバース プロキシが別のホスト上に存在する場合は、Docker ネットワークを放棄し、ホスト ネットワーク経由でアプリケーションをリバース プロキシに接続し、ポートを転送する必要があります。 アプリケーション パラメータ --publish、最初の起動時とリバース プロキシの場合と同様です。

リバース プロキシをポート 80 で実行します。これは、まさに外部ネットワークをリッスンする必要があるエンティティであるためです。 テスト ホストでポート 80 が使用中の場合は、パラメータを変更します。 --publish 80:80 на --publish ANY_FREE_PORT:80.

興味深いテクニック

• 「ユーザーが作成した Docker ネットワークでは、IP アドレスだけでなくコンテナと通信できます。 コンテナ名もその IP アドレスに解決されます。" (記事「スタンドアロン コンテナを使用したネットワーク」、パート「ユーザー定義のブリッジ ネットワークの使用」、docker コードのポイント 5)。

印刷する

$ 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 is running for 11.5 seconds.</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->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 is running for 104.1 seconds.</h2>

シームレスな展開

アプリケーションの新しいバージョン (起動パフォーマンスが XNUMX 倍向上) をロールアウトし、シームレスに展開してみましょう。

興味深いテクニック

• echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt' — テキストを書く my text ファイルへ /my-file.txt コンテナの中 my-container.
• cat > /my-file.txt — 標準入力の内容をファイルに書き出す /dev/stdin.

印刷する

$ 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
 ---> 8ecf5a48c789
Step 2/4 : EXPOSE 8080
 ---> Using cache
 ---> cf92d174c9d3
Step 3/4 : COPY uptimer.py app.py
 ---> 3eca6a51cb2d
Step 4/4 : CMD [ "python", "-u", "./app.py" ]
 ---> Running in 8f13c6d3d9e7
Removing intermediate container 8f13c6d3d9e7
 ---> 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 is running for 23.9 seconds.</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: signal process started

$ wget -qO- http://localhost
<h2>Uptimer v2.0 is running for 63.4 seconds.</h2>

$ docker rm -f uptimer
uptimer

$ wget -qO- http://localhost
<h2>Uptimer v2.0 is running for 84.8 seconds.</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->80/tcp   reverse-proxy

この段階では、イメージはサーバー上に直接構築されるため、アプリケーション ソースがそこに存在する必要があり、サーバーに不必要な作業の負荷もかかります。 次のステップでは、イメージ アセンブリを別のマシン (CI システムなど) に割り当て、サーバーに転送します。

画像を転送する

残念ながら、ローカルホストからローカルホストにイメージを転送することは意味がありません。そのため、このセクションは、Docker を備えた XNUMX つのホストがある場合にのみ検討できます。 少なくとも次のようになります。

$ 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

チーム docker save 画像データは .tar アーカイブに保存されます。つまり、圧縮形式での重量よりも約 1.5 倍の重量になります。 時間とトラフィックを節約するという名目で、これを実行しましょう。

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

ダウンロード プロセスを監視することもできます (ただし、これにはサードパーティのユーティリティが必要です)。

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

ヒント: SSH 経由でサーバーに接続するために多数のパラメータが必要な場合は、ファイルを使用していない可能性があります。 ~/.ssh/config.

画像を転送する docker image save/load - これは最もシンプルな方法ですが、唯一の方法ではありません。 他にもあります:

1. コンテナ レジストリ (業界標準)。
2. 別のホストから Docker デーモン サーバーに接続します。
   1. 環境変数 DOCKER_HOST.
   2. コマンドラインオプション -H または --host 計器 docker-compose.
   3. docker context

XNUMX 番目の方法 (実装には XNUMX つのオプションがあります) については、記事で詳しく説明されています。 docker-compose を使用してリモート Docker ホストにデプロイする方法.

deploy.sh

次に、手動で行ったすべての作業を XNUMX つのスクリプトにまとめてみましょう。 トップレベルの関数から始めて、次にその中で使用されている他の関数を見てみましょう。

興味深いテクニック

• ${parameter?err_msg} - バッシュ魔法の呪文の XNUMX つ (別名) パラメータ置換）。 もし parameter 指定されていない、出力 err_msg コード 1 で終了します。
• docker --log-driver journald — デフォルトでは、docker ロギング ドライバーはローテーションのないテキスト ファイルです。 このアプローチでは、ログがすぐにディスク全体をいっぱいにしてしまうため、運用環境ではドライバーをより高性能なものに変更する必要があります。

デプロイメントスクリプト

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
}

使用される機能:

• ensure-reverse-proxy — リバース プロキシが動作していることを確認します (最初の展開に役立ちます)
• get-active-slot service_name — 特定のサービスに対してどのスロットが現在アクティブであるかを決定します (BLUE または GREEN)
• get-service-status service_name deployment_slot — サービスが受信リクエストを処理する準備ができているかどうかを判断します
• set-active-slot service_name deployment_slot — リバースプロキシコンテナのnginx設定を変更します

ためには：

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
}

機能 get-active-slot 少し説明が必要です:

文字列を出力せずに数値を返すのはなぜですか?

とにかく、呼び出した関数でその作業の結果をチェックします。bash を使用して終了コードをチェックする方が、文字列をチェックするよりもはるかに簡単です。 さらに、そこから文字列を取得することも非常に簡単です。
get-active-slot service && echo BLUE || echo GREEN.

すべての状態を区別するには、本当に XNUMX つの条件で十分なのでしょうか?

XNUMX つでも十分です。最後の XNUMX つは完全を期すためだけにここにあります。 else.

nginx 構成を返す関数のみが未定義のままです。 get-nginx-config service_name deployment_slot。 ヘルスチェックと同様に、ここでは任意のサービスの任意の構成を設定できます。 興味深いもののうち - だけ cat <<- EOFを使用すると、最初のすべてのタブを削除できます。 確かに、適切な書式設定の代償としてタブとスペースが混在することになりますが、これは今日では非常に悪い形式と考えられています。 ただし、bash ではタブが強制されるため、nginx 設定で通常の書式設定を行うこともできます。 つまり、ここでタブとスペースを組み合わせることが、最悪の解決策のうちの最良の解決策のように思えます。 ただし、以下のスニペットではこれは見られません。これは、Habr がすべてのタブを 4 つのスペースに変更し、EOF を無効にすることで「うまく機能」しているためです。 そしてここで注目です.

二度起きないように今すぐ教えます cat << 'EOF'、これは後で遭遇します。 簡単に書くと cat << EOF、ヒアドキュメント内で文字列が補間されます (変数は展開されます ($foo)、コマンド呼び出し($(bar)) など)、ドキュメントの末尾を一重引用符で囲むと、補間が無効になり、シンボルが $ そのまま表示されます。 別のスクリプト内にスクリプトを挿入するために必要なもの。

get-nginx-config() {
    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

    local container_name=${service}_${slot}
    case $service in
        # Add specific nginx configs for your services here
        *) nginx-config-simple-service $container_name:8080 ;;
    esac
}

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

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

これがスクリプト全体です。 など このスクリプトの要点 wget またはcurl経由でダウンロードする場合。

リモートサーバー上でパラメータ化されたスクリプトを実行する

ターゲットサーバーをノックオンします。 この時 localhost 非常に適しています:

$ ssh-copy-id localhost
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
himura@localhost's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'localhost'"
and check to make sure that only the key(s) you wanted were added.

事前に構築されたイメージをターゲット サーバーにダウンロードし、サービス コンテナをシームレスに置き換えるデプロイメント スクリプトを作成しましたが、それをリモート マシンで実行するにはどうすればよいでしょうか? このスクリプトはユニバーサルであり、XNUMX つのリバース プロキシの下で一度に複数のサービスをデプロイできるため、スクリプトには引数があります (nginx 構成を使用して、どの URL がどのサービスになるかを決定できます)。 スクリプトをサーバーに保存することはできません。この場合、(バグ修正や新しいサービスの追加の目的で) スクリプトを自動的に更新することができず、一般に状態 = 悪となるためです。

解決策 1: スクリプトは引き続きサーバーに保存しますが、毎回コピーします。 scp。 次に、経由で接続します ssh 必要な引数を指定してスクリプトを実行します。

短所：

• XNUMX つのアクションではなく XNUMX つのアクション
• コピーする場所がなかったり、アクセスできなかったり、置換時にスクリプトが実行されたりする可能性があります。
• 自分でクリーンアップする (スクリプトを削除する) ことをお勧めします。
• すでにアクションがXNUMXつあります。

解決策2：解決策XNUMX：

• スクリプト内に関数定義のみを保持し、何も実行しない
• ととも​​に sed 関数呼び出しを最後に追加します
• すべてをパイプ経由で shh に直接送信します (|)

長所：

• まさに無国籍
• 定型エンティティはありません
• クールな気分

Ansible を使わずにやってみましょう。 そう、すべてはすでに発明されているのです。 そう、自転車です。 このバイクがいかにシンプルで、エレガントで、ミニマルであるかを見てください。

$ cat << 'EOF' > 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! The 'deploy' function is executing on 'hut' with argument 'magic-porridge-pot'

ただし、リモート ホストに適切な bash があるかどうかは確認できないため、最初に小さなチェックを追加します (これは、 シェルバン):

if [ "$SHELL" != "/bin/bash" ]
then
    echo "The '$SHELL' shell is not supported by 'deploy.sh'. Set a '/bin/bash' shell for '$USER@$HOSTNAME'."
    exit 1
fi

そして今、それは現実です:

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

これで開くことができます http://localhost/ ブラウザで展開を再度実行し、レイアウト中に CD に従ってページを更新することでシームレスに実行されることを確認します。

仕事の後は片づけを忘れずに :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

出所： habr.com