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

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

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

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

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

жду

Не дождёшься. Иди есть в другое место, зелёный.

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

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

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

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

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

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

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

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

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

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

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

У тебя там крутится джава и .нет. И ты беспокоишся о процессорных кешах?

У тебя там крутится джава и .нет

У меня — нет.

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

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

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

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

Ну да, а потом «ой, а чо эт рама на сервере кончилась, надо ещё рамы докинуть, чо как не в 21 веке».

Кому будет легче от того, что ты где-то сэкономишь 200мб, если речь идёт про жабку.

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

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

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

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

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

Если у тебя столь дикий хайлоад

Если там такой дикий хайлоад, то там такое дикое масштабирование и докер как раз таки друг, а не враг. Ну и вообще aws.

Сорян, гуляю, по диагонали прочёл.

Добавил в избранное, интересно...

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

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

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

Про podman, buildah, skopeo слышал?

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

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

Их используют полтора инвалида.

Про podman, buildah, skopeo слышал?

Какой-то стрёмный вендорлок. К счастью, мертворожденный.

Ах-ха-ха)

Какой-то стрёмный вендорлок.

Как ты живёшь в этом мире?

Docker не вендорлок по твоему, а podman и Ко вендорлок?

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

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

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

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

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

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

Юзкейс:

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

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

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

Требования:

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

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

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

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

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

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

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

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

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

А, и да

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

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

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

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

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

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

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

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

Так еще ж «виндовс-контейнеры» бывают, что есть особое извращение. Расскажи дотнетчикам — пускай порадуются.

Ха, вон поцоны из Cloudera вообще весь хадуп с его экосистемой в один докер образ пихнули и ничего, 4.5 гига весит, всего-то.

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

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

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

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

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

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

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

А сколько там средний размер образа у LXC? Он умеет делать хранилище образов с тагами, пуллить только небольшую часть, подписывать их и добавлять новые таги?

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

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

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

Да

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

Нет

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

Да

не хочу декларативности и стандартизации, хочу руками да вприсядку

Так никто не заставляет, делай что хочешь.

Ты щас описал 80% всего кодаа вообще.

тред не читал:

дохер нужен для того, чтобы админы перестали быть незаменимыми :)

Что-то пока не очень получается.

Что-то пока не очень получается.

Как говорится, это не ваша заслуга, а наша недоработка.

безадминские системы существуют жеж. оракель доказал

Особенно круто иметь возможность развернуть тестовую среду с помощью единственного docker-compose up.

Там сценарий использования другой, это классический контейнер типа Jail или virtuozzo, туда вся система разом упихивается, не смысла сравнивать.

«docker-compose up» покрывает первую строчку из таблицы.

Show me, show me, show me how you do that trick,
The one that makes me scream she said,
The one that makes me laugh she said

Не уловил твою мысль.