argoproj/argo-cd — 優良食堂詳しい解説

01 / 概要

何をするものか一文で言うと

ひとことでKubernetesの宣言的GitOpsによる継続的デリバリーツール

argoproj/argo-cdは、Kubernetesクラスタ向けの宣言的GitOps継続的デプロイツールです。Gitリポジトリに置かれたマニフェスト(Helm、Kustomize、plain YAMLなど)を「望ましい状態」として扱い、クラスタの実際の状態と自動的に比較・同期します。Application、ApplicationSetというCRDを中心に、Webコンソール・CLI・APIサーバーを備えた本番運用向けのプラットフォームです。

02 / 構造

どう動くのか中核のしくみ

読み方動きの流れを図と一緒にほどきました。

中心にあるのはApplicationというCRDです。Gitリポジトリのパスをソース、対象クラスタをデスティネーションとして定義します。repo-serverがそのリポジトリをクローンし、Helm・Kustomize・git-lfsなどのツールを使ってマニフェストを実際のYAMLへレンダリングします。application-controller(cmd/argocd-application-controller)は一定の周期で再同期し、レンダリング結果とクラスタ上の実リソースを比較します。差分があればOutOfSyncと判定し、自動同期や自己修復(self heal)で収束させます。コードにはresync periodやジッター、バックオフ、hydration-processorsの並列数などの調整フラグが多数用意されており、大規模クラスタでも運用できる設計です。ApplicationSet機能では、List・Git・Cluster・Matrix・Mergeなど複数のGeneratorを組み合わせ、1つのテンプレートから多数のApplicationを動的に生成できます。commit-serverはhydrator機能でレンダリング結果をGitへ書き戻すこともできます。ビルド面では、マルチステージDockerfileでUbuntuベース画像にhelm・kustomize・git-lfsを組み込み、GitHub Actionsのワークフローでビルド・テスト・CodeQL解析・cosignによるイメージ署名・OpenSSF Scorecard評価までを自動化しています。

03 / 体験

入れるとこんな体験になりますギット飯が実際にたどった順序

所要ギット飯が実際に導入・実行しながらたどった順序です。

STEP 01
Kubernetesクラスタにmanifests/install.yamlを適用すると、repo-server・application-controller・applicationset-controller・APIサーバーなど複数のPodが起動します。
STEP 02
argocd CLIでログインし、GitリポジトリのパスとクラスタをSource・Destinationに指定してApplicationを作成すると、まずOutOfSyncという状態がUIとCLIに表示されます。
STEP 03
argocd app syncを実行すると、repo-serverがHelmやKustomizeでマニフェストをレンダリングし、実際にクラスタへリソースが作成される過程が同期履歴として記録されます。
STEP 04
ApplicationSetのGit GeneratorやList Generatorの例(applicationset/examples配下)をapplyすると、1つの定義から複数のApplicationが自動生成される様子を確認できます。
STEP 05
ローカルでソースからビルドする場合はGo・Node・helmなど多数の依存が必要で、Tiltfileを使った開発者向けのホットリロード環境も用意されています。
STEP 06
リリース用コンテナ画像はGitHub Actionsのimage-reuse.yamlで複数レジストリへ公開され、cosignで署名される流れをワークフロー定義から確認できます。

04 / 成果物

何が手に入るのか導入後に手元に残るもの

実行環境を用意すれば、Gitの変更が自動的にKubernetesクラスタへ反映される継続的デプロイの仕組みが手に入ります。具体的には、Application単位の同期状態(Synced/OutOfSync)の可視化、同期履歴、ロールバック、ApplicationSetによる多数アプリケーションの一括管理、Helm・Kustomize・jsonnetなど複数テンプレートエンジンへの対応が得られます。CI/CD面では、ビルド済みコンテナ画像にcosign署名とCodeQL・Scorecardによるサプライチェーン検査が付随した状態で配布される点も含まれます。

05 / 注意

ここは先に知っておいてください先に知っておくとよいこと

正直なところ誰にでも合うとは言いにくいところです。

実際に動かすにはKubernetesクラスタと接続できる環境が前提で、Dockerfileを見てもGo・Node・helm・kustomize・git-lfsなど依存が多く、ローカルビルドの準備は軽くありません。

manifests配下のインストールYAMLやCRDはlinguist-generated指定の生成物で、直接編集せずcodegenから作り直す運用が求められます。

applicationset配下の多数のGenerator(List、Git、Matrix、Mergeなど)は組み合わせが複雑で、設計を理解するまでに学習コストがかかります。

06 / 結論

ギット飯の結論食べてみる価値のある一膳か

ギット飯の最終判断優良食堂

複数チームや複数クラスタでGitOpsによるデプロイ運用を本格導入したいチームに向いています。CIワークフロー、イメージ署名、CodeQLやScorecardといったサプライチェーン対策がリポジトリ構成自体に組み込まれている点、application-controllerのresync・self heal・バックオフなど運用パラメータがコードで細かく調整できる点から、本番運用を想定した成熟度の高さが確認できます。実際に動かさなくても、CRD設計とコントローラーの再同期ロジック、ApplicationSetのGenerator群、CI/CDワークフロー定義を読むだけで、挙動と運用上の論点はおおむね判断できます。