Cheat notes · Module 02 · Foundations

Your first Application, from Git

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

An Application is a pointer: a source in Git, a destination in a cluster, and a project that allows it. Argo CD reports two independent things about it: sync (does the cluster equal Git?) and health (does it work?).

Remember

Application: a Kubernetes object in the argocd namespace with source (repoURL, targetRevision, path), destination (server, namespace), project and an optional syncPolicy.
Sync status: Synced, OutOfSync, or Unknown when Argo CD cannot even render or read the source.
Health status: Healthy, Progressing, Degraded, Missing, Suspended. Independent of sync: Synced + Degraded means Git faithfully declares something broken.
Refresh vs sync: refresh re-reads Git and compares (automatic every few minutes; --refresh only skips the wait). Sync applies the difference. Without a sync policy, syncing is manual.
Reading it: OutOfSync + Missing = in Git, not deployed yet. Synced + Progressing = pods starting. Unknown + ComparisonError = read the conditions.
History: one row per sync (a deploy), not per commit. REVISION shows the branch or tag and the exact commit.

Pitfalls

Pushing an Application file to Git does nothing until something applies it: kubectl apply here, the root app from module 04.
A typo in path gives Unknown and a ComparisonError. The running workload is untouched: Argo CD changes nothing it cannot render.
Synced does not mean working. Always read health as well.

Commands

`kubectl apply -n argocd -f apps/checkout-dev.yaml`	Create or update the Application object. Pushing the file is not enough yet
`argocd app get APP`	Sync, health, conditions and every resource
`argocd app get APP --refresh`	Look at Git now instead of waiting
`argocd app diff APP`	What a sync would change
`argocd app sync APP`	Apply the difference
`argocd app wait APP --health --timeout 180`	Wait until it is healthy
`argocd app history APP`	One row per deploy, with the commit

An Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout-dev
  namespace: argocd           # Applications live here
spec:
  project: default            # the fence
  source:                     # where in Git
    repoURL: https://github.com/YOUR_GITHUB_USER/checkout-config.git
    targetRevision: main
    path: manifests
  destination:                # where in the cluster
    server: https://kubernetes.default.svc
    namespace: checkout-dev
  syncPolicy:
    syncOptions: [CreateNamespace=true]

Test yourself

Answer in your head first, then open the answer.

An Application is Synced and Degraded. What does that mean?

The cluster matches Git, but the workload is not working.

Without a sync policy, what happens when you push a change?

Argo CD detects it and shows OutOfSync, then waits for someone to sync.

Where does an Application object live?

In the argocd namespace, on the cluster where Argo CD runs. Its destination namespace holds what it deploys.

What does --refresh do, and what does it not do?

It makes Argo CD read Git right now. It deploys nothing.

Where module 02 leaves you: The checkout-config repo holds the manifests, the Application checkout-dev exists in Argo CD, and the demo app (podinfo) runs in the checkout-dev namespace with 2 replicas, deployed from Git.