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

это ты клинический случай. система в продакшне должна работать на нескольких хостах, на каждом сервис должен выставлять 80й порт. или 443й, или 1488й. потому что должен, потому что продакшн так сделан. твой пердолинг «systemd встанет — переопределится» никак не поможет протестировать конфигурацию, которая будет в продакшне

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

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

Благо для кого? Я вижу благо лишь для фирм, которые нанимают бездарных кодеров и чудом запускают их поделия в контейнерах. И то это только серверный софт, клиентский в таких случая предпочитают писать на браузере. Для обычной эксплуатации софта докер бесполезен, поскольку не позволяет просто написать «docker install gajim» и началь пользоваться жабером без дополнительных запаров, вроде монтирования профилей, /dev, для звука и видео, /run для dbus, и прочих шалостей — внезапно выясняется, что система цельна, а не собрана из набора независимых сервисов. Собсна, точно та же проблема у вас возникнет, если вы рискнете сделать на докере тесно связанную серверную систему вместо stateless сервисов.

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

Запускаю 25 экземпляров на разных портах

Как?

Согласен, контейнер тут к месту.

Однако, если тестовое и рабочее окружение должны быть максимально унифицированы, то докер на CI означает докер и в проде.

Правильно написанный софт

А, ну тогда проблема решена. Осталось весь софт правильно переписать и дело в шляпе.

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

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

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

Прогресс? Не вижу прогресса. Упомянутые мной проекты были одним сплошным косяком, единственный способ сделать правильно был «не делать их». Собсна, создатель PHP так и грил «я не умею делать языки программирования, я не собирался делать ЯП, я просто не знаю, как это остановить».

Зато без лишнего звена

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

И тот же процессор. Везде есть грань полезного и удобного.

Наличие спецификации против её отсутсвия, выбор очевиден.

Именно то, о чем я говорю, вместо того, чтобы передать порт конфигурационным параметром

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

На 2.6 ничерта ты не развернешь

Этот хейт слишком тупой, не позорься

RHEL 6 на 2.6 и до сих пор поддерживается. Седьмой дебиан на 3.2, на котором не запустится докер, но уже не поддерживается. Не каждый заказчик по три раза в год новый дистр на сервер ставит.

И тот же процессор.

Готов допустить, что бывают случаи когда это важно.

Везде есть грань полезного и удобного.

Докер это полезно и удобно в большинстве случаев.

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

Ты большой молодец, что всё это написал, но nix и docker практически ортогональны друг другу и вообще решают разные проблемы. Мы, например, никсом собираем докер контейнеры с нашим софтом. Брат жив.

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

Писать сервис время было, а запускать его времени нету?

Вторые два тезиса решаются при помощи добавления одного флага запуска этого самого бинарника и примитивного chroot-а.

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

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

Ты большой молодец, что всё это написал, но nix и docker практически ортогональны друг другу и вообще решают разные проблемы. Мы, например, никсом собираем докер контейнеры с нашим софтом. Брат жив

Это какие же разные проблемы? Разве проблема не одна и та же — обуздание разных версий на одной машине?

Некрофажьи проблемы.

Писать сервис время было, а запускать его времени нету?

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

Писать сервис время было, а запускать его времени нету?

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

И что, связи между ними нет?

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

Разве проблема не одна и та же — обуздание разных версий на одной машине?

Глобальная проблема – это деплой приложений. То, что могут быть пересечения зависимостей, это лишь одна из частей этой проблемы. Есть ещё масштабирование и прочий геморрой. Docker и инструменты вокруг него, например K8s, решают их. Nix их не решает.

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

И что, связи между ними нет?

Не понял вопроса.

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

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

И что, связи между ними нет?

Не понял вопроса

«Вася, собери мне свой кусок дерьма в один бинарник пожалста»,

Проблема только в том, что только у тебя. Я если Васян-сосед захотел как у тебя, но у него yum вместо apt, то начинается скулеж «ну там просто надо поменять это на это… найди в какой репе лежит это… я же не знаю как у вас там это….»

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

Писать сервис время было, а запускать его времени нету?

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

«Вася, собери мне свой кусок дерьма в один бинарник пожалста»,

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

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

Как я смог сразу узнать, что ты гуманитарий?

Так не уж не любопытно потыкать в новую хайповую штуку?

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

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

Товарищ предлагал бандлить каждое приложение руками или собирать статически. Найдите десять отличий

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

Дебилы дебилами, а ничего лучше докера никто из участников треда, увы, так и не предложил

Почему-то в этом треде редко упоминается, что есть ряд задач, для которых докер бесполезен, как то десктоп и связанные приложения, в том числе отладка, поскольку настроить их полноценную работу в докере сложнее, чем написать скрипты для сборки. Я уже ответил на эту тему, просто дублирую: В чем плюсы контейнеров для разработки? (комментарий)

Причем, тарбол с run.sh как раз для таких задач прекрасно подходит и часто применяется.

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

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

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

Что вы имеете в виду? Это звучит как «язык $ProgramLanguage отстой. программы работают, только если программисты их правильно написали!!!». Наверное вы что-то другое имели в виду, но что?

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

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

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

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

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

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

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

это ты клинический случай. система в продакшне должна работать на нескольких хостах, на каждом сервис должен выставлять 80й порт. или 443й, или 1488й

И это неправильный ответ. Напомню, что изначально LXC разработаны гуглем для балансировки нагрузки огромного числа серверов еще большим числом сервисов. Если у тебя «один сервис - один сервер», то тебе вообще контейнеры не нужны, ты можешь поставить единственный набор версий софтин на комп, и забыть про докер. Докер нужен именно тогда, когда сервисов нужно запустить много, когда один сервис работает в нескольких экземплярах на одной машине, а на другой его и вовсе пока что нету. Всё это дело, естественно, нужно связать оркестратором, мол «сюда ходи, сюда не ходи». но в индусоконторах эта идея, естественно, вырождается в полную порнуху, когда на хосте до сих пор крутится какой-то говносервис на порте 80, написанный уволенным сотрудником, но никто не рискует его останавливать, потому что вдруг он что-то важное делает, и перекидываю контейнер на 81 порт.

Запускаю 25 экземпляров на разных портах

Как?

А как я запускаю их на разных машинах? Вот так же беру, и запускаю.

А, ну тогда проблема решена. Осталось весь софт правильно переписать и дело в шляпе

Кривого софта не так много, но это как минимум PHP и Python. Тут больше нечего сказать.

Наличие спецификации против её отсутсвия, выбор очевиден

У баша нет спецификации, что ли?

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

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

Это как? Докер позволяет делать снапшот оперативной памяти для передачи по сети, что ли?

Глобальная проблема – это деплой приложений. То, что могут быть пересечения зависимостей, это лишь одна из частей этой проблемы. Есть ещё масштабирование и прочий геморрой. Docker и инструменты вокруг него, например K8s, решают их. Nix их не решает.

https://github.com/svanderburg/disnix
https://github.com/NixOS/hydra
https://github.com/NixOS/nixops

Не?

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

Тестирование настраивается единственный раз, как и пишется. Что не так?

даже не говоря о том, что docker save позволяет передать на порядок больше информации, чем «я что-то нажал» – тебе вообще нет необходимости что-то передавать по сети: оставляешь контейнер работать, даёшь его координаты разработчику чтобы он там делал exec иди шо там разработчики с ними делают, а сам запускаешь вместо него другой или вообще всю систему целиком.

и ты бы знал это, если бы имел хоть какое-то представление о докере.

К сожалению, в эту итерацию я уже занят

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

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

Как я смог сразу узнать, что ты гуманитарий?

А ты не угадал.

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