GitOps は、自動化された継続的デリバリーの信頼できる情報源として使用される Git にアプリケーションと宣言型インフラストラクチャ コードを格納する、クラウドネイティブ アプリケーションの運用モデルです。 GitOps では、システム全体の必要な状態を Git リポジトリに記述し、GitOps オペレーターがお使いの環境にデプロイします。多くの場合、これは Kubernetes クラスターです。 Azure 上の GitOps for Kubernetes の詳細については、「Azure Kubernetes Service 向け GitOps」および「CI/CD と Azure Arc 対応 Kubernetes での GitOps の原則」を参照してください。
この記事のシナリオ例は、コンテナー、ビルド用の継続的インテグレーション (CI)、継続的デプロイ (CD) 用の GitOps を使用して、エンドツーエンドのアプリケーション開発を最新化する必要がある企業に当てはまります。 このシナリオでは、Flask アプリが例として使用されます。 この Web アプリは、Python を使用して記述されたフロントエンドと Flask フレームワークで構成されます。
Architecture
以下のオプションでは、プッシュベースとプルベースの CI/CD アプローチについて説明します。
オプション 1: プッシュベースの CI/CD
CI と CD に GitHub Actions を使用したプッシュ ベースのアーキテクチャ。
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
このシナリオでは、2 層 Web アプリケーションのプッシュベースの DevOps パイプラインと、フロントエンド Web コンポーネントと Redis を使用するバックエンドを取り上げます。 このパイプラインでは、ビルドとデプロイに GitHub Actions を使用します。 このシナリオのデータ フローは次のとおりです。
- アプリ コードが開発されます。
- アプリ コードが GitHub Git リポジトリにコミットされます。
- GitHub Actions でアプリ コードからコンテナー イメージがビルドされ、コンテナー イメージが Azure Container Registry にプッシュされます。
- GitHub Actions ジョブは、マニフェスト ファイルで説明されているように、kubectl または Kubernetes クラスターへのデプロイ アクションを使用して、アプリを Azure Kubernetes Service (AKS) クラスターにデプロイ、すなわちプッシュします。
オプション 2: プルベースの CI/CD (GitOps)
CI 用の GitHub Actions と CD 用の Argo CD を使用したプルベースのアーキテクチャ。
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
このシナリオでは、2 層 Web アプリケーションのプルベースの DevOps パイプラインと、フロントエンド Web コンポーネントと Redis を使用するバックエンドを取り上げます。 このパイプラインでは、ビルドに GitHub Actions を使用します。 デプロイの場合、GitOps オペレーターとして Argo CD を使用してアプリをプル/同期します。 このシナリオのデータ フローは次のとおりです。
- アプリ コードが開発されます。
- アプリ コードが GitHub リポジトリにコミットされます。
- GitHub Actions でアプリ コードからコンテナー イメージがビルドされ、コンテナー イメージが Azure Container Registry にプッシュされます。
- GitHub Actions は、Azure Container Registry 内のコンテナー イメージのバージョン番号に基づいて、現在のイメージ バージョンで Kubernetes マニフェスト デプロイ ファイルを更新します。
- Argo CD は、Git リポジトリと同期するか、Git リポジトリからプルされます。
- Argo CD は、アプリを AKS クラスターにデプロイします。
Components
- GitHub Actions は、継続的インテグレーション (CI) のために Azure サービスと統合できる自動化ソリューションです。 このシナリオでは、GitHub Actions によって、ソース管理へのコミットに基づいて新しいコンテナー イメージの作成が調整され、それらのイメージが Azure Container Registry にプッシュされた後、GitHub リポジトリ内の Kubernetes マニフェスト ファイルが更新されます。
- Azure Kubernetes Service (AKS) は、コンテナー オーケストレーションの専門知識がなくても、コンテナー化されたアプリケーションをデプロイし、管理できるマネージド Kubernetes プラットフォームです。 ホストされた Kubernetes サービスとして、Azure は正常性監視やメンテナンスなどの重要なタスクを自動的に処理します。
- Azure Container Registry は、AKS クラスターで使用されるコンテナー イメージを保存し、管理します。 イメージは安全に保存されています。Azure プラットフォームによって他のリージョンにレプリケートすることで、デプロイ時間を短縮できます。
- GitHub は、Git で実行される Web ベースのソース管理システムであり、開発者がアプリケーション コードの格納とバージョン管理に使用します。 このシナリオでは、GitHub を使用してソース コードを Git リポジトリに格納し、GitHub Actions を使用してコンテナー イメージをビルドし、プッシュベースのアプローチで Azure Container Registry にプッシュします。
- Argo CD は、GitHub および AKS と統合されるオープンソースの GitOps オペレーターです。 Argo CD では、継続的デプロイ (CD) がサポートされます。 Flux がこの目的で使用されてきましたが、Argo CD では、クラスター オペレーターがクラスター管理に使用するのと同じツールを使用する場合と比較して、アプリ チームが特定のアプリケーション ライフサイクルに関する問題に対して別個のツールを選択する方法が示されています。
- Azure Monitor は、パフォーマンスの追跡、セキュリティの維持、傾向の把握に役立ちます。 Azure Monitor によって取得されたメトリックは、他のリソースやツール (Grafana など) で使用できます。
代替
- Azure Pipelines は、任意のアプリの CI/DC とテスト パイプラインを実装するのに役立ちます。
- Jenkins は、CI/CD のために Azure サービスと統合できるオープンソース オートメーション サーバーです。
- Flux は GitOps オペレーターとして利用できます。 Argo CD と同じタスクを実行でき、AKS で同じように動作します。
シナリオの詳細
このシナリオでは、アプリの自動ビルドとデプロイで複数のテクノロジを使用します。 コードは VS Code で開発され、GitHub リポジトリに格納されます。 GitHub Actions は、アプリをコンテナーとしてビルドし、コンテナー イメージを Azure Container Registry にプッシュするために使用されます。 GitHub Actions は、Git リポジトリにも格納されている必要な Kubernetes マニフェスト デプロイ ファイルの更新に使用され、GitOps オペレーター Argo CD はそこから Kubernetes マニフェスト ファイルを取得し、アプリを AKS クラスターにデプロイします。
その他の例には、自動化された開発環境の提供、新しいコード コミットの検証、ステージング環境または運用環境への新しいデプロイのプッシュがあります。 従来、企業はアプリケーションや更新プログラムを手動でビルドしてコンパイルし、大規模なモノリシック コード ベースを維持する必要がありました。 CI と CD 用の GitOps を使用する最新のアプリケーション開発手法により、サービスの構築、テスト、デプロイを迅速化できます。 この最新の手法により、アプリケーションや更新プログラムを顧客により迅速にリリースし、変化するビジネス要求により俊敏に対応することができます。
AKS、Container Registry、GitHub、GitHub Actions などの Azure および GitHub サービスを使用することで、企業は最新のアプリケーション開発技術やツールを使って、高可用性の実装プロセスを簡素化できます。 また、Flux や Argo CD for GitOps などのオープンソース テクノロジを使用することで、企業はデプロイを簡素化し、必要な状態のアプリケーションを適用します。
考えられるユース ケース
その他の関連するユース ケース:
- コンテナー ベースのマイクロサービス手法を採用することで、アプリケーション開発プラクティスを最新化する。
- アプリケーションの開発とデプロイのライフサイクルを加速化する。
- 検証のために、テスト環境または受け入れ環境へのデプロイを自動化する。
- アプリケーションの構成と必要な状態を確保する。
- クラスターのライフサイクル管理を自動化する。
CI/CD オプション
このドキュメントでは、CI/CD パイプラインでの継続的デプロイを処理するための最新のアプローチに GitOps を使用する方法を紹介します。 ただし、組織ごとに異なります。 自動デリバリー パイプラインを使用して Kubernetes クラスターにアプリケーションをデプロイする場合は、さまざまな方法を理解することが重要です。
アプリケーションを AKS クラスターにデプロイするための最も一般的な 2 つの CI/CD オプションは、プッシュベースとプルベースです。 プッシュ オプションでは、継続的デプロイに GitHub Actions を利用し、プル オプションでは、継続的デプロイに GitOps を利用します。
オプション 1: CI と CD に GitHub Actions を使用するプッシュベースのアーキテクチャ
このアプローチでは、コードはパイプラインの CI 部分から始まり、Kubernetes クラスターへのデプロイとして変更がプッシュされます。 デプロイはトリガーに基づいて行われます。 リポジトリへのコミットや別の CI パイプラインからのトリガーなど、デプロイを開始できるさまざまなトリガーがあります。 この方法では、パイプライン システムは Kubernetes クラスターにアクセスできます。 プッシュベースのモジュールが、CI/CD ツールで現在使用されている最も一般的なモデルです。
プッシュベースのアプローチを使用する理由は次のとおりです。
柔軟性: 現在、ほとんどの GitOps オペレーターは Kubernetes でのみ実行されています。 組織が Kubernetes 以外にアプリケーションをデプロイする必要がある場合は、GitHub Actions などの他の CI/CD ツールを使用して、その環境にアプリケーションをプッシュする必要があります。
効率性: クラウドネイティブおよび従来のアプリケーションをデプロイするために標準化されたアプローチの方が効率的です。 現在、GitOps が、Kubernetes で実行されるクラウドネイティブ アプリケーションに最適です。
シンプルさ: プッシュベースの CI/CD は、多くの組織の最も幅広いエンジニアの間でよく知られています。 プッシュベースのアプローチは、プッシュベースとプルベースを組み合わせた CI/CD アプローチよりも簡単な場合があります。
構造: アプリケーションに使用される現在のリポジトリ構造は GitOps に適していない場合があります。つまり、GitOps に合わせて大幅な計画と再構築が必要になります。
オプション 2: CI 用の GitHub Actions と CD 用の GitOps オペレーター Argo CD を使用するプルベースのアーキテクチャ
このアプローチでは、Kubernetes クラスター内から変更を適用することを中心にしています。 Kubernetes クラスターに含まれているオペレーターは、クラスターの必要な状態を Git リポジトリでスキャンし、必要な変更を選択して適用します。 このモデルでは、外部クライアントに、Kubernetes クラスターに対する管理者レベルの資格情報がありません。 プルモデルは新しいものではありませんが、CI/CD ツールで広く使用されていませんでした。 最近、GitOps の導入に伴って、プルモデルが採用されてきました。 多くの組織では、CD/CD パイプラインでの継続的なデプロイを容易にするために GitOps を利用してきました。
プルベースのアプローチを使用する理由は次のとおりです。
整合性: GitOps を使用すると、オペレーターは Kubernetes クラスターの状態を、Git リポジトリ内の構成とアプリケーションに必要な状態と比較します。 構成またはアプリケーションに誤差がある場合、GitOps オペレーターは Kubernetes クラスターを必要な状態に自動的に戻します。
セキュリティ: GitOps を使用した CI/CD に対するプルベースのアプローチでは、セキュリティ資格情報を Kubernetes クラスターに移すことができます。これにより、外部 CI ツールに格納されている資格情報を削除することで、セキュリティやリスクが軽減されます。 また、許可されている着信接続を減らし、Kubernetes クラスターへの管理者レベルのアクセスを制限することもできます。
バージョン管理: GitOps は信頼できる情報源として Git リポジトリを利用するため、継続的デプロイには本質的にバージョン管理、ロールバック、監査の機能があります。
マルチテナント: GitOps を使用したプルベースのアプローチは、分散チームやマルチテナントに適しています。 GitOps を使用すると、個別の Git リポジトリ、個別のアクセス権を利用し、異なる名前空間にデプロイを分散できます。
クラウド ネイティブ: 最新化され、クラウドネイティブに構築されるアプリケーションが増えています。 ほとんどのアプリケーションが Kubernetes で実行されている組織では、GitOps オペレーターを継続的デプロイに利用する方が、CI/CD に対する従来のプッシュベースのアプローチよりも簡単で効率的です。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
アプリケーションのパフォーマンスを監視し、問題を報告するために、このシナリオでは Azure Monitor を使用します。 これを使用すると、コードの更新が必要になる可能性のあるパフォーマンスの問題を監視し、トラブルシューティングを行うことができます。コードの更新は、CI/CD パイプラインを使用して展開できます。
AKS クラスターに含まれるロード バランサーは、アプリケーションを実行する 1 つ以上のコンテナーまたはポッドにアプリケーション トラフィックを分散します。 コンテナー化されたアプリケーションを Kubernetes で実行するこのアプローチにより、可用性の高いインフラストラクチャが顧客に提供されます。
Note
この記事では、CI/CD パイプラインの高可用性については直接扱いません。 詳細については、「GitHub Actions の高可用性」および「Argo CD - Kubernetes 用の宣言型 GitOps CD」を参照してください。
回復性コンポーネントは Kubernetes に組み込まれています。 問題がある場合は、これらのコンポーネントがコンテナーまたはポッドを監視して再起動します。 複数の Kubernetes ノードを組み合わせると、アプリケーションは使用できなくなっているポッドやノードを許容できます。
回復性があるソリューションの設計に関する一般的なガイダンスについては、「Designing reliable Azure applications」 (信頼性の高い Azure アプリケーションの設計) を参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
資格情報とアクセス許可を分離するために、このシナリオでは専用の Microsoft Entra サービス プリンシパルを使用します。 このサービス プリンシパルの資格情報は、セキュリティで保護された資格情報オブジェクト (GitHub Actions のシークレット) として GitHub に保存されているため、スクリプトやビルド パイプライン内で直接公開されたり表示されたりすることはありません。
AKS クラスターでのアプリケーションのセキュリティ保護に関する一般的なガイダンスについては、「AKS でのアプリケーションとクラスターに対するセキュリティの概念」を参照してください。
懸念事項を分離するために、このガイダンスでは、ビジネス アプリケーションと GitOps オペレーターを Kubernetes クラスター上の別々の名前空間で実行することで、ビジネス アプリケーションを実行するコンピューティングを CD エージェントまたは GitOps オペレーターから分離します。 懸念事項をさらに分離するために、GitOps オペレーターは、ビジネス アプリケーションを実行する運用 Kubernetes クラスターとは別に、GitOps インスタンス専用の Kubernetes クラスターで実行できます。
Note
この記事では、CI/CD パイプラインをセキュリティで保護する方法については直接扱いません。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
AKS を使用すると、アプリケーションの要求に応じてクラスター ノードの数をスケーリングできます。 アプリケーションが拡大するにつれて、サービスを実行する Kubernetes ノードの数をスケールアップできます。
GitHub Actions では、クラウド プロバイダーがランナーの数を自動的にスケーリングします。 セルフホステッド ランナーを使用する場合、ランナーのホストは、必要に応じてそれらのスケーリングを担当します。
スケーラビリティに関する他のトピックについては、「パフォーマンス効率のチェックリスト」を参照してください。
このシナリオのデプロイ
AKS-baseline-automation リファレンス実装の手順に従って、シナリオをデプロイします。 リファレンス実装リポジトリには、プッシュベースの CI/CD シナリオとプルベースの CI/CD (GitOps) シナリオの両方のガイド付きチュートリアルがあります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Steve Buchanan | プリンシパル プログラム マネージャー
その他の共同作成者:
- Ayobami Ayodeji | シニア プログラム マネージャー
- Bahram Rushenas | シニア アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
このシナリオでは、Azure Container Registry と AKS を使用して、コンテナー ベースのアプリケーションを格納し、実行しました。 オーケストレーション コンポーネントをプロビジョニングしなくても、Azure Container Apps または Azure Container Instances を使用して、コンテナー ベースのアプリケーションを実行することもできます。 詳細については、Azure Container Instances の概要に関する記事と「Azure Container Apps の概要」をご覧ください。
製品ドキュメント:
- Azure Kubernetes Service
- Azure Monitor の概要
- Azure の Linux 仮想マシン
- Azure のプライベート Docker コンテナー レジストリ
- AKS でのアプリケーションとクラスターに対するセキュリティの概念
- AKS ランディング ゾーン アクセラレータ
Microsoft Learn モジュール：
- Docker を使用してコンテナー化された Web アプリケーションを構築する
- コンテナー化されたアプリケーションを Azure Kubernetes Service にデプロイする
- Azure Kubernetes Service (AKS) を実装する
- Azure Monitor を使用したリソースの使用状況、パフォーマンス、および可用性の監視