Belajar Helm Chart - GitOps dengan Helm

#Pendahuluan

Setelah di episode 24 sebelumnya kita membahas bagaimana Helm diintegrasikan ke dalam pipeline CI/CD — mulai dari GitHub Actions, GitLab CI/CD, hingga Jenkins dan Tekton — pada episode kali ini kita naik satu level abstraksi: bukan sekadar otomatisasi build dan deploy di dalam satu pipeline, melainkan menjadikan Git sebagai satu-satunya sumber kebenaran (source of truth) bagi seluruh kondisi cluster kita. Konsep ini dikenal sebagai GitOps, dan Helm adalah komponen kunci di dalamnya.

Kenapa ini penting? Di episode-episode sebelumnya, proses upgrade tetap dipanggil secara manual atau lewat pipeline — manusia atau script yang memutuskan kapan helm upgrade dieksekusi. Dalam skala enterprise, cara itu rapuh: dua engineer bisa saja meng-upgrade release yang sama dengan values berbeda tanpa saling tahu, dan kondisi cluster yang menyimpang dari "rencana" sering baru terdeteksi setelah terjadi insiden. GitOps menghilangkan tebakan ini: kondisi yang diinginkan (desired state) dideklarasikan di Git, lalu sebuah controller bekerja terus-menerus merekonsiliasi cluster agar selalu sesuai dengan Git — seperti autopilot yang terus mengoreksi arah kapal agar kembali ke jalur yang sudah dipetakan, bukan pilot yang hanya menerbangkan saat lepas landas.

Di episode ini kita akan membedah prinsip-prinsip GitOps, memahami posisi Helm di dalam arsitektur GitOps, mempraktikkan dua implementasi paling populer — ArgoCD dan Flux — lalu menutup dengan praktik terbaik yang menyelamatkan tim kalian di produksi.

#Prinsip-Prinsip GitOps

GitOps bukan produk — ia adalah seperangkat prinsip operasional yang pertama kali dipopulerkan oleh Weaveworks pada 2017 sebagai jawaban atas pertanyaan "bagaimana kita menerapkan praktik engineering yang sama disiplinnya dengan Git untuk deployment?". Ada empat prinsip inti yang saling terkait.

#Git sebagai Source of Truth

Semua hal yang menentukan kondisi cluster — manifest, values, versi chart, konfigurasi, bahkan deskripsi environment — disimpan di Git. Tidak ada lagi "konfigurasi yang hanya ada di laptop Rudi". Jika sebuah objek tidak ada di Git, ia tidak seharusnya ada di cluster. Ini memberi tiga manfaat langsung: audit trail (siapa mengubah apa dan kapan), rollback instan (cukup git revert lalu biarkan controller yang menerapkan), dan reproducibility (cluster baru bisa dibangun ulang dari nol hanya dari repo — ini menjadi fondasi disaster recovery yang sangat praktis).

#Konfigurasi Deklaratif

Kita menyatakan apa yang diinginkan, bukan bagaimana mencapainya. Kalimat "saya ingin release payment-api menggunakan chart versi 4.2.1, 3 replica, image v2.1.0" adalah deklarasi; sedangkan "jalankan helm upgrade lalu tunggu sampai selesai" adalah instruksi imperatif. GitOps memakai yang pertama. Controller yang menafsirkan deklarasi — bukan kita — yang mengeksekusi langkah-langkahnya, lengkap dengan retry, rollback, dan pembuatan laporan status.

#Sinkronisasi Otomatis

Setelah desired state dideklarasikan, tidak ada tangan manusia yang perlu menjalankan perintah deploy. Controller membandingkan kondisi Git dengan kondisi cluster secara berkala (polling) atau saat ada event (webhook/push), lalu menerapkan perbedaan yang ditemukan. Praktik ini menghapus "deployment Friday" dan lonjakan kecemasan manual; perubahan disetujui di Git, dan sisanya dikerjakan mesin. Perlu diingat: otomatis tidak selalu berarti tanpa persetujuan. Sinkronisasi otomatis dengan persetujuan manual (misal tombol sync yang menunggu review) adalah variasi yang sah dan sering dipakai untuk produksi.

#Drift Detection

Bahkan dengan sinkronisasi otomatis, kondisi cluster bisa menyimpang — misalnya seseorang menjalankan kubectl scale langsung di cluster, atau Pod dihapus manual, atau service diubah lewat dashboard cloud. GitOps controller mendeteksi penyimpangan ini dan, tergantung kebijakan, mengoreksinya kembali agar sesuai Git (self-heal) atau setidaknya menandainya sebagai drift pada dashboard. Inilah yang membedakan GitOps dari CI/CD biasa: CI/CD berhenti bekerja setelah deploy selesai, GitOps tidak pernah berhenti menjaga.

#Posisi Helm dalam Arsitektur GitOps

Banyak yang salah kaprah mengira GitOps menggantikan Helm. Faktanya justru sebaliknya: Helm dan GitOps saling melengkapi. GitOps menyelesaikan masalah bagaimana desired state diterapkan dan dijaga, sementara Helm menyelesaikan masalah bagaimana aplikasi kompleks dipaketkan dan dikonfigurasi dengan nilai-nilai yang dapat diparameterkan. Tanpa Helm, repo GitOps dipenuhi puluhan manifest YAML yang berulang; tanpa GitOps, chart Helm masih bergantung pada manusia yang mengetik perintah di terminal.

#Chart Version di Git

Repo GitOps menyimpan referensi chart yang eksplisit: nama chart, repository asal, dan versi (4.2.1, bukan latest). Dengan begitu, chart mana pun yang dipakai di produksi selalu bisa ditelusuri balik ke commit Git. Ini menjawab pertanyaan audit "chart versi berapa yang berjalan di staging bulan lalu?" secara instan, dan memungkinkan perbandingan "apa yang berubah antara versi ini dan versi itu" sebelum di-deploy.

#Values di Git

File values per environment — values-dev.yaml, values-staging.yaml, values-prod.yaml — hidup di repo GitOps. Setiap perubahan konfigurasi (menaikkan replica, mengubah resource limit, mengganti image tag) adalah commit, direview lewat pull request, dan hanya masuk produksi setelah disetujui. Inilah yang mengubah "seni konfigurasi" yang rawan insiden menjadi proses yang terdokumentasi dan bisa dipertanggungjawabkan.

#Manajemen Release

Di GitOps, operasi helm install dan helm upgrade tidak lagi dipanggil manusia, melainkan oleh controller (ArgoCD/Flux) yang bertindak sebagai klien Helm atas nama kita. Release dibuat, di-upgrade, dan di-rollback berdasarkan apa yang tertulis di Git. Konsekuensi penting: jangan pernah mengelola release yang sama dari dua tempat (controller GitOps dan terminal manual) sekaligus — itu resep konflik yang menyakitkan. Pilih salah satu sumber kebenaran.

#Drift Detection dengan Helm

Helm punya mekanisme deteksi drift bawaannya: ketika menjalankan operasi, Helm membandingkan manifest yang dirender dengan apa yang ada di cluster, dan resource yang dimodifikasi di luar Helm akan diperlihatkan lewat helm get manifest vs kondisi aktual. GitOps controller melengkapi ini dengan pemeriksaan terus-menerus, sehingga drift yang timbul di antara dua operasi manual bisa langsung dikoreksi — termasuk drift yang tidak pernah disadari manusia.

#ArgoCD + Helm

ArgoCD adalah GitOps tool dari komunitas CNCF yang menerapkan pola pull-based deployment: ArgoCD (yang berjalan di dalam cluster) menarik kondisi yang diinginkan dari Git atau helm repository, bukan menunggu dorongan dari luar. Karena berjalan di dalam cluster, ArgoCD tidak memerlukan kredensial cluster di CI/CD eksternal — satu alasan mengapa ia sangat populer untuk environment dengan security requirement yang ketat.

#Konsep Application

Unit dasar ArgoCD adalah Application — sebuah CRD yang menghubungkan sumber (source: repo Git atau helm repository) dengan tujuan (destination: cluster + namespace). Saat sebuah Application didefinisikan, ArgoCD terus-menerus merekonsiliasi resource-nya: ia men-render chart, membandingkan hasilnya dengan kondisi cluster, lalu menyinkronkan perbedaan yang ada. Semua aktivitas ini tercatat dan bisa dilihat dari UI maupun argocd app get.

#Parameter Helm di ArgoCD

Untuk chart Helm, ArgoCD mendukung tiga cara melewati values, dan ketiganya bisa dikombinasikan:

• parameters — daftar pasangan name/value, setara --set image.tag=2.1.0.
• values — YAML inline yang ditulis langsung di definisi Application, setara file values yang ditulis inline.
• valueFiles — referensi file values dari repo Git, mendukung substitution $values (repo config terpisah) dan $param (nilai dari parameter).

Urutan presedensi di ArgoCD mengikuti aturan Helm: valueFiles dan values digabungkan sebagai file values, lalu parameters menimpanya — mirip hierarki --values vs --set yang sudah kita bahas di episode 6.

#Sync Behavior dan Automated Sync

ArgoCD menawarkan dua kebijakan sinkronisasi utama:

• Manual sync (default) — perubahan di Git tidak otomatis diterapkan; engineer meninjau perbedaan (diff preview) lalu menyinkronkan lewat UI/CLI.
• Automated sync — ArgoCD otomatis menerapkan perubahan dari Git, dengan opsi prune: true (hapus resource yang tidak lagi ada di Git) dan selfHeal: true (koreksi drift yang terjadi di cluster).

Berikut contoh Application lengkap yang memakai chart Helm dari repo publik, dengan values yang ditarik dari repo config terpisah:

argo-application.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-api
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: platform
  source:
    repoURL: https://github.com/company/gitops-configs
    targetRevision: main
    path: apps/payment-api
    helm:
      releaseName: payment-api
      valueFiles:
        - $values/apps/payment-api/values-prod.yaml
      parameters:
        - name: image.tag
          value: 2.1.0
        - name: ingress.enabled
          value: "true"
  destination:
    server: https://kubernetes.default.svc
    namespace: payment
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Beberapa hal yang perlu dicermati dari contoh di atas. prune: true sangat kuat tapi juga berbahaya — resource yang sengaja dihapus dari Git akan ikut dihapus dari cluster, jadi pastikan setiap penghapusan benar-benar disengaja dan melalui review. CreateNamespace=true membuat namespace tujuan otomatis jika belum ada. Perhatikan juga bahwa ingress.enabled dikirim sebagai string "true" — ini adalah pitfall klasik yang akan kita bahas di bawah.

#Flux + Helm

Flux adalah alternatif GitOps yang terbilang lebih "Helm-native". Daripada satu CRD Application yang monolitik, Flux memisahkan sumber (source) dari hasil (release) melalui dua CRD utama: HelmRepository dan HelmRelease. Pemisahan ini membuat pipeline-nya modular dan mudah diperluas.

#HelmRepository Source

HelmRepository mendefinisikan dari mana chart diambil — URL repo HTTP/HTTPS atau OCI registry — beserta interval sinkronisasinya. Flux secara berkala meng-index repo tersebut dan menyimpan snapshot-nya sebagai objek HelmChart. Dengan snapshot ini, versi chart mana pun bisa di-render ulang kapan saja tanpa menunggu repo diperbarui.

#HelmRelease CRD

HelmRelease adalah CRD yang "memutar" Helm atas nama kalian: ia mereferensikan HelmChart (chart + versi) dan HelmRepository asal, lalu menetapkan versi chart yang diinginkan, values, dan kebijakan upgrade. Flux yang menjalankan helm install/upgrade di cluster — proses ini disebut reconcile dan berjalan terus-menerus sesuai interval yang didefinisikan.

#Override Values

Values di Flux bisa berasal dari tiga sumber: inline langsung di CRD (bagian spec.values), dari ConfigMap/Secret eksternal (lewat spec.valuesFrom), atau kombinasi keduanya. Sumber eksternal ini memudahkan pemisahan konfigurasi biasa dari nilai sensitif — misalnya Secret yang dibuat dari SOPS atau external-secrets, sehingga teks rahasia tidak perlu tertulis di CRD.

#Automated Updates (Image Automation)

Fitur unik Flux adalah image automation. Lewat tiga CRD pelengkap — ImagePolicy (atur kebijakan semver/tag mana yang dianggap "terbaru"), ImageRepository (pemantau registry), dan ImageUpdateAutomation (penulis balik repo Git) — Flux bisa meng-update nilai image.tag di repo Git secara otomatis saat image baru dirilis. Ini membentuk loop GitOps yang utuh: build image → push registry → Flux menulis tag baru di Git → Flux deploy versi baru.

Berikut contoh pasangan HelmRepository + HelmRelease yang paling sering dipakai:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 10m
  url: https://charts.bitnami.com/bitnami
  type: oci

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: redis
  namespace: platform
spec:
  interval: 5m
  chart:
    spec:
      chart: redis
      version: "18.0.0"
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
  values:
    architecture: standalone
    auth:
      enabled: true
      existingSecret: redis-credentials
    master:
      resources:
        requests:
          memory: 256Mi
          cpu: 250m
  upgrade:
    remediation:
      retries: 3

Pada contoh di atas, version: "18.0.0" dipin (dikunci) — Flux tidak akan meng-upgrade chart di luar versi tersebut. values di-override langsung di CRD, dan auth.existingSecret menunjuk Secret yang dikelola terpisah (misal dari SOPS). Yang paling menarik: upgrade.remediation.retries: 3 membuat Flux mencoba kembali upgrade yang gagal hingga 3 kali; jika tetap gagal, Flux otomatis melakukan rollback ke versi terakhir yang sukses. Self-healing upgrade seperti ini adalah alasan mengapa Flux begitu diandalkan untuk workload kritis.

#Praktik Terbaik GitOps

Menjalankan ArgoCD atau Flux saja tidak membuat setup kalian otomatis matang. Berikut praktik yang membedakan setup GitOps profesional dari yang sekadar "pasang lalu jalan":

#Manajemen Values File

Pisahkan values per environment di struktur yang rapi dan gunakan pola base + overlay. Contoh struktur repo GitOps yang sehat:

gitops-configs/
├── base/
│   └── payment-api/
│       ├── chart.yaml            # referensi chart + versi
│       └── values-base.yaml      # nilai default semua env
├── overlays/
│   ├── dev/    └── payment-api/values-dev.yaml
│   ├── staging/└── payment-api/values-staging.yaml
│   └── prod/   └── payment-api/values-prod.yaml
└── apps/
    └── payment-api/
        └── application.yaml      # definisi ArgoCD Application

Struktur seperti ini membuat perbedaan antar environment terlihat jelas di satu glance, dan review PR menjadi lebih mudah karena diff-nya kecil dan terarah.

#Penanganan Secret di Git

Aturan emas: jangan pernah commit secret mentah. Dua pendekatan yang paling populer:

1. Sealed Secrets — secret dienkripsi menjadi SealedSecret di Git; hanya controller sealed-secrets di cluster yang bisa membukanya. Aman di-commit, tapi enkripsi terikat pada cluster/key tertentu — menyalin ke cluster lain membutuhkan ekspor kunci.
2. SOPS (Mozilla SOPS) — file YAML dienkripsi per-field dengan kunci yang dikelola KMS (AWS KMS, GCP KMS, Azure Key Vault, atau age). Terintegrasi rapi dengan ArgoCD (lewat plugin/--enable-eval) dan Flux (sops terhubung ke proses reconcile). Lebih fleksibel dan portable karena kuncinya terpisah dari repo.

#Version Pinning

Selalu pin versi chart eksak di Git. latest atau semver range di produksi adalah undangan kejutan: chart baru bisa merubah perilaku tanpa pernah lewat review. Kombinasikan pinning dengan PR yang ter-review sehingga kenaikan versi chart selalu tercatat sebagai perubahan yang disengaja, bukan efek samping.

#Strategi Upgrade

Gunakan automated + selfHeal hanya di environment yang bisa menoleransi otomatisasi penuh (biasanya dev/staging). Di produksi, banyak tim memilih manual sync atau automated sync dengan preSync hooks — misalnya smoke test yang harus lulus sebelum resource baru diterapkan — sehingga upgrade yang berpotensi merusak tidak langsung menyebar ke pengguna. Dan selalu mulai dari prune yang hati-hati: hapus resource dari Git hanya saat kalian benar-benar yakin.

#Penutup

Pada episode 25 ini kita telah memahami bahwa GitOps menjadikan Git sebagai source of truth tunggal dengan konfigurasi deklaratif, sinkronisasi otomatis, dan deteksi drift; bahwa Helm dan GitOps saling melengkapi — GitOps mengelola "kapan dan bagaimana diterapkan", Helm mengelola "apa yang diterapkan dan dengan nilai apa"; bahwa ArgoCD menawarkan Application terpadu dengan parameter Helm, values, valueFiles, serta automated sync dengan self-heal; dan bahwa Flux menawarkan pemisahan sumber (HelmRepository) dan hasil (HelmRelease) yang modular, dilengkapi image automation yang unik.

Inti yang harus kalian bawa:

• GitOps = Git sebagai kebenaran + controller yang merekonsiliasi cluster terhadap Git secara terus-menerus.
• Helm adalah mekanisme packaging/konfigurasi; GitOps adalah mekanisme sinkronisasi — keduanya bekerja sama, bukan bersaing.
• ArgoCD unggul dalam kesederhanaan Application terpadu; Flux unggul dalam pendekatan Helm-native dan image automation.
• Secret selalu dienkripsi (Sealed Secrets/SOPS), versi chart dipin, dan upgrade diotomatisasi lewat PR yang ter-review.

Namun GitOps tidak membuat Helm kebal terhadap kegagalan — ketika release gagal, drift tidak teratasi, atau template render error, kita butuh teknik membedah yang sistematis. Di episode 26 selanjutnya kita akan membahas troubleshooting dan debugging Helm: dari kegagalan instalasi dan upgrade, error template, release yang stuck, hingga teknik advanced seperti inspeksi secret release dan analisis event log. Pastikan tetap semangat, sampai jumpa di episode 26!