Docker и организация хранения данных

Поставь ноду кубера. Задача от этого не изменится ничуть, зато посмеёшься.

Если бы существовал оптимальный вариант, других бы не существовало. Подумай об этом.

Оптимальный вариант для моего кейса…

мне всего лишь контейнеризация без заморочек нужна…

контейнеризация
без заморочек

Но контейнеризация - это уже заморочка

Окей, допустим.

Пока рассматриваю вариант 1 и 4 из списка.

Пока склоняюсь к варианту 4, т.к. через docker volumes легко рулить хранилищами и есть возможность лёгкой миграции в случае чего.

вопрос как правильно организовать хранение данных

Так а цель-то в чём? Чего добиться пытаешься?

Использовать bind mounts;

КМК, bind mounts не для этого. Это скорее опция для разработки.

Использовать плагин (драйвер) - local-persist;

Никогда не слышал о таком. Нашёл поиском - репозиторий архивирован 1.5 месяца назад без объявления причин. Т.е. точно можно исключить из альтернатив.

Нарезать блочное устройство на разделы и отдать контейнеру по разделу;

Жесть, как такое может вообще в голову прийти. Зачем?

Так а цель-то в чём? Чего добиться пытаешься?

Из коробки все генеририуемые контейнерами данные лежат в каталоге </var/lib/docker/…>, который находится в корневом разделе. Мне надо использовать по максимому 1 локальный диск (рейд) для данных контейнеров.

КМК, bind mounts не для этого. Это скорее опция для разработки.

Да, это даже в документации описано.

Никогда не слышал о таком. Нашёл поиском - репозиторий архивирован 1.5 месяца назад без объявления причин. Т.е. точно можно исключить из альтернатив.

Да, к сожалению, это не официальная фича, которая не завелась в Alpine.

Жесть, как такое может вообще в голову прийти. Зачем?

Набрасывал как вариант, но будет жутко неудобно всё это деплоить. Отметаю.

Пока остановился на варианте отдать весь диск под /var/lib/docker.

так ведь помимо gcc существует clang) А помимо иксов зачем-то появился вейленд)

Ты можешь докеру сказать где угодно хранить свои данные. Настраивается в /etc/docker/daemon.json

Вроде есть 3 варианта.

1. Монтирование из твоего п.1
2. Анонимус волум
3. Именнованый волум

2 и 3 хранятся в дире докера.

Но что ты хранить хочешь?

Базу данных, например?

Но что ты хранить хочешь? Базу данных, например?

Как выше писал, моя основная цель - утилизировать дисковое пространство рейд массива под контейнера докера.

Т.е. будут стейтефул контейнера, например, с постгресом или контейнера с генерацией контента (игровые серверами и т.д.).

/etc/docker/daemon.json

Спасибо, покапаюсь в доках.

контейнера

Ужас, зачем так писать? Это читается как родительный падеж единственного числа и портит предложение. Контейнеры.

Что касается твоего вопроса, то очевидный вариант 4, все остальные - какие-то глупости. Только тут, как уже уточнили, можно ещё сменить и путь хранения на другой - /var, который почему-то во всех дистрах под это дефолтно используют, совершенно неудачное место для таких штук (а ещё - для директории веб-сервера и для баз данных), это всё разумнее класть либо в /home либо в какое-то отдельное место. А /var оставить для системных файлов, не связанных с полезной нагрузкой сервера.

Т.е. будут стейтефул контейнера, например, с постгресом или контейнера с генерацией контента (игровые серверами и т.д.).

Я в докере нуб, потихоньку разбираюсь вот. Но мне думается - разве волюмы и для того и придуманы чтобы «выносить» стейт контейнеров в постоянное хранилище? Если правильно понимаю концепцию - сам контейнер должен быть легко заменяемым/обновляемым/выкидываемым и внутри ничего пользовательского быть не должно.

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

Как выше писал, моя основная цель - утилизировать дисковое пространство рейд массива под контейнера докера.

Тогда без разницы. Ты понимаешь, что разные способы организации хранилища придуманы не ради хорошей жизни, а из-за того, что они по-разному воспринимают нагрузку и по-разному решают задачи? И если ты не знаешь, какая у тебя нагрузка и какие задачи, то тебе всё равно.

Возьми смонтируй всё на /var, это самый простой способ, ничего настраивать не надо. Если упрёшься в производительность, приходи с конкретными вопросами.

Надо использовать флаг -v

Использовать плагин (драйвер) - local-persist;

This project is not really needed anymore, and is not being maintained. You can effectively accomplish the same thing with a local volume thusly (Docker Compose example):

volumes:
  my-volume:
    driver_opts:
      type: none
      device: /path/to/volume/on/host/
      o: bind

Вот и ответ?

Да, это тоже ответ. Спасибо! Я похоже не до конца прочитал доку…

Но пока думаю остановиться на варианте с монтированием диска в </var/lib/docker/>, т.к. это самый простой и надёжный вариант не запутаться в слоях.

Ну тогда тебе нужен только Podman.

Дома локальные тома использую, а на работе, так как тонкий лвм был уже до появления докера на том серваке - написал (взяв за идею другой заброшенный плагин) вольюм дрвйвер, который сам автоматически тома на тонком лвме создаёт. Худо-бедно эксплуатация уже к вторую пятилетку отмеряет

Docker нужно разворачивать в LXC-контейнере, иначе фиаско неизбежно.

А я наоборот ухожу от LXC в докер, т.к. у меня много LXC контейнеров стало и обновлять потроха каждого контейнера стало накладно в отличии от обновления докер контейнера.

А наработки не публиковались? Я даже в сторону LVM и не думал…

до сего момента - нет ))) стряхнул нафталин, выложил

Вариант 4 самый простой, если ты планируешь использовать volume-ы самого докера и по-минимуму использовать bind mounts за пределы /var/lib/docker. Мне volume-ы встроенные в докер не нравятся тем, что для отладки приходится идти в директорию с километровым хэш адресом, но это лично мои заморочки - так-то встроенные volume штука здравая.

1 вариант, все остальные приведут к потере данных

что для отладки приходится идти в директорию с километровым хэш адресом

docker run -it --rm -v my-volume:/data -w /data alpine:3.22

См. также docker cp.

Использовать bind mounts;

Вариант, если тебе это удобно с точки зрения конфигурирования. В случае, если у тебя все баловство будет в compose описано, это норм, наверное. Если без compose, то можно быстро запутаться.

Нарезать блочное устройство на разделы и отдать контейнеру по разделу;

Теряешь половину смысла контейнеризации.

Примонтировать диск к /var/lib/docker;

А вот это можно сделать настройками docker просто, но и да, просто смонтировать нужный раздел в эту точку никто не запретит.

Из того, что ты описал, кмк, оптимальным будет последний вариант.

1 вариант, все остальные приведут к потере данных

Поясни, пожалуйста, свою мысль. Почему и как остальные варианты приведут к потере данных? Демон-потерятор-данных украдет?

У меня один вопрос: разве конетйнеры могут в блочные устройства?

docker run –device …

Но чот сомнительно, что стоит, потому что так ты отдашь сырое блочное устройство одному контейнеру фактически.

Сам подумай

Не-не, я потому и переспросил, что не могу придумать. Поясни, пожалуйста, или подскажи, где и что почитать.

Блочное устройство — не обязательно является реальным диском. Можно так, например:

docker run -it --rm \
  --mount='type=volume,dst=/external-drive,volume-driver=local,volume-opt=device=/dev/loop5,volume-opt=type=ext4' \
  ubuntu bash

Придумать содержимое /dev/loop5 оставляю для вашей фантазии.

Нормальная идея, да, можно держать файловую систему контейнера в отдельном файле, но я на немного другой вопрос ответил: можно ли сырое устройство прицепить. И, в общем-то, можно.

у меня много LXC контейнеров стало и обновлять потроха каждого контейнера стало накладно

Про ansible не слышал?

Все разворачиваемые в lxc-контейнерах сервисы у меня описаны в плеях. Но плеи мне сейчас не помогут, потому что часть контейнеров запущена на базе арч линукса (так исторически сложилось) и приходится после обновления потрохов контейнера всё-равно руками лезть что-то ковырять/ремонтировать. В этом плане с докером проще - сделал резервирование volume, докер композом обновил контейнер - всё. В целом я с LXC сейчас мигрирую в докер как раз для того, чтобы уменьшить оверхед. + Я так и не понял статус LXC - будет ли он развиваться под управлением Каноникал или incus сейчас стоит брать.

часть контейнеров запущена на базе арч линукса

и приходится после обновления потрохов контейнера всё-равно руками лезть что-то ковырять/ремонтировать

Вся суть арча, негодный дистр. Настоящие джедаи сидят на debian и вообще никуда не лазают «ковырять/ремонтировать», в zabbix глянул раз в неделю и нормально, скрипты всё делают, аларм приходит только если железка накрылась, но это редко бывает.

Энивей, всё сводится к тому, что зачем делать LXC + Docker или LXC + сервис, когда есть Docker, которым из коробки проще оперировать?

ИМХО, любой дистр - это инструмент, который применим в определённых ситуациях. Арч для сервера - плохое решение (убедился на практике, но переделывать не стал). Но допустим для домашней печки он вполне себе хорош (10 лет использую без переустановки).

Арч для сервера - плохое решение

Арч просто плохое решение, для всего.

Но допустим для домашней печки он вполне себе хорош (10 лет использую без переустановки).

На DOS можно сидеть 10 лет без переустановки, но это не значит что ОС хорошая.

Docker, которым из коробки проще оперировать

Внушили вам так, поэтому проще. Проще всё на хосте поднимать, но это же теперь не модно. А насчёт дискуссий аля docker vs lxc, надо хоть основы знать и то и другое банальное namespaces и cgroups, обвешанное скриптами. 30 лет назад такое же делали, но это никак не называлось, потом обозвали chroot, а потом пошёл маркетинг, детям понравилось, но никакой глубины в этом нет, это тривиальные древние технологии. Скрипты типа docker написать совсем не сложно, а у современных «админов» и, прости хосспаде «девопсов» синдром утёнка.

namespaces и cgroups

Да, но насколько мне известно, Docker заточен на изоляцию процессов и контейнеры по большей части стейтлесс. А lxc среднее между докером и ВМ, контейнера стейтфулл и из коробки нет overlayfs, т.е. за содержимым потрохов контейнера надо как-то следить.

Скрипты типа docker написать совсем не сложно, а у современных «админов» и, прости хосспаде «девопсов» синдром утёнка.

Ну это, извиняюсь, дрочь. Я в своё время на хостах поднимал всякое. Вся эта контейнеризация - это очередной инструмент, который облегчает и ускоряет задачи по деплою сервиса.

Я LXC попробовал, 3 года крутились сервисы, но поддерживать LXC контейнеры у меня нет времени и сил - есть дела поважнее.

На DOS можно сидеть 10 лет без переустановки, но это не значит что ОС хорошая.

Обожаю такие холивары.

ОС - это инструмент. Он либо решает задачу как ожидается, либо нет. В моём случае - этот инструмент решает задачу, раз без переустановки столько лет прожил.

Арч просто плохое решение, для всего.

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

Я LXC попробовал, 3 года крутились сервисы, но поддерживать LXC контейнеры у меня нет времени и сил - есть дела поважнее.

А контейнер из «docker hub» by «хава нагила» с червями и закладками значит норм? Ну ладно, главное думать не надо :)

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

Но я больше зацепился за докер в LXC - так и не понял прикола.

докер в LXC - так и не понял прикола.

Очень смешная шутка, кстати.

На домашнем файлосервачке данные хранятся в отдельном каталоге для каждого контейнера.

а LXC - в виртуалке, а виртуалка - на Hyper-V

тевам и OS не нужно!

Сколько много слоёв пост-иронии, прямо как докер в LXC, а LXC в ВМ, которая на HyperV