Deployment stateless pada host tanpa shared filesystem cocok ketika Anda ingin rollback cepat, isolasi antar host, dan tidak mau menggantungkan runtime aplikasi pada network mount. Intinya sederhana: setiap host menerima artifact versi tertentu, menyimpannya sebagai rilis immutable, lalu menjalankan aplikasi melalui symlink seperti current. Jika rilis baru bermasalah, Anda cukup menggeser symlink kembali ke versi sebelumnya dan me-reload proses.

Pendekatan ini mengingatkan pada pola lama workstation diskless SunOS sebelum NFS dipakai luas: sistem tetap bisa beroperasi dengan salinan lokal yang jelas dan terkontrol, bukan membaca semua hal secara dinamis dari storage bersama. Dalam konteks modern, ide yang relevan bukan nostalgia infrastrukturnya, melainkan prinsip operasionalnya: state runtime sesedikit mungkin, artifact tidak berubah, dan pergantian versi harus murah.

Mengapa memilih deployment stateless tanpa shared FS

Pada model ini, tiap host memiliki salinan artifact sendiri. Anda tidak mengeksekusi aplikasi langsung dari shared storage, object mount, atau filesystem jaringan. Keuntungan praktisnya:

  • Rollback cepat: tidak perlu menyalin ulang artifact lama jika masih tersimpan di host.
  • Kegagalan lebih terlokalisasi: masalah di satu host tidak otomatis menjalar ke semua host lewat filesystem bersama.
  • Perilaku runtime lebih deterministik: proses membaca file lokal, bukan bergantung pada latensi dan ketersediaan mount jaringan.
  • Mudah diaudit: versi aktif pada host bisa diketahui dari direktori rilis atau symlink.

Namun model ini bukan tanpa biaya. Anda harus disiplin pada versioning artifact, distribusi file ke semua host, dan pencegahan configuration drift. Jika tidak, tiap host bisa diam-diam menjalankan kombinasi binary, config, atau aset yang berbeda.

Prinsip desain yang perlu dipegang

1. Rilis harus immutable

Setelah artifact versi 2026-08-03.1 atau commit tertentu dirilis, isinya tidak boleh diubah. Jika ada perbaikan, buat rilis baru. Ini penting agar rollback benar-benar kembali ke keadaan yang sama seperti sebelumnya, bukan ke direktori yang sudah ditambal manual.

2. Pisahkan artifact, konfigurasi, dan data runtime

Artifact aplikasi berisi binary, dependency, template, dan aset statis yang diperlukan untuk berjalan. Konfigurasi lingkungan seperti endpoint database, kredensial, atau flag operasional sebaiknya berada di luar artifact, misalnya melalui environment variable atau file config terkelola. Data runtime seperti PID file, socket, cache lokal, dan log tidak boleh ditulis ke direktori rilis.

3. Aktivasi rilis harus atomik

Host perlu cara sederhana untuk berpindah dari versi lama ke versi baru. Teknik yang umum adalah symlink:

  • /opt/myapp/releases/2026-08-03.1
  • /opt/myapp/releases/2026-08-01.3
  • /opt/myapp/current -> /opt/myapp/releases/2026-08-03.1

Mengubah symlink adalah operasi kecil dan cepat. Dengan ini, Anda tidak mencampur file antar versi di direktori yang sama.

4. Host harus disposable, tetapi rollback tetap lokal

Disebut stateless bukan berarti host tidak punya disk lokal sama sekali, melainkan state penting tidak disimpan di host sebagai satu-satunya sumber kebenaran. Menyimpan beberapa rilis artifact di disk lokal untuk rollback tetap masuk akal, selama data bisnis, sesi penting, dan antrian persisten tidak bergantung pada disk host tersebut.

Struktur direktori yang praktis

Berikut contoh layout yang mudah dioperasikan:

/opt/myapp/
  releases/
    2026-08-01.3/
    2026-08-03.1/
  current -> /opt/myapp/releases/2026-08-03.1
  shared/
    tmp/
    run/
  logs/

Beberapa catatan:

  • releases/ berisi artifact immutable.
  • current menunjuk ke versi aktif.
  • shared/ boleh dipakai untuk file runtime yang tidak layak masuk ke artifact, tetapi jangan menjadikannya tempat penyimpanan state bisnis.
  • Jika aplikasi menulis cache lokal, pastikan aman untuk dihapus dan dibangun ulang.

Alur deployment yang aman dan bisa di-rollback

1. Bangun artifact sekali

Buat artifact di CI, lalu gunakan hasil yang sama untuk semua host. Jangan membangun ulang per host karena dapat menimbulkan perbedaan isi walaupun versi logisnya sama.

Contoh isi artifact bisa berupa:

  • binary hasil kompilasi, atau
  • direktori aplikasi yang sudah berisi dependency produksi, atau
  • arsip .tar.gz yang nanti diekstrak di host.

Tambahkan metadata sederhana seperti versi, commit, waktu build, dan checksum.

2. Distribusikan ke host

Artifact dapat didorong ke host melalui SCP/rsync, agen deployment, atau ditarik dari object storage. Yang penting, host menerima file berdasarkan versi yang jelas dan memverifikasi integritasnya sebelum aktivasi.

# contoh alur generik di host
APP_DIR=/opt/myapp
REL=2026-08-03.1
mkdir -p "$APP_DIR/releases/$REL"
tar -xzf "/tmp/myapp-$REL.tar.gz" -C "$APP_DIR/releases/$REL"

# opsional: verifikasi checksum sebelum lanjut
sha256sum -c "/tmp/myapp-$REL.tar.gz.sha256"

3. Jalankan preflight check

Sebelum symlink digeser, validasi hal-hal yang paling sering gagal:

  • file utama ada dan permission benar,
  • konfigurasi wajib tersedia,
  • dependency eksternal penting dapat dijangkau,
  • port tujuan belum bentrok,
  • migrasi database kompatibel dengan strategi rilis Anda.

Kesalahan umum di sini adalah langsung mengaktifkan rilis baru tanpa memastikan aplikasi benar-benar bisa start.

4. Aktivasi dengan symlink current

Setelah preflight lolos, ubah symlink lalu lakukan reload atau restart proses dengan cara yang sesuai.

ln -sfn "/opt/myapp/releases/$REL" /opt/myapp/current
systemctl reload myapp || systemctl restart myapp

ln -sfn lazim dipakai karena sederhana. Pastikan proses Anda memang membaca path melalui /opt/myapp/current, bukan path versi hardcoded, agar pergantian rilis benar-benar efektif.

5. Health check pasca-aktivasi

Jangan menganggap deploy berhasil hanya karena proses hidup. Minimal lakukan:

  • process check: service up, tidak crash-loop,
  • readiness check: endpoint health mengembalikan status sukses,
  • smoke test: satu atau dua request nyata yang mewakili fungsi penting.

Bedakan liveness dan readiness. Proses bisa hidup tetapi belum siap menerima trafik karena koneksi database belum sehat atau cache belum terinisialisasi.

Contoh skrip deploy dan rollback

Berikut contoh skrip shell generik. Ini bukan sistem orkestrasi penuh, tetapi cukup menunjukkan pola yang penting.

#!/usr/bin/env sh
set -eu

APP_DIR=/opt/myapp
REL="$1"
ARCHIVE="/tmp/myapp-$REL.tar.gz"
RELEASE_DIR="$APP_DIR/releases/$REL"
CURRENT_LINK="$APP_DIR/current"
PREV_LINK="$APP_DIR/previous"

mkdir -p "$APP_DIR/releases" "$APP_DIR/shared/tmp" "$APP_DIR/shared/run"
rm -rf "$RELEASE_DIR"
mkdir -p "$RELEASE_DIR"
tar -xzf "$ARCHIVE" -C "$RELEASE_DIR"

# simpan target current lama untuk rollback cepat
if [ -L "$CURRENT_LINK" ]; then
  PREV_TARGET=$(readlink "$CURRENT_LINK")
  ln -sfn "$PREV_TARGET" "$PREV_LINK"
fi

# preflight sederhana
test -x "$RELEASE_DIR/bin/start-app"
test -f "$RELEASE_DIR/config/schema.json"

ln -sfn "$RELEASE_DIR" "$CURRENT_LINK"
if ! systemctl restart myapp; then
  echo "restart gagal, rollback..."
  if [ -L "$PREV_LINK" ]; then
    ln -sfn "$(readlink "$PREV_LINK")" "$CURRENT_LINK"
    systemctl restart myapp
  fi
  exit 1
fi

# health check singkat
if ! curl -fsS http://127.0.0.1:8080/healthz >/dev/null; then
  echo "health check gagal, rollback..."
  if [ -L "$PREV_LINK" ]; then
    ln -sfn "$(readlink "$PREV_LINK")" "$CURRENT_LINK"
    systemctl restart myapp
  fi
  exit 1
fi

echo "deploy $REL berhasil"

Beberapa alasan mengapa pola ini efektif:

  • Artifact diekstrak ke direktori baru, bukan menimpa direktori lama.
  • Symlink lama disimpan agar rollback tidak perlu menebak versi sebelumnya.
  • Restart dan health check menjadi gerbang sukses deploy.
  • Rollback dilakukan dengan mekanisme yang sama seperti deploy: geser symlink, restart, verifikasi.

Untuk rollback manual, host cukup menjalankan:

ln -sfn "$(readlink /opt/myapp/previous)" /opt/myapp/current
systemctl restart myapp
curl -fsS http://127.0.0.1:8080/healthz

Health check yang benar-benar berguna

Banyak implementasi health check terlalu dangkal: asal mengembalikan HTTP 200. Untuk deployment stateless, health check sebaiknya menjawab pertanyaan operasional: apakah host aman menerima trafik sekarang?

Minimum yang perlu ada

  • Endpoint readiness yang memeriksa dependency kritis seperlunya.
  • Build info seperti versi dan commit aktif untuk memudahkan verifikasi.
  • Timeout pendek agar check tidak menggantung saat deploy.

Contoh respons yang berguna:

{
  "status": "ok",
  "version": "2026-08-03.1",
  "commit": "a1b2c3d4",
  "uptime_sec": 42
}

Anda tidak perlu memasukkan semua detail dependency ke health endpoint publik. Untuk endpoint internal, cukup tampilkan informasi yang membantu operator memastikan bahwa host memang menjalankan rilis yang diharapkan.

Observability minimum yang wajib ada

Rollback cepat hanya berguna jika Anda cepat tahu bahwa rilis baru bermasalah. Minimal, pantau hal-hal berikut per host dan per versi rilis:

  • request rate,
  • error rate HTTP atau RPC,
  • latency terutama p95/p99 jika tersedia,
  • restart/crash count,
  • health check failures,
  • log startup dan error fatal,
  • versi rilis aktif sebagai label atau field log.

Jika sistem Anda sederhana, observability minimum bisa berupa:

  • log terstruktur ke collector pusat,
  • satu dashboard metrik layanan,
  • alert saat error rate naik atau instance healthy turun setelah deploy.

Kesalahan umum adalah hanya memantau CPU dan memori. Untuk keputusan rollback, metrik aplikasi hampir selalu lebih penting.

Alur insiden singkat: gejala, mitigasi, rollback, verifikasi, postmortem

Gejala

Setelah rilis 2026-08-03.1 masuk ke tiga dari dua puluh host, error rate endpoint login naik, beberapa host mengembalikan 502, dan log menunjukkan kegagalan memuat file konfigurasi turunan.

Mitigasi

Hentikan rollout ke host lain. Jika Anda berada di belakang load balancer, keluarkan host yang bermasalah dari pool atau tandai tidak siap menerima trafik. Tujuannya membatasi dampak sambil mengumpulkan sinyal.

Rollback

Geser current kembali ke previous pada host terdampak, lalu restart service. Karena artifact lama masih lokal, rollback tidak perlu menarik file dari jaringan atau menunggu sinkronisasi shared storage.

Verifikasi

Pastikan:

  • health endpoint kembali sukses,
  • versi aktif sesuai target rollback,
  • error rate turun,
  • trafik normal kembali setelah host dimasukkan ke pool.

Postmortem ringan

Catat akar masalah, misalnya file config opsional ternyata diasumsikan selalu ada oleh startup baru. Tindak lanjut yang layak:

  • tambahkan preflight check untuk file tersebut,
  • perbaiki startup agar gagal dengan pesan yang lebih jelas,
  • perketat checklist rilis,
  • mulai rollout dari canary lebih kecil.

Postmortem tidak harus panjang, tetapi harus menghasilkan perubahan konkret agar kelas insiden yang sama tidak berulang.

Mencegah drift konfigurasi antar host

Tanpa shared FS, salah satu risiko utama adalah drift konfigurasi: host A dan host B menjalankan artifact yang sama, tetapi environment variable, file config, sertifikat, atau secret berbeda. Gejalanya sering membingungkan karena hanya sebagian host yang gagal.

Tindakan pencegahan yang efektif:

  • Kelola config secara terpusat melalui sistem manajemen konfigurasi atau secret manager.
  • Template config dari sumber yang sama, bukan edit manual di host.
  • Validasi startup untuk semua variabel wajib.
  • Expose build/config fingerprint yang aman di endpoint internal atau log startup.
  • Larangan perubahan manual pada direktori rilis dan file config produksi tanpa jejak perubahan.

Jika Anda harus menyimpan file environment lokal, setidaknya hash atau tanggal pembaruannya perlu bisa diaudit.

Checklist rilis yang realistis

Checklist tidak perlu birokratis, tetapi harus menutup celah yang sering memicu rollback darurat.

  1. Artifact dibangun sekali di CI dan memiliki versi unik.
  2. Checksum atau integritas artifact diverifikasi.
  3. Catatan perubahan menyebut perubahan skema, config baru, atau migrasi.
  4. Kompatibilitas database diperiksa untuk deploy bertahap.
  5. Canary host dipilih sebelum rollout penuh.
  6. Health check dan smoke test didefinisikan.
  7. Dashboard dan alert dipantau selama rollout.
  8. Mekanisme rollback diuji, bukan hanya diasumsikan ada.

Canary kecil lebih penting daripada rollout cepat

Pada banyak tim, masalah bukan tidak punya rollback, tetapi mendeteksi kebutuhan rollback terlalu lambat. Karena itu, canary kecil adalah pasangan alami deployment stateless. Aktifkan rilis baru pada satu atau dua host lebih dulu, amati metrik dan log beberapa menit, baru lanjutkan bertahap.

Canary membantu menemukan masalah yang lolos tes, seperti:

  • path file lokal yang berbeda antar image atau host,
  • konfigurasi yang tidak lengkap di sebagian environment,
  • masalah performa startup,
  • perubahan perilaku pada trafik nyata.

Jika canary gagal, rollback lokal terjadi cepat dan blast radius tetap kecil.

Trade-off dibanding shared storage atau network mount modern

Kelebihan pendekatan tanpa shared FS

  • Ketergantungan runtime lebih sedikit: aplikasi tidak perlu mount jaringan agar bisa membaca binary dan asetnya.
  • Rollback lebih langsung: host tinggal kembali ke artifact lokal sebelumnya.
  • Failure domain lebih kecil: outage pada shared storage tidak otomatis mematikan semua instance.

Kekurangannya

  • Distribusi artifact lebih kompleks karena tiap host harus menerima salinan.
  • Kebutuhan disk lokal lebih besar jika Anda menyimpan beberapa versi untuk rollback.
  • Risiko drift lebih tinggi jika konfigurasi tidak dikelola disiplin.
  • Cleanup perlu diotomatisasi agar rilis lama tidak menumpuk.

Kapan shared storage tetap masuk akal

Shared storage masih relevan untuk data yang memang harus dibagi, seperti media upload bersama, model tertentu, atau aset yang terlalu besar untuk dibundel per rilis. Tetapi sebisa mungkin, jangan jadikan shared mount sebagai tempat eksekusi artifact aplikasi utama. Pisahkan kebutuhan data bersama dari kebutuhan deployment aplikasi.

Kesalahan umum yang sering muncul

  • Menulis file ke direktori rilis, sehingga artifact tidak lagi immutable.
  • Symlink current dipakai sebagian, sementara beberapa service masih menunjuk path versi lama atau hardcoded.
  • Rollback tidak diuji, sehingga saat insiden justru gagal karena script usang.
  • Migrasi database tidak kompatibel mundur, membuat rollback aplikasi tidak cukup memulihkan layanan.
  • Health check terlalu dangkal, menyebabkan host yang rusak tetap dianggap sehat.

Penutup

Deployment stateless untuk host tanpa shared filesystem bekerja baik jika Anda menegakkan beberapa disiplin dasar: artifact immutable per versi, aktivasi atomik lewat symlink current, health check yang bermakna, observability minimum, dan rollback yang benar-benar pernah diuji. Pendekatan ini tidak menghilangkan semua risiko, tetapi sangat mengurangi biaya operasional saat rilis bermasalah.

Jika Anda mengelola banyak host dan ingin rollback cepat tanpa bergantung pada shared FS, mulailah dari hal yang paling praktis: struktur direktori rilis, metadata versi, canary kecil, lalu otomasi deploy dan rollback yang konsisten. Dari sana, reliability biasanya meningkat bukan karena sistem menjadi rumit, tetapi karena proses rilis menjadi lebih deterministik.