Belajar LocalStack - Persistence & State Management

#Pendahuluan

Selama sepuluh episode lebih kita membangun bucket, tabel, fungsi Lambda, queue, hingga secret di LocalStack. Tapi ada satu ketentuan yang belum dibahas: semua state itu hidup di memori emulator. Restart image, dan semuanya lenyap — seperti server tanpa hard disk. Di episode 11 kita menyimpan rahasia; kini kita amankan seluruh state dengan persistence dan snapshot.

Di episode ini kalian akan mengaktifkan PERSISTENCE=1, memahami di mana data disimpan dan bagaimana volume bekerja, lalu menggunakan Cloud Pods untuk membagikan state lengkap ke tim.

#Mengapa State Hilang Tanpa Persistence

Secara default, LocalStack berjalan dengan penyimpanan ephemeral: file system di dalam container bersifat sementara. Restart container menghapus bucket S3, tabel DynamoDB, fungsi Lambda, dan secret yang sudah dibuat. Ini sengaja — CI menginginkan lingkungan yang bersih dan deterministik setiap kali dijalankan.

Masalahnya muncul saat development: membangun ulang seluruh infrastruktur setiap kali ganti branch atau menyalakan ulang laptop itu membuang waktu. Solusinya adalah persistence: menulis state ke disk yang bertahan hidup melewati restart.

#Mengaktifkan PERSISTENCE

Cukup satu environment variable: PERSISTENCE=1. Definisikan lewat docker-compose agar berlaku konsisten:

docker-compose.yml dengan persistence

services:
  localstack:
    image: localstack/localstack:latest
    ports:
      - "4566:4566"
    environment:
      - PERSISTENCE=1
      - DEBUG=1
    volumes:
      - localstack_data:/var/lib/localstack
 
volumes:
  localstack_data:

Perhatikan baris volume: inilah kunci sebenarnya. PERSISTENCE=1 memberi tahu emulator untuk menyimpan state ke /var/lib/localstack di dalam container, dan named volume Docker menjaga direktori itu tetap ada setelah container mati.

Tip

Named volume (localstack_data) lebih disarankan daripada bind mount untuk penggunaan normal: penanganan permission otomatis dan tidak bergantung path host. Bind mount baru perlu jika kalian ingin memeriksa file mentah dari host.

#Lokasi Data di Dalam Container

Data terletak di /var/lib/localstack dengan subdirektori per layanan: object S3, tabel DynamoDB, state Lambda, dan lain-lain. Verifikasi dari dalam container:

Lihat isi direktori state

docker compose exec localstack ls -la /var/lib/localstack
docker compose exec localstack du -sh /var/lib/localstack

Jika kalian pernah memakai DynamoDB Local atau moto, pola ini familiar: emulasi stateful ditulis ke disk agar bisa dibaca ulang saat startup berikutnya.

#Menguji Persistence

Uji sederhana untuk membuktikan state bertahan. Buat bucket, restart container, lalu cek apakah bucket masih ada:

Tulis, restart, verifikasi

awslocal s3 mb s3://survives
docker compose restart localstack
awslocal s3 ls

Jika survives muncul, persistence bekerja. Pastikan emulator hidup kembali dengan localstack status sebelum menjalankan perintah verifikasi. Balik keadaan: matikan PERSISTENCE, lakukan langkah yang sama, dan bucket akan hilang — bukti bahwa env var inilah pengontrol state.

#Kapan Persistence Harus Dimatikan

Persistence bukan selalu baik. Di CI/CD, biarkan state bersih: setiap job butuh lingkungan deterministik dari nol, dan state lama justru mengotori hasil test. Di dev lokal, nyalakan persistence untuk kenyamanan iterasi. Aturan praktis: persistence untuk manusia, kebersihan untuk mesin.

Warning

Jangan pernah menguji skenario state kosong (misalnya bucket baru) dengan persistence aktif — sisa data test sebelumnya bisa membuat test palsu lolos. Matikan persistence atau pakai volume terpisah untuk test suite.

#Cloud Pods: Snapshot State untuk Tim (Pro)

Persistence melindungi state di satu mesin. Tapi bagaimana jika ingin berbagi state ke rekan kerja atau memindahkannya ke CI? Jawaban Pro LocalStack adalah Cloud Pods: snapshot seluruh state yang diunggah ke cloud dan bisa dimuat kembali di instance mana pun.

#Menyimpan & Memuat Pod

Cloud Pods memakai CLI localstack pod:

Simpan dan muat pod

localstack pod save staging-ready
localstack pod list
localstack pod load staging-ready

Setelah pod save staging-ready, seluruh bucket, tabel, fungsi, dan secret dikemas menjadi satu snapshot bernama. Developer lain cukup menjalankan pod load staging-ready untuk memiliki lingkungan identik — tanpa setup manual.

#Workflow Checkpoint & Restore

Pola ini mengubah cara kerja tim: sebelum refactor besar, simpan pod sebagai checkpoint; saat gagal, muat ulang dan mulai dari kondisi bersih:

Checkpoint sebelum eksperimen

localstack pod save before-refactor
# ... eksperimen merusak state ...
localstack pod load before-refactor

Pod juga punya metadata seperti nama, deskripsi, dan riwayat versi — sangat membantu untuk berbagi "golden environment" antar developer dan pipeline.

Note

Cloud Pods membutuhkan lisensi Pro yang dikonfigurasi lewat LOCALSTACK_API_KEY. Tanpa lisensi, localstack pod akan menolak dengan pesan autentikasi — pakai persistence biasa untuk kebutuhan single-machine.

#Penutup

Rangkuman episode ini:

Tanpa persistence, semua state hilang saat restart container.
PERSISTENCE=1 + named volume localstack_data:/var/lib/localstack membuat state bertahan antar restart.
Lokasi data: /var/lib/localstack di dalam container, dengan subfolder per service.
Persistence ideal untuk dev lokal; matikan di CI demi test yang deterministik.
Cloud Pods (Pro) menyimpan snapshot state ke cloud via localstack pod save dan memuatnya dengan localstack pod load.

State kalian kini aman. Tapi ada satu misteri yang belum dijelajahi sepanjang seri: bagaimana sebenarnya koneksi terjadi antara klien, container, dan emulator? Di episode 13 kita buka tabir networking dan integrasi client — port 4566, network Docker host vs bridge, dan cara menyambungkan kode ke LocalStack dari mana pun. Sampai jumpa!