
はじめに
こんにちは。ACS事業部 木戸と申します。
検証用のAKS環境で利用しているサンプルアプリは、GitHub Actions を利用して自動的に最新のコンテナがリポジトリ(Azure Container Registry)に反映されるようにしています。
ただ、AKS環境のManifestファイルについては kubectl による手動でのデプロイを実施していました。
今回は手動で行っていたAKS環境へのManifestファイルのデプロイを、GitOpsを実践するためのCD(継続的デリバリー)ツールであるArgo CDを導入し、自動化してみたいと思います。
techblog.ap-com.co.jp techblog.ap-com.co.jp
目次
- はじめに
- 目次
- 1. GitOpsとは
- 2. Argo CDとは
- 3. Argo CDのインストール
- 4. Argo CDとGitHubを連携するための準備
- 5. Repositoryの設定
- 6. AppProjectの追加
- 7. Applicationの追加
- 8. アプリケーションを更新し、Argo CDで自動的に同期が実行されることを確認する
- 9. まとめ
- ACS事業部のご紹介
1. GitOpsとは
GitOpsは、Gitリポジトリをインフラやアプリケーションの 信頼できる唯一の情報源(Single Source of Truth)として使用するDevOpsの運用手法の一つです。
誰がいつ何を変更したかが明確となり、Gitを介さない変更があった場合はGitの状態に自動で復帰させる事なども可能になります。
2. Argo CDとは
主にKubernetes向けにGitOpsを実現するためのCDツールです。
Kubernetes内からGitリポジトリを監視し、変更があった場合に自動的にデプロイを実施することができます。
今回は、Argo CDにおける App of Appsパターンを利用してアプリケーションのデプロイをしてみたいと思います。
App of Appsパターンは他のArgo CD Applicationリソースを管理する親Applicationを定義し、複数の子Applicationの監視を行う階層的なデプロイパターンです。
3. Argo CDのインストール
今回は公式が提供しているHelm Chartを利用してArgo CDをインストールします。
github.com
Argo CDは標準でTLS証明書でのhttps通信を要求されるため、今回はopensslで作成した自己署名証明書によるhttps通信を使ってアクセスできるようにしてみます。
まずはopensslで自己署名証明書と鍵を作成します。
// 証明書と鍵の作成 openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout tls.key -out tls.crt \ -subj "/CN=argocd.example.com" // Argo CD用の名前空間の設定 kubectl create namespace argocd // 作成された証明書と鍵をK8SのSecretに追加 kubectl create secret tls argocd-tls-secret \ --key tls.key \ --cert tls.crt \ -n argocd
Helmのインストール時に指定するvalues.yamlを作成します。
今回の検証の場合、TLSの終端は Envoy Gateway で行うため argocd-server を insecure モードで起動する設定を追加しています。
// values.yamlの内容
global:
domain: argocd.example.com
server:
httproute:
enabled: true
parentRefs:
- name: argocd-gateway
namespace: argocd
sectionName: https
configs:
params:
# insecureモードで起動
server.insecure: true
Helmコマンドにvalues.yamlを指定してインストールをします。
// Helmのリポジトリ登録 helm repo add argo https://argoproj.github.io/argo-helm // values.yamlを指定してArgo CDをインストール helm install argocd argo/argo-cd --namespace argocd -f values.yaml
Helmでのインストールが完了したら、Argo CD用のGatewayをデプロイします。
// Argo CD用のGatewayのデプロイ kubectl apply -f argocd-gateway.yaml
// Argo CD用のGateway YAML
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: argocd-gateway
namespace: argocd
spec:
gatewayClassName: eg-class
listeners:
- name: http
protocol: HTTP
port: 80
- name: https
protocol: HTTPS
port: 443
tls:
mode: Terminate
certificateRefs:
# TLS 証明書の参照設定
- name: argocd-tls-secret
Argo CDの管理者ユーザの初期パスワードは以下のコマンドで取得可能です。
// Argo CD の初期パスワード
kubectl -n argocd get secret/argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
Gatewayで出力されたアドレスにhttpsにアクセスすると、Argo CDのログイン画面が表示されます。
Argo CDの管理者のパスワードはUser Infoのメニューから変更ができます。


4. Argo CDとGitHubを連携するための準備
Argo CD と GitHubとの連携の方法は複数ありますが、今回の検証では個人のPAT等のアクセストークンでの認証ではなく連携専用の GitHub App を作成しました。
管理対象のGitリポジトリへのRead権限を設定しています。

5. Repositoryの設定
Argo CDが参照するGitのリポジトリを設定します。
今回はGitリポジトリの追加の際、連携方法に GitHub App を選択して設定を追加していきます。
必要な情報として、GitHub Appの作成時に発行される以下の値が必要になります。
1) GitHub App ID
2) GitHub App Installation ID
3) GitHub App Private Key
Settings > Repositoriesを選択

RepositoryのURLとGitHub Appの必要情報を入力し Connectを選択

登録後、一覧のCONNECTION STATUS が Successful になればGitリポジトリとの接続は成功しています。

6. AppProjectの追加
Argo CDには AppProject というグループを作成することができます。
Project単位にアクセスできるリポジトリや管理対象のKubernetesのクラスター、名前空間の設定、クラスターへアクセス可能なオブジェクトなど運用における細かい権限設定などができます。
今回は検証Application用に sample-1 という Project を作成し、デプロイ先の名前空間などを指定しています。

7. Applicationの追加
今回は以下のような構成でApplication用のYAMLを作成しています。
App of Appsパターンで構成しており、親Applicationの監視対象として4つの子Applicationが設定されています。
この構成は複数のコンポーネントで構成されているシステムの関連などを可視化できるとともに、新たなコンポーネントを追加する際も所定のディレクトリに子ApplicationのYAMLを追加することで管理もしやすくなります。
今回の検証では、AppProject, 親Applicationの追加はWebUIの方から設定しましたが、親ApplicaitonのYAMLは別フォルダに管理してkubectl等のコマンドで親Applicationを設定することもできます。
argocd/
├── apps/
│ ├── application-backend.yaml
│ ├── application-common.yaml
│ ├── application-echo.yaml
│ └── application-frontend.yaml
└── bootstrap/
├── app-project.yaml ※今回はWebUIから設定
└── sampleapp.yaml ※今回はWebUIから設定
子ApplicationのYAMLにはDeploymentのマニフェストファイルのパスが監視対象として設定されています。
---
# 子Application(common)のYAML
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: sampleapp-common
namespace: argocd
# 子Applicationのデプロイ順
annotations:
argocd.argoproj.io/sync-wave: "1"
spec:
destination:
namespace: sample-1
server: https://kubernetes.default.svc
source:
path: {監視対象manifestファイルの格納ディレクトリのパス}
repoURL: {GitのリポジトリURL}
targetRevision: {ブランチ名}
project: sample-1
syncPolicy:
automated:
prune: true
selfHeal: true
enabled: true
今回は親ApplicationのYAMLを WebUI から以下の値を設定していきます。
・Applicaiton名
・Projectの指定
・同期設定 (今回は自動的に同期されるように設定)
・RepositoryのURL
・Revision(今回はmainブランチの更新を監視)
・Pathの指定(子ApplicationのYAMLの格納されているパス)
・参照先のKubernetesクラスターと名前空間の設定

Application が追加され、自動で子Applicationのデプロイも開始され、最終的に同期が完了することを確認できました。


ブラウザからサンプルアプリにアクセスできることを確認できました。

8. アプリケーションを更新し、Argo CDで自動的に同期が実行されることを確認する
サンプルアプリを更新してACRのコンテナのバージョンを更新し、Argo CDによる監視で自動的に同期が行われる事を確認します。
以下の流れで変更を行います。
1) フロントエンドのアプリを修正し、コンテナの最新版をACRにプッシュする。(GitHub Actionsで実施)

3) 最新のバージョン番号をフロントエンドのマニフェストのYAMLを更新し、Gitリポジトリにプッシュする。
4) 一定時間経過するとArgo CDの同期が自動的に開始され、AKS環境に最新のフロントエンドのアプリがデプロイされる。

上記対応の結果、サンプルアプリの表示が想定通り変更されている事を確認できました。

9. まとめ
今回は、AKS環境でGitOpsを実践するためにArgo CDを導入し、GitHubとの連携からAppProjectの設定、App of AppsパターンによるApplication登録、自動同期までの一連の流れを確認しました。
Git上のYAMLを修正するだけで、その後のデプロイを自動化できることに加え、変更履歴を活用してトラブル発生時に以前の状態へ戻しやすい点も、Argo CDによる運用管理の大きな利点だと感じました。
また、Project単位で細かな権限設定を行える点もArgo CDを利用するメリットの一つですが、この権限管理の詳細については別の機会にあらためて検証していきたいと思います。
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人となります。
www.ap-com.co.jp