Oracle Cloud Infrastructure DevOpsによる最新のアプリケーション・デプロイメント戦略の理解

アプリケーションのクラウドでの効率的な実行には、ソフトウェアの迅速な配信が不可欠です。Oracle DevOpsサービスは、Oracle Cloudでソフトウェアとアプリケーションを簡単に構築、テストおよびデプロイするために使用できる開発者のための継続的な統合およびデプロイメント(CI/CD)プラットフォームを提供します。

DevOpsビルドおよびデプロイメント・パイプラインにより、変更駆動のエラーを削減し、リリースの作成とデプロイに費やす時間を短縮できます。また、このサービスは、コードを格納するためのプライベートGitリポジトリを提供し、外部コード・リポジトリへの接続をサポートします。ワークロードを(オンプレミスまたは他のクラウドから) OCIに移行する場合でも、OCIで新しいアプリケーションを開発する場合でも、DevOpsサービスを使用して、ソフトウェア・デリバリのライフサイクルを簡略化できます。

アーキテクチャ

このリファレンス・アーキテクチャでは、ブルーグリーン戦略とカナリア戦略の2つの異なるデプロイメント戦略について説明します。

デプロイメント戦略は、アプリケーションの変更またはアップグレードを可能にするモデルおよびプラクティスです。これにより、DevOpsチームは、アプリケーションを本番環境にデプロイする方法を定義できます。様々なデプロイメント戦略の選択により、管理者は、新しいリリースをデプロイするリスク、新しいリリースがユーザーに与える影響、戦略の実装に必要なインフラストラクチャ・オーバーヘッドの間での適切なトレードオフを行うことができます。ここで示す戦略は、アプリケーションのニーズに応じて、適切なトレードオフを行うためのさらなるオプションを提供します。

ブルーグリーン導入

ブルーグリーン・デプロイメント計画では、DevOpsチームは、2つの同一環境を使用してアプリケーションの新しいバージョンをリリースできます。この環境では、1つずつアクティブになります。アプリケーションの現在のバージョンはアクティブな環境にプロビジョニングされますが、新しいバージョンはスタンバイ環境にデプロイされます。

スタンバイ環境にデプロイしても、アクティブな環境やユーザー・トラフィックには影響しません。DevOpsリリース・パイプラインは、新しいバージョンに対して検証テストを実行でき、承認されると、ユーザー・トラフィックをスタンバイ環境に切り替えるだけで本番に進めることができます。このプロセスは、アプリケーションの新しいリリースごとに繰り返されます。

この戦略の主な利点は、ほぼゼロのダウンタイムと即時ロールバック機能を提供することです。新しいバージョンで問題が発生した場合、トラフィックは直ちに以前の安定したバージョンに戻すことができます。また、スタンバイ環境は、アプリケーション・リリースに関する問題のデバッグに使用できます。

Blue Greenのデプロイメントには、次の利点があります。
  • これにより、迅速でリスクのないデプロイメントが可能になります。
  • 効果的でシンプルなロールバック・メカニズムを提供します。
  • これは、A/Bソフトウェア・テストを編成する効果的な方法です。
  • 本番は常にアクティブな環境の1つ(ロード・バランサによって制御される)によって提供されるため、停止時間はほとんど必要ありません。
ただし、次の欠点を注意する必要があります。
  • 同じ環境の実行はコストがかかり、メンテナンスはリソース集約型です。
  • 2つの同一環境間でリリースを管理する場合は、両方の環境を緊密に監視する必要があります。
  • デプロイメント間のデータベース依存関係の管理は複雑になる場合があります。

次の図は、青緑色のデプロイメント・アーキテクチャを示しています。

blue-green-deployment.pngの説明が続きます
図blue-green-deployment.pngの説明

Blue-green-deployment.zip

Canaryデプロイメント

Canaryデプロイメント戦略では、アプリケーションのリリースは、ユーザーのサブセットに対して増分的に行われます。最初は、新しいバージョンが、ユーザー・トラフィックのない運河環境にデプロイされます。DevOpsリリース・パイプラインでは、新しいバージョンに対して検証テストを実行し、準備が整ったら、ユーザーのサブセットのみを運河環境にルーティングできます。

この方法により、DevOpsチームは、実際のユーザー・トラフィックに対して新しいアプリケーションのバージョンを評価できます。新しいバージョンを大きなユーザー・ベースにロールアウトする前に、2つのアプリケーションのバージョンを並べて比較できます。また、新しいバージョンが少数のユーザーに対してのみ有効になっているため、リスクの軽減も提供されます。問題が発生した場合、これらのユーザーは以前のバージョンに簡単に切り替えることができます。

Canaryデプロイメントには次の利点があります。
  • 2つのアプリケーションのバージョンを実ユーザーと並べてテストできます。
  • 新しいバージョン・リリースのダウンタイムはゼロ。
  • 以前のバージョンへのロールバックは非常に簡単で、リスクを最小限に抑えます。
ただし、次の欠点を注意する必要があります。
  • 大規模な新しいリリースのテストおよび検証は複雑になる場合があります。
  • ユーザー・テストから新しいリリースへのフィードバックのフェッチには時間がかかります。

次の図は、Canaryデプロイメント戦略を示しています。

canary-deployment.pngの説明が続きます
図canary-deployment.pngの説明

canary-deployment-oracle.zip

これらのアーキテクチャーには、次のコンポーネントが含まれます。
  • リージョン

    OCIリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的な領域です。リージョンは他のリージョンから独立しており、巨大な距離は(国全体または大陸にわたって)分離できます。アーキテクチャでは単一のリージョンが使用されます。

  • DevOpsプロジェクト

    CI/CDワークフローの実装に必要なDevOpsリソースの論理グループ。DevOpsリソースは、アーティファクト、ビルド・パイプライン、デプロイメント・パイプライン、外部接続、トリガーおよび環境です。DevOpsプロジェクトを使用すると、すべてのDevOpsリソースのロギング、監視および通知を簡単に有効にできます。

  • パイプラインのビルド

    ビルド・パイプラインでは、ソース・コード・リポジトリからコミットIDを受け取り、そのソース・コードを使用してビルド手順を実行します。ビルド・パイプラインは、ソフトウェア・アーティファクトの作成、テストおよびコンパイル、OCIリポジトリへのアーティファクトの配信、およびオプションでデプロイメントのトリガーなど、ビルド・プロセスのステージのセットを定義します。ビルド実行のフローおよび指示はビルド仕様ファイルで定義します。

  • ビルド・ステージ
    ステージは、パイプライン実行中に実行される個々のアクションです。ここで説明する様々なビルド・ステージは次のとおりです。
    • 管理対象ビルド・ステージ:ソース・コードを構築およびテストするための管理対象ビルド・ステージ。
    • アーティファクト・ステージの配信:ビルド・ステージの出力を様々なリポジトリにプッシュするステージ。たとえば、コンテナ・イメージをコンテナ・リポジトリにプッシュしたり、デプロイメント・マニフェストをアーティファクト・レジストリにプッシュします。
    • デプロイメントの起動:ビルド・ステージの完了後にデプロイメント・パイプラインを起動するステージであり、管理対象ビルド・ステージからデプロイメント・パイプライン・ステージへのエクスポートされた変数の解析も含まれます。
  • コード・リポジトリ

    DevOpsサービスによってホストされるプライベートGitリポジトリ。これらのDevOpsコード・リポジトリを使用して、ソース・コードを格納、管理、開発できます。

  • デプロイメント・パイプライン

    一連のアーティファクトをターゲット環境に提供およびデプロイするための一連のステップ。ソフトウェアリリースのフローおよびロジックは、シリアルまたはパラレルで実行できるステージを定義することで制御できます。

  • デプロイメント・ステージ
    ステージは、パイプラインの実行中に実行される個々のアクションです。Blue-Greenデプロイメントのビルド・ステージは次のとおりです。
    • 青/緑色のOKEデプロイメントまたは青/緑色のインスタンス・グループ・デプロイメント:更新したコードをターゲット環境にデプロイするステージ。
    • デプロイメントの検証:ファンクションを使用してデプロイメントを検証できるオプションのステージ。
    • 制御:承認: ターゲット本番環境へのデプロイメントを承認するための制御ステージ。
    • 青/緑のOKEトラフィック・シフトまたは青/緑のインスタンス・グループ・トラフィック・シフト:最終ステージで、本番トラフィックが最新のデプロイ済環境に切り替わります。
    Canaryデプロイメントのビルド・ステージは次のとおりです。
    • Canary OKE DeploymentまたはCanary Instance Group Deployment:更新したコードをターゲット環境にデプロイするステージ。
    • デプロイメントの検証:ファンクションを使用してデプロイメントを検証できるオプションのステージ。
    • Canary OKE Traffic ShiftまたはCanary Instance Group Traffic Shift:ランプ制限(%シフトするトラフィックの%)に基づいて、トラフィックをカナリア環境に切り替えます。
    • 制御:承認:ターゲット本番環境へのデプロイメントを承認するための制御ステージ。
    • インスタンス・グループ・プロダクションのカナダデプロイまたはOKEデプロイ:本番トラフィックが最新のデプロイ済環境に切り替わる最終ステージ。
  • DevOpsアーティファクト

    DevOpsアーティファクトは、アプリケーションを構成するファイル、バイナリ、パッケージ、マニフェストまたはイメージへの参照またはポインタです。アーティファクトの作成時に、実際のアーティファクトのソースの場所をOracle DevOpsに通知します。DevOpsでは、OCIコンテナ・イメージ・レジストリおよびOCIアーティファクト・レジストリ・リポジトリがサポートされます。

  • アーティファクト・リポジトリ

    アーティファクト・リポジトリは、類似したアーティファクトをグループ化するリポジトリを作成します。作成後、アーティファクトをこのリポジトリにアップロードできます。これらのアーティファクトは、ターゲット・デプロイメント環境に配信されるテキスト・ファイル、バイナリおよびデプロイメント・マニフェストのコレクションです。各アーティファクトには、パス: versionで構成される名前があります。パスは、アーティファクトを編成するための文字列です。

  • OCIロギングおよび通知サービス

    OCIロギング・サービスは、デプロイメントに関連するログを格納します。デプロイメント・ランタイム出力およびデプロイメントの最終結果は、ログ・エントリとして表示されます。OCI Notificationsサービスでは、デプロイメント・プロジェクトとそのリソースの最新状態を可視化し、必要なアクションを実行できます。たとえば、承認を待機しているデプロイ・パイプラインのステージなどの重要なイベントが発生すると通知されます。通知メッセージを受信したら、DevOpsデプロイメント・パイプラインに移動し、ステージを承認できます。

  • 環境の配置

    この環境は、アーティファクトがデプロイされているコンピューティング・リソースのコレクションです。環境は、ファンクション、コンピュート仮想マシン(VM)またはベア・メタル・インスタンス、OKEクラスタのいずれかです。ブルーグリーン・デプロイメントは、OKEクラスタおよびコンピュート仮想マシンでのみ使用できます。

推奨

Oracle DevOpsサービスを使用して継続的インテグレーションおよびデプロイメント(CI/CD)プラットフォームをデプロイする場合は、次の推奨事項を開始点として使用します。要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • コンピュート・シェイプ

    このアーキテクチャでは、E3またはE4フレックス・シェイプ(最小リソース)を持つOracle Linux OSイメージを使用して、OKEクラスタ・ノードのコンピュート・ホストをホストします。アプリケーションでより多くのメモリーまたはコアが必要な場合は、別のシェイプを選択できます。

  • VCN

    VCNを作成する際、VCNのサブネットにアタッチする予定のリソース数に基づいて、必要なCIDRブロックの数および各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。このアーキテクチャは、パブリックVCNを使用してOracle Container Engine for Kubernetesをホストします。プライベートVCNを使用することもできます。その場合、NATゲートウェイを使用して、パブリック・インターネットを介したクラスタ・アクセス権を付与します。

  • Oracle Container Engine for Kubernetes (Oke)

    このアーキテクチャーは、OKEクラスタにターゲット環境の1つとして配備されます。ワーカー・ノードは、E3またはE4 Oracle Linux OSにデプロイされます。このアーキテクチャでは、クラスタ内の3つのワーカー・ノードを使用しますが、各クラスタに最大1,000個のノードを作成できます。

  • インスタンス・グループ

    このアーキテクチャを選択してインスタンス・グループにデプロイする場合は、選択したシェイプの新しいコンピュート・インスタンスがテナンシ内に作成されます。

  • コンテナ・イメージ・レジストリ

    このアーキテクチャは、レジストリを内部使用のためのプライベートDockerレジストリとしてデプロイします。Dockerイメージはレジストリにプッシュされ、レジストリからプルされます。レジストリをパブリックDockerレジストリとして使用することもできます。これにより、インターネットにアクセスし、適切なURLの知識があるユーザーはOracle Cloudのパブリック・リポジトリからイメージをプルできます。

  • アーティファクト・レジストリ

    このアーキテクチャは、インスタンス・グループ、OKEおよびファンクション・デプロイメントで使用されるソフトウェアおよび構成用のアーティファクトを作成します。アーキテクチャは、内部使用のためにアーティファクト・レジストリ・リポジトリを作成します。ソフトウェア・バイナリ、テキストおよびデプロイメント構成は、アーティファクト・レジストリ・リポジトリにアップロードおよびダウンロードされます。

注意事項

Oracle DevOpsサービスを使用して継続的インテグレーションおよびデプロイメント(CI/CD)プラットフォームをデプロイする場合は、これらの要因を考慮してください。

  • DevOpsでサポートされているデプロイメント

    DevOpsは、OKE、コンピュート・ホストおよびファンクションへのデプロイメントをサポートします。このアーキテクチャーはOKEクラスタにデプロイされます。特定の要件に基づいて他のエンドポイントにデプロイすることを検討してください。

  • Linuxのサポート

    コンピュート・インスタンスへのインスタンス・グループ・デプロイメントでは、Linuxホストのみがサポートされています。

  • デプロイ済アーティファクト

    DevOpsでデプロイするアーティファクトは、OCIアーティファクト・レジストリまたはコンテナ・イメージ・レジストリ・リポジトリに存在する必要があります。

  • アプリケーションのグループ化

    ベスト・プラクティスとして、各アプリケーションおよびすべてのマイクロサービスを単一のプロジェクトにグループ化します。

デプロイ

このリファレンス・アーキテクチャのTerraformコードは、Oracle Cloud Infrastructure Resource Managerのサンプル・スタックとして使用できます。GitHubからコードをダウンロードし、特定の要件にあわせてカスタマイズすることもできます。

  • Oracle Cloud Infrastructure Resource Managerのサンプル・スタックを使用してデプロイします:
    1. 目的のデプロイメント戦略に対応するボタンをクリックし、ステップ2-6の手順に従います。

      まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。

    2. スタックをデプロイするリージョンを選択します。
    3. 画面上のプロンプトと手順に従ってスタックを作成します。
    4. スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
    5. ジョブが完了するまで待機し、プランをレビューします。

      変更するには、「スタックの詳細」ページに戻り、「スタックの編集」をクリックして必要な変更を行います。次に、「プラン」アクションを再度実行します。

    6. これ以上の変更が必要ない場合は、「スタックの詳細」ページに戻り、「Terraformアクション」をクリックして「適用」を選択します。
  • GitHubでTerraformコードを使用してデプロイします。
    1. GitHubにアクセスします。
    2. リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
    3. READMEドキュメントの指示に従います。

詳細の検討

Oracle Cloud InfrastructureのDevopsで最新のアプリケーション・デプロイメント戦略について詳しく学習します。

次の追加のソリューションを確認します。

謝辞

  • 作成者: Rahul M R
  • 貢献者: Saurabh Shah、 Lukasz Feldman