После прочтения документов я оказался в некотором замешательстве относительно того, как лучше всего управлять производительными данными приложений / служб.
Кажется, есть 3 варианта:
Просто сопоставьте том с каталогом хоста (т.е. -v аргумент в пользу docker run)
Создайте образ контейнера docker для данных (т.е. отдельный контейнер и --volumes-from)
Создание тома docker (т.е. docker volume create)
Теперь, похоже, общепринятой практикой является вариант № 2, но тогда мне интересно, какова цель № 3.
Особенно, как вы правильно справляетесь с этими сценариями с docker volume и лучше ли использовать контейнер объема данных или это для каждой ситуации?
Вам нужны данные приложения в отдельном томе и/или на уровне хранилища на вашем сервере
Я думаю, что # 2 и # 3 - это почти одно и то же, главное отличие заключается в том, что с # 3 нет остановленного контейнера (это буквально просто именованный том). Например, вы можете создать именованный том и сделать аналогично тому, что вы сделали бы с # 2 с помощью -v вместо.
Создайте именованный том:
$ docker volume create --name test
Монтируйте и записывайте некоторые данные на этот том из контейнера:
$ docker run -v test:/opt/test alpine touch /opt/test/hello
Затем вы можете смонтировать тот же самый test том в другом контейнере и считывает данные:
$ docker run -v test:/opt/test alpine ls -al /opt/test total 8drwxr-xr-x 2 root root 4096 Jan 23 22:28 .drwxr-xr-x 3 root root 4096 Jan 23 22:29 ..-rw-r--r-- 1 root root 0 Jan 23 22:28 hello
Преимущество здесь заключается в том, что том случайно не исчезнет, если вы удалите контейнер только для данных. Теперь вы управляете им с помощью docker volume субкомандование.
$ d volume lsDRIVER VOLUME NAMElocal test
Это также открывает возможности для драйверов томов в будущем, так что вы можете создавать общие тома между хостами (т.Е. Именованные тома через NFS). Примерами этого могут быть Флокер и Конвой. Что касается конкретно вашего вопроса о перемещении или резервном копировании данных, Convoy имеет специальные подкоманды для резервного копирования данных и позволяет хранить их на NFS или EBS, внешних по отношению к вашему хосту.
По этой причине я думаю, что более новый способ (Docker 1.9+) заключается в использовании именованного тома, а не контейнера только для данных.
@MichaelHampton Почему?, данные могут не быть докеризованы, но хост-ОС по-прежнему управляется командой инфраструктуры, которая отслеживает и создает резервные копии
@dukeofgaming Не говоря уже о том, что вы можете запустить на нем “btrfs scrub”, чтобы найти и исправить поврежденные файлы. Я не уверен, как работает докеризованный материал, но я предполагаю, что он не защищает от повреждения данных, поэтому мне всегда нужно полное восстановление, если происходит что-то плохое, вместо того, чтобы просто восстанавливать отдельные файлы. Другая мысль заключается в том, что это добавляет еще один уровень абстракции, поэтому еще больше замедляет чтение и запись файлов. Я почему-то не вижу преимуществ # 2 и # 3, но у меня нет опыта работы с docker, так что это может измениться.