LINUX.ORG.RU

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

 ,


3

3

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

Сейчас модно нахерачить целый докер образ и таскать его с собой.

Вопрос: в чем плюс подобного подхода?

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



Последнее исправление: Trunk (всего исправлений: 1)

Ответ на: комментарий от winlook38

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

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

mogwai ★★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от mogwai

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

кроме

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

ansible-playbook

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

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

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

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

winlook38 ★★
()
Ответ на: комментарий от winlook38

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

ugoday ★★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от byko3y

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

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

intelfx ★★★★★
()
Ответ на: комментарий от winlook38

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

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

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

mogwai ★★★★★
()
Ответ на: комментарий от intelfx

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

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

mogwai ★★★★★
()
Ответ на: комментарий от winlook38

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

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

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от mogwai

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

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

intelfx ★★★★★
()
Ответ на: комментарий от mogwai

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

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

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

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

winlook38 ★★
()
Ответ на: комментарий от byko3y

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

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

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

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

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

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

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

winlook38 ★★
()
Ответ на: комментарий от byko3y

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

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

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

не несут.

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Балабол.

winlook38 ★★
()
Ответ на: комментарий от winlook38

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

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

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

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

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

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

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

winlook38 ★★
()

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

ugoday ★★★★★
()
Ответ на: комментарий от winlook38

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы:

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

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

mogwai ★★★★★
()
Ответ на: комментарий от intelfx

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

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

mogwai ★★★★★
()
Ответ на: комментарий от ugoday

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

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

Vit ★★★★★
()
Ответ на: комментарий от mogwai

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

Басни

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

anonymous
()
Ответ на: комментарий от mogwai

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

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

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

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

Vit ★★★★★
()
Ответ на: комментарий от mogwai

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

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

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

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

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

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

winlook38 ★★
()
Ответ на: комментарий от winlook38

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

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

anonymous
()
Ответ на: комментарий от Vit

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

mogwai ★★★★★
()
Ответ на: комментарий от anonymous

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

mogwai ★★★★★
()
Ответ на: комментарий от winlook38

Уже нет.

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

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

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

mogwai ★★★★★
()
Ответ на: комментарий от mogwai

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от mogwai

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

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

alpha ★★★★★
()
Ответ на: комментарий от anonymous

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

winlook38 ★★
()
Ответ на: комментарий от mogwai

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

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

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

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

winlook38 ★★
()
Ответ на: комментарий от alpha

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

mogwai ★★★★★
()
Ответ на: комментарий от alpha

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

mogwai ★★★★★
()
Ответ на: комментарий от winlook38

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

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

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

ugoday ★★★★★
()
Ответ на: комментарий от mogwai

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

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

Интересная компания у которой весь прод на единственном сервере крутится. А те, у кого сервер не один, те весь прод в одной группе в 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-портам и всё контролировалось напрямую разработчиками.

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

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 3)
Ответ на: комментарий от alpha

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

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

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

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

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

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

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

alpha ★★★★★
()
Ответ на: комментарий от ugoday

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

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

winlook38 ★★
()
Ответ на: комментарий от winlook38

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

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

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

winlook38 ★★
()
Ответ на: комментарий от mogwai

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

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

Vit ★★★★★
()
Ответ на: комментарий от Vit

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

anonymous
()
Ответ на: комментарий от winlook38

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

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

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

byko3y ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.