After an intense journey through the #30DaysOfAWSTerraform challenge, Day 29 stands out as one of the most transformative milestones so far.
This wasn’t just about provisioning infrastructure anymore—it was about building a self-healing, automated, and production-grade GitOps workflow.
If Infrastructure as Code (IaC) is the foundation, GitOps is the operating system that keeps everything running smoothly.
🔄 From IaC to GitOps: What Changed?
Until now, Terraform allowed me to:
- Define infrastructure declaratively
- Provision resources consistently
- Avoid manual “ClickOps”
But GitOps takes it a step further:
- Git becomes the single source of truth
- Systems automatically reconcile drift
- Deployments become continuous and auditable
👉 In short:
IaC provisions infrastructure. GitOps keeps it correct.
🏗️ Architecture Overview
This project bridges infrastructure provisioning and application deployment into one cohesive system.
1. Infrastructure Repository (Terraform)
Responsible for:
- Provisioning an Amazon EKS cluster
- Setting up networking (VPC, subnets)
- Installing ArgoCD via Helm
- Configuring storage (EBS CSI driver)
2. Application Repository (Kubernetes Manifests)
Contains:
- Frontend (UI layer)
- Backend (API layer)
- PostgreSQL database
⚙️ How the Workflow Operates
- Terraform provisions the infrastructure (EKS + ArgoCD)
- ArgoCD connects to the application Git repository
- Kubernetes manifests define the desired application state
- ArgoCD continuously monitors and syncs changes
💡 The Magic:
If anything changes outside Git (manual kubectl edits, scaling, etc.),
ArgoCD automatically reverts it back to the desired state.
🔍 Key Concepts I Mastered
🔹 1. Terraform Helm Provider
Instead of manually installing ArgoCD:
resource "helm_release" "argocd" {
name = "argocd"
repository = "https://argoproj.github.io/argo-helm"
chart = "argo-cd"
}
👉 This ensures ArgoCD itself is version-controlled and reproducible.
🔹 2. The “App of Apps” Pattern
Rather than deploying each service manually:
- A parent ArgoCD application manages multiple child apps
- Each microservice is defined independently
✅ Result:
- Scalable architecture
- Clean separation of concerns
- Easier multi-service management
🔹 3. Drift Detection & Self-Healing
This was the biggest “aha!” moment.
I tested:
- Manually modifying a deployment
- Changing image versions outside Git
📌 Result:
ArgoCD instantly detected the drift and reconciled it automatically.
👉 No manual rollback. No panic fixes. Just automation.
🧠 What This Means in Real-World DevOps
This project reflects how modern teams operate:
| Traditional Approach | GitOps Approach |
|---|---|
| Manual deployments | Automated sync |
| Human error risk | Self-healing systems |
| Drift goes unnoticed | Drift auto-corrected |
| Config scattered | Git as single truth |
🔐 Challenges & Lessons Learned
⚠️ Secrets Management
- Kubernetes secrets are base64 encoded—not secure enough
- Next step: integrate AWS Secrets Manager
⚠️ State Management
- Local Terraform state is risky
-
Plan: move to:
- S3 backend
- DynamoDB locking
⚠️ Complexity Growth
- GitOps introduces more moving parts
- But the trade-off is worth it for automation + reliability
🚀 What’s Next? (Final Stretch)
Before wrapping up the challenge, I plan to:
- ✅ Implement remote state management
- ✅ Secure secrets with AWS Secrets Manager
- ✅ Enhance CI/CD integration
- ✅ Explore advanced GitOps patterns
💭 Final Thoughts
Day 29 changed how I think about infrastructure.
This isn’t just about provisioning resources anymore—it’s about:
- Building autonomous systems
- Reducing human intervention
- Creating resilient platforms
👉 The goal is no longer just “infrastructure that works”
👉 It’s “infrastructure that fixes itself.”
Top comments (0)