REMOVE THIS SLIDE OR SKIP WHEN PRESENTING

The purpose of this deck is to dive deeper into how Argo CD works. It’s intended for SAs/Consultants presenting to the technical
staff/team of a customer.

You can use all or a subset of this presentation as you see fit.

Business value/overview presentation can be found here: Continuous Delivery and GitOps on OpenShift

1
 OpenShift GitOps Deep Dive
Technical Deep Dive into Argo CD

2
 OpenShift GitOps
Declarative GitOps for multi-cluster
continuous delivery

3

Multi-cluster config
management
Declaratively manage cluster and
application configurations across
multi-cluster OpenShift and
Kubernetes infrastructure with
Argo CD
OpenShift GitOps
Automated Argo CD Opinionated GitOps Deployments and
install and upgrade bootstrapping environments insights
Automated install, Bootstrap end-to-end GitOps Visibility into application
configurations and upgrade workflows for application delivery deployments across
of Argo CD through using Argo CD and Tekton with environments and the history
OperatorHub GitOps Application Manager CLI of deployments in the
OpenShift Console
Powered by
 Argo CD

● Cluster and application configuration versioned in Git

Monitor
● Automatically syncs configuration from Git to clusters
● Drift detection, visualization and correction
● Granular control over sync order for complex rollouts Detect
Sync
drift
● Rollback and rollforward to any Git commit
● Manifest templating support (Helm, Kustomize, etc)
Take
● Visual insight into sync status and history action

5
 Argo CD

OpenShift
Pull Request (on-premises)
merged webhook sync
OpenShift
(public cloud)
poll
Kubernetes
hooks

6
 Flexible Deployment Strategies

App A App B

Auth
OpenShift

NS NS
Registry
Networking
NS NS
Storage
Install Operators
NS NS
Namespaces
... App A App B

OpenShift OpenShift

Central Hub (Push) Cluster Scoped (Pull) Application Scoped (Pull)

A central Argo CD pushes Git A cluster-scope Argo CD pulls cluster An application scoped Argo CD pulls
repository content to remote service configurations into the application deployment and
OpenShift and Kubernetes clusters OpenShift cluster configurations into app namespaces

7
 Argo CD Applications
Atomic Unit of Work within Argo CD

8
 Argo CD Application

apiVersion: argoproj.io/v1alpha1
● “Application” is a custom resource kind: Application
metadata:
provided by Argo CD name: product-catalog-dev
namespace: argocd
● Unit of work within Argo CD spec:
destination:
● Logical collection of YAML namespace: argocd
server: https://kubernetes.default.svc
● Support for Helm and Kustomize project: product-catalog
source:
● Configuration specs path: manifests/app/overlays/dev-quay
repoURL: https://github.com/gnunn-gitops/product-catalog.git
○ Git Repository targetRevision: main
syncPolicy:
automated:
○ Revision/Branch prune: false
selfHeal: false
○ What cluster and namespace
 Application Scope of Deployment

● Argo CD Application can span multiple Kubernetes Namespaces

● In Argo CD, the Application is the “center of the world”
● Argo CD has multi tenancy capabilities with Projects
○ These differ from OpenShift Projects
○ Is not 1:1 with Namespaces/Projects
○ RBAC is scoped at the Argo CD Application level.
● Argo CD Application deployed to an Argo CD Project can be explicitly be
deployed across multiple Namespaces/Projects

Example ArgoCD Application and be found here

 Limitations of Applications

● Only one cluster per Application definition

● Only one type of resource defined
○ Git or Helm
● Only one Git repo or Helm chart defined
● Anything else would require multiple Applications
 Argo CD ApplicationSets
A Factory for creating ArgoCD
Applications

12
App of Apps Pattern

● Application that deploys Applications

● Method of Bootstrapping
○ Hundreds of Applications can
be deployed in “one shot”
● Logically group Applications made up
of YAML and Helm.
● Watchdog for Applications.
 ApplicationSets

● Use a single manifest to target multiple clusters

● Deploy Application from a single or multiple git repos
● Manages lifecycle of the Application CR
● Can be thought of as sort of a “factory” for building
Application CRs
○ You still end up with Application definitions, it’s just
managed now from a central configuration.
 ApplicationSets Generators

● ‘Generators’ are different ways to instruct how to build Applications

CRs
● Each ‘generator’ tackles a different use case
● There are 3 main ‘generators’
○ List Generators
○ Cluster Generator
○ Git Generator
● The Git Generator has two sub ‘generators’
○ Git Directory
○ Git File
● More than one ‘generator’ can be used in an ApplicationSet
 List Generator

● Based on cluster name/cluster URL list

● Elements are listed in a key/value pair.
● The Template section is how the Application
CR will be built
● This specific configuration will result in 3
Applications
 Cluster Generator

● Managed cluster’s information is stored

in a secret.

● ApplicationSet reads this information to

glean information.

● The Cluster “generator” uses this

information to generate an Application
CR

● Labeling the secret corresponding to the

cluster will deploy the application to that
cluster.
 Git Generator - Directory

● Creates parameters based on directory

structure
● Individual paths can be used
● Commonly a path is scanned
● Adding applications is done by adding a
directory to the right path.
 Git Generator - File

● Based on a file the ApplicationSet reads

● Can be named anything you want as long

as it’s valid JSON

● The configuration file can be structured

however you like as long as it’s valid
JSON

● Very flexible
 Manifest Templeting
Working with Kustomize and Helm

20
 Avoiding YAML Duplication

● Argo CD reads manifests from a Git repository

● This means that you might need the same manifest
deployed multiple times.
○ With the delta of difference being small
● Use the “DRY” approach
○ Don’t Repeat Yourself
● Various templating tools exist to help avoid YAML
duplication
 Using Kustomize

apiVersion: kustomize.config.k8s.io/v1beta1
└── apps
kind: Kustomization
└── myapp
├── base
resources:
│ ├── kustomization.yaml
- service.yaml
│ ├── service.yaml
- route.yaml
│ ├── route.yaml
- deployment.yaml
│ └── deployment.yaml
│
└── overlays
├── dev
apiVersion: kustomize.config.k8s.io/v1beta1
│ ├── patch-route.yaml
kind: Kustomization
│ ├── namespace.yaml
│ └── kustomization.yaml
Namespace: dev
└── stage
bases:
├── patch-route.yaml
- ../../base
├── namespace.yaml
resources:
└── kustomization.yaml
- namespace.yaml
patchesStrategicMerge:
- patch-route.yaml
 Helm Templates

apiVersion: build.openshift.io/v1 apiVersion: apps/v1

kind: BuildConfig kind: Deployment
... metadata:
spec: ...
... spec:
source: replicas: {{ .Values.deploy.replicas }}
type: Git ...
git: template:
uri: {{ .Values.build.uri }} spec:
contextDir: {{ .Values.build.contextDir }} containers:
{{- if and .Values.build.native.useDefaultDockerfile (eq .Values.build.mode “native”) }} - name: web
dockerfile: |- image: {{ .Release.Name }}:{{ .Values.image.tag }}
FROM registry.redhat.com/quarkus/mandrel-20-rhel8 AS builder {{- if .Values.deploy.resources }}
... resources:
{{- end }} {{- toYaml .Values.deploy.resources | nindent 12 }}
strategy: {{- end }}
{{- if eq .Values.build.mode “jvm” }} ...
type: Source
sourceStrategy:
...
 Kustomize Native Integration

apiVersion: argoproj.io/v1alpha1
● Argo CD supports Kustomize kind: Application
metadata:
natively name: product-catalog-dev
namespace: argocd
● No special configuration is needed. spec:
destination:
● Automatically detects that you’re namespace: argocd
using Kustomize server: https://kubernetes.default.svc
project: product-catalog
● YAML is validated before applying source:
path: manifests/app/overlays/dev-quay
repoURL: https://github.com/gnunn-gitops/product-catalog.git
targetRevision: main
syncPolicy:
automated:
prune: false
selfHeal: false
 Helm Integration with ArgoCD

● Charts can be sourced from:

○ Git Repositories
○ Helm Repositories

● Override Chart Values

○ Separate Values files
○ Individual parameters

● Managed via UI or CLI

 The Sync Operation
How a Sync operation works

26
 Argo CD Sync

● Argo CD checks at regular intervals

Monitor
○ Every 3 minutes
● If the current state differs from the desired state, Argo CD
will “apply” the desired state.
Detect
Sync
○ A “replace” can also be done. drift

● Can be set to prune resources

○ Deletes what it doesn’t know about Take
action
● Can be set up to apply only out of sync objects

27
 Sync Operation

● Argo CD has a “local cache” of the git repo used

● A “git pull” is performed when a sync happens

○ Latest changes pulled into this copy of the repo
○ Only target branch is used to compare

● The desired configuration is compared to the running configuration.

○ A “three way diff” is performed
○ Desired config, last applied config, and current config

● No need to “backup” the cache

○ A “git clone” is performed if the “local cache” isn’t found.
 The Three Way Diff

● Reads all manifests from the repository (aka “desired state”)

and puts them to cache Desired State Running State Last Applied

● Reads corresponding resources from the cluster (aka

“running state”) and puts them to cache
● Calculates the diff for resources, taking
last-applied-configuration from the live resources into
account
● Patches each resource individually that is part of the diff
○ Each resource gets applied individually.
Patch

29
 SyncWaves
How to deploy your manifests in a
specific order

30
 Ordering Deployment

● Ordering of deployment is done using “Syncwaves”

● Manifests are applied based on a number

○ Number can be negative.
○ Lowest gets applied first.

● Annotate your resource.

○ Example ~> argocd.argoproj.io/sync-wave: “5”

● Default Value is zero, if not specified.

0 1 2
● Syncwaves can also be applied to Phases (more on other slides)
 How Does a Syncwave Work?

● Precedence during a sync

○ Phase
○ Wave (lower value first)
○ Kind (e.g. namespaces go first)
○ Name (alphabetized)
● The next resource will only be applied when the current is
“healthy” state
● Process continues until all objects are reporting “healthy”

32
NOTE: Since an application can be unhealthy at any point of any wave, it may be that
your Application will never get to healthy!
 SyncHooks
Using a phased sync process to refine
your deployments

33
 Phased Deployment
● Argo CD has 3 main deployment phases (Hooks)
○ PreSync
○ Sync
○ PostSync

● Hooks can be any kind of Kubernetes resource

○ Usually Jobs or Pods

● Define Hooks in the resource annotation

○ Example ~> argocd.argoproj.io/hook: PostSync

● Deletion Policies
○ HookSucceeded
○ HookFailed
○ BeforeHookCreation
 Hook Deletion

● Hooks can be deleted

○ Lack of deletion policy means it sticks around

● Configured via annotation

○ e.g. ~> argocd.argoproj.io/hook-delete-policy: HookSucceeded

● Deletion Policies
○ HookSucceeded
○ HookFailed
○ BeforeHookCreation
 Using Syncwaves and
Hooks
Example of how to use both Syncwaves
and Hooks together.

36
 Syncwaves and Hooks

37
 Syncwaves and Hooks
Passage of Time

38
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

39
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job

40
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job

41
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route

job

42
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route

0 1 2

job

43
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route

0 1 2

job

44
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route

0 1 2

job

45
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route

0 1 2

job

46
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route

0 1 2

job

47
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route job

delete on success

0 1 2

job

48
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route job

delete on success

0 1 2

job

49
 Syncwaves and Hooks
Passage of Time

Phases

PreSync Sync PostSync

job deploy service route job

delete on success

0 1 2

job

50
 Thank You! linkedin.com/company/red-hat

youtube.com/user/RedHatVideos

facebook.com/redhatinc

twitter.com/RedHat

51