Setelah membaca dan bermain-main dengan docker sebentar, saya mempertimbangkan untuk menggunakannya di lingkungan produksi saya. Namun saya masih mencoba memahami perbedaan antara mount binds dan volume.
Menurut dokumentasi Dockers di Mount binds (https://docs.docker.com/storage/bind-mounts/):
Bind Mount telah ada sejak hari-hari awal Docker. Bind mount memiliki fungsionalitas terbatas dibandingkan dengan volume. Bila Anda menggunakan mengikat mount, file atau direktori pada mesin host dipasang ke dalam wadah. File atau direktori direferensikan oleh path penuh atau relatif pada mesin host. Sebaliknya, ketika Anda menggunakan volume, direktori baru dibuat dalam direktori penyimpanan Docker di mesin host, dan Docker mengelola konten direktori itu.
Dari ini (dan dari bermain-main) tampaknya bagi saya bahwa mount binds dan volume adalah hal yang sama, satu-satunya perbedaan adalah lokasi data. (volume disimpan di area penyimpanan "pribadi" docker, sementara mount binds dapat disimpan di mana saja). Ya, mount bind harus ada sebelum memulai wadah docker, sementara volume dapat dibuat oleh Mesin docker saat wadah dimulai - tetapi perbedaan ini adalah kinerja atau perawatan yang tidak sopan.
Saya tidak dapat memahami manfaat yang seharusnya dari volume yang dinyatakan oleh dokumentasi (https://docs.docker.com/storage/volumes/) karena semuanya tampaknya berlaku untuk mount binds sama saja.
Adakah yang bisa menjelaskan perbedaan utama antara volume dan mount-binds (kinerja dan pemeliharaan bijaksana) dan yang paling penting kasus penggunaannya?
terima kasih atas bantuannya.
Secara default, volume bernama lokal persis seperti yang Anda jelaskan, pengikatan mount ke direktori docker khusus. Perbedaan yang saya lihat:
Pertama, yang besar adalah perbedaan perilaku antara volume bernama dan volume host (alias bind mounts). Docker akan menginisialisasi volume bernama dari isi gambar. Ini termasuk pemilik file dan izin. Ini berarti Anda dapat menghindari kekhawatiran tentang masalah izin yang biasa ditemui dengan volume host.
Kedua, portabilitas. Volume bernama dapat digunakan dari host docker yang berbeda tanpa mengkhawatirkan jalur sistem file lokal atau pengguna yang menjalankan perintah. Baik itu di laptop MacOS, atau Server Linux dalam produksi, anda cukup memberi nama volume dan menganggapnya akan berfungsi sebagai bagian dari instalasi docker default.
Ketiga, bagaimana mereka dikelola. Volume Host biasanya dikelola di luar docker yang merupakan tempat masalah izin sering ikut bermain (karena UID/GID pada host Biasanya tidak cocok dengan UID/GID di dalam wadah). Dengan volume bernama, anda akan mengelolanya dari dalam wadah docker lain tempat Anda dapat mengontrol alat apa yang diinstal, dibuat pengguna, dll.
Ada juga perbedaan besar lainnya dengan volume bernama. Itu karena aku berkata "secara default" di atas, dan volume bernama dapat dikonfigurasi dalam beberapa cara. Driver volume dapat diubah ke yang lain yang sadar cloud. Atau Anda dapat meneruskan opsi ke driver volume lokal untuk mengubah dari pengikatan lokal ke direktori tertentu ke apa pun yang dapat anda lakukan dengan mount syscall. Itu termasuk melakukan pengikatan pengikatan ke direktori yang berbeda, pemasangan NFS, dan Anda bahkan dapat membuat sistem file overlay Anda sendiri sebagai volume untuk memungkinkan wadah mengakses dan memodifikasi beberapa data di dalam wadah tanpa mengubah file yang mendasarinya di lapisan dasar.
Dengan menggunakan volume bernama, anda juga dapat memisahkan pengelolaan penyimpanan dari pengelolaan wadah. Anda cukup menunjuk ke nama dan alat eksternal dapat membuat volume itu untuk menunjuk ke lokasi yang sesuai di lingkungan itu.
Beberapa contoh volume bernama yang saya gunakan dengan driver volume lokal meliputi:
# named bind mount$ docker volume create --driver local \ --opt type=none \ --opt device=/home/user/test \ --opt o=bind \ test_vol# nfs$ docker volume create --driver local \ --opt type=nfs \ --opt o=nfsvers=4,addr=nfs.example.com,rw \ --opt device=:/path/to/dir \ foo# overlay$ docker volume create --driver local --opt type=overlay \ --opt o=lowerdir=${PWD}/ro-data,upperdir=${PWD}/upper1,workdir=${PWD}/work1 \ --opt device=overlay overlay1