# Advanced Gitops Workflow: Mengelola Infrastruktur Multi-Cloud dengan ArgoCD

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/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:

```bash
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:

```bash
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:

```bash
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:

```bash
# 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:

```yaml
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:

```yaml
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.