Belajar Helm Chart - Helm Plugins

#Pendahuluan

Setelah di episode 21 sebelumnya kita membahas multi-environment management — dari organisasi file values hingga Helmfile yang mendeklarasikan seluruh release — pada episode kali ini kita memperluas kemampuan Helm itu sendiri lewat plugin. Helm 3 sengaja dirancang sebagai inti yang ramping: ia menangani install, upgrade, package, dan repo, tapi tidak menangani semuanya. Diff sebelum apply? Tidak ada di inti Helm. Enkripsi secret? Tidak ada. Unit testing template? Tidak ada. Semua ini diisi oleh ekosistem plugin.

Bayangkan Helm seperti sistem operasi smartphone: kernel-nya kecil dan stabil, tapi yang membuatnya berguna adalah aplikasi-aplikasi yang dipasang di atasnya. Plugin Helm adalah aplikasi itu — perintah tambahan yang terpasang ke CLI, dipanggil seperti helm diff, helm secrets, helm unittest, dan muncul otomatis di helm help sebagai subcommand baru.

Mengapa kalian harus peduli? Karena workflow production yang serius hampir selalu melibatkan plugin: helm-diff menyelamatkan kalian dari upgrade yang salah dengan menunjukkan perubahan sebelum diterapkan, helm-secrets menjaga nilai sensitif tetap terenkripsi di Git, dan helm-unittest menjadikan template chart sesuatu yang bisa diuji di CI tanpa cluster. Tidak menguasai plugin berarti membangun kembali semuanya secara manual — atau melakukan upgrade tanpa bisa melihat apa yang akan berubah.

Pada episode ini kita akan membedah arsitektur sistem plugin, plugin-plugin paling penting di ekosistem, cara menginstal dan mengelolanya, lalu — bagian paling menarik — cara membuat plugin kalian sendiri dengan manifest plugin.yaml, skrip executable, dan variabel environment HELM_* yang disediakan Helm.

#Pembahasan Utama

#Arsitektur Sistem Plugin

Plugin Helm adalah konsep yang sederhana: sebuah direktori dengan file manifest plugin.yaml dan satu atau lebih file executable. Saat Helm menjalankan helm <nama-plugin> <args>, ia menemukan direktori plugin, membaca plugin.yaml untuk menemukan command yang benar, lalu mengeksekusinya — meneruskan argumen dan menambahkan sejumlah variabel environment khusus.

Struktur direktori plugin di sistem:

~/.local/share/helm/plugins/
├── diff/
│   ├── plugin.yaml
│   └── scripts/
│       └── diff
├── secrets/
│   ├── plugin.yaml
│   └── scripts/
│       └── run
└── unittest/
    ├── plugin.yaml
    └── run

Lokasi direktori ini mengikuti XDG Base Directory — di Linux biasanya ~/.local/share/helm/plugins, tapi Helm menghormati variabel HELM_PLUGINS jika kalian mengubahnya. Beberapa distribusi (dan pengguna yang memakai sudo) mungkin menempatkannya di direktori root user. Untuk mengecek di mana plugin kalian berada:

helm env | grep HELM_PLUGINS
helm plugin list

Penemuan plugin (plugin discovery) terjadi saat Helm memindai direktori tersebut di setiap invokasi. Setiap subdirektori yang berisi plugin.yaml yang valid dianggap satu plugin, dan command yang didefinisikannya diregistrasikan ke CLI. Artinya, untuk "menginstal" plugin kalian tidak perlu memodifikasi Helm sama sekali — cukup letakkan direktori yang benar, dan Helm langsung mengenalinya.

#Plugin Populer yang Wajib Dikuasai

Ekosistem Helm memiliki enam plugin yang hampir selalu muncul di workflow production:

helm-diff — kemungkinan plugin paling penting. Ia menjalankan helm upgrade --dry-run dan memformat perbedaan antara manifest yang berjalan saat ini dan yang akan diterapkan, dalam format diff yang mudah dibaca. Ini adalah "jendela pengaman" sebelum setiap upgrade:

helm diff upgrade myapp ./charts/myapp \
  -f deploy/values-common.yaml \
  -f deploy/values-prod.yaml

Output-nya berbentuk seperti git diff, jadi kalian bisa melihat persis baris yang berubah, ditambah atau dihapus:

~  Deployment "myapp" changed
  # Source: myapp/templates/deployment.yaml
  23   spec:
  24     template:
  25       spec:
  26         containers:
  27           - name: myapp
+          resources:
+            requests:
+              cpu: 500m
+              memory: 512Mi
+            limits:
+              cpu: "2"
+              memory: 2Gi

helm diff upgrade myapp ./charts/myapp -f deploy/values-prod.yaml > /tmp/upgrade.diff
wc -l /tmp/upgrade.diff

Di CI/CD, helm diff sering dijadikan gate: pipeline menampilkan diff di log review, dan manusia (atau aturan otomatis) menyetujui sebelum helm upgrade benar-benar dijalankan.

helm-secrets — integrasi dengan SOPS untuk mengenkripsi file values sebelum masuk Git. Secret tetap ditulis di values.yaml, tapi dalam bentuk terenkripsi yang hanya bisa dibaca dengan kunci yang tepat (KMS, Age, PGP). Penggunaan dasarnya: helm secrets enc secrets/prod.yaml mengenkripsi, helm secrets dec mendekripsinya ke file sementara yang diabaikan Git, dan helm secrets upgrade menggabungkan prosesnya. Keuntungan: Git tetap menyimpan secret, tapi dalam bentuk yang tidak berguna tanpa kunci — menjembatani kebutuhan review dan kebutuhan keamanan.

helm-unittest — unit testing untuk template chart tanpa cluster. Ia menulis test dalam YAML dan memvalidasi output render: "Deployment harus punya 2 replicas jika nilai X", "Ingress tidak boleh dirender jika ingress.enabled: false". Ini adalah plugin yang kita singgung di episode 14 dan menjadi tulang punggung testing chart di CI.

helm-git — memungkinkan chart direferensikan langsung dari repository Git: helm install app helm-git://https://github.com/org/charts.git//path/to/chart?ref=v1.2.3. Berguna untuk tim yang belum punya chart repository formal dan ingin memakai cabang Git sebagai sumber chart.

helm-s3 — menjadikan bucket S3 (atau kompatibel, termasuk MinIO) sebagai chart repository. helm repo add myrepo s3://my-charts-bucket lalu helm s3 push untuk mengunggah chart. Solusi populer untuk repository privat di AWS.

helm-push — mengunggah chart ke ChartMuseum (repository chart yang kita bahas di episode 17) lewat API: helm push mychart-1.0.0.tgz http://chartmuseum.internal. Sebelum era OCI, ini adalah cara standar publikasi chart organisasi.

helm-s3 dan helm-push vs OCI — perlu dicatat posisi historisnya: kedua plugin ini lahir sebelum Helm mendukung OCI. Sejak OCI matang (episode 18), alur helm push ke registry container menggantikan kebutuhan keduanya untuk banyak tim — satu toolchain, satu auth, tanpa plugin. Tetap relevan di organisasi yang sudah terlanjur membangun repository HTTP/S3 internal, atau yang belum siap pindah registry. Keputusan migrasinya mengikuti logika yang sama dengan migrasi repository di episode 18.

#Mengelola Plugin: Install, List, Update, Uninstall

Semua operasi plugin menggunakan subcommand helm plugin:

helm plugin install https://github.com/databus23/helm-diff
helm plugin install https://github.com/jkroepke/helm-secrets --version v4.5.1
helm plugin list
helm plugin update diff
helm plugin uninstall diff

Beberapa detail penting. helm plugin install menerima URL Git, path lokal, atau tarball. Saat menginstal dari Git, Helm memuat file plugin.yaml dari root repo dan mengeksekusi perintah install yang didefinisikan di dalamnya (jika ada) — banyak plugin memakai ini untuk men-download binary yang sesungguhnya. --version memilih versi spesifik, penting untuk reproducible environment. Dan karena plugin adalah binary yang dieksekusi, plugin harus diinstal ulang saat berganti arsitektur atau OS — pastikan pencatatan plugin yang dibutuhkan ada di dokumentasi on-call tim kalian, atau gunakan container image CI yang sudah berisi plugin.

Satu nuansa yang jarang dibahas: plugin tidak di-cache atau diverifikasi seperti dependency chart. Tidak ada Chart.lock untuk plugin — setiap developer dan setiap CI runner yang butuh plugin harus menginstalnya sendiri. Inilah mengapa konvensi umum adalah mendokumentasikan plugin dalam file Makefile atau skrip bootstrap (misalnya target make plugins yang menjalankan serangkaian helm plugin install --version <x>), dan menyalinnya ke base image CI. Dengan begitu, perbedaan versi plugin antar environment — sumber bug klasik "berjalan di laptop, gagal di CI" — bisa diminimalkan.

#Membuat Plugin Sendiri: plugin.yaml dan Skrip Executable

Sekarang bagian yang menarik — membuat plugin kustom. Sebuah plugin terkecil hanya butuh dua file: plugin.yaml dan sebuah skrip. Manifest-nya:

name: "template-dump"
version: "0.1.0"
usage: "Render semua template dan simpan ke direktori"
description: |-
  Plugin kustom untuk me-render chart ke direktori output
  sehingga bisa direview oleh reviewer non-Helm.
command: "$HELM_PLUGIN_DIR/scripts/dump.sh"
hooks:
  install: "cd $HELM_PLUGIN_DIR && ./scripts/install.sh"
platformCommand:
  - os: linux
    command: "$HELM_PLUGIN_DIR/scripts/dump-linux.sh"
  - os: darwin
    command: "$HELM_PLUGIN_DIR/scripts/dump-macos.sh"

Mari bedah setiap field. name harus unik — inilah nama yang muncul di helm plugin list dan dipakai sebagai subcommand (helm template-dump). command adalah jalur ke executable yang dijalankan saat plugin dipanggil; perhatikan penggunaan variabel $HELM_PLUGIN_DIR — variabel environment yang disuntikkan Helm agar plugin tahu di mana dirinya sendiri, sehingga plugin bisa dipindahkan tanpa mematahkan path. hooks.install (dan update) adalah perintah yang dieksekusi saat helm plugin install — tempat yang tepat untuk men-download binary, mengompilasi, atau mengatur izin. platformCommand memungkinkan command berbeda per sistem operasi — penting untuk plugin yang dikompilasi per-platform.

Skrip plugin yang paling sederhana — memanfaatkan variabel environment yang disediakan Helm:

#!/usr/bin/env bash
set -euo pipefail
 
RELEASE="${1:?Usage: helm template-dump <release>}"
CHART="${2:?Usage: helm template-dump <release> <chart>}"
OUTPUT="${3:-./rendered}"
 
mkdir -p "$OUTPUT"
 
"$HELM_BIN" template "$RELEASE" "$CHART" \
  --namespace "$HELM_NAMESPACE" \
  -f "${HELM_VALUES_FILE:-values.yaml}" \
  > "$OUTPUT/$RELEASE.yaml"
 
echo "Templates dumped to $OUTPUT/$RELEASE.yaml (namespace: $HELM_NAMESPACE)"

Skrip ini menunjukkan variabel environment HELM_* yang paling berguna. $HELM_BIN berisi path ke binary Helm yang menjalankan plugin — selalu gunakan ini untuk memanggil Helm di dalam plugin, jangan hardcode helm, supaya plugin tetap bekerja jika Helm dijalankan dari path non-standar. $HELM_NAMESPACE berisi namespace yang sedang dipakai (dari --namespace atau HELM_NAMESPACE environment). Ada juga $HELM_KUBECONTEXT, $HELM_REGISTRY_CONFIG, $HELM_REPOSITORY_CONFIG, $HELM_PLUGIN_DIR, dan $HELM_DEBUG — daftar lengkapnya ada di helm env.

Setelah file siap, beri izin executable dan uji:

chmod +x scripts/dump.sh
helm plugin install .
helm template-dump myapp ./charts/myapp ./out
helm plugin list

#Praktik Terbaik Menulis Plugin

Menulis plugin yang baik membutuhkan lebih dari sekadar skrip yang berfungsi. Berikut standar yang harus dipenuhi agar plugin kalian bisa dipakai oleh orang lain (atau oleh diri kalian sendiri enam bulan kemudian):

1. Version compatibility. Tulis komentar eksplisit di plugin.yaml tentang versi Helm minimum yang didukung (minimumHelmVersion bukan field standar, tapi dokumentasikan di description) dan versi Kubernetes yang ditargetkan. Plugin yang memakai flag baru di Helm 3.12 akan gagal misterius di Helm 3.10.
2. Error handling. Setiap skrip harus set -euo pipefail — stop pada error, tolak variabel tak ter-set, dan gagal jika ada command di pipeline yang error. Output error harus menjelaskan ke pengguna apa yang salah dan cara memperbaikinya, bukan sekadar "command not found".
3. Dokumentasi. usage dan description di plugin.yaml harus mengikuti format yang membantu: usage singkat dengan argumen, description menjelaskan mengapa plugin ini ada. README dengan contoh pemakaian adalah keharusan untuk distribusi.
4. Distribusi. Publikasikan plugin sebagai repository Git (dengan versi via tag), atau sebagai tarball di release page. Praktik umum: repo dengan plugin.yaml di root dan script install.sh di hooks.install yang men-download binary dari GitHub Releases sesuai arsitektur — pola yang dipakai helm-diff, helm-secrets, dan hampir semua plugin besar.

#Penutup

Pada episode 22 ini kita telah membedah sistem plugin Helm: arsitektur yang berbasis direktori sederhana dengan manifest plugin.yaml dan executable, enam plugin populer yang wajib dikuasai (helm-diff untuk diff sebelum apply, helm-secrets untuk enkripsi SOPS, helm-unittest untuk testing, helm-git, helm-s3, dan helm-push), pengelolaan plugin dengan helm plugin install/list/update/uninstall, serta cara membuat plugin kustom — manifest, skrip, variabel environment HELM_BIN dan HELM_NAMESPACE, hingga praktik terbaik distribusi.

Inti yang harus kalian bawa:

• Plugin memperluas Helm tanpa mengubah intinya — inti tetap ramping, ekosistem yang tumbuh.
• helm diff sebelum setiap upgrade adalah disiplin yang menyelamatkan produksi.
• $HELM_BIN dan $HELM_PLUGIN_DIR adalah jembatan antara plugin dan Helm — selalu pakai keduanya.
• platformCommand untuk multi-OS, hooks.install untuk setup, set -euo pipefail untuk keandalan.

Di episode 23 selanjutnya kita akan membahas Helm SDK & penggunaan programatik: bukan lagi memanggil Helm sebagai CLI, melainkan mengimpor Helm sebagai library Go di dalam aplikasi kalian sendiri — dasar dari operator, platform engineering tools, dan self-service portal. Sampai jumpa di episode 23!