Docker menyediakan 2 cara untuk mencadangkan dan menyinkronkan data kontainer pada mesin lokal yaitu. volume dan gunung. Keduanya berperilaku dengan cara yang sama kecuali untuk beberapa hal yang saya perhatikan:
Volume selalu menyimpan data di / var/lib/docker / volumes, sementara titik mount dapat dibuat di mana pun kita inginkan.
Jika wadah yang diberi titik pemasangan juga diberi volume maka semua data dari titik pemasangan disalin ke volume secara otomatis, sedangkan yang sebaliknya tidak benar.
Kami tidak dapat mendeskripsikan titik pemasangan di Dockerfile tetapi dapat memberikan volume di Dockerfile.
Ok, jadi kita dapat mengatakan ada beberapa keuntungan dan Kerugian dari metodologi tetapi masih ada beberapa klasifikasi atau perbedaan dalam hal optimasi.
Volume Host: apa yang Anda sebut sebagai mount dalam wadah, istilah yang lebih umum adalah bind mount.
Named Volume: setiap volume yang dikelola oleh docker yang Anda beri nama.
Volume anonim: volume apa pun tanpa sumber, docker akan membuat ini sebagai volume lokal dengan ID unik yang panjang, dan berperilaku sebagai volume bernama.
Volume memiliki sumber dan target. Sumber mengidentifikasi jenis volume, sehingga jalur (termasuk garis miring terdepan) ke file/direktori menghasilkan volume host. Jika Anda tidak menyediakan sumber, Anda mendapatkan volume anonim. Jika Anda menentukan volume di dalam Dockerfile, Anda tidak dapat menentukan sumber di sana, jadi secara default docker akan membuat volume anonim kecuali Anda mengarahkannya sebaliknya saat runtime.
Untuk setiap jenis, berikut adalah pro / kontra:
Host:
Pro: mudah untuk mengakses file yang mendasari dari host
Con: masalah izin uid / gid terjadi ketika UID pengguna penampung tidak cocok dengan Gid host
Con: data tidak diinisialisasi
Bernama:
Pro: mudah untuk membuat penggunaan kembali antara wadah / gambar yang berbeda. Jika Anda hanya memberinya nama tanpa pengaturan lain, driver lokal akan secara default menyimpan data anda di /var/lib/docker/volumes yang seharusnya hanya dapat diakses oleh root dari luar docker.
Pro: menginisialisasi konten ke konten gambar saat kosong / baru dan wadah dibuat. Inisialisasi Ini mencakup pemilik file dan izin dari gambar, yang dapat menyelesaikan sebagian besar masalah uid/gid.
Pro: dapat terhubung ke apa pun yang dapat dilakukan oleh perintah mount, termasuk bind mount atau NFS mount, dengan driver lokal. Driver lain memungkinkan anda mereferensikan data di lebih banyak lokasi (misalnya penyedia cloud).
Con: mengelola konten harus dilakukan melalui wadah.
Anonim:
Pro: tidak memerlukan perencanaan untuk menggunakan
Con: data biasanya hilang di sini karena tidak ada pemetaan dari volume kembali ke wadah/gambar yang membuatnya. Ini adalah cara terburuk untuk menyimpan volume menurut saya, dan alasan bahwa tidak ada yang harus mendefinisikan volume di dalam Dockerfile mereka.
Jika memungkinkan, saya menggunakan volume bernama. Inisialisasi data dan penanganan masalah uid/gid yang lebih baik mengalahkan kenyamanan volume host. Jika saya benar-benar membutuhkan akses di luar docker langsung ke data, maka saya mencoba menggunakan volume bernama yang menunjuk ke bind mount alih-alih pengaturan driver lokal default. Contoh sederhana dari ini adalah:
Untuk menentukan volume saya, karena Anda tidak ingin melakukan ini di Dockerfile, saya menggunakan docker-compose.yml dan tentukan volume saya di sana. Jika digunakan dengan mode swarm, saya akan menunjuk ke server NFS dengan volume bernama untuk memungkinkan data dijangkau saat wadah bermigrasi ke host yang berbeda. Jika tidak, ini adalah volume bernama lokal yang dapat dengan mudah digunakan dengan docker-compose.
Volume di dockerfile memungkinkan jalur ditentukan dalam gambar yang harus selalu dibuat sebagai volume. Ini secara inheren melewati penggunaan buruh pelabuhan sistem file union.
Pengguna gambar seperti itu akan selalu mendapatkan volume di lokasi itu saat menjalankan
docker run <imagename>
yaitu tidak ada alasan untuk pernah menambahkan -v /my/mount/point:/mount/here dan dengan demikian pengguna tidak perlu khawatir dengan itu.
binding mounts (seperti contoh di atas dengan -v) harus selalu ada jika diperlukan. dan tidak portabel antara gambar.
perbedaan efektif untuk optimasi adalah ini:
volume dapat digunakan di mana banyak operasi r / w diperlukan dan memiliki penulisan bisnis pada sistem file union (pikirkan database)
volume tidak berharga untuk memasang hal-hal seperti volume data. Anda dapat melakukannya, tetapi Anda mengambil hit r / w yang sangat besar karena tidak ada alasan untuk ini berada di sistem file union.
namun Mount akan menyimpan ini (di atas) dengan cukup baik karena hanya memasang direktori yang ada ke suatu tempat di dalam wadah dan mengabaikan sistem file union untuk direktori itu secara bersamaan.