Blue-Green vs Canary Deployment dengan Budget Terbatas (Tanpa Kubernetes)

Kebanyakan artikel tentang strategi deployment mengasumsikan Anda punya Kubernetes, Istio, dan tim platform. Kebanyakan tim yang saya tangani punya dua atau tiga developer, beberapa VPS, nginx, dan Docker. Kabar baik yang jarang disampaikan: blue-green dan canary deployment adalah pola routing, bukan fitur Kubernetes. Semua yang Anda butuhkan untuk menjalankan keduanya dengan aman sudah ada di nginx dan Docker Compose yang Anda operasikan sekarang.

Saya sudah merilis kedua pola ini untuk klien SMB Indonesia dan di box Docker Swarm saya sendiri. Di artikel ini saya akan mendefinisikan tiap strategi dengan presisi, menunjukkan implementasi minimal yang bekerja di satu VPS, membandingkan keduanya pada kriteria yang benar-benar penting di skala kecil — biaya, kecepatan rollback, dan kebutuhan observability — dan memberi Anda aturan keputusan yang muat di selembar sticky note.

Dua Strategi dalam Satu Menit

Perhatikan kesamaan kedua definisi: dua versi berjalan bersamaan dan sebuah router yang memutuskan siapa melihat apa. Router itu tidak harus service mesh. Dengan budget terbatas, ia adalah nginx dengan blok upstream — dan persis itulah implementasi yang akan kita bangun.

Blue-Green di Satu VPS dengan Nginx dan Compose

Blue-green minimal saya adalah dua proyek Docker Compose, app-blue di port 3001 dan app-green di port 3002, di belakang satu upstream nginx. Script deploy-nya cukup pendek untuk dibaca utuh:

# Two compose projects, one nginx upstream
# /etc/nginx/conf.d/app-upstream.conf
upstream app_backend {
    server 127.0.0.1:3001;   # blue (live)
    # server 127.0.0.1:3002; # green (idle)
}

# deploy.sh — the whole "platform"
docker compose -p app-green up -d --build   # start new version on :3002
./smoke-test.sh http://127.0.0.1:3002       # verify before any user sees it
sed -i 's/3001/3002/' /etc/nginx/conf.d/app-upstream.conf
nginx -t && nginx -s reload                  # atomic cutover
docker compose -p app-blue stop              # keep it around for rollback

Tiga properti membuat ini sepadan dengan RAM ekstra yang sederhana untuk menjalankan dua instance aplikasi sebentar:

• User tidak pernah melihat kondisi setengah-terdeploy. Smoke test berjalan terhadap build production sungguhan, di hardware production, sebelum reload — kegagalan tertangkap saat green masih nol traffic.
• Rollback adalah operasi satu baris yang sama dibalik arah, dan hanya butuh hitungan detik. Tanpa rebuild image, tanpa git revert di bawah tekanan, cukup arahkan nginx kembali ke blue.
• Reload nginx itu graceful: koneksi yang ada diselesaikan worker process lama sementara koneksi baru menuju upstream baru. Di workload HTTP, cutover-nya praktis tak terlihat.

Canary Tanpa Service Mesh: Weighted Upstream

Canary release terdengar seperti butuh traffic splitting milik Istio, padahal nginx sudah membawa weighted load balancing selama dua dekade. Layout dua-instance yang sama berubah jadi canary dengan satu directive:

# Weighted canary with plain nginx — no service mesh
upstream app_backend {
    server 127.0.0.1:3001 weight=9;  # stable: 90% of traffic
    server 127.0.0.1:3002 weight=1;  # canary: 10% of traffic
}

# promote by shifting weights: 9/1 -> 5/5 -> 0/1
# rollback = comment out the canary line and reload

Promosi berarti mengedit weight dan reload: biasanya saya pakai 10 persen selama sejam, 50 persen beberapa jam, lalu 100. Jebakan yang jarang disebut: weighted canary hanya sebagus kemampuan Anda membandingkan dua versi. Kalau Anda tidak bisa membedakan error canary dari error stabil, Anda bukan sedang canary — Anda sedang berjudi pelan-pelan. Saya melabeli metrik dan log berdasarkan port upstream di Prometheus dan Loki sehingga perbandingannya jadi satu panel Grafana: error rate dan latency p95, stabil versus canary, berdampingan.

Adu Langsung untuk Tim Kecil

Kedua pola mengalahkan deploy-sambil-berdoa. Bedanya ada di apa yang mereka minta dari Anda dan dari monitoring Anda:

Database Adalah Bagian Tersulit di Keduanya

Kedua strategi menempatkan dua versi aplikasi pada satu database, jadi skemanya harus mendukung keduanya sekaligus. Saran Fowler lahir sebelum Kubernetes dan tetap mengalahkan semua tool: pisahkan perubahan skema dari deploy kode dengan expand-and-contract. Urutannya mekanis:

1. Expand: terapkan migrasi aditif — kolom nullable baru, tabel baru, index baru. Kode lama mengabaikannya, kode baru bisa memakainya. Deploy ini sendirian dan verifikasi.
2. Deploy versi aplikasi baru dengan blue-green atau canary, sementara kode lama dan baru sama-sama bekerja terhadap skema yang sudah diperluas.
3. Migrasikan data di background bila perlu, dalam batch kecil yang tidak mengunci tabel production.
4. Contract: hanya setelah versi baru melewati masa soak dan environment lama dipensiunkan, hapus kolom lama di migrasi terpisah. Jangan pernah expand dan contract dalam satu rilis yang sama.

Aturan Keputusan Saya

• Default ke blue-green. Lebih mudah dinalar, tidak butuh observability per versi, dan mencakup mayoritas mutlak rilis untuk tim seukuran dua pizza.
• Pakai canary saat perubahannya benar-benar berisiko dan service-nya cukup ramai sehingga irisan 10 persen menghasilkan sinyal yang bermakna secara statistik dalam satu-dua jam.
• Kalau Anda belum bisa memisahkan metrik per versi, Anda belum bisa canary — investasikan dulu di metrik Prometheus berlabel, atau tetap di blue-green dengan jujur.
• Jangan pernah mencampur contract skema dengan strategi mana pun. Expand-and-contract membuat kedua pola aman; melewatkannya membuat kedua pola berbahaya.

Intinya

Keamanan deployment adalah properti dari routing dan disiplin Anda, bukan label harga orchestrator Anda. VPS 4 dolar yang menjalankan nginx di depan dua proyek Compose memberi jaminan fundamental yang sama dengan yang dibeli perusahaan lewat service mesh: cutover tanpa downtime, rollback instan, dan paparan terkontrol.

Mulailah dengan script blue-green di atas — itu kerja satu sore termasuk smoke test-nya. Tambahkan weighted canary di hari Anda merilis sesuatu yang sungguh menakutkan. Dan apa pun pilihan Anda, lakukan tarian expand-and-contract di database, karena di sanalah strategi deployment benar-benar gagal.