GitOps は何と違い、何の上に立つのか — 関連する実践とパターン
一言でいうと
IaC・CaCは「状態をファイルに書く」までで、CI/CDは「あらかじめ決めたトリガーで自動化する」ものであり、GitOpsはその上に、エージェントが自分で取り込み、ずれがあるたびに合わせる部分(それぞれpullとreconcile)を加えたものです。パターンとは、この調整ループをどこに置き、いつ起こすかの選択です。
なぜ必要なのか
CGOAのRelated Practicesドメイン(16%)は、GitOpsを隣接する概念と区別するよう求めます。実務では「うちはTerraformをGitに置いているからGitOpsだ」「Jenkinsがkubectl applyを実行するからGitOpsだ」という言葉をよく耳にしますが、OpenGitOpsの原則に照らすと、どちらも半分しか合っていません。原則3(Pulled Automatically)と原則4(Continuously Reconciled)が欠けているからです。境界を正確に知っていて初めて、何を加えればGitOpsになるのかを語れます。
Patternsドメイン(20%)は、その次の問いです。調整器(reconciler)をクラスターの中に置くか外に置くか、定期的に取り込むかイベントで起こすか、段階的デプロイをGitOpsのループにどう組み込むか、ステートストアをGitだけにするか。それぞれの選択には、公式ドキュメントが書き残している理由があります。
どう動くのか
関連プラクティス: CNCF用語集の定義で区別する
| プラクティス | CNCF用語集の定義 | GitOpsとの関係 |
|---|---|---|
| IaC | インフラの定義をファイルとして保存し、手動のプロビジョニングを置き換えます。信頼できる唯一の情報源であり、CI/CDパイプラインで管理されます | 原則1・2(宣言的、バージョン管理・不変)を満たします。原則3・4は、ツールによってあることもないこともあります |
| CaC | 設定をコードのようにバージョン管理します。opengitops.devに載っているKelsey Hightowerの言葉「GitOpsはconfiguration as code以来の最良のもの」が、その関係を要約しています | リポジトリは同じですが、GitOpsは適用の主体を、人やパイプラインからエージェントへ移します |
| DevOps | 開発から運用まで、1つのチームがすべての工程を所有します。引き継ぎを減らす、文化とプロセスの転換です | GitOpsは、その文化を実現する運用方式の1つです |
| DevSecOps | DevOpsにセキュリティの責任を統合します。自動化されたCI/CDワークフローとポリシーの強制により、開発者を妨げることなくセキュリティを徹底します | Gitのレビューと監査履歴、そして調整器の最小権限が、そのポリシー強制の置き場所になります |
| CI | コードの変更をできるだけ頻繁に統合します。コミットから始まり、テスト済みのアーティファクトで終わります | GitOpsはCIを置き換えません。CIが作ったアーティファクトを参照する宣言が、GitOpsの入力です |
| CD | 変更を受け入れ環境(continuous deploymentなら本番)へ自動でデプロイします。テストとロールバックの手順を含みます | 従来のCDはトリガーで押し込み(push)、GitOpsはエージェントが取り込みます(pull) |
OpenGitOpsの用語集は、pullを次のように説明します。エージェントが変更があるときだけでなく、いつでもステートストアの望ましい状態(desired state)にアクセスできなければならず、そうであって初めて原則4の継続的な調整が可能になります。従来のCI/CDは「あらかじめ決めたトリガー」で自動化が動きますが、GitOpsの調整はずれ(divergence)があるたびに起こり、ずれは、意図して新しいバージョンを上げたときだけでなく、実際の状態が意図せず流れていったとき(drift)にも生じます。フィードバック(feedback)は制御理論の閉ループから来た言葉で、以前の適用の試みが実際の状態にどんな影響を与えたかを指し、エージェントはそれに応じて、リトライ、ロールバック、アラートを行います。
パターン1: pullの周期とイベント駆動の調整
2つの調整器とも、デフォルトは定期的なpullです。Argo CDはGit・OCI・Helmのリポジトリを3分ごとにポーリングし、FluxのKustomizationは5分ごと(.spec.interval)に調整します。この遅延をなくすために、どちらもWebhookを受け付けます。Argo CDはAPIサーバーの/api/webhookでGitHub・GitLab・Bitbucket・Azure DevOpsなどのpushイベントを受け取り、Fluxはnotification-controllerのReceiver(ポート9292)がGitHub・GitLab・Harbor・Jenkinsなどのイベントを受け取って、「pullパイプラインをpushと同じくらい反応的に」します。
重要なのは、Webhookが原則3を破らないという点です。Argo CDのドキュメントは、Webhookのペイロードを信頼せず、認証されていないイベントが来ても行うのは、3分ごとにどのみち起こるrefreshだけだと書いています。イベントは「今取りに行け」という合図にすぎず、状態を押し込みません。イベント駆動の調整は、pullを置き換えるのではなく、pullのタイミングを前倒しするものです。
パターン2: 調整器がクラスターの中にあるか外にあるか
in-clusterの調整器は、自分が動いているクラスターを合わせます。Argo CDのdestination.server: https://kubernetes.default.svcがそれで、Fluxはbootstrapによって自分自身まで同じ方式で管理します。externalの調整器は、1か所から複数のクラスターを合わせます。Argo CDは、対象クラスターの認証情報を、argocd.argoproj.io/secret-type: clusterラベルが付いたSecret(name、server、config)として登録し、namespacesでアクセス範囲を絞れます。Fluxのドキュメントも「1つのクラスターから、同じクラスターや別のクラスターのアプリを管理できる」と書いています。違いは、認証情報がどこに集まるかです。in-clusterでは各クラスターが自分の分だけを持ち、externalでは管理クラスターがすべてのクラスターの認証情報を持ちます。
パターン3: 段階的デプロイをループの中に入れる
Fluxの用語集は、段階的デプロイ(progressive delivery)を「新機能を一部のユーザーに先に出して観察し、調整したうえで全体にデプロイすること」と定義し、カナリア・A/B・フィーチャーフラグを手法として挙げています。FluxではFlaggerという別のコントローラーが、ArgoではArgo Rolloutsがこれを担います。Argo Rolloutsは、Deploymentの代わりにRolloutリソースでReplicaSetを管理し、spec.templateが変わるとstrategy(blue-green、canary)に従って進め、メトリクス分析を通過すると新しいReplicaSetをstableとして印を付けます。GitOpsの観点での核心は、デプロイ戦略そのものが宣言(desired state)の一部だという点です。Gitには「新しいイメージ」と「10%ずつ増やしながらエラー率を見る」が一緒に書かれ、調整器はその宣言どおりに少しずつ合わせていきます。
パターン4: ステートストアを何にするか
OpenGitOpsの用語集は、ステートストア(state store)を「不変バージョンの望ましい状態を保存し、アクセス制御と監査を提供するシステム」と定義し、Gitが名前の由来であり代表的な事例だが、条件を満たす他のシステムでもよいと書いています。FluxはOCIRepositoryとOCIアーティファクトで「Gitless GitOps」を実現しました。ユーザーは依然としてGitで状態を管理しますが、コントローラーはコンテナレジストリだけを見るので、Gitサーバーが運用上の依存関係から外れます。Argo CDも、Kustomize・Helm・OCIイメージ・YAMLディレクトリ・プラグインをソースとして受け付けます。逆に、Argo CDの--localマニフェストのアップロードは、ドキュメント自身が「GitOpsのアンチパターン」と呼ぶ、開発用の機能です。
現場での姿
あるチームがJenkinsからkubectl applyでデプロイしていて、Argo CDを導入する際に、Jenkinsのapplyステップを残してしまいました。2つの主体が同じリソースをめぐって互いに元に戻し合う状況になり、Argo CDはずっとOutOfSyncを報告していました。CIの役割を「イメージを作り、Gitのタグを変える」までに減らすと、問題は消えました。CIとGitOpsの境界を決めないと起きる、典型的な事例です。
段階的デプロイでは、自動ロールバックがトラフィックとReplicaSetを元に戻しますが、Gitの宣言はそのままだという点を見落としがちです。調整器は依然として新しいイメージを望ましい状態と見ているので、人がGitを元に戻すまで、同じ試みが繰り返される可能性があります。ロールバックをGitのコミットで締めくくる手順が必要です。
次の理論で見ること
続く理論では、このパターンを実装する2つのツール、Argo CDとFluxの構造を実際に見比べ、アラート・オブザーバビリティ・CI連携がどこにつながるかを見ます。参考: OpenGitOps Principles、GitOps Glossary、CNCF Glossary: GitOps、Argo CD Webhook Configuration、Flux Core Concepts、Flux Webhook Receivers。