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

ты тогда мой аргумент про унификацию проигнорировал

Потому что я с ним согласен.

А крупная компания даёт гарантии?

INFINITI

3 года или 100 000 км пробега, в зависимости от того, что наступит раньше.

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

Когда так устроена работа, надо нафиг разгонять всю контору, от программиста, до генерального директора.

Ты пробовал(а) в РФ хоть от кого-то получить что-то? По гарантии, закону или ещё как-то? Если нет, то не пиши больше.

Монитор заменили на новый по гарантии.

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

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

Видимо маркетологи посчитали, что это выгодно.

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

Никак. Потому что при облегчении одних проблем говнокод переходит на новый уровень и появляются другие проблемы. Не веришь, попробуй http://deeppavlov.ai/ там как раз смузихлёбы всё через докер сделали. Столько багов я очень давно не видел...

А В? С каких пор горизонталтная масштабируемость — это плохо?

Это просто закон РФ о правах потребителей.

С таких, что это не горизонтальная масштабируемость. Горизонтальная масштабируемость это кластеры.

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

Рано или поздно понимание возникает.

попробуй http://deeppavlov.ai/ там как раз смузихлёбы всё через докер сделали.

Есть какие-то гарантии, что без докера оно бы лучше работало?

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

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

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

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

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

Это действительно полезная инфа.

Извините, за банальность, но https://docs.docker.com.

И шо там таки хорошая документация?

В части расковырять чужой контейнер.

Да, там хорошая документация.

Докер вообще ортогонален сборке под другую архитектуру. Он никак не помогает и никак не мешает

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

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

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

почитай уже что такое docker volume, чудище позорное

С «docker run -v» ни разу не гладко, volume предпочтительнее, а там уже внезапно выясняется, что почему-то не особо проще стало работать с софтиной.

Звучит бредово. С этого места поподробнее

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

И снова ты проповедуешь ручной велосипединг против софта, который делает ровно то же самое, но унифицированно и автоматически

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

почитай уже что такое docker volume, чудище позорное

Что не так?

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

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

На оффтопе простыми скриптами? В чем? В баше? PowerShell? На WSL, например, есть веселые проблемы с регистрозависимостью.

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

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

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

А, я понял, что ты не понял. Даю пример: у тебя есть база постгреса и постгрес 9.4. Ты, конечно же, используешь божественный докер для облегчения задачи обновления, разворачиваешь контейнер с 9.5 с запуском pg_upgrade, и загладываешь большой и толстый елдак, после чего удаляешь получившуюся испорченную базу, откатываешься на бэкап старой базы, и пытаешься делать миграцию через backup-restore.

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

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

Можешь показать лошкам, как надо, своим примером корпоративного строительства.

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

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

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

Механизмы, на которых работает докер, универсальны для всех линуксов, и большим кол-вом готового софта используется. Мало кому нужны все те функции докера, а в простых случаях сделать скрипт для чрута не сложнее, чем настраивать контейнер докера. Я уже приводил пример PyInstaller, а для статически компилируемых софтин возможна статическая линковка, в том числе для AoT-компилируемой жавы — в итоге ты получаешь единый бинарник, который можно запускать в докере, чруте, просто в папке. В оффтопике уже давным давно подход «всё свое ношу с собой» активно применяется, но почему-то на лине люди пользоваться этим не хотят. Конечно, не в последнюю очередь потому, что у того же питона кривущая дистрибуция — но нет, мы не хотим исправить питон, мы будем писать костыли, готовые костыли, унифицированыне костыли.

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

в жопу себе такой пример засунь, поехавший.

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

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

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

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

в жопу себе такой пример засунь, поехавший

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

Форум — Development  

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

кудахтает про базу в докере

ты уже всех заебал. и ваших и наших и вообще всех и себя самого, наверное, тоже

не мешая и не помогая.

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

Да у каждого языка (почти) есть свой пакетный менеджер и какая-та вариация на тему виртуальных окружений. А если ещё добавить chroot, ip net namespaces, немножко iptables и слегка подмазать скриптами, то получится ничем не хуже, чем у докера. Но зачем?

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

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

ты уже всех заебал. и ваших и наших и вообще всех и себя самого, наверное, тоже

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

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

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

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

Иными словами, как уже упоминал @intelfx в похожем топике, Докер это способ поставки, а не метод деплоя приложения

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

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

Ты уже придумал, как будешь core dump анализировать из контейнера?

как будешь core dump анализировать из контейнера

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

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

Во, наконец кто-то сделал акцент на истинной причине. Я ее уже описывал:

postgres первые шаги (комментарий)

Никс является хорошей альтернативой там, где нужно заморачиваться с многочисленными версиями софта. Традиционная никсовая организация (FHS) в виде мусорок /etc, /bin, /lib, /include, /share устарела уже в девяностых, потому что кол-во софтин давно перевалило за два десятка.
В шинде уже в конце девяностых MS реализовало систему https://en.wikipedia.org/wiki/Side-by-side_assembly , благодаря которой родившиеся в девяностых люди так и не узнали, что такое dll-hell. Надо сказать, что я тоже не узнал о нем, но скорее потому, что первый компьютер у меня появился довольно поздно. А в мейнстримовых никсах и вовсе нет никаких способов решения проблем конфликтующего софта. Именно это создало почву для докера, который тоже не решает проблему, а лишь подпирает ее костылем, позволяя держать параллельно разные версии виртуальной системы. Почему я настаиваю именно на том, что проблема докером не решена - потому что докер обрезает функциональность софта (сеть, логи, да и в целом ФС и прочие устройства), давая в результате кастрированную систему, в которой нужно делать много дополнительных действий просто для того, чтобы сделать ее похожей на полноценную.

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

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

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

Но зачем, если с докером можно ничего не таскать? Пишешь Dockerfile, docker-compose.yml и Makefile, чтобы поюзабельней было, да сохраняешь прямо в репозитории.
Мне очень нравится иметь декларативное окружение

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

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

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