株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
GitOpsとは？Gitリポジトリを唯一の信頼源とするインフラ運用モデル
GitOpsとは、Gitリポジトリをインフラストラクチャおよびアプリケーション構成の「唯一の信頼源（Single Source of Truth）」として扱い、Gitへのコミット・マージを起点にインフラの変更を自動的に反映する運用モデルです。DevOpsのベストプラクティスであるバージョン管理、コードレビュー、CI/CDをインフラ管理にも適用する考え方として、Weaveworks社が2017年に提唱しました（同社共同創業者Alexis Richardson氏の説明）。
従来のCI/CD（CIOps）がCIパイプラインからクラスタに直接デプロイする「Push型」であるのに対し、GitOpsはクラスタ側のエージェントがGitリポジトリの状態を監視し、差分を検出して自動的に反映する「Pull型」を基本とします。この構成ではCIシステムにデプロイ先のKubernetes認証情報を持たせずに運用でき、認証情報を扱う範囲を減らせます。ただし、Gitへの書き込み権限やGitOpsエージェントの権限管理は必要です（Argo CDの自動同期）。
Kubernetes環境向けには、CNCF（Cloud Native Computing Foundation）のFluxやArgoなどのプロジェクトがGitOpsの運用を支えています。両プロジェクトはCNCFのGraduated段階にあり、ツールや連携機能のエコシステムが整備されています。採用を検討する際は、普及度だけでなく対象環境と運用体制に合うかを確認します。
GitOpsの基本原則：4つの柱
OpenGitOpsが定義する4原則に沿って、構成の宣言・履歴管理・自動取得・継続的な調整を整理します。
1. 宣言的な構成（Declarative）
システムの「あるべき状態（Desired State）」をYAMLやHelmチャートなどの宣言的な構成ファイルで記述します。操作手順だけでなく「何が動いているべきか」を定義し、環境の一貫性と再現性を高めます。kubectl apply自体は宣言的なマニフェストの適用にも用いられるため、コマンド名だけで手続き型とは区別できません（Kubernetes公式の宣言的管理の説明）。
2. バージョン管理と不変性（Versioned and Immutable）
Gitで管理する構成情報については、いつ・誰が・何を変更したかをコミット履歴で追跡できます。履歴の保持・保護に加え、Gitを経由しない操作や実行結果には、Kubernetesの監査ログなどを別途用意します。問題発生時には、構成変更と運用ログを照合して迅速に原因を特定できる体制が必要です。
3. 自動プル（Pulled Automatically）
GitOpsエージェント（Argo CD、Flux等）がGitリポジトリからあるべき状態を自動取得します。ポーリングやWebhookによる変更検知を利用し、自動同期を設定した対象では差分を反映するため、通常のデプロイ操作を自動化できます。Argo CDでは自動同期の有効化が必要で、検知だけを行う運用も可能です。
4. 継続的な調整（Continuously Reconciled）
GitOpsエージェントは実際の状態を継続的に観測し、Gitリポジトリの定義に近づける調整を行います。手動変更による「ドリフト（構成のずれ）」を自動修正するには、Argo CDのselfHeal等の設定、対象リソースへの権限、コントローラーの正常稼働が必要です。同期エラーや対象外リソースまで含めて、常時一致が保証されるわけではありません。
GitOpsツールの比較：Argo CD vs Flux
GitOpsを実現する代表的なツールはArgo CDとFluxです。Argo CDはCNCFのArgoプロジェクトの一部で、FluxもCNCFプロジェクトです。Argo CDとFluxはいずれも、宣言した構成と実際の状態を照合して調整します。
| 観点 | Argo CD | Flux |
|---|---|---|
| UI | リッチなWebUIを標準搭載 | CLI・Kubernetes APIが中心。UIは別途（Weave GitOpsはコミュニティ移行を表明。Mission Control等の選択肢も確認） |
| マルチクラスタ | 中央管理型で複数クラスタを一元管理 | 各クラスタへの配置に加え、kubeConfigによるリモートクラスタ管理も可能 |
| カスタマイズ性 | Application CRDでの管理が中心 | Kustomization・HelmRelease等きめ細かい制御 |
| 学習コスト | Web UIで状態を確認できる。Applicationや同期設定の理解が必要 | YAMLベースで概念理解が必要 |
| 通知連携 | Argo CD NotificationsでSlack・Webhook等に連携 | Notification Controllerでイベントと通知先を設定 |
| イメージ自動更新 | Argo CD Image Updater（別コンポーネント） | image-reflector-controllerとimage-automation-controllerを追加導入（既定構成には含まれない） |
Web UIでの状態確認や集中管理を重視する場合はArgo CDが候補です。Kustomization・HelmRelease等を組み合わせた制御を重視する場合はFluxも候補になります。両者とも複数クラスタを管理できるため、小〜中規模・大規模という区分だけで適否は決まりません。権限の分離、既存の構成管理、チームの習熟度を基準に比較し、組み合わせる場合は同じリソースを重複管理しないよう責任範囲を分けます。
GitOpsによるKubernetes運用自動化の実践
リポジトリ構成のベストプラクティス
GitOpsでは通常、アプリケーションコードとインフラ構成を別リポジトリで管理します。
- アプリリポジトリ：アプリケーションのソースコード、Dockerfile、CIパイプライン
- マニフェストリポジトリ：Kubernetesマニフェスト、Helmチャート、Kustomize構成
CIパイプラインがアプリリポジトリのコードをビルド→コンテナイメージをレジストリにプッシュ→マニフェストリポジトリのイメージタグを更新→GitOpsエージェントが変更を検知して自動デプロイ、というフローを構成できます。自動同期を有効化した場合の流れはArgo CDのCI連携例でも示されています。
環境管理（dev/staging/production）
Kustomizeのoverlays機能やHelmのvaluesファイルで環境ごとの差分を管理します。Kustomize公式資料では共通のbaseと環境別のoverlayを組み合わせる方法が説明されています。ディレクトリ構成例：
- base/ ... 共通のマニフェスト定義
- overlays/dev/ ... 開発環境固有の設定
- overlays/staging/ ... ステージング環境固有の設定
- overlays/production/ ... 本番環境固有の設定
各環境へのデプロイはGitブランチまたはディレクトリで制御し、本番環境へのデプロイにはPull Requestの承認プロセスを必須とすることで、変更の品質を担保します。
シークレット管理
機密情報（APIキー、パスワード等）をGitリポジトリに平文で保存してはなりません。Sealed SecretsやSOPS（CNCFのSandboxプロジェクト）は、Gitに置く情報を暗号化する方式です。一方、External Secrets OperatorはHashiCorp Vault等の外部管理先から値を読み、Kubernetes Secretへ同期します。用途に応じて方式を選び、復号鍵・外部管理先へのアクセス権・ローテーションも設計することが必要です。
GitOpsとCI/CDの連携パターン
CIOps（従来型）との比較
CIOps（Push型）：CIパイプライン（GitHub Actions、Jenkins等）がビルド→テスト→デプロイを一貫して実行。CIシステムがクラスタへのアクセス権を利用するため、短期認証情報や最小権限の設計が重要。
GitOps（Pull型）：CIパイプラインはビルド→テスト→マニフェスト更新まで。デプロイはクラスタ内のGitOpsエージェントが担当。CIシステムにクラスタ認証情報が不要。
Progressive Delivery
GitOpsと組み合わせて、カナリアリリースやブルーグリーンデプロイメントを自動化する手法です。Argo Rolloutsを使えば、新バージョンのトラフィック比率を段階的に増やし、事前に定義したメトリクスの失敗条件に達した場合に配信を中断して安定版へ戻す仕組みを構築できます。監視指標・判定条件・トラフィック制御の設定が前提です。
GitOps導入のメリットと注意点
メリット
- 監査性：Gitで管理する構成変更を履歴で追跡。クラスタ操作・実行結果の監査ログは別途用意
- 再現性：Gitの構成を基に再構築を自動化。クラスタへのコントローラー導入・接続設定や認証情報・データの復元は別途必要
- セキュリティ：CI/CDパイプラインにクラスタ認証情報を渡す必要がない
- 自動修復：管理対象の構成ドリフトを検知し、同期・修復設定と権限が整っていれば自動修正
- 開発者体験：Gitで管理する通常の構成変更をPRと同期で実施。初期構築や障害調査ではクラスタ操作が必要になる場合がある
注意点
- 学習コスト：Kubernetes、Helm/Kustomize、GitOpsツールの理解が必要
- シークレット管理：追加のツール導入と設計が必要
- リポジトリ肥大化：大規模環境ではマニフェストの管理が複雑化
- デバッグ：同期エラー発生時の原因特定に慣れが必要
よくある質問（FAQ）
Q1. GitOpsはKubernetes以外でも使えますか？
はい。GitOpsの4原則はKubernetes専用ではなく、TerraformやAWS CloudFormationなどのIaCを使う環境にも適用を検討できます。Argo CDとFluxの中心的な管理対象はKubernetesリソースです。TerraformをGitと連携させる選択肢にはHCP TerraformやAtlantisがありますが、VCS連携でplan/applyを起動する仕組みだけで、Pull型の継続的な状態調整まで満たすとは限りません。実装する範囲を分けて確認します。
Q2. GitOpsの導入に必要な前提条件は何ですか？
本記事のKubernetes上の実装では、1）Kubernetesクラスタ（EKS、GKE、AKS等）が利用できること、2）Gitリポジトリ（GitHub、GitLab等）が利用可能なこと、3）インフラ構成がコード化（YAML、Helm等）されていること、の3点が基本です。これに加え、GitOpsコントローラーの導入と、リポジトリ・対象クラスタへの権限設定を行います。Kubernetes自体がGitOps全般の必須条件という意味ではありません。
Q3. Argo CD とFlux、どちらを選ぶべきですか？
Web UIでアプリケーションの状態や差分を確認したい場合はArgo CDが候補です。Kubernetes APIを通じてKustomization・HelmReleaseなどを組み合わせて制御したい場合はFluxも候補です。両者とも複数クラスタを管理できます。Terraform用コントローラーとの連携を含め、利用する拡張機能の対応範囲、権限設計、チームの習熟度を確認して選びます。
Q4. GitOpsで障害が発生した場合、ロールバックはどうしますか？
git revertで前のバージョンのマニフェストに戻すコミットを作成し、対象リポジトリへ反映します。自動同期が有効で適用可能な状態なら、GitOpsエージェントが構成の巻き戻しを試みます（Argo CDの同期条件）。Gitの履歴は戻す構成を選ぶ材料になりますが、永続データや不可逆なDB変更まで復元するものではありません。データのバックアップと復旧手順は別途必要です。
Q5. GitOpsとDevOpsの違いは何ですか？
DevOpsは開発（Dev）と運用（Ops）の協業を促進する文化・プラクティスの総称で、GitOpsはDevOpsの中でも特に「Gitを中心としたインフラ運用自動化」に特化した手法です。GitOpsはDevOpsのサブセットであり、DevOpsの原則をインフラ管理に具体的に適用したものと位置づけられます。