序章

最近の開発慣行では、ソフトウェアの展開とリリースを区別することがよくあります。 展開は、サーバーに新しいコードを取得することを含むステップです。 リリースは、新しいコードが本番トラフィックの受信を開始するステップです。

青緑色の展開は、ソフトウェアを展開およびリリースするための戦略です。 議論を容易にするために、青と緑のニックネームが付けられた、2つの別々の本番環境に対応した環境を維持することに依存しています。 このガイドでは、DigitalOceanで青緑色の展開を使用して、ユーザーを新しいバージョンのソフトウェアに移行するプロセスを改善する方法について説明します。

前提条件

このガイドを完了するには、ホスト間でIPアドレスを移動できる環境に2台のUbuntu20.04サーバーをデプロイする必要があります。 DigitalOceanでは、予約済みIPがこの機能を提供できます。 これらのサーバーは、ステージングと本番環境に交互に使用される2つの並列環境を表します。 これらのサーバーは好きなように呼び出すことができますが、このガイドでは、これらのサーバーを「青」および「緑」と呼びます。

これらの各サーバーには、root以外のユーザーが必要です。 sudo 管理機能用に構成されています。 これらのユーザーは、Ubuntu20.04初期サーバーセットアップガイドに従って構成できます。

ブルーグリーン展開とは何ですか？

マーティンファウラーのこの投稿で普及した手法であるブルーグリーン展開の背後にある基本概念は、それぞれが本番環境でアプリケーションを提供できる2セットの環境を維持することです。 これらの2つの環境はほぼ同じである必要があります。 慣例により、これらは青および緑の環境と呼ばれます。

これらの環境の1つだけがアクティブであり、一度に実稼働トラフィックを受信します。 これらの環境（Webサーバーまたはロードバランサー）のWebエンドポイントの前で、ルーターまたはその他のトラフィック転送メカニズムが、すべての本番トラフィックを現在アクティブな環境にプッシュします。

新しいリリースが計画されると、非アクティブな環境にデプロイされます。 青緑色の展開の場合、非アクティブな環境は最終的なステージング環境として機能します。 これは本番環境を非常に厳密に反映しており、変更をライブでプッシュすることを決定する前の最終テストに使用できます。

デプロイメントを内部でテストし、その堅牢性に自信を持ったら、ルーティングメカニズムを調整することで新しいバージョンをすばやくリリースできます。 基本的に、トラフィックディレクティングレイヤーでスイッチを切り替えて、すべての本番トラフィックが新しいソフトウェアバージョンに移動し始めるようにします。 以前にアクティブだった環境は非アクティブになり、以前のステージング環境は新しい実稼働環境になります。

この時点で、以前のソフトウェアバージョンはアクティブではありませんが、引き続きアクセスできます。 新しくアクティブになった展開で重大な問題が発生した場合は、ルーティングメカニズムを再度変更することで、以前のバージョンに戻すことができます。

ステップ1-ローカルアプリケーションの作成

この一般的な概念を示すために、2つのサーバー環境をセットアップします。 それぞれにWebサーバーがインストールされます。 この例では、Webサーバーは、ロードバランサー、複数のWebサーバー、およびバックエンドの分散データベースまたは複製データベースを含む可能性のあるアプリケーションスタック全体を表していることに注意してください。 このガイドでは、このリリースパターンを示すことができる最小の環境を表すWebサーバーを使用しています。

ローカルコンピュータで「アプリ」の開発を開始します。 実際には、これは index.html サーバーにデプロイできるページ。 各サーバーにgitpost receive hook を構成して、を発行してデプロイできるようにします。 git push. アプリケーションの初期バージョンを両方のサーバーにデプロイします。

このガイドでは、ルーティングメカニズムとしてDigitalOcean予約済みIPアドレスを使用します。 予約済みIPは、あるサーバーから別のサーバーにトラフィックを移動するためのメカニズムを提供します。 予約済みIPを作成し、それをグリーンサーバーにポイントして、これを最初の本番マシンとして設定します。

次に、アプリケーションを変更して、青いサーバーにデプロイします。 この時点では、本番トラフィックは変更されていないグリーンサーバーから引き続き提供されます。 次に、青いサーバーをテストして、展開が成功し、バグがないことを確認できます。 準備ができたら、予約済みIPアドレスを青いサーバーに再割り当てすることで、予約済みIPを新しいバージョンのコードに移動できます。

まず、「アプリケーション」を作成します。 上記のように、これは実際にはWebサーバーが表示できる単なるインデックスページです。 これにより、実際の開発のオーバーヘッドなしに、アプリのさまざまな「バージョン」を示すことができます。

ローカルシステム（または別のドロップレット）に、プラットフォームの推奨方法を使用してgitをインストールします。 ローカルマシンがUbuntuを実行している場合は、次のように入力してインストールできます。

  1. sudo apt update

  2. sudo apt install git

Mac、Windows、または別のLinux環境では、git がまだインストールされていない場合は、そのドキュメントに従ってインストールする必要があります。

コミットするには、いくつかの構成設定を設定する必要があります git リポジトリ。 次のように入力して、名前とメールアドレスを設定します。

  1. git config --global user.name "Your Name"

  2. git config --global user.email "[email protected]"

構成セットを使用して、新しいアプリケーションのディレクトリを作成し、そこに移動できます。

  1. mkdir ~/sample_app

  2. cd ~/sample_app

次のように入力して、アプリケーションディレクトリのgitリポジトリを初期化します。

  1. git init

次に、を作成します index.html アプリケーションを表すファイルを使用して nano またはお気に入りのテキストエディタ：

  1. nano index.html

内部では、アプリケーションのバージョン番号を指定するだけです。 このようにして、各サーバーにあるアプリのバージョンを確認できます。

〜/ sample_app / index.html
App v1

終了したら、ファイルを保存して閉じます。 使用している場合 nano、 押す Ctrl+X、プロンプトが表示されたら、 Y とEnter。

最後に、を追加できます index.html ファイルに git ステージング領域を入力してから、次のように入力してコミットします。

  1. git add .

  2. git commit -m "initializing repository with version 1"

ファイルがコミットされたら、ローカルマシンでのアプリケーション開発を一時的に停止し、青と緑のWebサーバーのセットアップに集中します。

ステップ2–青と緑のWebサーバーを構成する

次に、機能するWebサーバーを使用して緑と青の環境をセットアップする作業を行います。 このガイドではApacheを使用します。 でサーバーにログインします sudo 開始するユーザー。

注：このセクションの手順は、青と緑のサーバーの両方で完了する必要があります。

Apacheをインストールできます apt. ローカルパッケージインデックスを更新し、次のように入力してWebサーバーソフトウェアをインストールします。

  1. sudo apt update

  2. sudo apt install apache2

これにより、両方のWebサーバーにApacheがインストールされて起動します。

次に、「デプロイ」ユーザーを作成して構成する必要があります。 このユーザーはApacheのWebルートにアクセスでき、ベアを所有します git アプリをプッシュするリポジトリ。

作成する deploy 次のように入力してユーザーを入力します。

  1. sudo adduser --disabled-password deploy

これにより、パスワード認証が無効になっている新しいユーザーが作成されます。

この新しいユーザーに、ApacheのデフォルトのWebルートに対する所有権を付与します。 これはにあります /var/www/html. 次のように入力して、このディレクトリの所有権を変更します。

  1. sudo chown -R deploy:deploy /var/www/html

これは、ファイルをWebルートに移動することだけに依存する展開に必要なすべてです。

注：このガイドから逸脱していて、展開手順でroot権限が必要な場合は、パスワードなしで構成することをお勧めします。 sudo で使用するために必要なコマンドの特権 deploy アカウント。

これは、新しいものを作成することによって行うことができます sudoers 内のファイル /etc/sudoers.d ディレクトリ：

  1. sudo visudo -f /etc/sudoers.d/90-deployment

このファイル内に、展開中に実行する必要のあるコマンドを追加できます。 これらは次のように指定できます。

/etc/sudoers.d/90-デプロイメント
deploy ALL=(ALL) NOPASSWD: first_deployment_command, second_deployment_command, ...

終了したら、ファイルを保存して閉じます。 これにより、 deploy パスワードなしで必要なコマンドを正しく実行するためのユーザー。

ステップ3–グリーンおよびブルーのWebサーバーでのGitデプロイメントのセットアップ

Apacheがインストールされ、デプロイメントを実行するようにユーザーが構成されたので、ベアを構成できます。 git アプリケーションをプッシュするリポジトリ。 次に、 post-receive サーバーにプッシュすると、メインブランチの最新バージョンを自動的にデプロイするフック。

注：このセクションの手順は、青と緑のサーバーの両方で完了する必要があります。

インストールすることから始めます git 両方のサーバーで：

  1. sudo apt install git

次に、としてログインする必要があります deploy ユーザー。 私たちはそれを行うことができます sudo 次のように入力します。

  1. sudo su - deploy

私たちの中で deploy ユーザーのホームディレクトリで、ローカルコンピュータで行ったのと同じように、サンプルアプリケーション用のディレクトリを作成します。 作成後にディレクトリに移動します。

  1. mkdir ~/sample_app

  2. cd ~/sample_app

初期化します git ローカルシステムで行ったように、このディレクトリのリポジトリ。 ただし、サーバーには、 --bare オプション。 これにより、 git 作業ディレクトリのないリポジトリ。 代わりに、通常は .git ディレクトリはメインフォルダに配置されます：

  1. git init --bare

を設定します post-receive 次にフックします。 これは、変更後に変更を展開する単なるスクリプトです。 git push 発生します。 この導入戦略の詳細については、このガイドをご覧ください。 このスクリプトをに配置する必要があります hooks リポジトリのディレクトリ。 次のように入力して、ファイルを作成して開きます。

  1. nano hooks/post-receive

内部に、次の展開スクリプトを貼り付けます。 これは基本的に、上記のリンク先の記事で概説されているのと同じスクリプトです。 私たちは使用しています GIT_DIR 私たちを示す変数 git サーバー上のリポジトリ、 WORK_TREE Apacheドキュメントルートを指定する変数、および HOSTNAME 進行状況メッセージ用にサーバーのホスト名を取得します。 このスクリプトは、すべての変更を展開します main Webディレクトリに分岐します。 以下のスクリプトを変更する必要はありません。

/ home / deploy / sample_app / hooks / post-receive
#!/bin/bash

GIT_DIR=/home/deploy/sample_app
WORK_TREE=/var/www/html
HOSTNAME=$(hostname)

while read oldrev newrev ref
do
    if [[ $ref =~ .*/main$ ]];
    then
        echo "Main ref received.  Deploying main branch to $HOSTNAME..."
        git --work-tree=$WORK_TREE --git-dir=$GIT_DIR checkout -f
        echo "Git hooks deploy complete."
    else
        echo "Ref $ref successfully received.  Doing nothing: only the main branch may be deployed on this server."
    fi
done

このガイドから逸脱していて、より複雑な展開手順が必要な場合は、それらをに追加してください。 then 上記のスクリプトの句。 このセクションで昇格された特権を必要とするすべてのステップで、 sudo 指図。 また、を使用するすべてのコマンドを確認してください sudo ここに追加されます sudoers 最後のセクションの下部で指定されているファイル。

終了したら、ファイルを保存して閉じます。

の権限を変更します post-receive フックするように git 適切なタイミングで実行できます。

  1. chmod +x hooks/post-receive

ステップ4–BlueサーバーとGreenサーバーでのSSHキーアクセスの構成

次に、SSHキーを次のように構成します git パスワードの入力を求めずに、変更をWebサーバーにプッシュできます。

ローカルコンピューターまたは開発用コンピューターで、次のように入力して、SSHキーが既に構成されているかどうかを確認します。

  1. cat ~/.ssh/id_rsa.pub

すでにSSHキーペアを利用できる場合は、次のように表示されます。

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDilFdzkgBcSKdh6tx5pLf+HH6Pv7z7jRZ7cSo6lQvecWOOgGl/wHCVZWx1ULvrF7VgJpgugLwxYsFh3E39sm1+7zeAlRxhFrbWvATwpAEwh5m0+48LTmvXCnJ8/om+GfmAwplmzGk/DNs5trVeagG62Css0rypdoNuLrVdCVKUXGXbO6KnpOsBqoM2HvZKtQ8j1gx+1UUnvK9LYes+ZzC2XZZeBh2dGABe7HNnd8+6e1f2ZjPEKAEV2fPJGAGaAQOnzSKJkUt/B9PdKFbCjnnG1sT0kQoxMRIAiqfR7wa7PUQCM5Orm5S92OTNcnRr8bWVjN18bWCyXkpxxWbIvVU/ user@devel

コマンドが正しく実行された場合は、表示されているテキスト全体をコピーします。 これは次のセクションで使用します。 ここで安全にスキップできます。

ローカルマシンにSSHキーがない場合は、次のようなエラーが表示される可能性があります。

Output
cat: /home/user/.ssh/id_rsa.pub: No such file or directory

この場合、次のように入力して、新しい公開鍵と秘密鍵のペアを作成できます。

  1. ssh-keygen

すべてのプロンプトでEnterキーを押して、デフォルト値を受け入れます。 キーが作成されたら、 cat 新しい公開鍵を表示するコマンド：

  1. cat ~/.ssh/id_rsa.pub

今回は正しく実行されるはずです。 表示された行をコピーして、次のセクションで使用します。

緑と青のサーバーに戻ると、ローカルマシンまたは開発マシンのアカウントに接続を許可します deploy ユーザー。

あなたのように deploy ユーザー、作成する ~/.ssh ディレクトリ。 内部で、というファイルを開きます authorized_keys:

  1. mkdir ~/.ssh

  2. nano ~/.ssh/authorized_keys

このファイル内に、ローカルマシンからコピーした出力を貼り付けます。

〜/ .ssh / authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDilFdzkgBcSKdh6tx5pLf+HH6Pv7z7jRZ7cSo6lQvecWOOgGl/wHCVZWx1ULvrF7VgJpgugLwxYsFh3E39sm1+7zeAlRxhFrbWvATwpAEwh5m0+48LTmvXCnJ8/om+GfmAwplmzGk/DNs5trVeagG62Css0rypdoNuLrVdCVKUXGXbO6KnpOsBqoM2HvZKtQ8j1gx+1UUnvK9LYes+ZzC2XZZeBh2dGABe7HNnd8+6e1f2ZjPEKAEV2fPJGAGaAQOnzSKJkUt/B9PdKFbCjnnG1sT0kQoxMRIAiqfR7wa7PUQCM5Orm5S92OTNcnRr8bWVjN18bWCyXkpxxWbIvVU/ user@devel

終了したら、ファイルを保存して閉じます。

次に、SSHが作成したファイルを使用できるように、アクセス許可をロックダウンします。

  1. chmod 600 ~/.ssh/authorized_keys

  2. chmod 700 ~/.ssh

ステップ5–ローカル開発マシンでGitリモートを構成する

WebサーバーにSSHキーアクセスを構成し、各サーバーにアプリケーションディレクトリを設定したので、ローカルにリモートとして青と緑のサーバーを追加できます。 git アプリリポジトリ。

ローカルマシンで、アプリケーションディレクトリに戻ります。

  1. cd ~/sample_app

リモート参照を追加して、 git 緑と青のWebサーバーに変更をプッシュできます。

  1. git remote add blue deploy@blue_server_ip:sample_app

  2. git remote add green deploy@green_server_ip:sample_app

これで、アプリを両方のサーバーにプッシュできるようになります。 アプリケーションのバージョン1を両方のサーバーにプッシュしてテストしてみましょう。

  1. git push blue main

  2. git push green main

最初のデプロイで、各サーバーのキーフィンガープリントを受け入れる必要がある場合があります。 次のような出力が表示されます。

Output
The authenticity of host '111.111.111.111 (111.111.111.111)' can't be established.
ECDSA key fingerprint is 30:a1:2c:8b:ec:98:a3:3c:7f:4a:db:46:2b:96:b5:06.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '111.111.111.111' (ECDSA) to the list of known hosts.
Counting objects: 3, done.
Writing objects: 100% (3/3), 246 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Main ref received.  Deploying main branch to blue...
remote: Git hooks deploy complete.
To [email protected]:sample_app
 * [new branch]      main -> main

ご覧のとおり、「remote：」で始まる行には、 echo からのステートメント post-receive サーバーに接続します。 アプリを両方のサーバーにプッシュすることを忘れないでください。

アプリの初期デプロイがcurlで成功したことをテストできます。

  1. curl blue_server_ip

  2. curl green_server_ip

これらの呼び出しの両方について、応答は次のようになります。

Output
App v1

これは、展開スクリプトが正しく機能していることを示しています。

トラフィックをルーティングするための予約済みIPアドレスの設定

アプリケーションの初期バージョンがデプロイされたので、予約済みIPアドレスを作成し、それを最初に「グリーン」サーバーにポイントすることができます。

DigitalOceanコントロールパネルで、[ネットワーク]タブをクリックしてから、[予約済みIP]メニュー項目をクリックします。 表示されるメニューで、グリーンサーバーを選択し、[予約済みIPの割り当て]ボタンをクリックします。

数秒後、IPがグリーンサーバーに割り当てられます。

これで、このIPアドレスを実稼働アプリケーションのデプロイメントへの主要なエントリー・ポイントとして使用できます。 Webアプリのドメイン名を設定する場合は、ドメインがこの予約済みIPアドレスを指すようにします。

次のように入力して、予約済みIPアドレスからアプリケーションにアクセスできることをテストします。

  1. curl reserved_IP_addr

アプリケーションのバージョン1が表示されます。

Output
App v1

グリーンサーバーは現在、この応答を提供しています。

ステップ6–ブルーグリーン展開の練習

構成が完了したので、青緑色の展開が実際にどのように機能するかを示すことができます。 現在、予約済みIPアドレスはグリーンサーバーを指しています。 前述のように、予約済みIPアドレスは本番トラフィックを表し、アプリケーションのドメイン名を付加する場所になります。

ローカルマシンまたは開発マシンで、アプリケーションにいくつかの変更を加えることができます。 インデックスファイルを開きます。

  1. cd ~/sample_app

  2. nano index.html

バージョン番号を増やして、アプリケーションに目に見える変更を加えましょう。

〜/ sample_app / index.html
App v2

終了したら、ファイルを保存して閉じます。

ファイルをに追加します git ステージング領域を入力し、次のように入力して変更をコミットします。

  1. git add .

  2. git commit -m "Application version 2"

次に、新しい変更を非アクティブな環境にプッシュできます。 これにより、本番サーバーに影響を与えることなく、デプロイメントをテストする機会が得られます。

予約済みIPアドレスは現在グリーン環境を指しているため、ブルーサーバーにデプロイします。 ローカル開発マシンで次のように入力して、新しい変更を青い環境にプッシュします。

  1. git push blue main

予約済みIPアドレスにアクセスすると、アプリケーションのバージョン1がまだ提供されていることがわかります。

  1. curl reserved_IP_addr



Output
App v1

ただし、 blueサーバーの通常のIPアドレスを確認すると、アプリケーションのバージョン2をテストできます。

  1. curl blue_server_IP



Output
App v2

これが私たちが期待していることであり、私たちが望んでいることです。 これで、必要な内部テストを実行して、青いサーバー環境を実行できます。 その間、グリーンサーバーは本番トラフィックにサービスを提供し続けます。

アプリケーションの最新バージョンをテストし、それが期待どおりに機能していることを確認したら、本番トラフィックを青いサーバーに切り替えることができます。

これを行うには、DigitalOceanコントロールパネルにアクセスします。 「ネットワーク」タブをクリックし、「予約済みIP」ナビゲーション項目を選択します。 「予約済みIP」リストに、現在グリーンサーバーを指している予約済みIPが表示されます。

切り替える前に、ターミナルウィンドウの1つで、 while 予約済みIPアドレスを介して繰り返しリクエストを行うことができるようにループします。 これにより、本番アプリケーションのバージョンがv1からv2に移行するのをすぐに確認できます。

  1. while true; do curl reserved_ip_addr; sleep 2; done

Webリクエストの結果の出力を開始する必要があります。

Output
App v1
App v1
App v1
App v1

ここで、ソフトウェアの新しいバージョンを切り替えて「リリース」するには、予約済みIP割り当ての右側にある青いボタンをクリックして、IPアドレスを再割り当てします。 青いサーバーを選択します。

数秒で、予約済みIPが青いサーバーに再割り当てされます。 ターミナルウィンドウで、切り替えが明確になっているはずです。

Output
App v1
App v1
App v2
App v2

停止します while 「Ctrl+C」を押してループします。

現在、本番トラフィックは新しいバージョンのアプリケーションにルーティングされています。 これで、以前の運用サーバーであるグリーンサーバーが、ロールバックマシンと次のステージング領域の両方としてセットアップされました。

トラフィックを新しいバージョンのアプリケーションに移動した後、問題を発見した場合、このリリース戦略により、以前のバージョンにすばやく簡単にロールバックできます。 これを行うには、プロセスを逆にして、予約済みIPアドレスをグリーンサーバーに戻します。

ステップ7–データベースの更新の処理（オプション）

上で概説したシナリオは、展開およびリリース戦略自体に焦点を当てるためにスコープダウンされました。 より複雑ではありませんが、データベースを含むような一般的な設定については説明しませんでした。

2つの環境間で永続データを処理するために使用できるいくつかの異なる戦略があります。

環境ごとに個別のデータベースを維持することが可能です。 ただし、この戦略では、本番データベースのデータを非アクティブデータベースに複製し、切り替えを開始する瞬間にトランザクションを停止する必要があります。 基本的に、ライブデータベースの移行と、展開ごとに少しのダウンタイムが必要になります。 これはすぐに非常に時間がかかり、エラーが発生しやすくなる可能性があります。

より良い代替策は、通常、緑と青の環境間で単一のデータベースシステムを共有することです。 アプリケーションコードは青緑色のリリース戦略を使用して切り替え可能ですが、データベース自体は両方の環境で使用されます。

このアプローチの主な関心事は、下位互換性のないデータベース移行を含む更新をどのように展開およびリリースするかです。 現在の本番デプロイメントでは機能しない方法でデータベースを追加または変更する新しいリリースをステージングにデプロイすると、アプリケーションが破損します。

これを防ぐには、多くの場合、移行をコードベースの展開とは別に、必要に応じて段階的に展開するのが最適です。 この変更されたプロセスは、blue-turquoise-greendeploymentと呼ばれることもあります。 基本的には、データベースの古いバージョンと新しいバージョンの両方を処理できるアプリケーションコードの中間バージョンをデプロイすることに依存します。

中間アプリケーションコードは、以前のバージョンとほぼ完全に同じですが、移行が行われた後に存在する新しいデータ構造に備えて、いくつかの追加ロジックが追加されています。 多くの場合、これは、既存のデータ構造を変更するのではなく、完全に新しいデータ構造を作成するように移行を構築することによって実現されます。 このようにして、古いデータ構造、たとえばテーブルを保持し、重大な変更を含む新しいデータ構造を作成できます。

中間のターコイズ展開は、移行プロセスの最初のステップとして展開されます。 このデプロイメントは、最初は古いテーブルからの読み取りと古いテーブルへの書き込みを行いますが、新しい構造の存在を確認します。 次に、移行自体が実行され、古いバージョンと一緒に新しいバージョンのデータ構造が作成されます。 ターコイズ展開のロジックは、新しい構造が配置されていることを認識し、古い構造と新しい構造の両方への変更の書き込みを開始するように構成する必要があります。 とりあえず古い構造から読み続けます。

この時点で、すべての新しいアクティビティが両方のデータ構造に記録されます。 新しい構造を古い構造のデータで埋め戻し、途中で変換して新しい構造の条件を満たすことができます。 これが完了すると、すべてのレコードが両方の場所に存在するはずです。 移行を続行するために、次のアプリケーションデプロイメントは両方の構造に書き込みを継続する場合がありますが、新しい構造から読み取る場合があります。 すべてがスムーズに実行されていることが確認された後、別のデプロイメントが古い構造からの書き込みを遮断し、古い構造が削除される場合があります。

このプロセスは、最初はかなり複雑に見えるかもしれませんが、通常、実際にはそれほど多くの追加作業ではありません。 主な作業は、レガシー構造と新しい構造の両方を一時的に使用するセーフティネットを構築することです。 これにより、移行をコミットする前に詳細にテストする時間が与えられ、いつでもデータ構造の以前の作業バージョンにロールバックできます。 このデータ移行がどのように行われるかの例については、EtsyのMikeBrittainによるこれらのスライドのいくつかをご覧ください。

結論

デプロイメントを新しいコードの実際のリリースから分離するために採用できる戦略は他にもたくさんありますが、青緑色のデプロイメントは迅速に実装できるメカニズムです。 これは、実稼働環境を完全に反映する優れたステージング環境を提供すると同時に、リリース後、予期しない状況が発生した場合に即座にロールバックの機会を提供します。

次に、ArgoCDなどの最新のKubernetesツールを使用して青緑色のデプロイを実行する方法を学習することをお勧めします。