Swarm Mode, birimlerle farklı bir şey yapmaz, konteynerin çalıştığı düğümde sağladığınız herhangi bir birim bağlama komutunu çalıştırır. Birim montajınız bu düğüm için yerelse, verileriniz yerel olarak o düğüme kaydedilir. Verileri düğümler arasında otomatik olarak taşımak için yerleşik bir işlev yoktur.
GlusterFS gibi bazı yazılım tabanlı dağıtılmış depolama çözümleri vardır ve Docker, henüz GA olmayan Infinit adında bir tanesine sahiptir ve EE'deki Kubernetes entegrasyonuna arka koltuk almıştır.
Tipik sonuç, ya uygulamanızdaki depolamanın replikasyonunu yönetmeniz (örn. Etcd ve diğer sal tabanlı algoritmalar) ya da bağlantılarınızı harici bir depolama sisteminde (umarız kendi HA'sı ile) gerçekleştirmenizdir. Harici bir depolama sistemini bağlamak blok veya dosya tabanlı olmak üzere iki seçeneğe sahiptir. Blok tabanlı depolama (örn. EBS) tipik olarak daha yüksek performansla gelir, ancak yalnızca tek bir düğüme monte edilmesiyle sınırlıdır. Bunun için, docker düğümünüze bu blok depolamaya erişim sağlamak için genellikle bir 3. parti birim eklenti sürücüsüne ihtiyacınız olacaktır. Dosya tabanlı depolama (örn. EFS) daha düşük performansa sahiptir, ancak daha taşınabilirdir ve aynı anda birden çok düğüme monte edilebilir, bu da çoğaltılmış bir hizmet için yararlıdır.
En yaygın dosya tabanlı ağ depolaması NFS'dir (bu, EFS tarafından kullanılan protokoldür). Ve bunu herhangi bir 3. taraf eklenti sürücüsü olmadan monte edebilirsiniz. Docker ile birlikte gönderilen maalesef adlandırılmış "yerel" birim eklenti sürücüsü, size istediğiniz değerleri sürücü seçenekleriyle bağlama komutuna geçirme seçeneği sunar ve hiçbir seçenek olmadan birimleri docker dizininde / var / lib / docker / volumes. Seçeneklerle, ona NFS parametrelerini iletebilirsiniz ve hatta NFS ana bilgisayar adı üzerinde bir DNS araması bile gerçekleştirir (normalde NFS ile sahip olmadığınız bir şey). Yerel birim sürücüsünü kullanarak bir NFS dosya sistemini bağlamanın farklı yollarının bir örneğini burada bulabilirsiniz:
# 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"
...
Sonunda oluşturma dosyası örneğini kullanırsanız, bir birimdeki değişikliklerin (örneğin, sunucu yolunu veya adresini güncelleme) var oldukları sürece var olan adlandırılmış birimlere yansıtılmadığını unutmayın. Swarm'ın yeni değerlerle yeniden oluşturmasına izin vermek için ya biriminizi yeniden adlandırmanız ya da silmeniz gerekir.
Çoğu NFS kullanımında gördüğüm diğer yaygın sorun, sunucuda etkinleştirilen "kök ezme" dir. Bu, kök olarak çalışan kapsayıcılar birime dosya yazmaya çalıştığında izin sorunlarına yol açar. Ayrıca, kapsayıcı UID / GID'nin birime yazmak için izinlere ihtiyaç duyduğu ve NFS sunucusunda dizin sahipliğini ve izinlerin ayarlanmasını gerektirebilecek benzer UID / GID izin sorunlarınız var.