Belajar GitOps - FluxCD - Sejarah, Latar Belakang & Mengapa Membutuhkan GitOps

#Pendahuluan

Di episode 0 kalian sudah menyiapkan seluruh environment: cluster Kubernetes, kubectl, Helm, Kustomize, dan Flux CLI. Sekarang saatnya berhenti sejenak dari terminal dan memahami mengapa semua tools itu dibutuhkan. GitOps bukan sekadar tools — ia adalah filosofi operasi yang lahir dari rasa sakit nyata di dunia deployment aplikasi.

Episode ini menelusuri sejarah lahirnya GitOps: siapa yang menciptakannya, mengapa Flux menjadi proyek paling awal yang mewujudkannya, dan masalah-masalah konkret yang diselesaikan oleh pola pikir ini. Pemahaman sejarah ini penting karena seluruh keputusan desain FluxCD di episode-episode berikutnya — dari arsitektur controller sampai cara kerjanya membaca Git — adalah jawaban terhadap masalah yang dibahas di episode ini.

#Evolusi Deployment Aplikasi

Sebelum GitOps, dunia deployment mengalami perjalanan panjang yang meninggalkan banyak luka.

#Era Imperative dan Manual

Awalnya deployment dilakukan sepenuhnya manual: SSH ke server, menarik image, menyalakan proses. Masalahnya jelas — tidak ada catatan perubahan, tidak ada cara mengulang hasil yang sama, dan satu typo bisa merusak produksi tanpa jejak audit. Coba tanya diri kalian: kalau server produksi mati hari ini, bisakah kalian membangun ulang persis seperti semula?

#Era Infrastructure as Code

Masuk era Infrastructure as Code (IaC): server dan pipeline didefinisikan sebagai kode. Ini langkah maju besar, tetapi ada celah: siapa yang mengeksekusi konfigurasi itu? Biasanya pipeline CI/CD yang menjalankan kubectl apply ke cluster. Akibatnya muncul istilah "config drift" — konfigurasi di Git sudah tidak sesuai dengan kondisi nyata di cluster, karena ada perubahan manual yang tidak tercatat, atau karena tidak ada yang memverifikasi apa yang terjadi setelah apply.

Perbedaan filosofinya bisa dilihat dari perintah yang dipakai kedua era ini:

# Cara lama: perintah imperative sekali jalan dari CI
ssh deploy@prod "docker pull registry/myapp:1.2 && docker restart myapp"
 
# Cara GitOps: ubah nilai di Git, agent di dalam cluster yang bekerja
git add deploy/myapp.yaml
git commit -m "chore: update image myapp ke 1.2"
git push origin main

Perhatikan baris terakhir: tidak ada SSH ke server, tidak ada kubectl apply dari CI. Yang terjadi hanyalah perubahan di Git — sisanya dikerjakan oleh agent yang berjalan di dalam cluster. Inilah inti pergeseran paradigma dari push ke pull.

#Kelahiran GitOps dan Weaveworks

Titik balik terjadi di tahun 2017. Weaveworks, perusahaan yang mengembangkan tools untuk Kubernetes, memperkenalkan istilah GitOps sebagai pola operasi di mana Git menjadi sumber kebenaran tunggal untuk sistem deployment. Sebelum nama itu lahir, Weaveworks sudah membangun Flux v1 — tool yang secara terus-menerus menyinkronkan cluster dengan repository Git, dan inilah yang menjadi cikal bakal FluxCD yang kita kenal sekarang.

Setelah istilah GitOps populer, komunitas berkumpul membentuk GitOps Working Group di dalam CNCF untuk menyepakati definisi dan prinsipnya. Pada tahun 2020+, proyek Flux mengalami titik balik kedua: Flux v2 dirancang ulang total dengan arsitektur modular yang disebut GitOps Toolkit. Flux v2 kemudian masuk program CNCF sandbox dan akhirnya graduated sebagai salah satu proyek CNCF yang paling matang.

Garis waktu ringkasnya:

#Empat Prinsip Inti GitOps

GitOps berdiri di atas empat prinsip yang didefinisikan komunitas. Seluruh desain FluxCD mengikuti prinsip ini:

Bandingkan dengan cara lama: kubectl apply sekali lalu tidak ada yang memantau. GitOps tidak berhenti setelah apply — ia menjaga keadaan selamanya.

Frasa kuncinya adalah pulled automatically. Pada arsitektur push, kredensial cluster harus dibawa ke tempat CI berjalan — potensi kebocoran yang besar. Pada model pull, agent di dalam cluster yang memegang kredensial, sementara Git cukup menyediakan konfigurasi yang aman untuk dibaca siapa pun yang berhak. Inilah salah satu alasan GitOps dianggap lebih aman secara desain, bukan sekadar karena kebiasaan yang baik.

Kombinasi empat prinsip ini menghasilkan jaminan penting: apa pun yang terjadi pada cluster, selama Git tetap benar, sistem akan kembali ke kondisi yang dideklarasikan. Prinsip inilah yang kemudian diwujudkan secara ketat oleh FluxCD.

#Masalah yang Diselesaikan GitOps

Kenapa kita butuh pola seperti ini? Karena masalah-masalah berikut terlalu sering terjadi di tim yang memakai deployment manual atau CI-driven:

• Configuration drift detection: perbedaan antara kondisi nyata dan Git terdeteksi dan otomatis dikoreksi, bukan dibiarkan menumpuk.
• Penghapusan deployment manual: tidak ada lagi "deploy diam-diam" lewat SSH; semua perubahan melalui Git.
• Audit trail melalui Git: setiap perubahan punya riwayat commit — siapa, kapan, dan apa.
• Konsistensi environment: dev, staging, dan produksi mengikuti konfigurasi yang sama dari repo yang sama.
• Disaster recovery yang sederhana: cluster baru cukup ditarik ke Git; tidak perlu merekonstruksi dari ingatan.
• Kemampuan rollback: kegagalan bisa dikembalikan dengan git revert atau checkout commit sebelumnya.

Perhatikan pola yang sama di balik semua masalah ini: semuanya muncul karena tidak ada satu sumber kebenaran yang hidup. GitOps menutup celah itu dengan menjadikan Git sebagai otoritas tunggal, sekaligus memberi tim alat untuk menegakkan otoritas tersebut secara otomatis.

#Manfaat bagi Tim dan Organisasi

Dari sudut pandang praktis, GitOps mengubah cara kerja tim dalam enam hal besar:

• Git sebagai single source of truth: satu repo menjadi jawaban untuk "apa yang sedang berjalan di produksi?"
• Keamanan meningkat: kredensial cluster tidak perlu berada di CI — agent di dalam cluster yang menarik konfigurasi, sehingga tidak ada token cluster yang bocor di pipeline.
• Deployment lebih cepat: tim bisa deploy berkali-kali sehari lewat PR, bukan lewat antrian manual.
• Kolaborasi lebih baik: workflow berbasis PR memberi ruang review dan approval sebelum perubahan masuk.
• Compliance dan auditability: jejak lengkap setiap perubahan otomatis tersedia dari Git.
• Produktivitas developer: developer fokus pada hasil akhir yang dideskripsikan, bukan pada urutan langkah deploy.

#Penutup

Episode 1 meletakkan fondasi konseptual seri ini:

• Sejarah: GitOps diciptakan Weaveworks pada 2017, lahir dari Flux v1, dan matang sebagai Flux v2 versi GitOps Toolkit.
• Prinsip inti: declarative, versioned and immutable, pulled automatically, dan continuously reconciled.
• Masalah nyata: config drift, deploy manual, audit trail, konsistensi environment, disaster recovery, dan rollback.
• Manfaat tim: single source of truth, keamanan, kecepatan, kolaborasi, compliance, dan produktivitas.

Di episode 2 kita masuk ke level arsitektur: mengenal FluxCD v2, mengapa ia memilih arsitektur berbasis controller modular yang disebut GitOps Toolkit, perbandingan FluxCD vs ArgoCD, dan komponen-komponen inti yang menyusunnya. Sampai jumpa di episode berikutnya!