В чем плюсы контейнеров для разработки?

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

Я могу в разных контейнерах держать разные версии постгреса, python либ и не париться… И Докер образ ОЧЕНЬ маленький.

Да у каждого языка (почти) есть свой пакетный менеджер и какая-та вариация на тему виртуальных окружений. А если ещё добавить chroot, ip net namespaces, немножко iptables и слегка подмазать скриптами, то получится ничем не хуже, чем у докера. Но зачем?

Самое смешное то, что эти докеры популярны в той же жабе, или го. В которых данная проблема решена давно существующими вещами (система сборки, например).

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

Докер - это в принципе то что получается когда энтерпрайз-разработка пытается поделиться своими творениями.

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

Докер - это про так как сделать переиспользуемым одноразовое приложение.

Мне не важно, что там у заказчика, я ему образ предоставляю и знаю, что оно работает

Я работал с Docker но только в консольном виде. А может ли Docker предоставлять графические приложения, без учета всяких сетевых пробросов? Вот как есть образы Virtual Box с интеграцией окон

А может ли Docker запускать программы на другой ОС? Или это просто удобная паравиртуализация для Linux? Хотя этот второй вопрос я могу и сам поискать, просто не интересовался

А может ли Docker предоставлять графические приложения

Такой «докер» называется flatpack

А может ли Docker предоставлять графические приложения,

Может, только надо переменные окружения правильно выставить и /tmp/.X11-unix сокет в контейнер прокинуть.

думаю изучить всякие новые тулзы и прикидываю, стоит ли оно того

не стоит, не учи. если понадобится – скажи что на ЛОРе не убедили. все сразу поймут, что перед ними ценный специалист, чьё время стоит слишком много чтобы учить что-то, и обязательно перезвонят.

чем больше bloatware весит, тем более ынтырпрайзно и серьёзно выглядит для хипсторков

вероятно наступит боль и унижение, если ты не прокинешь ещё /dev/dri/* или /dev/nvidia*

А для разработки среднестатистического сервиса на той же Жабе мне все это нужно потому что?

Не знаю, я пару лет назад инетереса ради запускал в докере firefox и ещё что-то графическое, но так как дальше «ну надо же, оно работает» дело не пошло, подробностей уже не помню.

Технология предоставляет возможности. А уж как вы ими распорядитесь для своих задач —— дело ваше. К слову, а как вы тестируете свой среднестатический сервис на той же Жабе? Вот, нужно поднять на одном теством узле 25 экземляров сервиса, каждый из которых слушает 80-ый порт и прогнать разные интерграционные проверки. Ваши действия?

Вот захочешь ты что-нибудь нетривиальное сделать, например, мотор от Нивы в БМВ воткнуть, сервис тебя нафиг пошлёт, а Вася в гараже сделает.

Докер - это про так как сделать переиспользуемым одноразовое приложение.

Иными словами, как уже упоминал intelfx в похожем топике, Докер это способ поставки, а не метод деплоя приложения.

Ну да, все логично, исходим из потребностей конкретных задач, а про «веб-мастеров», ну заставь дурака Богу молиться :-)

поколение Z по-другому не умеет

Они передохнут, не переживай.

А может ли Docker предоставлять графические приложения, без учета всяких сетевых пробросов? Вот как есть образы Virtual Box с интеграцией окон

Это тупо обёртка вокруг chroot, namespaces и cgroups, а не то, что ты думаешь.

А может ли Docker запускать программы на другой ОС? Или это просто удобная паравиртуализация для Linux?

«Docker под мак/винду» — это тупо VM в Virtualbox, внутри которой крутится настоящий докер.

Докер это способ поставки, а не метод деплоя приложения.

Метод деплоя — это оркестратор, который возьмёт и из «где-то в реестре образов есть нужный» сделает развёрнутое по всем правилам приложение.

Вот, нужно поднять на одном теством узле 25 экземляров сервиса, каждый из которых слушает 80-ый порт

unshare/nsenter

каждый из которых слушает 80-ый порт

Восхитительная постановка вопроса — оправдывать неумение отвязывать программу от гвоздей докером. Когда приходит момент связывать сервисы в одном неймспейсе, будь то хост или pod, наступает заслуженная боль.

и баша

Казалось бы…

Расскажи, где это и как.

unshare/nsenter

Позволю себе автоцитату: Да у каждого языка (почти) есть свой пакетный менеджер и какая-та вариация на тему виртуальных окружений. А если ещё добавить chroot, ip net namespaces, немножко iptables и слегка подмазать скриптами, то получится ничем не хуже, чем у докера. Но зачем?

Когда приходит момент связывать сервисы в одном неймспейсе, будь то хост или pod, наступает заслуженная боль.

Расскажите мне больше об этом.

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

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

Мы вот хацкеллокод докером деплоим, хотя там один бинарник в образе и пачка файлов с ресурсами. А знаешь почему? Потому что при переходе с одной версии CentOS на другую понадобилось половину спеки переписать. В итоге мы прикинули, выкинули rpm spec и написали Dockerfile в три раза короче. И всё работает.

Алсо Kubernetes.

Но зачем?

Чтобы не пользоваться тем, чем не нужно, не загаживая себе мозги, ресурсы ОС (и не затрудняя общение с другими программами). Чрут при грамотной установке и отсутствии гвоздей не нужен. Сетевые неймспейсы не нужны, если все сервисы не смотрят безальтернативно на 80. Фаервол по большей части не нужен, если IPC делается так, как оно и должно делаться — через сокеты UNIX; и это я не говорю, что докер превращает чистую таблицу фаервола в кашу. Слегка подмазать скриптами — это не необходимость, а возможность. Тот же пресловутый тулчейн в архиве работает со скриптами гораздо проще, нежели автоматизируется образ + тулчейн с докером, особенно если принять во внимание, что человек точно знает, чего он хочет и собирает себе сам.

Расскажите мне больше об этом.

Так хардкод на двадцати недосервисах убирает специально обученный девопс или вопроса разработки системы в одном netns cтоять не будет никогда?

таскаешь его с собой между системами в виде архива

Но зачем, если с докером можно ничего не таскать? Пишешь Dockerfile, docker-compose.yml и Makefile, чтобы поюзабельней было, да сохраняешь прямо в репозитории.

Мне очень нравится иметь декларативное окружение.

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

Контейнер — это замечательный кроссплатформенный инструмент, который позволяет запускать твой код на любой ОС при условии, что эта ОС — линукс. Для лаконичности я опустил требование соответствия архитектуры процессора и наличие достаточно новой версии ядра.

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

Реально полезны контейнеры в случае, когда:
— нужно прогнать тесты на горе разных чистых окружений;
— у тебя в коллективе работают бездарные макаки, которые делают зависимость от мажорных, а то и минорных версий софта, и на других версиях он просто не работает. И если пакетные менеджеры еще способны поставить рядом девятый и десятый постгрес, то поставить одновременно 9.4.26 и 9.5.22 они не смогут.

Отвечая на вопрос:

Сейчас модно нахерачить целый докер образ и таскать его с собой.
Вопрос: в чем плюс подобного подхода?

Плюса никакого нет.

можно относительно легко вкорячить на одном линуксе рантайм и тулчейн разных версии ubuntu, debian и fedora (docker-образами) не выкаблучиваясь вокруг виртуалок

Да.

Потестировать на разных версиях Python-а, например, не выёживаясь с virtualenv

Конкретно это вообще не является проблемой, просто пишешь скрипт.

докер и кубернетис предлагают активно насаждаемый подход который скорее всего станет стандартом де-факто просто потому что это удобно

PHP — удобно; MyISAM в мускуле — вообще кайф, кончаю радугой; монго первых версий — просто стандарт в софтостроении. А докер, видать, завоевал доверие еще со времен, когда он уничтожал целые разделы с данными. Отличные истории. Запомни: качество, надежность, стабильность, производительность и удобство в современном IT не являются первостепенными качествами. Первостепенными качествами являются хайп и хороший маркетинг. Все пользуются, потому что все пользуются — вот и вся истинная логическая связь.

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

crosstool-NG не сложнее iptables. Хотя, у меня есть странное ощущение, что современные мамкины админы не умеют настраивать iptables.

Мне не важно, что там у заказчика, я ему образ предоставляю и знаю, что оно работает

У заказчика винда. Ваш ход.

У заказчика винда. Ваш ход.

docker-machine.

В ближайшем будущем — WSL2.

Специалисты никуда не денутся, их навыки не обесцениваются докером. Докер не про это, вместе с кубернетисом. Он про то, что есть у вас штат в некоторое количество администраторов(девопсов) и парк 10 тысяч серверов, и надо быстро просто и легко и главное единообразно разворачивать некоторые решения, поддерживать их и т.д. и т.п. Если каждый разработчик будет приходить к вам со своим тулчейном это быстро превратится в ад. А так вам дали инструмент который увязывает одних с другими и все это достаточно быстро и продуктивно

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

docker-machine

Виртуалочка нивелирует смысл докера.

В ближайшем будущем — WSL2

Ах, мечты-мечты.

В том, что Docker-образ можно развернуть везде. Хоть на старенькой машинке «одмина», хоть на сверхмощном сервере на том краю света. При стандартном подходе этот процесс растянулся бы во времени, а время — деньги

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

Виртуалочка нивелирует смысл докера.

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

Ах, мечты-мечты.

Попробуй заменить свой пук в лужу каким-либо осмысленным аргументом.

Виртуалочка нивелирует смысл докера.

Каким образом, позвольте узнать?

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

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

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

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

Починил.

Плюса никакого нет.

К сожалению, он есть. Докер — это очень удобная абстракция и обобщённое решение, которое работает всегда (в отличие от языкоспецифичных virtualenv, crosstool и т. п. местечковых костылей).

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

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

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

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

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

Починил

Ну статическая линковка же или тупо построение зависимостей в одном каталоге — неужели не понятно?

Докер — это очень удобная абстракция и обобщённое решение, которое работает всегда (в отличие от языкоспецифичных virtualenv, crosstool и т. п. местечковых костылей)

VirtualEnv и crosstool работают на других архитектурах, в отличие от. Да, проблемы у них свои есть тоже. не спорю.

А вторым является виртуалочка. Которая прекрасно работает на маке, винде, и фряхе, а не только лишь на единственном линуксе

А зачем плодить сущности? Контейнеры эффективнее виртуалочек — очевидный, объективный факт. Зачем поставлять один и тот же софт и в виде виртуалочки, и в виде докера, когда можно поставлять его только в виде докера, а там, куда докер нативно не встаёт — накатывать докер в виртуалочку?

Инкапсуляция и декомпозиция.

той же архитектуры процессора.

Это не является проблемой, man docker multiarch.

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

Потому что есть докер который и призван решить эту проблему в том числе

Докер стал пятнадцатым стандартом:

https://xkcd.com/927/

Который, в общем-то, побеждает остальные.

Зачем поставлять один и тот же софт и в виде виртуалочки, и в виде докера, когда можно поставлять его только в виде докера, а там, куда докер нативно не встаёт — накатывать докер в виртуалочку?

А я задам другой вопрос: зачем нужен докер и виртуалочка, если в итоге нам нужен тупо линукс?

той же архитектуры процессора.

Это не является проблемой, man docker multiarch

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

Ну статическая линковка же

Расскажи мне, как ты собрался статически линковать зависимости к программам на Python или Java.

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

VirtualEnv и crosstool работают на других архитектурах, в отличие от

Что значит «в отличие от»? 1) Докер прекрасно работает на других архитектурах, и 2) ещё раз напоминаю про docker multiarch.

или тупо построение зависимостей в одном каталоге — неужели не понятно?

Вы только что переизобрели докер, только хуже. Ну и зачем?

Позволяет хоть как-то делать виртуалэнвы в условиях импотентных пакетных менеджеров.

А я задам другой вопрос: зачем нужен докер и виртуалочка, если в итоге нам нужен тупо линукс?

зачем нужен докер

Чтобы под «тупо линуксом» было что запускать.

и виртуалочка

По твоим же условиям задачи.

Ловите адеквата.

Расскажи мне, как ты собрался статически линковать зависимости к программам на Python или Java

http://www.pyinstaller.org/

Что значит «в отличие от»? 1) Докер прекрасно работает на других архитектурах, и 2) ещё раз напоминаю про docker multiarch

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

Вы только что переизобрели докер, только хуже. Ну и зачем?

Нет, это докер переизобрел этот метод, только хуже — у докера нет простых путей сохранения состояния.

и виртуалочка

По твоим же условиям задачи

А по этим условиям будет виртуалочка без докера. Лишная сущность-с.

http://www.pyinstaller.org/

Местечковый языкоспецифичный костыль против обобщённого решения костыля.

докер не решает проблему запуска на другой архитектуре

А что решает проблему запуска на другой архитектуре?

Проблему запуска на другой архитектуре решает только сборка бинарника под целевую архитектуру.

Нет, это докер переизобрел этот метод, только хуже — у докера нет простых путей сохранения состояния.

Ну с какой радости? man VOLUME или docker run -v.

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

Позволяет хоть как-то делать виртуалэнвы в условиях импотентных пакетных менеджеров

Nix?