LINUX.ORG.RU
ФорумAdmin

Зачем нужен Docker, если изучил Linux namespaces & CGroups и LXC/LXD?

 , ,


3

4

Салют, бродяги!

У меня вопрос, а зачем нужен Дохер?

Я реально не пойму. ИМХО я херею с людей на фирме:

- лагерь дотнетчиков

- лагерь жабистов

свою лабуду они запускают в Дохере... в Дохере же юзается (загибаем пальца):

1. runC

2. шимы containerd

3. containerd демон сам

4. демон Дохера, тоже сам

5. под капотом сиё добро юзают namespaces, cgroups и SELinux или AppArmor (в зависимости от дистра)

лабуда с пункта №1 по №4 - жрет ресурсы... если, это сиё еще в Кубернетесе... то 20-30 микросервисов Жабы, сожрут много ресурсов, и в целом... возни с обслугой сего добра (хелс-чеки, ридинесс-пробы, выставлени лимитов для Cgroup, тюнинг нод Кубера, где этот Дохер работать будет)

зачем???? вот, не проще бы народу юзать LXC/LXD?

1. Dockerfile? а чо, это не тупо bash-скрипт? ну да, есть там: FROM и multistage-билды... но, при прямых руках сие можно повторить в плане автоматизации и с другими технологиями

2. иммутабельные слои (или как там это хрень?) ну... когда билдили FROM scracth - Гошники свои имаджи - еще куда не шло, НО! у сранных жабистов с их SpringBoot, Hadoop и прочей хренью выходят огроменные размеры этих Дохер-образов

сижу и матерюсь... да, бродяги... я ною, да я знаю, что всем пофиг... но, я все равно поною...

мне надоел Дохер... его суют уже во все щели, без мысли - надо или не надо... мне этот Дохер снится в кошмарах уже...

PS: покидайтесь пометом в меня, жду


Dockerfile близок к декларативщине, а вокруг докера шикарная экосистема для автоматизации. Быстро, классно удобно.

лабуда с пункта №1 по №4 - жрет ресурсы…

Бред, жрётся диск, да, есть накладные расходы на сеть, в остальном там не жрётся примерно ничего.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Оперативная память, кеши, TLB. «Примерно ничего» my ass.

Правильное использование докера — это собирать все свои образы самостоятельно из единого (своевременно обновляемого) базового образа. Тогда оверхед минимален, но он всё равно есть, и это плохо.

intelfx ★★★★★ ()

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

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

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

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

anonymous ()
Ответ на: комментарий от intelfx

Докер — не мёртвый груз, а это не значимый оверхед. Если запустить сервис, который что-то активно логирует, под systemd, то journald наверняка ещё и больший оверхед даст. Ты про какую-то экономию на спичках втираешь.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

Докер — не мёртвый груз, а это не значимый оверхед.

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

Ты про какую-то экономию на спичках втираешь.

Экономия кэшей и TLB за счёт использования динамических библиотек по назначению — экономия на спичках?

Лол, иди учи матчасть.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Я тебя попутал с ТС

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

Если у тебя столь дикий хайлоад, что из-за этого заметно сильное изменение скорости, то да, возможно стоит запускаться на голом железе без всяких докеров и вообще контейнеров.

В остальных 99.99999% случаев об этом можно не беспокоиться.

anonymous ()
Ответ на: комментарий от intelfx

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

anonymous ()
Ответ на: комментарий от intelfx

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

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

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

вытеснено докером

Да хотя бы читать научись сначала.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

даже правильно собранный базовый образ всё равно дублирует библиотеки базовой системы, и это оверхед

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

Deleted ()

Ой, подумаешь. Я вот знаю чуваков, которым впадлу IDE ставить на компы и они все в один докер образ закрутили. И IDE, и девелоперские зависимости. Монтируют в контейнер хомяк пользователя и радуются.

Смогли бы они так без докера? Конечно смогли бы! Но тогда пришлось бы подумать сначала, а потом отказаться от этой идеи из-за ее бесмысленности. А так, не приходя в сознание, нахерачил докерфайл и радуешься.

Deleted ()
Ответ на: комментарий от Deleted

Тогда в идеале следовало бы заменить базовую систему.

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

Гораздо большую проблему представляет безалаберное использование самого Docker-а и неправильная работа с базовыми образами.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 4)

докер костыль, nix для деплоя лучше идет. Тоже тащит совместимые между собой зависимости, тоже окружение настраивает, НО не тащит образ системы с кучей лишних утилит.

SR_team ★★★★ ()

Сам по себе докер нафиг никому не нужен, это просто деталь имплементации деплоя.

Юзкейс:

* моё приложение — это 15+ связанных между собой (разных) сервисов

* у этих сервисов могут быть несовместимые друг с другом версии. Поэтому каждый сервис включает manifest с описанием того, какие версии прочих сервисов он ожидает

* есть load balancer, который может раскидать нагрузку на N машин с одинаковыми сервисами. Вообще, load balancer есть практически везде * есть CI/CD система, которая умеет более-менее автоматически обновлять все эти сервисы в продакшне.

Требования:

* тупо возможность по-быстрому добавить машин с определённым сервисом в зависимости от нагрузки

* не сойти с ума при поддержке разных версий (а они есть как минимум во время обновления)

Ты *можешь* написать гору bash-скриптов для того, чтобы всё это задеплоить. Но деплой terraform + тот же k8s или ECS — удобнее ментейнить, а внутри ecs/k8s есть docker.

Если же у тебя монолитное приложение и/или load balancer отсутствует — конечно, тебе это нафиг не нужно (ну, CI может быть чуть удобнее с докером или другими контейнерами, но это не критично). Но писать деплой-процесс для high available-приложения, состоящего из уймы микросервисов, довольно сложно.

x3al ★★★★★ ()
Последнее исправление: x3al (всего исправлений: 1)

Ага, ты ещё подмана вспомни.

Вокруг чего комьюнити крутится, на том всё и мутится.

О симбиозе жабыдла с доцкером (и женкинсом, ага) вообще озуительные истории имеются, но это будет оффтопом.

Для обычных же херов с горы на доцкерхабе имеются рецепты на все случаи жизни. И сила доцкера именно в этом, а не в навороченных слоях внутри. То есть да, всё то же самое можно наворотить и подманом/тулбоксом, и голым LXC, но зачем лишний раз лохматить бабушку? И даже не по работе: что проще при статической пересборке под armhf — пердолиться (особенно на маке) с тулчейнами или просто жахнуть docker pull multiarch/crossbuild?

Так что причина популярности сего поделия вместо LXC примерно такая же, как и причина популярности убунты вместо LFS. То есть последнее использовать тоже можно, но подавляющему большинству, которому надо работу работать, нафиг не нужно.

rebforce ()

А, и да

то 20-30 микросервисов Жабы, сожрут много ресурсов

При самом худшем раскладе — процентов 5 от того, что выжирает сама жаба.

я херею с людей на фирме

Я тоже, но они деньги считать умеют. Затраты на голый LXC точно не окупятся.

rebforce ()
Последнее исправление: rebforce (всего исправлений: 1)

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

PolarFox ★★★★★ ()
Ответ на: комментарий от intelfx

Гораздо большую проблему представляет безалаберное использование самого Docker-а и неправильная работа с базовыми образами.

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

rebforce ()

Жабо контора, на всех девелоперских машинах docker вне зависимости от платформы хоста, т.е. widnows/linux/mac. Получамый энвайромент у приложения на компах девелопера близок к проду. Юнит тесты запускают контейнеры в которых например может быть база, На хосте девелопера должна быть жаба, maven/gradle, ide, docker и git, и все, девелоперский комп готов, никакого дополнительного конфигурирования. Команда распределенная.

anonymous ()

Собственно, а в чём проблема?

Я против нытья ничего не имею, сам это дело люблю, но было бы интереснее, если бы выразили свою неудовлетворённость в формате:

- проблема :: Что, собственно, вас беспокоит. Причём не в формате «ну, какое-то оно такое-нетакое» а с цифрами.

- требования :: Ограничения, которым должно удовлетворять приемлемое решение.

- приёмочные критерии :: Как вы узнаете, что получили то, что хотели.

Ну и после этого уже можно будет судить лучше ли Docker своих альтернатив.

ugoday ★★★★★ ()
Ответ на: комментарий от vrutkovs

А сколько там средний размер образа у LXC?

Такой же как у docker

Он умеет делать хранилище образов с тагами

Да

пуллить только небольшую часть

Нет

подписывать их и добавлять новые таги

Да

anonymous ()