Коллеги, вот думаю написать небольшую статью на Хабре о том, как я вижу главный косяк docker с точки зрения любого вменяемого сисадмина. И он - в практике применения, когда разработчики считают почему-то контейнеры помойкой, в которую они имеют право упаковывать какие угодно бредовые зависимости типа библиотечки, умершей ещё в 2011-м году. Эти зависимости там рано или поздно протухают, у разных контейнеров с примерно одними и теми же зависимостями - разные их версии, потому что разработчики свято верят в то, что с библиотечкой 1.31 их софт работает, а с 2.05 - уже нет, и это никак не исправить (потому что лень). Всё это легко можно исправить и делать вещи правильным образом. Но в реальной практике почти никто не делает так, и контейнеры превращаются в рассадник, где на 20% обновляемого актуального кода от разработчиков и 80% - непонятно откуда надёрганного никогда уже и никем не обновляемого кода от Васи Пупкина с гитхаба. Что думаете об этом? Может быть, моё видение ситуации слишком мрачное и в действительности проблема упаковки гниющих в контейнерах зависимостей успешно решается?

Коллеги, вот думаю написать небольшую статью на Хабре о том, как я вижу главный косяк docker с точки зрения любого вменяемого сисадмина. И он - в практике применения, когда разработчики считают почему-то контейнеры помойкой, в которую они имеют право упаковывать какие угодно бредовые зависимости типа библиотечки, умершей ещё в 2011-м году. Эти зависимости там рано или поздно протухают, у разных контейнеров с примерно одними и теми же зависимостями - разные их версии, потому что разработчики свято верят в то, что с библиотечкой 1.31 их софт работает, а с 2.05 - уже нет, и это никак не исправить (потому что лень). Всё это легко можно исправить и делать вещи правильным образом. Но в реальной практике почти никто не делает так, и контейнеры превращаются в рассадник, где на 20% обновляемого актуального кода от разработчиков и 80% - непонятно откуда надёрганного никогда уже и никем не обновляемого кода от Васи Пупкина с гитхаба. Что думаете об этом? Может быть, моё видение ситуации слишком мрачное и в действительности проблема упаковки гниющих в контейнерах зависимостей успешно решается?

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

Коллеги добрый день, подскажите плз. Нужен имейдж Кафки для arm(m1) желательно чтобы коннекторы из коробки были. Гугл ничего дельного не сказал, может кто то свой образ собирал?

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

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

https://habr.com/ru/sandbox/156808/

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

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

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

Вопрос (я не стал уже его освещать, иначе статью бы до нездоровых размеров раздуло) ещё в том, что традиционные unix-системы построены на идеологии разделяемого кода, это их краеугольный камень и во многом именно то, что обеспечило их популярность и на серверах, и в среде разработчиков. Сейчас же docker по сути является вещью, провоцирующей использовать подход как в экосистеме windows, когда каждое приложение таскает почти все нужные ему библиотеки с собой. Безусловно, всё это легко разруливается слоями, регулярным обновлением базовых слоёв, максимальным использованием одних и тех же слоёв в разных приложениях, но... если этого можно не делать, ни с кем не договариваться, ничего не настраивать, а просто пихать в свой пакет всё, что удобно данной конкретной команде разработчиков - так чего ж не запихать, кто помешает-то?

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

Коллеги, вот думаю написать небольшую статью на Хабре о том, как я вижу главный косяк docker с точки зрения любого вменяемого сисадмина. И он - в практике применения, когда разработчики считают почему-то контейнеры помойкой, в которую они имеют право упаковывать какие угодно бредовые зависимости типа библиотечки, умершей ещё в 2011-м году. Эти зависимости там рано или поздно протухают, у разных контейнеров с примерно одними и теми же зависимостями - разные их версии, потому что разработчики свято верят в то, что с библиотечкой 1.31 их софт работает, а с 2.05 - уже нет, и это никак не исправить (потому что лень). Всё это легко можно исправить и делать вещи правильным образом. Но в реальной практике почти никто не делает так, и контейнеры превращаются в рассадник, где на 20% обновляемого актуального кода от разработчиков и 80% - непонятно откуда надёрганного никогда уже и никем не обновляемого кода от Васи Пупкина с гитхаба. Что думаете об этом? Может быть, моё видение ситуации слишком мрачное и в действительности проблема упаковки гниющих в контейнерах зависимостей успешно решается?

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

Если это систематическая работа, а она должна быть систематической, то и не нужно будет править кучу мест и тратить много времени. К тому же, время разраба - это не то, чем он сам распоряжается и сам себе решает, что ему делать, а что нет. Это вопрос того, какие задания будут поставлены разрабу его руководителями (начиная тим-лидом и выше). Если руководители вменяемы, то они предусмотрят время на адаптацию к изменениям в экосистеме, если нет - у них будет Java 1.5, бережно хранимая в запасниках и библиотеки из 2008-го года. Я с таким сталкивался, но подобные вещи нельзя назвать иначе как разработкой по методологии "после нас хоть потоп"

Причём, в чем практическая проблема всякого такого разного в докере, безопасность- да, а ещё? Кроме мнения, что это «помойка некрасивая»

Я в статье немного написал об этом. Например, заменить Вас программистом со стороны с ходу будет проблематично, если там на древнем говне построена экосистема. Во-первых - как найти документацию по этим артефактам? Во-вторых - Вы сами-то любите возиться с лютым легаси, которое непонятно откуда взялось и непонятно что даст вам для опыта/резюме? Ну и, я об этом тоже упомянул, новые версии языка со старыми либами могут быть банально несовместимыми. Скомпилированные Java-классы из 2008-го не работают на современной JRE в 2021-м

Да при чем тут резюме, java. Аргумента кроме «красиво» - или «помойка». Если код работает, продукт или сервис реализуется, удовлетворяет бизнес интересам, интересам потребителей, продаётся в конце концов, и руководство понимает, как это будет развиваться. То лишние либы или пакеты в докере - это самое последнее о чем думают. Это все сверх идеализм, ничего общего не имеющий с реальностью. Более такой подход, на самом деле - вредный для «дела».

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

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

Не надо ситуацию доводить до абсурда, равно как и вылизывать код, который уже после завтра не понадобится

А что за странные заказчики, которым нужен код, но не нужна поддержка?

могу ли я как-то сказать докеру, чтобы при docker stack deploy он не останавливал уже существующие сервисы? docs.docker.com/compose/compose-file/compose-file-v3/#update_config есть stop-first, есть start-first, но не вижу опции, чтобы не останавливать сервисы вообще

могу ли я как-то сказать докеру, чтобы при docker stack deploy он не останавливал уже существующие сервисы? docs.docker.com/compose/compose-file/compose-file-v3/#update_config есть stop-first, есть start-first, но не вижу опции, чтобы не останавливать сервисы вообще

Предположу что раз нет в доке, то не сможешь сделать. А зачем вам вообще такое?

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

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

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

Несуществующую проблему? Правда? :) На серверах находятся активные игроки, просто так кикнуть их нельзя. Сервера - stateful, поэтому просто перенаправить трафик нельзя. Единственное решение: через апи сказать старым серверам перестать принимать новых игроков, дождаться, пока старые закончат свои матчи и выключиться, параллельно запуская новые сервера для новых игроков. Кажется, несуществующую проблему решить пытаетесь именно Вы :)

Сорян ребята, может вопрос туповат. Есть софт по линь для управления докерами? чет консоль в данном процессе мне не очень вкатывает

Несуществующую проблему? Правда? :) На серверах находятся активные игроки, просто так кикнуть их нельзя. Сервера - stateful, поэтому просто перенаправить трафик нельзя. Единственное решение: через апи сказать старым серверам перестать принимать новых игроков, дождаться, пока старые закончат свои матчи и выключиться, параллельно запуская новые сервера для новых игроков. Кажется, несуществующую проблему решить пытаетесь именно Вы :)

Кубер, portainer, rancher

Кубер, portainer, rancher

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

Это решается на балансировщике трафика, если он вообще у вас есть

Как это можно решить с балансировщиком? Я же указал несколько раз: попросту перенаправить трафик нельзя, состояние игрока привязано к конкретному серверу

Docker не запустился. Помогите в чем может быть проблема ?

WSL2, кажется, у тебя не включен... посмотри, какие шаги по мануалу будут достаточны - после каждого пытайся запустить докер, все оголтело не надо выполнять... https://docs.microsoft.com/ru-ru/windows/wsl/install-win10#step-1---enable-the-windows-subsystem-for-linux

Попробую. Что значить оголтело ?

WSL2, кажется, у тебя не включен... посмотри, какие шаги по мануалу будут достаточны - после каждого пытайся запустить докер, все оголтело не надо выполнять... https://docs.microsoft.com/ru-ru/windows/wsl/install-win10#step-1---enable-the-windows-subsystem-for-linux

Приветствую всех, подскажите пожалуйста, как запустить при старте контейнера сразу два .sh скрипта?

Приветствую всех, подскажите пожалуйста, как запустить при старте контейнера сразу два .sh скрипта?

А как же философия докера «один контейнер - один процесс» ?