Azure Kubernetes Service 上のクラスターにArgo CD を導入し、GitHub の更新をトリガーにデプロイを行う
Azure Kubernetes Service (以下AKS) 上のコンテナを運用する上で、デプロイや更新をシンプルにしたいと考えることがあります。今回はGitOps の説明に加え、Kubernetes でよく利用されるArgo CD をAKS の導入、GitHub のマニフェスト更新をトリガーにKubernetes クラスターにデプロイまで行います。

実施環境
Azure CLI | 2.75.0 |
---|---|
Kubernetes (AKS) | 1.33.2 |
Argo CD | v3.0.11 |
前提条件
- ローカルPC にてkubectl およびAzure CLI のコマンドを利用できること
- 各コマンドはWindows 11 のWSL (Ubuntu 24.04 LTS) 経由で実行とする
- Azure のアカウントを持っていること
- GitHub のアカウントがあり、Argo CD 用のリポジトリを作成していること
GitOps とは
Argo CD を利用したデプロイの前に前提となるGitOps について説明します。
概要
GitOps はアプリケーションのデプロイにおけるライフサイクル改善のため、インフラとアプリケーションの構成を改善する一連のプロセスです。GitOps はDevOps プラクティスにおけるバージョン管理、CI/CD、インフラおよびアプリケーションのデプロイ自動化を提供します。一連のプロセスを改善することにより、アプリケーションの標準的なワークフローを提供できるようになります。
GitOps ではGit リポジトリを唯一の信頼源とし、インフラの望ましい状態を宣言的に定義します。Git リポジトリを望ましい状態とするため、主にリポジトリの状態を変更するPull Request (ツールによってはMerge Request) をトリガーにデプロイを行います。例えば、main ブランチへのマージをトリガーに本番環境のシステムにデプロイを行い、Git リポジトリと本番環境のシステムに一貫性を持たせたりします。その他に、Git リポジトリの更新の追跡やロールバックが容易であり、サービスによる監査ログのような仕組みにより、セキュリティへの信頼性も担保できます。
GitOps によるプロセス改善により、ただし、GitOps を適切に行うには、単純にツールを導入するだけでなくシステムの構成、デプロイプロセスの変更を伴うことが多くあります。そのため、GitOps の最適化まで時間がかかるデメリットがあります。また、Git リポジトリの変更をトリガーとしプロセスを最適化するため、システムや特定の用途により複雑なデプロイプロセスを求められるケースには向いていません。
GitOps でよく利用されるGit リポジトリ
GitOps でよく利用されるGit リポジトリには、一例として以下のようなサービス (ソフトウェア) があります。GitOps では特定のサービスでなければいけない制約は無いため、業務や個人で利用しているリポジトリに合わせて適切なサービスを利用してください。
- GitHub
- GitLab
- Bitbucket
- Azure Repos
GitOps でよく利用されるCD 関連ツール
GitOps でよく利用されるCD 関連ツールには以下のようなものがあります。
- Argo CD (今回説明するツール)
- FluxCD
- Rancher Fleet
- GitLab CI/CD
単体のCD ツール以外にRed Hat OpenShift のようなGitOps の仕組みを含む統合製品もあります。
Argo CD とは
概要
Argo CD はGit リポジトリ内にあるマニフェストの更新を検知し、更新内容をKubernetes クラスターへ手動または自動で反映するツールです。Argo CD はGit リポジトリの更新に応じてKubernetes クラスターにインフラの設定を反映するため、複雑なデプロイプロセスの簡略化を手助けします。Argo CD ではResource Hook の仕組みを使うことで、デプロイ前やデプロイ後に任意のコマンドを実行できます。マニフェストの更新だけでなく、ちょっとした処理を行いたい場合に役立ちます。
Argo CD はKubernetes へのデプロイを前提とするため、従来のサーバーのようにKubernetes を利用していないシステムのデプロイには利用できません。また、システムの関係で複雑なデプロイプロセスが必要な場合もArgo CD はあまり向かないです。
Argo CD はArgo Project の中の1製品であり、Argo CD 以外には以下のツールがあります。Kubernetes クラスターでBlue-Green デプロイ、Canary デプロイを行う場合に利用するArgo Rollouts はよく知られています。
これらの製品以外にコンテナレジストリの更新に応じてコンテナイメージを更新するArgo CD Image Updater があります。Argo CD Image Updater はブログによる導入事例もありますが、現時点で開発中のステータスのため導入する場合は検討の上で導入してください。
Argo CD の通信要件
Argo CD を用いたデプロイを行うにはGit リポジトリとKubernetes API へのHTTPS 通信が必要となります。リモートのサーバーへの接続が必要な場合は、状況に応じてSSH 通信の許可も必要となります。プライベート環境におけるKubernetes クラスターを利用する場合、プロキシの通信許可やNAT のような外部インターネットへ通信する仕組みが必要です。これらの通信許可設定が無い場合、Argo CD 本体やArgo CD CLI のインストール用マニフェストも取得できなくなるため注意してください。
その他
Argo Project ではArgo 製品のスキルを問う認定試験があります。Argo CD 以外のArgo Workflows、Argo Rollouts、Argo Events も問われる内容となっています。詳細は以下リンクから確認してください。
Certified Argo Project Associate (CAPA) | Linux Foundation
今回の構成
今回はAzure Kubernetes Service 上にArgo CD をデプロイし、Nginx のPod を2台デプロイします。GitHub のリポジトリ名はargocd-demo とし、ディレクトリ構成は以下のとおりです。
.
├ demo
│ └─ nginx.yaml
└─ README.md
GitHub リポジトリの準備
初めにGitHub 上に今回デプロイするNginx イメージのマニフェストファイルを準備します。Argo CD ではApplication 作成時にGit リポジトリに指定のディレクトリが存在しない場合、Application 作成時にエラーとなるため事前に作成します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
マニフェスト作成後、構成のディレクトリ内に配置しGitHub リポジトリにPush します。
Argo CD CLI のインストール
GitHub リポジトリの準備完了後、Argo CD の初期管理者パスワードを取得するためにArgo CD CLI をローカルPC にインストールします。OS によってインストール方法が異なるため、操作するOS に合わせてインストールしてください。
Installation - Argo CD - Declarative GitOps CD for Kubernetes
リソースグループ、AKS の作成
Argo CD CLI インストール後、Azure 上にArgo CD 用のリソースグループ、AKS を作成します。今回はArgo CD の挙動を確認する目的のため、最小限のノード数やパブリックのクラスターとしていますが、実務で作成する場合は用途に合わせてプライベートクラスターで作成するようにしてください。
# リソースグループを作成する
az group create --name rg-argocdtest --location japaneast
# AKSクラスターを作成する
# Kubernetesのバージョンは検証時の最新バージョンとする
az aks create \
--resource-group rg-argocdtest \
--name aks-argocdtest \
--kubernetes-version 1.33.2 \
--node-count 1 \
--enable-cluster-autoscaler \
--min-count 1 \
--max-count 1 \
--node-vm-size Standard_D4s_v4 \
--nodepool-name nodepool1 \
--vm-set-type VirtualMachineScaleSets \
--generate-ssh-keys
AKS 作成後、kubectl 接続用の資格情報を取得します。
# AKS接続用の資格情報を取得する
az aks get-credentials \
--resource-group rg-argocdtest \
--name aks-argocdtest
Argo CD のデプロイ
AKS 作成後、AKS 上にArgo CD をデプロイします。Argo CD のマニフェストはパブリックに公開されているものを利用します。こちらのマニフェストをデプロイすると、必要なリソースが作成されます。
# Argo CD用の名前空間を作成する
kubectl create namespace argocd
# Argo CDのマニフェストをデプロイする
# Get Startedのinstall.yamlは最新のArgoCDバージョンではないため、別途修正する
# バージョンを現時点の安定版となる3.0.11に置換する
curl -o ./argo-install.yaml https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
sed -i 's/3.0.6/3.0.11/g' argo-install.yaml
kubectl apply -n argocd -f argo-install.yaml
Argo CD Web UI 接続用にService 設定を修正
Argo CD をデプロイしましたが、現在の状態ではArgoCD Server はClusterIP のためWeb UI に接続できません。今回は一番簡単な方法として、Argo CD Server のサービスをClusterIP からLoadBalancer に変更します。変更後、Service の状態を確認しArgo CD Server のTYPE がLoadBalancer に変更されたことを確認します。この際、EXTERNAL-IP はArgo CD のPortal 接続時に利用するためメモしておきます。
# Argo CD ServerのLoadBalancerで接続させる
# 今回は検証用のためLoadBalancerとしているが、業務で使う場合はIngressなどうまく使うようにする
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
# Argo CD ServerのTYPEを確認する
# ServiceがLoadBalancerでEXTERNAL-IPが付与されたことを確認する
kubectl get svc -n argocd
設定後、Argo CD の初期管理者パスワードを取得します。パスワードが表示されたらメモしておきます。初期管理者ユーザーのパスワードを変更したい場合はCLI またはWeb UI の「Settings > User Info」の「UPDATE PASSWORD」から変更してください。
# Argo CDの初期管理者パスワードを取得する
argocd admin initial-password -n argocd
# 管理者パスワードを変更する
# ユーザー名にadmin、パスワードは一つ前に表示されたパスワードを入力し変更する
argocd login <ArgoCD ServerのIPアドレス>
argocd account update-password
初期パスワード取得後、メモしておいたEXTERNAL-IP を使い「https://<EXTERNAL-IP>」でArgo CD のWeb UI にアクセスします。今回はSSL 証明書の設定を行っていないため警告が表示されますが、そのままWeb ページにアクセスしてください。アクセス後、ユーザー名:admin、初期管理者パスワードを入力し SIGN IN を選択します。

入力後、Web UI の画面が表示されることを確認します。

Argo CD の設定、動作確認
Argo CD の設定を行うには以下の方法があります。
- Argo CD Web UI
- Argo CD CLI
- Kubernetes のマニフェスト
今回はArgo CD のWeb UI からApplication を作成します。左ペインの Application を選択し、+NEW APP または CREATE APPLICATION を選択します。選択後、Application の詳細を入力する画面に遷移するため、以下の内容を入力します。指定した内容以外はデフォルトの設定とします。
Application Name | nginxdemo |
---|---|
Project Name | default |
SYNC POLICY | Automatic |
Repository URL | <GitHub リポジトリのURL> |
Revision | main |
Path | demo |
Cluster URL | https://kubernetes.default.svc |
Namespace | default |
Application 作成後、自動でGit リポジトリと同期を行いデプロイを開始します。デプロイが完了すると Status が Synced となります。もし正常に動作しない場合はマニフェストファイルやGit リポジトリの構成を確認してください。

AKS 上にNginx のPod が2つ作成されたことを確認します。
# AKS上のPodを確認します。
kubectl get pod -n default
kdkwakaba@TEST-PC:~$ kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
nginx-deployment-96b9d695-9ll59 1/1 Running 0 7m1s
nginx-deployment-96b9d695-jw2nz 1/1 Running 0 7m1s
Nginx のデプロイが確認できましたら、次はGit リポジトリ更新時に実行されるか確認します。nginx.yaml のreplicas を 3 に修正し、GitHub にPush します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3 # この部分を2から3に修正
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
修正後、Argo CD で更新まで待ちます。更新が遅い場合は SYNC 横の更新ボタンを選択し更新してください。更新後、先ほどと同じコマンドを実行し、Nginx のPod が3つになったことを確認します。
kdkwakaba@TEST-PC:~$ kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
nginx-deployment-96b9d695-5cqlg 1/1 Running 0 2m18s
nginx-deployment-96b9d695-9ll59 1/1 Running 0 12m
nginx-deployment-96b9d695-jw2nz 1/1 Running 0 12m
リソースのクリーンアップ
動作確認後、リソースをクリーンアップするためリソースグループを削除します。
# リソースグループを削除する
az group delete --name rg-argocdtest
まとめ
- GitOps はアプリケーションのデプロイにおけるライフサイクル改善のため、インフラとアプリケーションの構成を改善する一連のプロセス。システムによって向き、不向きもあるためシステムの特性に合わせて導入を検討する。
- Argo CD はGit リポジトリの変更を検知し、Kubernetes クラスターのシステムに更新を行うGitOps でよく利用されるソフトウェア