Swarm Mode itu sendiri tidak melakukan sesuatu yang berbeda dengan volume, ia menjalankan perintah volume mount yang Anda berikan pada node tempat container sedang berjalan. Jika volume mount Anda lokal ke node itu, maka data Anda akan disimpan secara lokal di node itu. Tidak ada fungsionalitas bawaan untuk memindahkan data antar node secara otomatis.
Ada beberapa solusi penyimpanan terdistribusi berbasis perangkat lunak seperti GlusterFS, dan Docker memiliki satu yang disebut Infinit yang belum menjadi GA dan pengembangannya telah mengambil kursi belakang untuk integrasi Kubernetes di EE.
Hasil tipikal adalah Anda perlu mengelola replikasi penyimpanan dalam aplikasi Anda (mis. Etcd dan algoritma berbasis rakit lainnya) atau Anda melakukan pemasangan pada sistem penyimpanan eksternal (mudah-mudahan dengan HA-nya sendiri). Memasang sistem penyimpanan eksternal memiliki dua opsi, blok atau berbasis file. Penyimpanan berbasis blok (mis. EBS) biasanya hadir dengan kinerja yang lebih tinggi, tetapi terbatas hanya untuk dipasang pada satu node. Untuk ini, Anda biasanya memerlukan driver plugin volume pihak ketiga untuk memberikan akses node docker Anda ke penyimpanan blok itu. Penyimpanan berbasis file (mis. EFS) memiliki kinerja yang lebih rendah, tetapi lebih portabel, dan dapat dipasang secara bersamaan pada beberapa node, yang berguna untuk layanan yang direplikasi.
Penyimpanan jaringan berbasis file yang paling umum adalah NFS (ini adalah protokol yang sama yang digunakan oleh EFS). Dan Anda dapat memasangnya tanpa driver plugin pihak ketiga. Sayangnya, driver plugin volume "lokal" yang dikirimkan oleh buruh pelabuhan memberi Anda opsi untuk meneruskan nilai apa pun yang Anda inginkan ke perintah mount dengan opsi driver, dan tanpa opsi, defaultnya adalah menyimpan volume di direktori buruh pelabuhan / var / lib / buruh pelabuhan / volume. Dengan opsi, Anda dapat meneruskannya ke parameter NFS, dan bahkan akan melakukan pencarian DNS pada nama host NFS (sesuatu yang biasanya tidak Anda miliki dengan NFS). Berikut adalah contoh dari berbagai cara untuk memasang sistem file NFS menggunakan driver volume lokal:
# create a reusable volume
$ docker volume create --driver local \
--opt type=nfs \
--opt o=nfsvers=4,addr=192.168.1.1,rw \
--opt device=:/path/to/dir \
foo
# or from the docker run command
$ docker run -it --rm \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=192.168.1.1\",volume-opt=device=:/host/path \
foo
# or to create a service
$ docker service create \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=192.168.1.1\",volume-opt=device=:/host/path \
foo
# inside a docker-compose file
...
volumes:
nfs-data:
driver: local
driver_opts:
type: nfs
o: nfsvers=4,addr=192.168.1.1,rw
device: ":/path/to/dir"
...
Jika Anda menggunakan contoh compose file di bagian akhir, perhatikan bahwa perubahan volume (misalnya memperbarui jalur atau alamat server) tidak tercermin dalam volume bernama yang ada selama ada. Anda perlu mengganti nama volume Anda, atau menghapusnya, untuk memungkinkan swarm membuatnya kembali dengan nilai baru.
Masalah umum lainnya yang saya lihat di sebagian besar penggunaan NFS adalah "root squash" yang diaktifkan di server. Hal ini menyebabkan masalah izin saat penampung yang berjalan sebagai root mencoba menulis file ke volume. Anda juga memiliki masalah izin UID / GID yang serupa dengan UID / GID penampung yang memerlukan izin untuk menulis ke volume, yang mungkin memerlukan kepemilikan direktori dan izin untuk disesuaikan di server NFS.