Прочитав и немного поигравшись с докером, я подумываю использовать его в своей производственной среде. Однако я все еще пытаюсь понять разницу между привязками монтирования и томами.
Согласно документации Dockers по привязкам монтирования (https://docs.docker.com/storage/bind-mounts/):
Крепления привязки используются с первых дней существования Docker. Привязочные крепления имеют ограниченную функциональность по сравнению с томами. Когда вы используете привязку, файл или каталог на хост-машине монтируется в контейнер. На файл или каталог ссылается его полный или относительный путь на хост-машине. Напротив, когда вы используете том, новый каталог создается в каталоге хранилища Docker на хост-машине, и Docker управляет содержимым этого каталога.
Из этого (и из экспериментов) мне кажется, что привязки монтирования и тома - это одно и то же, единственная разница заключается в расположении данных. (тома хранятся в «частной» области хранения докера, а привязки монтирования могут храниться где угодно). Да, привязка монтирования должна существовать до запуска контейнера докеров, в то время как тома могут быть созданы механизмом докеров при запуске контейнера, но эта разница связана с производительностью или обслуживанием.
Я не мог понять предполагаемых преимуществ объемов, указанных в документации (https://docs.docker.com/storage/volumes/), поскольку все они, похоже, одинаково применимы к привязкам монтирования.
Может ли кто-нибудь объяснить основные различия между томами и привязками монтирования (с точки зрения производительности и обслуживания) и, что наиболее важно, их варианты использования?
Спасибо за помощь.
По умолчанию локальный именованный том точно такой, как вы описали, привязка монтирования к специальному каталогу докеров. Отличия вижу:
Во-первых, самая большая разница в поведении именованных томов и хост-томов (также называемых привязкой монтирования). Docker инициализирует именованный том из содержимого образа. Это включает владельцев файлов и разрешения. Это означает, что вы можете не беспокоиться о проблемах с разрешениями, которые обычно встречаются с томами хоста.
Во-вторых, портативность. Именованные тома можно использовать с разных хостов докеров, не беспокоясь о путях в локальной файловой системе или о пользователе, выполняющем команды. Независимо от того, находится ли он на ноутбуке MacOS или на производственном сервере Linux, вы можете просто назвать том и предположить, что он будет работать как часть установки докера по умолчанию.
В-третьих, как ими управлять. Тома хоста обычно управляются вне докера, где часто возникают проблемы с разрешениями (поскольку UID / GID на хосте обычно не соответствует UID / GID внутри контейнера). С помощью именованных томов вы можете управлять ими из другого контейнера докеров, где вы можете контролировать, какие инструменты установлены, созданы пользователи и т. Д.
Есть еще одна большая разница с именованными томами. Это потому что я сказал "по умолчанию" выше, и именованный том можно настроить несколькими способами. Драйвер тома можно заменить на другой, поддерживающий облако. Или вы можете передать параметры драйверу локального тома, чтобы переключиться с монтирования локальной привязки в конкретный каталог на все, что вы можете сделать с помощью системного вызова монтирования. Это включает в себя выполнение привязки к другому каталогу, монтирование NFS, и вы даже можете создать свою собственную файловую систему наложения в качестве тома, чтобы позволить контейнерам получать доступ и изменять некоторые данные внутри контейнера без изменения базовых файлов в базовом слое.
Используя именованные тома, вы также можете отделить управление хранилищем от управления контейнерами. Вы просто указываете на имя, и внешний инструмент может создать этот том, чтобы указать на соответствующее место в этой среде.
Вот несколько примеров именованных томов, которые я использовал с драйвером локального тома:
# named bind mount
$ docker volume create --driver local \
--opt type=none \
--opt device=/home/user/test \
--opt o=bind \
test_vol
# nfs
$ docker volume create --driver local \
--opt type=nfs \
--opt o=nfsvers=4,addr=nfs.example.com,rw \
--opt device=:/path/to/dir \
foo
# overlay
$ docker volume create --driver local --opt type=overlay \
--opt o=lowerdir=${PWD}/ro-data,upperdir=${PWD}/upper1,workdir=${PWD}/work1 \
--opt device=overlay overlay1