１クール続けるブログ

とりあえず１クール続けるソフトウェアエンジニアの備忘録

ArgoCDでArgoCD自身を管理する

kubernetes argocd

記事一覧はこちら

背景/モチベーション

業務で利用し始めたArgoCDリソースを個人でも試しておこうという試みです。ArgoCDをArgoCD自身に管理させるところがちょっと腹落ちしていない箇所なので、やっておこうと思います。

ArgoCDについて

公式docsはこちら

概要

ArgoCDはk8sのための宣言的なGitOpsのCDツールです。2020年4月、CNCFにIncubation-level Projectとして迎え入れられました。 ArgoCDはGitOpsパターンに従います。GitOpsはGitリポジトリを、望んだアプリケーション状態を定義した source of truth として扱います（tracking strategies）。 k8sのマニフェストは、 kustomize や helm 等いくつかの指定方法がサポートされています。

アーキテクチャ

docsはこちら

ArgoCDはKubernetesのControllerとして実装されており、このControllerは動いているアプリケーションを監視し、動いている構成とGitリポジトリ内のdesiredな構成を比較します。もし、その2つに差分が見られた場合には、 OutOfSync と見なされます。ArgoCDは差分をレポートすると同時に、ターゲットの状態に自動的または手動で同期させる機能を提供します。

ArgoCDは3つの要素から構成されます。

  • API Server
    • WEB UI, CLI, CI/CDシステムからアクセスされるgRPC/RESTサーバ
    • 主に下記の機能を提供する
      • アプリケーションのオペレーションを呼び出す（sync, rollback等）
      • リポジトリとクラスタの認証情報管理
      • アプリケーションの管理とステータスのReport
  • Repository Server
  • Application Controller
    • OutOfSync を検出し、設定によってはターゲットと同期させる
    • ユーザが定義したLifecycle（PreSync, Sync, PostSync）のhookを呼び出す

Core Concepts

言葉の定義とかをちゃんと認識しないとですね docsはこちら

Term Meaning
Application k8sリソースのグループ。CRDとして定義される。
Application source type マニフェストをビルドするツールのこと、例えばkustomizeやHelmなど
Target State アプリケーションのあるべき状態。Gitリポジトリのファイルに相当する。
Live State アプリケーションが動いている現在の状態
Reflesh Gitの最新のコードをfetchして差分を認識する
Sync Live StateをTarget Stateに移行させる

ArgoCDでArgoCD自身を管理する

方針

宣言的なセットアップ方法かつArgoCD自身をArgoCDで管理する方法を取りたいと思います（参考）。ArgoCDもk8sマニフェストで表現できるのでこの方法が可能なんですね。 ArgoCDのリリースページをを確認して最新版を取得するように変更します。 kustomize v4.0 以降では、 raw.githubusercontent.com は利用できなくなっていますので、こちらのExampleでの表記では通らないことにご注意ください（参考）
※ 自分は kustomizeのv3.9.2 で動かしました

実践

ファイルは下記のリポジトリにまとめています。README.mdに細かい手順の記載もあります。

github.com

基本はkustomizeで管理することにします。 このようにファイル群を作成しました。 applications ディレクトリ配下にArgoCDのApplication（CRD）の設定ファイルが格納される。それ以外のルート直下のディレクトリには各アプリケーションをデプロイするためのマニフェスト群を配置します。

.
├── applications
│   ├── base
│   │   ├── argo-cd.yaml
│   │   ├── external-dns.yaml
│   │   ├── kustomization.yaml
│   │   └── sealed-secrets.yaml
│   └── overlays
│       ├── dev
│       │   ├── helm-values.yaml
│       │   ├── kustomization.yaml
│       │   └── source-path.yaml
│       └── prod
├── argo-cd
│   ├── base
│   │   └── ...
│   └── overlays
│       ├── dev
│       │   └── ...
│       └── prod
└── sealed-secrets
    └── kustomization.yaml

今回はsecretの管理にbitnamiのsealed-secretを利用します！ sealed-secret に関する記事は以前書いてますので良かったらどうぞ → こちら

GitOpsで運用していく際には、実際に上記をデプロイする前にリポジトリのCredential情報を暗号化しておく必要があります。sealed-secretsを利用する場合は、暗号化する際にsealed-secretsのControllerに対して公開鍵を取得が行われます。そのため、sealed-secretsのControllerはArgoCDに先んじてデプロイを行います。後ほどsealed-secretsもArgoCDの管理対象に加えます。

# Sealed SecretsのControllerをデプロイ
kustomize build sealed-secrets | kubectl apply -f -

# Secretリソースの作成
kubectl create secret generic repo-secrets -n argocd --dry-run --from-literal=username='<REPLACE_YOUR_USERNAME>' --from-literal=password='<REPLACE_YOUR_PASSWORD>' -o yaml >tmp.yaml
kubeseal -o yaml <tmp.yaml >repo-secrets.yaml 
rm -f tmp.yaml && mv repo-secrets.yaml argo-cd/overlays/dev # 作成したファイルをkustomizeのデプロイ対象に含める

# argocdをデプロイ
kustomize build argo-cd/overlays/dev | kubectl apply -f -

次にArgoCDで管理するApplicationリソースをデプロイします。 これらをデプロイすると、ArgoCDがApplicationの設定を読み取ってリポジトリ<−>クラスタ間の同期をかけます。

kustomize build applications/overlays/dev | kubectl apply -f -

動作確認

ログイン方法はこちらを参照ください。 Ingressのエンドポイントにアクセスすると、下記のような画面を確認できるかと思います。

これでArgoCD自身をArgoCDで管理する方法ができました！

f:id:jrywm121:20210308233352p:plain
argocd

実際に動くと楽しいですね！ ここに自作のアプリケーションを載せていくときには、リポジトリごと別にして作成するのが一般的なのかなと思います。

時間見つけて、Argo Rolloutも復習しておきたいです！以上！