ArgoCD & GitOps¶

Before You Read¶

This page explains the deployment architecture. For step-by-step deployment instructions see GitOps Workflow Guide. For rollbacks see Rollbacks Guide.

What is GitOps?¶

GitOps means Git is the single source of truth for all cluster configuration. The rule is simple:

No one manually applies kubectl or helm commands to change running services. All changes go through Git.

ArgoCD continuously watches the Git repository. When it detects a difference between the Git state (desired) and the cluster state (actual), it automatically reconciles.

flowchart LR
    Dev["Developer\npushes code"]
    Git["Git (Bitbucket)\ninfra repo"]
    ArgoCD["ArgoCD\nwatches for changes"]
    Cluster["GKE Cluster\napply changes"]

    Dev -->|"PR merge"| Git
    Git -->|"detects drift"| ArgoCD
    ArgoCD -->|"helm upgrade / kubectl apply"| Cluster
    Cluster -->|"sync status"| ArgoCD

ArgoCD Architecture¶

ArgoCD runs in the argocd namespace and is exposed via an Istio VirtualService:

Dev: https://argocd.dev.orofi.xyz
Staging: https://argocd.stage.orofi.xyz

It authenticates using SSH against Bitbucket using the bitbucket-ssh-key secret (a deploy key on the repository).

Access Control¶

ArgoCD RBAC is configured conservatively:

policy.default: role:readonly

By default, all users can view applications but cannot trigger syncs or rollbacks. [NEEDS TEAM INPUT: which roles/groups have admin access to ArgoCD?]

Application Structure¶

Each microservice and platform component is an ArgoCD Application resource. Applications are stored in the infrastructure-configuration repository.

Application configuration follows this pattern:

# infrastructure-configuration/projects/orofi/{service}/argocd-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: microservice-identity
  namespace: argocd
spec:
  project: default
  source:
    repoURL: git@bitbucket.org:oro-codebase/microservice-identity.git
    path: helm/
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: microservice-identity
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Deployment Types¶

The shared Helm chart template supports two deployment strategies via ArgoCD Rollouts:

Standard Deployment¶

Standard Kubernetes rolling update. New pods replace old pods gradually.

Canary Deployment (ArgoCD Rollout)¶

The Helm chart includes a rollout.yaml template based on ArgoCD Rollouts. This enables canary releases where a small percentage of traffic goes to the new version before full rollout.

[NEEDS TEAM INPUT: specify which services use canary vs standard rollout, and the canary step configuration (e.g., 10% → 30% → 100%).]

Helm Chart Template¶

All microservices use the shared Helm chart at infrastructure-configuration/projects/templates/microservice/helm/. The chart is called orofi-application (version 0.1.0).

Chart Templates¶

Template	Resource Created	Purpose
`deployment.yaml`	`apps/v1/Deployment` or `argoproj.io/Rollout`	Run service pods
`service.yaml`	`v1/Service` (ClusterIP)	Internal service discovery
`namespace.yaml`	`v1/Namespace`	Create the namespace
`serviceaccount.yaml`	`v1/ServiceAccount`	Workload Identity binding target
`hpa.yaml`	`autoscaling/HorizontalPodAutoscaler`	CPU/memory based autoscaling
`virtualservice.yaml`	`networking.istio.io/VirtualService`	Istio routing (hostname → service)
`destinationrule.yaml`	`networking.istio.io/DestinationRule`	Circuit breaking, load balancing
`peerauthentication.yaml`	`security.istio.io/PeerAuthentication`	Enforce mTLS for this namespace
`telemetry.yaml`	`telemetry.istio.io/Telemetry`	Istio metrics/tracing config
`keda-scaledobject.yaml`	`keda.sh/ScaledObject`	KEDA autoscaling triggers
`rollout.yaml`	`argoproj.io/Rollout`	Canary/blue-green deployment

Key Deployment Spec Values¶

# From infrastructure-configuration/projects/templates/microservice/helm/templates/deployment.yaml
containers:
  - name: app
    ports:
      - containerPort: 80      # All services listen on HTTP 80
    livenessProbe:
      httpGet:
        path: /health           # [NEEDS TEAM INPUT: confirm health check paths per service]
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 300
    readinessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 5

Redis port exclusion

The Istio sidecar is configured to exclude outbound traffic on port 6379 (Redis). This means Redis connections bypass the Istio proxy and go directly from the application container. This is a common pattern for Redis to avoid mTLS overhead on high-throughput cache traffic.

Source Repositories¶

ArgoCD connects to Bitbucket via SSH using a deploy key:

git@bitbucket.org:oro-codebase/{serviceName}.git

The SSH key is stored in the bitbucket-ssh-key Kubernetes secret in the argocd namespace (synced from GCP Secret Manager via ESO).

Sync Policies¶

[NEEDS TEAM INPUT: document whether automated sync (with selfHeal and prune) is enabled per environment, and whether there's a manual approval gate for production deployments.]

ApplicationSets¶

[NEEDS TEAM INPUT: determine if ArgoCD ApplicationSets are used to manage the fleet of microservice applications. If yes, document the generator pattern (Git generator, list generator, etc.) and the template configuration.]

Rollouts (Progressive Delivery)¶

ArgoCD Rollouts extends ArgoCD with canary and blue-green deployment strategies. The KEDA ScaledObject integrates with Rollouts to ensure autoscaling works correctly during canary promotions.

For rollback procedures see Rollbacks Guide.

Monitoring ArgoCD Sync Status¶

ArgoCD exposes application health and sync status via: 1. The ArgoCD web UI (requires access to argocd.{env}.orofi.xyz) 2. The ArgoCD CLI: argocd app list, argocd app get <name> 3. Prometheus metrics scraped from ArgoCD (viewable in Grafana)