概要
ブルーグリーン・デプロイメントは、ユーザートラフィックを、アプリケーションやマイクロサービスの以前のバージョンから、ほぼ同一の新しいリリースに徐々に転送するアプリケーション・リリースモデルで、両バージョンが稼働中の状態で実施するものです。
古いバージョンはブルー環境、新しいバージョンはグリーン環境と呼ばれます。ブルーからグリーンへの本番環境のトラフィックの転送が完了すると、ブルーはロールバックに備えてスタンバイさせるか、あるいは本番環境からプルして更新し、次回の更新の際にテンプレートとして使用することができます。
この継続的なデプロイメントモデルにについては、すべての環境がブルーグリーンの場合と同じアップタイム要件や CI/CD プロセスを適切に実行するためのリソースを備えている訳ではないため、すべての環境に展開できる訳ではないというのが現状です。しかし、多くのアプリケーションは、エンタープライズによるデジタル・トランスフォーメーションの進展に伴い、継続的デリバリーを支援できるように進化しています。
ブルーグリーン・デプロイメントの仕組み
次のように考えてみてください。あなたはシンプルなクラウドネイティブ・アプリケーションを開発しました。ユーザーが画面上を飛ぶ色とりどりの風船をタップしてポイントを獲得するモバイルゲームです。ゲームのバックエンドは、ゲームの実績、スコアリング、メカニクス、コミュニケーション、プレーヤーの識別を処理する複数のコンテナベースのマイクロサービスによってサポートされています。
最初のリリース後、何百人ものユーザーがゲームをプレイし始めます。毎分数千ものトランザクションがログに記録されます。DevOps チームが迅速で頻繁なリリースを推奨しているので、あなたは、メカニック・マイクロサービスにマイナーアップデートをリリースして、赤い風船のサイズとスピードを増加しようとしています。
本番環境への更新を深夜 (アクティブユーザーの数が最も少ない時間帯) まで待つのではなく、ブルーグリーン・デプロイメントモデルを使用して、ピーク使用時にアプリケーションを更新します。ダウンタイムは生じません。
これができるのは、本番環境 (ブルー) でメカニック・マイクロサービスを取得し、それを同一、ただし別個のコンテナ (グリーン) にコピーしたからです。グリーン環境で赤い風船のサイズとスピードを増加した後、その更新がアクティブなブルー環境と共に本番環境にプッシュされる前に、Q/A とステージング (Jenkins のようなオープンソースのストレステスト・プロジェクトによって自動化されている場合もあります) を完了します。
運用チームは、ロードバランサーを使用して各ユーザーの次のトランザクションをブルーからグリーンにリダイレクトできます。すべての本番環境のトラフィックがグリーン環境でフィルター処理されると、ブルー環境がオフラインになります。ブルーは、障害復旧のためのオプションとしてスタンバイすることも、次回の更新のためのコンテナにすることもできます。
ブルーグリーン・デプロイメントと Kubernetes
Kubernetes は、クラウドネイティブ・アプリケーション、マイクロサービス、コンテナ、継続的インテグレーション、継続的デリバリー、継続的デプロイメント、SRE、DevOps など、ブルーグリーン・デプロイメントのプロセスに関連するすべての要素と自然に調和します。Linux® コンテナのオペレーションを自動化するオープンソース・プラットフォームとして、Kubernetes はクラウドネイティブ・アプリケーションのマイクロサービスをパッケージ化するコンテナのオーケストレーションをサポートするだけでなく、Kubernetes では開発者がアプリケーション・アーキテクチャをゼロから作成せずに再利用できるアーキテクチャ・パターンのコレクションを使用することもできます。
これらの Kubernetes パターンの 1 つに、宣言的デプロイメントパターンがあります。マイクロサービスは本質的に小さいため、非常に迅速に数を増やすことができます。宣言的デプロイメントパターンにより、Kubernetes アーキテクチャで最小かつ最も単純なユニットである新しい Pod をデプロイするために必要な手動の労力が軽減されます。
Red Hat を選ぶ理由
Red Hat は、主要なエンタープライズ Kubernetes プラットフォームの Red Hat® OpenShift を、コアの CI/CD 機能と共に強化しました。また、Red Hat OpenShift 環境内でブルーグリーン・デプロイメントをロールアウトするためのステップバイステップのコマンドラインプロンプトと引数についてもすでに文書化しています。
また、エンタープライズ Kubernetes プラットフォームをオープンソースのままにしておくと、プラットフォーム全体とそれに依存するすべてのものを制御できるため、アプリケーションとサービスの場所や、それらが何をサポートしているかに関係なく、そのまま機能させることができます。
そこから始めて、テクノロジーを支えるソースコードを調査、修正、改良しましょう。Red Hat の製品はフォーチュン 500 企業の 90% 以上から信頼を集めており*、Red Hat の製品およびテクノロジーを活用して構築されたインフラストラクチャでできないことはないと言えるでしょう。
