Belajar HAProxy - CI/CD & Configuration Management

#Pendahuluan

Konfigurasi HAProxy adalah kode: dia harus di-review, diuji, dan di-deploy secara teratur. Episode 20 membahas cara memperlakukan haproxy.cfg seperti produk perangkat lunak yang layak.

Kalian akan membangun pipeline validasi di CI, memilih strategi rollout yang tidak mengganggu trafik, dan menguji perubahan pada lingkungan staging sebelum produksi. Tujuannya satu: perubahan konfigurasi tidak boleh lagi menjadi momen yang menegangkan.

#Validasi Konfigurasi di CI

#Langkah Validasi Dasar

Semua dimulai dari satu perintah yang sudah sering kalian pakai: haproxy -c. Di pipeline, perintah itu menjadi gerbang utama:

name: validate-haproxy
on:
  pull_request:
    paths:
      - "haproxy.cfg"
      - "maps/*.map"
 
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validate syntax
        run: |
          docker run --rm -v "$PWD:/config:ro" \
            haproxy:2.9-alpine \
            haproxy -c -f /config/haproxy.cfg

Workflow di atas menjalankan validasi setiap kali ada perubahan di file konfigurasi. haproxy -c -f /config/haproxy.cfg berjalan di container dengan versi HAProxy yang sama dengan produksi.

#Menjamin Konsistensi Versi

Perbedaan versi bisa membuat konfigurasi lolos validasi lokal tapi gagal di produksi. Karena itu:

• Gunakan image HAProxy versi produksi di pipeline.
• Tambahkan perintah haproxy -c -d untuk melihat evaluasi direktif.
• Simpan file konfigurasi di repository agar setiap perubahan bisa ditelusuri.

haproxy -c -d -f /etc/haproxy/haproxy.cfg

haproxy -c -d -f /etc/haproxy/haproxy.cfg memvalidasi sekaligus menampilkan hasil evaluasi. Berguna untuk menangkap direktif yang salah ketik sejak dini.

#Strategi Rollout yang Aman

#Blue-Green Deployment

Pola blue-green menjaga dua konfigurasi hidup: yang lama dan yang baru. Trafik dipindahkan sebagai satu unit:

haproxy -c -f /etc/haproxy/haproxy-green.cfg || exit 1
cp /etc/haproxy/haproxy-green.cfg /etc/haproxy/haproxy.cfg
systemctl reload haproxy

haproxy -c -f /etc/haproxy/haproxy-green.cfg || exit 1 memastikan konfigurasi baru valid sebelum menggantikan file aktif. Rollback cukup mengembalikan file lama dan reload lagi.

#Canary dengan Weight Runtime

Canary lebih mulus: sebagian kecil trafik diarahkan ke server dengan konfigurasi atau versi baru, sisanya ke yang lama:

backend web_back
    balance roundrobin
    server stable 10.0.0.11:8080 check weight 90
    server canary 10.0.0.12:8080 check weight 10

Konfigurasi di atas mengirim 10 persen trafik ke server canary. Jika sehat, naikkan bobotnya bertahap:

echo "set weight web_back/canary 50" | socat stdio /run/haproxy.sock

echo "set weight web_back/canary 50" | socat stdio /run/haproxy.sock menggeser trafik tanpa reload. Jika masalah muncul, turunkan weight kembali ke nol.

#Rollout per Node pada Klaster

Jika klaster memakai banyak node HAProxy (episode 13), rollout dilakukan node per node:

echo "set server web_back/node1 state drain" | socat stdio /run/haproxy.sock
systemctl restart haproxy
echo "set server web_back/node1 state ready" | socat stdio /run/haproxy.sock

Urutan drain, restart, ready membuat satu node diperbarui tanpa menurunkan layanan secara keseluruhan.

#Pengujian Sebelum Produksi

#Lingkungan Staging yang Setara

Pengujian yang bermakna butuh lingkungan yang menyerupai produksi:

• Salin konfigurasi produksi ke staging, ubah hanya nama host.
• Isi backend staging dengan mock atau aplikasi asli.
• Replay sebagian trafik produksi dengan tool seperti go-replay atau tcpreplay.

#Tes Perilaku Routing

Selain sintaks, uji perilaku: routing harus mengarah ke backend yang benar.

curl -s -o /dev/null -w "%{http_code}\n" http://staging/api/health
curl -s -o /dev/null -w "%{http_code}\n" http://staging/admin/health

curl -s -o /dev/null -w "%{http_code}\n" membandingkan status antar path. Uji ini bisa diulang di produksi setelah deploy untuk konfirmasi akhir.

#Kriteria Go/No-Go

Sebelum release ke produksi, pastikan:

• Validasi sintaks lulus di versi produksi.
• Tidak ada perubahan error rate di staging.
• Rollback path sudah teruji dan terdokumentasi.
• Log dan metrik terkoneksi sebelum trafik dinaikkan.

#Penutup

Episode 20 mengubah konfigurasi HAProxy menjadi aset yang dikelola seperti kode: validasi otomatis di CI, rollout yang bertahap dan mudah di-rollback, serta pengujian yang menjamin perilaku sebelum produksi.

Inti yang harus dibawa pulang:

• Jadikan haproxy -c sebagai gerbang wajib di pipeline CI.
• Gunakan versi image yang sama dengan produksi saat validasi.
• Blue-green memindahkan trafik sebagai satu unit; canary menggeser weight.
• Drain server node per node untuk rollout tanpa henti.
• Uji perilaku routing, bukan hanya sintaks, di staging.

Di episode 21 selanjutnya kita akan membahas SLOs, SLIs & operational metrics — mendefinisikan SLO untuk trafik HAProxy, menyusun alerting berbasis error rate, latensi, dan saturasi sumber daya, serta menulis runbook untuk insiden trafik dan failover.