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

  1. What is GitOps?
  2. What is Argo CD?
  3. How does Argo CD detect configuration drift?
  4. What is the purpose of an Argo CD Application?
  5. What is automatic synchronization?
  6. What is self-healing in Argo CD?
  7. How do you perform a rollback using GitOps?
  8. Why should Git be the single source of truth?
  9. How does Tekton integrate with Argo CD?
  10. What are the best practices for implementing GitOps on OpenShift?