Contents
GitOps入門:ArgoCDによるKubernetes環境構築の基本概念
Kubernetes運用において「コードでインフラを管理する」GitOpsの概念は、近年注目を集めています。特にArgoCDは、GitHubなどのリポジトリと連携して自動デプロイを行うことで、DevOpsエンジニアの負担軽減に貢献します。本記事では、GitOpsとArgoCDの基礎知識から、実際の環境構築手順までをステップバイステップで解説します。
GitOpsとは?
GitOpsは、「Gitリポジトリが唯一の真実」として、インフラやアプリケーションの運用をすべてGitで管理する手法です。具体的には以下のような流れになります:
- 開発者がコード変更をGitHubにプッシュ
- CI/CDツール(例: GitHub Actions)がリポジトリの変化を検知
- ArgoCDが変更内容をKubernetesクラスターと同期
この仕組みにより、手動操作やミスによるエラーを防ぎながら、一貫した環境管理が可能になります。
ArgoCDの役割と特徴
ArgoCDはGitOps実現のためのCD(継続的配布)ツールです。主な機能・メリットは以下の通りです:
- 自動同期機能:リポジトリの変更をリアルタイムでクラスターに反映
- 視覚的なUI:デプロイ状況やバージョン管理を確認できるダッシュボード提供
- 多様なソースサポート:GitHub、GitLab、OCIなど幅広いリポジトリとの連携対応
Kubernetes初心者でも直感的に使える設計となっており、企業での導入実績も増えています。
ArgoCDのインストール手順(Helm/Manifests比較)
ArgoCDをクラスターに導入するには「Helm」または「YAMLマニフェスト」の2つの方法があります。それぞれの特徴と手順を確認しましょう。
Helmによるインストール
HelmはKubernetesのリソース管理を容易にするパッケージ管理ツールです。導入が簡単で、バージョン管理も楽なためおすすめです。
- Helmクライアントのインストール
- macOS:
brew install helm -
Linux: 公式サイトからダウンロード
-
ArgoCDリポジトリを追加
bash
helm repo add argocd https://argoproj.github.io/argo-helm
helm repo update -
チャートのインストール
bash
helm install argocd argocd/argo-cd \
--namespace argocd \
--create-namespace -
UIへのアクセス設定
- インストール後、
kubectl get svc -n argocdでサービス名を取得し、LoadBalancerやIngress経由でアクセス可能に
メリット: バージョン管理が簡単、リソース一覧の見やすさ
デメリット: Helmが導入済みである必要がある
純粋なYAMLマニフェストでの導入
YAMLファイルで手動でリソースを定義する方法です。初学者向けに「仕組み」を理解したい場合におすすめします。
-
公式マニフェストの取得
GitHubからinstall.yamlをダウンロードし、クラスターに適用します:
bash
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.13.0/manifests/install.yaml -
サービスの公開設定
kubectl get svc -n argocdで外部アクセス用サービス(例:argocd-server)を確認- IngressやLoadBalancerによりインターネットからアクセス可能に
| 項目 | Helm導入 | YAML導入 |
|---|---|---|
| 手軽さ | ✅ おすすめ | ⚠️ 手間かかる |
| バージョン管理 | ✅ 易しい | ❌ 困難 |
| 学習効果 | ⚠️ 不要 | ✅ 高い |
GitOpsワークフローの仕組みと自動化原理
ArgoCDは、GitHub ActionsなどのCI/CDツールと連携することで、コード変更からデプロイまでの全工程を自動化します。
コード変更→リポジトリ更新
開発者は、アプリケーションやKubernetesマニフェストのコードをGitHubにプッシュします。この時、Branch Policy(例: mainブランチ限定)を設定することで、不適切な変更がクラスターに反映されないようにできます。
ArgoCDによる自動同期メカニズム
ArgoCDは以下のような仕組みで自動同期を行います:
- リポジトリと同期:GitHubの
mainブランチを監視 - 差分検出:クラスター内の現状とリポジトリの変更を比較
- アプリケーション更新:必要に応じて自動でKubernetesリソースを更新
この流れにより、手動でのデプロイ作業が不要になります。
注意: GitHub Actionsでは「プルリクエストがマージされた時」にのみArgoCDを起動させるように設定することが重要です。これにより不完全なコードがクラスターへ反映されるのを防ぎます。
Applicationリソースの定義方法とベストプラクティス
ArgoCDは、Applicationというカスタムリソース(CRD)を使って、GitHubリポジトリとKubernetesクラスターの同期を管理します。
argocd-application.yamlの基本構造
以下がシンプルな例です:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: sample-app spec: project: default source: repoURL: https://github.com/yourname/app-repo.git path: k8s/manifests targetRevision: main destination: server: https://kubernetes.default.svc namespace: default |
repoURL: GitHubリポジトリのURLpath: マニフェストファイルが配置されているディレクトリtargetRevision: クラスターに同期するブランチ(例:main)
Gitリポジトリとのバインド設定
以下の3点を正しく設定することで、ArgoCDは自動で同期動作を行います:
- マニフェストファイルの配置場所
-
通常は
k8s/manifestsなど専用ディレクトリにまとめたほうが見やすくなります -
バージョン管理方法(ブランチ指定)
-
targetRevision: mainで最新のmainブランチを同期対象とします -
Kubernetesクラスターへのアクセス権限
- ServiceAccountやRBAC設定でArgoCDがリソースを操作できるようにする必要があります
Applicationリソースの作成手順
Applicationリソースを作成するには、以下のいずれかの方法があります:
-
kubectl apply コマンド
bash
kubectl apply -f argocd-application.yaml -
ArgoCD UI操作
- ArgoCDダッシュボードにログイン後、「Applications」タブから「New Application」を作成
-
SourceとDestinationの設定を入力して保存 -
argocd app createコマンド
bash
argocd app create sample-app \
--repo https://github.com/yourname/app-repo.git \
--path k8s/manifests \
--dest-server https://kubernetes.default.svc \
--dest-namespace default
GitHub Actions連携によるCI/CD自動化設定
GitHub Actionsとの連携により、プルリクエスト時に自動でデプロイ作業が実行されます。
シークレットの設定手順
ArgoCDへのアクセスにはAPIトークンが必要です。以下のようにシークレットを登録します:
- GitHubリポジトリのSettings → Secrets and variablesから追加
ARGOCD_TOKENという名前で、以下のコマンドで取得したトークンを設定(※クラスタアクセス権が必要):
bash
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
注意: 上記コマンドの実行には、ArgoCDが配置されたKubernetesクラスターへのアクセス権が必要です。
ワークフロー YAML の作成例
以下のYAMLファイルで、プルリクエストがマージされた時にArgoCDを実行させます:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
name: Deploy with ArgoCD on: push: branches: - main jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Install argocd cli run: | curl -sSL https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64 -o /usr/local/bin/argocd chmod +x /usr/local/bin/argocd - name: Sync with ArgoCD run: | argocd app sync sample-app --repo https://github.com/yourname/app-repo.git --namespace default |
重要: 上記の
sample-appは、先ほど作成したApplicationリソースの名前と一致させる必要があります。また、argocd app syncコマンドは非推奨であり、ArgoCDの自動同期機能に依存する形で設定することを推奨します。
初期デプロイからトラブルシューティングまで
ArgoCDを導入後は、初期設定の確認や代表的なエラーへの対処が重要です。
同期状態の確認方法
以下のコマンドで、リポジトリとクラスターの同期状況を確認できます:
|
1 2 |
kubectl get applications -n argocd |
出力例:
|
1 2 3 |
NAME SYNC STATUS HEALTH STATUS sample-app Synced Healthy |
- Synced: 正常に同期されている
- OutOfSync: リポジトリとクラスターの差分がある
代表的なエラーケースと解決策
| エラー内容 | 原因・対処法 |
|---|---|
Application is not in sync |
リポジトリに変更がない、または同期が失敗している。kubectl logs -n argocd argocd-application-controller-xxxxxで詳細を確認 |
Resource does not exist |
Kubernetesクラスターにリソースが存在しない。マニフェストファイルのエラーか、クラスターへのアクセス権限がない可能性あり |
Invalid configuration for Application |
.spec.source.pathや.spec.destination.namespaceなどのパラメータが不正 |
まとめ
本記事では、ArgoCDによるGitOps環境構築の基本フローと実践手順を解説しました。要点を以下にまとめます:
- GitOpsは「コードでインフラ管理」を行う手法
- ArgoCDはGitHub Actionsとの連携により、自動同期が可能
- Applicationリソース定義やワークフローセットアップが導入のカギ
- トラブルシューティングの基本を押さえておくことで、運用が安定
読者の中には「実際のクラスターで試してみたい」という声もあるでしょう。ぜひ自身の環境でArgoCDを導入し、GitOpsの仕組みを体感してください。コメント欄で実装結果や疑問点を共有いただければ幸いです。