Sam tryb roju nie robi nic innego z woluminami, uruchamia dowolne polecenie podłączenia woluminu, które podasz w węźle, w którym działa kontener. Jeśli instalacja woluminu jest lokalna w tym węźle, dane zostaną zapisane lokalnie w tym węźle. Nie ma wbudowanej funkcji automatycznego przenoszenia danych między węzłami.
Istnieje kilka rozproszonych rozwiązań pamięci masowych opartych na oprogramowaniu, takich jak GlusterFS, a Docker ma jeden o nazwie Infinit, który nie jest jeszcze GA, a jego rozwój zajął tylne miejsce w integracji Kubernetes w EE.
Typowy wynik jest taki, że musisz albo zarządzać replikacją pamięci masowej w aplikacji (np. Etcd i inne algorytmy oparte na tratwie), albo wykonywać montowania w zewnętrznym systemie pamięci masowej (miejmy nadzieję, z własnym HA). Montowanie zewnętrznego systemu pamięci masowej ma dwie opcje, oparte na blokach lub plikach. Pamięć masowa oparta na blokach (np. EBS) ma zwykle wyższą wydajność, ale jest ograniczona do montażu tylko w jednym węźle. W tym celu zazwyczaj będziesz potrzebować sterownika wtyczki woluminu innej firmy, aby zapewnić węzłowi Docker dostęp do tego bloku magazynowego. Magazyn oparty na plikach (np. EFS) ma niższą wydajność, ale jest bardziej przenośny i może być jednocześnie montowany na wielu węzłach, co jest przydatne w przypadku usługi replikowanej.
Najpopularniejszym magazynem sieciowym opartym na plikach jest NFS (jest to ten sam protokół używany przez EFS). Możesz to zamontować bez sterowników wtyczek innych firm. Niestety nazwany „lokalny” sterownik wtyczki woluminu, z którym docker jest dostarczany, daje możliwość przekazania dowolnych wartości do polecenia mount z opcjami sterownika, a bez opcji domyślnie przechowuje woluminy w katalogu docker / var / lib / docker / woluminy. Dzięki opcjom możesz przekazać mu parametry NFS, a nawet wykona wyszukiwanie DNS na nazwie hosta NFS (coś, czego normalnie nie masz w NFS). Oto przykład różnych sposobów montowania systemu plików NFS przy użyciu lokalnego sterownika woluminu:
# 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"
...
Jeśli na końcu użyjesz przykładu pliku redagowania, zwróć uwagę, że zmiany w wolumenie (np. Aktualizacja ścieżki lub adresu serwera) nie są odzwierciedlane w istniejących nazwanych woluminach tak długo, jak istnieją. Musisz albo zmienić nazwę swojego wolumenu, albo go usunąć, aby umożliwić rójowi odtworzenie go z nowymi wartościami.
Innym częstym problemem, który widzę w większości zastosowań NFS, jest włączenie „root squash” na serwerze. Powoduje to problemy z uprawnieniami, gdy kontenery działające jako root próbują zapisywać pliki na woluminie. Masz również podobne problemy z uprawnieniami UID / GID, w których identyfikator UID / GID kontenera jest tym, który wymaga uprawnień do zapisu w woluminie, co może wymagać posiadania własności katalogu i dostosowania uprawnień na serwerze NFS.