Belajar Envoy Proxy - GitOps, CI/CD & Configuration Management

#Pendahuluan

Config Envoy adalah kode — dan kode harus dikelola seperti kode. Episode 20 membahas GitOps, CI/CD, dan configuration management: menyimpan config Envoy di Git sebagai single source of truth, memvalidasi config secara otomatis di pipeline, serta menggulirkan perubahan dengan aman.

Banyak insiden production disebabkan perubahan config yang tidak teruji. Dengan alur yang kalian pelajari di episode ini, setiap perubahan config melewati review, validasi, dan deploy yang terkontrol — persis seperti perubahan kode.

#Mengelola Config Envoy dalam GitOps

#Config sebagai Kode

Prinsip GitOps sederhana: semua config Envoy disimpan di repository Git, di-deploy oleh tool otomatis, dan status aktual selalu ditarik menuju status yang diinginkan. Tidak ada ssh ke server untuk mengedit config.

Struktur repository yang disarankan:

envoy-configs/
  base/
    bootstrap.yaml
  overlays/
    staging/
      bootstrap.yaml
    production/
      bootstrap.yaml
  clusters/
    orders-service.yaml
  README.md

Direktori overlays/ memisahkan perbedaan config antar environment. Tools seperti Kustomize atau Helm memudahkan pola ini, dan Argo CD atau Flux menjaga cluster tetap sinkron dengan repository.

#Perbedaan Antar Environment

Biasanya hanya ada sedikit perbedaan antar environment: alamat control plane, level logging, dan sumber sertifikat. Pisahkan bagian yang berubah dari bagian yang sama — bukan menyalin seluruh config.

#Validasi Config di CI/CD

#Perintah Validasi Envoy

Envoy memiliki mode validasi bawaan yang sempurna untuk pipeline:

envoy --mode validate -c envoy.yaml
docker run --rm -v $(pwd):/etc/envoy \
  envoyproxy/envoy:v1.31.0 envoy --mode validate -c /etc/envoy/envoy.yaml

Perintah envoy --mode validate -c envoy.yaml memeriksa seluruh config tanpa menjalankan proxy. Validasi ini membaca YAML, memverifikasi semua tipe dan nama filter, dan memeriksa referensi antar resource. Output OK berarti config siap di-deploy.

#Validasi di GitHub Actions

Masukkan validasi ke pipeline sebagai langkah wajib:

name: validate-envoy-config
on:
  pull_request:
    paths:
      - "configs/**"
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validate Envoy config
        run: |
          for f in configs/*.yaml; do
            docker run --rm \
              -v "$PWD":/etc/envoy \
              envoyproxy/envoy:v1.31.0 \
              envoy --mode validate -c "/etc/envoy/$f"
          done

Workflow validate-envoy-config menjalankan validasi pada setiap pull request yang menyentuh direktori configs. Jika ada config rusak, PR tidak bisa di-merge — kesalahan tertangkap sebelum sampai production.

#Menguji Config dengan Runner Nyata

Validasi tidak cukup untuk config yang sudah benar secara sintaks tapi salah logika (misalnya route ke cluster yang tidak ada). Untuk pengujian yang lebih dalam:

• Jalankan Envoy dengan config tersebut di CI dan kirim request uji.
• Bandingkan perilaku dengan config sebelumnya.
• Gunakan integrasi test yang mensimulasikan traffic nyata.

#Rolling Updates dan Manajemen Perubahan

#Strategi Pengguliran Config

Perubahan config harus digulirkan, bukan langsung mengganti semua instance sekaligus. Pola yang umum:

1. Terapkan ke satu instance staging.
2. Validasi dan jalankan smoke test.
3. Gulirkan ke subset production.
4. Pantau metric dan access log.
5. Lengkapi seluruh fleet.

#Rolling Update Kubernetes dengan ConfigMap

Di Kubernetes, perubahan config biasanya lewat ConfigMap:

kubectl apply -f configs/production/orders-envoy.yaml
kubectl rollout status deployment/orders -n prod

Perintah kubectl apply mengubah ConfigMap, dan deployment yang di-restart memuat config baru. Untuk rollout yang lebih aman, kombinasikan dengan health check Envoy yang sudah disiapkan di episode 7 — pod yang gagal readiness tidak menerima traffic.

#Feature Flags dan Rollback

Cara tercepat menangani config yang bermasalah adalah rollback:

git revert HEAD
kubectl rollout undo deployment/orders -n prod

Perintah git revert HEAD mengembalikan config di repo, dan kubectl rollout undo mengembalikan pod ke versi sebelumnya. Kecepatan rollback inilah nilai utama GitOps: setiap perubahan bisa dilacak dan dibatalkan dengan presisi.

#Audit Trail Perubahan

Karena semua perubahan lewat Git, setiap config punya riwayat: siapa mengubah apa, kapan, dan review mana yang menyetujui. Ini bukan sekadar compliance — audit trail adalah tool debugging pertama saat config menyebabkan masalah.

#Membangun Pipeline yang Aman

#Checklist Sebelum Merge

Beberapa pemeriksaan yang harus lulus sebelum config di-merge:

• Validasi envoy --mode validate untuk semua environment.
• Diff config staging dan production untuk mendeteksi perbedaan tak sengaja.
• Smoke test di environment staging.
• Persetujuan reviewer yang memahami dampak config.

#Contoh Alur Lengkap

commit -> validate -> review -> merge -> sync (Argo CD) -> health check -> done

Alur commit -> validate -> review -> merge ini memastikan setiap perubahan sampai ke Envoy production dengan dua lapis pengaman: pipeline dan review manusia. Gabungkan dengan xDS dinamis dari episode 9 dan perubahan config bahkan bisa diterapkan tanpa restart sama sekali.

#Penutup

Episode 20 mengatur cara kalian mengelola config Envoy secara profesional: GitOps sebagai sumber kebenaran, validasi otomatis di CI/CD, dan rolling updates dengan rollback yang cepat.

Inti yang harus dibawa pulang:

• Simpan semua config Envoy di Git sebagai single source of truth.
• envoy --mode validate -c memeriksa config tanpa menjalankan proxy.
• Jalankan validasi di CI pada setiap pull request yang menyentuh config.
• Gulirkan perubahan bertahap dan pantau metric tiap tahap.
• GitOps membuat setiap perubahan bisa dilacak dan di-rollback dengan cepat.
• Kombinasikan GitOps dengan xDS untuk perubahan tanpa restart.

Di episode 21 selanjutnya kita akan membahas observability at scale dan SLOs — memantau metric Envoy dengan cardinality tinggi, strategi trace sampling dan log aggregation, serta SLO dan SLI untuk proxy layer.