Плюсы докера

собирать на разных версиях тулчейна

Зачем, если в проде конкретная версия всего? Или вы не про веб разработку?

а не обучать каждого джуна

Согласен, докер для джунов (насыпал прикормки).

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

А если надо программный продукт перенести на новую версию библиотек? Или одновременная поддержка нескольких версий с разным набором зависимостей?

Ну вот представь у тебя есть сервис. У него есть какие-то зависимости. И чтобы его запустить тебе надо поставить эти самые зависимости

apt install nginx разве не устанавливает сам зависимрсти?

Или npm install, pip, что там еще

Мне вот такое окончание нравиться:
- А видите там узкая полоска не прокрашена?
- Ну и что? Не видно же.
- А вы на шкаф залейте.
Залезли.
- Ну все равно не видно.
- А вы правее сдвиньтесь.
- Невидно.
- Ещё правее.
Проверяющий падает со шкафа.
Мужик:
- И вот такая фигня каждый день.

результат хрупкого баланса конкретных версий библиотек

Буквально, стандартный взгляд фронтендщика на бекенд.

Насколько я уверен

Ну, если не понимать что настраиваешь, то действительно, откуда взяться уверенности.

Вообще, хвалить докер сидя на форуме посвященному Linux это иметь лишнюю хромосому. Почему - попробуйте понять сами.

2k == 20

Нет. k - кило.

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

Берём стабильный дистрибутив. Ставим там стабильную версию Python. Затем развёртываем на этом сервере пару сервисов разработанными разными командами из нашей организации и имеющими разный релизный цикл, разные зависимости и т. д.

Обнаруживаем, что команда сервиса A использует библиотеку работающую только с Python < 3.11, а команда сервиса B использует другую библиотеку работающую только с Python > 3.11. А наш стабильный дистрибутив не даёт поставить две версии третьего питона одновременно.

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

С Docker просто у двух образов сервисов будут разные базовые образы с разными версиями Python, а админу сервера даже не обязательно знать на каком языке написаны сервисы. Ему нужно только знать какие порты они слушают, к каким другим сервисам обращаются (например, к СУБД) и, иногда, какие volume у них нужно сделать persistent.

Это у вас продакшен такой? Где на одном сервере несколько рукожопых поделок?

Вывод: докер чтобы скрыть рукожопость дерьмоподелок.

Аргумент как-то не слишком положительный для докера

Нет, про разработку/сборку софта. С вебом я слабо дружу.

Допустим мне нужно, собирать софт (и пакеты, соответственно) так чтобы поддерживало, допустим ubuntu 20+/debian, RH 8+ и т.д. Работаю я вообще на Альте.

Раньше надо долго и извращённо настраивать на каждом конкретном хосте. С контейнерами: описал окружения, настроил процесс сборки, который триггерится хоть руками хоть git-ом. Один раз настроил - везде работает. Красота, же.

Где ты такие дикие сервисы берешь, самодельные что ли? На чем написаны? Почему зависимости не лежат с ими же в папочках аккуратно?

А если надо программный продукт перенести на новую версию библиотек?

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

Мы же не сторонники заметать косяки по ковер новых абстракций, правда же?

Или одновременная поддержка нескольких версий с разным набором зависимостей?

Разные тестовые сервера (хоть в железе хоть виртуальные) с разным набором зависимостей. Им не нужно быть такими же мощными как продакшн сервера что может себе позволить любая контора средней руки. На компах разработчиков - любые системы изоляции окружения сред разработки, от Anaconda до Vagrant.

На винде докер тормозит, к сожалению.

До сих пор? Не знал, думал уже давно пофиксили.

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

Однажды у одной из либ из зависимостей случается ломающее обновление или её разработчика сбивает автобус (да, при выборе стараются выбирать такие, у которых стабильное API и широкое community разработки, но никто не даст 100% гарантий и чем больше либ в проекте и чем дольше идёт проект, тем выше шанс, что хоть одна либа да выстрелит).

И появляется таска «обновить/заменить либу». Только на момент появления этой таски у команды в беклоге ещё сотня других задач, которые тоже нужные и важные (более того, с точки зрения бизнеса они даже более важные, ибо старая версия либы обычно продолжает работать). И между появлением проблемы и обновлением либы может пройти и несколько месяцев и даже несколько лет.

А сервис нужно как-то поддерживать в работе. С Docker просто заморозится версия базового образа, пока команда сервиса работает над решением проблемы, а сисадмин у которого на сервере 10 таких сервисов (и команды некоторых сервисов оказались расторопнее и успели либу обновить или вообще её не использовали) не будет жонглировать их зависимостями.

Вот бы щас в «2ˣ10³ + 25» шеймить кого-то за то, что он не знает чего-то, что знаешь ты, и исккене без лишних кривляний интересуется.

Фу таким быть.

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

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

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

Буквально, можно в одной консоли conda activate my_project_python3.8 а в другой conda activate my_another_project_python3.11 и спокойно работать.

В чем плюсы докера?

За хардкоженный порт ноды к тебе не прибегают ругаться админы.

Тогда там не конкатенация, а сложение.

кто как применяет и для его в реале.

Ну орды «новодельных» k8s-only девопсов ринувшихся в профессию
Профит жеж

Нет, про разработку/сборку софта. С вебом я слабо дружу.

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

Допустим мне нужно, собирать софт (и пакеты, соответственно) так чтобы поддерживало, допустим ubuntu 20+/debian, RH 8+ и т.д.

А как вам докер поможет подогнать софт под разные разные библиотеки которые опакетили разные мейнтейнеры в разных дистрах?

Однажды у одной из либ из зависимостей случается ломающее обновление

Интересно почему у тебя админы ХОСТА обязательно криворукие накатывальшики обновлений не глядя, а сборщики докер-контейнера умнички, фиксирующие библиотеки.

Сейчас в ходу микросервисная архитектура. Если раньше для типового приклада было достаточно 3 серверов (app, web, db), то теперь разрабы плодят кучу микросервисов.

Отсюда и пошли контейнеры и куберы.

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

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

Сишка. Потихоньку въезжаю в Rust, но то такое.

А как вам докер поможет подогнать софт

В контейнере (не обязательно Docker, но он самый популярный) можно собрать весь тулчейн с зависимостями.

Писал-же выше, что, для примера, почти все публичные CI/CD, которые мне известны, построены так.

Нет, всё они прекрасно знают, но не могут удержаться и идут в атаку.

Сишка. Потихоньку въезжаю в Rust, но то такое.

Под Си из инструментов создания изолированного виртуального окружения для разработки помню только Conan и Bazel. С Conan работал еще лет 10 назад, про Bazel только слышал.

Изолированные и цельные окружения. Либо можно всё установить на одну систему и потенциально получить конфликты разных и несовместимых версий ПО, влияние всего и вся друг на друга и пр., нереальность развёртывания ПО и пакетов для разных систем и пр. Плюс докер это часто про воспроизводимость результата и например если какой-то разработчик разрабатывает ПО под какой-то системой с кастомными настройками, ПО, пакетами и пр., то даже в относительно простых случаях есть риск того, что даже сборка C++ проекта(напр. игрового движка) с помощью cmake у вас не сработает и потребует возьни к устранению, а создание воспроизводимого окружения, потребует минимума усилий к воспроизведению результатов.

Conda это самый неправильный инструмент. По умолчанию предоставляет свои, устаревшие, часто небезопасные версии либ (что полностью ломает нормальный подход к разработке), а anaconda (которая еще и с EULA) - системных зависимостей. Оно медленное, оно не поддерживает PEP 631, огромный, нет, даже колоссальный вес среды. Этакая песочница для начинающих дата сайенсов, которые не могут в кастомный Docker образ на distroless Debian + uv.

По умолчанию предоставляет свои, устаревшие, часто небезопасные версии либ

А зачем вы ставите через conda пакеты если есть pip? Я говорю о Conda как о механизме изоляции среды разработки, а не о пакетном менеджере.

conda activate blablabla
pip install whatever==1.2.3

В этом случае pip поставит пакет нужной версии со всеми зависимостями в conda окружение (/opt/anaconda3/blablabla).

Для простой изоляции есть встроенный venv. Для простой установки Python - pyenv. Зачем какие-то костыли с conda (у которой также остальные минусы) - непонятно. Портабельный и удобный способ всего и вместе через Docker я уже описал.

В чем плюсы докера? … Как и для чего вы его используете?

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

В чем плюсы докера?

а живёте Вы где? В …
сейчас бы бросить всё и уехать в …

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

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

С точки зрения админа локалхоста - так вообще имба. Вот стоит у меня коробочка, на ней три десятка контейнеров бегает (будет больше). Большинство контейнеров подняты из образов, созданных разработчиками сервисов (postgresql, redis, nginx, nextcloud, whatever) - мне не нужно менеджить все эти среды в вмках, например (конечно, и это описывается в виде IaC, но трудозатраты неадекватны относительно подкроватного сервера). Я могу только подцепить волюмы и написать конфиги, которые могут хоть в гите жить. И вместо того, чтобы пердолиться с подгонкой окружения под каждый сервис, я просто пишу композы и Portainer мне это всё поднимает в том виде, в котором сами разработчики продуктов задумали.

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

Докер - это неизбежное зло, вызванное практикуемой моделью разработки «хк хк и в продакшен».

Почему ты так решил? Хокей хокей и в продакшен зависит вовсе не от докера.

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

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

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

Мы живём в эпоху облаков и железные коробочки мало кому нужны. Сейчас наиболее распространённый вариант развёртывания - это AWS EKS вмести с прочими сервисами от Amazon.

Мы живём в эпоху облаков и железные коробочки мало кому нужны. Сейчас наиболее распространённый вариант развёртывания - это AWS EKS вмести с прочими сервисами от Amazon.

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

Поэтому берут железо и на нем уже разворачивают нужную инфру сами.

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

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

И я таки видел далеко не только небольшие стартапы, но и компании побольше, вплоть до корпораций. Он-према становится всё меньше и меньше практически везде.

Сейчас наиболее распространённый вариант развёртывания - это AWS EKS вмести с прочими сервисами от Amazon.

А потом приходит очередной-пакет-санкций/пожар/etc и ваша «радость» превращается в тыкву.

Тут это неактуально, а у вас наверняка есть аналоги AWS. Или нет?

Аналоги AWS не спасут от пожаров и других etc.

От каких пожаров? У AWS всё продублировано.

У AWS всё продублировано.

Ну вы тоже говорите. (с) анекдот.

Когда там был последний пожар?

Зато помню как был пожар в дата центра где хостился ЛОР.

Когда там был последний пожар?

Проблема не в том когда там был последний пожар, а в том когда будет следующий.

А когда будет следующий пожар\рейд в онпрем?

Потомки Ванги пока в отпуске.

А сам выше?

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

Мой текущий проект в конце прошлого года имел 8-10 миллионов запросов в день (10 на black friday). Живет на AWS уже 7 лет, проблем нет, в том числе со средствами на оплату. Давайте, расскажите обезъяну как космические корабли бороздят просторы колокейшна.