Як визначитися між контейнером об'єму докера та обсягом докера?

Прочитавши документи, я трохи розгубився, як найкраще керувати продуктивними даними додатків / послуг.

Здається, є 3 варіанти:

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

Зараз здається, що прийнята практика - це варіант №2, але тоді мені цікаво, яка мета №3.

Особливо, як ви правильно поводитесь із цими сценаріями docker volumeі чи краще використовувати контейнер для обсягу даних або це для кожної ситуації?

Вам потрібні дані програми в окремому томі та / або рівні зберігання на вашому сервері
Резервне копіювання
Відновлення даних

storage docker

— герцогство
джерело

serverfault.com/q/576490/126632

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

@MichaelHampton Я зрозумів, що я повинен перефразувати своє запитання

— герцогство, яке стосується

№1 не є серйозним варіантом для виробництва; це взагалі ніколи не повинно робитись, якщо існує альтернатива.

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

@MichaelHampton Чому ?, Дані можуть не бути докерні, але хост ОС все ще керує командою з інфраструктури, яка здійснює моніторинг та резервне копіювання

— dukeofgaming

@dukeofgaming Не кажучи вже про те, що ви можете запустити btrfs scrubна ньому пошук і виправлення пошкоджених файлів. Я не впевнений, як працює докерізований матеріал, але я вважаю, що він не захищає від гниття даних, тому мені завжди потрібно повне відновлення, якщо щось погане трапиться замість того, щоб просто відновити окремі файли. Інша думка, що це додає ще один шар абстракції, тому він ще більше сповільнює читання та запис файлів. Я якось не бачу переваг №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+) є використання названого тома, а не контейнера, призначеного лише для даних.

— Енді Шінн
джерело

Дякую, ви відповіли на більшість моїх запитань, але питання щодо керування даними контейнерів у іншому фізичному ярусі досі не відповідає, і це найважливіше ... припустимо, це рішення для управління gpo repo, і мені потрібна ця частина контейнера дані (що є обсягом, визначеним в докер-файлі) у сховищі першого рівня, розташованому в іншому фізичному об'ємі хоста (тобто інший розділ, фізичний диск чи будь-який інший)

— герцогство з

Я начебто згадав про водіїв гучності. Зараз для зберігання даних поза фізичним локальним драйвером зберігання вам потрібно буде використовувати той, який робив саме те, що ви шукаєте. У верхній частині моєї голови є github.com/rancher/convoy та github.com/ClusterHQ/flocker . На даний момент у Convoy є підтримка NFS та GlusterFS, що звучить ближче до того, що ви хочете. Я модифікую відповідь, щоб уточнити це.

— Енді Шінн

Використання драйвера devicemapper, здається, відповідає на моє запитання, дякую! 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 самі припускають, що контейнери обсягу даних " більше не вважаються рекомендованою схемою ", " названі томи повинні мати можливість замінювати томи, що містяться лише в даних, у більшості (якщо не у всіх) випадках ", і " жодна причина, яку я бачу використовувати контейнери лише для даних . "

— Квінн Комендант
джерело