Docker на домашнем сервере

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

насколько оправдано

Нинасколько.

какие я получу преимущества

Никаких.

При каких ситуациях раскрываются преимущества Docker?

Когда ты ленивый мудак-разработчик очередной ненужной вебни на заказ.

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

предлагается устанавливать в виде контейнеров Docker

Тогда, какие вопросы? Оправдано.

все это можно сделать и нативно, штатными средствами Debian

Классический анекдот-вопрос, вам шашечки или ехать?

При каких ситуациях раскрываются преимущества Docker?

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

Когда ты ленивый мудак-разработчик очередной ненужной вебни на заказ.

Очень категорично. Интересно, каким образом можно решить задачу того, чтобы все разработчики, которых может быть в проекте до нескольких сотен, могли работать в разных операционных системах и разных версиях операционных систем. Чтобы могли работать над разными версиями своего софта, например, два релиза назад использовали Postgres 12, а сейчас — 14. Мне надо исправить ошибку в старом релизе, т.е., я, как неленивый разработчик, должен снести из системы Postgres 14, установить (скорее всего через configure/make/make install) Postgres 12, исправить баг, сделать всё в обратной последовательности. И так может понадобиться несколько раз в день.

Каким образом можно реализовывать универсальные CI системы без Docker?

Да, удобство. Все можно сделать и другими средствами, но с докером это удобней.

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

Удобно как и для тестов/разработки так и для развертывания в проде.

Если достаточно всего из репы дистрибутива и в плане поставил и пусть работает (например, та же торрент-качалка) пока поддержка дистра не закончится, то тут докер не нужен.

Вообще вещь полезная, освоить не слишком сложно, это не кубер. Ну и на podman взглянуть советую.

Этот текст как-то связан с топиком?

Предыдущий камент спилили, я повторю суть иными словами.
Шли годы. Шли десятилетия. Мимо, на машинах с какими угодно шашечками, весело катались довольные люди, с недоумением поглядывая на суровых люниксоидов, до сих пор стоящих перед непростым выбором.

Мимо, на машинах с какими угодно шашечками, весело катались довольные люди

Кмк, точно описано преимущество использования докера перед классическим подходом - «суровых люниксоидов, до сих пор стоящих перед непростым выбором».

Ты уже определись, докер это «ехать» или «шашечки»?

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

докер это не золотая таблетка от всех болезней, а прикладной инструмент, имеющий свои плюсы и минусы.

если операционка конститента и все требующееся имеет в репе, то докер не нужен.

если систему собираешь «с мира по нитке», ставишь что-то где-то как-то «тяп-ляп и в продакшен» то наверное да.

Лучше Kubernetes, докер уже устарел. А так - без разницы, как тебе комфортней, так и делай.

принт-сервер .... в виде контейнеров Docker

Однако.

Ждём правил iptables в докере (это я фантазирую, хз что это может быть)

Ну я в кубернетесе запускал ваергард сервер. В нём были iptables правила для NAT. Работало. Не думаю, что в докере будут отличия.

меня в докере всегда раздражало то, что он пытается быть умнее юзера. Иерархическая организация слепков ФС, автоконфигурирование iptables – зачем это нормальному человеку?

ИМХО, для людей (не киборгов) гораздо лучше подходят контейнеры (LXC/LXD те же). Идеология проще и понятнее – это тот же chroot с кучей плюшек. Да кстати, а chroot сам по себе не пойдет?

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

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

Это не огромная проблема, можно написать правила фаервола, которые будут работать совместно с докером. Но это может стать неприятным сюрпризом.

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

Оно на домашнем сервере прям надо-надо???

Есть решение - и контейнеры и фаервол запускай/настраивай в одном ansible-плейбуке. И не настраивай сервера руками вообще. IaC или страдания, выбирай.

Домашний сервер это развлечение. Что там надо - зависит от того, чем тебе хочется упороться. Хоть хайку ставь с самописным HTTP сервером.

На мой взгляд поднять там кластер это прикольно и полезно для самообразования.

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

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

полезны изоляцией ... всякую фигню

lpd/cups, iptables, nfs, вот это всё.

А теперь если вспомнить, что вся подсистема Netfilter входит в network namespace…

Выкинь докер, используй lxc

я вообще настройку сети хоста в докере имел ввиду, ну ладно.

насколько оправдано

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

Ну так это, -net=host и можешь заворачивать firewalld в докер :)

ну а как мне вообще сеть не нужна в контейнере?

не нужна сеть в контейнере - не указывать при запуске порт, который выбрасывается наружу, логично же? или указывать порт, который контейнер будет слушать внутри бриджевой сети, но он не будет публиковаться наружу, чем не решение?

Джва чая этому господину!

Какое отношение среда разработчика имеет к сере пользователя?

У себя на хосте разработчик может творить любую дичь. Хочет с докером, хочет без него. А когда он свою среду пытается утащить на системы пользователя его продукта, то он или дурак (читай «не может написать, чтобы его поделие не падало от любого чиха») или, как сказал thesis, «ленивый…»

Каким образом можно реализовывать универсальные CI системы без Docker?

Сначала обоснуй нужность этого «универсального сияй сиди». И почему не работает apt-get update && apt-get upgrade.

При каких ситуациях раскрываются преимущества Docker

Вот прикинь что у тебя есть торрентокачалка на пистоне и скажем какая нибудь прикладнуха на нем же. Торрентокач сделан хипсторами под 3.10. Прикладнуха под 3.4. Часть вызовов в прикладнухе была deprecated уже тогда. Как запустить без геморроя и поднятия двух окружений руками?

Топикстартеру: главное не слушайте ругань :) Docker - это профессиональный инструмент, который больше нужен для построения сложных систем, а не на домашнем сервере, конечно. Это про облако, распределенные системы и прочий highload, когда нужно масштабироваться горизонтально в течение минут, а не часов и гибко реагировать на изменяющиеся нагрузки. Но…

Но и «для дома для семьи» вполне годится. Удобство по сравнению с пакетной установкой очевидное, можно описать весь требуемый функционал одним файликом и дальше повторяемо разворачивать его без плясок с бубном (docker compose имеется в виду).

Еще выше привели хорошие примеры с зоопарком версий. Эта проблема решается на корню. Можно рядом поднять разные версии одного и того же (например Postgres 11, 13 и 14 одновременно). Но, ИМХО, это больше важно и актуально разработчикам и редко нужно обычному пользователю.

Также бывает, что нужной версии софта в принципе нет в репо дистрибутива. Передаю тут привет Debian, например: все стабильное, но ссука, старенькое :)

Также бывает, что нужный софт есть либо в исходниках, либо на hub.docker.com и вот тут встает вопрос, что лучше, собирать его локально или взять готовые бинарники, работающие гарантированно одинаково у всех, т.к. все зависимости напиханы внутрь контейнера… Что выбрать для production среды?… Ну конечно билдить руками, ога :)

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

Насколько оправданно - ИМХО, правильный ответ выше уже был дан: узнаете о новом для себя инструменте побольше, получите новый опыт, если будет интересно сходить и покопаться в потрохах. Это раз. И два - вы же сами говорите, что этот ваш OpenMediaVault штатно предлагает устанавливать контейнерами. К чему сопротивляться решению, которое разработчики выбрали, наверное не зря, а подумав :)

Надо только иметь в виду, что за запуск прихожений в контейнерах придется заплатить небольшим оверхедом по памяти и диску, но, как правило, контейнеризированные приложения используют очень легкие базовые образы типа alpine (что-то окло 5 Мб, емнип) или busybox:glibc (что-то около 4 Мб). При нынешних параметрах железа - это ерунда, у меня в рабочем ноуте 40Гб оперативы, лол :)

О личном примере. У меня сервер для разных занятных экпериментов с кодом, там развернуты Rabbit, Redis, Postgres, еще там всякие мелочи и мои приложухи, которые всем этим пользуются. Вся среда разворачивается с помощью docker compose. Все что нужно - положить рядом код, пару конфигов, compose файл и сказать docker compose up. Поднимется вся среда, создадутся нужные БД, накатятся миграции, соберутся приложухи и оно просто молча взлетит. Повторяемо, на любой машине, куда бы я это ни принес… Вот вполне бытовой кейс.

Короч, Docker это не только интересно и увлекательно, но и вполне полезно даже на домашней машине :)

Вот такой наброс :) Всем удачи :)

Вопрос, когда у вас оно наворачивается, вы горько плачете или бегаете к ближайшей стене? :)

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

Ясно.

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

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

Убрать геморрой через скриптование поднятия окружения, очевидно же

Каким инструментом? Кондой? Пипенвом? Poetry? Или ставить все разом и потом получить сратое шапито вместо системы после пары десятков таких скриптов?

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

Nix

Чтобы могли работать над разными версиями своего софта, например, два релиза назад использовали Postgres 12, а сейчас — 14. Мне надо исправить ошибку в старом релизе, т.е., я, как неленивый разработчик, должен снести из системы Postgres 14, установить (скорее всего через configure/make/make install) Postgres 12, исправить баг, сделать всё в обратной последовательности. И так может понадобиться несколько раз в день.

Nix же

Каким образом можно реализовывать универсальные CI системы без Docker?

Nix же, ну.

А в целом контейнеры на домашнем сервере полезны изоляцией. Я часто всякую фигню пробую а потом удаляю.

Фуфу. Это же ужос! Пользователи, считающие себя илиткой, пробуют «всякую фигню» на localhost, считая его сервером, Карл!

Да в рот мне ноги! И зачёсывают с умным видом!..

Nix наверное крутая штука, судя по описанию, но не решает, например, проблему изоляции открытых портов/сетей.

Что, конечно, можно решить самостоятельно, скриптами, и в итоге получить тот же докер.

Который, кстати, в базовом виде реализуется скриптом на 50 строк на bash.

Но зачем изобретать велосипед заново, когда он уже везде есть?

Какое отношение «джокер» имеет к сетям ?

но не решает, например, проблему изоляции открытых портов/сетей.

Для разработки в этом мало смысла, а для деплоя можно собирать докер-образы автоматически через Nix с минимальными усилиями. Также можно использовать декларативные контейнеры NixOS, а для максимальной изоляции виртуализацией можно использовать microvm.nix. Мир на докере не заканчивается короче, есть варианты получше.

ДА как же? А автонастройка правил? Я фигею от ребят, которым скормили эту хрень.

Мало того, что не понимают, так теперь ручные. Без докера жить не могут.

Так к сетям это какое отношение имеет?

а я о чём пишу?

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

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

Ну И?

Docker, имхо, тут то ли не очень любят, то ли не очень понимают :)

Скорее всего, не разработчики, поэтому сложно понять, насколько сильно он облегчает разработку.