Belajar Multigress - CI/CD for Multigress Configuration

#Pendahuluan

Perubahan routing yang dilakukan manual adalah sumber utama insiden produksi. Episode 19 membahas CI/CD untuk konfigurasi Multigress: memvalidasi manifest Gateway API di pipeline, men-deploy serta me-rollback secara otomatis, dan mengelola rilis untuk perubahan routing.

Konteks dari episode 11 kita perluas: bukan hanya menyimpan manifest di Git, tetapi mengeksekusinya lewat pipeline yang teruji.

#Validasi Manifest Gateway API di CI

#Validasi Skema dengan kubeconform

Pipeline harus menolak konfigurasi yang salah sejak awal. kubeconform memvalidasi manifest terhadap skema Kubernetes dan CRD yang tersedia.

kubeconform -strict -summary \
  -kubernetes-version 1.30 \
  gateway.yaml httproutes.yaml

Perintah kubeconform -strict -summary menandai manifest yang tidak sesuai skema. Jalankan ini di setiap commit agar kesalahan YAML dan field typo tertangkap sebelum sampai ke cluster.

#Dry-Run ke Cluster

Skema valid tidak berarti objeknya diterima cluster. Gunakan dry-run server untuk memeriksa apakah resource bisa dibuat di cluster asli.

kubectl apply --dry-run=server -f config/ -o name
kubectl apply --dry-run=client -f config/ -o name

kubectl apply --dry-run=server menguji terhadap API server tanpa menulis perubahan. Ini menangkap masalah seperti namespace yang belum ada atau field yang ditolak oleh admission webhook.

#Deployment Otomatis dan Rollback

#Pipeline di CI

Setelah validasi lulus, perubahan bisa di-deploy otomatis. Contoh pipeline sederhana di bawah menjalankan validasi lalu menerapkan manifest.

name: validate-and-deploy
on:
  push:
    branches:
      - main
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validasi skema
        run: kubeconform -strict -summary ./gateway/
  deploy:
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - uses: actions/checkout@v4
      - uses: azure/k8s-set-context@v4
        with:
          kubeconfig: ${{ secrets.KUBECONFIG }}
      - run: kubectl apply -f gateway/

Job deploy hanya berjalan jika job validate sukses, sehingga manifest yang rusak tidak akan pernah sampai ke produksi.

#Rollback Otomatis dan Manual

Rollback harus cepat dan terukur. Untuk deployment berbasis Helm, riwayat versi chart menyediakan jalur mundur yang jelas.

helm list -n multigress-system
helm rollback multigress 2 -n multigress-system

Perintah helm rollback multigress 2 mengembalikan release ke revisi kedua. Kunci rollback yang baik adalah konfigurasi lama yang selalu bisa di-rebuild — bukan bergantung pada ingatan manusia.

Rollback juga bisa dipicu otomatis: jika error rate melonjak beberapa menit setelah deploy, pipeline membalik ke revisi sebelumnya tanpa menunggu manusia.

#Release Management untuk Perubahan Routing

#Versioning dan Changelog

Konfigurasi gateway adalah artefak rilis. Beri nomor versi pada setiap perubahan routing dan catat di changelog, sehingga setiap perilaku gateway bisa dikaitkan ke versi tertentu.

Semantic versioning juga berlaku di sini: perubahan perilaku routing yang bisa memutus pengguna adalah breaking change dan layak mendapat versi mayor, sedangkan penambahan route tanpa mengubah perilaku lama cukup versi minor. Dengan kata lain, perilaku rilis konfigurasi gateway dirawat seketat rilis kode aplikasi.

#Approval untuk Perubahan Sensitif

Tidak semua perubahan sama risikonya. Tambahkan gerbang review manual untuk perubahan berdampak besar seperti pemindahan traffic atau perubahan TLS, sambil membiarkan perubahan kecil mengalir otomatis. Mulai dari perubahan yang memindahkan traffic dalam jumlah besar atau menyentuh sertifikat, lalu perluas daftarnya seiring pengalaman tim.

#Penutup

Episode 19 menjadikan konfigurasi gateway sebagai artefak yang dikelola seperti kode: divalidasi di CI, di-deploy otomatis, bisa di-rollback, dan dirilis dengan versi serta review.

Inti yang harus dibawa pulang:

• kubeconform menolak manifest yang tidak sesuai skema sejak commit.
• Dry-run server memverifikasi terhadap cluster asli tanpa menulis.
• Deployment otomatis hanya berjalan setelah validasi lulus.
• Helm rollback menyediakan jalur mundur yang cepat.
• Setiap perubahan routing diberi versi dan changelog.
• Perubahan sensitif melewati gerbang review manual.

Di episode 20 selanjutnya kita akan membahas observability at scale — memantau performa route dan latensi, melacak trace melalui ingress dan backend, serta membangun dashboard untuk SLI traffic. Pipeline yang kalian bangun akan dipantau dengan metrik yang lebih dalam.