Menjalankan Redis

Tiga chapter terakhir memainkan variasi di atas satu tema: database relasional dengan tabel, baris, dan bahasa SQL. Redis menolak masuk ke keluarga itu sama sekali — ia adalah penyimpan pasangan kunci-nilai yang bekerja sepenuhnya di memori, tanpa skema, tanpa join, dan tanpa SQL. Posisinya di arsitektur aplikasi pun berbeda: Redis jarang menjadi rumah utama data, melainkan menjadi lapisan cepat di sampingnya — cache hasil kueri, keranjang belanja sesi, hitungan pengunjung, antrian pekerjaan ringan. Justru karena perannya yang istimewa itu Redis wajib hadir di section ini: ia mengajarkan dua hal yang tidak diajarkan database relasional, yaitu disiplin batas memori pada data yang hidup di RAM, dan konfigurasi image yang sama sekali tidak lewat environment variable. Container kita bernama cache — nama yang menegaskan perannya, bukan mesinnya.

Menyalakan cache #

Perintah pembuka kita jauh lebih pendek dari tiga pendahulunya, karena Redis memang tidak menuntut user, password, ataupun database awal:

$ docker run -d --name cache -v cache-data:/data redis:7-alpine

Output yang Dihasilkan:

Unable to find image 'redis:7-alpine' locally
7-alpine: Pulling from library/redis
...
Digest: sha256:aab90c4894d7887e4686056dd427a63c00f0ee664b5489e099a4a843f6dd50e6
Status: Downloaded newer image for redis:7-alpine
37ee3e9a1c765d5781088f9e3ce2f4abceeca734accae27f19f7dbce5e176f39

Varian 7-alpine belum pernah dipakai di mesin cerita kita — image redis:7 yang dulu menemani Section Dasar Docker CLI adalah varian Debian — sehingga daemon menariknya lebih dulu; baris-baris layer di tengah dipotong agar ringkas. Mari kita telaah dua bagian yang ada:

1. -v cache-data:/data — volume bernama dipasang di /data, direktori kerja resmi image redis; inilah satu-satunya titik tempat Redis menyentuh disk, dan kita butuhkan saat bicara persistensi di bagian akhir.
2. redis:7-alpine — seri 7 varian Alpine yang ramping; seri 8 juga tersedia, tetapi seri 7 dipilih Course ini karena stabil dan paling banyak dipakai di lapangan.

Log startup-nya singkat, format yang sudah kita kenal sejak Chapter Melihat Log Container:

$ docker logs cache

Output yang Dihasilkan:

1:C 13 Oct 2026 21:18:02.411 # oO0O oO0O Redis is starting oO0O oO0O
...
1:M 13 Oct 2026 21:18:02.415 * Running mode=standalone, port: 6379.
1:M 13 Oct 2026 21:18:02.416 * Server initialized
1:M 13 Oct 2026 21:18:02.417 * Ready to accept connections tcp

Satu baris versi beserta peringatan konfigurasi kernel dipotong agar ringkas. Kalimat penutupnya adalah sinyal siap yang kita cari: Ready to accept connections tcp. Cara tercepat memverifikasinya sudah kita kenal — ketukan ping:

$ docker exec cache redis-cli ping

Output yang Dihasilkan:

PONG

Satu kata PONG menegaskan bahwa server hidup dan menjawab — pasangan ping/PONG inilah bahan healthcheck paling populer untuk Redis, padanan pg_isready dan mysqladmin ping.

Sesi redis-cli #

Kunci kunjungan yang kita tanam di Section Dasar Docker CLI menjadi titik berangkat yang pas — kali ini kita ajak bermain lebih jauh lewat sesi interaktif redis-cli, pola docker exec -it yang sudah akrab:

$ docker exec -it cache redis-cli

Output yang Dihasilkan:

127.0.0.1:6379> SET kunjungan 1
OK
127.0.0.1:6379> INCR kunjungan
(integer) 2
127.0.0.1:6379> GET kunjungan
"2"
127.0.0.1:6379> TTL kunjungan
(integer) -1
127.0.0.1:6379> SETEX keranjang 300 "Kopi Torabika x2"
OK
127.0.0.1:6379> TTL keranjang
(integer) 296
127.0.0.1:6379> exit

Prompt 127.0.0.1:6379 di tiap baris adalah prompt redis-cli beserta ketikan kita; jawaban server tampil di baris di anteranya. Mari kita telaah perintah-perintahnya:

1. SET kunjungan 1 — menanam kunci bernama kunjungan bernilai string 1; jawaban OK adalah konfirmasi standar Redis untuk perintah tulis yang sukses.
2. INCR kunjungan — menaikkan nilai kunci secara atomik menjadi (integer) 2; satu perintah ini menggantikan rangkaian baca-ubah-tulis yang rawan balapan pada database relasional — inilah pola penghitung kunjungan klasik Redis.
3. GET kunjungan — membaca kembali nilainya; tanda kutip pada "2" adalah gaya redis-cli untuk nilai bertipe string.
4. TTL kunjungan dengan jawaban -1 — sisa umur kunci; -1 berarti kunci ini tidak punya batas waktu dan akan hidup selama memorinya hidup.
5. SETEX keranjang 300 "Kopi Torabika x2" — menanam kunci sekaligus memasang kedaluwarsa 300 detik; jawaban TTL yang menyusulnya terbaca 296 karena empat detik sudah terpakai sejak penciptaan — angkanya akan terus turun bila diukur ulang, dan begitu mencapai nol, Redis memusnahkan keranjang itu diam-diam tanpa meninggalkan bekas. Umur terbatas inilah yang membuat pola SETEX pas untuk sesi dan token.

Konfigurasi lewat Argumen, Bukan Environment #

Di sinilah Redis memisahkan diri dari tiga chapter sebelumnya. Image resminya tidak menyediakan variabel konfigurasi khusus — tidak ada REDIS_PASSWORD yang dibaca entrypoint, tidak ada padanan POSTGRES_DB. Konfigurasinya dituang lewat dua jalur resmi Redis: berkas redis.conf, atau argumen baris perintah yang diserahkan kepada redis-server.

Mari kita buktikan dengan kebutuhan paling realistis: kata sandi. Container lama kita buang dulu, lalu container baru lahir dengan satu argumen tambahan:

$ docker rm -f cache
$ docker run -d --name cache -v cache-data:/data redis:7-alpine \
    redis-server --requirepass rahasia123

Output yang Dihasilkan:

cache
757359193aee4e987fc4f07e910b84b3dc3f85fc08c3988a41df766d8d5173ce

Baris pertama adalah konfirmasi docker rm -f; baris kedua adalah ID container baru. Perhatikan bahwa seluruh argumen setelah nama image — redis-server --requirepass rahasia123 — menggantikan CMD bawaan image, sehingga entrypoint menerima perintah lengkap itu untuk dijalankan. Server yang kini menyala menuntut autentikasi, dan ketukan polos kita ditolak dengan jujur:

$ docker exec cache redis-cli ping

Output yang Dihasilkan:

NOAUTH Authentication required.

Dengan sandi di tangan, pintu terbuka kembali:

$ docker exec cache redis-cli -a rahasia123 ping

Output yang Dihasilkan:

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
PONG

Mari kita telaah tiga keluaran di atas:

1. NOAUTH Authentication required. — jawaban galat server terhadap klien tanpa kredensial; server tetap hidup dan sehat, hanya pintunya yang terkunci.
2. -a rahasia123 pada sisi klien — redis-cli membawa sandi sebagai argumen; peringatannya sendiri jujur bahwa sandi pada baris perintah bisa terbaca, keluhan yang sama dengan klien mysql pada chapter sebelumnya.
3. PONG tetap tercapai — setelah autentikasi, seluruh perintah sesi berjalan seperti biasa; hanya pintu masuknya yang kini bertanya dahulu.

Batas Memori dan Eviksi #

Sifat in-memory membawa konsekuensi yang harus dikelola: data yang hidup di RAM tidak boleh dibiarkan tumbuh tanpa aturan. Redis menyediakan dua argumen redis-server untuk disiplin itu, dan kita pasangkan pada container berikutnya:

$ docker rm -f cache
$ docker run -d --name cache -v cache-data:/data redis:7-alpine \
    redis-server --requirepass rahasia123 \
    --maxmemory 128mb --maxmemory-policy allkeys-lru

Output yang Dihasilkan:

cache
ec4bcb8d8bc7af5408dd835ccabb1ae2f94a67d7bba12a48ad99ea477e6814dd

Argumen bertumpuk rapi di belakang redis-server — satu baris konfigurasi demi satu baris kebutuhan. Keduanya bisa dibuktikan bekerja lewat perintah konfigurasi klien:

$ docker exec cache redis-cli -a rahasia123 CONFIG GET maxmemory

Output yang Dihasilkan:

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
1) "maxmemory"
2) "134217728"

Mari kita telaah dua argumen dan angkanya:

1. --maxmemory 128mb — plafon data Redis sebesar 128 MB; angka 134217728 pada jawaban CONFIG adalah nilai yang sama dalam byte mentah — 128 × 1024 × 1024.
2. --maxmemory-policy allkeys-lru — kebijakan saat plafon tercapai: di antara seluruh kunci, kunci yang paling lama tidak disentuh (least recently used) dibuang lebih dulu untuk memberi ruang; cache memang sepatutnya membuang barang yang paling jarang diambil.
3. Kebijakan bawaan berbeda — tanpa argumen ini Redis memakai noeviction: memori penuh berarti setiap perintah tulis ditolak dengan galat. Pas untuk rumah data utama, keliru untuk cache — kebijakan harus mengikuti peran.

Persistensi ke Volume cache-data #

Memori lenyap saat proses mati, dan justru karena itu Redis menawarkan dua jalan menyentuh disk — keduanya jatuh ke /data, titik yang sejak perintah pertama sudah kita tutup dengan volume cache-data. Jalan pertama adalah snapshot RDB: pada titik-titik tertentu (bawaannya, antara lain, satu perubahan dalam satu jam atau seratus perubahan dalam lima menit), Redis menuliskan seluruh memorinya ke satu berkas dump.rdb; snapshot juga ditulis setiap kali Redis berhenti dengan sopan. Jalan kedua adalah append-only file: argumen --appendonly yes menghidupkan jurnal yang mencatat setiap perintah tulis begitu diterima, sehingga kehilangan data terpangkas hingga ke interval paling kecil — dengan bayaran berkas yang terus tumbuh dan harus dikelola.

Kedua jalan itu bisa kita saksikan tanpa mengubah container saat ini, karena RDB memang sudah aktif secara bawaan. Kita tanam satu kunci, lalu hentikan container dengan sopan:

$ docker exec cache redis-cli -a rahasia123 SET stok:torabika 12
$ docker stop cache

Output yang Dihasilkan:

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
OK
cache

Sinyal SIGTERM dari docker stop memberi Redis masa tenggang untuk bereskan diri — dan riwayatnya tercatat di log:

$ docker logs cache --tail 3

Output yang Dihasilkan:

1:M 13 Oct 2026 21:33:41.100 * Saving the final RDB snapshot before exiting.
1:M 13 Oct 2026 21:33:41.112 * DB saved on disk
1:M 13 Oct 2026 21:33:41.113 * Redis is now ready to exit, bye for now

Tiga baris itu adalah kesaksian snapshot tersimpan sebelum proses pergi. Container yang dijalankan kembali membuktikannya:

$ docker start cache
$ docker exec cache redis-cli -a rahasia123 GET stok:torabika

Output yang Dihasilkan:

cache
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"12"

Mari kita telaah rangkaian penutup ini:

1. "12" terbaca utuh — kunci stok:torabika selamat melewati siklus stop-start karena snapshotnya hidup di dump.rdb pada volume cache-data, bukan di memori yang ikut padam.
2. docker stop, bukan docker rm -f — kesopanan inilah syaratnya; docker rm -f mengirim SIGKILL yang memotong proses tanpa upaya menyimpan, dan pada dua kali pergantian container tadi, kunci kunjungan memang lenyap begitu saja tanpa RDB keselamatan. Data berharga menuntut AOF atau kesopanan mati — idealnya keduanya.
3. docker start tidak mengulang inisialisasi — container yang sama dinyalakan ulang dengan konfigurasi yang sama; tidak ada env yang dibaca ulang, karena memang tidak ada env di sini.

Deretan argumen redis-server yang kita kumpulkan sepanjang chapter dirangkum pada tabel berikut:

Empat mesin database kini berdiri di mesin Budi: PostgreSQL dengan tabel produk, MySQL dan MariaDB dengan katalognya masing-masing, dan Redis dengan kunci-kunci stoknya. Akan tetapi satu pertanyaan besar section ini masih berdiri tanpa jawaban tuntas: benarkah data-data itu bertahan melampaui kematian container yang menampungnya? Volume sudah berkali-kali kita pasang dan klaimnya sudah berkali-kali kita ulang — sekarang saatnya membuktikannya dengan pengadilan paling kejam yang kita kenal: docker rm -f, lalu menjalankan ulang dari nol. Chapter Persistensi Database menyelenggarakan pengadilan itu, membedah isi volume sampai ke berkas fisiknya, dan menutup dengan disiplin reset yang membuat eksperimen berikutnya selalu bisa dimulai bersih.

Referensi #

• Redis — Docker Hub — perilaku image resmi: argumen redis-server, direktori /data, dan pola konfigurasinya.
• Redis Documentation — rujukan perintah redis-cli, kebijakan eviksi maxmemory, serta persistensi RDB dan AOF.
• docker container run — CLI Reference — argumen setelah nama image sebagai command override.
• Resource Constraints — batas memori cgroup yang memayungi maxmemory Redis.