GitOps を使用した CI/CD ワークフロー - Azure Arc 対応 Kubernetes

  • [アーティクル]

重要

このドキュメントで取り上げるワークフローでは、Flux v1 による GitOps が使用されています。 Azure Arc 対応 Kubernetes と Azure Kubernetes Service (AKS) クラスターで、Flux v2 による GitOps を使用できるようになりました。Flux v2 による GitOps を使用した CI/CD ワークフローに関するページを参照してください。 できるだけ早く Flux v2 に移行 することをお勧めします。

2024 年 1 月 1 日より前に作成された Flux v1 ベースのクラスター構成リソースのサポートは、2025 年 5 月 24 日に終了します。 2024 年 1 月 1 日から、新しい Flux v1 ベースのクラスター構成リソースを作成することはできません。

最近の Kubernetes のデプロイには、複数のアプリケーション、クラスター、環境が収容されています。 GitOps を使用すると、これらの複雑な設定をより簡単に管理でき、Git を使用して宣言によって Kubernetes 環境の望ましい状態を追跡できます。 共通の Git ツールを使用してクラスターの状態を追跡することにより、アカウンタビリティが向上し、障害の調査が容易になり、環境の管理を自動化することができます。

この概念の概要では、Azure Arc、Azure Repos、Azure Pipelines を使用したアプリケーション変更の完全ライフサイクルにおける現実としての GitOps について説明します。 ここをクリックすると、GitOps で制御される Kubernetes 環境でアプリケーションを 1 つ変更する例にジャンプします。

アーキテクチャ

1 つ以上の Kubernetes 環境にデプロイされたアプリケーションについて考えてみましょう。

GitOps CI/CD architecture

アプリケーション リポジトリ

アプリケーション リポジトリには、開発者が内部の開発工程で作業するアプリケーション コードが含まれています。 アプリケーションの展開テンプレートは、このリポジトリ内に通常の形式 (Helm や Kustomize など) で格納されています。 環境固有の値は格納されません。 このリポジトリが変更されると、デプロイ処理を開始する PR または CI パイプラインが呼び出されます。

Container Registry

コンテナー レジストリには、Kubernetes 環境で使用される第一のイメージとすべてのサードパーティ製のイメージが保持されています。 人間が判読できるタグと、イメージのビルドに使用される Git コミットを使用して、ファーストパーティのアプリケーション イメージにタグが付けられます。 セキュリティ、速度、および回復力のために、サードパーティ製のイメージがキャッシュされます。 セキュリティ パッチを適時にテストおよび統合するための計画が設定されます。 詳細については、Azure Container Registry を使用してパブリック コンテンツを使用および保守する方法に関するページを例として参照してください。

PR パイプライン

アプリケーション リポジトリに対する PR は、PR パイプラインが正常に実行されたときにゲートが実行されます。 このパイプラインでは、アプリケーション コードでのリンティングや単体テストなどの基本的な品質ゲートが実行されます。 このパイプラインでは、アプリケーションがテストされ、Kubernetes 環境へのデプロイに使用される Dockerfile と Helm テンプレートがリンティングされます。 Docker イメージはビルドしてテストする必要がありますが、プッシュされません。 迅速に反復処理できるように、パイプラインの継続時間が比較的短くなるようにしてください。

CI パイプライン

アプリケーションの CI パイプラインでは、すべての PR パイプライン ステップが実行され、テストとデプロイのチェックが拡張されます。 このパイプラインは、コミットごとに実行するか、コミットのグループを使用して定期的に実行することができます。 この段階では、PR パイプラインには長すぎるアプリケーション テストを実行します。 デプロイの準備として Docker イメージをビルドした後に、コンテナー レジストリにプッシュします。 置換されたテンプレートに対しては、一連のテスト値を使用してリンティングできます。 サービス実行時に使用されるイメージは、この時点でリンティング、ビルド、テストする必要があります。 特に CI ビルドでは、成果物が CD ステップに対して公開され、デプロイの準備で使用されます。

Flux

Flux は、各クラスターで実行されるサービスであり、望ましい状態を維持する役割を担います。 このサービスでは、クラスターに対する変更について GitOps リポジトリを頻繁にポーリングし、それらを適用します。

CD パイプライン

CD パイプラインは、正常な CI ビルドによって自動的にトリガーされます。 以前に公開されたテンプレートを使用して、環境の値に置き換え、PR を GitOps リポジトリに開いて、1 つ以上の Kubernetes クラスターを望ましい状態にする変更を要求します。 クラスター管理者は、状態変更 PR を確認し、GitOps リポジトリへのマージを認可します。 その後、このパイプラインは、その PR が完了するまで待機します。これにより、Flux で状態の変更を取得できるようになります。

GitOps リポジトリ

GitOps リポジトリは、クラスター内のすべての環境の現在の望ましい状態を表します。 このリポジトリに対する変更は、各クラスターの Flux サービスによって取得されてデプロイされます。 PR は、望ましい状態への変更を使用して作成され、レビューおよびマージされます。 これらの PR には、展開テンプレートと、結果としてレンダリングされる Kubernetes マニフェストの両方に対する変更が含まれています。 マニフェストを詳細にレンダリングすると、テンプレートレベルでは通常見られない変更を一層注意深く調べることができます。

Kubernetes クラスター

少なくとも 1 つの Azure Arc 対応 Kubernetes クラスターで、アプリケーションで必要とされるさまざまな環境が提供されます。 たとえば、1 つのクラスターで異なる名前空間を使用して、開発環境と QA 環境の両方を提供できます。 2 つ目のクラスターを使用すると、環境の分離が容易になり、よりきめ細かい制御が可能になります。

ワークフローの例

アプリケーション開発者として、アリスは次のことを行います。

  • アプリケーション コードを記述します。
  • Docker コンテナーでアプリケーションを実行する方法を決定します。
  • Kubernetes クラスター内のコンテナーと依存サービスを実行するテンプレートを定義します。

アリスは、複数の環境で実行する機能がアプリケーションに必要であることは知っていますが、各環境に固有の設定は知りません。

アプリケーションの展開テンプレートで使用される Docker イメージが変更されるようなアプリケーションの変更をアリスが行うとします。

  1. アリスは展開テンプレートを変更して、アプリケーション リポジトリのリモート ブランチにそれをプッシュし、確認のために PR を開きます。
  2. アリスは、変更を確認するように自分のチームに依頼します。
    • PR パイプラインによって検証が実行されます。
    • パイプラインの実行が成功すると、チームがサインオフし、変更がマージされます。
  3. CI パイプラインによってアリスの変更が検証され、正常に完了します。
    • 変更はクラスターに安全にデプロイでき、成果物は CI パイプラインの実行に保存されます。
  4. アリスの変更によって、CD パイプラインがマージされてトリガーされます。
    • CD パイプラインでは、アリスの CI パイプラインの実行によって格納された成果物が取得されます。
    • CD パイプラインでは、テンプレートが環境固有の値に置き換えられ、GitOps リポジトリ内の既存のクラスターの状態に対する変更がステージングされます。
    • CD パイプラインでは、クラスターの状態に対して必要な変更を加えて、GitOps リポジトリに PR が作成されます。
  5. アリスのチームは、アリスの PR を確認して認可します。
    • この変更は、環境に対応するターゲット ブランチにマージされます。
  6. 数分で、Flux によって GitOps リポジトリの変更が認識され、アリスの変更がプルされます。
    • Docker イメージが変更されたため、アプリケーション ポッドには更新が必要となります。
    • Flux によって、クラスターに変更が適用されます。
  7. アリスは、アプリケーション エンドポイントをテストして、デプロイが正常に完了したことを確認します。

    Note

    デプロイの対象である他の環境では、CD パイプラインで、次の環境の PR を作成することによって反復処理が行われ、手順 4-7 が繰り返されます。 この処理では、セキュリティ関連の変更や運用環境など、より危険性の高いデプロイや環境に対する追加の承認が必要となることがあります。

  8. すべての環境に正常にデプロイされると、パイプラインが完了します。

次のステップ

Azure Arc 対応 Kubernetes を使用して、構成リソースとして、クラスターと Git リポジトリ間の接続を作成する方法の詳細について説明します