Bind Mount

Bind mount adalah cara paling langsung untuk menghubungkan direktori di host, yaitu mesin tempat Docker berjalan, dengan sebuah jalur di dalam container. Topik ini membahas sintaks pemasangan, alur kerja pengembangan yang dimungkinkan bind mount, perbedaannya dengan volume sebagai penyimpanan yang dikelola Docker, opsi read-only, dan jebakan kepemilikan berkas. Setelah mekanismenya dipahami, pilihan antara bind mount dan volume untuk setiap jenis data menjadi keputusan yang berdasar.

Bind mount memetakan direktori host#

Bind mount adalah mount, yaitu pemasangan sistem berkas, dari direktori atau berkas di host ke sebuah jalur di dalam container. Berbeda dengan volume yang isinya dikelola Docker, sumber bind mount adalah direktori mana pun milik pengguna, misalnya folder proyek. Docker tidak menyalin isinya. Container membaca dan menulis berkas yang sama dengan host, sehingga perubahan dari sisi mana pun langsung terlihat di sisi lain.

Opsi -v menerima bentuk jalur_host:jalur_container. Apabila bagian pertama berupa jalur, misalnya $(pwd) yang berarti direktori kerja saat ini, Docker menafsirkannya sebagai bind mount. Apabila bagian pertama berupa nama tunggal, Docker menafsirkannya sebagai volume. Bentuk kedua yang lebih eksplisit adalah --mount type=bind, yang menyatakan tipe pemetaannya secara langsung. Kedua bentuk berikut menghasilkan pemasangan yang sama.

# tidak-dijalankan: daemon Docker tidak tersedia di sandbox
# memetakan direktori kerja host ke /app di dalam container
docker run --rm -v "$(pwd)":/app python:3.12-slim python /app/app.py
docker run --rm --mount type=bind,src="$(pwd)",dst=/app python:3.12-slim python /app/app.py

Perbedaan praktis keduanya muncul ketika jalur host belum ada. Opsi -v membuat direktorinya secara otomatis, sedangkan --mount type=bind menolak berjalan dan menampilkan error bila jalurnya tidak ditemukan. Perilaku menolak itu sering diinginkan, karena salah ketik jalur langsung terlihat dan tidak meninggalkan direktori kosong yang membingungkan.

Alur kerja pengembangan dengan bind mount#

Bind mount paling sering dipakai untuk pengembangan aplikasi. Kode sumber tetap berada di direktori proyek di host, editor bekerja normal terhadap berkas yang sama seperti biasa, dan container berperan sebagai lingkungan tempat kode dijalankan. Tidak ada langkah menyalin kode ke dalam image setiap kali berubah, dan tidak ada image baru yang perlu dibangun untuk menguji satu perubahan kecil.

# tidak-dijalankan: daemon Docker tidak tersedia di sandbox
# opsi -w mengarahkan direktori kerja container ke /app
docker run --rm -v "$(pwd)":/app -w /app python:3.12-slim python app.py

Urutan kerjanya pendek. Sunting berkas di host, jalankan ulang perintah docker run, dan container membaca versi terbaru kode secara langsung. Aplikasi yang menulis keluaran ke dalam direktori terpasang, misalnya log atau berkas unggahan, menghasilkan berkas yang langsung tampak di host pula. Dua arah itu bekerja tanpa sinkronisasi karena hanya ada satu salinan berkas yang dibagi bersama.

Kelebihan lain muncul saat pengujian. Container dapat membawa versi Python yang berbeda dari versi di host, sehingga perilaku pada lingkungan produksi dapat diuji tanpa mengubah instalasi Python lokal. Kode uji dan hasil keluarannya tetap berada di direktori proyek yang sama, sedangkan image hanya berperan sebagai lingkungan yang mudah ditukar.

Perbedaan bind mount dan volume#

Bind mount dan volume menyelesaikan masalah yang sama, yaitu menaruh data persisten di luar lapisan tulis, dengan cara yang berbeda. Data persisten berarti data yang harus tetap ada melewati umur container. Pilihan yang tepat mengikuti siapa yang mengelola isinya dan berapa lama datanya harus hidup. Tabel berikut menyandingkan keduanya.

Aturan pilihan yang lazim menempatkan bind mount pada hal yang disunting manusia selama pengembangan dan volume pada hal yang ditulis aplikasi serta harus bertahan. Keduanya boleh dipasang bersamaan pada satu container, misalnya kode sumber lewat bind mount sekaligus basis data lewat volume. Pada lingkungan produksi, bind mount jarang dipakai karena jalurnya terikat pada mesin tertentu, sedangkan volume mengikuti aturan Docker yang seragam di mana pun berjalan. Pembagian peran itu juga menjaga tiap jenis data berada pada tempat yang paling sedikit menimbulkan kejutan.

Opsi read-only dan jebakan kepemilikan#

Akhiran :ro pada akhir opsi -v menjadikan pemasangan read-only dari sisi container, dan bentuk --mount menyatakannya dengan opsi readonly. Container masih dapat membaca berkasnya, tetapi setiap percobaan menulis ditolak. Pembatasan ini melindungi kode sumber dan konfigurasi dari kesalahan program yang menulis ke tempat yang salah.

# tidak-dijalankan: daemon Docker tidak tersedia di sandbox
# direktori konfigurasi dipasang read-only agar tidak dapat diubah dari container
docker run --rm -v "$(pwd)/konfigurasi":/opt/konfigurasi:ro alpine:3.20 cat /opt/konfigurasi/aplikasi.yaml

Jebakan berikutnya muncul dari kepemilikan berkas. Setiap proses di Linux berjalan atas nama satu UID, angka identitas pengguna, dan berkas baru mengikuti UID proses yang menulisnya. Container secara bawaan menjalankan prosesnya sebagai root dengan UID 0, sehingga berkas yang dibuat container di dalam bind mount muncul di host sebagai milik root. Editor dan perintah di host kemudian menolak menyunting atau menghapusnya tanpa hak istimewa tambahan.

Perbaikannya adalah menyamakan identitas. Opsi --user $(id -u):$(id -g) memerintahkan container berjalan dengan UID dan GID pengguna di host, yaitu angka identitas pengguna dan grup, sehingga berkas hasil tulisan container tetap milik pengguna tersebut. Arah sebaliknya juga dapat bermasalah, yaitu container non-root yang gagal menulis ke direktori host milik UID lain. Pada kedua arah, solusinya tetap sama, yaitu menyelaraskan identitas proses container dengan pemilik direktori.

Ringkasan#

• Bind mount memetakan direktori host ke container tanpa penyalinan, sehingga perubahan di kedua sisi langsung saling terlihat.
• Bentuk -v "$(pwd)":/app melayani alur kerja pengembangan, sedangkan --mount type=bind lebih eksplisit dan menolak jalur host yang tidak ada.
• Volume lebih cocok untuk data aplikasi yang harus bertahan, sedangkan bind mount untuk kode sumber dan konfigurasi saat pengembangan.
• Akhiran :ro membatasi container menjadi pembaca, dan opsi --user menyelaraskan UID agar berkas hasil tulisan container tetap milik pengguna host.

Referensi#

• Bind mounts — Docker Docs — Dokumentasi utama bind mount, mencakup opsi -v, --mount, dan read-only.
• Volumes — Docker Docs — Pembanding utama bind mount beserta keunggulan volume.
• Storage overview — Docker Docs — Peta pilihan penyimpanan data container dan letak masing-masing.