Belajar Helm Chart - Dukungan OCI Registry

#Pendahuluan

Setelah di episode 17 sebelumnya kita membangun chart repository klasik — struktur index.yaml, repository HTTP statis, otomasi GitHub Pages dengan chart-releaser-action, hingga ChartMuseum — pada episode kali ini kita membahas pergeseran yang mengubah lanskap distribusi chart: dukungan OCI registry di Helm 3.8+.

Mengapa ini penting? Selama ini chart dan image kontainer hidup di dunia yang berbeda: image tinggal di registry (Docker Hub, GHCR, ECR), sementara chart tinggal di repository HTTP dengan index.yaml sendiri. Dua infrastruktur, dua cara autentikasi, dua tempat yang harus dijaga. OCI mengubahnya: chart disimpan sebagai artefak OCI di registry yang sama dengan image — satu tempat, satu mekanisme auth, satu toolchain. Ini bukan sekadar kenyamanan; ini menghapus satu kategori infrastruktur yang harus dioperasikan dan diamankan.

Seperti semua pergeseran platform, adopsi OCI punya harga: tidak ada index.yaml yang bisa di-search seperti repository klasik, dan tooling pendukung harus ikut pindah. Di episode ini kita bedah secara jujur: mengapa OCI menang, bagaimana operasinya sehari-hari, registry apa saja yang tersedia, praktik terbaik yang menjaga produksi tetap aman, dan kapan serta bagaimana kalian harus bermigrasi.

#Pembahasan Utama

#Mengapa OCI — Repository Baru bagi Helm

OCI (Open Container Initiative) adalah standar untuk mendistribusikan artefak kontainer — bukan hanya image, tapi segala jenis artefak yang dibungkus dalam format yang sama, lengkap dengan mekanisme content-addressing dan manifest. Sejak Helm 3.8, chart bisa disimpan sebagai artefak OCI, membuat Docker registry biasa menjadi chart repository. Perbedaan mental yang harus kalian pahami:

• Repository HTTP menyimpan chart sebagai file yang didaftar dalam index.yaml; versi dipilih client dengan menarik index lalu mengunduh .tgz.
• OCI menyimpan chart sebagai artefak yang di-addressing oleh konten dan tag; versi adalah tag pada manifest, dan keaslian bisa diverifikasi lewat digest.

Keuntungan yang membuat OCI menarik:

• Satu auth untuk semua. Credential Docker registry yang sudah kalian kelola (kubelet pull secret, CI login) langsung berlaku untuk chart. Tidak ada lagi kredensial terpisah untuk repository HTTP.
• Penandatanganan terintegrasi. Registry OCI adalah target alami untuk penandatanganan dan verifikasi dengan Cosign — yang bisa menandatangani manifest chart dan image dalam satu ekosistem.
• Tanpa index.yaml. Tidak ada lagi ritual "generate index" yang bisa terlupa. Push chart = chart langsung tersedia; tidak ada katalog yang bisa basi.
• Mutability & rollback lebih jelas. Setiap versi chart adalah tag dengan digest immutable; menarik versi tertentu selalu menghasilkan artefak yang persis sama.

Yang hilang harus dikatakan dengan jujur: tidak ada helm search repo untuk OCI. Karena tidak ada index, pencarian chart beralih ke fitur listing dari masing-masing registry (misalnya UI GHCR atau API registry), bukan ke perintah Helm. Bagi tim yang terbiasa helm search, ini kurva adaptasi tersendiri.

#Operasi OCI — push, pull, dan Autentikasi

Alur kerja OCI dimulai dari autentikasi. helm registry login menyimpan kredensial di helper yang sama dengan Docker, sehingga login untuk push chart dan login untuk pull image adalah satu kesatuan:

helm registry login ghcr.io --username arman \
  --password-stdin

Lalu push chart yang sudah di-package (episode 16) ke registry. Perhatikan skema URL-nya — prefix oci:// memberi tahu Helm bahwa ini referensi OCI, bukan repository HTTP:

helm package ./myapp
# myapp-2.0.0.tgz
 
helm push myapp-2.0.0.tgz oci://ghcr.io/myorg/charts

helm pull oci://ghcr.io/myorg/charts/myapp --version 2.0.0
 
helm install myapp oci://ghcr.io/myorg/charts/myapp \
  --version 2.0.0 --namespace myapp --create-namespace

Perhatikan bagian ghcr.io/myorg/charts — inilah repository container tempat chart ditinggal, dan myapp adalah nama chart (ditentukan dari Chart.yaml, bukan dari path). Konvensi umum adalah memisahkan namespace atau prefix: myorg/charts untuk chart, myorg/apps untuk image, sehingga satu registry bisa menampung keduanya dengan jelas.

Untuk memeriksa apa yang sudah pernah ditarik atau mengunduh ulang versi tertentu, helm pull dengan --untar akan mengekstrak chart:

helm pull oci://ghcr.io/myorg/charts/myapp --version 2.0.0 --untar
ls myapp/

Satu catatan teknis: saat pull, Helm memvalidasi digest terhadap manifest registry. Jika kalian sudah men-set OCI experimental di versi lama — sebenarnya sejak 3.8 OCI sudah stable dan tidak perlu HELM_EXPERIMENTAL_OCI=1 lagi. Sama seperti helm repo update di dunia klasik, credential yang tersimpan membantu operasi tanpa login ulang setiap kali.

#Anatomi Chart OCI — Apa yang Sebenarnya Disimpan

Saat chart di-push ke registry, ia tidak disimpan sebagai satu file utuh. Registry memecahnya menjadi beberapa layer (seperti image kontainer), dan manifest mereferensikannya. Ini membawa satu keuntungan besar yang kurang disadari: deduplikasi. Jika chart kalian memuat dependency yang sama (misalnya common library dari episode 19) di banyak chart, layer yang identik cukup disimpan satu kali di registry — menghemat penyimpanan sekaligus mempercepat pull di network yang terbatas.

helm show chart oci://ghcr.io/myorg/charts/myapp --version 2.0.0
# apiVersion: v2
# name: myapp
# version: 2.0.0
 
# Melihat digest manifest untuk pin yang immutable
helm pull oci://ghcr.io/myorg/charts/myapp --version 2.0.0 \
  --untar --verify

Dua hal yang berbeda dengan repository HTTP yang harus diingat:

1. Digest vs tag. Tag (2.0.0) adalah label yang bisa dipindahkan; digest (sha256:...) adalah identitas immutable dari isi manifest. Untuk release yang diaudit ketat, pin install ke digest: helm install myapp oci://ghcr.io/myorg/charts/myapp@sha256:.... Tag memudahkan manusia, digest memastikan determinisme.
2. Cache lokal. Chart yang pernah di-pull disimpan di cache Helm ($HELM_CACHE_HOME). Sebelum menarik ulang, Helm memeriksa apakah layer yang dibutuhkan sudah ada — inilah mengapa install berulang dari OCI terasa lebih cepat setelah pull pertama.

Memahami penyimpanan berlapis ini membantu saat kalian memecahkan masalah yang aneh-aneh: ukuran "chart kecil" yang tiba-tiba besar biasanya berasal dari dependency yang ter-embed penuh di dalam layer — topik yang akan kita kendalikan di episode 19 dengan library charts.

#Memilih Registry — Dari GHCR hingga AWS ECR

Karena chart OCI adalah artefak kontainer biasa, hampir semua registry modern mendukungnya. Pilihannya mengikuti jawaban atas satu pertanyaan: di mana image kalian sudah tinggal? Kecenderungan yang benar adalah menyatukan chart dengan image di registry yang sama.

Pola yang hampir selalu benar di perusahaan: chart tinggal di registry yang sama dengan image aplikasi. Ini menyederhanakan banyak hal sekaligus — satu sumber kredensial, satu dashboard, satu kebijakan akses. Contoh untuk AWS ECR, di mana auth memakai aws CLI:

aws ecr get-login-password --region ap-southeast-1 \
  | helm registry login --username AWS --password-stdin \
    <account-id>.dkr.ecr.ap-southeast-1.amazonaws.com
 
helm push myapp-2.0.0.tgz \
  oci://<account-id>.dkr.ecr.ap-southeast-1.amazonaws.com/charts

#Praktik Terbaik — Tagging, Signing, dan Access Control

OCI menghadirkan kembali semua isu keamanan distribusi — dan memberinya alat yang lebih baik. Tiga praktik yang wajib diadopsi:

Pertama, strategi tagging yang deterministik. Di OCI, versi chart menjadi tag pada manifest. Ikuti semver yang sudah kita bangun di episode 16: tag 2.0.0 untuk rilis, dan hindari tag bergerak seperti latest untuk chart produksi — tag bergerak membuat rollback tidak memiliki target yang pasti. Untuk audit yang kuat, catat juga digest manifest (helm show chart oci://... atau helm pull lalu helm show chart), karena digest adalah satu-satunya identitas yang benar-benar immutable.

Kedua, signing & verification dengan Cosign. Inilah keunggulan OCI yang paling nyata dibanding repository HTTP: chart bisa ditandatangani dengan Cosign (dari proyek sigstore) — tool yang sama yang menandatangani image. Verifikasi menjadi bagian dari alur:

# Signing
cosign sign ghcr.io/myorg/charts/myapp@sha256:1f7a4b3c...
 
# Verification sebelum install
cosign verify \
  --key cosign.pub \
  ghcr.io/myorg/charts/myapp@sha256:1f7a4b3c...

Cosign bahkan mendukung keyless signing — verifikasi identitas lewat OIDC tanpa mengelola kunci privat, dan bundle bukti tersimpan di transparency log. Ini menghilangkan masalah "trust establishment" yang kita bahas di episode 16: siapa pun yang menjalankan cosign verify pada artefak yang ditandatangani keyless bisa memeriksa bahwa identitas penandatangan diverifikasi oleh identitas yang bisa diaudit.

Ketiga, access control yang ketat. Karena chart kini hidup di registry, kebijakan akses diatur di sana: RBAC GitHub untuk GHCR, IAM untuk ECR, IAM untuk Artifact Registry. Prinsipnya: push chart memerlukan hak tulis yang lebih terbatas daripada push image produksi, dan pull boleh diberikan ke cluster atau CI yang butuh. Satu poin penting yang sering terlupa: chart bisa mengandung Secret (episode 20 akan membahas ini). Registry privat dengan akses terkontrol adalah alasan terkuat untuk tidak pernah mem-push chart internal ke registry publik.

#Migrasi dari HTTP Repository

Migrasi tidak harus dilakukan sekaligus — kenyataannya, hybrid justru sering menjadi strategi paling realistis. OCI dan repository HTTP bisa hidup berdampingan di mesin yang sama; helm install cukup diberi referensi yang berbeda.

Pertimbangan sebelum migrasi:

• Audit tooling. Pastikan seluruh alur yang memakai repository kalian mendukung OCI: GitHub Actions, ArgoCD (mendukung OCI sejak versi 2.6), Flux (via HelmRepository type oci), dan internal tooling.
• Pertahankan kompatibilitas. chart-releaser-action yang kita bahas di episode 17 bisa diarahkan untuk push ke GHCR alih-alih gh-pages; beberapa tim bahkan menjalankan keduanya selama masa transisi — HTTP untuk konsumen lama, OCI untuk yang baru.
• Migrasi data. Pull seluruh chart dari repository lama (helm pull <repo>/<chart> --version X), lalu push ke registry dengan tag yang sama. Karena semver chart dipertahankan, konstrain versi pengguna tidak berubah — hanya URL sumbernya.
• Komunikasikan perubahan alamat. Pindah sumber chart berarti semua konsumen harus memperbarui referensi — dari repo add + nama chart menjadi oci:// penuh. Dokumentasikan ini sejelas dokumen migrasi yang kita bahas di episode 15.

Arah industri jelas: OCI adalah masa depan distribusi chart. Project seperti cert-manager, Kubernetes dashboard, dan banyak chart publik telah menerbitkan artefak OCI, dan GitOps tools modern menjadikannya jalur utama. Memahami keduanya — dan tahu kapan pindah — adalah keterampilan platform engineer yang utuh.

#Penutup

Pada episode 18 ini kita telah membedah dukungan OCI di Helm 3.8+ secara menyeluruh. Kita memahami bahwa OCI mengubah chart menjadi artefak kontainer biasa — satu auth, satu toolchain, tanpa index.yaml, dengan penandatanganan yang terintegrasi — sambil jujur bahwa pencarian chart harus beralih ke fitur listing registry. Kita menjalankan alur lengkap helm registry login → helm push → helm pull → helm install dengan skema URL oci://, membandingkan pilihan registry dari GHCR, Docker Hub, GitLab, ECR, Artifact Registry, hingga ACR, dan mengadopsi praktik terbaik: tagging deterministik berbasis semver, signing keyless dengan Cosign, serta access control yang ketat karena chart bisa membawa Secret. Terakhir, kita menyusun strategi migrasi bertahap yang menjaga kompatibilitas selama transisi.

Inti yang harus kalian bawa:

• OCI menghilangkan index.yaml dan menyatukan auth — tapi juga menghilangkan helm search repo.
• helm push/helm pull/helm install bekerja langsung pada referensi oci:// sejak Helm 3.8.
• Simpan chart di registry yang sama dengan image untuk satu sumber kredensial dan kebijakan.
• Cosign memberi signing keyless yang memecahkan masalah trust establishment di OCI.
• Migrasi bertahap: jalankan HTTP dan OCI berdampingan sampai semua konsumen pindah.

Sekarang chart kalian punya rumah modern yang aman dan teraudit. Di episode 19 selanjutnya kita masuk ke pola desain yang mengubah cara tim membangun chart berskala besar: library charts — chart yang tidak bisa di-install, tapi menjadi gudang template bersama yang di-include oleh chart-chart lain, membawa standardisasi label, helper, dan security context ke seluruh portofolio aplikasi. Pastikan tetap semangat!