次の方法で共有

GitOps を使用した CI/CD ワークフロー (Flux v2)

  • [アーティクル]

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

この記事では、Azure Arc、Azure Repos、Azure Pipelines を使用したアプリケーション変更の完全ライフサイクルにおいて GitOps がどのように適合するかについて説明します。 GitOps で制御される Kubernetes 環境でアプリケーションを 1 つ変更する例も示します。

アーキテクチャ

この図は、1 つ以上の Kubernetes 環境にデプロイされたアプリケーションの CI/CD ワークフローを示しています。

GitOps CI/CD アーキテクチャを示す図。

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

アプリケーション リポジトリには、開発者が内部の開発工程で作業するアプリケーション コードが含まれています。 アプリケーションの展開テンプレートは、このリポジトリ内に通常の形式 (Helm や Kustomize など) で格納されています。 環境固有の値はリポジトリに格納されません。

このリポジトリが変更されると、デプロイ処理を開始する PR または CI パイプラインが呼び出されます。

コンテナー レジストリ

コンテナー レジストリには、Kubernetes 環境で使用される第一のイメージとすべてのサードパーティ製のイメージが保持されています。 人間が判読できるタグと、イメージのビルドに使用される Git コミットを使用して、ファーストパーティのアプリケーション イメージにタグが付けられます。 サードパーティのイメージは、セキュリティ、速度、回復性に役立つようキャッシュされる場合があります。 セキュリティ パッチを適時にテストおよび統合するための計画が設定されます。

詳細については、「Azure Container Registry タスクを使用してパブリック コンテンツを使用および保守する方法」を参照してください。

PR パイプライン

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

CI パイプライン

アプリケーションの CI パイプラインでは、すべての PR パイプライン ステップが実行され、テストとデプロイのチェックが拡張されます。 このパイプラインは、メインへのコミットごとに実行するか、コミットのグループを使用して定期的に実行することができます。

この段階では、PR パイプラインにとって負担が大きすぎるアプリケーション テストを実行できます。これには、次のものが含まれます。

  • コンテナー レジストリへのイメージのプッシュ
  • イメージの構築、リンティング、テスト
  • 生の YAML ファイルのテンプレート生成

CI ビルドが終了すると、成果物が生成されます。 これらの成果物は、CD ステップで使用して、デプロイの準備として使用できます。

Flux クラスターの拡張機能

Flux は、クラスター拡張機能として各クラスターで実行されるエージェントです。 この Flux クラスター拡張機能は、目的の状態を維持します。 エージェントは、ユーザー定義の間隔で GitOps リポジトリをポーリングし、Git リポジトリで宣言された状態とクラスターの状態を調整します。

詳細については、チュートリアル: GitOps with Flux v2 を使ってアプリケーションをデプロイする方法に関するページを参照してください。

CD パイプライン

CD パイプラインは、正常な CI ビルドによって自動的にトリガーされます。 このパイプライン環境では、環境固有の値が以前に公開されたテンプレートに置き換えられ、これらの値を使用して GitOps リポジトリに対して新しい pull request を生成します。 この pull request には、1 つ以上の Kubernetes クラスターの望ましい状態に対して提案された変更が含まれる場合があります。 クラスター管理者は、pull request を確認し、GitOps リポジトリへのマージを承認します。 パイプラインは pull request がマージされるのを待機し、その後 Flux が同期され、状態の変更が適用されます。

GitOps リポジトリ

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

GitOps コネクタ

GitOps コネクタによって、Flux エージェントと GitOps リポジトリ/CD パイプラインの間に接続が作成されます。 クラスターに変更を適用すると、Flux によって GitOps コネクタに、すべてのフェーズ変更と正常性チェックが実行されたことが通知されます。 このコンポーネントはアダプターとして機能します。 これは Git リポジトリと通信する方法を理解していて、同期の進行状況が GitOps リポジトリに表示されるように Git コミットの状態を更新します。 デプロイが完了すると (成功か失敗かに関わらず)、コネクタによって CD パイプラインに続行が通知され、パイプラインが統合テストなどのデプロイ後のアクティビティを実行できるようします。

Kubernetes クラスター

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

ワークフローの例

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

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

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

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

  1. アリスは展開テンプレートを変更して、アプリケーション リポジトリの alice と呼ばれるリモート ブランチにそれをプッシュし、main ブランチに対する確認のために pull request を開きます。

  2. アリスは、変更を確認するように自分のチームに依頼します。

    • PR パイプラインによって検証が実行されます。
    • PR パイプラインの実行と、チームの承認が成功すると、変更がマージされます。

  3. CI パイプラインによってアリスの変更が開始されて検証され、正常に完了します。

    • 変更はクラスターに安全にデプロイでき、成果物は CI パイプラインの実行に保存されます。

  4. CI パイプラインの実行が成功すると、CD パイプラインがトリガーされます。

    • CD パイプラインでは、アリスの CI パイプラインの実行によって格納された成果物が取得されます。
    • CD パイプラインでは、テンプレートが環境固有の値に置き換えられ、GitOps リポジトリ内の既存のクラスターの状態に対する変更がステージングされます。
    • CD パイプラインでは、クラスターの状態に対して必要な変更を加えて、GitOps リポジトリの実稼働ブランチに pull request が作成されます。

  5. アリスのチームは、アリスの pull request を確認して承認します。

    • この変更は、環境に対応するターゲット ブランチにマージされます。

  6. 数分で、Flux によって GitOps リポジトリの変更が認識され、アリスの変更がプルされます。

    • Docker イメージが変更されたため、アプリケーション ポッドには更新が必要となります。
    • Flux によって、クラスターに変更が適用されます。
    • Flux は、GitOps コネクタを使用してデプロイの状態を GitOps リポジトリに報告します。

  7. CD パイプラインは、自動テストを実行して、新しいデプロイが正常に完了し、期待したとおりに動作することを確認します。

    Note

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

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

次のステップ