а нужны ли мне эти ваши docker-контейнеры?

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

У меня как бы две реакции на этот тезис. Одну уже написали, потому напишу вторую: ты прав, и я почему-то не задумывался серьезно над такой теорией принятия решений в индустрии. Ну типа «нам нужно сделать проект. На чем мы будем его писать? Конечно же на питоне. а репозиторий проекта будет на Git, а трекинг на Jira — потому что под эти инструменты самые дешевые специалисты на рынке, за альтернативы с нас потребуют дополнительной оплаты» — и вуаля, питонисты становятся одними из самых дорогостоящих спецов на рынке:

Спрос на питонистов [теория тупости]

А где-то люди пишут на руби и трекинг у них на Redmine.

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

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

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

Вот! Наконец адекватный сотрудник в треде.

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

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

Ну что за придирки к словам, ведь понятно же о чём речь. Это была аналогия к эмуляторам в их более широком понимании. Имелось ввиду что на сервере «аналог» содержимого «контейнера» кладётся в / хоста - это его основная ОС и она не контейнеризована.

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

Почему не нужно от же контейнер запускать на сервере? Потому что контейнер - это считай эмулятор сервера

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

Были б нужны, не было б вопроса.

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

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

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

Наверное и CI/CD тоже не нужен.

в принципе работодателю нужна только кнопка «что все работало на заеотлично» вот только погромисты все никак ее написать не могут.
придумывают всякие прокладкоконтейнеры, сфероконей и прочую науку хитровумную науку… :)

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

извините, не разобрался в тонкостях вашей религиозной системы

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

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

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

Про мак не знаю, а в винде в прежние времена было принято все зависимости программы или библиотеки таскать в её установщике. Они всё ещё так делают? Опять же, вспоминая буквы «dll hell» это кажется не очень помогало

Начиная с Win XP про DLL Hell уже никто не слышал. Я сам вкатился конкретно в компы именно с Win XP, потому с недоумением почитывал в интернетах страшилки про DLL Hell. Суть этой проблемы заключалась в том, что в какой-то момент было популярно считать, что срать своими библиотеками в С:\Windows\System32 — это круто, эффективно как по использованию оперативной памяти, так и место на диске экономит. Потом выяснилось, что если несколько программ делают то же самое, то как минимум одна из них перестает работать. Есть два вектора решения этих проблем: либо таскать все либы с собой, либо служба Side-by-Side, которая дает каждому приложению свою версию библиотеки. Последний вариант по результатам на самом деле совпадает со сценарием «таскать все либы с собой», потому да, таскайте все либы с собой на здоровье. А типа докер делает не то же самое?

А разница? Это уже есть и это не изменится никогда, значит нужно как-то пытаться выжить в данной ситуации

Это не абстрактная «ситуация», а конкретный банный питон. Та же нода, например, хоть и требует кучи мелких файликов, может работать из своего каталога независимо от остальной системы — потому что JS вырос из виртуального окружения. Питон вырос из окружения «идёшь, видишь, что на дороге насрано — сядь посри в эту кучу», Почему-то винда смогла решить похожую проблему конфликта софтин, хотя у неё наследие тянется аж с 80-х годов, когда винда еще 16-битнй была. Даже постгрес решил эту проблему, являясь изначально никсовой софтиной. «Просто, у нас принято срать на стул, на котором сидишь. Диды так делали, и ты делай». (извиняюсь за флешбеки после вчерашнего: За что я люблю никсовую консоль )

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

Дело в том, что докер решает проблему, которую призван решать. А нытьё «отчего люди не летают как птицы» не решает.

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

Ну переносят и переносят. Не вижу в том большой печали.

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

Т.е. винда решает проблему так же, как и докер. Ну, ок, пускай её. Здесь действительно мало что можно придумать. (хотя и можно, см Guix, например).

, а конкретный банный питон.

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

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

Это где такое? По моим наблюдением в реальности этот интервал составляет скорее пол-недели, максимум пол-месяца.

По поводу «хочется убрать препятствия для найма» — как говорил Станославский «не верю». Мой опыт найма говорит, что наниматели придумывают препятствия для найма чаще «от балды» чем для реального отсева. И, внимание, самый главный искуственный барьер... барабанная дробь... это знание языка программирования или другого инструмента администрирования/тестирования/разработки. Как правило, если вы ищете не сеньора с богатым опытом разработки на конкретном стэке для обучения джунов, то глубоко пофигу, на чем там до этого писал условный джуномидл, при условии, конечно, что работал он в смежных сферах (а не так, что PHP-кодера зовут писать CAD/CAM на Qt).

Ну и давай, покажи мне теперь тех самых людей, которые «максимально убирают препятствия для найма», которые максимизируют выбор кандидатов? Я за свою жизнь про таких слышал только в Google и Valve, и то для Google это актуально только после приема на работу, до приема ты будешь с утра до вечера переворачивать деревья на доске и десять раз рассказывать 2-минутные речи о том, почему именно тебя должны взять на эту должность.

Чего только не придумают чтобы jail не портировать...

Наверное и CI/CD тоже не нужен

Примерно так же некоторые считают, что CI/CD — это только GitHub/GitLab. Но CI/CD абсолютно ортогонален контейнерам, и если уж хочется чистое окружение на каждом подходе, то можно держать снимок VM под новую итерацию. Что, в принципе, довольно похоже на подход контейнеров — я просто подчеркиваю, что вариантов CI/CD может быть много, можно даже без VM это делать.

Дело в том, что докер решает проблему, которую призван решать. А нытьё «отчего люди не летают как птицы» не решает

Пардон, разве не мы с тобой в соседней ветке обсуждаем «почему заказчики выбирают именно эти инструменты реализации?». Заказчик выбрал участвовать в ралли Париж-Дакар на жигулях, теперь твоя задача, как исполнителя — накатить это всё на докер поставить на жигули полный привод и заставить его ездить быстрее 100 км/ч. Это вопрос уже не столько технический, сколько экзистенциальный, мол «зачем мы живем? Зачем мы страдаем? Что будет после смерти» — короче говоря, какая-то бессмысленная херня, которой ты занимаешься просто потому, что занимаешься. По сути, твой ответ сводится к «используем докер, потому что используем докер» — но это не ответ, это не решение, это просто «плывем по течению, зарабатываем, пока за это платят». Мне, как «художнику», неприятно было бы такой херней заниматься.

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

Ну переносят и переносят. Не вижу в том большой печали

Это я о том, что контейнеры сами по себе якобы что-то там решают. Докер для большинства людей решает проблемы, которые эти люди сами себе и создали.

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

Эм-м-м-м... я привел пример ноды, где такой проблемы нету, по большей части. Неужели трешак с PHP/Python/Ruby настолько всем проел мозг, что теперь это кажется единственным возможным подходом к деплою?

Он вообще у студентов популярен, я тоже его в свое время любил за портативность и везде тащил

BDB студни тоже тащили куда ни попадя?

Это где такое? По моим наблюдением в реальности этот интервал составляет скорее пол-недели, максимум пол-месяца.

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

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

Если с рядовым питонастом всё так печально, как я описал выше, то толкового хаскеллиста вы вообще два года искать будете.

можно держать снимок VM под новую итерацию.

Спасибо, я лучше пешком постою.

можно даже без VM это делать.

А сексом вы тоже стоя в гамаке на лыжах занимаетесь?

Что в ноде есть node_modules, что в питоне есть venv’ы. Код чисто на питоне запустить обособленно не особая проблема.

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

Да, часто есть архив с бинарной сборкой, но они могут не пойти на вашей подтухшей центоси.

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

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

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

интересно. минимальный докер-хост содержит в себе только докер и ssh или еще чего требуется ??

можно и без ssh

управлять по ком-порту ?? :)

А ssh уже в докере

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

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

Ну, как хотите. Однако ответ тот же, минимальный докер-хост кроме докера ничего не содержит.

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

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

Спасибо, я лучше пешком постою

В чем проблема? Это аналогичным образом дешманская операция, докер лепит те же снимки.

можно даже без VM это делать.

А сексом вы тоже стоя в гамаке на лыжах занимаетесь?

В чем проблема тестирования без VM? Если у тебя бинарь на Go, то ему все равно без какого VM работать.

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

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

И давно ты в последний раз собирал что-то для ноды с нативным API? Мне вот покамеся не приходилось. А питон весь из этого слеплен.

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

Я так понимаю, что ты сейчас про тайпскрипт и амазоновый API, где первый жирный просто потому, что это довольно сложный транспилятор на JS, а второй жирный потому, что Amazon всегда всё делает жирным — так лучше покупают. И как бы при чем тут hello world?

В чем проблема?

1. Закат Солнца вручную.

2. Изобретать поверх ВМ свою оркестрацию.

3. Ещё и сетевыми автообнаружениями заморачиваться придётся. Както же фронт-энв114 должен найти бэк-энв114 и не перепутать его с бэк-энв115.

4. Опа-опа, мы уже пол кубернетиса и написали.

5. А ещё вм медленно запускается, жрёт ресурсы и дисков на них не напасёшься.

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

В чем проблема тестирования без VM?

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

Если у тебя бинарь на Go, то ему все равно без какого VM работать.

1. Первый бинарь Go открывает порт 8080. Всё работает, тесты проходят успешно.

2. Второй бинарь открывает порт 8080 … упс. Кажется что-то пошло не так.

3. Третий бинарь отрывыет порт 8080, и всё снова работает, тесты проходят успешно (потому что первый набор тестов уже завершился).

Счастливой отладки.

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

А его нет. В докере ты придумываешь универсальный способ упаковки для линукса конкретных версий ядра. Для WinRT нужно будет упаковывать по-своему, для обычного десктопа — опять же по другому, для других никсов будет своя упаковка.

Я так понимаю, что ты сейчас про тайпскрипт и амазоновый API,

Ты знал! Ты знал! Да, я про AWS CDK, где конструк, который мне создаёт несколько IAM ролей весит 671Мб, вот, только-что проверил. Из них 200кб мой код, всё остальное нода накачала.

В докере ты придумываешь универсальный способ упаковки для линукса конкретных версий ядра.

s/конкретных версий ядра/практически любого линукса, который реально встретиь в продакшене/.

Специфичный язык, специфичный фреймворк, специфичный набор вспомогательных инструментов или производственных практик — шаг в сторону от попсы и ты попал на долгий и печальный поиск кандидатов

Почему? Каким образом одна половина этого тезиса связана с другой? Почему не «повесил морковку на входе в офис — и ты попал на долгий и печальный поиск кандидатов»?

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

Попытался запустить поделие наших фронтовиков недавно дебага ради, на каком-то node-sass споткнулось.

Ты путаешь контейнер и оркестратор. Такую шнягу и на pcmk поднять можно.

Если грубо и на пальцах зачем все эти баззворды:

• у тебя есть твой код. Чтоб он работал нужны либы, код плюс либы плюс сборка это приложение, например через npm/pip/maven
• Приложению нужна среда, это ОС с подготовкой типа terraform/puppet, либо чтоб меньше зависеть от внезапного обновления и нестыковки дистров это контейнер, например докер
• приложения должны взаимодействовать, для этого нужна сеть и что-то что знает кто где сидит, плюс контроль что все что надо живо, это оркестратор. Например сварм, кубы или pcmk
• приложениям нужен конфиг. Можно его нести скажем через темплейтер или через оркестратор. Это кубы (config map) или consul-template
• все это надо можно разбить по версиям, их можно хранить либо руками в гите либо в helm
• все это вместе - сервис для клиента, окружение. Его можно прописать одной спекой например через helmfile или чистый helm или compose и деплоить одной командой

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

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

У меня в прошлой конторе сказали Kubernetes - слишком сложный нам надо попроще, возьмём Nomad. Я три митинга пыталась донести мысль что Nomad хоть и проще, но не решает никаких из наших задач, и нам придется все эти решения дописывать своими руками, не прокатило. Запустили на Nomad. Написали половину кубернетесового API: я на ansible, соседняя команда на баше.

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

Написали половину кубернетесового API: я на ansible, соседняя команда на баше.

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

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

Положа руку на сердце, обратные примеры тоже бывают. Я как-то участвовал в проекте (меня заставили!), в котором 5 человек с кубренетесом, эластиксёрчем и самописным аналогом кафки два месяца ваяли проект, который моя мама сделалабы за неделю не выходя из экселя.

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

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

Наивные сисадмины потому что.

«Подумаешь, там всего лишь надо поднять несколько контейнеров, всего лишь каждый на своём порту, всего лишь как-то понять какой порт которому процессу сооответствует… Я это и без всяких оркестраторов могу!»

А потом выясняется что просто с нуля придумать схему именования тегов для контейнеров и описать её в документации - это задача на месяц. При этом в K8S она разумеется давно решена, протестирована и задокументирована со всеми частными случаями и сотней примеров.

И так бывает конечно. Overengineering никто не отменял.

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