Automasi Zenith-X: Dari Nol ke GitOps Auto-Deploy

Yo, jadi gini ceritanya. Gue punya satu misi: bikin infrastruktur cloud dari nol yang bisa auto-deploy sendiri. Nggak pakai manual SSH ke server, nggak pakai copy-paste YAML sana-sini. Semuanya harus otomatis, reproducible, dan tentunya production-grade. Dan dari situlah Project Zenith-X lahir.

Kenapa GitOps? Kenapa Nggak CI/CD Biasa Aja?

Oke, sebelum masuk ke teknis, gue mau jelasin dulu kenapa gue milih GitOps. Jadi kalau CI/CD "biasa", pipeline lo yang nge-push perubahan ke server. Tapi di GitOps, Git adalah sumber kebenaran. Lo cukup push manifest ke Git, terus ada "agen" di dalam cluster (dalam kasus ini ArgoCD) yang terus-terusan nge-watch Git repo lo. Begitu ada perubahan, dia langsung sync. Simple, clean, dan yang paling penting: semuanya bisa di-audit lewat Git history.

Yang Gue Bangun

Stack-nya lumayan banyak tapi semuanya saling terhubung dengan rapi:

• Terraform buat nge-provisioning semua infrastruktur GCP dari VPC, GKE cluster pakai Spot nodes (biar hemat!), sampai IAM dan Workload Identity.
• ArgoCD sebagai otak GitOps yang nge-deploy semua aplikasi dan add-on ke cluster secara otomatis.
• Traefik sebagai ingress controller buat routing traffic dari internet ke aplikasi.
• Cert-Manager buat otomasi SSL certificate dari Let's Encrypt. Bye-bye self-signed cert!
• External Secrets Operator buat narik secret dari Google Secret Manager ke Kubernetes. Jadi nggak ada credential yang hardcode di mana pun.
• GitHub Actions sebagai CI/CD pipeline yang build Docker image, push ke Artifact Registry, dan update manifest di Git. Semuanya pakai Workload Identity Federation — alias nggak pakai JSON key sama sekali. Keyless authentication, bro.

Alur Kerjanya

Developer push kode → GitHub Actions build image → Push ke Artifact Registry
→ Update image tag di Git → ArgoCD detect perubahan → Auto-deploy ke GKE
→ Traefik route traffic → Let's Encrypt kasih SSL → Secret dari GSM ter-inject

Satu kali push, semuanya jalan sendiri. Chef's kiss. 🤌

Drama yang Terjadi (a.k.a. Error-Error Menyebalkan)

Nah, ini bagian serunya. Nggak ada project yang mulus tanpa drama, dan Zenith-X punya beberapa episode yang cukup bikin naik darah:

🔥 Episode 1: Cluster yang Ke-Recreate Terus

Ini sih yang paling bikin frustrasi. Setiap kali gue jalanin terraform apply, Terraform dengan santainya bilang "oh, ada perubahan nih, gue destroy dulu ya clusternya terus bikin baru." Bro, cluster itu butuh 15 menit buat dibuat ulang! Belum lagi semua yang udah di-deploy (ArgoCD, Traefik, cert, semuanya) hilang semua.

Ternyata masalahnya: GCP secara otomatis nge-update beberapa parameter cluster kayak node_version dan konfigurasi internal lainnya. Terraform nge-compare state file sama kondisi aktual, nemu "drift", dan memutuskan buat recreate. Solusinya? Tambahin lifecycle { ignore_changes = [...] } di Terraform. Ini kayak bilang ke Terraform: "Eh, parameter ini bukan urusan lo ya, biarin aja."

Lesson learned: Kalau pakai managed service kayak GKE, SELALU pakai ignore_changes untuk parameter yang dikelola oleh cloud provider. Kalau nggak, siap-siap aja cluster lo di-destroy bolak-balik.

🔥 Episode 2: External Secrets — "Permission Denied" yang Misterius

Ini juga seru. Gue udah setup semuanya dengan benar (atau setidaknya gue pikir benar):

• Google Service Account (GSA) punya role secretmanager.secretAccessor ✅
• IAM binding Workload Identity udah di-set ✅
• ClusterSecretStore pointing ke GSM ✅

Tapi ESO tetap error: PermissionDenied: secretmanager.versions.access denied. WTF?

Setelah debugging berjam-jam, ternyata masalahnya receh banget: Kubernetes ServiceAccount (KSA) nggak punya annotation iam.gke.io/gcp-service-account. Tanpa annotation ini, Workload Identity nggak tahu KSA mana yang boleh "menyamar" sebagai GSA.

Dan kenapa annotation-nya nggak ke-apply? Karena indentasi YAML yang salah di Helm values ArgoCD. Satu spasi yang salah, nggak ada error message, tapi konfigurasi-nya nggak jalan. Silent failure. Ini tipe bug yang bikin lo questioning life choices.

Lesson learned: Kalau Workload Identity gagal, SELALU cek KSA annotation dulu. Itu titik kegagalan nomor satu. Dan double-check indentasi YAML lo, karena satu spasi bisa bikin segalanya berantakan.

🔥 Episode 3: Git Conflict dari CI/CD

Yang ini relatif minor tapi tetap annoying. Gue push kode, GitHub Actions jalan, dia update image tag di manifest lalu commit balik ke Git. Tapi pas gue mau push perubahan infrastructure, boom — conflict karena remote udah berubah.

Solusinya gampang: git pull --rebase sebelum push. Tapi ini reminder penting bahwa kalau CI/CD dan developer kerja di branch yang sama, komunikasi lewat Git harus disiplin.

Cleanup — Bersihin Semua Biar Nggak Kena Billing

Setelah semua selesai dan terdokumentasi, saatnya cleanup:

cd terraform && terraform destroy
cd state-bootstrap && terraform destroy

Fun fact: Terraform nggak bisa langsung hapus VPC karena ada orphaned firewall rules yang ditinggalin GKE. Jadi harus di-delete manual dulu pakai gcloud compute firewall-rules delete sebelum VPC bisa di-destroy. Lagi-lagi, lesson learned.

Penutup

Project Zenith-X ini buat gue bukan cuma soal bikin infrastruktur. Ini soal memahami bagaimana setiap komponen cloud saling terhubung — dari networking, compute, identity, sampai secret management. Dan yang paling penting, semua ini bisa diulang kapan aja cukup dengan terraform apply dan satu kubectl apply.

Kalau lo lagi belajar DevOps atau cloud engineering, gue sangat rekomendasi untuk bikin project serupa. Nggak harus persis sama, tapi coba aja bangun sesuatu yang end-to-end: dari provisioning sampai deployment. Percaya deh, lo bakal belajar jauh lebih banyak daripada cuma baca dokumentasi.

Stay relevant, keep building. 🚀

👉 Cek source code Zenith-X di GitHub