Прочитав и немного поиграв с docker, я подумываю об использовании его в своей производственной среде. Однако я все еще пытаюсь понять разницу между привязками монтирования и томами.
Согласно документации Dockers по монтированию привязок (https://docs.docker.com/storage/bind-mounts/):
Крепления Bind существуют с первых дней существования Docker. Привязанные крепления имеют ограниченную функциональность по сравнению с томами. Когда вы используете привязку, файл или каталог на хост-компьютере монтируется в контейнер. На файл или каталог ссылается его полный или относительный путь на хост-компьютере. В отличие от этого, когда вы используете том, в каталоге хранилища Docker на хост-компьютере создается новый каталог, и Docker управляет содержимым этого каталога.
Из этого (и из игры вокруг) мне кажется, что привязки монтирования и тома - это одно и то же, разница лишь в расположении данных. (тома хранятся в "частной" области хранения docker, в то время как привязки к монтированию могут храниться где угодно). Да, привязка к монтированию должна существовать до запуска контейнера docker, в то время как тома могут быть созданы механизмом docker при запуске контейнера, но это различие неуважительно относится к производительности или обслуживанию.
Я не смог понять предполагаемых преимуществ объемов, указанных в документации (https://docs.docker.com/storage/volumes/), поскольку все они, похоже, одинаково применимы к привязкам монтирования.
Может кто-нибудь, пожалуйста, объяснить основные различия между томами и привязками к монтированию (с точки зрения производительности и обслуживания) и, самое главное, их варианты использования?
спасибо за помощь.
По умолчанию локальный именованный том - это именно то, что вы описали, привязка к специальному каталогу docker. Различия, которые я вижу:
Во-первых, большая разница - это разница в поведении между именованными томами и томами хоста (они же привязанные монтирования). Docker инициализирует именованный том из содержимого образа. Это включает в себя владельцев файлов и разрешения. Это означает, что вы можете не беспокоиться о проблемах с разрешениями, которые обычно возникают с томами хоста.
Во-вторых, мобильность. Именованные тома можно использовать с разных хостов docker, не беспокоясь о путях к локальной файловой системе или о пользователе, выполняющем команды. Независимо от того, находится ли он на ноутбуке macOS или на рабочем сервере Linux, вы можете просто назвать том и предположить, что он будет работать как часть установки docker по умолчанию.
В-третьих, как ими управляют. Тома хоста обычно управляются вне docker, где часто возникают проблемы с разрешениями (поскольку UID / GID на хосте обычно не совпадает с UID / GID внутри контейнера). С именованными томами вы могли бы управлять ими из другого контейнера docker, где вы можете контролировать, какие инструменты устанавливаются, создаются пользователи и т.д.
Есть также еще одна большая разница с именованными томами. Это потому, что я сказал "по умолчанию" выше, и именованный том можно настроить несколькими способами. Драйвер тома можно заменить на другой, работающий в облаке. Или вы можете передать параметры драйверу локального тома, чтобы переключиться с локального привязки к определенному каталогу на все, что вы можете сделать с помощью системного вызова mount. Это включает в себя выполнение привязки к другому каталогу, монтирование 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