Argo CD on GKE

The smallest example of the three-layer split: Chant authors typed manifests, Argo CD reconciles them, and an Op on a steward (not needed here) drives anything procedural. A single GKE cluster runs Argo CD, and one Chant-authored workload is deployed through a K8s::Argo::Application declared in TypeScript with ArgoAppFor.

This mirrors the argo-cd-gke example.

What you’ll build

GKE cluster (Autopilot)
  └── Argo CD (namespace argocd)
        └── Application "web"  ──watches──▶  git repo (dist/app/)
              └── reconciles ──▶  Deployment + Service  (namespace demo)

The k8s lexicon stays runtime-agnostic. The workload (src/app) is plain Chant k8s with no reference to Argo, and one ArgoAppFor call in src/bootstrap adds Argo.

Layout

src/
  config.ts                 # repo URL, paths, namespaces, the demo image
  app/web.ts                # the workload — WebApp (Deployment + Service)
  bootstrap/application.ts   # ArgoAppFor → the Argo Application that syncs src/app

Two build outputs:

• dist/app/manifests.yaml — the workload. Commit it to the repo Argo watches.
• dist/argo.yaml — the Argo Application. Apply it once to bootstrap the GitOps loop.

1. Declare the workload

src/app/web.ts is ordinary Chant, a WebApp composite with no Argo in it:

import { WebApp } from "@intentius/chant-lexicon-k8s";
import { config } from "../config";

const { deployment, service } = WebApp({
  name: config.appName,
  image: config.appImage,
  port: config.appPort,
  namespace: config.appNamespace,
  replicas: 2,
});

export { deployment, service };

2. Declare the Argo Application

src/bootstrap/application.ts adds Argo in one call:

import { ArgoAppFor } from "@intentius/chant-lexicon-k8s";
import { config } from "../config";

export const web = ArgoAppFor(config.appName, {
  repo: config.repo,
  path: config.appPath,
  destination: { server: config.destinationServer, namespace: config.appNamespace },
});

That renders to ~20 lines of Application YAML with a safe automated, non-pruning, self-healing sync policy:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/argo-cd-gke-demo
    path: dist/app
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: demo
  syncPolicy:
    automated: { prune: false, selfHeal: true }
    syncOptions: ["CreateNamespace=true"]

Tip

prune: false keeps this ARGO001-clean. Flip pruning on per the rule’s guidance once you trust the loop.

3. Build and push the workload

npm install
npm run build           # → dist/app/manifests.yaml + dist/argo.yaml

Commit dist/app/ to the repo referenced by ARGO_REPO so Argo has something to sync.

4. Create the cluster and install Argo CD

npm run cluster           # GKE Autopilot cluster (idempotent)
npm run configure-kubectl
npm run install-argocd    # Argo CD v2.13.3 into namespace argocd

5. Bootstrap the Application

npm run bootstrap         # kubectl apply dist/argo.yaml
npm run wait              # block until the Application is Healthy
npm run status

What success looks like

$ npm run status
NAME   SYNC STATUS   HEALTH STATUS
web    Synced        Healthy

The web Deployment and Service exist in the demo namespace, created by Argo rather than by kubectl apply of the workload. Change src/app, rebuild, push to git, and Argo reconciles the diff on its own.

Next steps

• Scope the Application to a real AppProject for RBAC (ARGO002).
• Fan out across regional clusters with ArgoAppSetForRegions.
• Gate procedural steps on Argo finishing with the k8s lexicon’s waitForArgoSync activity. The CockroachDB multi-region tutorial does this, with Argo for the apply layer and a steward for the procedural one.
• For Flux instead of Argo, Flux CD Self-Hosted has the same split on a self-hosted estate.