OpenShift GitOps with Argo CD
Learn how to implement GitOps on OpenShift using Argo CD. Understand GitOps architecture, Argo CD Applications, Sync Policies, Automated Deployments, Rollbacks, Multi-Environment Promotion, and enterprise best practices.
Introduction
Traditional CI/CD pipelines deploy applications directly into Kubernetes or OpenShift clusters.
This creates several challenges:
- Manual deployments
- Configuration drift
- Difficult rollbacks
- Limited auditability
- Environment inconsistencies
GitOps solves these problems by making Git the single source of truth.
Instead of engineers deploying directly to OpenShift, they commit configuration changes to Git. Argo CD continuously monitors the Git repository and automatically synchronizes the OpenShift cluster to match the desired state.
Git becomes the deployment system.
Learning Objectives
By the end of this article, you will understand:
- What is GitOps?
- What is Argo CD?
- GitOps Architecture
- Argo CD Components
- Applications
- Sync Policies
- Automated Rollbacks
- Multi-Environment Deployment
- Enterprise GitOps Best Practices
What is GitOps?
GitOps is an operational model where Git stores the desired configuration of your infrastructure and applications.
Benefits:
- Version Controlled Deployments
- Automated Synchronization
- Easy Rollback
- Complete Audit Trail
- Infrastructure as Code
GitOps Architecture
flowchart LR
A[Developer]
B[Git Repository]
C[Argo CD]
D[OpenShift Cluster]
A --> B
B --> C
C --> D
Traditional Deployment
flowchart LR
A[Developer]
B[Jenkins]
C[OpenShift]
A --> B
B --> C
Pipeline pushes directly to the cluster.
GitOps Deployment
flowchart LR
A[Developer]
B[Git Repository]
C[Argo CD]
D[Deployment]
E[Pods]
A --> B
B --> C
C --> D
D --> E
The cluster automatically follows Git.
GitOps Workflow
sequenceDiagram
participant Dev as Developer
participant Git
participant Argo
participant OCP as OpenShift
Dev->>Git: Commit YAML Changes
Git->>Argo: Repository Updated
Argo->>Argo: Compare Desired State
Argo->>OCP: Synchronize Cluster
Argo CD Components
| Component | Purpose |
|---|---|
| API Server | Web UI & REST API |
| Repository Server | Reads Git repositories |
| Application Controller | Monitors cluster state |
| Redis | Caching |
| CLI | Command Line Interface |
Argo CD Architecture
flowchart TD
A[Git Repository]
B[Repository Server]
C[Application Controller]
D[API Server]
E[OpenShift Cluster]
A --> B
B --> C
C --> D
D --> E
Spring Boot Repository
payment-service/
├── src/
├── pom.xml
k8s/
├── deployment.yaml
├── service.yaml
├── route.yaml
└── configmap.yaml
The k8s/ folder contains Kubernetes manifests monitored by Argo CD.
Argo CD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: payment-service
spec:
source:
repoURL: https://github.com/company/payment-service
path: k8s
targetRevision: main
destination:
namespace: payments
server: https://kubernetes.default.svc
Application Architecture
flowchart LR
A[Git Repository]
B[Argo Application]
C[Deployment]
D[Pods]
A --> B
B --> C
C --> D
Synchronization
Argo CD continuously compares:
- Desired State (Git)
- Actual State (Cluster)
flowchart LR
A[Git]
B[Compare]
C[Cluster]
A --> B
C --> B
Auto Sync
syncPolicy:
automated:
prune: true
selfHeal: true
Features:
- Automatic Deployment
- Remove Obsolete Resources
- Self Healing
Auto Sync Workflow
flowchart LR
A[Git Commit]
B[Argo Detects Change]
C[Sync]
D[OpenShift Updated]
A --> B
B --> C
C --> D
Self Healing
Suppose someone manually deletes a Deployment.
flowchart LR
A[Deployment Deleted]
B[Argo Detects Drift]
C[Recreate Deployment]
A --> B
B --> C
Git remains the source of truth.
Configuration Drift
flowchart LR
A[Git Configuration]
B[Cluster Configuration]
C[Difference Detected]
D[Auto Sync]
A --> C
B --> C
C --> D
Rollback
Rollback becomes simple.
flowchart LR
A[Git History]
B[Previous Commit]
C[Argo Sync]
D[Previous Version]
A --> B
B --> C
C --> D
Just revert the Git commit.
Multi-Environment GitOps
flowchart LR
A[Git Repository]
B[Development]
C[QA]
D[Production]
A --> B
A --> C
A --> D
Each environment references different folders or branches.
Git Repository Structure
gitops/
├── dev/
├── qa/
├── uat/
└── production/
Enterprise Banking Architecture
flowchart LR
A[Developer]
B[GitHub Enterprise]
C[Argo CD]
D[OpenShift Dev]
E[OpenShift QA]
F[OpenShift Production]
A --> B
B --> C
C --> D
C --> E
C --> F
GitOps + Tekton
Modern OpenShift architecture combines Tekton with Argo CD.
flowchart LR
A[Developer]
B[Tekton Pipeline]
C[Container Registry]
D[GitOps Repository]
E[Argo CD]
F[OpenShift]
A --> B
B --> C
B --> D
D --> E
E --> F
Tekton builds the image.
Argo CD deploys it.
Argo CD Dashboard
The Web UI provides:
- Applications
- Health Status
- Sync Status
- Deployment History
- Rollback
- Repository Information
- Resource Tree
Useful Commands
Login
argocd login
List Applications
argocd app list
Sync Application
argocd app sync payment-service
Application Status
argocd app get payment-service
Common Problems
Application OutOfSync
Possible causes:
- Manual cluster changes
- Git repository updated
- Sync disabled
Sync Failed
Verify:
- Repository access
- Cluster permissions
- Invalid YAML
Health Degraded
Check
oc get pods
Review Pod logs and Events.
Repository Access Error
Verify:
- Git credentials
- SSH Keys
- Personal Access Token
Production Best Practices
- Keep Git as the only deployment source.
- Enable automated synchronization.
- Enable self-healing.
- Protect production branches.
- Use Pull Requests.
- Separate repositories for application and GitOps manifests.
- Review every deployment through code review.
- Use immutable container image tags.
- Monitor Argo CD synchronization status.
- Enable audit logging.
Common Mistakes
❌ Deploying manually with oc apply.
❌ Editing cluster resources directly.
❌ Using mutable image tags like latest.
❌ Disabling self-healing.
❌ Mixing application source code with GitOps configuration without a clear repository strategy.
Advantages
- Git as the single source of truth
- Automatic deployments
- Easy rollback
- Self-healing clusters
- Configuration drift detection
- Version-controlled infrastructure
- Enterprise auditability
- Kubernetes-native deployment model
Summary
GitOps with Argo CD provides a modern, reliable, and auditable deployment model for OpenShift.
Key takeaways:
- Git stores the desired application and infrastructure configuration.
- Argo CD continuously synchronizes the OpenShift cluster with Git.
- Self-healing corrects unauthorized changes automatically.
- Rollbacks become as simple as reverting a Git commit.
- Combining Tekton for CI and Argo CD for CD creates a complete cloud-native DevSecOps platform.
Interview Questions
- What is GitOps?
- What is Argo CD?
- How does Argo CD detect configuration drift?
- What is the purpose of an Argo CD Application?
- What is automatic synchronization?
- What is self-healing in Argo CD?
- How do you perform a rollback using GitOps?
- Why should Git be the single source of truth?
- How does Tekton integrate with Argo CD?
- What are the best practices for implementing GitOps on OpenShift?