Belajar Jenkins - Continuous Deployment (CD) ke Kubernetes & Helm

#Pendahuluan

Di episode 15 kita mengirim aplikasi ke Linux server lewat SSH dan Ansible — pendekatan klasik yang tetap valid untuk mesin virtual. Sekarang saatnya naik kelas: kita deploy ke Kubernetes cluster dengan Helm, kombinasi yang dipakai hampir semua perusahaan yang berjalan di container. Kubernetes memberi rolling update, self-healing, dan environment yang seragam antar node. Helm membuat puluhan baris manifest YAML bisa di-package, di-version, dan di-release seperti aplikasi biasa — bayangkan Helm seperti apt-get untuk Kubernetes.

Di episode ini kita membahas tiga hal utama:

1. Deploy manifest ke cluster secara aman dengan step withKubeConfig dan kubectl apply.
2. Automatisasi release aplikasi dengan helm upgrade --install.
3. Integrasi GitOps dengan ArgoCD dan Flux agar cluster selalu sinkron dengan Git.

#Mengapa Kubernetes & Helm untuk CD?

Setelah build sukses dan image Docker ter-push, aplikasi masih harus dideploy. Deploy manual ke ratusan pod dengan kubectl run jelas tidak scalable. Kubernetes memberi kita:

• Rolling update — pod diganti bertahap tanpa downtime.
• Self-healing — pod yang crash otomatis diganti oleh ReplicaSet.
• Declarative state — kita cukup bilang "ingin 3 replica", Kubernetes yang mengurus sisanya.

Sedangkan Helm memecahkan masalah manifest YAML yang berulang antar environment. Satu chart bisa dipakai untuk staging dan production, hanya berbeda file values. Ini analog dengan templating, tapi khusus untuk infrastruktur.

#Menyiapkan Akses Cluster yang Aman

Akses ke cluster dikendalikan oleh file kubeconfig yang berisi server address, token, dan context. File ini adalah kunci rumah kita — jika bocor, siapa pun bisa menghancurkan cluster production. Karena itu kubeconfig tidak pernah boleh dicopy ke repository atau workspace.

Cara aman di Jenkins adalah menyimpannya sebagai credential bertipe Secret file. Di Manage Jenkins lalu Credentials, tambahkan kubeconfig dari file ~/.kube/config cluster production sebagai Secret file dengan ID kubeconfig-prod.

#Deploy dengan Step withKubeConfig

Plugin Kubernetes CLI menyediakan step withKubeConfig yang menulis kubeconfig dari credential ke file sementara, lalu menghapusnya setelah blok selesai. Kita tidak perlu repot mengekspor variabel atau menyimpan file di workspace.

Jenkinsfile - deploy manifest dengan withKubeConfig

stage('Deploy ke Kubernetes') {
    steps {
        withKubeConfig(credentialsId: 'kubeconfig-prod', serverUrl: 'https://k8s-prod.example.com') {
            sh 'kubectl apply -f k8s/ --namespace production'
        }
    }
}

Mari kita urai apa yang terjadi:

• credentialsId menunjuk ke Secret file yang kita buat tadi.
• serverUrl memberi tahu step server cluster mana yang dipakai.
• Di dalam blok, command kubectl apply otomatis membaca kubeconfig dari file sementara tersebut.

Command kubectl apply -f k8s/ menerapkan semua manifest di folder k8s/ — Deployment, Service, dan Ingress. Perintah ini bersifat idempotent, sehingga aman dijalankan berulang kali.

#Validasi Manifest Sebelum Apply

Jangan langsung apply di production tanpa validasi. Tambahkan dry-run sebagai smoke test:

kubectl apply -f k8s/ --namespace production --dry-run=client -o yaml

Langkah ini memastikan YAML valid dan schema-nya dikenali oleh Kubernetes. Baru setelah itu lakukan apply yang sesungguhnya.

#Automatisasi Release Helm Chart

Setelah manifest dasar berjalan, kita beralih ke Helm. Prinsip utamanya: helm upgrade --install bersifat idempotent — ia menginstall jika belum ada, dan meng-upgrade jika sudah ada. Satu command untuk dua kebutuhan.

helm upgrade --install my-app ./chart \
  --namespace production \
  --values values.production.yaml \
  --set image.repository=registry.example.com/my-app \
  --set image.tag=1.0.42

Flag --values memakai file konfigurasi per environment, sementara --set bisa menimpa nilai tertentu, misalnya tag image hasil build. Di Jenkins, tag bisa diambil dari environment variable BUILD_NUMBER sehingga setiap build menghasilkan release baru.

Jenkinsfile - release Helm dengan tag dinamis

stage('Release Helm Chart') {
    steps {
        sh 'helm upgrade --install my-app ./chart \
            --namespace production \
            --values values.production.yaml \
            --set image.tag=1.0.${BUILD_NUMBER}'
    }
}

Jenkins melakukan interpolasi nilai BUILD_NUMBER di command tersebut sebelum diteruskan ke shell. Untuk chart dari repositori publik, tambahkan dulu dengan helm repo add lalu install langsung dari nama chart.

#Integrasi GitOps: ArgoCD & Flux

Terakhir, kita bahas pola modern: GitOps. Idenya, repository Git menjadi satu-satunya sumber kebenaran untuk kondisi cluster. Alih-alih Jenkins mengeksekusi perintah langsung ke cluster, Jenkins cukup memperbarui repositori Git yang berisi manifest, lalu ArgoCD atau Flux yang menarik perubahan tersebut dan menyinkronkan cluster. Arsitektur ini membuat operasi cluster bisa diaudit penuh lewat commit history.

Urutan kerjanya seperti ini:

1. Pipeline Jenkins build image dan push ke registry.
2. Jenkins melakukan commit perubahan tag image ke repository gitops.
3. ArgoCD atau Flux mendeteksi perubahan di Git dan me-reconcile cluster.
4. Cluster di-update tanpa Jenkins menyentuh cluster secara langsung.

Contoh Jenkins melakukan bump tag di repository gitops:

git clone git@github.com:my-org/gitops-repo.git
cd gitops-repo
sed -i 's|imageTag: .*|imageTag: 1.0.42|' apps/my-app/values.yaml
git add apps/my-app/values.yaml
git commit -m "chore: bump my-app to 1.0.42"
git push origin main

ArgoCD maupun Flux otomatis membaca perubahan tersebut. Bila ingin memicu sinkronisasi secara langsung (tanpa menunggu interval polling), Jenkins bisa memanggil CLI-nya:

Jenkins - trigger sync ArgoCD

withCredentials([string(credentialsId: 'argocd-token', variable: 'ARGOCD_TOKEN')]) {
    sh 'argocd login argocd.example.com --auth-token=$ARGOCD_TOKEN --grpc-web'
    sh 'argocd app sync my-app --grpc-web'
}

Untuk Flux, perintah yang setara adalah flux reconcile kustomization my-app.

#ArgoCD vs Flux — Mana yang Dipilih?

Keduanya sama-sama tangguh. Pilih berdasarkan budaya tim: ArgoCD unggul di visibility, Flux lebih minimalis dan murni deklaratif.

#Penutup

Di episode ini kita telah membahas continuous deployment ke Kubernetes dan Helm:

• Step withKubeConfig memakai kubeconfig dari credential Secret file tanpa menyimpannya di workspace.
• kubectl apply -f k8s/ menerapkan manifest secara idempotent, dan bisa divalidasi dulu dengan --dry-run.
• helm upgrade --install menginstall sekaligus meng-upgrade chart dengan nilai per environment.
• GitOps dengan ArgoCD atau Flux memindahkan tanggung jawab sinkronisasi cluster ke Git, sehingga deployment bisa diaudit dan di-rollback dengan mudah.

Deployment otomatis memang hebat, tapi tanpa notifikasi tim tidak akan tahu build sukses atau gagal. Di episode 17 kita akan mengintegrasikan notifikasi production ke Slack, Microsoft Teams, Telegram, dan email HTML kustom — sehingga setiap peristiwa build langsung sampai ke orang yang tepat. Sampai jumpa!