LINUX.ORG.RU

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

 ,


3

3

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

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

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

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


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

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

INFINITI

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

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

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

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

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

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

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

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

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

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

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

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

peregrine ★★★★★ ()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от peregrine
Купили как-то суровым сибирским лесорубам японскую бензопилу.
Собрались в кружок лесорубы, решили ее испытать.
Завели ее, подсунули ей деревце.
«Вжик» — сказала японская пила.
«У, бля...» — сказали лесорубы.
Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
«Ух, бля!» — сказали лесорубы.
Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
«Ух ты, бля!!» — сказали лесорубы.
Подсунули ей железный лом. «КРЯК!» — сказала пила.
«Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами…
ugoday ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Форум — Development  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

byko3y ()

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

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

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

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

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

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

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

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