GitOps — ArgoCD/Fluxと「Gitを信頼の源にする」宣言的デプロイ

「Gitを信頼の源(single source of truth)にする」というGitOpsの考え方は、宣言的な状態管理とクラスタ内エージェントによる継続的な調整で成り立ちます。ArgoCDとFluxを軸に、push型CIとの違いとAWS環境での勘所を整理します。

01GitOpsとは何か — Gitを「信頼の源」にする

GitOpsは、アプリケーションやインフラの「あるべき状態」をGitリポジトリに宣言的に記述し、そのGitを唯一の信頼の源(single source of truth)として扱う運用の考え方です。人がサーバやクラスタに直接手を入れるのではなく、Gitへのコミットを起点に、ソフトウェアエージェントが自動でその状態を反映・維持します。CNCFのGitOps Working Groupが運営するOpenGitOpsプロジェクトは、この考え方を4つの原則として明文化しました。

宣言的(Declarative)：システムのあるべき状態は宣言的に表現される。手順の羅列ではなく、YAMLなどで「こうあってほしい」を記述します。
バージョン管理・不変(Versioned and Immutable)：あるべき状態は不変性とバージョニングを担保する形で保存され、完全な変更履歴が残る。
自動的にプル(Pulled Automatically)：ソフトウェアエージェントが、あるべき状態の宣言をソースから自動的にプルする。
継続的に調整(Continuously Reconciled)：エージェントが実際の状態を継続的に観測し、あるべき状態を適用し続ける。

用語としてのGitOpsは、2017年にWeaveworksのAlexis Richardson氏が提唱したものが起点とされています。以来、Kubernetes(K8s)のエコシステムを中心に広がり、いまや宣言的デプロイの標準的な語彙になりました。この4原則自体はK8s専用の概念ではありませんが、宣言的APIと調整ループ(reconciliation loop)を前提とするK8sと相性が良く、実装が一気に進んだという経緯があります。

02push型CIとpull型GitOpsの違い

従来のCIパイプラインは、CIサーバがビルド後にkubectl applyやhelm upgradeを実行し、外側からクラスタへ変更を「押し込む(push)」構造です。これに対しGitOpsは、クラスタ内に常駐するエージェントがGitを監視し、変更を「引き込む(pull)」構造を取ります。この違いは些細に見えて、運用のセキュリティと信頼性に大きく効いてきます。

認証情報の置き場所：push型はCI側にクラスタの管理者相当クレデンシャルを持たせます。pull型ではエージェントがクラスタ内から自分でGitを取りに行くため、外部CIにクラスタの強い権限を渡さずに済みます。Argo CDの公式ドキュメント(Automated Sync Policy)も、自動同期の利点として「CI/CDパイプラインがデプロイのためにArgo CD APIサーバへ直接アクセスする必要がなくなる」と説明しています。
「適用したつもり」の排除：push型はパイプラインが通った時点で完了と見なしがちですが、その後クラスタが変化しても検知しません。pull型は継続的に調整し続けるため、Gitとの差分を常に監視できます。
監査性：すべての変更がGitのコミット履歴として残り、誰が・いつ・何を変えたかがそのまま監査ログになります。

現場のコツ：「GitOpsを入れる＝既存CIを捨てる」ではありません。CNCFも、既存のCIツールを捨てずにGitOpsを足せると明言しています。実務では、ビルド・テスト・イメージ作成まではこれまでのCIで行い、デプロイ(状態の反映)だけをGitOpsに任せる分業がスムーズです。CIはマニフェスト用リポジトリのタグを書き換えるところまで、その先はArgoCD/Fluxに渡す、という切り分けが定番です。

図：push型CIは外部からクラスタへ適用を押し込む。pull型GitOpsはクラスタ内エージェントがGitを監視し変更を引き込む。

03ArgoCD — 差分の可視化と同期

ArgoCDは、Intuit社が開発しCNCFに寄贈された「Kubernetes向けの宣言的GitOps継続的デリバリツール」です。Gitリポジトリをアプリケーションのあるべき状態の源として使い、稼働中のアプリケーションを継続的に監視して、Gitの目標状態とライブ状態を突き合わせます。ライブ状態がGitから乖離すると、そのアプリケーションはOutOfSyncとして表示されます。

差分の可視化：どのリソースがGitと食い違っているかをUI・CLIで確認できます。「設定ドリフトの自動検知と可視化」はArgoCDの中心機能です。
宣言的な自己管理：ArgoCDのApplicationやプロジェクト設定自体もK8sマニフェストとして宣言的に定義でき、kubectl applyで管理できます。ArgoCDを使う設定もまたGitで管理する、という一貫性が保てます。
同期の選択：手動同期(承認を挟む)と自動同期(Gitへのコミットで即反映)を、アプリケーション単位で選べます。エンタープライズでは本番だけ手動承認を残す、といった運用が現実的です。

04Flux — GitOps Toolkitとコントローラ群

Fluxは、Weaveworks発の「Kubernetes向けのオープンで拡張可能な継続的デリバリソリューション」で、GitOps Toolkitと呼ばれるコントローラ群の上に構成されています。FluxはK8sのAPI拡張機構(カスタムリソース)をフルに使う設計で、GitRepositoryやKustomization、HelmReleaseといったカスタムリソースとしてあるべき状態を宣言します。

調整(reconciliation)が中核：Fluxのコントローラは、Git・Helmリポジトリ・OCIレジストリに定義された目標状態と、クラスタ内の実状態を比較し、差分を埋める動作をします。この「調整」こそがGitOpsのエンジンです。
コンポーザブル：Source Controller / Kustomize Controller / Helm Controllerなどが役割ごとに分かれており、必要な部品だけを組み合わせられます。
マルチテナント・マルチリポジトリ：任意の数のGitリポジトリの同期やマルチテナントに対応し、大規模組織のプラットフォーム基盤に向いています。プログレッシブデリバリはFlaggerと組み合わせて実現します。

現場のコツ：ArgoCDとFluxはどちらが上位互換という関係ではありません。ざっくりした傾向として、アプリチームにセルフサービスのUIを提供したいならArgoCD、プラットフォームチームがコントローラをK8sネイティブに組み込んで自動運用したいならFlux、という選び方が多い印象です。まずは非本番の一クラスタでどちらかを試し、UIの有無・マニフェスト管理のしやすさを実際に手で触って決めることをおすすめします。機能の細部やバージョン差はいずれも進化が速いため、公式ドキュメントで最新を要確認です。

05CNCFでの位置づけと潮流

ArgoCDとFluxは、いずれもCNCFのGraduated(卒業)プロジェクトです。CNCFのプロジェクト成熟度はSandbox → Incubating → Graduatedの三段階で、Graduatedは最上位に位置します。つまり両者とも、コミュニティの広がりとガバナンスの成熟が公式に認められた、事実上のデファクトと言える存在です。

加えて、これらのツールが実装する「GitOpsとは何か」の定義そのものを、CNCFのGitOps Working GroupがベンダーニュートラルにOpenGitOpsとして標準化しています。ツール選定に迷ったとき、まず4原則という共通の物差しに立ち返れるのは、エンタープライズにとって大きな安心材料です。特定ベンダーのマーケティング用語ではなく、Linux Foundation傘下のワーキンググループが定義した原則である、という点は稟議の場でも効いてきます。

06K8s前提の潮流とAWS環境での適用

GitOpsの実装が急速に広がった背景には、K8sの宣言的APIと調整ループがあります。裏を返すと、多くのGitOpsツールはK8sを前提に作られています。AWS環境で活かす場合、次のような整理が実務的です。

クラスタ内の状態管理はGitOpsツールで：Amazon EKS上のDeployment・Service・Ingress・ConfigMapなどK8sリソースは、ArgoCD/Fluxの得意領域です。EKSを使うなら第一候補になります。
クラスタ外のAWSリソースはIaCと役割分担：VPC・IAM・RDS・S3といったAWSインフラそのものは、TerraformやCloudFormation、あるいはCrossplaneやAWS Controllers for Kubernetes(ACK)経由でK8sリソース化してGitOpsに載せる、といった選択肢があります。どこまでをGitOpsの調整対象にするかは、チームの運用習熟度に合わせて段階的に広げるのが安全です。
権限設計との接続：pull型はクラスタ内エージェントに権限が集まります。エージェントのIAMロール(IRSA/EKS Pod Identity)やGitへのアクセス権を最小権限で設計することが要になります。マルチアカウント構成なら、アカウント境界をまたぐ調整の設計が論点です。

アカウントをまたぐ統制やIAMの現実的な設計は、GitOps単独では閉じません。土台となる考え方はマルチアカウント統制のページも併せてご覧ください。IaCとGitOpsをどう分担させるかは、状態管理の設計そのものと直結するため、IaCの状態管理の観点とセットで検討することをおすすめします。

07drift(構成ドリフト)の自動修復

GitOpsの4原則の最後、「継続的な調整」を運用に落とし込むのがdriftの自動修復です。誰かが緊急対応でクラスタを直接kubectl editしてしまった——こうした「Gitに書かれていない変更(ドリフト)」を、GitOpsは検知し、必要なら元に戻します。

ArgoCDのselfHeal：自動同期ポリシーでselfHealを有効にすると、ライブクラスタの状態がGitの目標状態から乖離したときに自動同期がトリガーされます。公式ドキュメントは「既定では、ライブクラスタへの変更は自動同期をトリガーしない。Gitで定義された状態から乖離したときに自動同期させるにはargocd app set <APPNAME> --self-healを実行する」と明記しています。既定は無効である点に注意が必要です。
prune(不要リソースの削除)：Gitから削除されたリソースをクラスタからも消す動作は、安全のため既定で無効です。有効化すると、Gitに存在しなくなったリソースが自動同期時に削除されます。
Fluxの調整ループ：Fluxはコントローラが継続的に目標状態と実状態を比較し、差分を埋め続けます。ドリフトの是正はこの調整の一部として自然に行われます。

現場のコツ：selfHealとpruneは強力ですが、既定で無効なのには理由があります。障害対応で入れた手当てを、GitOpsが気を利かせて即座に巻き戻してしまうと、火に油を注ぎかねません。導入初期は「検知はするが自動では戻さない(可視化のみ)」から始め、運用が回り始めてからselfHealを、最後にpruneを、という順で有効化していくのが堅実です。本番環境だけはメンテナンスウィンドウの概念や一時停止(sync window)を併用し、無防備な自動巻き戻しを避ける設計にしておくと安心です。

—まとめ

GitOpsは「Gitを信頼の源にし、宣言的な状態をエージェントが継続的に調整し続ける」という、一貫した原則の集まりです。push型CIとの違いは認証情報の置き場所と監査性に効き、ArgoCDとFluxというCNCF卒業プロジェクトが、それぞれUI重視・K8sネイティブという性格で選べます。K8s(EKS)を使うなら第一候補ですが、クラスタ外のAWSリソースはIaCと役割分担し、selfHeal・pruneは段階的に有効化していくのが、大手SIer・エンタープライズの現場では無理のない進め方です。EMWは、既存のCIやIaC資産を活かしたまま、現場の運用習熟度に合わせてGitOpsを組み込む支援を行っています。導入事例は導入事例もご覧ください。

—参考(一次情報)

GitOps基盤の設計やArgoCD/Flux導入、既存のCIパイプラインからの移行をご検討でしたら、お問い合わせください。現場の運用に合わせた無理のない移行計画をご提案します。

相談する

← ブログ一覧へ戻る