Назад | Перейти на главную страницу

В чем разница между созданием тома или монтированием в контейнерах докеров?

Docker предоставляет 2 способа резервного копирования и синхронизации данных контейнера на локальном компьютере, т.е. объем и монтировать. Оба ведут себя одинаково, за исключением нескольких вещей, которые я заметил:

  1. Том всегда хранит данные в / var / lib / docker / volume, а точки монтирования могут быть созданы где угодно.
  2. Если контейнеру, которому назначена точка монтирования, также назначается том, тогда все данные из точки монтирования автоматически копируются в том, в то время как обратное неверно.
  3. Мы не можем описать точку монтирования в Dockerfile, но можем указать тома в Dockerfile.

Итак, мы можем сказать, что у методологии есть некоторые преимущества и недостатки, но есть ли некоторая классификация или различия в плане оптимизации.

Пожалуйста, дайте объясненный ответ.

На самом деле существует три типа томов:

  • Том хоста: то, что вы называете монтированием в контейнере, более распространенным термином является привязка монтирования.
  • Именованный том: любой том, управляемый докером, которому вы даете имя.
  • Анонимный том: любой том без источника, докер создаст его как локальный том с длинным уникальным идентификатором, и он будет вести себя как именованный том.

У томов есть источник и цель. Источник идентифицирует тип тома, поэтому путь (включая ведущую косую черту) к файлу / каталогу приводит к тому хосту. Если вы не предоставите источник, вы получите анонимные тома. Если вы определяете том внутри Dockerfile, вы не можете указать там источник, поэтому по умолчанию docker будет создавать анонимные тома, если вы не укажете иное во время выполнения.

Вот плюсы и минусы каждого типа:

  • Хост:
    • Плюсы: простой доступ к базовым файлам с хоста
    • Против: проблемы с разрешениями uid / gid возникают, когда uid пользователя контейнера не совпадает с gid хоста
    • Минус: данные не инициализируются
  • По имени:
    • Плюсы: легко создать повторное использование между разными контейнерами / образами. Если вы дадите ему только имя без каких-либо других настроек, локальный драйвер по умолчанию будет хранить ваши данные в / var / lib / docker / volume, которые должны быть доступны только root вне докера.
    • Pro: инициализирует содержимое содержимым изображения, когда оно пустое / новое и контейнер создан. Эта инициализация включает владельцев файлов и разрешения образа, которые могут решить большинство проблем с uid / gid.
    • Pro: может подключаться ко всему, что может выполнить команда mount, включая привязку или монтирование NFS, с помощью локального драйвера. Другие драйверы позволяют ссылаться на данные в еще большем количестве мест (например, облачные провайдеры).
    • Минусы: управление контентом должно осуществляться через контейнер.
  • Аноним:
    • Плюс: не требует планирования для использования
    • Против: данные обычно теряются, поскольку нет сопоставления тома с контейнером / образом, который его создал. На мой взгляд, это наихудший способ хранения томов и причина того, что никто никогда не должен определять том внутри своего Dockerfile.

По возможности я использую именованный том. Инициализация данных и лучшая обработка проблем uid / gid превосходит удобство хост-тома. Если мне действительно нужен доступ за пределами докера непосредственно к данным, я пытаюсь использовать именованный том, который указывает на привязку, вместо настроек локального драйвера по умолчанию. Вот простой пример:

$ docker volume create --driver local \
  --opt type=none \
  --opt device=/home/user/test \
  --opt o=bind \
  test_vol

Для определения моих томов, поскольку вы не хотите делать это в Dockerfile, я использую docker-compose.yml и определяю свои тома там. Если он развернут в режиме swarm, я укажу на сервер NFS с именованным томом, чтобы обеспечить доступ к данным при миграции контейнеров на другие хосты. В противном случае это локальный именованный том, который можно легко использовать с docker-compose.

Тома в файле докеров позволяют указывать путь в образе, который всегда должен создаваться как том. Это по сути обходит использование докером объединенной файловой системы.

Пользователи такого изображения всегда будут получать том в этом месте при запуске

docker run <imagename>

т.е. нет причин когда-либо добавлять -v /my/mount/point:/mount/here и поэтому пользователям не нужно беспокоиться об этом.

привязные крепления (как в примере выше с -v) всегда должны присутствовать, если они требуются. и не переносятся между изображениями.

Эффективные отличия от оптимизации таковы:

  • тома могут использоваться там, где требуется много операций чтения / записи, и он имеет деловую запись в файловой системе union (подумайте о базах данных)
  • тома бесполезны для монтирования таких вещей, как тома данных. вы можете это сделать, но вы получите огромное количество R / W, потому что нет причин для этого в файловой системе union.
  • Однако mounts сохранит это (указанное выше) достаточно хорошо, поскольку он просто монтирует существующий каталог в место внутри контейнера и игнорирует файловую систему union для этого каталога вместе.

Имеет ли это смысл?