はじめに:なぜ今、GitOpsが注目されるのか?
現代のクラウドネイティブな開発において、インフラの管理はますます複雑化しています。手動での設定変更はヒューマンエラーのリスクを高め、デプロイの速度を低下させます。そこで登場したのが「GitOps」という運用モデルです。
GitOpsは、Gitリポジトリを「信頼できる唯一の情報源(Single Source of Truth)」として、インフラとアプリケーションのデプロイを自動化するアプローチです。これにより、開発者はGitのプルリクエストを通じてインフラの変更を提案し、レビュー、承認、そして自動デプロイまでの一連のワークフローを確立できます。
私自身、DevOpsエンジニアとして多くのプロジェクトでCI/CDパイプラインの構築に携わってきましたが、特にKubernetes環境におけるアプリケーションとインフラのデプロイ管理において、GitOpsがもたらす恩恵は計り知れないと感じています。変更履歴の透明性、ロールバックの容易さ、そして何よりも「運用が楽になる」という点が大きな魅力です。
本記事では、GitOpsの基本概念から、インフラのコード化(IaC)ツールであるTerraformと、KubernetesネイティブなGitOpsツールであるArgo CDを組み合わせた実践的なインフラ自動化のワークフローを解説します。あなたのインフラ運用を次のレベルへと引き上げるための一助となれば幸いです。
GitOpsとは何か?
GitOpsは、Weaveworks社によって提唱された運用モデルで、以下の原則に基づいています。
- 宣言的記述: システムの状態(インフラ、アプリケーション)は宣言的に記述され、Gitに保存される。
- Gitが信頼できる唯一の情報源: Gitリポジトリに記述された状態が、常に本番環境の理想的な状態を表す。
- 自動化された同期: Gitリポジトリの変更が検知されると、自動的に本番環境に適用される。
- 継続的な調整: 実際の環境の状態とGitリポジトリの状態を継続的に比較し、差異があれば自動的に修正する(ドリフト検知と修正)。
GitOpsのメリット
- 高速なデプロイ: Gitへのコミットがトリガーとなり、自動的にデプロイが実行されるため、デプロイサイクルが短縮されます。
- 容易なロールバック: Gitのコミット履歴が全て残っているため、問題が発生した場合でも、過去のコミットに戻すだけで簡単にロールバックできます。
- 透明性と監査性: 全ての変更がGitのコミット履歴として残るため、誰が、いつ、何を、なぜ変更したのかが明確になり、監査が容易になります。
- セキュリティの向上: Gitリポジトリへのアクセス制御とレビュープロセスにより、不正な変更を防ぎます。
- 開発者体験の向上: 開発者は使い慣れたGitのワークフロー(プルリクエスト、コードレビュー)でインフラやアプリケーションの変更を管理できます。
Terraformによるインフラの宣言的記述
Terraformは、HashiCorp社が開発したオープンソースのIaC(Infrastructure as Code)ツールです。HCL(HashiCorp Configuration Language)という宣言的な言語を使って、クラウドプロバイダー(AWS, Azure, GCPなど)やオンプレミスのインフラリソースをコードとして定義し、プロビジョニングできます。
GitOpsの文脈では、TerraformコードをGitリポジトリに保存し、インフラの理想的な状態を宣言的に記述します。
Terraformコードの例 (AWS S3バケットの作成)
# main.tf
provider "aws" {
region = "ap-northeast-1"
}
resource "aws_s3_bucket" "my_bucket" {
bucket = "my-unique-gitops-example-bucket-2025"
acl = "private"
tags = {
Environment = "Production"
ManagedBy = "Terraform-GitOps"
}
}
resource "aws_s3_bucket_versioning" "my_bucket_versioning" {
bucket = aws_s3_bucket.my_bucket.id
versioning_configuration {
status = "Enabled"
}
}
output "bucket_id" {
value = aws_s3_bucket.my_bucket.id
}
このTerraformコードは、my-unique-gitops-example-bucket-2025
という名前のS3バケットを作成し、バージョニングを有効にするという「理想の状態」を宣言しています。このコードをGitリポジトリにコミットすることで、インフラの変更履歴が管理されます。
Argo CDによるKubernetesへの自動同期
Argo CDは、Kubernetesネイティブな宣言的GitOps継続的デリバリーツールです。Gitリポジトリに定義されたアプリケーションやインフラの宣言的状態を監視し、Kubernetesクラスターの実際の状態と同期させます。
Argo CDの仕組み
- Gitリポジトリの監視: Argo CDは、設定されたGitリポジトリ(アプリケーションのマニフェストファイルやHelmチャート、Terraformの出力など)を継続的に監視します。
- ドリフト検知: Gitリポジトリの理想的な状態と、Kubernetesクラスターの実際の状態を比較し、差異(ドリフト)を検知します。
- 自動同期: ドリフトが検知されると、Argo CDは自動的にKubernetesクラスターの状態をGitリポジトリの理想的な状態に同期させます。手動での同期も可能です。
- 可視化と監査: Argo CDのUIを通じて、アプリケーションの状態、同期状況、履歴、ログなどを視覚的に確認できます。
TerraformとArgo CDの連携パターン
Terraformはインフラプロビジョニングに特化しており、Argo CDはKubernetesへのアプリケーションデプロイに特化しています。この2つを組み合わせることで、エンドツーエンドのGitOpsワークフローを構築できます。
パターン1: TerraformでKubernetesクラスターをプロビジョニングし、Argo CDでアプリケーションをデプロイ
最も一般的なパターンです。TerraformでEKSやGKEなどのKubernetesクラスターを構築し、そのクラスター内にArgo CDをデプロイします。その後、Argo CDがアプリケーションのKubernetesマニフェスト(Deployment, Serviceなど)をGitから取得し、クラスターにデプロイします。
パターン2: Terraformの出力をArgo CDで利用
Terraformでプロビジョニングしたインフラリソース(例: S3バケット名、RDSエンドポイント)の情報を、KubernetesのConfigMapやSecretとしてArgo CD経由でアプリケーションに渡すことができます。これにより、アプリケーションがインフラリソースに依存する設定をGitOpsで管理できます。
例えば、Terraformで作成したS3バケット名をKubernetesのDeploymentに環境変数として渡す場合:
- TerraformでS3バケットを作成し、バケット名を出力として定義。
- Terraformの出力値をCI/CDパイプラインで取得し、KubernetesのConfigMapマニフェストに埋め込む。
- ConfigMapマニフェストをGitリポジトリにコミット。
- Argo CDがConfigMapの変更を検知し、Kubernetesクラスターに適用。
- アプリケーションのDeploymentがConfigMapを参照し、環境変数としてバケット名を取得。
# kubernetes/configmap.yaml (Terraformの出力から生成される)
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
S3_BUCKET_NAME: "my-unique-gitops-example-bucket-2025" # Terraformの出力値
# kubernetes/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: my-app-container
image: my-app:latest
env:
- name: S3_BUCKET_NAME
valueFrom:
configMapKeyRef:
name: app-config
key: S3_BUCKET_NAME
実践的なGitOpsワークフローの構築
1. Gitリポジトリの構成
インフラとアプリケーションのコードを同じリポジトリで管理するか、別々のリポジトリで管理するかは、チームの規模や運用方針によります。
- モノレポ: インフラとアプリケーションを同じリポジトリで管理。変更の関連性が分かりやすい。
- ポリレポ: インフラとアプリケーションを別々のリポジトリで管理。独立性が高い。
私の経験では、小規模なプロジェクトではモノレポ、大規模なマイクロサービス環境ではポリレポが適していると感じています。インフラのTerraformコードとKubernetesマニフェストは、通常、別々のディレクトリに配置します。
.gitops/
├── infrastructure/ # Terraformコード
│ ├── aws/
│ │ └── main.tf
│ └── gcp/
│ └── main.tf
└── kubernetes/ # Kubernetesマニフェスト、Helmチャートなど
├── applications/
│ ├── my-app/
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ └── another-app/
└── base/
└── argocd-install.yaml
2. CI/CDパイプラインの統合
GitOpsはCI/CDパイプラインと密接に連携します。
- CI (継続的インテグレーション): コードのビルド、テスト、静的解析など。
- CD (継続的デリバリー): Gitリポジトリへのコミットをトリガーに、Argo CDが自動的にデプロイを実行。
Terraformの変更は、terraform plan
をCIパイプラインで実行し、変更内容をレビューするプロセスを組み込むことが推奨されます。terraform apply
は、Argo CDのようなGitOpsツール、または承認プロセスを経た後に自動実行されるように設定します。
3. 監視とアラート
GitOps環境では、Argo CDが提供するUIだけでなく、PrometheusやGrafanaなどの監視ツールと連携し、インフラとアプリケーションの状態を継続的に監視することが重要です。ドリフト検知やデプロイの失敗時には、SlackやPagerDutyなどにアラートを飛ばす仕組みを構築します。
実体験に基づくGitOps導入の教訓
1. まずはKubernetesアプリケーションから始める
GitOpsの導入は、まずKubernetes上のアプリケーションデプロイから始めるのが最もスムーズです。Argo CDはKubernetesネイティブであり、導入のハードルが比較的低いため、成功体験を積みやすいでしょう。その後、Terraformなどのインフラプロビジョニングに範囲を広げていくのが現実的です。
2. 組織文化とワークフローの変革
GitOpsは単なるツールの導入ではなく、開発と運用のワークフロー、そして組織文化の変革を伴います。開発チームと運用チームが密に連携し、Gitを介した協調作業に慣れるためのトレーニングや意識改革が不可欠です。
3. ドリフト検知と自動修正のバランス
Argo CDはドリフトを自動修正する機能を持っていますが、本番環境での予期せぬ自動修正はリスクを伴う場合があります。最初は手動同期から始め、十分に安定性が確認できてから自動同期に切り替えるなど、段階的な導入を検討しましょう。
4. シークレット管理
Gitリポジトリにシークレット(APIキー、パスワードなど)を直接保存することは避けるべきです。HashiCorp Vault、AWS Secrets Manager、Kubernetes Secretsなどの専用ツールと連携し、安全にシークレットを管理する仕組みを構築しましょう。
まとめ:GitOpsで実現する安全で効率的なインフラ運用
GitOpsは、Gitを信頼できる唯一の情報源とすることで、インフラとアプリケーションのデプロイを安全かつ効率的に自動化する強力な運用モデルです。Terraformによる宣言的なインフラ定義と、Argo CDによるKubernetesへの自動同期を組み合わせることで、開発者はプルリクエストを通じてインフラの変更を管理し、DevOpsのプラクティスをさらに深化させることができます。
本記事で解説したGitOpsの原則、TerraformとArgo CDの連携パターン、そして実践的なワークフローは、私がこれまでの経験で培ってきた知見の集大成です。特に、Kubernetes環境における複雑なデプロイ管理に悩んでいる方にとって、GitOpsは強力な解決策となるでしょう。
GitOpsの導入は、単なる技術的な挑戦に留まらず、チームの協調性や運用文化の変革を促します。ぜひ、あなたのプロジェクトでもGitOpsを導入し、より安全で効率的なインフラ運用を実現してください。
参考文献:
* What is GitOps?
* Terraform Documentation
* Argo CD Documentation
コメント