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

В виндовом контейнере на виндовом хосте.

На винфак, вантузятник!

Просто, кто-то там рассказывал сказки, что докер помогает что-то там переносить.

Кто рассказывал?

Ну и как ты собрался обновлять данные в докере?

Я собрался обновлять код приложения, а не данные.

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

И что? Кто-то обещал иное?

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

кроме

Тебе в другой тред, бедолага.

ansible-playbook

Отличная штука, используем.

Ты уж определись

Ты читать, к сожалению, не умеешь. Я использую docker для своих повседневных нужд. С ним оказалось проще расшарить инструмент кроме случаев, когда коллеги о докере не знают. Тогда все по старинке. Но, тот факт, что я завернул инструмент в контейнер, облегчает его встраивание в наш CI. В другом контейнере виндовое приложение, которое теперь можно масштабировать в рамках одного хоста. Это все наш CI.

Заказчики не приобретают наш CI, они приобретают наш продукт, который не зависит от нашего CI вообще никак. Их требования - работать в k8s-среде. В основном, это означает что-то типа соблюдения 12 факторов.

Я попытался придумать максимально комплиментарное объяснение их поведению. К слову, я и сам бы не прочь, чтобы все менеджеры-заказчки свалили в туман со своими требованиями и сроками, а я бы получил возможность любовно выпиливать лобзиком все компоненты в соответствии с моим чувством прекрасного. Но чтобы зарплату платили по-прежнему!

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

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

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

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

«Ваши автомобили не умеют летать, говно ваши автомобили, будем продолжать ездить на лошадях»

Тем же самым с теми же уязвимостями, известными каждому скрипт-кидду?

Зависит от твоей квалификации.

Согласен. И по другому не получится.

Докером можно сделать плохо, а можно сделать хорошо. Бандлингом можно сделать строго плохо. Ещё вопросы?

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

Какой в жопу десктоп? Кто вообще говорил про десктоп?

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

Тебе в другой тред

И чего ты тогда со мной споришь? И как соотносится твой аргумент против моей позиции, что докеру в проде не место: «мне проще когда заказчик не требует срончо» с тем, что ты докер в проде не используешь?

Докером можно сделать плохо, а можно сделать хорошо

Не хватает истории о том, что ЦА докера не берёт готовые образы с докерхаба за основу, а собирает свои с нуля.

Ты не сделаешь. Я сделаю:

FROM mcr.microsoft.com/windows/servercore:ltsc2019

А теперь я желаю тебе успехов повторить то же на седьмой или восьмой винде. Напомню, что семерка — это по прежнему 20% всего оффтопа в интернетах. Это уже не говоря о том, что образ 1903 не пойдет на 1709.

Я на контейнеры перешел после того, как в приложении с плагинным движком отвалились плагины

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

ЦА докера, увы, делает в своей массе плохо. Но готовые базовые образы с докерхаба к этой проблеме совершенно точно не относятся.

баш-портянка с debootstrap внутри (да что там debootstrap, банально скрипт ОПа с тарболлами, если он сборку своего тулчейна возложил на скрипт) имеет большую повторяемость

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

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

Восхитительно. ЧТД.

И чего ты тогда со мной споришь? Puppet/Chef/Ansible/etc - способ обеспечить это.

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

докеру в проде не место

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

на седьмой или восьмой винде

1. Нет такого кейса
2. Там можно и без докера, никто тебе его в глотку не пихает

это по прежнему 20%

Что за колхоз. Мы давно по соображениям ИБ на 10.

В FAQ py2exe вполне явно описано

Ну я же говорю, та слышал, но не делал.

Вообще, как я и ожидал, хейтеры докера на каждый чих предлагают новое обходное решение.

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

Никакой воспроизводимости и логов, кроме честного слова разработчиков, докерфайлы вида

FROM scratch
ADD rootfs.tar.xz /
CMD ["bash"]

не несут.

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

Единственная причина, почему вот это всё защищают — непонимание сути докера и светлый образ Чёрного Ящика, Который Не Ломается™. Хотя люди с таким светлым образом в голове, уйдя с винды, должны были уже начать что-то понимать. С пониманием ситуации Светлый Образ Того, Что Я Не Понимаю™ обычно рассасывается.

А ещё можно нарочно детородный орган дверью прищемить, а потом всем рассказывать про неправильные двери.

врёти так не бывает

Впереди тебя ждет еще множество таких же откровений. Не удивляйся.

Чёрного Ящика, Который Не Ломается™

Балабол.

Можно придумать защиту от дурака, но не от изобретательного.

Там можно и без докера, никто тебе его в глотку не пихает

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

Мы давно по соображениям ИБ на 10

Ты ставишь трояна в качестве операционной системы, а потом рассказываешь про ИБ.

Ну так-то я тоже делаю

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

Ты ставишь трояна в качестве операционной системы

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

я ничего не видел и прикинулся шлангом, где там ADD rootfs.tar.xz / ? Ничего не видно!

Они просят код, визжат, требуя пруфы, кричат на башпортянки, но не в состоянии прочитать даже докерфайлы из FROM и делают громкие заявления. Когда их тычут носом в докерфалы из FROM, они надевают шоры на глаза и всё так же талдычут свои громогласные заявления про Светлое Будущее Докера™, где всё за них уже написано.

Всё, ребята, свою дозу хохота на сегодня я получил.

P.S. Назвать универсальный инструмент менеджером помойки — это надо уметь.

где там ADD rootfs.tar.xz /

Есть два варианта отчего такое может происходить:

1. Вы профессионал и знаете что делаете и зачем. Тогда всё в порядке.

2. У вас слабоумие и тогда к вам вопросов никаких нет. А вот с HR нужно будет серьёзно поговорить, чтобы впредь не допустить таких проколов.

С другой стороны, ansible-портянки порой не лучше.

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

Но у нас нет прода, в котором есть докер. Прод с докером есть у заказчика, это заставляет заказчиков пересматривать свое отношение к инцидентам.

Это таки равно «мы используем докер в проде».

Пока в основном за счет низкой квалификации, но нам это на руку.

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

докеру в проде не место

Я с этим не согласен.

Давай поспорим.

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

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

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

Вопросы:

• Зачем нужен докер, если и без него всё уже работает?
• Как докер позволяет решить задачу «я купил сервер, мне необходимо его в прод включить»?

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

Но готовые базовые образы с докерхаба к этой проблеме совершенно точно не относятся.

ИМХО, это как раз его главная проблема. Кто туда напихал, что напихал, как напихал?

Ну и это тоже. У меня немного другая область - опенсорсы. Лепить там решения, с которыми потом справятся только гениальные анонимусы лора - не очень дальновидно.

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

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

Басни

админы локалхоста подъехали

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

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

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

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

Кто-то придумал инструмент для разработчика

Уже нет. Это один из слоев абстрагирования от железа и удобный примитив для оркестрации. SRE book в помощь.

Давай поспорим

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

разные версии одной и той же библиотеки

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

из области разработки или местечкового прома

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

Если лучший разработчик в компании не в состоянии написать плейбук, кто у них младшими научными работает? Технички?

Какой из сервисов заставляет тебя на одном хосте держать несколько разных версий одной библиотеки?

Уже нет.

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

Это как раз скорее из области разработки

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

Лучше бизнес оплатит несколько часов своему топовому разработчику один раз…

…и тот напишет контейнеризацию и оркестрацию.

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

И внезапно оказывается «бизнес» всё это и сделал.

На боевых серверах всё-равно будет одна версия, что «вашей практикой» и подтверждается.

Про green-blue deployment и A/B-тестирование не слышал?

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

бурить стены шуруповёртом

Не делайте так. Докер ни при чем.

На боевых серверах всё-равно будет одна версия

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

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

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в SCMS сидят.

Это как раз скорее из области разработки или местечкового прома.

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

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

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

Я этого не говорила.

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в SCMS сидят.

В моей прошлой конторе было пять датацентров, 600 серверов, 8 инстансов java-на сервер, оркестрация через salt и раскладывание джарников и их конфигов по серверам.

Первое, что сделали админы в этой компании - это для каждого джарника подняли свой инстанс tomcat в /opt. Потому что хотя tomcat вообще-то должен уметь крутить сколько угодно сервисов, на хайлоаде «так надёжнее». То есть на каждом серваке крутилось 8 разных томкатов из восьми разных распакованных архивов.

Ну и salt-конфиги, которые настраивали порты для этих томкатов - это отдельная песня. Потому что у джава-сервиса не один порт. У него один порт для web, один для jmx, один для debug, и один для админки. И всё это накостылено в помеси баш-скрипта с jinja-темплейтом.

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

Первый вопрос который я задала был - «почему шардов 8, а не 12». В ответ тимлид команды разработчиков разрыдался а тимлид команды админов возвел очи горе, и сказал что-то наподобие «вы, юные хипстеры просто не понимаете масштабов и сложности прода который мы администрируем, и бегаете тут со своими идеями. А я, админ с 20-летним стажем, и ответственно заявляю что в наших salt-конфигах инстансов сделано восемь от начала времён и изменить это физически нельзя.»

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

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

В итоге наши контейнеры состояли из одного базового слоя с jvm без всяких томкатов, и слоя на 1MB, в котором находился джарник с сервисом. На один сервак мы деплоили до 30 штук сервисов с динамическим шардингом, релиз занимал минуты, и у меня были метрики, админка, доступ к debug-портам и всё контролировалось напрямую разработчиками.

Так что да, оркестрация бывает разная. И её разную надо уметь готовить.

Вообще это был отличный обучающий проект на тему что такое хайлоад:

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

Решили что чего-то не хватает, добавили Kafka-сервис, куда все сервисы, базы и баш скрипты, в которых никто не может разобраться, стали сваливать свой debug-вывод. Получили high load.

Три года подряд на всех Kafka-конфах рапортовали «никто не процессит в Kafka столько трафика сколько мы!». Я каждый раз хотела сказать, может не надо столько мусора-то генерить?

При этом на каждый вопрос «а давайте что-то улучшим или поменяем» отвечали «вы хипстеры, что не понимаете, у нас хайлоад!»

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

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

предсказать заранее какие приложения будут работать одновременно на одном узле

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

Я говорю о совершенно другом подходе, когда кластеру совершенно всё равно какую нагрузку на нём гоняют. Подход «один сервер=одно приложение, которое на нём крутится» всё ещё применим в некоторых ситуациях, но в общем это уходящая натура.

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

один сервер=одно приложение

Это зависит от утилизации/роли ноды.

Нет разницы, кто у них работает, если дело движется.

Идеальные разработчики бывают только в твоем идеальном мире. А в реальном приходится иметь дело с теми кто есть на настоящий момент. Разницу между «хочется» и «приходится» улавливаешь :)?

Начнём с того, что твой идеальный язык - это жс.

Без докера оно, конечно, так сложно реализуется

Без системы оркестрации. А контейнеры проще оркестрировать

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