Buy me a DrinkEther Coffee (5$)

tektoSync (Part 2): ArgoCD Orchestration and The Configuration Trap

Published on:

2026-06-07

#ArgoCD #GitOps #Microservices #DevSecOps #Troubleshooting #AI

Table of Contents

1. Orchestrating the Microservices Engine

2. The ArgoCD Reconciliation Loop

3. Post-Mortem: The CORS & Configuration Trap

4. System Validation & Replication

5. Next Steps

1. Orchestrating the Microservices Engine

With our Tekton CI pipeline building code and committing tags safely to Git, the second half of the equation belongs to Continuous Deployment. Instead of relying on a tiny 'Hello World' app, tektoSync handles the complete, production-realistic distributed application architecture of the OG Coolstore-nodejs.

PS: To map out the microservices topology without getting locked into the app's original opinionated Nodeshift deployment tooling, I used the provided docker-compose.yml file as a blueprint to manually construct standard Kubernetes manifests.

Stateless Frontend & APIs: Independent Node.js microservices handling separate responsibilities: frontend, cart-service, catalog-service, inventory-service, order-service, and payment-service.
Stateful Infrastructure: A heavy-duty operational backend composed of Apache Zookeeper, Apache Kafka, a Redis cluster (cartcache), and MongoDB (coolstoredb).

Running 11 stateful and stateless components simultaneously inside a local single-node cluster is exactly why the host machine required a healthy allocation of 18GB of RAM and 6 cores.

2. The ArgoCD Reconciliation Loop

To manage this massive microservice fleet cleanly, I deployed an ArgoCD Application manifest targeting our configuration repository. ArgoCD continuously monitors the repository's HEAD commit. The moment Tekton pushes an updated image tag to the Kustomize overlay, ArgoCD intercepts the delta and coordinates an automated rollout.

The actual declarative manifest utilized to bootstrap this self-healing deployment pipeline looks like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: coolstore-dev
  namespace: openshift-gitops
spec:
  project: default
  source:
    repoURL: http://theplayground.home:3000/yass/tektoSync-Config.git
    targetRevision: HEAD 
    path: overlays/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: dev-sandbox
  syncPolicy:
    automated:
    prune: true
    selfHeal: true
  syncOptions:
    - CreateNamespace=false

By setting both prune: true and selfHeal: true, the cluster locks into a purely declarative state. Any accidental manual tweaks or test injections executed directly via the OpenShift console are immediately detected as configuration drift and eliminated by ArgoCD.

3. Post-Mortem: The CORS & Configuration Trap

No real engineering lab is built without hitting a few major operational roadblocks. In tektoSync, the most complex issue revolved around configuring Cross-Origin Resource Sharing (CORS) across the 6 newly mapped public OpenShift routes.

PS: Because the Coolstore application relies heavily on client-side API aggregation, the client browser must fetch database information across distinctly named backend routes. While debugging why components couldn't talk to each other, a catastrophic configuration drift occurred.

In the frenzy of modifying environment variables across multiple deployments, statefulsets, and container build layers, I overlooked a single database configuration parameter. The containers reported completely Healthy and active on the OpenShift control plane, yet data failed to map to the UI. Tracking down that lone mismatched string across the microservice web was a painful but profound reminder of why configuration scaling demands centralized management tools.

4. System Validation & Replication

To verify that the GitOps loop functions correctly, we can monitor the live orchestration state. Below is a look at the ArgoCD dashboard maintaining a flawless, self-healing sync across all 11 stateful and stateless components of the OG Coolstore ecosystem.

Finally, the the actual use of the web app can show if anything needs debugging or all works smoothly.

PS: Want to spin up this delivery engine or test out its resilience in your own cluster? The entire infrastructure setup, Kustomize overlays, and deployment manifests are open-source. Follow the comprehensive deployment guide in the GitHub repository here to replicate this project from scratch!

5. Next Steps

Building this stack proved that setting up GitOps requires more than just pushing YAML files—it requires careful architecture design and infrastructure coordination. The stage is officially set for an awesome DevSecOps transition!