Docker Mount: Volumes, Bind Mounts, dan tmpfs Dijelaskan

Jadi Anda baru saja menghentikan container Docker untuk memperbarui file konfigurasi, tetapi saat menyalakannya kembali, semua data hilang. Saya pun pernah mengalaminya.

Ini terjadi karena container bersifat ephemeral secara default – saat dihapus, seluruh data yang disimpan di layer writable di dalamnya akan hilang. Aplikasi nyata tidak bisa bekerja seperti itu. Anda membutuhkan database yang persisten, file konfigurasi yang tetap ada setelah restart, dan log yang benar-benar bisa Anda akses.

Docker mount menyelesaikan masalah ini dengan menghubungkan penyimpanan container ke lokasi eksternal. Ada tiga jenis: volumes untuk data produksi, bind mounts untuk alur kerja pengembangan, dan tmpfs untuk file sementara yang disimpan di memori.

Dalam artikel ini, saya akan memandu Anda memilih jenis mount yang tepat untuk kasus penggunaan Anda dan mengimplementasikannya dengan benar. Untuk memahami semua yang dibahas, Anda perlu pemahaman yang cukup tentang Docker dan kontainerisasi. Ikuti kursus Intermediate Docker kami untuk cepat mengejar ketertinggalan.

Bagaimana Docker Menangani Penyimpanan

Container Docker menggunakan filesystem berlapis yang memperlakukan semuanya sebagai sementara secara default.

Saat Anda membangun image Docker, setiap instruksi di Dockerfile membuat layer baru yang hanya-baca. Layer-layer ini ditumpuk satu sama lain seperti setumpuk kartu. Jika Anda menarik image Ubuntu dengan Python terpasang, Anda akan mendapatkan satu layer untuk OS dasar dan satu lagi untuk Python.

Masalahnya adalah semua layer ini bersifat hanya-baca. Anda tidak dapat mengubahnya.

Filesystem container dan layer writable

Saat Anda memulai container, Docker menambahkan satu layer lagi di atasnya - yaitu layer container yang dapat ditulis (writable).

Di sinilah semua perubahan terjadi. Setiap file yang Anda buat, konfigurasi yang Anda ubah, dan catatan tabel yang Anda tambahkan berada di sini.

Kedengarannya bagus, tetapi masalahnya layer ini terikat pada siklus hidup container.

Saat Anda menghentikan dan menghapus container dengan docker rm, layer writable hilang. Semua yang telah Anda kerjakan lenyap. Docker tidak akan meminta konfirmasi. Ia langsung menghapus semuanya.

Desain ini masuk akal untuk aplikasi stateless yang tidak perlu mengingat apa pun antar-run. Namun aplikasi nyata bukanlah stateless.

Mengapa mount diperlukan

Layer writable memiliki dua masalah besar untuk lingkungan produksi.

Pertama, Anda kehilangan data saat container berhenti. Apa gunanya container database yang melupakan semua baris setelah restart? Saya tidak kepikiran selain untuk menjalankan pengujian integrasi aplikasi Anda.

Kedua, Anda tidak bisa berbagi data antar-container. Misalnya Anda menjalankan aplikasi web dan worker latar belakang yang keduanya perlu mengakses file yang sama. Jika file-file itu berada di layer writable salah satu container, container lain tidak bisa melihatnya.

Docker mount menyelesaikan kedua masalah dengan menghubungkan container ke penyimpanan yang berada di luar siklus hidup container. Anda bisa me-mount direktori dari mesin host atau volume yang dikelola Docker. Data Anda tetap ada bahkan saat container dihapus. Beberapa container dapat me-mount lokasi yang sama dan berbagi file secara real-time.

Itulah alasan Anda perlu menggunakan mount. Mari kita bahas jenis-jenis mount berikutnya, lalu saya tunjukkan cara kerjanya.

Sekilas Tentang Jenis Mount Docker

Docker menyediakan tiga cara untuk menangani data persisten, dan masing-masing memecahkan masalah berbeda. Berikut fungsi tiap jenis dan kapan Anda harus menggunakannya.

Volumes

Volumes adalah jawaban default Docker untuk penyimpanan persisten.

Docker membuat dan mengelola volumes untuk Anda di direktori khusus pada mesin host. Anda tidak perlu tahu di mana direktori itu berada, semuanya ditangani untuk Anda. Ini membuat volumes portabel lintas sistem dan aman digunakan di produksi.

Saat Anda menghapus container, volume tetap utuh. Jika Anda memulai container baru dan melampirkan volume yang sama, semua data Anda akan persis seperti sebelumnya.

Volumes paling cocok untuk database produksi, state aplikasi, dan data apa pun yang tidak boleh hilang.

Bind mounts

Bind mounts menghubungkan direktori spesifik di mesin host Anda langsung ke container.

Anda memilih path tepat di host - seperti /home/user/project - dan Docker memetakkannya ke dalam container. Saat Anda mengubah file di host, container akan melihat perubahan itu seketika. Ubah file di container, dan perubahannya muncul di host Anda.

Sinkronisasi real-time ini membuat bind mounts sangat ideal untuk pengembangan.

Namun bind mounts memiliki risiko. Mereka mengekspos path host ke container dan bergantung pada struktur direktori spesifik yang mungkin tidak ada di mesin lain.

tmpfs mounts

tmpfs mounts menyimpan data di memori host Anda alih-alih di disk.

Tidak ada yang ditulis ke filesystem. Saat container berhenti, datanya menghilang sepenuhnya. Ini membuat tmpfs berguna untuk data sementara yang tidak ingin Anda persistensikan - seperti token autentikasi, data sesi, atau file cache yang akan Anda bangun ulang juga.

Meski begitu, tmpfs dibatasi oleh RAM yang tersedia dan hanya berfungsi di host Linux.

Docker Volumes untuk Data Persisten

Volumes adalah solusi penyimpanan siap produksi dari Docker, dan Anda sebaiknya menggunakannya secara default kecuali ada alasan spesifik untuk tidak melakukannya.

Volume sepenuhnya dikelola oleh Docker, bekerja konsisten lintas platform, dan secara desain tetap ada meskipun container dihapus. Jika Anda menjalankan database, menyimpan state aplikasi, atau menangani data apa pun yang harus bertahan lebih lama dari satu container, volumes adalah jawabannya.

Cara kerja Docker volume

Docker menyimpan volumes di direktori khusus pada mesin host Anda:

• Linux: /var/lib/docker/volumes/
• macOS: ~/Library/Containers/com.docker.docker/Data/vms/0/data/
• Windows: \\wsl$\docker-desktop-data\data\docker\volumes\, dengan asumsi backend WSL2

Anda tidak mengelola direktori ini secara langsung. Docker menangani pembuatan, izin, dan pembersihan melalui API-nya. Pemisahan ini berarti volumes bekerja sama apakah Anda di Linux, Mac, atau Windows, yang pada gilirannya membuat setup container Anda portabel antara lingkungan pengembangan dan produksi.

Hal yang perlu diingat adalah volume ada secara independen dari container mana pun. Saat Anda membuat volume, melampirkannya ke container, menjalankan aplikasi, lalu menghentikan dan menghapus container itu, volume tetap berada di tempatnya dengan semua data Anda utuh.

Jika Anda memulai container baru dan melampirkan volume yang sama, data Anda tetap ada.

Membuat dan memakai ulang volume

Anda bisa membuat volume bernama sebelum memulai container apa pun:

docker volume create mydata

Lalu lampirkan saat Anda menjalankan container menggunakan flag --mount:

docker run -d \
  --name postgres-db \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Ini me-mount volume mydata ke /var/lib/postgresql/data di dalam container, tempat Postgres menyimpan file database-nya.

Sekarang Anda bisa menghentikan dan menghapus container ini, lalu memulai yang baru dengan volume yang sama:

docker rm -f postgres-db

docker run -d \
  --name postgres-db-new \
  --mount source=mydata,target=/var/lib/postgresql/data \
  postgres:18

Database Anda kembali dengan semua tabel dan baris utuh.

Itulah inti volumes - persistensi data lintas siklus hidup container.

Mengelola dan memelihara data volume

Anda bisa menjalankan perintah ini untuk memeriksa volume apa yang ada di sistem Anda:

docker volume ls

Lalu, Anda bisa menjalankan perintah ini untuk memeriksa volume tertentu guna melihat di mana disimpan dan container mana yang menggunakannya:

docker volume inspect mydata

Ini menampilkan titik mount di host dan metadata yang berguna. Namun Anda jarang perlu mengakses direktori ini secara langsung - itu tugas Docker.

Jika Anda sudah selesai dengan volume dan ingin menghapusnya, jalankan perintah ini:

docker volume rm mydata

Docker tidak akan membiarkan Anda menghapus volume yang terpasang ke container yang berjalan. Hentikan container terlebih dahulu, lalu hapus volumenya.

Terakhir, jika Anda ingin membersihkan sumber daya dan mengklaim kembali ruang disk, Anda bisa menjalankan perintah ini untuk menghapus semua volume yang tidak digunakan sekaligus:

docker volume prune

Untuk setup produksi, Docker mendukung volume driver yang terhubung ke sistem penyimpanan eksternal seperti NFS, AWS EFS, atau cloud block storage. Anda menentukan driver saat membuat volume, dan Docker menangani sisanya. Ini memungkinkan Anda menyimpan data sepenuhnya di luar mesin host, yang penting untuk setup high-availability di mana container berpindah antarserver.

Selanjutnya, mari bahas bind mounts.

Bind Mounts untuk Pengembangan Lokal

Bind mounts memberi Anda akses langsung ke filesystem host dari dalam container, dan itulah alasan pengembang menyukainya.

Mereka sangat cocok untuk pengembangan lokal tetapi memiliki kompromi yang membuatnya berisiko untuk produksi. Anda mendapatkan sinkronisasi file real-time dan tanpa langkah build, tetapi kehilangan portabilitas dan bisa membuka celah keamanan.

Cara kerja bind mounts

Bind mount memetakan direktori spesifik pada mesin host Anda langsung ke container.

Anda menentukan path tepat - seperti /home/user/myapp - dan Docker membuatnya tersedia pada path di dalam container. Tidak ada penyalinan, tidak ada penyimpanan yang dikelola Docker, tidak ada lapisan abstraksi. Container melihat file host Anda yang sebenarnya.

Jika Anda mengubah file di host, container langsung melihat perubahannya. Demikian pula, jika Anda mengubah file di dalam container, itu akan terbarui di host Anda. Kedua sisi bekerja dengan file yang sama secara real-time.

Berikut contoh bind mount saat digunakan:

docker run -d \
  --name dev-app \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  python:3.14

Ini me-mount /Users/dradecic/Desktop/app dari host saya ke /app di dalam container. Saat saya mengedit file Python di /Users/dradecic/Desktop/app menggunakan editor teks Anda, aplikasi yang dikontainerkan langsung melihat perubahannya.

Anda juga dapat menggunakan sintaks yang lebih pendek:

Alur kerja pengembangan umum

Kasus penggunaan paling umum adalah me-mount kode sumber Anda selama pengembangan.

Misalnya Anda membangun aplikasi FastAPI. Anda dapat me-mount direktori proyek ke container, mengaktifkan hot reload, dan Anda memiliki lingkungan pengembangan lengkap:

docker run -d \
  --name fastapi-dev \
  --mount type=bind,source=/Users/dradecic/Desktop/app,target=/app \
  -w /app \
  -p 8000:8000 \
  python:3.14 \
  sh -c "pip install fastapi uvicorn && uvicorn main:app --reload --host 0.0.0.0"

Sebagai referensi, berikut file main.py saya:

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(
    title="FastAPI Docker Demo",
    description="A minimal FastAPI app running inside Docker",
    version="1.0.0",
)

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool = True

@app.get("/")
def read_root():
    return {
        "message": "FastAPI is running",
        "docs": "/docs",
        "redoc": "/redoc",
    }

@app.get("/health")
def health_check():
    return {"status": "ok"}

@app.post("/items")
def create_item(item: Item):
    return {
        "message": "Item received",
        "item": item,
    }

Setelah menjalankan perintah Docker, aplikasi tersedia dari mesin host saya pada port 8000:

Jika Anda mengedit main.py di editor Anda, simpan file, FastAPI akan memuat ulang secara otomatis. Tidak perlu rebuild image, tidak perlu restart container. Anda menulis kode seperti biasa secara lokal, tetapi aplikasi berjalan di lingkungan container yang konsisten.

Risiko dan keterbatasan

Bind mounts mengekspos filesystem host Anda ke container, dan itu dapat menimbulkan masalah keamanan.

Container dengan bind mount dapat membaca dan menulis file di host Anda. Menjalankan container sebagai root - defaultnya - memberi akses root ke file-file yang di-mount tersebut. Kode berbahaya atau container yang dikompromikan dapat memodifikasi atau menghapus apa pun di direktori yang di-mount.

Portabilitas juga menjadi masalah.

Bind mounts bergantung pada path tertentu yang ada di host. Path /Users/dradecic/Desktop/app tidak ada di mesin Anda atau di server produksi. Ini merusak janji "berfungsi di mana saja" dari container.

Perbedaan platform juga ada. Windows dan Mac menggunakan VM untuk menjalankan Docker, jadi bind mounts melewati lapisan translasi ekstra. Ini membuat operasi file lebih lambat dan dapat menyebabkan bug halus pada file watching dan symlink.

Lingkungan produksi tidak boleh menggunakan bind mounts.

Mereka terlalu bergantung pada path spesifik host, terlalu berisiko dari sisi keamanan, dan mustahil dikendalikan versinya. Volumes menyelesaikan semua masalah ini, itulah mengapa mereka menjadi standar produksi.

Perlakukan bind mounts sebagai alat pengembangan - cepat, praktis, dan kuat, tetapi bukan sesuatu yang Anda inginkan di dekat produksi.

tmpfs Mounts untuk Data Sementara

tmpfs mounts menyimpan data di RAM host alih-alih di disk. Ini membuatnya sempurna untuk data yang tidak ingin Anda persistensikan.

Perilaku penyimpanan di memori

Mount tmpfs sepenuhnya ada di memori.

Docker mengalokasikan RAM di mesin host Anda dan menyediakannya sebagai filesystem di dalam container. File yang ditulis ke mount tmpfs tidak pernah menyentuh disk. Data berada di memori hingga container berhenti.

Saat Anda menghentikan container, semua yang ada di mount tmpfs dihapus. Tidak diperlukan pembersihan, tidak ada file sisa, tidak ada jejak apa pun yang ada di sana. Setiap kali Anda memulai ulang container, Anda mendapatkan mount tmpfs yang baru dan kosong.

Singkatnya, tmpfs untuk data yang secara eksplisit tidak ingin Anda simpan - perhitungan sementara, token sesi, atau informasi sensitif yang tidak boleh bertahan setelah digunakan.

Kasus penggunaan khas

Kasus paling umum adalah menyimpan secret atau data sensitif.

Misalnya Anda menjalankan container yang membutuhkan API key atau kata sandi database. Simpan di mount tmpfs, dan secret tidak akan pernah disimpan di disk. Saat container berhenti, secret menghilang dari memori. Tidak ada file yang secara tidak sengaja dikomit ke version control atau tertinggal di filesystem.

Cache juga cocok. Artefak build, kode terkompilasi, atau dependensi yang diunduh yang akan Anda hasilkan kembali tidak perlu dipersistensikan. Taruh di tmpfs untuk akses yang lebih cepat selama masa hidup container, lalu biarkan hilang saat Anda selesai.

File sementara juga cocok di sini - seperti data sesi, lock file, atau hasil pemrosesan intermediate yang hanya penting saat container berjalan.

Konfigurasi dasar

Jalankan perintah ini untuk membuat mount tmpfs menggunakan flag --tmpfs:

docker run -d \
  --name temp-app \
  --tmpfs /tmp:rw,size=100m \
  python:3.14

Ini membuat mount tmpfs 100MB di /tmp di dalam container. Opsi size membatasi berapa banyak RAM yang dapat digunakan mount tersebut.

Anda juga bisa menggunakan sintaks --mount:

docker run -d \
  --name temp-app \
  --mount type=tmpfs,destination=/tmp,tmpfs-size=104857600 \
  python:3.14

Nilai tmpfs-size dalam byte - 104857600 byte sama dengan 100MB.

Jika Anda tidak menentukan batas ukuran, tmpfs menggunakan hingga setengah RAM sistem Anda. Itu berbahaya - karena alasan yang jelas. Selalu tetapkan batas ukuran eksplisit.

Satu-satunya kelemahan besar adalah bahwa tmpfs mounts hanya berfungsi di Linux.

Docker Desktop untuk Mac dan Windows tidak mendukungnya karena menjalankan Docker di dalam VM Linux, dan tmpfs memerlukan dukungan kernel langsung.

Sintaks dan Konfigurasi Docker Mount

Docker menyediakan dua cara untuk mendefinisikan mount, dan memilih sintaks yang tepat membuat perintah Anda lebih mudah dibaca dan di-debug.

Keduanya bekerja, tetapi satu lebih skalabel saat Anda membutuhkan opsi lanjutan atau beberapa mount dalam satu container.

-mount vs --volume

Flag --mount menggunakan pasangan key-value eksplisit, sedangkan -v atau --volume menggunakan string yang dipisahkan titik dua.

Berikut mount volume yang sama dengan kedua sintaks:

# Using --mount
docker run -d \
  --mount type=volume,source=mydata,target=/app/data \
  python:3.14

# Using -v
docker run -d \
  -v mydata:/app/data \
  python:3.14

Keduanya membuat volume bernama mydata dan me-mount-nya ke /app/data di container.

Gunakan --mount untuk kebutuhan di luar setup dasar. Memang lebih verbose, tetapi key yang eksplisit membuat tiap bagian jelas fungsinya. Saat Anda menambahkan opsi seperti akses read-only atau volume driver kustom, perintah tetap mudah dibaca, sementara -v bisa terlihat seperti string yang membingungkan.

Sintaks -v baik untuk alur kerja pengembangan sederhana di mana Anda mengetik perintah secara manual.

Opsi mount umum

Opsi readonly mencegah container memodifikasi data yang di-mount:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,readonly \
  python:3.14

Ini berguna untuk file konfigurasi atau data referensi yang boleh dibaca tetapi tidak boleh diubah oleh container. Container yang mencoba menulis ke mount readonly akan mendapat error izin.

Untuk volumes, opsi volume-nocopy melewati penyalinan data yang sudah ada dari image container ke dalam volume:

docker run -d \
  --mount type=volume,source=mydata,target=/app/data,volume-nocopy \
  python:3.14

Secara default, Docker menyalin apa pun yang ada pada titik mount di image ke volume baru. Saat Anda menetapkan volume-nocopy, Anda mendapatkan volume kosong terlepas dari apa yang ada di image.

Untuk tmpfs, opsi tmpfs-size menetapkan batas memori:

docker run -d \
  --mount type=tmpfs,target=/tmp,tmpfs-size=104857600 \
  python:3.14

Ini membatasi mount tmpfs di 100MB. Tanpanya, mount tmpfs bisa mengonsumsi seluruh RAM yang tersedia.

Mount di atas data yang sudah ada

Saat Anda me-mount ke direktori yang sudah ada di image container, mount sepenuhnya menyembunyikan apa pun yang ada di sana.

Misalnya image Anda memiliki direktori /app/data dengan file konfigurasi bawaan. Saat Anda me-mount volume ke /app/data, file konfigurasi tersebut akan menghilang. Container hanya melihat apa yang ada di volume.

Ini terjadi pada semua jenis mount - volumes, bind mounts, dan tmpfs. Konten yang di-mount memiliki prioritas, dan direktori asli tidak dapat diakses selama mount aktif.

Menggunakan Mount dengan Docker Compose

Docker Compose memudahkan untuk mendefinisikan dan berbagi mount di banyak container dalam tumpukan aplikasi Anda.

Alih-alih mengetik perintah docker run yang panjang dengan flag mount, Anda mendeklarasikan semuanya dalam file docker-compose.yml. Saya tunjukkan caranya.

Mendefinisikan volumes dan bind mounts di Compose

Berikut file Compose dengan contoh volume dan bind mount:

services:
  service-1:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - ./code:/app          # Bind mount for development
      - shared:/data         # Named volume shared with worker

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    volumes:
      - shared:/data         # Same volume as service-1

volumes:
  shared:

Key volumes di bawah setiap service mendefinisikan apa yang di-mount. Path relatif seperti ./code membuat bind mount, sementara nama seperti shared merujuk ke volume bernama.

Bagian volumes tingkat atas mendeklarasikan volume bernama yang dibuat dan dikelola Compose. Baik service-1 maupun service-2 me-mount volume shared yang sama, sehingga mereka melihat file yang sama. Tulis file dari satu container, dan container lain bisa langsung membacanya.

Perintah sleep infinity menjaga container tetap berjalan agar Anda bisa exec ke dalamnya - hanya untuk keperluan demonstrasi.

Mempertahankan dan memverifikasi data

Mulai stack Anda dengan docker compose up -d, lalu periksa apakah mount berfungsi:

# Write data to the shared volume from app
docker compose exec service-1 sh -c "echo 'test' > /data/file.txt"

# Read it from worker
docker compose exec service-2 cat /data/file.txt

Jika kedua perintah berhasil, volume Anda telah dikonfigurasi dengan benar.

Sekarang Anda bisa menjalankan perintah ini untuk menghentikan dan menghapus semuanya:

docker compose down

Volume bernama Anda akan tetap ada. Jika Anda memulai stack lagi dengan docker compose up -d, data yang Anda tulis sebelumnya masih ada. Beginilah database bertahan lintas deployment - volume bertahan lebih lama daripada container.

Untuk menghapus volume saat Anda menghentikan stack, tambahkan flag -v:

docker compose down -v

Ini menghapus semua volume yang didefinisikan di file Compose Anda. Gunakan saat Anda menginginkan kondisi bersih.

Mengisi volume dengan data awal

Pola paling umum adalah menggunakan init container terpisah untuk men-seed volume bersama:

services:
  init:
    image: ubuntu:latest
    command: sh -c "mkdir -p /source && echo 'initial data' > /source/seed.txt && cp /source/* /dest/"
    volumes:
      - shared:/dest

  service-1:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

  service-2:
    image: ubuntu:latest
    command: sleep infinity
    depends_on:
      - init
    volumes:
      - shared:/data

volumes:
  shared:

Container init membuat data seed dan menyalinnya ke volume shared, lalu keluar. Baik service-1 maupun service-2 mulai setelahnya dan menemukan data seed siap digunakan.

Compose menangani kompleksitas koordinasi beberapa container dan penyimpanan bersama mereka dalam satu file yang dikendalikan versi.

Performa dan Keamanan Docker Mount

Memilih jenis mount yang salah dapat memperlambat container Anda atau menciptakan celah keamanan yang tidak Anda sadari. Baca bagian ini jika Anda tidak ingin itu terjadi.

Kompromi performa antar jenis mount

Volumes menawarkan performa terbaik di Linux karena disimpan langsung di filesystem host tanpa lapisan translasi.

Di Mac dan Windows, Docker berjalan di dalam VM Linux. Volumes tetap berkinerja baik karena tetap di dalam VM tersebut. Di sisi lain, bind mounts harus menyinkronkan file antara OS host dan VM Linux, yang menambah overhead. Operasi file pada bind mounts bisa jauh lebih lambat di Mac dan Windows dibandingkan Linux native.

tmpfs adalah opsi tercepat untuk operasi baca dan tulis karena semuanya terjadi di RAM. Tidak ada I/O disk, tidak ada overhead filesystem. Namun Anda dibatasi oleh memori yang tersedia, dan data menghilang saat container berhenti.

Jika Anda di Linux dan membutuhkan performa maksimum, gunakan volumes. Jika Anda di Mac atau Windows dan melihat operasi file lambat selama pengembangan, kemungkinan Anda terkena overhead bind mount. Beralihlah ke volumes untuk beban kerja produksi.

Implikasi keamanan dari mount

Setiap mount memberi container akses ke sesuatu di luar filesystem terisolasinya, dan itu menciptakan risiko.

Bind mounts adalah kekhawatiran terbesar. Jika Anda me-mount /home/user ke container, container yang dikompromikan dapat membaca kunci SSH Anda, memodifikasi konfigurasi shell, atau menghapus file di seluruh direktori home Anda. Jalankan container itu sebagai root - defaultnya - dan ia memiliki akses root ke file-file tersebut.

Volumes mengurangi risiko ini karena terisolasi di direktori penyimpanan Docker. Container tidak dapat me-mount path host sembarang melalui volumes. Namun volumes tetap dapat membocorkan data antar-container jika Anda berbagi sembarangan.

tmpfs meminimalkan risiko persistensi - secret yang disimpan di memori menghilang saat container berhenti. Namun mereka tidak melindungi dari serangan runtime di mana container yang dikompromikan membaca secret dari memori.

Aturannya secara umum adalah bahwa mount merusak isolasi container, jadi gunakan dengan hati-hati.

Praktik terbaik untuk mount yang aman

Mount hanya apa yang dibutuhkan container dan tidak lebih.

Alih-alih me-mount seluruh direktori proyek, mount hanya subdirektori yang digunakan container. Alih-alih me-mount /var/log dengan akses tulis, mount read-only jika container hanya perlu membaca log.

Gunakan opsi readonly kapan pun memungkinkan:

docker run -d \
  --mount type=bind,source=/app/config,target=/config,readonly \
  ubuntu:latest

Ini mencegah container memodifikasi data yang di-mount, membatasi kerusakan jika dikompromikan.

Jalankan container sebagai pengguna non-root untuk mengurangi dampak kerentanan bind mount. Buat pengguna di Dockerfile Anda dan beralihlah ke pengguna tersebut sebelum container mulai:

RUN useradd -m appuser
USER appuser

Bersihkan volume yang tidak digunakan secara berkala dengan docker volume prune. Volume lama menumpuk seiring waktu, mengonsumsi ruang disk dan berpotensi menyimpan data sensitif dari container yang telah dihapus.

Jangan pernah me-mount direktori host yang sensitif seperti /, /etc, atau /var kecuali ada alasan spesifik dan Anda memahami risikonya. Setiap mount harus memiliki tujuan yang jelas dan ruang lingkup minimal.

Memecahkan Masalah Mount Docker

Masalah mount biasanya muncul sebagai error izin, file hilang, atau container yang tidak mau mulai - dan hampir selalu disebabkan oleh kumpulan masalah yang sama.

Berikut cara mendiagnosis dan memperbaiki masalah paling umum yang akan Anda temui.

Error izin dan kepemilikan

Error izin terjadi ketika pengguna di dalam container tidak memiliki akses ke file yang di-mount.

Container Docker berjalan sebagai root secara default. Saat root membuat file di bind mount, file itu dimiliki oleh root di host Anda. Jika Anda mencoba mengeditnya dengan akun pengguna biasa, Anda akan mendapatkan error permission denied.

Sebaliknya juga terjadi. Me-mount direktori yang Anda miliki ke container yang berjalan sebagai pengguna non-root, dan container mungkin tidak bisa menulis ke sana.

Anda bisa memeriksa kepemilikan file dengan ls -la pada direktori yang di-mount:

ls -la /path/to/mounted/directory

Jika file dimiliki oleh root tetapi container Anda berjalan sebagai pengguna berbeda, terjadi ketidaksesuaian. Perbaiki dengan menjalankan container sebagai pengguna yang sama dengan pemilik file:

docker run -d \
  --user $(id -u):$(id -g) \
  -v ./data:/app/data \
  ubuntu:latest

Ini menjalankan container sebagai pengguna Anda saat ini, bukan root, sehingga cocok dengan kepemilikan file di bind mount.

Untuk volumes, Docker menangani izin secara otomatis saat container membuat file. Tetapi jika Anda melihat error, periksa pengguna apa yang menjalankan aplikasi di dalam container dan apakah ia memiliki akses tulis ke titik mount.

Kesalahan path dan konfigurasi

Kesalahan paling umum adalah me-mount path yang tidak ada di host.

Coba me-mount /home/user/project saat direktori itu tidak ada, dan Docker akan membuat direktori kosong yang dimiliki root. Container Anda mulai, tetapi ia me-mount hal yang salah - direktori kosong, bukan proyek Anda yang sebenarnya.

Selalu verifikasi path ada sebelum me-mount-nya:

ls /home/user/project

Jika direktori tidak ada, buat dulu atau perbaiki path di perintah mount Anda.

Di Docker Compose, path relatif diresolusikan dari direktori yang berisi file docker-compose.yml Anda. Jika file Anda ada di /home/user/app/ dan Anda menggunakan ./data, Docker mencari /home/user/app/data.

Pindahkan file Compose, dan mount akan rusak.

Kesalahan umum lainnya adalah me-mount ke path target yang salah di dalam container. Me-mount ke /app/data saat aplikasi Anda mengharapkan /data, maka aplikasi tidak akan dapat menemukan filenya. Periksa dokumentasi aplikasi atau Dockerfile untuk memastikan di mana ia mengharapkan data berada.

Keanehan spesifik platform

Di Linux, bind mounts bekerja langsung dengan filesystem host.

Di Mac dan Windows, Docker berjalan di dalam VM Linux. Bind mounts menyinkronkan file antara OS host dan VM tersebut, yang menimbulkan masalah timing. File watcher - alat yang memuat ulang aplikasi saat file berubah - terkadang melewatkan pembaruan karena keterlambatan sinkronisasi.

Mac dan Windows juga menangani izin file secara berbeda. VM menerjemahkan izin antara OS host dan Linux, yang dapat menyebabkan file tampak dengan kepemilikan yang salah di dalam container.

Symlink tidak dapat diandalkan di bind mounts pada Mac dan Windows. VM tidak selalu bisa menyelesaikan symlink yang menunjuk ke luar direktori yang di-mount, sehingga file tampak hilang atau rusak di dalam container.

tmpfs tidak berfungsi sama sekali di Mac dan Windows karena VM tidak mengekspos tmpfs ke host. Jika Anda mencoba menggunakan tmpfs, Docker akan diam-diam mengabaikannya atau melempar error tergantung versinya.

Jika Anda mengembangkan di Mac atau Windows dan mengalami masalah sinkronisasi file yang aneh, beralihlah ke volume bernama untuk performa dan keandalan yang lebih baik. Simpan bind mounts untuk alur kerja pengembangan di mana sinkronisasi real-time lebih penting daripada konsistensi yang sempurna.

Kesimpulan

Sebagai penutup, gunakan volumes untuk data produksi yang perlu persist, seperti database, file unggahan, state aplikasi - apa pun yang tidak boleh hilang. Mereka dikelola Docker, portabel lintas platform, dan pilihan paling aman untuk data yang penting.

Bind mounts cocok untuk alur kerja pengembangan saat Anda memerlukan sinkronisasi file real-time antara host dan container. Saat Anda mengedit kode di editor, Anda akan melihat perubahan seketika di aplikasi yang dikontainerkan. Namun jangan gunakan di produksi karena terlalu bergantung pada path spesifik host dan menimbulkan risiko keamanan yang tidak perlu.

Saat Anda siap mendalami kontainerisasi dan virtualisasi, lihat kursus kami: Containerization and Virtualization with Docker and Kubernetes.