GitOps は、ソフトウェア システムを運用および管理する際の一連の原則です。 この記事では、GitOps の原則を使って Azure Kubernetes Services (AKS) クラスターを運用および管理する手法について説明します。
Flux、Argo CD、OPA Gatekeeper、Kubernetes、git のロゴは、各社の商標です。 これらのマークを使用することが、保証を意味するものではありません。
アーキテクチャ
AKS で使用できる GitOps オペレーターは Flux と Argo CD の 2 つです。 これらは Cloud Native Computing Foundation (CNCF) のグラデュエート プロジェクトであり、広く使われています。 次のシナリオは、これらの使用方法を示しています。
シナリオ 1: GitOps と Flux、AKS との併用
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 1 のデータフロー
Flux は、AKS のネイティブ クラスター拡張機能です。 クラスター拡張機能には、AKS クラスターにソリューションをインストールし、管理するためのプラットフォームが用意されています。 AKS の拡張機能として Flux を有効にするには、Azure portal、Azure CLI、またはコードとしてのインフラストラクチャ (IaC) スクリプト (Terraform、Bicep スクリプトなど) を使用できます。 また、Azure Policy を使って、AKS クラスターに Flux v2 構成を大規模に適用することもできます。 詳細については、「Flux v2 構成と Azure Policy を使用して、アプリケーションを一貫して大規模にデプロイする」を参照してください。
Flux を使うと、Kubernetes マニフェスト、Helm グラフ、Kustomization ファイルを AKS にデプロイできます。 Flux はポーリングベースのプロセスなので、クラスターのエンドポイントをビルド エージェントに公開することなく、構成の変更の検出、プル、調整を行うことができます。
このシナリオの場合、Kubernetes 管理者は、シークレットや ConfigMaps などの Kubernetes 構成オブジェクトを変更し、その変更を GitHub リポジトリに直接コミットできます。
このシナリオのデータ フローは次のとおりです。
- 開発者が構成変更を GitHub リポジトリにコミットします。
- Flux により、Git リポジトリ内の構成のドリフトが検出され、構成の変更がプルされます。
- Flux により、Kubernetes クラスターの状態が調整されます。
シナリオ 1 の代替方法
- Flux は、Azure DevOps、GitLab、BitBucket などの他の Git リポジトリと共に使用できます。
- Git リポジトリではなく、Flux Bucket API を使うと、Amazon S3 や Google Cloud Storage バケットなどのストレージ ソリューションのオブジェクトに対して、成果物を生成するソースを定義できます。 また、S3 互換の API を持つソリューションを使うこともできます。 2 つの例は Minio と Alibaba Cloud OSS ですが、他にもあります。
- また、成果物を生成するソースとして Azure Blob Storage コンテナーに対して Flux を構成することもできます。 詳細については、「AKS および Azure Arc 対応 Kubernetes を使用した GitOps Flux v2 構成」を参照してください。
シナリオ 2: GitOps と Flux、GitHub、AKS を併用して CI/CD を実装する
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 2 のデータフロー
このシナリオは、一般的な Web アプリケーションに対応するプルベースの DevOps パイプラインです。 このパイプラインでは、ビルドに GitHub Actions を使います。 デプロイには、アプリをプルして同期する GitOps オペレーターとして Flux を使います。 このシナリオのデータ フローは次のとおりです。
- このアプリ コードは、Visual Studio Code などの IDE を使って開発しています。
- アプリ コードが GitHub リポジトリにコミットされます。
- GitHub Actions でアプリ コードからコンテナー イメージがビルドされ、コンテナー イメージが Azure Container Registry にプッシュされます。
- GitHub Actions は、Azure Container Registry 内のコンテナー イメージのバージョン番号に基づいて、現在のイメージ バージョンで Kubernetes マニフェスト デプロイ ファイルを更新します。
- Flux オペレーターにより、Git リポジトリ内の構成のドリフトが検出され、構成の変更がプルされます。
- Flux は、アプリを AKS クラスターにデプロイするためにマニフェスト ファイルを使います。
シナリオ 3: GitOps と、Argo CD、GitHub リポジトリ、AKS の併用
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 3 のデータフロー
このシナリオの場合、Kubernetes 管理者は、シークレットや ConfigMaps などの Kubernetes 構成オブジェクトを変更し、その変更を GitHub リポジトリに直接コミットできます。
このシナリオのデータ フローは次のとおりです。
- Kubernetes 管理者は、YAML ファイルで構成の変更を行い、その変更を GitHub リポジトリにコミットします。
- Argo CD は Git リポジトリから変更をプルします。
- Argo CD は AKS クラスターに合わせて構成の変更を調整します。
Argo CD で、目的のターゲット状態を AKS クラスターに自動的に同期する必要はありません。 これは、実行中のアプリケーションを継続的に監視する Kubernetes コントローラーとして実装されています。 AKS クラスターの現在のライブ状態と、Git リポジトリ内の指定した目的のターゲット状態が比較されます。 Argo CD には、その差異を報告し、視覚化する機能があります。また、ライブ状態を目的のターゲット状態に戻す自動または手動の同期機能もあります。
Argo CD にはブラウザーベースのユーザー インターフェイスがあります。 これを使って、アプリケーションの構成を追加し、クラスターに対する同期状態を観察し、クラスターに対する同期を開始することができます。 また、Argo CD コマンド ラインを使って、これらの操作を行うこともできます。 ユーザー インターフェイスとコマンド ライン インターフェイスの両方に、構成の変更履歴を表示し、以前のバージョンにロールバックする機能があります。
既定では、Argo CD ユーザー インターフェイスと API サーバーは公開されません。 それらにアクセスするには、内部 IP アドレスを持つイングレス コントローラーを作成することをお勧めします。 また、内部のロード バランサーを使ってそれらを公開することもできます。
シナリオ 3 の代替方法
Azure DevOps などの Git と互換性のあるリポジトリであれば、構成ソース リポジトリとして利用できます。
シナリオ 4: GitOps と Argo CD、GitHub Actions、AKS を併用して CI/CD を実装する
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオ 4 のデータフロー
このシナリオは、一般的な Web アプリケーションに対応するプルベースの DevOps パイプラインです。 このパイプラインでは、ビルドに GitHub Actions を使います。 デプロイの場合、GitOps オペレーターとして Argo CD を使ってアプリのプルと同期を行います。 このシナリオのデータ フローは次のとおりです。
- このアプリ コードは、Visual Studio Code などの IDE を使って開発しています。
- アプリ コードが GitHub リポジトリにコミットされます。
- GitHub Actions でアプリ コードからコンテナー イメージがビルドされ、コンテナー イメージが Azure Container Registry にプッシュされます。
- GitHub Actions は、Azure Container Registry 内のコンテナー イメージのバージョン番号に基づいて、現在のイメージ バージョンで Kubernetes マニフェスト デプロイ ファイルを更新します。
- Argo CD は Git リポジトリからプルします。
- Argo CD は、アプリを AKS クラスターにデプロイします。
シナリオ 4 の代替方法
Azure DevOps などの Git と互換性のあるリポジトリであれば、構成ソース リポジトリとして利用できます。
シナリオの詳細
GitOps は、ソフトウェア システムを運用および管理する際の一連の原則です。
- システムの信頼できる唯一の情報源としてソース管理が使われています。
- バージョン コントロール、コラボレーション、コンプライアンス、継続的インテグレーションと継続的デプロイ (CI/CD) などの開発プラクティスがインフラストラクチャ自動化に適用されます。
- これはあらゆるソフトウェア システムに適用できます。
GitOps は、Kubernetes のクラスター管理とアプリケーション配信によく使われます。 この記事では、GitOps を AKS クラスターと共に使う際の一般的なオプションについて説明します。
GitOps の原則によると、GitOps で管理されるシステムの目的の状態は、以下のとおりである必要があります。
- 宣言型である: GitOps で管理されるシステムは、その目的の状態を宣言的に表す必要があります。 通常、この宣言は Git リポジトリに格納されます。
- バージョン管理され、不変である: 目的の状態は、不変性とバージョン管理を適用し、完全なバージョン履歴を保持する方法で格納されます。
- 自動的にプルされる: ソフトウェア エージェントは、ソースから目的の状態宣言を自動的にプルします。
- 継続的に調整される: ソフトウェア エージェントは、実際のシステム状態を継続的に観察し、目的の状態を適用しようとします。
GitOps では、コードとしてのインフラストラクチャ (IaC) は、コードを使って、仮想マシン (VM)、ネットワーク、ファイアウォールなどのインフラストラクチャ コンポーネントの必要な状態を宣言します。 このコードはバージョン コントロールされ、監査できます。
Kubernetes は、マニフェストを使った宣言によって、クラスター状態からアプリケーション デプロイに至るすべてを記述します。 GitOps for Kubernetes では、クラスター インフラストラクチャの必要な状態が、バージョン コントロールに配置されます。 クラスター内のコンポーネント (通常はオペレーターと呼ばれます) は、宣言型の状態を継続的に同期します。 この方法で、クラスターに影響するコード変更を確認し、監査できます。 最小特権の原則をサポートすることで、セキュリティを強化できます。
GitOps エージェントは、コード リポジトリに格納されている目的の状態を使って、システムの状態を継続的に調整します。 一部の GitOps エージェントでは、Kubernetes オブジェクトの手動作成など、クラスターの外部で実行される操作を元に戻すことができます。 たとえば、アドミッション コントローラーを使うと、作成、更新、削除の操作中にオブジェクトにポリシーを適用できます。 これらを使うと、ソース リポジトリ内のデプロイ コードが変更された場合にのみ、デプロイを変更できます。
ポリシーの管理と適用のツールを GitOps と組み合わせて、ポリシーを適用し、提案されたポリシーの変更に対してフィードバックを提供することができます。 さまざまなチームに対して通知を構成して、最新の GitOps 状態を提供できます。 たとえば、デプロイの成功と調整の失敗の通知を送信できます。
信頼できる唯一の情報源としての GitOps
GitOps には、クラスター状態の整合性と標準化の機能があり、セキュリティの強化に役立てることができます。 また、GitOps を使って、複数のクラスター間で一貫した状態を確保することもできます。 たとえば、GitOps は、プライマリとディザスター リカバリー (DR) のクラスター、またはクラスターのファーム全体で同じ構成を適用できます。
GitOps のみがクラスターの状態を変更できるようにする場合は、クラスターへの直接アクセスを制限できます。 これを行うには、Azure ロールベースのアクセス制御 (RBAC)、アドミッション コントローラー、その他のツールなど、さまざまな方法があります。
GitOps を使って初期構成をブートストラップする
ベースライン構成の一部として AKS クラスターをデプロイする必要性が生じることがあります。 たとえば、ワークロードをデプロイする前に、一連の共有サービスまたは構成をデプロイする必要がある場合です。 これらの共有サービスでは、次のような AKS アドオンを構成できます。
- Microsoft Entra ワークロード ID。
- シークレット格納 CSI ドライバーの Azure Key Vault プロバイダー。
- 次のようなパートナー ツール:
- 次のようなオープンソース ツール:
Flux は、AKS クラスターを作成するときに適用される拡張機能として有効にすることができます。 Flux は、ベースライン構成をクラスターにブートストラップすることができます。 AKS クラスターのベースライン アーキテクチャに関する記事では、ブートストラップに GitOps を使うことが提案されています。 Flux 拡張機能を使うと、デプロイ後すぐにクラスターをブートストラップできます。
その他の GitOps ツールとアドオン
説明されているシナリオを他の GitOps ツールに拡張できます。 Jenkins X も、Azure に統合する手順が用意されている GitOps ツールです。 Flagger などのプログレッシブ デリバリー ツールを使うと、GitOps を介してデプロイされる運用ワークロードを段階的に移行することができます。
考えられるユース ケース
このソリューションは、すべての変更の監査証跡を使用して、アプリケーションとインフラストラクチャをコードとして展開する利点を必要とするすべての組織にとってメリットがあります。
GitOps を使うと、開発者は複雑なコンテナー環境の管理を行わずに済みます。 開発者は、Git のような使い慣れたツールを引き続き使って更新プログラムと新機能を管理できます。 このような方法で、GitOps を使って開発者の生産性を高めることができます。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
信頼性の重要な柱の 1 つは回復性です。 回復性の目的は、障害の発生後にアプリケーションを十分に機能する状態に戻すことです。 クラスターが使用不能になった場合、GitOps はすぐに新しく作成します。 Kubernetes の構成とアプリケーション ロジックに関する信頼できる唯一の情報源として、Git リポジトリが使われます。 クラスターの構成とアプリケーションのデプロイをスケール ユニットとして作成し、適用することができます。また、デプロイ スタンプ パターンを確立することができます。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
GitOps アプローチでは、個々の開発者または管理者が Kubernetes クラスターに直接アクセスして変更や更新を適用することはありません。 代わりに、ユーザーが変更を Git リポジトリにプッシュすると、GitOps オペレーター (Flux または Argo CD) によって変更が読み取られ、クラスターに適用されます。 このアプローチは、Kubernetes API への書き込みアクセス許可を DevOps チームに付与しないことによって、最小の特権のセキュリティのベスト プラクティスに従います。 診断またはトラブルシューティングのシナリオでは、クラスターのアクセス許可を特定の時間に限定して付与することができます。
リポジトリのアクセス許可を設定するタスクとは別に、Azure Kubernetes Service クラスターに同期する Git リポジトリ内に次のセキュリティ対策を実装することを検討してください。
- ブランチ保護: Kubernetes クラスターの状態を表すブランチを保護して、変更が直接プッシュされないようにします。 PR を使って変更を加え、少なくとも 1 人の別の担当者が各 PR を確認するようにします。 また、PR を使って、自動チェックを実行します。
- PR のレビュー: 4 つの目の原則 (必ず 2 人が目を通す) を適用するには、少なくとも 1 人のレビュー担当者が必要です。 また、GitHub コード所有者機能を使用して、リポジトリ内の特定のファイルのレビューに責任を持つ個人またはチームを定義することもできます。
- 変更不可能な履歴: 新しいコミットを既存の変更に加えてのみ許可します。 監査目的では、変更不可能な履歴が特に重要です。
- 追加のセキュリティ対策: GitHub ユーザーに 2 要素認証のアクティブ化を要求します。 また、署名されたコミットのみを許可して、変更を防ぎます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
- Free レベルでは、AKS には無料のクラスター管理機能があります。 コストは、AKS がノードのホストに使うコンピューティング、ストレージ、ネットワークの各リソースに限定されます。
- GitHub は無料のサービスを提供していますが、コード所有者や必要なレビュー担当者など、セキュリティ関連の高度な機能を使用するには、Team プランが必要です。 詳細については、GitHub の価格に関するページを参照してください。
- Azure DevOps は、一部のシナリオに使用できる Free レベルを提供しています。
- コストの見積もりには、Azure 料金計算ツールをご利用ください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
GitOps を使用すると DevOps の生産性が向上します。 最も便利な機能の 1 つは、Git 操作を実行するだけで、予期しない動作になる変更を迅速にロールバックできることです。 コミット グラフには、まだすべてのコミットが含まれているので、事後分析に役立てられます。
GitOps チームは、多くの場合、同じアプリケーションの複数の環境を管理します。 アプリケーションの複数の段階を異なる Kubernetes クラスターまたは名前空間にデプロイするのが一般的です。 信頼できる単一の情報源である Git リポジトリは、現在クラスターにデプロイされているアプリケーションのバージョンを示しています。
シナリオをデプロイする
次の一覧は、5 つのシナリオのデプロイに関する情報の参照先です。
- シナリオ 1: GitOps with Flux v2 を使って AKS にアプリケーションをデプロイする際のガイダンスについては、「チュートリアル: GitOps with Flux v2 を使ってアプリケーションをデプロイする」を参照してください。 Flux 拡張機能を使って AKS クラスター デプロイをブートストラップする方法の例については、AKS ベースラインの参照実装のページを参照してください。
- シナリオ 2: GitOps with Flux v2 on AKS を使ってアプリケーションをデプロイし、CI/CD を実装する際のガイダンスについては、「チュートリアル: GitOps (Flux v2) を使用して CI/CD を実装する」を参照してください。
- シナリオ 3、4: Argo CD と AKS を使ってサンプル ワークロードをデプロイする手順のガイダンスについては、「AKS ベースラインのオートメーション」のプルベースの CI/CD シナリオを参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Francis Simy Nazareth | Principal Cloud Solutions Architect
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。