Advanced Gitops Workflow: Mengelola Infrastruktur Multi-Cloud dengan ArgoCD

1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02:14 pagi. Ponsel saya tiba-tiba menjerit melengking, membangunkan tidur nyenyak setelah seharian bermigrasi infrastruktur. PagerDuty melaporkan metrik yang membuat darah mendadak berdesir: tingkat error rate pada gerbang API utama melompat dari standar normal di bawah 0.01% menjadi hampir 45%. Bukan hanya itu, edge caching Cloudflare mulai memuntahkan halaman HTTP 502 Bad Gateway karena upstream PHP-FPM dan Node.js di cluster Kubernetes multi-cloud kami mendadak lumpuh total. Tanpa pikir panjang, saya langsung menyambar laptop di samping tempat tidur, membuka terminal, dan bersiap menghadapi mimpi buruk setiap platform engineer.

Sistem kami yang biasanya berjalan mulus menggunakan pendekatan Advanced Gitops Workflow dengan ArgoCD untuk mengorkestrasi cluster di AWS EKS dan Google Cloud GKE mendadak mengalami desync masif. Sekitar sepuluh menit lalu, sebuah pull request yang mengubah konfigurasi secret dan ingress controller baru saja di-merge ke branch main. Alih-alih melakukan rolling update yang anggun, ArgoCD justru secara brutal menghapus beberapa objek Kubernetes penting karena definisi deklaratif di Git mengalami drift akibat penerapan skrip manajemen manual yang lalai dihapus sebelumnya. Layanan web utama kami, mulai dari frontend Next.js, backend Go, hingga koneksi WebSocket real-time, berguguran satu per satu seperti kartu domino.

Kepanikan awal langsung ditepis oleh disiplin operasional bertahun-tahun. Sebagai senior staff engineer, saya tahu persis bahwa menebak-nebak tidak akan menyelesaikan masalah. Kita butuh data mentah, dan kita butuh sekarang juga. Jari-jemari langsung menari di atas keyboard, meluncur masuk ke dalam perut sistem untuk melacak jejak digital dari bencana kecil ini.

2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Langkah pertama yang saya ambil bukanlah langsung melakukan rollback buta, melainkan membuka terminal dan memanggil status kesehatan ArgoCD di cluster management. Perintah pertama langsung dieksekusi:

argocd app list --output wide

Hasilnya langsung terpampang nyata di layar terminal yang gelap. Aplikasi utama kami berstatus OutOfSync dan Degraded. Saya kemudian mempersempit investigasi pada log controller ArgoCD untuk melihat apa yang sebenarnya terjadi tepat pukul 02:10 WIB:

kubectl logs -n argocd deployment/argocd-application-controller --tail=100 --follow

Deretan baris log mengalir deras, dan di sanalah saya menemukan pelakunya. ArgoCD mendeteksi adanya conflict pada objek Secret yang dikelola oleh External Secrets Operator yang mengambil data langsung dari HashiCorp Vault. Karena ada perubahan struktur pada file manifest YAML di repositori Git—di mana blok konfigurasi stringData pada Secret Nginx dan PHP-FPM tertimpa oleh template kosong—ArgoCD memutuskan untuk mengeksekusi perintah prune secara otomatis. Akibatnya, environment variables penting yang dibutuhkan oleh backend Go dan koneksi database MySQL lenyap seketika, membuat aplikasi mengalami crash loopback beruntun.

Untuk memastikan sejauh mana kerusakan pada tingkat pod, saya memeriksa status pods di namespace produksi:

kubectl get pods -n production --field-selector=status.phase!=Running

Benar saja, puluhan pod terjebak dalam status CrashLoopBackOff. File log Nginx dan PHP-FPM dibanjiri pesan error koneksi database yang gagal karena variabel DB_HOST dan REDIS_URL bernilai kosong. Jejak digital ini memperjelas satu hal: ini bukan kegagalan infrastruktur cloud, melainkan kesalahan fatal dalam manajemen state deklaratif GitOps yang tidak dilengkapi dengan pengaman validasi schema sebelum merge.

3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Setelah menggali lebih dalam, akar masalah dari insiden ini terbagi menjadi tiga lapisan kegagalan arsitektural yang saling bertaut. Pertama, fitur Auto-Prune di ArgoCD diaktifkan tanpa batasan safeguard yang memadai pada ApplicationSet. Ketika seorang junior engineer menghapus baris konfigurasi secara tidak sengaja di Git, ArgoCD menganggap itu sebagai instruksi valid untuk menghapus sumber daya terkait di kluster produksi multi-cloud.

Kedua, integrasi antara HashiCorp Vault dan External Secrets Operator mengalami race condition sesaat setelah sinkronisasi ulang dilakukan. Vault sempat merespons dengan HTTP 429 Too Many Requests karena lonjakan read request dari dua cluster Kubernetes secara bersamaan, yang membuat External Secrets gagal memperbarui token dan menghasilkan Secret kosong di dalam cluster.

Ketiga, tidak ada validasi pre-commit atau CI pipeline yang memeriksa apakah manifest YAML yang dihasilkan valid secara semantik sebelum masuk ke branch utama. Ini adalah celah klasik dalam kultur Move Fast and Break Things yang mengabaikan prinsip Declarative GitOps Safeguards. Untuk menyelamatkan situasi, kita harus segera melakukan tindakan darurat sebelum bos besar mengirimkan pesan WhatsApp menanyakan kondisi sistem.

4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Hitungan Menit

Waktu terus berjalan dan setiap detik downtime berarti kerugian finansial. Kita harus segera mematikan fitur Auto-Prune yang merusak, mengembalikan versi manifest Git ke kondisi stabil sebelumnya, dan memaksa sinkronisasi manual secara terkontrol.

Berikut adalah rangkaian perintah darurat (emergency runbook) yang saya eksekusi langsung dari terminal untuk memulihkan layanan dalam waktu kurang dari 60 detik:

# 1. Nonaktifkan sementara auto-sync dan auto-prune pada ArgoCD application yang bermasalah
argocd app set production-core-infra --autosync=false

# 2. Lakukan rollback pada repositori Git ke commit stabil terakhir
git revert --no-commit HEAD && git commit -m "Emergency rollback: revert bad secret manifest changes" && git push origin main

# 3. Paksa ArgoCD untuk melakukan sync ulang dengan kebijakan skip pruning
argocd app sync production-core-infra --prune=false

# 4. Restart deployment backend Go dan PHP-FPM untuk memuat ulang secret yang sudah pulih
kubectl rollout restart deployment/backend-api -n production
kubectl rollout restart deployment/php-fpm-app -n production

Setelah perintah tersebut dieksekusi, metrik di dashboard Prometheus dan grafana mulai menunjukkan penurunan error rate yang signifikan. Pod-pod yang tadinya mengalami CrashLoopBackOff perlahan berubah status menjadi Running dan health check dari Cloudflare kembali mengembalikan status HTTP 200 OK. Layanan berhasil diselamatkan.

5. Kebijakan Retrospektif: Menambal Celah agar Tak Pernah Terulang

Insiden pukul 02:14 pagi ini memberikan pelajaran mahal tentang bagaimana memperlakukan infrastruktur sebagai kode. Kita tidak bisa lagi hanya mengandalkan kepercayaan pada setiap pull request yang masuk. Oleh karena itu, saya merumuskan beberapa kebijakan defensif baru yang wajib diterapkan oleh seluruh tim:

1. Mematikan Auto-Prune Global: ArgoCD tidak boleh lagi diizinkan untuk menghapus sumber daya penting (namespace, secret, persistent volume) secara otomatis tanpa konfirmasi manual (soft-prune).
2. Validasi Ketat dengan Conftest & OPA (Open Policy Agent): Setiap pull request kini harus melewati pemeriksaan Gatekeeper di GitHub Actions untuk memvalidasi apakah ada properti penting yang hilang dari file Kubernetes manifest.
3. Rate Limiting Vault: Mengonfigurasi ulang Vault dengan kebijakan token caching yang lebih agresif di sisi External Secrets Operator guna menghindari lonjakan request saat mass synchronization terjadi.

Berikut adalah contoh konfigurasi ArgoCD Application yang kini sudah diamankan dengan kebijakan SyncPolicy yang defensif:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-core-infra
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/company/infrastructure-gitops.git'
    targetRevision: HEAD
    path: k8s/overlays/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated:
      prune: false # PERINGATAN: Jangan pernah set true untuk objek kritis tanpa safeguard!
      selfHeal: true
    syncOptions:
      - Validate=true
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

6. Pasang Alarm: Otomasi Deteksi Dini untuk Tim On-Call

Agar kejadian serupa tidak sampai membangunkan kita di tengah malam tanpa peringatan dini, kita perlu memasang jaring pengaman berlapis berupa aturan Alerting di Prometheus yang memantau kesehatan ArgoCD secara spesifik. Jika terjadi sync failure atau lonjakan objek OutOfSync selama lebih dari 3 menit, sistem harus segera memberikan eskalasi ringan ke channel Slack khusus sebelum berubah menjadi bencana produksi.

Berikut adalah definisi Prometheus Alert Rule yang saya pasang untuk memantau kesehatan siklus GitOps kita:

groups:
  - name: argocd-health-alerts
    rules:
      - alert: ArgoCDApplicationDegraded
        expr: argocd_app_info{health="Degraded"} == 1
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "ArgoCD application {{ $labels.name }} is in Degraded state"
          description: "Aplikasi GitOps mengalami masalah sinkronisasi atau kesehatan resource menurun drastis di cluster produksi."

      - alert: ArgoCDSyncFailed
        expr: argocd_app_sync_status{status="Failed"} == 1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "ArgoCD application {{ $labels.name }} sync failed"
          description: "Sinkronisasi deklaratif gagal total. Segera periksa log controller dan status manifest Git!"

Dengan sistem deteksi dini ini, tim on-call kini memiliki waktu reaktif yang cukup sebelum layanan publik benar-benar terdampak. Infrastruktur multi-cloud kita kini jauh lebih tangguh, terdokumentasi dengan baik, dan siap menghadapi beban kerja skala enterprise tanpa rasa cemas.