GitOps で catalog を配信する

GitOps とは、Git リポジトリがクラスター内で実行されるものの信頼できる情報源であることを意味します。手動で kubectl apply を実行する代わりに、マニフェストを Git にコミットし、コントローラーが継続的にクラスターを Git に一致するように調整します。Argo CD がそのコントローラーです。

ここでの Git リポジトリは、prepare-environment によって作成され、シードされた AWS CodeCommit リポジトリ $EKS_CAP_CODECOMMIT_REPO です。これには catalog/ ディレクトリの下に catalog サービスの Kubernetes マニフェストが含まれています。

現在、catalog サービスはベースアプリケーションの一部として実行されており、kubectl で直接適用されています。これを Argo CD に所有権を移譲し、代わりにそのリポジトリから配信されるようにします。2つの宣言的なステップでそれが実現します。このクラスターをデプロイメントターゲットとして登録し、次にリポジトリを指す Argo CD Application を作成します。

クラスターをデプロイメントターゲットとして登録する

Argo CD は、どの クラスターにデプロイするかを知る必要があります。オープンソースの Argo CD は実行されているクラスターを想定していますが、マネージド capability はクラスター外で実行され、組み込みのローカルターゲットがないため、このクラスターを明示的に登録します。Argo CD がデプロイメントターゲットとして認識する Secret として定義します。

~/environment/eks-workshop/modules/fastpaths/eks-capabilities/argocd/cluster.yaml

# Registers the local EKS cluster as an Argo CD deployment target.
#
# The managed Argo CD capability does NOT register the local cluster
# automatically, and it identifies clusters by EKS cluster ARN (the usual
# https://kubernetes.default.svc is not supported). We give it the explicit
# name eks-workshop, NOT the open-source Argo CD default in-cluster, to
# make clear the managed capability has no built-in local deployment target.
#
# Piped through envsubst before applying so $EKS_CLUSTER_AUTO_ARN is resolved.
apiVersion: v1
kind: Secret
metadata:
  name: eks-workshop
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: eks-workshop
  server: ${EKS_CLUSTER_AUTO_ARN}
  project: default

A

argocd.argoproj.io/secret-type: cluster ラベルは、この Secret がデプロイメントターゲットを記述していることを Argo CD に伝えます。

B

ターゲットに明示的な名前 eks-workshop を付けます。

C

ターゲットは、通常の https://kubernetes.default.svc ではなく、EKS クラスター ARN ($EKS_CLUSTER_AUTO_ARN) によって識別されます。

Argo CD はすでにこのクラスターに同期できます。prepare-environment の間に、capability は cluster-admin ポリシーがアタッチされた IAM ロールの EKS アクセスエントリを作成しました。

envsubst でクラスター ARN を解決して適用します。

~$cat ~/environment/eks-workshop/modules/fastpaths/eks-capabilities/argocd/cluster.yaml \

| envsubst | kubectl apply -f -

secret/eks-workshop created

catalog Application を作成する

次に、シードされた CodeCommit リポジトリを指す Argo CD Application を定義します。IAM Capability Role が codecommit:GitPull を許可しているため、Argo CD は HTTPS URL で 直接 リポジトリを読み取ります。リポジトリ Secret も、SSH キーも、設定する Git 認証情報ヘルパーもありません。

~/environment/eks-workshop/modules/fastpaths/eks-capabilities/argocd/application.yaml

# Argo CD Application that delivers the catalog service via GitOps.
#
# The source is the pre-provisioned CodeCommit repository, referenced DIRECTLY
# by its HTTPS URL. The managed Argo CD capability authenticates to CodeCommit
# using its IAM Capability Role (codecommit:GitPull), so there is no repository
# Secret, no SSH key, and no Git credential helper.
#
# Destination uses the registered eks-workshop cluster target. Automated sync
# with prune + selfHeal turns every push to the repo into a reconciled rollout.
#
# Piped through envsubst before applying so $EKS_CAP_CODECOMMIT_URL is resolved.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: catalog
  namespace: argocd
spec:
  project: default
  source:
    repoURL: ${EKS_CAP_CODECOMMIT_URL}
    targetRevision: main
    path: catalog
  destination:
    name: eks-workshop
    namespace: catalog
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

A

source は CodeCommit リポジトリ ($EKS_CAP_CODECOMMIT_URL) を指します。path: catalog はリポジトリ内のマニフェストディレクトリを選択します。

B

destination.name: eks-workshop は、登録したばかりのデプロイメントターゲットと一致します。

C

syncPolicy.automated と prune および selfHeal により、Argo CD は継続的にクラスターを Git に一致するように調整します。

ベースアプリケーションはすでに kubectl で catalog をデプロイしています。Argo CD が唯一の所有者になるように削除します。Argo CD は次のステップで Git からスタックを再作成します。

~$kubectl delete namespace catalog --ignore-not-found

namespace "catalog" deleted

envsubst でリポジトリ URL を解決して Application を適用します。

~$kubectl delete application catalog -n argocd --ignore-not-found

~$cat ~/environment/eks-workshop/modules/fastpaths/eks-capabilities/argocd/application.yaml \

| envsubst | kubectl apply -f -

application.argoproj.io/catalog created

Argo CD は新しい Application を取得し、CodeCommit からマニフェストをプルし、catalog Namespace を作成し、ワークロードをデプロイします。デフォルトの約3分間のポーリングを待たないように即座にリフレッシュをトリガーし、Application が Healthy を報告するまで待ちます。Healthy な Argo CD Application は、そのワークロードが正常にロールアウトされたことを意味するため、実行する別のロールアウトチェックはありません。

~$kubectl annotate application catalog -n argocd \

argocd.argoproj.io/refresh=hard --overwrite

~$kubectl wait --for=jsonpath='{.status.health.status}'=Healthy \

application/catalog -n argocd --timeout=300s

application.argoproj.io/catalog condition met

最終的な同期とヘルス状態を確認します。

~$kubectl get application catalog -n argocd \

-o jsonpath='{.status.sync.status}{"/"}{.status.health.status}{"\n"}'

Synced/Healthy

UI にサインインした場合は、Applications ページの catalog タイルをクリックして、そのリソースツリーを開き、Argo CD がワークロードを調整するのを確認できます。

catalog サービスは GitOps によって配信されるようになりました。CodeCommit リポジトリにプッシュされた変更は、自動的にクラスターに調整されます。これは次に見ていきます。