Docker предоставляет 2 способа резервного копирования и синхронизации данных контейнера на локальном компьютере, т.е. объем и монтировать. Оба ведут себя одинаково, за исключением нескольких вещей, которые я заметил:
Итак, мы можем сказать, что у методологии есть некоторые преимущества и недостатки, но есть ли некоторая классификация или различия в плане оптимизации.
Пожалуйста, дайте объясненный ответ.
На самом деле существует три типа томов:
У томов есть источник и цель. Источник идентифицирует тип тома, поэтому путь (включая ведущую косую черту) к файлу / каталогу приводит к тому хосту. Если вы не предоставите источник, вы получите анонимные тома. Если вы определяете том внутри Dockerfile, вы не можете указать там источник, поэтому по умолчанию docker будет создавать анонимные тома, если вы не укажете иное во время выполнения.
Вот плюсы и минусы каждого типа:
По возможности я использую именованный том. Инициализация данных и лучшая обработка проблем 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
) всегда должны присутствовать, если они требуются. и не переносятся между изображениями.
Эффективные отличия от оптимизации таковы:
Имеет ли это смысл?