ブルーグリーンの展開とDrupal-あなたは本当にどれだけ知っていますか？

ブルーグリーンデプロイメントは、アプリケーションデプロイメントへの従来のアプローチの制限を克服するデプロイメント戦略の主力の1つです。 ブルーグリーン展開についてどのくらい知っていますか？ DrupalでのBlueGreenの展開はどのように実装されていますか？

はい、あなたはその権利を読みます。 更新のために、または新しいバージョンの起動中にアプリケーションをオフラインにする必要があるのは、大変な作業であり、非常に苦痛です。 スケジュールされたダウンタイムでこれを軽減できることは事実ですが、それは顧客を満足させるものではありません。 一部のサイトは、実際には1分ごとに数千ドルを失っています。 アプリケーションの展開またはアップグレードが、損失の背後にある本当の理由である必要がありますか？

ブルーグリーンの展開がダウンタイムを削減し、アプリケーションの展開に伴うその他のリスクを軽減するための最良の戦略である理由について説明します。 ブルーグリーンの展開とDrupalの詳細をご覧ください。

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

Blue-Green Deploymentは、2つの異なるバージョンのアプリケーションを実行している2つの同一の環境間でトラフィックをシフトまたは移動することにより、アプリケーションを解放するための手法です。

簡単に言うと、アプリケーションのバージョンがあります。本番環境では「ブルーバージョン」と呼びましょう。 次に、トラフィックをアプリにルーティングするために使用されるルーターがあります。 今、あなたは別のバージョンが必要です。 いくつかのグッズが追加された「グリーンバージョン」が展開されます。 ただし、この展開が行われている間も、ユーザーがアプリケーションを停止せずに、アプリケーションを表示したり、ボタンを押したり、好きなことを実行したりできるようにする必要もあります。 「青バージョン」がその間にすべてのトラフィックを処理し、最終的に接続を交換する前に、「緑バージョン」を密かに展開するようなものです。

ほぼゼロのダウンタイムリリースおよびロールバック機能を備えたBlue-GreenDeploymentの基本的な考え方は、2つの異なるバージョンのアプリケーションを実行している2つの同一の環境間でトラフィックをシフトすることです。 アプリケーションの現在のバージョンはBlue環境で表されますが、Greenバージョンは別のバージョンを実行してステージングされます。

なぜブルーグリーン展開なのか？

展開プロセスを自動化する際の主な課題の1つは、カットオーバー自体です。つまり、アプリケーションをテストの最終段階からライブ段階に移動します。 また、あらゆる種類のダウンタイムを最小限に抑えるために、これを迅速に処理する必要があります。 これはまさに青緑色の展開が行うことです。 2つの実稼働環境（本質的に可能な限り同一）では、任意の時点で、そのうちの1つが稼働しています。 また、新しいリリースの準備をするときに、稼働していない他の環境ですべてのテストを実行します。 ロールする準備ができたら、ルーターを切り替えるだけで、すべてのトラフィックが最新のリリースに向けられ、他の環境はアイドル状態になります。

また、Blue-Greenデプロイメントは、最も重要な機能の1つである、迅速なロールバックを提供します。 最新のリリースで問題が発生した場合は、ルーターを元に戻す必要があります。 障害のある環境が稼働しているときに失われたトランザクションに問題がある可能性がありますが、両方の環境にトランザクションが供給され、一方が他方のバックアップとして機能するように設計することもできます。

どのように青緑色の展開ですか？

Blue-Green Deploymentの2つの環境について理解したので、同じものを実装するためのいくつかのベストプラクティスを見てみましょう。

• DNSスイッチングを介した負荷分散

環境を切り替えるときは、ドメインが最終的に別のサーバーを指すようにすることに注意してください。 DNSレコードに移動してDNS管理インターフェイスに変更を加える代わりに、負荷分散を使用します。

DNSレコードに変更を加える際の問題は、トラフィックの軌跡が長くなるだけです。 つまり、一部のユーザーには引き続き古い環境が提供されますが、トラフィックのルーティング先を完全に制御することはできません。

ただし、ロードバランサーを使用すると、新しいサーバーをすぐにセットアップできるため、DNSメカニズムに依存する必要はありません。 このようにして、トラフィックを完全に制御でき、すべてのトラフィックが新しい環境にルーティングされていることを完全に確認できます。

• ローリングアップデート

すべてのサーバーを一度に切り替えないでください。 代わりにローリングアップデートを実行してください。 つまり、BlueサーバーからGreenサーバーに一度に切り替えるのではなく、統合環境で作業します。 新しいサーバーを1つ追加し、古いサーバーを廃止します。 すべての新しいサーバーが配置されるまで繰り返します。 これにより、ダウンタイムが大幅に短縮されます。

• 環境モニタリング

ライブ環境を監視することは明らかですが、他の環境を監視しないことで不意を突かれるのは望ましくありません。 はい、他の環境の監視はそれほど重要ではありません。 ただし、同じ環境が両方の状態として機能する可能性があるため、2つの間でアラートを切り替える簡単な方法が必要になります。 レポートを返す2つの環境に異なるAPIトークンを設定するか、役割が変更/切り替えられたときに環境のアラートポリシーをプログラムで変更します。

• オートメーション

手動の一連のアクションは、作業を増やすだけです。 代わりに、切り替えプロセスのすべてのアクションをスクリプト化します。 切り替えプロセスを自動化すると、Blue-GreenDeploymentの実装がより迅速、簡単、安全になります。

DrupalWebサイトのBlueGreen展開

問題

• コードのデプロイ中、Drupalはデータベースの更新を実行して動作させる必要があります。これは、Drupalの更新によってWebサイトがメンテナンスモードに設定され、ユーザーにこの美しい白い画面が表示されるため、大きな問題です。

デプロイメントが失敗した場合、データベーススキーマが変更されている可能性があることを考慮して、ダンプからデータベースを復元することによってのみロールバックが可能です。 これはダウンタイムを意味します！

解決策：ブルーグリーン展開！

DrupalでBlueGreenDeploymentを実装するためのインフラストラクチャの概要をいくつか見てみましょう。 Drupalのあらゆる種類の操作には、Nginxとphpサーバー（主にDrupalを実行するため）が必要です。データベース、ファイルストレージ、キャッシュが必要です。スタックは、可用性が高くなるように設計されています。

Blue Green Deploymentでは、新しいコードベースで新しいスタックをデプロイし、すべてのデータベースと以前のコードベースからのさまざまな状態を、できればDrushを使用してコピーする必要があります。

2つの異なるスタックを設定したら、本番スタックとは別にステージングスタックをテストする必要があります。 基本的に、ユーザーはスタック（本番スタック）に移動して、デプロイされているWebサイトのバージョンをテストする必要があります。 そして、他のバージョン（ステージングスタック）の準備ができたら、バージョンを反転するだけです。 これで、ユーザーは新しいスタックに移動し、古いバージョンをテストできるようになります。

Dockerを使用したBlueGreenデプロイメント

Drupalでのデプロイは簡単ではありません。 コードがデプロイされ、コンポーザーの依存関係が処理され、スキーマの更新が最新であり、すべてのキャッシュがクリアされていることを確認する必要がありますが、「レスポンシブWebサイト」が稼働していることも確認する必要があります。 また、問題が発生して展開が失敗した場合はどうなりますか？ ロールバックしますか？ または、展開を停止しますか？

あなたが探しているフレーズは、Blue GreenDeploymentです。

Drupalのデプロイ中、Dockerはアプリケーション間の移行を容易にし、同じバージョンの異なるバージョンのビルドと実行を容易にします。 EC2インスタンスには、常に青と緑の隆起したDockerコンテナーのセットがあり、nginxはリバースプロキシサーバーとして機能します。 Dockerを使用した青緑色のデプロイにより、ユーザーは2つの異なる環境で並行して実行されるDrupalWebサイトを構築できます。

AWSを使用したBlueGreenのデプロイ

歴史的に、ブルーグリーンの展開は、コストが高く複雑であるため、オンプレミスでソフトウェアを展開する最初の選択肢ではありませんでしたが、コンテナーはこの認識を永久に変えました。

コンテナは、パッケージが簡単で、環境を切り替える際の動作が一貫しているため、ブルーグリーン展開の採用が容易になります。 また、コンテナーの構成を変更するには、ソフトウェアを更新するのではなく、dockerfileを更新し、コンテナーを再構築して所定の場所に再デプロイするだけです。

Amazon ECSは、既存のAmazon ECSサービスを更新するときに、これらのローリング更新を実行します。 ecs blue greenデプロイメントのローリングアップデートには、既存のバージョンのコンテナーを最新バージョンに置き換えることが含まれます。 更新中にAmazonECSが追加または削除するこのコンテナーの数は、サービスのデプロイ中に許可される正常なタスクの最大数と最小数を調整することによって制御されます。更新後、サービスのタスク定義はコンテナーイメージの最新バージョンで更新されます。 Amazon ECSは、コンテナの古いバージョンから最新バージョンへの置き換えを自動的に開始します。

AWS ECSを使用したブルーグリーンのデプロイは、同じリソースセットに縛られていないため、最適化のメリットも提供します。 つまり、アプリケーションのパフォーマンスエンベロープがバージョンごとに変わる場合は、最適化されたリソースを使用して新しい環境を起動するだけです（リソースの数を減らしたり、リソースのセットを完全に変えたりすることができます）。

AWSでのブルーグリーンのデプロイは、継続的インテグレーションとデプロイワークフローにもうまく適合し、デプロイの自動化で既存の環境への依存関係を少なく考慮できるようにすることで、複雑さをチェックし続けます。

このソリューションにより、ユーザーは時間を無駄にすることなく、Webプラットフォームの展開とスケーラビリティを簡単に管理できます。 このデプロイメントは、DrupalWebサイトを問題なく実行できる高可用性環境の構成に役立ちます。