ブルーグリーン展開を使用してソフトウェアを安全にリリースする方法

序章

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

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

前提条件

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sudo apt update
sudo apt install git

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

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

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

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

mkdir ~/sample_app
cd ~/sample_app

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

git init

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

nano index.html

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

〜/ sample_app / index.html

App v1

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

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

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

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

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

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

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

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

sudo apt update
sudo apt install apache2

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

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

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

sudo adduser --disabled-password deploy

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

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

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

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

注：このガイドから逸脱していて、展開手順でroot権限が必要な場合は、deployで使用する必要なコマンドにパスワードなしのsudo権限を設定する必要があります。 ] アカウント。

これは、/etc/sudoers.dディレクトリ内に新しいsudoersファイルを作成することで実行できます。

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をインストールします。

sudo apt install git

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

sudo su - deploy

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

mkdir ~/sample_app
cd ~/sample_app

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

git init --bare

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

nano hooks/post-receive

内部に、次の展開スクリプトを貼り付けます。これは基本的に、上記のリンク先の記事で概説されているのと同じスクリプトです。サーバー上のgitリポジトリを示すためにGIT_DIR変数を使用し、Apacheドキュメントルートを指定するためにWORK_TREE変数を使用し、進行状況メッセージ用のサーバーのホスト名。このスクリプトは、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が適切なタイミングで実行できるようにします。

chmod +x hooks/post-receive

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

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

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

cat ~/.ssh/id_rsa.pub

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

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

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

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

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

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

ssh-keygen

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

cat ~/.ssh/id_rsa.pub

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

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

deployユーザーとして、~/.sshディレクトリを作成します。内部で、authorized_keysというファイルを開きます。

mkdir ~/.ssh
nano ~/.ssh/authorized_keys

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

〜/ .ssh / authorized_keys

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

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

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

chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

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

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

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

cd ~/sample_app

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

git remote add blue deploy@blue_server_ip:sample_app
git remote add green deploy@green_server_ip:sample_app

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

git push blue main
git push green main

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

OutputThe 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：」で始まる行には、サーバーのpost-receiveフックからのechoステートメントが含まれています。アプリを両方のサーバーにプッシュすることを忘れないでください。

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

curl blue_server_ip
curl green_server_ip

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

OutputApp v1

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

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

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

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

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

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

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

curl floating_IP_addr

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

OutputApp v1

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

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

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

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

cd ~/sample_app
nano index.html

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

〜/ sample_app / index.html

App v2

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

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

git add .
git commit -m "Application version 2"

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

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

git push blue main

フローティングIPアドレスにアクセスすると、アプリケーションのバージョン1が引き続き提供されていることがわかります。

curl Floating_IP_addr

OutputApp v1

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

curl blue_server_IP

OutputApp v2

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

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

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

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

while true; do curl Floating_ip_addr; sleep 2; done

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

OutputApp v1
App v1
App v1
App v1

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

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

OutputApp v1
App v1
App v2
App v2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結論

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

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