Advanced GitOps Workflows: Mengelola Infrastruktur Skala Besar dengan ArgoCD

Pukul tiga pagi, pagerDuty saya menjerit tanpa ampun. Cluster Kubernetes multi-region di Frankfurt dan Virginia mendadak mengalami split-brain configuration setelah seorang engineer melakukan hotfix manual langsung via kubectl apply di production. Layanan e-commerce skala enterprise down, transaksi senilai ribuan dolar per detik tersendat, dan manajemen bertanya-tanya mengapa otomatisasi infrastruktur kita bisa semrawut ini. Di sinilah pertarungan arsitektur dimulai: apakah kita tetap bertahan dengan skrip Imperative CI/CD tradisional (seperti Jenkins/GitLab CI push-based) yang rentan human error, atau beralih sepenuhnya ke ekosistem Declarative GitOps berbasis ArgoCD (pull-based) yang menjaga state cluster selalu sinkron dengan repository Git?

Mari kita bedah langsung performa dan filosofinya melalui Head-to-Head Architectural Battle antara ArgoCD (GitOps Pull-based) melawan Jenkins CI/CD (Imperative Push-based) dalam mengelola infrastruktur web modern berskala masif.

[!IMPORTANT] Dalam infrastruktur web skala besar yang melayani jutaan request per hari, manajemen state berbasis push dari luar cluster adalah bom waktu keamanan dan konsistensi.

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Bayangkan Anda mengelola ratusan mikroservis backend (Go, Node.js, PHP-FPM), server web Nginx/Caddy di edge, database MySQL/Redis, hingga konfigurasi DNS Cloudflare. Pendekatan tradisional menggunakan Jenkins CI/CD bekerja seperti seorang kurir pos: ketika ada kode baru di Git, server Jenkins akan berlari membawa paket tersebut dan 'memaksa' masuk ke dalam server produksi atau cluster Kubernetes (kubectl apply). Masalahnya, jika kurir terjebak macet (network partition) atau salah alamat, sistem produksi berantakan.

Sebaliknya, ArgoCD menganut filosofi Pull-based GitOps. ArgoCD bertindak sebagai satpam mandiri yang berpatroli di dalam cluster Kubernetes Anda. Ia terus-menerus memantau repository Git (source of truth). Jika ada perbedaan (drift) antara apa yang tertulis di Git dan apa yang berjalan di server, ArgoCD secara otomatis menarik (pull) perubahan tersebut dan menyamakannya. Tidak ada lagi kredensial production yang disimpan di server CI/CD eksternal; cluster Anda mengambil sendiri apa yang dibutuhkannya.

Transisi dari model dorong ke model tarik ini memaksa tim untuk mengubah pola pikir: Infrastructure as Code bukan lagi sekadar slogan, melainkan hukum mutlak di mana Git adalah satu-satunya penguasa.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Mari kita lihat bagaimana kedua pendekatan ini terasa di tangan seorang engineer saat deadline mendesak. Di Jenkins, Anda harus menulis file Jenkinsfile yang panjang, penuh dengan skrip Groovy, penanganan error manual, dan pemanggilan sh 'kubectl apply -f k8s/'. Seringkali, debugging menjadi mimpi buruk ketika baris ke-150 gagal karena masalah environment.

Di ArgoCD, Anda cukup mendefinisikan Application Custom Resource (CRD) yang bersih dan deklaratif. Berikut adalah contoh manifest valid yang mendeklarasikan deployment infrastruktur web kita ke ArgoCD:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-web-cluster
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: 'https://github.com/perusahaan/infra-gitops.git'
    targetRevision: HEAD
    path: k8s/overlays/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

[!TIP] Dengan mengaktifkan selfHeal: true dan prune: true, ArgoCD akan langsung menghapus resource liar yang dibuat manual via CLI dan mengembalikan cluster ke kondisi bersih sesuai file YAML di Git.

3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Ketika kami melakukan uji beban (k6) dengan 50.000 virtual users yang menghantam API backend Go dan edge caching Nginx, stabilitas control plane diuji secara brutal. Pada skenario Jenkins, ketika terjadi lonjakan deployment massal bersamaan dengan traffic tinggi, Jenkins master sering mengalami Out of Memory (OOM) karena proses build dan deployment berjalan simultan di node yang sama.

Sementara itu, ArgoCD membuktikan keunggulannya dalam arsitektur terdistribusi berbasis Kubernetes. ArgoCD Application Controller memisahkan tugas rekonsiliasi. Saat traffic melonjak, ArgoCD tidak melakukan heavy lifting seperti compilling kode atau running unit test (itu tugas pipeline terpisah seperti GitLab CI). ArgoCD hanya fokus membaca manifest Kubernetes dan memastikan state cluster valid. Hasil pengujian menunjukkan latensi rekonsiliasi ArgoCD tetap stabil di bawah 300 milidetik bahkan saat cluster memproses 500 pods simultan.

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Dari sisi finansial infrastruktur, efisiensi adalah segalanya. Jenkins memerlukan dedicated worker nodes yang menyala 24/7 atau sistem dynamic agents yang memakan waktu spin-up (cold start) beberapa menit setiap kali ada job baru.

ArgoCD berjalan ringan di dalam cluster Kubernetes yang sudah ada. Menggunakan namespace khusus dengan limit resource yang ketat:

resources:
  limits:
    cpu: "2"
    memory: 2Gi
  requests:
    cpu: 500m
    memory: 512Mi

ArgoCD hanya mengonsumsi sekitar 1 hingga 2 core CPU dan kurang dari 1 GB RAM untuk mengelola ribuan resource objects di tiga region berbeda. Efisiensi ini memangkas biaya cloud bulanan secara signifikan dibandingkan mempertahankan beberapa instance Jenkins master dengan storage disk SSD yang membengkak akibat log build.

5. Kapan Wajib Menggunakan ArgoCD

Anda wajib menggunakan ArgoCD ketika infrastruktur Anda sudah sepenuhnya berbasis Kubernetes, mengelola arsitektur mikroservis multi-cluster atau multi-region, dan menuntut tingkat keamanan audit compliance yang ketat (SOC2/ISO). Ketika tim Anda sepakat bahwa “Jika tidak ada di Git, berarti itu tidak pernah terjadi”, maka ArgoCD adalah senjata pamungkas yang memberikan visibilitas UI real-time, manajemen secret terintegrasi dengan External Secrets Operator, serta kemampuan automated rollback dalam hitungan detik tanpa intervensi manusia.

6. Kapan Wajib Menggunakan Jenkins CI/CD

Di sisi lain, jangan gunakan ArgoCD jika aplikasi web Anda masih monolitik tradisional yang berjalan di atas sekumpulan Virtual Private Server (VPS) berbasis Linux murni tanpa Kubernetes. Jika infrastruktur Anda hanya terdiri dari Nginx, PHP-FPM, MySQL, dan Redis yang di-deploy menggunakan skrip Ansible atau Bash sederhana, Jenkins atau GitLab CI jauh lebih masuk akal dan tidak memerlukan kompleksitas kurva belajar Kubernetes.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Pertarungan antara ArgoCD dan Jenkins bukanlah soal mana yang mutlak lebih baik, melainkan kecocokan fase evolusi teknologi perusahaan Anda. Jika Anda sedang membangun fondasi web scale-up modern dengan orkestrasi kontainer masif, adopsi ArgoCD untuk GitOps adalah investasi jangka panjang terbaik yang akan menyelamatkan tidur malam Anda dari gangguan insiden produksi pukul tiga pagi.

Namun, jika sistem Anda masih sederhana dan belum mengadopsi cloud-native sepenuhnya, fokuslah merapikan skrip otomasi yang ada sebelum terjebak dalam over-engineering Kubernetes. Gunakan teknologi sesuai skala masalah yang Anda hadapi hari ini, dengan mata tetap terbuka untuk eskalasi masa depan.