Как выбрать между контейнером тома докера и томом докера?

Прочитав эту документацию, я почувствовал некоторое замешательство относительно того, как лучше всего управлять производительными данными приложений / служб.

Кажется, есть 3 варианта:

Просто сопоставьте том с каталогом хоста (т.е. -vаргументом для docker run)
Создать образ контейнера докера для данных (т.е. отдельный контейнер и --volumes-from)
Создание тома докера (т.е. docker volume create)

Похоже, что принятая практика - это вариант № 2, но мне интересно, какова цель № 3?

Особенно, как вы правильно обрабатываете эти сценарии, docker volumeи лучше ли использовать контейнер объема данных или это для каждой ситуации?

Вам нужны данные приложения на отдельном уровне тома и / или хранилища на вашем сервере
Резервное копирование
Восстановление данных

storage docker

— dukeofgaming
источник

serverfault.com/q/576490/126632

— Майкл Хэмптон

@MichaelHampton Я понял, что должен перефразировать свой вопрос

— dukeofgaming

# 1 не является серьезным вариантом для производства; это в принципе никогда не должно быть сделано, если существует альтернатива.

— Майкл Хэмптон

@MichaelHampton Почему ?, данные не могут быть докеризованы, но хост-ОС все еще управляется командой инфраструктуры, которая контролирует и

— создает

@dukeofgaming Не говоря уже о том, что вы можете запустить btrfs scrubего, чтобы найти и исправить поврежденные файлы. Я не уверен, как работает dockerized, но я полагаю, что он не защищает от гниения данных, поэтому мне всегда нужно полное восстановление, если происходит что-то плохое, а не просто восстановление отдельных файлов. Еще одна мысль, что он добавляет еще один уровень абстракции, поэтому он еще больше замедляет чтение и запись файлов. Я почему-то не вижу преимуществ # 2 и # 3, но у меня нет опыта работы с докером, так что это может измениться.

— inf3rno

Ответы:

Я думаю, что # 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 8
drwxr-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 ls
DRIVER              VOLUME NAME
local               test

Это также открывает возможности для драйверов томов в будущем, чтобы вы могли создавать общие тома между хостами (т. Е. Именованные тома по NFS). Примерами этого могут быть Флокер и Конвой . В частности, в отношении перемещения или резервного копирования данных Convoy имеет специальные подкоманды для резервного копирования данных и позволяет хранить их в NFS или EBS, внешних по отношению к вашему хосту.

По этой причине я считаю, что более новым способом (Docker 1.9+) является использование именованного тома, а не контейнера только для данных.

— Энди Шинн
источник

Спасибо, вы ответили на большинство моих вопросов, но вопрос об управлении данными контейнера на другом уровне физического тома все еще остается без ответа, и это очень важный вопрос ... предположим, что это решение для управления git-репо, и мне нужна эта часть контейнера данные (т. е. том, определенный в файле Docker) в хранилище уровня 0, расположенном на другом физическом томе хоста (то есть другом разделе, физическом диске или чем-либо еще)

— dukeofgaming

Я вроде сделал с упоминанием водителей объема. Прямо сейчас, чтобы хранить данные вне физического драйвера локального хранилища, вам нужно будет использовать тот, который сделал именно то, что вы хотите сделать. Вдоль моей головы есть github.com/rancher/convoy и github.com/ClusterHQ/flocker . На данный момент Convoy поддерживает NFS и GlusterFS, что звучит ближе к тому, что вам нужно. Я изменю ответ, чтобы уточнить это.

— Энди Шинн

Использование драйвера устройства устройства, кажется, отвечает на мой вопрос, спасибо! docs.docker.com/engine/userguide/storagedriver/…

— dukeofgaming

the volume won't accidentally disappear if you remove the data-only container, Не могли бы вы уточнить? Спасибо.

— Стефан

Начиная с Docker 1.9, создание именованных томов с помощью API томов ( docker volume create --name mydata) предпочтительнее, чем контейнер томов данных. По состоянию на февраль 2016 года документация по томам Docker крайне устарела. Сами люди в Docker полагают, что контейнеры томов данных « больше не считаются рекомендуемым шаблоном », « именованные тома должны иметь возможность заменять тома только для данных в большинстве (если не во всех) случаях » и « нет причин, которые я вижу, чтобы использовать контейнеры только для данных ».

— Куинн Комендант
источник