【AKS】AKS環境にFluxを導入し、Argo CDとの違いを検証してみた

はじめに

こんにちは。ACS事業部木戸と申します。

前回の検証でArgo CDによるGitOpsによるAKSへのアプリケーションのデプロイの自動化を体験しました。
GitOpsを実現する代表的なツールには、もう一つFluxがあります。
今回はFluxを利用してAKSへのアプリケーションのデプロイを自動化してみたいと思います。

techblog.ap-com.co.jp

はじめに
1. Fluxとは
2. ローカル環境にFlux CLIをインストールする。
3. AKSにFluxをインストールする
4. Fluxで監視するGitリポジトリやManifestファイルの情報を設定する
5. 監視対象のYAMLを修正し、アプリを最新化してみる。
6. まとめ(Argo CDとFluxの違い)
ACS事業部のご紹介

1. Fluxとは

主にKubernetes向けにGitOpsを実現するためのCDツールです。
FluxはFlux CLIというコマンドラインのツールを利用して監視対象のGitリポジトリやManifestなどを設定していきます。
公式に標準同梱されたGUIは提供されていない為、構造の可視化などは別方法を検討する必要がありますが、軽量でありコマンドで必要な設定が行えます。

fluxcd.io

2. ローカル環境にFlux CLIをインストールする。

まずはローカルのWSL環境(Ubuntu)にFlux CLIをインストールしていきます。
公式の手順通りにbashコマンドを実行します。

fluxcd.io

// Flux CLIコマンド
curl -s https://fluxcd.io/install.sh | sudo bash

// バージョン確認
flux version

＜出力結果＞
flux: v2.8.3
distribution: flux-helm-controller: v1.5.3
image-automation-controller: v1.1.1
image-reflector-controller: v1.1.1
kustomize-controller: v1.8.2
notification-controller: v1.8.2
source-controller: v1.8.1

3. AKSにFluxをインストールする

次にAKS側にFluxをインストールします。 AKSには拡張によってFluxを有効にする事もできますが、今回は公式のインストール手順で実装していきます。 learn.microsoft.com

公式のインストール方法も複数用意されていますが、今回はGitHub Appによる認証を行う為、公式資料の以下の方法を参考にインストールしました。 fluxcd.io

まずはHelmによるFluxOperatorのインストールとGitHubAppの認証に必要な情報のSecretを作成します。

// HelmによるFluxOperatorのインストール
helm install flux-operator oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator \
  --namespace flux-system \
  --create-namespace

// FluxOperatorのサービス確認
kubectl get svc -n flux-system

NAME            TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)             AGE
flux-operator   ClusterIP   xx.xx.xx.xx   <none>        8080/TCP,9080/TCP   28s

// GitHub Appの認証に必要な情報をSecretに登録
flux create secret githubapp flux-github-app-auth \
   --namespace=flux-system  \
   --app-id=<GitHub App ID>\
   --app-installation-id=<GitHub Installation ID>\
   --app-private-key=<Private Keyファイルのパス

// シークレットの確認
kubectl get secret -n flux-system

NAME                                  TYPE                 DATA   AGE
flux-github-app-auth                  Opaque               3      25s
flux-operator-entitlement             Opaque               2      6m46s
sh.helm.release.v1.flux-operator.v1   helm.sh/release.v1   1      6m55s

次にFluxInstanceのカスタムリソースをデプロイします。
実行後、FluxのControllerが実装されていることを確認できます。

kubectl apply -f flux_instance.yaml

// Serviceの確認
kubectl get svc -n flux-system

NAME                      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
flux-operator             ClusterIP   xx.xx.xx.xx    <none>        8080/TCP,9080/TCP   19m
notification-controller   ClusterIP   xx.xx.xx.xx   <none>        80/TCP              6m30s     
source-controller         ClusterIP   xx.xx.xx.xx    <none>        80/TCP              6m30s
webhook-receiver          ClusterIP   xx.xx.xx.xx    <none>        80/TCP              6m30s

// FluxInstanceのカスタムリソース
apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
  name: flux
  namespace: flux-system
spec:
  distribution:
    version: "2.x"
    registry: "ghcr.io/fluxcd"
  components:
    - source-controller
    - kustomize-controller
    - helm-controller
    - notification-controller
    - image-reflector-controller
    - image-automation-controller
  cluster:
    type: kubernetes
    multitenant: false
    networkPolicy: true
    domain: "cluster.local"

4. Fluxで監視するGitリポジトリやManifestファイルの情報を設定する

今回の検証用のYAMLのフォルダはfluxcd/deployment配下に格納しています。
Argo CDで検証した時と同様、App of Appsパターンで設定していきます。

fluxcd/
├─ bootstrap/
│ └─ flux_instance.yaml                 // FluxControllerインストールYAML
├─ deployment/
│ ├─ kustomization.yaml                 // 親ApplicationのYAML
│ ├─ apps/                              // 子ApplicationのYAML
│ │ ├─ kustomization-backend.yaml
│ │ ├─ kustomization-common.yaml
│ │ ├─ kustomization-echo.yaml
│ │ └─ kustomization-frontend.yaml
│ ├─ manifests/                         //Argo CDと同様のアプリ用のManifestファイル
│ │ ├─ backend/
│ │ ├─ common/
│ │ ├─ echo/
│ │ └─ frontend/
│ └─ sources/
│   └─ gitrepository-sampleapp.yaml     // Gitリポジトリ情報 → 今回はコマンドで登録

今回はCLIを利用してGitリポジトリを登録します。
YAMLファイルを作成してkubectlから登録することもできます。
Gitリポジトリの確認コマンドでSUSPENDEDがFalse, READYがTrueと表示されていれば正常に連携できています。

// Fluxコマンドで指定する場合 (GitHub App認証)
flux create source git sampleapp-repo \
  --namespace=flux-system   --url=<GitリポジトリURL>  --branch=<ブランチ名>  \
  --provider=github --secret-ref=flux-github-app-auth --interval=2m0s

// オプション
--provider=github                 // GitHubAppでの認証の場合の指定
--secret-ref=flux-github-app-auth // GitHubAppのIDや秘密鍵情報のSecret名
--interval=2m0s                  // 2分間隔で同期確認

// kubectlの場合
kubectl apply -f fluxcd/deployment/sources/gitrepository-sampleapp.yaml

＜gitrepository-sampleapp.yamlの内容＞
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: sampleapp-repo
  namespace: flux-system
spec:
  interval: 1m0s
  provider: github
  url: <GitリポジトリのURL>
  secretRef:
    name: flux-github-app-auth  # Secret名
  ref:
    branch: main

// Gitリポジトリの確認
 flux get sources git

NAME            REVISION                SUSPENDED       READY   MESSAGE                        
sampleapp-repo  main@sha1:af6725c5      False           True    stored artifact for revision 'main@sha1:af6725c5'

次に監視対象のApplicationを設定します。
Gitリポジトリと監視対象のマニフェスト情報をFluxに設定します。
子ApplicationのYAMLではdependsOnの指定をする事でデプロイが実施される順序を指定することもできます。
こちらもkubectlからYAMLファイルで登録することもできます。

// 親Applicationの設定（監視対象を子Applicationのディレクトリに設定）
flux create kustomization sampleapp \ 
--source=sampleapp-repo \                        // 作成したGitリポジトリの名称
--path="./fluxcd/deployment/apps" \          // 監視対象のパス
--prune=true \ 
--interval=5m

// kubectlの場合
kubectl apply -f fluxcd/deployment/kustomization.yaml

＜親ApplicationのYAMLの内容＞
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: sampleapp
  namespace: flux-system
spec:
  interval: 5m0s
  path: ./fluxcd/deployment/apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: sampleapp-repo

＜子ApplicationのYAMLの内容 (frontend)＞
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: sampleapp-frontend
  namespace: flux-system
spec:
  interval: 1m0s
  timeout: 3m0s
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: sampleapp-repo
  dependsOn:
    - name: sampleapp-common
    - name: sampleapp-backend
  path: ./fluxcd/deployment/manifests/frontend
  targetNamespace: sample-1

FluxでGitリポジトリの指定の箇所が監視対象になっていることを確認します。コマンド実行後に全てのKustomizationのREADYがTrueになれば同期完了となります。

// Kustomizationの内容
flux get kustomization

NAME                    REVISION                SUSPENDED       READY   MESSAGE                  

sampleapp               main@sha1:f3cebe9a      False           True    Applied revision: main@sha1:f3cebe9a
sampleapp-backend       main@sha1:f3cebe9a      False           True    Applied revision: main@sha1:f3cebe9a
sampleapp-common        main@sha1:f3cebe9a      False           True    Applied revision: main@sha1:f3cebe9a
sampleapp-echo          main@sha1:f3cebe9a      False           True    Applied revision: main@sha1:f3cebe9a
sampleapp-frontend      main@sha1:f3cebe9a      False           True    Applied revision: main@sha1:f3cebe9a

ブラウザでサンプルアプリが起動する事を確認します。

5. 監視対象のYAMLを修正し、アプリを最新化してみる。

前回の検証同様にサンプルアプリを修正して、最新のコンテナをPushします。
その後ManifestのYAMLファイルのコンテナバージョンを最新に編集しGitリポジトリにPushします。
一定時間経過すると自動的に同期が開始されます。

// Gitリポジトリの取得情報の確認
flux get sources git

＜結果
NAME            REVISION                SUSPENDED       READY   MESSAGE                          

sampleapp-repo  main@sha1:621b0339      False           True    stored artifact for revision 'main@sha1:621b0339'


// Kustomizationの確認（適用状況の確認）
flux get kustomizations

＜結果＞
※全てのREADYがTrueになれば同期完了です。
NAME                    REVISION                SUSPENDED       READY   MESSAGE                  

sampleapp               main@sha1:621b0339      False           True    Applied revision: main@sha1:621b0339
sampleapp-backend       main@sha1:621b0339      False           True    Applied revision: main@sha1:621b0339
sampleapp-common        main@sha1:621b0339      False           True    Applied revision: main@sha1:621b0339
sampleapp-echo          main@sha1:621b0339      False           True    Applied revision: main@sha1:621b0339
sampleapp-frontend      main@sha1:b2d462b6      False           False   dependency 'flux-system/sampleapp-backend' is not ready

ブラウザでサンプルアプリが更新され、想定の表示になっていることを確認できました。

6. まとめ(Argo CDとFluxの違い)

今回Argo CDとFluxの両方を使ってGitOpsによるアプリのデプロイを体験してみました。
両方に違った特色があり、プロジェクトの方針や要件によってGitOpsの導入方法を選択できるのはよいと感じました。

比較項目	Argo CD	Flux
主な選定理由	複数部署・複数名前空間での管理、構成の可視化を重視する場合	シンプルかつ迅速なGitOps導入を重視する場合
インターフェース	高機能なGUIを搭載。アプリケーション構成を視覚的に確認可能。	CLI（Flux CLI）がメイン。シンプルで軽量な運用。
導入の容易さ	検討項目が多い（TLS証明書、ドメイン、詳細な権限設計など）。	手軽（CLIとControllerの導入、コマンド実行のみで開始可能）。
権限管理	独自の権限での管理により細かいセキュリティ設定が可能。	Kubernetes標準のRBAC等で実施。
アクセス・通信	GUI利用時にHTTPS通信（証明書等）の準備を求められることが多い。	ツール導入時の構成がシンプル。
管理の傾向	複雑な要件や複数人での管理においてガバナンスを効かせやすい。	最小限の手間でGitOpsをプロジェクトに組み込める。

ACS事業部のご紹介

私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。

www.ap-com.co.jp また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人となります。 www.ap-com.co.jp

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。