tmpfs dan Storage

Tidak semua data yang dipakai container perlu bertahan lama. Sysadmin/DevOps Engineer yang mengelola aplikasi dengan data sensitif sementara, misalnya token session atau cache yang tidak boleh menyentuh disk, butuh mekanisme penyimpanan yang otomatis hilang begitu container berhenti. Di sisi lain, data yang memang harus tersimpan aman perlu strategi backup yang jelas, apalagi mengingat volume dan bind mount yang sudah dibahas sebelumnya sama-sama rentan hilang kalau host bermasalah. Bab ini membahas tmpfs mount sebagai opsi penyimpanan sementara di memori, cara kerja storage driver yang menopang filesystem image dan container, perbandingan karakteristik penyimpanan persisten versus temporer, sampai praktik backup dan recovery data volume secara langsung.

12.1 tmpfs Mounts

tmpfs mount adalah jenis mount yang menyimpan data langsung di memori (RAM) host, bukan di disk. Data yang ditulis ke tmpfs mount hilang total begitu container berhenti, karena memang tidak pernah tersimpan ke media fisik mana pun.

12.1.1 Cara Kerja tmpfs

Saat sebuah tmpfs mount dipasang ke container, Linux kernel mengalokasikan sebagian RAM sebagai filesystem sementara yang hanya terlihat oleh container tersebut. Sifatnya mirip volume dalam hal terpisah dari filesystem image, tapi berbeda total soal daya tahan datanya: volume dan bind mount tetap ada di disk host meski container dihapus, sementara isi tmpfs mount lenyap begitu container yang memakainya berhenti atau restart.

Karakteristik ini membuat tmpfs cocok untuk data yang memang tidak boleh bertahan lama, misalnya file lock sementara, cache runtime, atau data sensitif seperti token dan kredensial yang sengaja tidak ingin disimpan permanen di disk demi alasan keamanan. tmpfs mount hanya didukung saat Docker Engine berjalan di host Linux; Docker Desktop di Windows dan macOS menjalankan Linux VM di baliknya, sehingga tmpfs tetap berfungsi normal untuk container Linux, tapi tidak berlaku untuk container Windows karena Windows tidak mengenal konsep tmpfs.

12.1.2 Membuat tmpfs Mount

Docker menyediakan dua cara memasang tmpfs, sama seperti bind mount: opsi --tmpfs yang ringkas, dan opsi --mount yang lebih eksplisit lewat pasangan key=value.

docker run -d --name demo-tmpfs --tmpfs /app/cache alpine sleep 3600

Perintah di atas memasang tmpfs kosong ke path /app/cache di dalam container. Verifikasi lewat docker inspect untuk memastikan mount tipe tmpfs benar-benar terpasang.

docker inspect --format '{{json .Mounts}}' demo-tmpfs

Untuk sintaks yang lebih eksplisit, gunakan --mount dengan type=tmpfs.

docker run -d --name demo-tmpfs2 --mount type=tmpfs,dst=/app/cache alpine sleep 3600

Cara paling langsung membuktikan sifat sementara tmpfs adalah menulis file ke dalamnya, lalu restart container dan periksa lagi isinya.

docker exec demo-tmpfs sh -c "echo data-sementara > /app/cache/test.txt && cat /app/cache/test.txt"
docker restart demo-tmpfs
docker exec demo-tmpfs ls /app/cache

Direktori /app/cache akan kosong setelah restart, membuktikan data yang ditulis ke tmpfs benar-benar tidak bertahan melewati siklus hidup container.

12.1.3 Opsi Ukuran dan Mode tmpfs

Karena tmpfs memakai RAM host secara langsung, batasi ukurannya supaya satu container tidak menghabiskan seluruh memori host hanya lewat tulisan ke tmpfs. Kalau opsi ukuran tidak ditentukan, batas maksimum default sebuah tmpfs mount adalah 50% dari total RAM host, sesuai dokumentasi resmi Docker.

docker run -d --name demo-tmpfs3 --tmpfs /app/cache:size=64m,mode=1770 alpine sleep 3600

Opsi size membatasi kapasitas tmpfs dalam byte (bisa juga pakai sufiks seperti k, m, g), sementara mode menentukan permission filesystem dalam notasi octal, mirip permission Unix biasa. Lewat --mount, opsi yang setara ditulis sebagai tmpfs-size (dalam byte) dan tmpfs-mode.

docker run -d --name demo-tmpfs4 --mount type=tmpfs,dst=/app/cache,tmpfs-size=67108864,tmpfs-mode=1770 alpine sleep 3600

Opsi tambahan lain seperti noexec (mencegah eksekusi binary di dalam mount) atau uid/gid (menentukan owner tmpfs) juga tersedia lewat --tmpfs, berguna kalau ingin membatasi tmpfs hanya sebagai area penyimpanan data, bukan tempat menjalankan program. Perlu dicatat, tmpfs mount tidak bisa dipakai bersama (di-share) antar beberapa container sekaligus seperti halnya named volume, karena tmpfs memang didesain sebagai penyimpanan lokal khusus satu container.

Trustworthiness penting ditekankan di sini: data yang tersimpan di tmpfs tetap dihitung sebagai bagian dari batas memori container (opsi --memory). Menaikkan tmpfs-size tidak menambah jatah RAM container sama sekali, sekadar menaikkan batas atas tmpfs itu sendiri. Kalau data yang ditulis ke tmpfs sampai memenuhi batas memori container, proses di dalamnya bisa langsung dihentikan paksa oleh mekanisme OOM (out-of-memory) kernel Linux. Pastikan batas tmpfs-size dan batas memori container sudah diperhitungkan bersama-sama, terutama untuk aplikasi yang menulis data dalam volume besar ke tmpfs.

12.2 Storage Drivers

Storage driver adalah komponen di Docker Engine yang mengatur cara image layer dan writable layer container disimpan serta dikelola di filesystem host. Storage driver bekerja di balik layar setiap kali container dibuat, tapi memahami cara kerjanya penting untuk Sysadmin/DevOps Engineer yang perlu mendiagnosis masalah performa atau kapasitas disk di production.

12.2.1 Peran Storage Driver dalam Docker

Setiap image Docker tersusun dari beberapa layer read-only yang ditumpuk. Saat sebuah container dijalankan, Docker menambahkan satu writable layer di atas seluruh layer image tersebut, tempat semua perubahan (file baru, modifikasi, penghapusan) selama container berjalan disimpan. Storage driver bertanggung jawab menyatukan seluruh layer read-only dan writable layer itu menjadi satu filesystem terpadu yang terlihat oleh proses di dalam container, memakai teknik union filesystem.

Kalau container yang sama dihapus, writable layer miliknya ikut terhapus, sementara layer image yang read-only tetap ada dan bisa dipakai ulang container lain yang berasal dari image sama. Prinsip inilah yang membuat banyak container bisa berbagi layer image yang identik tanpa duplikasi data, sehingga image dengan base yang sama menghemat ruang disk secara signifikan.

12.2.2 overlay2 sebagai Driver Default

Docker Engine di Linux mendukung beberapa storage driver, di antaranya overlay2, fuse-overlayfs, btrfs, dan zfs. Menurut dokumentasi resmi Docker, overlay2 adalah storage driver yang direkomendasikan untuk seluruh distribusi Linux yang didukung saat ini dan dipilih secara default kalau kernel host memenuhi syaratnya, menggantikan driver lama seperti aufs atau devicemapper yang dipakai di versi Docker lampau. Kecuali ada alasan kuat untuk memakai driver lain, overlay2 sebaiknya tetap dipakai.

Di Windows, Docker Engine hanya mendukung storage driver windowsfilter, sehingga pembahasan pemilihan storage driver di atas hanya relevan untuk host Linux tempat Docker Engine (termasuk Docker Desktop yang menjalankan Linux VM di baliknya) berjalan.

12.2.3 Memeriksa dan Mengganti Storage Driver

Periksa storage driver yang sedang dipakai Docker Engine lewat docker info, cari baris Storage Driver dan Backing Filesystem pada outputnya.

docker info

Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true

Kalau memang perlu mengganti storage driver, misalnya karena kebutuhan khusus infrastruktur, tentukan lewat key storage-driver di file /etc/docker/daemon.json.

{
  "storage-driver": "overlay2"
}

Setelah mengubah daemon.json, restart Docker daemon supaya konfigurasi baru dipakai. Docker akan menolak start kalau isi daemon.json tidak valid secara sintaks JSON, jadi pastikan format file benar sebelum restart.

sudo systemctl restart docker
docker info | grep "Storage Driver"

Perlu ditekankan soal risikonya: mengganti storage driver membuat Docker Engine kehilangan akses ke seluruh image dan container yang tersimpan dengan driver lama, karena struktur penyimpanan layer antar driver tidak kompatibel satu sama lain. Backup data penting dan catat daftar image yang dipakai sebelum mengganti storage driver di environment production, supaya tidak kehilangan data secara tidak sengaja.

12.3 Persistent vs Temporary Storage

Setelah memahami volume, bind mount, dan tmpfs mount, langkah berikutnya adalah memilih jenis penyimpanan yang tepat sesuai sifat data yang sedang ditangani. Kesalahan paling umum di lapangan adalah menyimpan data yang seharusnya persisten (misalnya data database) di lokasi yang sifatnya sementara, atau sebaliknya menyimpan cache sementara di volume yang justru menambah beban I/O disk tanpa perlu.

12.3.1 Memilih Jenis Penyimpanan yang Tepat

Pertimbangan utama dalam memilih jenis penyimpanan adalah seberapa lama data tersebut perlu bertahan, dan siapa (Docker atau host) yang seharusnya mengelola lokasi fisiknya.

Di lapangan, Sysadmin/DevOps Engineer biasanya menggabungkan ketiganya dalam satu deployment: volume untuk data database yang wajib persisten, bind mount untuk file konfigurasi yang dikelola dari host, dan tmpfs untuk direktori cache atau session store yang memang tidak perlu tersimpan permanen. Kombinasi ini menjaga data penting tetap aman sekaligus menghindari penulisan yang tidak perlu ke disk untuk data yang sifatnya sekali pakai.

12.4 Data Backup dan Recovery

Volume Docker memang bertahan melewati siklus hidup container, tapi tetap saja hanya berada di satu host tertentu. Kalau disk host tersebut rusak atau host itu sendiri hilang, seluruh data di volumenya ikut hilang tanpa cara mengembalikannya, kecuali sudah ada strategi backup yang berjalan rutin.

12.4.1 Backup Volume dengan Container Sementara

Cara paling umum melakukan backup named volume adalah menjalankan container sementara yang me-mount volume tersebut sekaligus me-mount direktori host sebagai lokasi penyimpanan hasil backup, lalu mengarsipkan isi volume lewat tar.

docker run --rm \
  -v app-data:/data \
  -v $(pwd)/backup:/backup \
  alpine tar czf /backup/app-data-backup.tar.gz -C /data .

Perintah ini memasang volume app-data ke path /data, memasang direktori backup di host ke /backup, lalu menjalankan tar untuk mengompresi seluruh isi /data menjadi satu file arsip yang tersimpan langsung di host lewat bind mount. Opsi --rm memastikan container sementara ini otomatis terhapus begitu proses backup selesai, karena memang tidak perlu dipertahankan.

12.4.2 Restore Data dari Backup

Proses restore memakai pola serupa, hanya dibalik arah operasinya: ekstrak file arsip dari host langsung ke dalam volume tujuan.

docker volume create app-data-restored
docker run --rm \
  -v app-data-restored:/data \
  -v $(pwd)/backup:/backup \
  alpine tar xzf /backup/app-data-backup.tar.gz -C /data

Trustworthiness penting ditekankan di sini: perintah tar xzf di atas menimpa isi direktori /data pada volume tujuan tanpa konfirmasi apa pun. Kalau volume tujuan bukan volume baru dan sudah berisi data lain, proses restore ini berpotensi menimpa atau bercampur dengan data yang sudah ada. Pastikan volume tujuan memang benar-benar kosong atau memang dimaksudkan untuk ditimpa sebelum menjalankan perintah restore di production.

12.4.3 Verifikasi Integritas Backup

Backup yang tidak pernah diuji restore-nya sama saja dengan tidak punya backup, karena baru terlihat rusak atau tidak lengkap justru saat benar-benar dibutuhkan dalam kondisi darurat. Verifikasi isi file arsip tanpa perlu mengekstraknya penuh lewat opsi -t pada tar, untuk memastikan struktur arsip tidak rusak.

docker run --rm -v $(pwd)/backup:/backup alpine tar tzf /backup/app-data-backup.tar.gz

Bandingkan juga daftar isi volume hasil restore dengan volume aslinya, memastikan jumlah file dan strukturnya konsisten sebelum volume hasil restore benar-benar dipakai menggantikan volume production.

docker run --rm -v app-data:/data alpine ls -la /data
docker run --rm -v app-data-restored:/data alpine ls -la /data

Di lapangan, praktik backup volume idealnya dijadwalkan otomatis secara rutin (misalnya lewat cron di host yang menjalankan perintah backup di atas), disimpan di lokasi terpisah dari host production seperti object storage eksternal, dan diuji proses restore-nya secara berkala, bukan hanya diandalkan sekali saat volume dibuat pertama kali.