LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

GitOpsとは何か

GitOpsとは、Kubernetesなどのシステムが持つべき「望ましい状態」をGitリポジトリ上に宣言的に記述し、専用のソフトウェアエージェント（コントローラ）がその状態を自動的に実環境へ反映・維持する運用モデルを指します^*1。従来のCI/CDがビルド後に外部からクラスタへ変更を「push」するのに対し、GitOpsはクラスタ内のエージェントがGitの内容を「pull」してくる点が構造的な違いです。

GitOpsという用語は、Kubernetesエコシステムの標準化を進める団体であるCNCF（Cloud Native Computing Foundation）傘下のOpenGitOpsワーキンググループが、GitOps原則v1.0.0として4つの柱を定義しています^*2。第一に「宣言的（Declarative）」、第二に「バージョン管理と不変性（Versioned and Immutable）」、第三に「自動的な取得（Pulled Automatically）」、第四に「継続的な調整（Continuously Reconciled）」です。

この4原則のうち、外注検討の際に特に理解しておくべきなのが「継続的な調整」です。コントローラは一度反映して終わりではなく、実環境の状態を継続的に観測し、Gitの宣言内容とズレがあれば自動的に是正し続けます^*2。これは一般に「セルフヒーリング」と呼ばれる挙動で、手動でのkubectl操作によって生じた設定差分（ドリフト）も、コントローラが検知し次第Gitの状態へ巻き戻します。

ArgoCD・Fluxが担う役割とドリフト検出

GitOpsの原則を実装するソフトウェアがArgoCD（Argo CD）とFlux（Flux CD）です。Argo CDはKubernetes向けの「宣言的なGitOps継続的デリバリツール」と公式に位置づけられており^*3、クラスタ内のコントローラとして稼働し、実行中のアプリケーションの状態とGitに記述された目的の状態を継続的に比較します^*3。両者にズレが生じているアプリケーションは「OutOfSync」と判定され、自動または手動での同期対象として可視化されます^*3。

Fluxは、GitOpsツールキットと呼ばれる一連のコントローラ・ツール群として提供されています^*4。Gitリポジトリ・OCI（Open Container Initiative）レジストリ・Helmリポジトリなどを「Source（ソース）」として定義し、そこから望ましい状態を取得します^*4。取得後は「Reconciliation（調整）」と呼ばれる処理により、クラスタ内で稼働しているリソースやHelmリリースの状態を、Gitで定義された状態と一致させ続けます^*4。

両ツールに共通するのが、設定のドリフト（意図しない差分）を自動で検出し、是正する仕組みです。Argo CDは「自動的な設定ドリフト検出と可視化」を機能として掲げており^*3、緊急対応でクラスタに直接手を入れた場合でも、次回の調整サイクルでGitの状態へ引き戻される、または差分として警告される設計です。これにより「本番環境の実態が誰も把握していない設定になっている」という事態を構造的に防ぎます。

Push型CIとの違い

従来型のCI/CDパイプラインは、GitHub ActionsやJenkinsなどのCIツールがビルド・テストを終えた後、そのパイプライン自身がkubectlやHelmコマンドを実行してクラスタへ変更を送り込む「push型」です。この方式では、クラスタへの認証情報（kubeconfigなど）をCI環境側に持たせる必要があり、CI環境の権限がクラスタの変更権限に直結します。

GitOpsは逆に、クラスタ内で稼働するエージェントがGitリポジトリの内容を能動的に取得しにいく「pull型」です^*1。クラスタ側から見ると、外部から書き込まれるのではなく自ら取りに行く形になるため、クラスタへの外部からの直接アクセス経路を減らせる点が構造上の特徴です。CI側にはビルドとイメージのpushまでを担わせ、デプロイの実行はArgoCDやFluxに委ねる、という役割分担になります。

ここで注意したいのは、GitOpsが既存のCIを不要にするわけではないという点です。CIはコンテナイメージのビルド・テスト・脆弱性スキャンといった工程を担い続けます。GitOpsが置き換えるのは、あくまで「ビルド済みの成果物をクラスタへ反映する」デプロイの実行方式であり、パイプライン全体の代替ではありません。

push型のままクラスタへの認証情報をCI環境に持たせ続けると、CIの設定ミスや認証情報の漏えいが、そのまま本番クラスタへの誤反映につながるリスクを抱えます。CI環境の権限とクラスタへの変更権限が直結している構成では、CIパイプラインの設定変更1つが本番環境に波及するため、変更の影響範囲を事前に見積もりにくいという課題があります。GitOpsへの移行は、この権限分離の見直しという意味合いも持ちます。

一方で、pull型に切り替えたからといって設計上のリスクがなくなるわけではありません。ArgoCDやFluxのコントローラ自体がクラスタ内で強い権限を持つため、コントローラへのアクセス制御や、Gitリポジトリへの書き込み権限の管理を誤ると、今度はGitへの不正なマージがそのままクラスタへ反映される経路になります。pull型は権限の集中先を変えるものであり、権限管理そのものを不要にするものではない点に注意が必要です。

導入で詰めるべき論点

GitOps導入では、単にArgoCDやFluxをインストールするだけでは運用が回りません。導入前に整理しておくべき論点がいくつかあります。

第一に、リポジトリ構成です。アプリケーションごとにマニフェストリポジトリを分けるか、環境（開発・検証・本番）ごとにディレクトリまたはブランチを分けるかを決める必要があります。Argo CDのドキュメントでは、複数のArgo CDアプリケーションを1つの親アプリケーションから管理する「App of Apps」パターンが紹介されており^*3、アプリケーション数が増える組織では管理単位を階層化する設計が採られます。

第二に、シークレット管理です。GitOpsは設定をGitに保存する前提のため、パスワードやAPIキーなどの機微情報をそのままYAMLに平文で書くわけにはいきません。暗号化した状態でGit管理する、あるいは外部のシークレット管理サービスと連携する設計を、導入前に選定しておく必要があります。

第三に、段階導入とレビュー承認フローです。本番環境にいきなりGitOpsを適用するのではなく、検証環境から段階的に対象範囲を広げる進め方が現実的です。またGitへのマージがそのままデプロイの引き金になるため、プルリクエストの承認者・承認条件をどう設計するかが、誤反映を防ぐ運用上の要になります。

レビュー承認フローの設計では、誰が本番用リポジトリへのマージ権限を持つか、複数人承認を必須にするか、自動テストのパス条件を承認条件に含めるかといった細部を詰める必要があります。承認フローが緩いまま自動同期を有効にすると、意図しない変更が即座にクラスタへ反映される経路になります。承認フローが厳しすぎると、今度は緊急時のデプロイが遅延する要因になります。

第四に、既存の監視・アラート体制との連携です。ArgoCDやFluxが同期エラーを検知した際に、誰にどの経路で通知するかを事前に設計しておく必要があります。同期エラーが放置されると、Gitの宣言内容と実環境の差分が広がったまま気づかれない状態になります。これはGitOpsの「継続的な調整」という前提が崩れることを意味します。

これらの論点を設計段階で詰め切れないままArgoCDを導入すると、リポジトリ構成の作り直しやシークレットの再管理が後から発生し、手戻り工数が生じます。GitOps導入を内製のみで完結させるには、Kubernetesの運用経験に加え、リポジトリ設計・権限設計・監視連携という複数領域の知見を持つ担当者を確保する必要があります。この担当者確保が、内製での導入における実務上のハードルです。1名がすべてを兼務する体制では設計レビューの目が届きにくく、後から手戻りが発生しやすくなります。

外注の委託範囲と発注準備

GitOps導入を外注する場合、委託範囲を「初期構築」と「継続運用」に分けて検討すると整理しやすくなります。初期構築では、ArgoCDまたはFluxのクラスタへのセットアップ、リポジトリ構成の設計、App of Appsなど管理単位の設計、シークレット管理方式の選定と実装が主な作業範囲です。継続運用では、新規アプリケーションのオンボーディング、同期エラーの監視・対応、承認フローの運用支援などが含まれます。

発注前の準備としては、まず対象システムの現状を棚卸しすることが出発点です。既存のデプロイ手順が手動なのかCIパイプライン経由なのか、Kubernetesのバージョンやマネージドサービス（EKS・AKS・GKEなど）の種別、既にHelmやKustomizeを使っているかどうかを整理しておくと、見積もり精度が上がります。

次に、対象範囲を明確にすることです。全アプリケーションを一度にGitOps化するのか、特定のサービス群から段階導入するのかによって、初期構築の工数と難易度は変わります。加えて、シークレット管理の方針（暗号化ツールの利用可否や社内のセキュリティポリシー）は委託先の設計に直結するため、事前にセキュリティ部門と方針を握っておくことが望ましいです。

GitOps移行を内製のみで進める場合、Kubernetesの運用知識に加えてGitリポジトリ設計・CIとの役割分担・シークレット管理の設計を担える人材を確保する必要があり、体制構築に時間を要します。移行期間中は既存のデプロイ方式とGitOpsが並行稼働する期間も生じるため、切り替えの手順を誤ると同期エラーによるデプロイ停止や、意図しないロールバックが発生するリスクがあります。専門パートナーに委託する場合は、リポジトリ設計とシークレット管理の設計を先行して固めたうえで段階移行する進め方が採られ、内製よりも設計の手戻りを抑えやすい点が違いです。

LASSICは、Kubernetes基盤の運用保守を含むシステム運用の受託を行っており、GitOps導入の初期構築から継続運用までの委託先選定において、リポジトリ設計とシークレット管理方針の整理から支援します。

まとめ：GitOps導入の3つの判断軸

本稿では、GitOpsの原則とArgoCD・Fluxの役割、外注検討時の論点を整理しました。要点を3つに集約すると、第一に、GitOpsは「宣言的・バージョン管理・自動pull・継続的調整」という4原則に基づく運用モデルであり、push型CIとは異なる仕組みだという点です。第二に、ArgoCDやFluxはGitと実環境の差分を継続的に検出・是正するコントローラであり、ドリフトを自動是正する点が本番運用の安定性に直結します。第三に、外注の可否はリポジトリ構成・シークレット管理・段階導入計画を発注前にどこまで整理できているかで決まる、という点です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OpenGitOps「GitOps Principles v1.0.0」（CNCF, 2021年）https://opengitops.dev/
2. *2　出典：OpenGitOps「GitOps Principles v1.0.0」（CNCF, 2021年）https://opengitops.dev/
3. *3　出典：Argo Project「Argo CD – Declarative GitOps CD for Kubernetes」公式ドキュメント https://argo-cd.readthedocs.io/
4. *4　出典：Flux（CNCF）「Flux Concepts」公式ドキュメント https://fluxcd.io/flux/concepts/

Tweet