Belajar GitOps dengan ArgoCD - Sejarah, Latar Belakang & Mengapa Membutuhkan GitOps
Dari deployment manual hingga Infrastructure as Code, kenapa Weaveworks memperkenalkan istilah GitOps pada 2017, masalah yang dipecahkannya, dan mengapa model pull mengalahkan model push.
#Pendahuluan
Di episode 0 kita sudah menyiapkan seluruh tools dan memverifikasinya. Sekarang saatnya mundur sejenak dari keyboard dan bertanya satu hal yang paling penting: mengapa GitOps ada? Karena sebelum memahami sebuah alat, kita harus paham dulu masalah apa yang ia pecahkan — dan alat yang dipilih tanpa memahami masalahnya akan menjadi keputusan yang rapuh.
Epilepsia ini seperti membaca sejarah sebelum membeli mesin: setelah kalian tahu betapa menyakitkannya deployment manual dan betapa rapuhnya script, kalian akan mengerti kenapa dunia beralih ke GitOps. Di episode ini kita akan membahas evolusi deployment practices, kelahiran istilah GitOps oleh Weaveworks, masalah-masalah yang diselesaikannya, empat prinsip GitOps, perbandingan model push vs pull, dan manfaat yang bisa kalian rasakan.
#Evolusi Deployment Practices
Perjalanan menuju GitOps melalui empat era, dan setiap era lahir sebagai jawaban atas rasa sakit di era sebelumnya.
#Era 1: Manual Deployment
Di era awal, mendeploy aplikasi berarti login SSH ke server, menyalin artefak, menjalankan proses secara manual, lalu berharap semuanya berjalan. Setiap server diperlakukan sebagai individu. Tidak ada catatan siapa mengubah apa; semuanya bergantung pada ingatan dan disiplin orang yang mengeksekusi.
Masalahnya jelas: manusia tidak konsisten. Satu orang lupa mengubah konfigurasi environment, yang lain menginstall versi berbeda, dan tidak ada satu pun jejak yang bisa diaudit. Inilah akar dari banyak kegagalan produksi klasik.
#Era 2: Script-Based Deployment
Sebagai jawaban, para engineer mulai menulis shell script untuk mengotomatiskan urutan langkah deployment:
#!/bin/bash
set -euo pipefail
kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl set image deployment/api api=ghcr.io/arman/api:v1.2.0
kubectl rollout status deployment/apiScript ini imperative: menuliskan langkah demi langkah untuk mencapai hasil akhir. Lebih baik dari manual, tapi rapuh. kubectl set image menimpa state langsung di cluster, dan jika dua orang menjalankan script berbeda di waktu bersamaan, hasil akhirnya ditentukan oleh siapa yang terakhir mengeksekusi — bukan oleh siapa yang benar.
#Era 3: CI/CD Pipelines
Berikutnya datang CI/CD: Jenkins, GitLab CI, GitHub Actions, dan kawan-kawan mengotomatiskan build, test, dan deploy. Ini lompatan besar — deployment menjadi terdokumentasi di pipeline, dan gagal bisa langsung terdeteksi.
Namun ada kelemahan struktural yang melekat: model push. Pipeline memegang credential cluster dan mendorong perubahan ke produksi. Semakin banyak pipeline, semakin banyak credential tersebar. Dan karena deploy digerakkan dari luar cluster, sulit menjawab pertanyaan sederhana: "apakah cluster benar-benar dalam kondisi yang kita inginkan?"
#Era 4: Infrastructure as Code (IaC)
IaC mendeklarasikan infrastruktur sebagai kode: terraform untuk cloud, kustomize dan helm untuk Kubernetes. Sekarang kita bisa mereview infrastruktur di pull request dan mengaudit melalui riwayat Git. IaC menyelesaikan bagaimana infrastruktur didefinisikan — tapi belum menyelesaikan bagaimana perubahan itu sampai dan dipertahankan di cluster.
#Era 5: Lahirnya GitOps
Di sinilah GitOps melengkapi teka-tekinya: IaC memberikan definisi, Git memberikan rekam jejak, dan operator seperti ArgoCD memberikan eksekutor yang terus-menerus menyelaraskan. Git menjadi satu-satunya sumber kebenaran, dan cluster tidak lagi menunggu dorongan dari luar — ia menarik keinginannya sendiri dari Git.
#Apa itu GitOps?
Istilah GitOps pertama kali dicetuskan oleh Weaveworks pada tahun 2017 sebagai model operasional untuk Kubernetes: Git sebagai single source of truth untuk sistem yang bersifat declarative, dan agent otomatis yang berjalan di dalam cluster mewujudkan serta menjaga kondisi tersebut.
Intinya: "apa yang ada di Git adalah kebenaran. Cluster harus sama dengan Git. Selalu."
#Masalah yang Diselesaikan GitOps
GitOps lahir untuk menyelesaikan masalah-masalah nyata di lapangan:
| Masalah | Gejala | Solusi GitOps |
|---|---|---|
| Configuration drift | Cluster menyimpang dari konfigurasi yang diinginkan | Reconciliation terus-menerus mengembalikan kondisi |
| Manual deployment errors | Kesalahan manusia saat deploy | Perubahan hanya lewat Git + review PR |
| Kurangnya auditability | Tidak tahu siapa mengubah apa | Riwayat Git adalah audit trail lengkap |
| Rollback rumit | Sulit kembali ke kondisi sebelumnya | git revert + sync otomatis |
| Ketidakkonsistenan environment | dev dan prod berbeda jauh | Satu definisi sumber untuk semua |
| Kontrol akses berantakan | Banyak credential tersebar di pipeline | Model pull: hanya ArgoCD yang butuh akses |
| Visibilitas deployment | Tidak tahu status sebenarnya | Status sync dan health tampak real-time |
Important
Configuration drift adalah musuh utama. Bayangkan sebuah Deployment di produksi diubah manual oleh seseorang via kubectl scale deployment api --replicas=10. Sistem tidak salah — tetapi definisi di Git (misal replicas: 3) dan kondisi cluster (10 replika) kini berbeda. Drift seperti ini menumpuk diam-diam dan menjadi akar kegagalan yang tidak terduga.
#Empat Prinsip GitOps
Sesuai definisi Weaveworks, sistem yang benar-benar GitOps harus memenuhi empat prinsip:
- Declarative — seluruh sistem dideskripsikan sebagai kondisi akhir yang diinginkan, bukan urutan langkah. Manifest YAML di Git adalah satu-satunya bentuk kebenaran.
- Versioned dan immutable — setiap perubahan adalah commit baru. Definisi tidak pernah diubah "di tempat"; selalu direvisi dan dapat dikembalikan.
- Pulled secara otomatis — perubahan diambil oleh agent di dalam cluster (model pull), bukan didorong oleh sistem eksternal yang memegang credential.
- Terus-menerus direconciled — agent membandingkan kondisi nyata vs kondisi diinginkan, lalu menyelaraskannya secara otomatis. Kalau ada yang mengubah cluster manual, agent mengembalikannya.
#Push vs Pull Model
Perbedaan model ini menentukan arsitektur keamanan dan keandalan deployment:
| Aspek | Push (CI/CD tradisional) | Pull (GitOps) |
|---|---|---|
| Pemicu deployment | Pipeline eksternal | Perubahan di Git yang dideteksi agent |
| Akses cluster | Banyak tool memegang credential | Hanya operator di dalam cluster |
| Kondisi aktual | Tidak terpantau terus-menerus | Selalu direconciled |
| Rollback | Pipeline khusus | Revert Git, agent mengikuti |
| Audit | Log pipeline | Riwayat commit Git |
Model pull lebih aman karena credential cluster tidak tersebar ke luar, dan lebih andal karena kondisi cluster terus dipaksa kembali ke kondisi yang diinginkan.
#Manfaat GitOps
Secara ringkas, inilah yang kalian dapatkan:
- Single source of truth — Git menjawab semua pertanyaan tentang kondisi sistem.
- Keamanan lebih baik — akses cluster seminimal mungkin.
- Deployment lebih cepat — PR dan review menggantikan proses manual yang lambat.
- Reliabilitas meningkat — drift dan error manusia berkurang drastis.
- Kolaborasi lebih baik — infrastruktur direview seperti kode aplikasi.
- Disaster recovery — rebuild cluster = re-sync dari Git.
- Compliance dan auditability — riwayat lengkap siapa, apa, kapan.
#Penutup
Episode ini membangun pijakan konseptual seluruh seri:
- Deployment berevolusi dari manual, script, CI/CD, IaC, hingga GitOps.
- GitOps dicetuskan Weaveworks (2017): Git sebagai single source of truth.
- Masalah utama yang dipecahkan: drift, error manual, audit, rollback, dan visibilitas.
- Empat prinsip: declarative, versioned, pulled, dan terus direconciled.
- Model pull lebih aman dan andal dibandingkan model push.
Sekarang kalian tahu mengapa GitOps ada. Di episode 2 kita akan membahas ekosistem GitOps dan overview ArgoCD: peta persaingan dengan Flux dan Jenkins X, arsitektur komponen ArgoCD, core concepts-nya, dan bagaimana loop reconciliation bekerja. Sampai jumpa!