Вроде не обсуждалась данная тема. Вот регулярно во всяческих дискуссия на ods, где начинающие ds всюду где попало лепят docker. Т.е. у них на выходе
простенькая программа\сервис в кол-ве одной штуки и тут же к нему цепляется docker. А какой в этом смысл? Т.е. если нам нужна инфра-ра k8, ну ок.
Но стоит ли ради масштабирования и управления одним процессом завязываться на такие вещи?
Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?
S>Вроде не обсуждалась данная тема. Вот регулярно во всяческих дискуссия на ods, где начинающие ds всюду где попало лепят docker. Т.е. у них на выходе S>простенькая программа\сервис в кол-ве одной штуки и тут же к нему цепляется docker. А какой в этом смысл? Т.е. если нам нужна инфра-ра k8, ну ок. S>Но стоит ли ради масштабирования и управления одним процессом завязываться на такие вещи?
S>Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?
90% случаев использования докера — это проблемы окружения.
А совсем не производительность.
Здравствуйте, Sharov, Вы писали:
S> Для одного процесса зачем огород городить?
Проблема окружения или его воспроизведения. Если очень условно, то предположим у тебя есть программка собранная с библиотеками A/B/C определенных версий. Вместо того, чтобы требовать от своих потребителей воспроизведения такого же окружения ты распространяешь "эталонный" контейнер. Сделав так несколько раз, подсаживаешься на эту иглу и потом уже тяжело с нее слезть даже если программа уже не требует какого-то специфического окружения (собрана статически например).
Здравствуйте, Sharov, Вы писали:
S>Я ни слова про производительность не сказал. Для одного процесса зачем огород городить?
Например, чтобы было легче управлять зависимостями (а точнее не нужно было особо о них париться), чтобы не было проблем с repoducibility, чтобы не было конфликтов зависимостей, если вдруг появится второй сервис.
Здравствуйте, Anton Batenev, Вы писали:
AB>Проблема окружения или его воспроизведения. Если очень условно, то предположим у тебя есть программка собранная с библиотеками A/B/C определенных версий. Вместо того, чтобы требовать от своих потребителей воспроизведения такого же окружения ты распространяешь "эталонный" контейнер. Сделав так несколько раз, подсаживаешься на эту иглу и потом уже тяжело с нее слезть даже если программа уже не требует какого-то специфического окружения (собрана статически например).
А разве нет проблемы с поддержкой этих библиотек? Ты не должен следить за уязвимостями в них и своевременно обновлять распространяемый контейнер? А когда ты отдаешь софт просто так, это забота пользователя и маинтайнеров его дистрибутива.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops> А разве нет проблемы с поддержкой этих библиотек? Ты не должен следить за уязвимостями в них и своевременно обновлять распространяемый контейнер?
Теоретически — да, такая проблема есть. На практике же речь обычно идет о самых новых версиях библиотек (которые отсутствуют в дистрибутивах) и о том, что твое приложение достаточно интенсивно развивается из за чего часто происходит пересборка контейнера и относительно своевременное обновление этих самых библиотек. Ну или наоборот, твое приложение должно работать в столь древнем окружении для которого security-fixes уже не имеют принципиального значения (т.е. поддержка работоспособности приложения важнее чем сопутствующие проблемы).
Хорошие идеи часто используются не по назначению к сожалению и докер здесь вполне яркий пример.
Здравствуйте, Sharov, Вы писали:
S>Здравтсвуйте.
S>Вроде не обсуждалась данная тема. Вот регулярно во всяческих дискуссия на ods, где начинающие ds всюду где попало лепят docker. Т.е. у них на выходе S>простенькая программа\сервис в кол-ве одной штуки и тут же к нему цепляется docker. А какой в этом смысл? Т.е. если нам нужна инфра-ра k8, ну ок. S>Но стоит ли ради масштабирования и управления одним процессом завязываться на такие вещи?
Стоит ради упрощение развертывания и поддержки (обновления контейнера). Даже в простом DS-проекте куча зависимостей, в том числе к библиотекам на C.
С докером этими зависимостями занимается разработчик контейнера, а не конечный пользователь.
Плюс другие фишки докера — логи, управление версиями, настройки приложения. Плюс возможность использовать этот контейнер в связке с другими контейнерами (сервисами).
S>Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?
Отдельный контейнер для одного процесса/сервиса — это норма, скорее даже правило.
Здравствуйте, Sharov, Вы писали:
S>Здравтсвуйте.
S>Вроде не обсуждалась данная тема. Вот регулярно во всяческих дискуссия на ods, где начинающие ds всюду где попало лепят docker. Т.е. у них на выходе S>простенькая программа\сервис в кол-ве одной штуки и тут же к нему цепляется docker. А какой в этом смысл? Т.е. если нам нужна инфра-ра k8, ну ок. S>Но стоит ли ради масштабирования и управления одним процессом завязываться на такие вещи?
S>Нужно ли для одного процесса\сервиса использовать докер, или он нужен для изоляции >=2 сервисов в одном докере?
Один процесс — один контейнер.
Инфрастуктура рестартовать умеет контейнер в случае краша по любой причине только если у тебя один процесс на контейнер
Логи обрабатывать/доставлять по назначению тоже инфрвстуткура умеет тоже только если у тебя один процесс на контейнер
Что касается нужности то и без kubernetes docker очень любят сис-админы для так называемого single host deployment.
Берут файловую систему с поддержкой snapshot-ов для БД и за пару минут разворачивают сложные системы с бэкапом БД.
А программисты любят docker потому что Test & Staging окружения никакой тестровщик без их ведома не испортит.
Плюс есть помимо kebernetes очень известаная PaaS которая под капотом работает поверх docker — это flexing environment в Google Cloud Platform. Навреняка их много других.
Здравствуйте, Anton Batenev, Вы писали:
S>> Для одного процесса зачем огород городить?
AB>Проблема окружения или его воспроизведения. Если очень условно, то предположим у тебя есть программка собранная с библиотеками A/B/C определенных версий. Вместо того, чтобы требовать от своих потребителей воспроизведения такого же окружения ты распространяешь "эталонный" контейнер. Сделав так несколько раз, подсаживаешься на эту иглу и потом уже тяжело с нее слезть даже если программа уже не требует какого-то специфического окружения (собрана статически например).
Вот не понимаю, почему просто не собирать статически программы, если так уж хочется. Отличий 0. При этом пользоваться куда проще. Ещё больше не понимаю, зачем, например, Java-программы суют в докер, если с ними такой проблемы нет по определению.
Б>Стоит ради упрощение развертывания и поддержки (обновления контейнера). Даже в простом DS-проекте куча зависимостей, в том числе к библиотекам на C. Б>С докером этими зависимостями занимается разработчик контейнера, а не конечный пользователь.
Если ds это data science, то я как раз писал под впечатлением от дискуссий в ods. Вы все что написали выше вполне решается venv или conda. Зачем тут докер? Разве что для дистрибуции...
Здравствуйте, Sharov, Вы писали:
S>Если ds это data science, то я как раз писал под впечатлением от дискуссий в ods. Вы все что написали выше вполне решается venv или conda. Зачем тут докер? Разве что для дистрибуции...
Для дистрибуции. И деплоя.
venv и conda решает проблему зависимостей частично. Например для работы могут требоваться дополнительные артефакты, которые должны лежать в определенном месте, например, сохраненная обученная модель.
Здравствуйте, vsb, Вы писали:
vsb> Вот не понимаю, почему просто не собирать статически программы, если так уж хочется. Отличий 0. При этом пользоваться куда проще.
Не все программы можно собрать в единый бинарь. Например, тот же python — технически-то конечно можно, но получается франкинштейн. Или из за разницы лицензий.
vsb> Ещё больше не понимаю, зачем, например, Java-программы суют в докер, если с ними такой проблемы нет по определению.
Здравствуйте, vsb, Вы писали:
vsb>Вот не понимаю, почему просто не собирать статически программы, если так уж хочется. Отличий 0.
Еще можно нужные библиотеки просто класть в папку рядом с программой, и грузить именно их, а не общие, без всякого контейнера. Но это по-моему религиозное табу у линуксоидов.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Anton Batenev, Вы писали:
vsb>> Ещё больше не понимаю, зачем, например, Java-программы суют в докер, если с ними такой проблемы нет по определению.
AB>java runtime же.
Здравствуйте, Ops, Вы писали:
vsb>>Вот не понимаю, почему просто не собирать статически программы, если так уж хочется. Отличий 0.
Ops>Еще можно нужные библиотеки просто класть в папку рядом с программой, и грузить именно их, а не общие, без всякого контейнера. Но это по-моему религиозное табу у линуксоидов.
Ну по-мне смысла нет, разве что нет объектных файлов для статической линковки. Но да, технически можно.
Причём Linux даже гарантирует стабильный ABI ядра, т.е. можно статически линковать libc. По-моему это единственная ОС, которая даёт такие гарантии. Что Windows, что macOS, что FreeBSD таких гарантий не дают (т.е. нужно динамически линковаться с их libc или аналогами).
Здравствуйте, Ops, Вы писали:
Ops>Еще можно нужные библиотеки просто класть в папку рядом с программой, и грузить именно их, а не общие, без всякого контейнера. Но это по-моему религиозное табу у линуксоидов.
Здравствуйте, 3V, Вы писали:
Ops>>Еще можно нужные библиотеки просто класть в папку рядом с программой, и грузить именно их, а не общие, без всякого контейнера. Но это по-моему религиозное табу у линуксоидов.
3V>https://en.wikipedia.org/wiki/Rpath#GNU_ld.so
Ты можешь словами пояснить? Оно не умеет искать рядом с программой? Так в чем проблема научить? А если умеет, то почему так не делать?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
vsb>>Вот не понимаю, почему просто не собирать статически программы, если так уж хочется. Отличий 0.
Ops>Еще можно нужные библиотеки просто класть в папку рядом с программой, и грузить именно их, а не общие, без всякого контейнера. Но это по-моему религиозное табу у линуксоидов.
RPATH вполне себе используется. Как и статика. Но ты, давай, предложи алгоритм, как "нужные библиотеки просто класть в папку рядом с программой". Руками их туда копировать? И как узнать, какие надо, а какие нет. И чтобы надежно, т.е. нужные библиотеки находились в этой папке и работали как надо. Внезапно обнаружишь, что сделать это надежно не так просто. Проще собрать статикой, а еще проще в docker запаковать.
P.S. Официальная позиция Debian по поводу RPATH — его можно использовать, но только в пределах одного пакета (т.е. exe'шники, которые используют библиотеки в особой папке с помощью RPATH должны быть в этом же пакете). Причина — RPATH не надежен, есть реальные сценарии, когда он не работает. Так что для своей программы можешь использовать RPATH относительно exe'шника, но тебе придется и эти библиотеки собирать и следить, чтобы они ничего, кроме libc и libstdc++ не использовали... В общем, docker проще.
