GitOps memperkenalkan metode deklaratif untuk mengelola infrastruktur dan deployment menggunakan Git sebagai sumber kebenaran.
Artikel ini menjelaskan konsep dasar, alat populer, praktik keamanan, serta contoh kasus langkah demi langkah untuk membantu developer menerapkan GitOps dalam proyek nyata dengan fokus pada otomatisasi, observability, dan recovery.
Konsep Dasar dan Prinsip Kerja Otomasi Pengiriman
Dalam otomasi pengiriman modern, perbedaan declarative dan imperative itu krusial. Pendekatan imperative berarti kamu memberi perintah langkah demi langkah, misalnya menjalankan skrip deploy manual.
💻 Mulai Belajar Pemrograman
Belajar pemrograman di Dicoding Academy dan mulai perjalanan Anda sebagai developer profesional.
Daftar SekarangPendekatan declarative fokus pada “state yang diinginkan”, seperti file YAML yang mendefinisikan cara layanan harus berjalan. Tool seperti Argo CD atau Flux kemudian mengerjakan detailnya.
Prinsip utamanya: Git menjadi single source of truth, semua konfigurasi dan manifests tersimpan di sana. Automation controllers menarik konfigurasi dari Git, lalu menjalankan reconciliation loop untuk menyamakan kondisi cluster dengan definisi dalam repositori.
Berbeda dengan banyak praktik DevOps tradisional yang mengandalkan CI pipeline mendorong perubahan ke cluster, pendekatan ini membuat cluster “menarik” perubahan sendiri.
Bagi developer, manfaatnya nyata: reproducibility tinggi, ada audit trail jelas melalui git history, dan rollback cukup dengan git revert.
Namun, ada tantangan awal, seperti kompleksitas tooling, kurva belajar konsep declarative, dan perubahan budaya tim yang harus lebih disiplin terhadap pull request dan code review. Di sinilah arsitektur GitOps dan komponen utamanya menjadi penting untuk dipahami sebelum diadopsi luas dalam organisasi.
Arsitektur GitOps dan Komponen Utama
Dalam arsitektur GitOps, alur dasarnya sederhana: kamu commit ke Git, lalu sistem yang lain mengikuti.
Git repo menyimpan manifests atau configuration as code, menjadi single source of truth. CI pipeline membangun image, menjalankan test, lalu mengubah tag atau versi pada manifests.
Setelah itu, CD controller, seperti Argo CD atau Flux membaca perubahan dan melakukan sync ke cluster target. Di atasnya, observability layer memakai logging, metrics, dan tracing untuk memantau hasilnya.
Aliran datanya bisa diringkas: commit → CI pipeline → update manifests pada Git → CD controller pull → apply ke cluster. Model pull-based ini umum pada GitOps karena controller dalam cluster yang menarik konfigurasi sehingga kredensial tidak perlu keluar dari lingkungan produksi.
Sebaliknya, model push-based memakai sistem luar yang mendorong perubahan ke cluster, lebih sederhana, tetapi berisiko lebih tinggi untuk akses jaringan dan secrets. Untuk skala besar dan banyak cluster, pola pull-based biasanya lebih aman dan mudah diisolasi per environment.
Untuk multi-environment dan multi-cluster, kamu bisa memakai single repo dengan direktori per environment, atau multi-repo yang memisahkan tanggung jawab.
Single repo memudahkan koordinasi perubahan lintas layanan, tetapi butuh governance yang ketat. Multi-repo memberikan otonomi tim serta batasan yang lebih jelas antara app dan infrastructure. Banyak tim menggabungkan keduanya, misalnya satu app repo dan satu environment repo yang hanya berisi manifests produksi.
Supaya arsitektur ini benar-benar terasa manfaatnya, hubungkan alur GitOps dengan DORA metrics. Ukur deployment frequency dari jumlah sync sukses ke cluster, dan lead time dari commit sampai perubahan ter-deploy.
Catat juga MTTR dengan melihat waktu dari insiden sampai rollback atau fix tersinkron. Data ini bisa diambil dari Git events, CI/CD logs, serta observability stack, lalu dipakai untuk mengkalibrasi pipeline dan memilih alat yang akan dibahas dalam bagian berikutnya.
Alat Populer untuk CI/CD dan Infrastructure as Code
Pemilihan alat akan sangat memengaruhi seberapa mulus GitOps workflow kamu berjalan. Untuk CI, opsi populer adalah GitHub Actions, GitLab CI, dan Jenkins.
Hosted CI cocok untuk tim yang ingin minim operasional dan butuh integrasi cepat dengan repositori Git. Self-managed CI lebih tepat bila kamu punya regulasi ketat, butuh kontrol penuh resource, atau integrasi jaringan internal.
Untuk CD controller dalam Kubernetes, dua nama besar adalah Argo CD dan Flux. Keduanya memakai model reconciliation: kondisi cluster terus dibandingkan dengan state pada Git, lalu disinkronkan.
Argo CD unggul di antarmuka UI, application CRD, dan progressive delivery via Argo Rollouts. Flux lebih ringan, sangat modular, dan mudah diintegrasikan dengan Helm dan dikustomisasi melalui custom resources.
Di sisi infrastructure as code, Terraform umum dipakai untuk provisioning cloud (VPC, database, DNS).
Helm efektif untuk mengelola paket aplikasi yang punya banyak nilai konfigurasi, sedangkan Kustomize lebih cocok untuk overlay lingkungan, seperti dev, staging, dan prod tanpa templat. Crossplane membawa resource cloud dalam Kubernetes sebagai custom resources sehingga provisioning infrastruktur juga bisa mengikuti pola GitOps.
Pengelolaan secrets menjadi penting ketika semua konfigurasi disimpan dalam Git. SOPS dan Sealed Secrets memungkinkan kamu menyimpan data terenkripsi pada repo, lalu didekripsi dalam cluster saat reconciliation.
HashiCorp Vault lebih cocok untuk kebutuhan skala besar dengan dynamic secrets dan audit ketat, biasanya diintegrasikan dengan external secrets operator di Kubernetes.
Contoh keputusan arsitektural yang sering muncul adalah memilih Helm chart atau Kustomize untuk aplikasi mikroservis. Jika banyak layanan berbagi komponen yang sama dan butuh konfigurasi sangat parameterizable, Helm biasanya lebih praktis.
Namun, bila kamu ingin patch deklaratif yang mudah ditinjau diff-nya di Git, dan perbedaan lingkungan hanya berupa overlay kecil, Kustomize sering terasa lebih transparan serta mudah diaudit.
Praktik Keamanan dan Kebijakan Git Based Deployment
Pada workflow Git based deployment, keamanan dimulai dari kontrol akses Git. Terapkan branch protection untuk mencegah force push ke main, wajibkan required reviews, dan aktifkan status checks dari pipeline. Tambahkan aturan signed commits dan signed tags (misalnya dengan GPG atau sigstore) agar setiap perubahan punya identitas yang bisa diverifikasi.
Policy as code membantu memastikan konfigurasi aman sebelum menyentuh cluster. Kamu bisa memakai admission controller dengan policy engine, seperti OPA/Gatekeeper atau Kyverno untuk menolak deployment yang melanggar aturan, misalnya container jalan sebagai root atau tanpa resource limits. Kebijakan ditulis sebagai kode, disimpan pada Git, dan di-review seperti perubahan aplikasi.
Untuk secrets, hindari plain text di repo. Gunakan enkripsi, seperti Sealed Secrets atau Mozilla SOPS sehingga hanya cluster yang bisa mendekripsi. Lengkapi dengan runtime secret injection dari secret manager, seperti HashiCorp Vault atau cloud KMS, dan jadwalkan rotasi kunci otomatis pada pipeline.
Keamanan supply chain fokus pada hal yang kamu bangun dan jalankan. Tanda tangani container image dengan cosign, jalankan vulnerability scanning (misalnya Trivy atau Grype), dan aktifkan dependency checks dalam CI. Pada cluster, terapkan RBAC dan network policy agar setiap service hanya punya izin minimum serta ruang gerak terbatas bila terjadi insiden.
Monitoring, Observability, dan Recovery Otomatis
Dalam GitOps, observability berarti memahami hal yang terjadi dalam aplikasi dan controller, seperti Argo CD atau Flux. Tiga komponen utamanya adalah metrics, logs, dan traces. Biasanya kamu mengumpulkan metrics dengan Prometheus, membuat visualisasi pada Grafana, lalu menambah distributed tracing dengan OpenTelemetry atau Jaeger.
Kombinasi ini memudahkan kamu melihat hubungan antara perubahan pada Git, status deployment, dan pengalaman pengguna.
Dashboards sebaiknya menampilkan kesehatan deployment, misalnya sync status Argo CD, reconciliation errors, dan rollback count. Dari sini, kamu membuat alerts untuk kasus seperti sync gagal berulang, error rate melonjak, atau latency melebihi batas.
Untuk recovery, banyak tim memakai progressive delivery, seperti canary dan blue/green dengan Argo Rollouts atau Flagger. Strateginya: rilis ke sebagian kecil trafik, pantau health checks dan SLI, lalu otomatis promote atau rollback.
Contoh konfigurasi automated rollback berbasis metrics pada Argo Rollouts sebagai berikut.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
spec: strategy: canary: canaryService: my-app-canary stableService: my-app-stable steps: - setWeight: 20 - pause: { duration: 300 } - setWeight: 50 - pause: { duration: 300 } analysis: templates: - templateName: error-rate-check startingStep: 1 args: - name: threshold value: "0.02" |
Analysis template biasanya mengkueri Prometheus untuk error rate atau latency, lalu menghentikan atau membatalkan rilis jika melampaui ambang batas. Untuk insiden, kamu butuh runbook yang jelas: cek status controller, bandingkan desired state pada Git dengan live state dalam kluster, tentukan waktu melakukan rollback otomatis dan waktu untuk intervensi manual.
SLO/SLI yang umum dipakai antara lain persentase successful sync, waktu rata-rata reconciliation, serta error rate selama 10–30 menit setelah setiap deployment.
Contoh Kasus Implementasi dan Langkah Praktis
Pada skenario A, kamu mulai dari repo application dan repo deklaratif terpisah. Dalam repo application, siapkan CI pipeline sederhana yang membangun container image, menjalankan unit test, lalu push ke registry. Dalam repo deklaratif, buat namespace, deployment, dan service dengan pola image: myapp:vX.Y.Z agar mudah dilacak.
Untuk Argo CD, buat Application yang menunjuk ke repo deklaratif dan path microservice terkait. Pada Flux, gunakan GitRepository dan kustomisasi yang menarik konfigurasi dari branch main. Deploy pertama dilakukan dengan sync manual, lalu jalankan smoke test sederhana, misalnya curl ke health endpoint dan cek latency dasar.
Pada skenario B, mulai dengan audit manifest lama dan Helm chart yang tersebar. Refactor menjadi struktur GitOps yang rapi, misalnya berikut.
|
1 2 3 4 5 6 |
apps/ legacy-service/ base/ overlays/ staging/ production/ |
Gunakan strategi canary atau parallel environment dengan subset trafik. Pastikan ada rollback plan jelas, misalnya tag Git previous-stable dan Argo CD rollback ke revision tersebut, lalu lakukan pengujian pasca-migrasi dengan membandingkan metrics serta error rate sebelum dan sesudah.
Ceklis pra-produksi mencakup security review manifest (misalnya runAsNonRoot, readOnlyRootFilesystem), penanganan secret via External Secrets atau sealed-secrets, serta backup untuk data dan konfigurasi Git. Observability baseline perlu minimal dashboards, alert kritis, dan log retention yang memadai.
Masalah umum biasanya berupa drift, sync error, atau image tag yang tidak ter-update. Biasakan membaca events di Argo CD/Flux, cek health per resource, dan gunakan policy yang melarang perubahan langsung dalam cluster.
Untuk adopsi tim, mulai dari satu layanan dulu, dokumentasikan runbook, lakukan training singkat, lalu perluas ke layanan lain secara bertahap agar risiko tetap terkendali.
Penutup
Dengan memahami alur kerja, alat, dan praktik terbaik yang dijabarkan, developer dapat mengurangi risiko deployment serta mempercepat delivery. Artikel ini menjanjikan panduan praktis yang dapat diikuti untuk memulai GitOps, memilih tooling, serta mengatasi tantangan keamanan dan observability dalam skenario nyata.
