Сам Swarm Mode не делает ничего другого с томами, он запускает любую команду монтирования тома, которую вы вводите на узле, на котором работает контейнер. Если ваш том монтируется локально для этого узла, то ваши данные будут сохранены локально на этом узле. Нет встроенных функций для автоматического перемещения данных между узлами.
Есть несколько программных решений для распределенного хранения данных, таких как GlusterFS, и у Docker есть одно под названием Infinit, которое еще не является GA, и его разработка отошла на задний план по сравнению с интеграцией Kubernetes в EE.
Типичный результат: вам либо нужно управлять репликацией хранилища в вашем приложении (например, etcd и другие алгоритмы на основе raft), либо вы выполняете монтирование на внешней системе хранения (надеюсь, с ее собственной HA). Существует два варианта монтирования внешней системы хранения: блочное или файловое. Блочное хранилище (например, EBS) обычно имеет более высокую производительность, но его можно установить только на одном узле. Для этого вам обычно понадобится сторонний драйвер подключаемого модуля тома, чтобы предоставить вашему докер-узлу доступ к этому блочному хранилищу. Файловое хранилище (например, EFS) имеет более низкую производительность, но более портативно и может быть одновременно установлено на нескольких узлах, что полезно для реплицируемой службы.
Наиболее распространенным сетевым хранилищем на основе файлов является NFS (это тот же протокол, что и EFS). И вы можете смонтировать это без каких-либо сторонних драйверов плагинов. К сожалению, названный драйвер плагина локального тома, который поставляется с докером, дает вам возможность передавать любые значения, которые вы хотите, команде монтирования с параметрами драйвера, и без параметров по умолчанию он хранит тома в каталоге докера / var / lib / докер / тома. С помощью опций вы можете передать ему параметры NFS, и он даже будет выполнять поиск DNS по имени хоста NFS (чего у вас обычно нет с NFS). Вот пример различных способов монтирования файловой системы NFS с использованием драйвера локального тома:
# 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"
...
Если вы используете пример файла компоновки в конце, обратите внимание, что изменения в томе (например, обновление пути или адреса сервера) не отражаются в существующих именованных томах, пока они существуют. Вам нужно либо переименовать свой том, либо удалить его, чтобы позволить swarm воссоздать его с новыми значениями.
Другая распространенная проблема, с которой я сталкиваюсь в большинстве случаев использования NFS, - это включение на сервере "корневого сквоша". Это приводит к проблемам с разрешениями, когда контейнеры, работающие с правами root, пытаются записать файлы на том. У вас также есть аналогичные проблемы с разрешениями UID / GID, когда UID / GID контейнера - это тот, который требует разрешений для записи на том, что может потребовать настройки владельца каталога и разрешений на сервере NFS.