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

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

С айти на автомеханика соскакивал не я. Айти - это несколько другая отрасль, чем автосервис. Совсем другая.

+1

Можно таскать с софтом окружение.

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

А сколько систем сборки существует для С++ (conan и прочее)? Типа они тоже не умеют?

Почему не полноценный Linux на виртуалке? Потому что мне нужен только запуск приложения, а docker позволяет очень просто поднять контейнер, запустить приложение, остановить контейнер. Выглядит так, как будто просто выполняешь команду.

Для стильно-модно-молодёжной apt-системы, практически по-человечески:

which git || (sudo apt-get update; sudo apt-get -y install git python3-virtualenv)
if [ -x repo ]; then cd repo ; git pull;cd; else git clone $repo repo; fi
[ -x ~/.venv ] || python3 -m virtualenv ~/.venv
~.venv/python3 repo/main.py

Часть всего этого можно надёжно упаковать в скрипт внутри репозитория. Запускается в разы быстрее.

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

Это уже проблема воспитания. Кого родители зашугали — тот и боится.

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

Живём мы в этом вашем рыночке, при капитализмах. Поколение «Z» не настолько глупо, чтобы не видеть этого. Соответственно и ведёт себя также, выставляет напоказ то, что хотят видеть. И я не осуждаю. Сам был бы таким же. Но мне уже поздно меняться, да и не к чему. Жизнь надо посвящать вещам более приятным.

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

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

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

Инвалидация кэша — это долго. Необходимость ходить между окружениями — тоже долго. Железные докерфайлы по дефолту вместо отдельных команд тоже к быстроте не располагают. Отсутствие вменяемых манов, которые только написали не сразу — это вообще нонсенс.

Вот ты меня не понял. Хорошо, объясню иначе. Условный чел живёт в условном мухосранске. У него довольно редкий авто, а авторизированного сервиса в мухосранске нет. Его и не может там быть. Гонять авто в ДС? Дорого. Как быть? Вопрос решает какой-нибудь местный кулибин, к которому запись на полгода вперёд как к венерологу. Думаешь, ситуация редкая? Да как бы не так.

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

Кто хочет херак-херак и в продакшон, так они и девочке докер спецу платить не будут.

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

Без гарантии. И что дальше, если проблемы? В суд на него подашь?

У меня например так. На основной системе арчик, а компиляция программы и сборка её в deb пакет выполняется внутри контейнера с нужной версией убунты. Всё обмазано скриптами. Вызываю батник шеллскрипт, который запускает контейнер, всё там компилирует, собирает и отдаёт мне готовый deb пакет. Хипстер вей.

Вот. А ты ещё обижаешься, когла ваших из «Z» называют поколением, пиханных пальцем. Гонору много и пафоса, и ничего кроме.

И что дальше, если проблемы?

Устранит.

«Репутация». Открой словарь на букву «Р». Где-то после слова «Редиска» ты найдёшь его.

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

Тогда будет поздно.

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

Решение типа android открыто. Ничто не мешает использовать его для себя. Кроме огромного объёма тухлого кода и практически отсутствующей документации.

И кроме юзкейсов. Вся платформа Android на самом деле действует в интересах одной конкретной организации.

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

Без гарантии. И что дальше, если проблемы?

Если будут проблемы кулибин всё чинит за свой счёт. Потому что репутация дороже.

Это большие команды

Исправляюсь, большие команды — не выгодоприобретатели, а ЦА. Выгодоприобретатели — это хостеры и пердуны в уши навроде слёрмы. И гугли.

Вот и прошло поколение, не умеющее в LD_PRELOAD, chroot или статическую компиляцию.

Решение проблемы «на моем компьютере работает» и облегчение кластеризации.

Можно наплодить сотню аналогов make сложнее его самого, но проще аналогов я пока не видел.

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

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

https://aur.archlinux.org/packages/pbuilder-ubuntu/

Это как раз смузи проблемы не устранит, потому что оно дальше докерфайла не видит, а контейнер для него — это как VM, но не VM.

Когда смузи увидит проблему, оно полезет на stackoverflow, после первого же факапа от ответа (если он найдётся), смузи впряжёт того, кто дальше докерфайла таки видит и приберёт за смузистом его гуано.

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

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

Пардон, в некотором смысле докер и есть вот такой архив с библиотеками. Плюсами докера являются:

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

б) универсальность. Работает одинаково для С, питона, явы и вообще чего угодно.

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

г) изоляция (сетевая и дисковая).

Ну а что из этого надо конкретно вам, решайте уж сами.

Тогда будет поздно.

у открытых решений не бывает поздно.

Решение типа android открыто. Ничто не мешает использовать его для себя. Кроме огромного объёма тухлого кода и практически отсутствующей документации.

Тем не менее только ленивый сейчас не встраивает андроид в свое поделие. Китайцы с тобой не соглашаются.

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

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

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

Инвалидация кэша — это долго. Необходимость ходить между окружениями — тоже долго. Железные докерфайлы по дефолту вместо отдельных команд тоже к быстроте не располагают. Отсутствие вменяемых манов, которые только написали не сразу — это вообще нонсенс.

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

у открытых решений не бывает поздно.

COHERENT использовать не поздно? Открытое решение, если что.

Тем не менее только ленивый сейчас не встраивает андроид в свое поделие. Китайцы с тобой не соглашаются.

Встроить — дело одно. Действительно разбираться и тюнить внутри под свои нужды — дело другое. Встраивают его из-за распиаренности. В случае же затыка где-то в кишках андроида встраивающий горько пожалеет. Да даже не в кишках, обычные утилиты и вещи (aapt и его друзья, юзерлэнд Android, settings, properties) под Android докуметированы очень плохо, если вообще документированы. Системе в гигабайт 4-8 для сборки необходимо 100 гигабайт репозиториев, определённые версии Python и java, не учитывая блобы и патчи.

Китайцы с тобой не соглашаются.

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

Любой традиционный гнулинуксячий стек имеет всю документацию в /usr/share/doc, в виде info-документов и man-страниц, доступных прямо сейчас. Объём кода меньше, зависимости не настолько фиксированны.

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

Нет, это неудобно и непрактично. Удобно и практично это там, где

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

, то есть полный факап с точки зрения архитектуры, фич и всего остального.

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

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

А «изоляция» нужна чтобы случайно не загубить систему в попытках поиграться с версиями glibc или сделать rm -rf /*

какие есть у большого софтостроя

Ничего действительно полезного большой софтострой не делает.

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

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

Ничего действительно полезного большой софтострой не делает.

У «него» была необходимость, «он» сделал себе инструмент. Твое высказывание абсурдно само по себе.

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

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

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

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

То есть apt-get и virtualenv тебе доставляют невыразимые боли, так и запишем. Тогда всё ещё есть вариант c debootstrap, chroot и

tar c | ssh user@host «tar x; cd; sh sdelat-zakachaeshsya.sh»

Скриптец развертывания на коленке в пределах небольшой конторки в которой ты трудишься, и докер c к8с это вообще разного поля вещи.

А теперь обоснуй необходимость unshare по всем фронтам, полусотни правил фаервола, бриджа и гонений tar с недосервисами меж хостов.

Когда закончишь обоснование своей комбайнообразной тырпрайз-морды к неймспейсам и tar, пойдёшь обосновывать подход решения проблемы заваливанием её людьми (aka недосервисы).

COHERENT использовать не поздно? Открытое решение, если что.

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

Встроить — дело одно. Действительно разбираться и тюнить внутри под свои нужды — дело другое. Встраивают его из-за распиаренности. В случае же затыка где-то в кишках андроида встраивающий горько пожалеет. Да даже не в кишках, обычные утилиты и вещи (aapt и его друзья, юзерлэнд Android, settings, properties) под Android докуметированы очень плохо, если вообще документированы. Системе в гигабайт 4-8 для сборки необходимо 100 гигабайт репозиториев, определённые версии Python и java, не учитывая блобы и патчи.

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

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

Да-да азиаты сверхлюди. Они просто меньше болтают и больше делают, всего-то.

Любой традиционный гнулинуксячий стек имеет всю документацию в /usr/share/doc, в виде info-документов и man-страниц, доступных прямо сейчас. Объём кода меньше, зависимости не настолько фиксированны.

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

Нет, это неудобно и непрактично. Удобно и практично это там, где

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

, то есть полный факап с точки зрения архитектуры, фич и всего остального.

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

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

Если ты намекаешь на ядро

Я ещё и на BSD намекаю. У одной из них вместо бездумного добавления фич, судя по твоему безудержному желанию:

не такой уж и большой софтострой в плане вовлеченности всякого рода народа в процесс

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

ну и всем известно что линус ретроград и яростный неолудит

Луддит пишется через две «Д». Это раз. Вот мы и выявили апологета SaaSS и будущего с перманентой слежкой на сайте, посвящённому системе gnu. Это два. Возвращайся в твиттер или вконтакт. Это три.

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

У вас какугугла головного мозга, обратитесь к доктору.

Прости мне лень смотреть что это.

Тебе и на шелл смотреть лень.

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

Прямо сейчас сижу на такой системе.

Да-да азиаты сверхлюди. Они просто меньше болтают и больше делают, всего-то.

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

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

Доказательства в студию или ты шланг. Смузи-приложение — не доказательство.

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

За from-run-configure много денег платить не будут. За docker-compose up — тем более. Не сразу, конечно.

конторках

Какугугла.

в том что можно иметь полный набор всего того барахла, которое требует ПО ( те самые либы, той самой версии, и прочее ) и не поганить свою рабочую машину.

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

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

тогда слонов на картинке явно мало, их может быть больше!

можно вывалить своё дерьмо на сервера клиента и не париться о конфликтах с дерьмом, которое у него уже есть.

Ну, вообще неплохо, не?

Примерно поэтому, например, придумали «защищённый режим» процессора — чтобы одно дерьмо с другим никак не пересекались.

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

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

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

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

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

Да

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

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

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

А архив это просто свалка непонятно чего.

Архив — это архив. Это данные. Без ненужных метаданных навроде того, где этот архив создавался, без сотни тривиальных зависимостей и своей иерархии /etc/, без лишних копий systemd, man и тому подобного во взъерошенной /usr, обычно без сотен слоёв-подархивов, непонятно каким образом и для чего наложенных, без непонятного указания сменить неймспейсы и выставить наружу такие-то порты, без запрета на shm и /dev/. Из нужного только tar. Распаковал ручками ли, в шеллскрипте ли и пользуешься. При необходимости приправляешь сам неймспейсами и сигруппами.

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

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

на маке или винде

Не на маке или винде, а на VM, живущей на маке или винде. Про твои поползновения на мак и винду уже не буду.

И в последний раз за свалку:

https://www.bleepingcomputer.com/news/security/17-backdoored-docker-images-removed-from-docker-hub/

https://arstechnica.com/information-technology/2018/06/backdoored-images-downloaded-5-million-times-finally-removed-from-docker-hub/

По мотивам http://lorquotes.ru/view-quote.php?id=5885 предлагаю тебе сменить init на один большой docker-compose, а системные сервисы крутить в докере.

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

плюс в том, что это песочница, минусов особо нет

Да, твой юз-кейс оправдан. У меня немного другой - разработка линукс приложения под линуксом.

вот скажите мне, разработчик линукс-приложений под линуксом, как вы поступаете в ситуациях, как вы тестируете разворачивание приложений в вашей системе, когда у вас одно разрабатываемое приложение использует libc строго = 2.xxx, а другое libc строго = 1.yyy ?

да и в общем случае, одна приложуха у вас скажем под Debian, а другая под OpenWrt, как вы деплой тестируете?

А можно выкинуть докер и docker-compose, взять системный init (например systemd) и крутить podman-контейнеры как обычные сервисы.

Не надо путать контейнеризацию с оркестрацией. Совершенно не каждый контейнер надо запускать из k8s-кластера.

Если у языка есть нормальный ПМ - то незачем.

Б-же, какой тупой анонимус.

https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0

Например, ты разраб аппликух, и есть SDK, который тебе необходим. Этот SDK может поменяться когда угодно и другой командой или там какая-то своя интеграция сложная с 10 подрядчиками, с которой у тебя связь через 5 уровней начальства. И просьбы какого-то васяна, который успешно пилил свой опенсорс, компиля все с нуля на одном компе - их они пошлют молча на уйх. У тебя есть возможность собирать на билдсервере, у себя на компе в нативном линуксе, на венде с виртуалочкой. И везде будет одна и таже воспроизводимая среда сборки. А как ты всем этим будешь управляться на куче дистров линукса, когда у тебя не только кросскомпилятор с рутфс, но и хренова куча базовых зависимостей (некоторые - проприетарные блобы) плюс всякие скрипты от интеграторов/тестеров?

когда у вас одно разрабатываемое приложение использует libc строго = 2.xxx, а другое libc строго = 1.yyy

Такой большой дяденька, а про LD_PRELOAD и чруты не слышал. Стыдно!

Я исхожу из общеупотребимой практики «накидать из докерхаба, а вместо опций рантайма сделать yaml», а ты исходишь из мира розовых пони.

взять системный init (например systemd) и крутить podman-контейнеры как обычные сервисы.

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

Впрочем, init-скрипт и приложение, деплоящееся по-нормальному, всё равно лучше podman-контейнера. Зачем эти лишние телодвижения?

на венде с виртуалочкой

А комментарии про то, что putty.exe и virtualbox.exe — лучшие друзья, будут почему-то в новости про BSD.