Manajemen source tingkat lanjut: referensi GitRepository, optimasi repo besar, HelmRepository dan OCIRepository, Bucket untuk S3, GCS, dan Azure, serta verifikasi signature GPG dan Cosign.

Di episode 8 kalian sudah mereferensikan chart Helm sebagai source. Episode ini membuka seluruh tipe source yang didukung Flux dan fitur tingkat lanjutnya. Ini penting karena source adalah jantung GitOps: apa pun yang masuk ke cluster pasti lewat Source Controller.
Kita akan bedah GitRepository lanjutan, HelmRepository, OCIRepository, Bucket, lalu cara memverifikasi keaslian source dengan GPG dan Cosign.
Selain branch, ref bisa menunjuk tag, commit, atau semver:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: webapp
namespace: flux-system
spec:
interval: 5m
ref:
tag: v1.2.0
# atau commit:
# ref:
# commit: 3f4a8c9d21e0b4a1
# atau semver:
# ref:
# semver: ">=1.0.0 <2.0.0"
url: https://github.com/arman/webapp-manifests.gittag — menunjuk versi rilis tertentu; stabil untuk production.commit — pin ke hash commit; yang paling deterministik.semver — Flux memilih tag tertinggi yang cocok dengan range, lalu otomatis naik saat tag baru muncul.Repo besar bisa dirampingkan dengan dua cara. Pertama, aktifkan submodule:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: fleet
namespace: flux-system
spec:
interval: 5m
url: https://github.com/arman/fleet.git
ref:
branch: main
gitImplementation: go-git
recurseSubmodules: trueKedua, batasi file yang disalin lewat include dan exclude (pola gitignore). Ini mengurangi beban clone dan mempercepat rekonsiliasi untuk repo yang sangat besar:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: fleet
namespace: flux-system
spec:
interval: 5m
url: https://github.com/arman/fleet.git
ref:
branch: main
ignore: |
.github
docs/
**/*.mdTip
Optimasi lanjutan: gunakan flag --depth=1 saat bootstrap untuk shallow clone, dan untuk repo raksasa pertimbangkan OCIRepository yang memakai artifact yang lebih ringan — dibahas sebentar lagi.
Untuk memastikan commit benar-benar dari penulis sah, aktifkan verifikasi GPG:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: webapp
namespace: flux-system
spec:
interval: 5m
url: https://github.com/arman/webapp-manifests.git
ref:
branch: main
verify:
mode: head
secretRef:
name: gpg-public-keysHelmRepository pada dasarnya dua hal: direktori yang berisi index.yaml, atau OCI registry. Untuk repo HTTP biasa, Flux mengunduh index.yaml lalu mengambil chart yang dibutuhkan.
Autentikasi mirip dengan GitRepository — lewat Secret basic auth atau token:
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
name: internal
namespace: flux-system
spec:
interval: 1h
url: https://helm.internal.acme.com/charts
secretRef:
name: helm-auth
timeout: 60s
passCredentials: truepassCredentials — mengirim kredensial ke semua request, bukan hanya host utama. Berguna saat chart di-host di object storage yang memerlukan auth per request.certSecretRef — memasang custom CA untuk TLS.insecure: true — mematikan verifikasi TLS, hanya untuk lab.Warning
Jangan aktifkan insecure di production. Jika memakai registry internal dengan sertifikat self-signed, buat Secret berisi CA dan referensikan lewat certSecretRef.
OCIRepository adalah source generik untuk OCI artifact: chart, image, atau manifest yang dikemas sebagai layer OCI. Ia lebih ringan daripada clone Git dan sangat cocok untuk repo besar atau distribusi chart ke banyak cluster.
apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
name: webapp-chart
namespace: flux-system
spec:
interval: 10m
url: oci://registry.internal.acme.com/charts/webapp
ref:
tag: 1.2.0
secretRef:
name: registry-auth
layerSelector:
mediaType: application/vnd.cncf.helm.chart.content.v1.tar+gzipAutentikasi memakai Secret tipe dockerconfigjson:
flux create secret oci registry-auth \
--url=oci://registry.internal.acme.com/charts \
--username=arman \
--password=$REGISTRY_PASSWORDUse case paling umum: menyebarkan manifest ke banyak cluster tanpa kloning Git, dan mendistribusikan chart internal yang sudah di-scan dan disetujui security team.
Untuk artefak statis (S3-compatible, GCS, Azure Blob), Flux punya Bucket. Source ini mengunduh file dari object storage secara berkala:
apiVersion: source.toolkit.fluxcd.io/v1
kind: Bucket
metadata:
name: manifests
namespace: flux-system
spec:
interval: 10m
provider: generic
bucketName: my-app-manifests
endpoint: https://s3.ap-southeast-1.amazonaws.com
region: ap-southeast-1
secretRef:
name: s3-credentialsGCS dan Azure tinggal mengganti provider:
| Provider | Nilai provider |
|---|---|
| S3 / S3-compatible | generic (atau aws untuk IAM) |
| Google Cloud Storage | gcp |
| Azure Blob | azure |
Bucket berguna saat manifest dihasilkan pipeline CI (misal output build) dan diunggah ke storage, sehingga cluster tidak perlu akses ke Git.
Note
Kredensial bucket selalu lewat Secret: accesskey dan secretkey untuk S3, serviceaccount untuk GCP, accountkey untuk Azure. Flux membaca key tersebut sesuai provider.
Selain GPG di Git, Flux memverifikasi artifact OCI dengan Cosign. Buat OCIRepository dengan blok verify:
apiVersion: source.toolkit.fluxcd.io/v1
kind: OCIRepository
metadata:
name: webapp
namespace: flux-system
spec:
interval: 10m
url: oci://registry.internal.acme.com/apps/webapp
verify:
provider: cosign
secretRef:
name: cosign-public-keysKunci publik untuk GPG dan Cosign disimpan dalam Secret di flux-system; Source Controller juga memakai Key Management Service (misal AWS KMS atau Azure Key Vault) untuk kunci yang dikelola cloud. Ada dua mode perilaku:
failOnVerificationFailure: true — wajib verifikasi, artifact tanpa tanda tangan ditolak.ignoreNotVerified — hanya verifikasi, tidak menolak artifact tanpa tanda tangan.Important
Source verification adalah pertahanan terakhir sebelum manifest menyentuh cluster. Kombinasikan dengan commit yang di-sign dan policy engine di episode lanjutan untuk supply chain yang kuat.
Semua jalur masuk konfigurasi kini terbuka:
passCredentials.Source sudah beragam. Di episode 10 kita akan mengatur orkestrasi: dependsOn, health checks, strategi urutan deploy, dan skenario kompleks seperti database sebelum aplikasi. Sampai jumpa!