Blue-Green Deploy Linux Host Upgrade adalah cara aman untuk mengganti host Linux produksi tanpa memutus layanan: siapkan lingkungan baru (green), validasi fungsinya di bawah beban realistis, pindahkan trafik secara terkontrol, lalu pertahankan opsi rollback ke lingkungan lama (blue) selama masa observasi. Untuk upgrade host, pendekatan ini jauh lebih aman dibanding mengganti kernel, driver, runtime, atau konfigurasi sistem langsung di node yang sedang melayani trafik.

Dalam praktiknya, upgrade host Linux bukan hanya soal OS. Risiko biasanya muncul dari perubahan kernel/userspace boundary, driver jaringan atau storage, perilaku cgroup, kompatibilitas container runtime, aturan network policy, hingga unit systemd yang gagal start. Inspirasi dari evolusi platform Linux modern, termasuk tren platform vendor seperti Qualcomm Linux 2.0 yang menekankan integrasi stack sistem yang lebih matang, menunjukkan satu hal penting: host upgrade harus diperlakukan sebagai perubahan platform, bukan sekadar patch rutin.

Kapan pendekatan ini layak dipakai

Pendekatan blue-green paling cocok bila Anda mengelola:

  • Node aplikasi stateless di belakang load balancer.
  • Worker yang bisa dihentikan dan dipindahkan antreannya.
  • Cluster container atau VM fleet dengan proses drain dan attach yang jelas.
  • Host produksi dengan SLA ketat, di mana reboot in-place berisiko tinggi.

Pendekatan ini kurang sederhana untuk workload stateful yang menyimpan data lokal pada host. Untuk kasus tersebut, Anda memerlukan strategi tambahan seperti replikasi data, failover storage, atau migrasi shard yang terpisah dari upgrade host.

Konsep arsitektur: blue, green, cutover, rollback

Model dasar

Arsitekturnya sederhana:

  • Blue: host Linux lama yang saat ini melayani produksi.
  • Green: host Linux baru dengan image, agent, dan konfigurasi yang sudah divalidasi.
  • Cutover: perpindahan trafik dari blue ke green secara bertahap atau sekaligus.
  • Rollback: pengembalian trafik ke blue jika metrik atau health check memburuk.

Yang membuat pendekatan ini efektif adalah pemisahan tegas antara fase build, validation, dan traffic switch. Anda tidak mencoba memperbaiki node setelah menerima trafik produksi. Anda membangun host baru, mengujinya terlebih dahulu, baru memindahkan trafik jika semua indikator aman.

Kenapa pendekatan ini bekerja

Upgrade host memengaruhi banyak lapisan sekaligus: boot sequence, modul kernel, firewall, jaringan, DNS resolver, runtime container, dan agent observability. Bila Anda melakukan upgrade di tempat (in-place), kegagalan pada salah satu lapisan bisa langsung menjatuhkan layanan dan memperumit rollback. Dengan blue-green, rollback cukup dilakukan pada lapisan trafik atau registrasi node, tanpa menunggu downgrade kernel atau reinstall package.

Tahap sebelum deploy: fondasi yang menentukan hasil

1. Definisikan batas perubahan

Sebelum membuat image green, catat apa saja yang berubah. Minimal buat daftar:

  • Kernel atau base image OS.
  • Driver NIC, disk, GPU, atau perangkat khusus.
  • Konfigurasi cgroup dan namespace.
  • Versi dan konfigurasi container runtime.
  • Agent log, metrics, security, backup, atau service mesh.
  • Aturan firewall, network policy, dan resolusi DNS.
  • Unit systemd, dependency, dan target boot.

Tanpa batas perubahan yang jelas, Anda tidak akan tahu apa penyebab kegagalan saat green bermasalah.

2. Bangun image host yang reproducible

Hindari membangun host produksi dengan langkah manual. Gunakan pipeline image yang bisa diulang, misalnya melalui tooling image builder internal, cloud image pipeline, atau provisioning berbasis deklaratif. Tujuannya bukan memilih alat tertentu, melainkan memastikan:

  • Package yang terpasang konsisten.
  • Konfigurasi sistem tercatat di version control.
  • Perubahan dapat diaudit.
  • Image green bisa dibuat ulang untuk rollback jangka menengah atau investigasi.

3. Validasi image dan agent sebelum host menerima trafik

Ini sering diabaikan. Banyak deployment gagal bukan karena aplikasi, tetapi karena agent di host baru tidak aktif. Contohnya: log tidak terkirim, metrics kosong, atau security agent memblokir proses runtime.

Minimal validasi:

  • Host bisa boot normal dan mencapai target boot yang diharapkan.
  • systemd unit kritikal berstatus active.
  • Agent log berjalan dan mengirim event uji.
  • Agent metrics berjalan dan mengekspor metrik host dasar.
  • Runtime container atau service supervisor bisa start workload contoh.
  • Koneksi keluar ke registry, control plane, atau endpoint internal berfungsi.

Contoh pemeriksaan dasar pada host Linux:

#!/usr/bin/env bash
set -euo pipefail

systemctl is-system-running || true
systemctl --failed --no-pager

for svc in docker containerd node-exporter rsyslog; do
  if systemctl list-unit-files | grep -q "^${svc}"; then
    systemctl is-active --quiet "$svc" || {
      echo "service gagal: $svc" >&2
      exit 1
    }
  fi
done

uname -r
cat /proc/cgroups || true
ip addr show
ip route
journalctl -p err -b --no-pager | tail -n 50

Nama service di atas hanyalah contoh. Sesuaikan dengan stack Anda. Intinya, sebelum green masuk rotasi, Anda harus bisa menjawab: host hidup, runtime siap, agent aktif, dan jalur jaringan dasar berfungsi.

4. Uji kompatibilitas workload terhadap host baru

Jangan hanya menguji host kosong. Jalankan workload yang representatif, termasuk:

  • Container atau service utama.
  • Init process atau hook startup.
  • Volume mount dan izin file.
  • Koneksi TLS ke dependency internal.
  • Penggunaan memori, CPU quota, dan limit I/O.

Masalah yang sering muncul saat upgrade host:

  • Perubahan perilaku cgroup membuat pembacaan resource limit aplikasi berbeda.
  • Runtime container gagal karena driver storage atau overlay tidak sesuai.
  • Network policy atau firewall host memblokir health check atau egress.
  • systemd unit gagal start karena dependency berubah atau target boot tidak tercapai.

Checklist risiko upgrade host Linux

Checklist berikut sebaiknya ditinjau sebelum cutover. Ini bukan formalitas; setiap butir sering menjadi akar insiden.

Kompatibilitas kernel

  • Pastikan modul yang dibutuhkan workload tersedia.
  • Periksa fitur yang dibutuhkan runtime, misalnya namespace, seccomp, eBPF, atau netfilter, bila relevan.
  • Waspadai perubahan parameter kernel default yang memengaruhi network backlog, memory reclaim, atau file descriptor.

Driver

  • Verifikasi NIC, storage, dan perangkat akselerator jika ada.
  • Pastikan antarmuka jaringan muncul dengan nama yang diharapkan atau automasi Anda tidak bergantung pada nama lama.
  • Uji throughput dan stabilitas dasar, bukan hanya apakah interface terlihat.

cgroup

  • Pastikan mode cgroup selaras dengan runtime dan orkestrator Anda.
  • Periksa apakah aplikasi atau script membaca path cgroup lama secara hardcoded.
  • Uji perilaku limit CPU dan memori, bukan hanya startup container.

Container runtime

  • Pastikan runtime bisa pull image, mount volume, dan menjalankan container dengan capability yang dibutuhkan.
  • Periksa integrasi dengan log driver, registry auth, dan garbage collection image.
  • Jangan mengasumsikan konfigurasi runtime lama aman di host baru tanpa validasi.

Network policy

  • Pastikan health check dari load balancer ke host green tidak diblokir.
  • Verifikasi egress ke database, cache, API internal, DNS, registry, dan observability backend.
  • Uji resolusi DNS dan timeout koneksi, karena isu jaringan sering terlihat sebagai “aplikasi lambat”.

systemd unit

  • Periksa dependency After=, Requires=, dan target yang digunakan.
  • Pastikan Restart= dan timeout startup masuk akal untuk host baru.
  • Tinjau file override lokal yang mungkin tidak ikut terbawa ke image green.

Health check yang benar untuk blue-green host upgrade

Health check tidak boleh hanya memeriksa bahwa port terbuka. Untuk upgrade host Linux, gunakan tiga lapis pemeriksaan:

1. Host health

  • Boot sukses dan tidak ada unit kritikal yang gagal.
  • Disk, memory, dan CPU dalam kondisi wajar.
  • Jaringan aktif, route benar, DNS berfungsi.

2. Runtime health

  • Container runtime atau process supervisor siap menerima workload.
  • Volume mount, secret, dan permission berhasil.
  • Agent observability aktif.

3. Service health

  • Aplikasi merespons endpoint health internal.
  • Koneksi ke dependency penting berhasil.
  • Readiness check menguji fungsi minimum, bukan sekadar proses hidup.

Contoh endpoint readiness yang lebih berguna:

GET /ready
- cek koneksi ke cache atau DB bila itu dependency wajib
- cek worker thread utama sudah aktif
- cek konfigurasi penting sudah termuat
- jangan jalankan query berat atau tes yang mahal

Kesalahan umum adalah membuat health check terlalu dangkal sehingga host green terlihat sehat padahal gagal mengirim log, tidak bisa resolve DNS, atau tidak dapat membuka koneksi keluar.

Observability minimum yang wajib ada

Jika Anda tidak bisa mengamati green dengan cepat, Anda tidak punya rollback yang terukur. Observability minimum untuk host upgrade sebaiknya mencakup log, metrics, dan alert.

Log

  • Boot log dan error journal.
  • Log startup runtime atau aplikasi.
  • Log network/security yang relevan bila ada policy host-level.

Hal yang perlu dipastikan:

  • Timestamp sinkron.
  • Hostname atau node ID green jelas.
  • Log terkirim ke backend sentral sebelum cutover penuh.

Metrics

Minimal kumpulkan metrik berikut:

  • CPU, memory, disk usage, disk latency, network error/drop.
  • Restart service/container.
  • Error rate aplikasi.
  • Latency p50/p95 layanan yang menerima trafik.
  • Jumlah request atau throughput pada green.

Untuk worker atau batch host, tambahkan metrik seperti:

  • Panjang antrean.
  • Waktu proses job.
  • Rasio job gagal atau retry.

Alert

Alert untuk fase cutover harus sederhana dan langsung terkait rollback. Misalnya:

  • Error rate naik di atas baseline normal.
  • Latency meningkat signifikan setelah trafik dialihkan.
  • Host green gagal mengirim metrics atau log.
  • Service restart berulang.
  • Health check dari load balancer mulai gagal.

Jika tim Anda belum punya observability yang matang, jangan menunggu sempurna. Mulai dari metrik inti yang benar-benar dipakai untuk keputusan rollback.

Runbook singkat blue-green deploy saat upgrade host Linux

Runbook harus cukup ringkas untuk dipakai saat tekanan produksi meningkat. Contoh berikut bisa dijadikan template.

Sebelum cutover

  1. Bangun host green dari image yang sudah disetujui.
  2. Join green ke network, registry, dan control plane yang diperlukan.
  3. Jalankan validasi host, runtime, agent, dan service.
  4. Pastikan dashboard metrik dan log untuk green sudah terlihat.
  5. Lakukan uji beban ringan atau trafik canary bila memungkinkan.
  6. Konfirmasi host blue tetap sehat sebagai target rollback.

Saat cutover

  1. Kurangi trafik ke blue atau drain koneksi sesuai mekanisme load balancer.
  2. Arahkan sebagian kecil trafik ke green.
  3. Amati error rate, latency, restart, dan saturation host.
  4. Jika stabil, tingkatkan trafik bertahap hingga penuh.
  5. Pertahankan blue dalam keadaan siap rollback selama masa observasi.

Setelah cutover

  1. Amati green pada jendela observasi yang disepakati.
  2. Pastikan tidak ada alarm tertunda seperti disk pressure, memory leak, atau packet drop.
  3. Dokumentasikan hasil, termasuk anomali kecil.
  4. Baru nonaktifkan blue setelah masa aman lewat.

Contoh alur drain dan verifikasi

# contoh konseptual, sesuaikan dengan platform Anda
# 1. tandai blue tidak menerima trafik baru
# 2. tunggu koneksi aktif turun
# 3. registrasikan green
# 4. verifikasi health check green lulus
# 5. arahkan trafik bertahap
# 6. monitor metrik kunci selama beberapa menit pertama

Perintah konkret sangat bergantung pada load balancer, orchestrator, atau service discovery yang dipakai. Hindari runbook yang terlalu spesifik ke satu tool bila infrastruktur Anda heterogen.

Metrik keberhasilan dan trigger rollback

Metrik keberhasilan

Tentukan sejak awal apa yang dianggap sukses. Contoh indikator yang umum:

  • Semua host green lulus health check host, runtime, dan service.
  • Error rate tetap pada kisaran normal.
  • Latency tidak mengalami regresi yang bermakna.
  • Tidak ada lonjakan restart container atau unit systemd.
  • Metrics dan log dari green masuk konsisten.
  • Tidak ada backlog antrean atau timeout dependency yang meningkat.

Trigger rollback

Rollback harus didasarkan pada sinyal yang jelas, bukan perdebatan saat insiden. Contoh trigger rollback:

  • Health check green gagal berulang dalam interval pendek.
  • Error rate naik dan tidak kembali normal setelah trafik ditahan.
  • Latency melonjak setelah cutover tanpa penjelasan jelas.
  • Agent observability gagal, sehingga kondisi green tidak bisa dinilai.
  • Dependency jaringan kritikal tidak dapat diakses dari green.
  • Terjadi crash loop pada runtime atau service utama.

Prinsip pentingnya: lebih baik rollback cepat dengan data cukup daripada bertahan terlalu lama di kondisi tidak pasti.

Rollback cepat yang benar-benar bisa dijalankan

Rollback bukan dokumen; rollback adalah operasi yang harus bisa dilakukan dalam menit, bukan jam. Untuk itu:

  • Jangan hapus atau ubah blue sebelum green melewati masa observasi.
  • Simpan konfigurasi registrasi trafik blue agar bisa diaktifkan kembali cepat.
  • Pastikan blue masih kompatibel dengan dependency saat rollback terjadi.
  • Hindari migrasi state irreversibel bersamaan dengan host upgrade.

Urutan rollback yang aman biasanya:

  1. Hentikan penambahan trafik ke green.
  2. Alihkan trafik kembali ke blue.
  3. Verifikasi service level pulih di blue.
  4. Bekukan investigasi green; jangan sekaligus menerapkan banyak perubahan baru.
  5. Kumpulkan artefak debug: journal, log runtime, status service, snapshot konfigurasi.

Kesalahan umum saat rollback adalah mencoba memperbaiki green sambil tetap menerima sebagian trafik. Ini memperkeruh sinyal dan memperbesar durasi insiden.

Tindakan pencegahan agar upgrade host tidak memutus layanan

  • Pisahkan upgrade host dari perubahan aplikasi besar. Jika dua hal berubah sekaligus, analisis kegagalan menjadi sulit.
  • Gunakan canary sebelum full cutover. Bahkan satu host green yang menerima sebagian kecil trafik sudah cukup untuk menemukan masalah besar.
  • Pastikan kapasitas blue cukup menampung rollback. Jangan mengurangi kapasitas lama terlalu cepat.
  • Jaga kompatibilitas backward untuk service discovery, secret, dan logging.
  • Latih rollback. Simulasi rollback jauh lebih berharga daripada runbook yang belum pernah diuji.
  • Bekukan perubahan non-esensial selama window upgrade.

Debugging cepat saat green gagal

Saat green bermasalah, fokus pada pembuktian lapis demi lapis:

  1. Host: apakah boot bersih, unit kritikal aktif, NIC dan route benar?
  2. Runtime: apakah container/service benar-benar bisa start dan membaca konfigurasi?
  3. Network: apakah DNS, egress, dan health check LB berjalan?
  4. Observability: apakah log dan metrik tersedia sehingga Anda tidak buta?
  5. Workload behavior: apakah masalah terjadi hanya di bawah trafik nyata?

Perintah yang sering berguna saat investigasi awal:

journalctl -b --no-pager | tail -n 200
journalctl -u your-service --no-pager | tail -n 200
systemctl status your-service --no-pager
ss -lntp
ip route
resolvectl status || cat /etc/resolv.conf
df -h
free -m

Jangan langsung menyimpulkan “kernel baru buruk” atau “runtime rusak” tanpa memeriksa jaringan, unit dependency, dan permission filesystem. Banyak kegagalan upgrade host ternyata berasal dari konfigurasi bootstrap yang tidak ikut terbawa ke image green.

Postmortem ringan bila rilis gagal

Bila cutover gagal dan Anda melakukan rollback, lakukan postmortem ringan pada hari yang sama selagi konteks masih segar. Tujuannya bukan menyalahkan, melainkan memperkuat proses deploy berikutnya.

Format sederhana yang efektif

  • Apa yang berubah? Kernel, runtime, unit, policy, image, agent.
  • Apa gejalanya? Error rate, timeout, crash loop, health check gagal.
  • Kapan terdeteksi? Sebelum atau sesudah trafik nyata masuk.
  • Sinyal apa yang paling membantu? Log, metrik, alert, atau laporan pengguna.
  • Kenapa rollback berhasil atau lambat?
  • Kontrol apa yang hilang? Misalnya validasi agent belum ada, network policy belum diuji, atau dashboard belum disiapkan.
  • Aksi pencegahan berikutnya? Tambahkan test, check, alarm, atau guardrail baru.

Postmortem ringan sudah cukup selama menghasilkan tindakan konkret. Fokus pada perbaikan pipeline dan runbook, bukan laporan panjang yang tidak dioperasionalkan.

Penutup

Blue-Green Deploy Linux Host Upgrade memberi jalur aman untuk memperbarui host produksi karena Anda memindahkan risiko ke fase validasi, bukan ke saat node sedang aktif melayani trafik. Kunci keberhasilannya bukan pada istilah blue-green itu sendiri, melainkan pada disiplin operasional: image yang reproducible, validasi host dan agent, health check berlapis, observability minimum, trigger rollback yang jelas, serta postmortem ringan setiap kali rilis gagal.

Jika Anda ingin mengurangi kemungkinan layanan terputus saat upgrade host Linux, mulai dari hal paling praktis: buat checklist risiko, siapkan green yang benar-benar bisa diamati, lakukan cutover bertahap, dan jangan kompromi pada rollback cepat.