Какой смысл «выбирать между линуксами»?

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

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

Если нет особых требований, то «обычный helm chart» без проблем заведётся на «обычном кубернетесе». Вот, для контраста, помню работал я в одном стартапе. И там был проект с министерством обороны одной страны настолько секретный, что нагрузка запускалась в ЦОДе без доступа к интернетам. Поэтому, чтобы чего-то сделать, нужно было отправить туда местного инженера, созвониться, списаться с ним в Вацапе и говорить ему какие команды вбивать, слушать, что получилось и т.п. Я в тех.поддержке до того ни разу не работал и очень рад этому. Было бы славно, заменить всю эту … на 1) проверить на нашем k8s; 2) запустить на ихнем k8s; 3) пойти обмывать удачное развёртывание.

Кстати да, связка nomad + consul прямо очень хороша, но к сожалению все знают и используют исключительно к8s, потому что google по факту был первым и имеют куда лучшие возможности для популяризации своих решений.

Дальше, чтобы превратить этот аргумент во что-то стоящее, нужно выяснить как они это используют. Может они там immutable infrastructure делают вот таким странным образом и от дебиана одно название осталось?

У них есть специальные дистры для запуска всякой хрени с Google Cloud, то есть потенциально опасных приложений — там всё порезано и ограничено наглухо. Но собственные сервера и машины разработчиков они держат на gLinux Rodete, который в свою очередь сделан на базе ветки Debian testing, из которой постепенно выпускают стабильные пакеты (а не разом резко делается один большой дебиановский апгрейд). Смысл в том, что свои сервера у них всегда на свежих стабильных пакетах.

При этом макросервисы, из которых весь гугл слеплен, релизятся как самодостаточные приложения, которым даже libc не нужен. Правда, этот самый libc в макросервисах оказывается из того же самого Rodete — то есть, они делают копирование библиотек. В каком-то смысле это похоже на NixOS, который параллельно деплоит зависимости разных версий на одной машине.

Если вам дорога ваша жизнь и здоровье, в промышленном окружении не должно быть непротестированных изменений. Причём проверка должна проходить на окружениях максимально близких к боевым....
Да. А ещё QA, security и compliance officer. У нас тут энетрпрайз или где?

Ох как я не привык к этим вашем бэкендам. У меня большая часть карьеры прошла на поддержке софта, который релизился в совершенно неконтролируемое окружение. Ну то есть свои зависимости он таскал с собой, но системные либы, ядро — это всё неконтролируемо.

Да чо там — на последней работе мы на несколько ОС и платформ релизились. Одновременно, не по очереди.

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

по крайней мере исключаем приколы «у разработчика всё работает, на qa-окружении тоже норм, а в prod’е падает, потому что там одна библиотека»

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

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

Если руками делать, то нету. Но именно потму CI/CD и придуман.

У разрабов дистра есть люди, которые занимаются патчами ядра, которые разбираются во внутреннем устройстве systemd, в libc и libstdc++. У вас с вероятностью 95% таких людей нету, да и огромной базы для тестирования нет, потому вы в принципе их не можете досконально проверить — вы можете лишь понадеяться, что мейнтейнеры всё правильно сделали или что проблема с libc вылезет в каком-то прикладном тесте.

Есть старая истина: падающие тест показывает, что в вашем софте есть баг, успешно прошедший тест не показывает ничего. Именно потому я приводил пример челов, у которых CI/CD прошел, но по итогу ничего не работает.

Вся соль в том, что вообще пофиг как образ был создан, главное, что он: а) не меняется, т.е. можно один раз проверить, поставить галочку и больше не возвращаться к этому вопросу

LOL — а это ничо, что ты сам мне выше написал, что обновление ядра значит перетестирование всего софта? Насколько я помню, ядро ОС в докерах не деплоится. Но я ж не знаю, может вы там у себя через firecracker мини-ОС деплоите.

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

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

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

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

Вы утвреждаете, что в GKE под капотом Nomad, который только притворяется кубернетесом?

Нет, я такого не утверждал. У GKE собственная реализация kubernetes API, наглухо проприетарная, построенная на других их внутренних сервисах и приколоченная к их инфре.

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

Для того, чтобы достичь масштаба 10000+ узлов Ant Group понадобилось:
1. Переработать модуль хранилища в etcd (boltdb);
2. Реализовать Lease API;
3. Разработать собственный планировщик Sigma;
4. Разработать механизм P2P загрузки образов;
5. И ещё херову тучу мелких оптимизаций.

Это было мягко говоря не «из коробки». По трудоёмкости это было сравнимо с написанием оркестратора с нуля — они изменили почти все части кубернетеса.

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

так запускай ее сайдкаром в другом контейнере и тестируй

Я не просто так этот аргумент упоминал рядом с описанием проблемы итерирования. По факту это превращалось в здоровенный образ со всякими там GDB и Perf, а каталог проекта монтировался прямо в контейнер для инкрементальной сборки.

Теперь внимание вопрос: а зачем тут вообще контейнер тогда? (в моём случае ответ — потому что базовую систему собирал не я)

если у тебя есть Dockerfile лежащий прямо в твоем репозитории? Правь и gitlab runner (jenkins, github actions, drone или какой-то другой черт лысый) тебе его пересоберет, повесит тэг с версией и скопирует в registry. Сейчас прямо стандартно такой пайплайн.

Это займёт больше 30 секунд? Если да, то оно не нужно. зачем что-то там пересобирать, если можно вообще ничего не пересобирать? А CI? Ну да, пусть 30 минут гоняет тесты, я потом посмотрю на результат, но здесь и сейчас для целей разработки мне эта радость даром не нужна.

Если да, то оно не нужно. зачем что-то там пересобирать, если можно вообще ничего не пересобирать? А CI? Ну да, пусть 30 минут гоняет тесты, я потом посмотрю на результат

Так образы обычно кэшируются. разница будет всего в одном лейере с предыдущей сборкой.

но здесь и сейчас для целей разработки мне эта радость даром не нужна.

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

платформа универсальная, позволяющая более-менее абстрагироваться от железа с одной стороны, и разговаривать всем на одном языке с другой...
Было бы славно, заменить всю эту … на 1) проверить на нашем k8s; 2) запустить на ихнем k8s; 3) пойти обмывать удачное развёртывание.

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

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

Кстати да, связка nomad + consul прямо очень хороша, но к сожалению все знают и используют исключительно к8s, потому что google по факту был первым и имеют куда лучшие возможности для популяризации своих решений.

Так кубернетес не гугла софтина. Он просто слегка её поддерживает.

Так образы обычно кэшируются. разница будет всего в одном лейере с предыдущей сборкой.

В инкрементальную сборку (C, C++, Rust) докер сам по себе не умеет. Даже для того, чтобы сделать кэш пакетов для всяких там NPM и PIP, нужно доп приседания делать.

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

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

Ох как я не привык к этим вашем бэкендам.

Здрасьте. Тут у нас своя атмосфера. Если ваша упавшаая десктопная программа может расстроить одну секретаршу. То упавший pipeline CDN может расстроить половину интернета. Это в принципе иной уровень ответственности.

о печальном состоянии системы, чем про превосходные практики деплоя.

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

Оно скорее всего падало у кого-то, в каких-то окружениях, но на эту проблему забили, её не решили, вместо этого «зафиксируем версию окружения»

Идите к product owner’у. Расскажите, что выпуск откладывается, по ка вы не проверите/исправите все используемые библиотеки (и вообще линукс).

У вас с вероятностью 95% таких людей нету,

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

LOL — а это ничо, что ты сам мне выше написал, что обновление ядра

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

Либа на хосте есть нужной версии (на каждой машине своей), устройства тоже есть.

Ветром надуло или человек какие-то действия для этого предпринял?

Уже на тысяче будут проблемы, если специально не адаптировать систему.

Это было мягко говоря не «из коробки».

ВНЕЗАПНО! Масштабирование на десятки тысяч узлов требует каких-то усилий! Вот, никогда такого не было. Везде, что кластер на три узла в виртуалбоксе, что на тридцать тысяч серверов железных, всё ставится и работает одинаково, а тут надо какие-то действия предпринимать. Беда-печаль.

По трудоёмкости это было сравнимо с написанием оркестратора с нуля

Любая работа кажется простой и лёгкой, если её должен делать кто-то другой.

Я ещё раз напоминаю мой аргумент про «такое ощущение, будто не бывает функций, кроме перекладывания жсонов из сокета в сокет».

Но ведь это и свидетельствует о зрелости индустрии. Большинство работ довольно стандартные, делаются стандартными инструментами по стандартным образцам. Вас же не смущает, что большинство велосипедов похожи друг на друга? Два колеса, руль, педали, тормоз. Сел — поехал.

Вот у меня на последней работе было кастомное железо

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

почему-то на нём разговаривают очень странные люди,

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

Один фиг все будет в докере/кубере

если руководство компании хочет контейнер ради контейнера тогда да, один фиг. иначе не один.

даже сейчас в энтерпрайзе огромное количество неконтейнеризированных приложений.

ред хат кстати стал богатым и знаменитым (а уже тем более начинался) задолго до докера/кубера

RedHat это часть IBM теперь. А IBM поставляла немцам табуляторы для Освенцима. Так что у этой конторы есть богатый опыт с контейнерами и изоляцией.

ред хат кстати стал богатым и знаменитым (а уже тем более начинался) задолго до докера/кубера

Есть вероятность, что если бы был «докер», то он бы не стал богатым и знаменитым :)

Редхат, собственно, и продавал «контейнер» – стабильное окружение – во времена, когда контейнеров не было.

Если ваша упавшаая десктопная программа может расстроить одну секретаршу. То упавший pipeline CDN может расстроить половину интернета.

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

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

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

Идите к product owner’у. Расскажите, что выпуск откладывается, по ка вы не проверите/исправите все используемые библиотеки (и вообще линукс).

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

Ветром надуло или человек какие-то действия для этого предпринял?

Клиентская либа CUDA ставится пакетным манагером вместе с драйвером.

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

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

Но ведь это и свидетельствует о зрелости индустрии. Большинство работ довольно стандартные, делаются стандартными инструментами по стандартным образцам. Вас же не смущает, что большинство велосипедов похожи друг на друга? Два колеса, руль, педали, тормоз. Сел — поехал.

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

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

Спорный вопрос, отстал я или опередил. Точно не иду в ногу, это бесспорно.

Есть вероятность, что если бы был «докер», то он бы не стал богатым и знаменитым :)
Редхат, собственно, и продавал «контейнер» – стабильное окружение – во времена, когда контейнеров не было.

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

То есть, вместо укрепления каркаса ставят сейсмические стабилизаторы

Тоесть вместо нытья «а чего это земля трясётся» в сейсмоопасной зоне используют соответствующие архитектурные решения. Потому что людям нужен результат.

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

Первая же установленная библиотека из maven/pypi/npm/github и ваш «проверенный линукс» превращается в тыкву.

тавится пакетным манагером вместе с драйвером.

Т.е. поставить либу с драйвером в систему это не считается за работу, а закинуть её в контейнер — считается работой? Нормально.

кубернетес сам по себе вашу систему не замасштабирует.

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

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

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

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

накладные расходы на сеть и прочую инфру

Просчитаны и найдены приемлимыми. Я тут сижу в недрах кровавого энтерпрайза и переупаковка данных в json’ах это настолько ничтожная проблема, что … Но рассказать не могу. NDA, все дела.

Тоесть вместо нытья «а чего это земля трясётся» в сейсмоопасной зоне используют соответствующие архитектурные решения. Потому что людям нужен результат.

Ты знаешь, я сам пару раз наблюдал, как люди годами чёрт знает чем занимались, а потом им резко «нужен результат». Как бы да, но как бы «есть ньюанс». Я никогда не спорил, что эти ваши микросервисы — это способ скрыть/переложить ответственность и притвориться, что проблем нет.

Первая же установленная библиотека из maven/pypi/npm/github и ваш «проверенный линукс» превращается в тыкву.

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

А я давно писал, что cargo — это причина, почему в ближайшие годы никаких крупных проектов на Rust мы не увидим. «Накачать по три версии мусора с гитхаба» — это не способ организации проекта.

Т.е. поставить либу с драйвером в систему это не считается за работу, а закинуть её в контейнер — считается работой? Нормально.

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

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

Это не совсем тебе был ответ — тут выше оратор утверждал, что «кубернетес несложно масштабирует имеющуюся систему».

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

Ну слава богу, хоть признал.

Просчитаны и найдены приемлимыми. Я тут сижу в недрах кровавого энтерпрайза и переупаковка данных в json’ах это настолько ничтожная проблема, что … Но рассказать не могу. NDA, все дела.

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

Я никогда не спорил, что эти ваши микросервисы — это способ скрыть/переложить ответственность и притвориться, что проблем нет.

И чё делать? Тоесть какое конкретно ваше предложение? Других программистов у меня для вас нет.

«Накачать по три версии мусора с гитхаба» — это не способ организации проекта.

Альтернативы?

И чё делать? Тоесть какое конкретно ваше предложение? Других программистов у меня для вас нет.

Ну зато европка. Стабильность, job safety, и всё такое.

«Накачать по три версии мусора с гитхаба» — это не способ организации проекта.

Альтернативы?

Сообщество не способно производить хороший софт. Весь годный опенсорс — это мелкие группы фанатиков или крупные корпорации, делающие опенсорс для себя. NPM, Cargo, PIP — это игрушки для школьников. Серьёзные компании форкают код и поддерживают его ­­— это придётся делать так и так, но в форке хотя бы меньше шанс выхватить очередной left-pad или sha-hulud. Две зависимости требуют разных версий библиотеки? Сводишь их к зависимости от одной версии библиотеки.

Cargo ещё не скатился, но уже уверенно идёт по курсу NPM.

Ну зато европка.

Не жалуюсь, да. Однако, в остальном мире условия проживания хуже, а программисты такие же (или хуже). Так что всё равно как-то выживать надо.

Серьёзные компании форкают код и поддерживают его

Ну, я, значит, работаю в несерьёзной.

Две зависимости требуют разных версий библиотеки? Сводишь их к зависимости от одной версии библиотеки.

Стабильность, job safety, и всё такое. Главное, чтобы контора не разорилась, пока ты фигнёй страдаешь. Но это вообще от разных причин зависит.