GitOps with ArgoCD

To use GitOps you'll need a Git repository - GitHub, GitLab, Codeberg, or any other host, containing YAML files that describe your cluster's desired state. ArgoCD continuously monitors the repository and applies changes automatically, keeping the cluster in sync.

You can configure ArgoCD to:

• Watch specific branches or directories; useful for managing multiple applications or environments from a single repository.
• Require signed commits before applying changes, adding an extra layer of authorization.

Your first application

An ArgoCD Application points at a path in your Git repository and a destination in the cluster. Commit something like this (to the repository ArgoCD watches, or create it in the ArgoCD UI):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/my-cluster.git
    targetRevision: main
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: my-app
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

path: apps/my-app is a directory in your repo holding the Deployment, Service, and any other manifests for the app. ArgoCD renders and applies them, then keeps them in sync. With selfHeal enabled it also reverts manual drift, and with prune it removes resources you delete from Git.

Deploying into other namespaces

Although your kubectl access is scoped to the argocd namespace, ArgoCD itself runs with the permissions needed to create and manage resources elsewhere in the cluster. To deploy into another namespace, commit an Application (or ApplicationSet) manifest to your Git repository that targets the destination namespace; ArgoCD will create the namespace if it doesn't already exist (using syncOptions: CreateNamespace=true) and deploy your resources into it.

Managing many applications

For more than a handful of apps, an ApplicationSet generates Application resources from a template, for example one per directory or one per environment. This keeps a single source of truth for adding, updating, and removing applications across the cluster.