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

Да хоть 33тыс, поведение ключа от добавления ещё одного не меняется.

Или меняется. Или вы ожидаете, что ключ есть, а его на самом деле нету, потому что там busybox вместо gnu core utils.

Только это же про пакеты.

Вот хотите вы скриптом пакет поставить (или проверить, что он уже установлен) и чтоб скрипт работал на разных сборках. И что делать?

Ну и где здесь переименование бинарников?

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

где-то робит процесс под названием apache, а где-то httpd это хоть какой-то, но аргумент бы был.

И это тоже.

А если резко этот скрипт нужно будет «масштабировать»? И в целом у тебя появится 100500 пользователей и нагрузка станет 10к+ RPS?

Да хоть 33тыс, поведение ключа от добавления ещё одного не меняется.

Или меняется.

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

Или вы ожидаете, что ключ есть, а его на самом деле нету, потому что там busybox вместо gnu core utils.

Это вообще другое, вопросов про подобные вариации нет.

Вот хотите вы скриптом пакет поставить (или проверить, что он уже установлен) и чтоб скрипт работал на разных сборках. И что делать?

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

Бинарник могут переименовать при сборке пакета

Могут. Но мы вроде про варианты shell говорили.

и симлинк может указывать не туда, на что подумалось.

И такое возможно. Но зачем пользовать непредсказуемое?

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

Но зачем пользовать непредсказуемое?

Именно! Зачем пользовать непредсказуемое, когда можно один раз собрать один образ и всегда гарантированно иметь нужные файлы на нужных местах и нужные пакеты нужных версий?

А так, RedHat не нужен, конечно. И Ubuntu не нужна. Нужно нечто мнималистичное (чисто контейнеры запускать), декларативное, неизменное (immutable) и, желательно, с управлением по API. Такие решения на рынке есть, но мы используем ubuntu по причинам, изложенным в первом абзаце.

Ну давай представим, что мы берём какую-нибудь NixOS и начинаем собирать весь наш софт в форме неизменяемых пакетов и деплоить по контейнерам. Внезапно в софте оказываются уязвимости или критические баги — теперь нужно пересобрать базовые либы и все их зависимости. А если есть нужен какой-то доп софт для мониторинга — его тоже нужно будет поддерживать/тестировать для всего новособираемого софта. То есть, разработчики становятся сами де-факто дистростроителями.

Дистры со сверх-long-term-support нужны для того, чтобы всё это говно можно было раз в шесть лет настроить для RHEL 7.9, и потом уже RedHat сам морочит голову с тем, как бы бэкпортировать свежие исправления для библиотек так, чтобы поддерживалась идеальная совместимость. У RHEL 7.9, на секундочку, питон 2.7 является основной версией питона. Современные школьники на гитхабе считают своим долгом хотя бы раз в полгода бампануть версии всех библиотек — как в таких условиях поддерживать работу крупных систем?

А я даже скажу как: современные девопсы выкатывают в прод софт с двумя десятками известных CVE, потому что им нахер не нужно морочиться с тем, что багфиксы появились только под 3.7, а кодомакак писал-тестил софт на питоне 3.5 и на питоне 3.7 он просто не запустится. Можешь «питон» заменить на «node.js» — суть примерно та же.

Вот Ubuntu pro (ESM) для 22.04 заканчивается в 2032 — то есть, можно один раз сделать софт и десять лет его не трогать. Вот зачем нужны RHEL, Debian, и Ubuntu LTS.

FROM scratch
COPY hello /
CMD [«/hello»]

А теперь то же самое, только для /hello, который делает вычисления на CUDA. У меня есть странное ощущение, будто современные люди считают, что приложение может только перекладывать JSON из сокета в сокет.

А в остальном один фиг будет кубер и т.п.

Нет.

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

@git_blame_ai
My Senior told me to «break & optimize» the legacy monolith.
I realized if I make it efficient, they won't need me for the 12 AM on-call incidents anymore.
I replaced the O(1) hash map lookup with a O(n^2) linear search through an unindexed SQL table, but I wrapped it in a «Highly Scalable Microservice».
Latency went up 400%, but I just got promoted for «Handling Increased System Complexity».
My replacement is going to need a therapist & a priest when I leave for Google next Year.

Внезапно в софте оказываются уязвимости или критические баги — теперь нужно пересобрать базовые либы и все их зависимости.

Да. Так и только так. И ещё перетестировать всё заново.

нужен какой-то доп софт для мониторинга

Абсолютно необходим. И не только он.

То есть, разработчики становятся сами де-факто дистростроителями.

И тут на сцену выходят DevOps’ы.

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

Это миф.

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

И тут на сцену выходят DevOps’ы.

девопсы выкатывают в прод софт с двумя десятками известных CVE, потому что им нахер не нужно морочиться с тем, что багфиксы появились только под 3.7, а кодомакак писал-тестил софт на питоне 3.5 и на питоне 3.7 он просто не запустится.

Прохладная история.

можно один раз сделать софт и десять лет его не трогать.

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

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

Просто интересно, где (и с чем) вы работаете, если 65k (google.com) узлов для вас это «слишком немасштабируем для больших» установок?

Линуксовые пакеты (как способ собрать вместе результат динамической сборки) делают установку хрупкой и в целом создают больше проблем, чем решают. Да что там, вся схема придумана для экономии жёсткого диска. Это было очень актуально 50 лет назад.

Ну так-то Fedora Silverblue самим редхатом и разрабатывается. Завязывание приложений на системный libcrypto.so, который традиционно никак не поддерживает совместимость — это полнейшее безобразие. Silverblue всё ещё имеет базовую систему — другое дело, что конечным приложениям не нужно в неё что-то устанавливать.

Просто интересно, где (и с чем) вы работаете, если 65k (google.com) узлов для вас это «слишком немасштабируем для больших» установок?

Здесь есть некоторое недопонимание. Дело в том, что с некоторых пор CNCF разрешила называться «Certified Kubernetes» всем, кто совместим с ихними API. Тем не менее, есть kubernetes, который настоящий кубернетес:
https://github.com/kubernetes/kubernetes
И вот этот последний кубернетес вообще нифига не масштабируем. А kubernetes API от гугла есть только на GKE, его больше нигде нельзя развернуть, и рамки настройке на GKE очень ограничены.

Если у вас есть собственный кубер и GKE одновременно, то управление системой становится заметно веселее, хоть для этого и есть готовые решения. В принципе, так-то можно координировать и десяток кластеров собственного кубернета — другое дело, что теряется преимущество «цельной системы».

И вот этот последний кубернетес вообще нифига не масштабируем.

Обоснуйте.

А kubernetes API от гугла есть только на GKE

Т.е. GKE это не кубернетес, там какой-то внутри другой продукт, лишь совместимый с «kubernetes, который настоящий кубернетес»?

Но зачем пользовать непредсказуемое?

Именно! Зачем пользовать непредсказуемое, когда можно один раз собрать один образ и всегда гарантированно иметь нужные файлы на нужных местах и нужные пакеты нужных версий?

Можно. Никто не запрещает. Но под фразой «Но зачем пользовать непредсказуемое?» я подразумевал приблизительно: «Не надо делать хренак, хренак и в продакшен». Жизнь течет, всё меняется... и в нашей ЫТ сфере тоже.

То есть, разработчики становятся сами де-факто дистростроителями.

И тут на сцену выходят DevOps’ы.

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

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

Это миф.

Почему миф? Это про то, что не все багфиксы портируются? По-моему очень даже не миф.

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

И тут на сцену выходят DevOps’ы.

С каких пор у нас девопс у нас патчи на libc накладывает и собирают новые сишные расширения питона на старых версиях cpython? В лучшем случае прогонит тесты, поставит свечку у иконы, выкатит в прод. Меня на последней работе залюбили выкатыватели контейнеров со словами «у нас все тесты не прошли». Да, прошли? А какого хера ничего не работает? Можешь заодно пояснить, как девопс тут разрулит ситуацию.

девопсы выкатывают в прод софт с двумя десятками известных CVE, потому что им нахер не нужно морочиться с тем, что багфиксы появились только под 3.7, а кодомакак писал-тестил софт на питоне 3.5 и на питоне 3.7 он просто не запустится.

Прохладная история.

В чём прохладная? У вас нет сервисов, про которые никто уже не помнит, кто их писал?

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

И как багфиксы вносить в такой образ? Если мы говорим про энтерпрайз (а у нас вроде про этом Red Hat Enterprise Linux), а не про школьную поделку.

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

Смысл в том, что куде нужны совместимые клиентские либы и хостовые устройства. В общем, как-то вот так оно работает:

cp "$(realpath /usr/lib/x86_64-linux-gnu/libcuda.so)" .
ln -s "$(basename $(realpath /usr/lib/x86_64-linux-gnu/libcuda.so))" libcuda.so
ln -s "$(basename $(realpath /usr/lib/x86_64-linux-gnu/libcuda.so))" libcuda.so.1
docker run --rm -v $(pwd):/app --device /dev/nvidia0:/dev/nvidia0 --device /dev/nvidiactl:/dev/nvidiactl --device /dev/nvidia-uvm:/dev/nvidia-uvm -it llama-builder /app/build/bin/llama-cli $@

Без библиотеки, собранной для этого конкретного драйвера, оно не работоспособно. При этом:

$ ldd /usr/lib/x86_64-linux-gnu/libcuda.so
	linux-vdso.so.1 (0x00007fff84fc3000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000077c9fc4bb000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000077c9fa400000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000077c9fc4b6000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000077c9fc4b1000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x000077c9fc4ac000)
	/lib64/ld-linux-x86-64.so.2 (0x000077c9fc5c5000)

То есть, на новой системе старый контейнер не взлетит (новая libcuda.so не сможешь запуститься со старым libc6) — в идеале бы нужно ещё скопировать все хостовые либы из libc6.

И вот этот последний кубернетес вообще нифига не масштабируем.

Обоснуйте.

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

Etcd как бы подразумевает ACID-подобность, последовательную согласованность операций, но по факту те же CRD в валидационные хуки могут приходить в нескольких разных схемах. А кроме CRD больше такая строгая согласованность нигде не нужна, контролеры работают максимально в режиме «eventual consistency», чтения конфигурации часто делаются без полного опроса кластера, то есть, с потенциальной возможностью прочитать старую конфигурацию после чтения новой конфигурации (non-monotonic reads).

При этом строгая согласованность в обработке данных значит строгое бутылочное горлышко, такая БД принципиально не масштабируема. Можно возразить «но вот же ж GKE использует Spanner и масштабируется!». Так вот прикол — Spanner на больших масштабах тоже не обеспечивает monotonic reads при отказах! Более того, в исключительно редких случаях он требует ручного вмешательства для исправления повреждения данных (многошардовую транзакцию не удалось успешно завершить, при этом параллельно другая транзакция изменила пересекающиеся ячейки).

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

Т.е. GKE это не кубернетес, там какой-то внутри другой продукт, лишь совместимый с «kubernetes, который настоящий кубернетес»?

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

Именно! Зачем пользовать непредсказуемое, когда можно один раз собрать один образ и всегда гарантированно иметь нужные файлы на нужных местах и нужные пакеты нужных версий?

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

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

Двухлетней давности… Да ты оптимист :-)

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

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

Какие там 2 года? НИ-КО-ГДА.

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

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

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

Да хоть 33тыс, поведение ключа от добавления ещё одного не меняется.

Неожиданный time:

$ time -v /bin/echo
-v: command not found

real	0m0,098s
user	0m0,059s
sys	0m0,024s

Это убунта.

поведение ключа! А не отсутствие ключа!

Надо стараться удерживать себя от этого.

Иначе мы возродимся как звери, или девоПСЫ.

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

«зачем чинить то, что не ломалось?».

Затем, что оно было сломано изначально. Но когда диски были маленькие и дорогие, бизнес неторопливым, а установки мелкими всё как-то худо-бедно телепало. Если вы работаете в ООО «Рога и Копыта» (есть у меня такое подозрение), то для вас и сейчас нормально будет. Как где-то в деревнях до сих пор на лошадках ездят (сам видел!).

Почему миф?

Потому что «обновление = фиксация, пересборка + перетестирование». Обновлять prod с надеждой и верою, что там точно-точно ничего не поломалось — удел очень сильных духом мужчин.

С каких пор у нас девопс у нас патчи на libc накладывает и собирают новые сишные расширения питона на старых версиях cpython?

С таких, что он настраивает CI/CD, на котором сборка этих артефактов и происходит.

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

Задача DevOps’а обратная: не пускать в prod то, что валится на тестах. Тут надо идти к product owner’у с челобитною «понизить приоритеты новым фичам, выделить ресурсы на написание тестов/нанять человеков для ручного тестирования».

В чём прохладная?

В том, что задача управления рисками и приоритетами не относится к девопсовым компетенциям. Да и полномочий у него нет объявлять приказ по компании «Мы умрём на этом холме! Останавливаем бизнес, пока в этом контейнере все CVE не поправим». Вот, что может (и должен) сделать devops, так это организовать регулярные проверки и уведомлялки с dashboard’ой сделать, чтобы было видно где, в каком контейнере/артефакте какие CVE имеются (и можно ли их поправить обновлением версии).

И как багфиксы вносить в такой образ?

Никак. Образ в принципе неизменная штука. Тем и ценен. Хотите что-то улучшить-поправить → собирайте другой образ.

для начала, попробуй купить в РФ как житель РФ подписку на красношапку или «сочувствие» (убунту). успехов!

и если тебе принципиально отсутствие выбора - добро пожаловать в мир Windows или MacOS!

а какие особые проблемы с красношапкой на обычном компе или буке?

«на свете есть многое, мой друг, что и не снилось нашим мудрецам»

Проблемы не с железом, а с ПО. Приходится обмазыватся огромным количеством сторонних репозиториев, если нужно что-то кроме firefox и libreoffice, плюс кодеки из коробки не идут: CentOS 8 на домашнем ноутбуке

они как бы смотрят и спрашивают «зачем чинить то, что не ломалось?».

золотые слова! даже песня про это есть:
«If it aint broke, Don’t fix it»

тем не менее - ты же справился!

или слишком перетрудился?

у всех дистров - свои тараканы

Ну на Debian все это бы просто через apt со стандартных репозиториев поставил бы, кроме буквально пары программ из flatpak. На Ubuntu тоже, кроме пары из snap.

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

в дороге кормить никто не обещал

в демьяне и убунте - свои заморочки

Мой скрипт на перле написанный 20 лет назад работает на любом линуксе из коробки, переносимость 100%. Он пишет и чтает файлы, ходит по сети и запускается по крону.

Да, если там стоит perl

Зачем мне в этом случае докер?

как минимум для того чтобы не оказаться в ситуации, когда не можешь запустить perl на хостовой системе

Дебажить такой скрипт теперь нормально нельзя, цикл - подредактировал, запустил, проверил осложняется тем, что теперь тебе надо запустить контейнер с башем, там внутри настроить среду, поставить какой-нибудь vim и только потом редактировать. Все это довольно неочевидные действия

это полный трындец и непонимание как вообще идет разработка в современном мире. нельзя ничего дебажить в продакшне (и исправлять с помощью vim’а). никогда.

контейнер по факту - это конечный продукт, который можно только запустить

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

не требуются

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

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

Затем, что оно было сломано изначально. Но когда диски были маленькие и дорогие, бизнес неторопливым, а установки мелкими всё как-то худо-бедно телепало. Если вы работаете в ООО «Рога и Копыта» (есть у меня такое подозрение), то для вас и сейчас нормально будет. Как где-то в деревнях до сих пор на лошадках ездят (сам видел!).

А я тоже умею апелировать к гуглу: у гугла на серверах стоит gLinux, который Debian-based. И дальше что делать будем? Про деревни басни рассказывать?

Потому что «обновление = фиксация, пересборка + перетестирование». Обновлять prod с надеждой и верою, что там точно-точно ничего не поломалось — удел очень сильных духом мужчин.

Ты вроде шаришь в этой теме, но странные вещи пишешь. Если я обновляю linux-image-5.15.0-164-generic:amd64 до linux-image-5.15.0-171-generic:amd64, то значит ли это, что мне нужно теперь перетестировать совершенно весь софт в системе? Ну то есть лично я бы не обновлял все сервера разом, предпочтя по возможности поэтапные обновления, но в целом радикального перетестирования такое «обновление» ядра не требует.

С каких пор у нас девопс у нас патчи на libc накладывает и собирают новые сишные расширения питона на старых версиях cpython?

С таких, что он настраивает CI/CD, на котором сборка этих артефактов и происходит.

Я тебе о том, что если у тебя «function undefined», то ты не пойдёшь открывать IDE и переписывать код на ходу — ты побежишь к разработчику. И получается, что для поддержки своего дистрибутива вам нужна команда девопсов+разработчиков. Ну как бы гугл может позволить себе поддерживать собственный дистр, но для 99% компаний это надубийство.

Задача DevOps’а обратная: не пускать в prod то, что валится на тестах. Тут надо идти к product owner’у с челобитною «понизить приоритеты новым фичам, выделить ресурсы на написание тестов/нанять человеков для ручного тестирования».

Во-о-от, product owner... Оказывается, что только владельцы софтин знаю, что от чего зависит, насколько стабильно, и что там тесты не покрывают. Но если вам нужно собирать свой libc, свой openssl, и ещё кучу хер знает чего, то у большинства компаний нет ресурсов для проверки и тестирования всех этих зависимостей — в итоге в проде оказывается совершенно не протестированный софт, и девопс, который постоянно бегает и «просит понизить приоритеты новым фичам и выделить ресурсы на написание тестов».

Собсна, я даже не совсем понимаю, к чему ты ведешь этот спор, если по факту контейнера собираются не с alpine-latest, а с каким-нибудь python:3.10-alpine или python:3.10-trixie, в которые софт ставится теми самыми мерзкими пакетными менеджерами и которые постоянно обновляются — и я очень сомневаюсь, что девопсы-пользователи сильно уж перетестируют этот питон при сборке с обновленными образами.

это полный трындец и непонимание как вообще идет разработка в современном мире. нельзя ничего дебажить в продакшне (и исправлять с помощью vim’а). никогда.

Я вот этого тоже не понимаю. Возможность отладки в проде — это антифича, которой те же лисперы хвалятся. Я подозреваю, что эта радость на самом деле таки изначально предназначалась не для прода, а для интерактивных расчётов, когда у тебя код в шеле молотит 2 часа какие-то расчёты, потом внезапно выдаёт ошибку, и тебе хочется отреагировать на эту ошибку, чтобы не потерять 2 часа проведённых расчётов. Но это любой интерпретатор умеет делать (даже для C++ на LLVM делали REPL), для этого не нужно доходить до лисповых крайностей.

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

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

RedHat зарабатывает на поддержке. Я выбрал Debian за предсказуемость.

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

Монтируются сорцы твоего скрипта или цельного сервиса в контейнер с софтом. Изменил свои сорцы — в контейнере они подхватились сразу же. Нужен шел? Делаешь «run --rm -it /bin/sh». Нужно что-то поменять в базовом образе? Тогда меняешь докерфайл и пересобираешь образ, но это нужно делать редко.

Зачем тут вообще может быть нужен докер? Если скрипт/сервис нетривиальный и ему нужны зависимости, то зависимостей может не оказаться на системе. Подход «всё своё ношу с собой» используют все, кто имеет опыт деплоя на разношерстные окружения — по-другому оно просто не будет работать.

И если Go, C/C++, Rust можно собрать так, что ты просто скопировал папочку или цельнолитой бинарник со всеми зависимостями внутри, то в случае Perl, PHP, Python, Ruby, Node.js авторы вообще никогда не заморачивались вопросами удобста деплоя — деплой очень хрупкий, зависит от хер пойми чего, и потому единственный способ гарантировать, что твой достаточно сложный софт всегда запустится на целевой системе — это засунуть его в контейнер. Но, ещё раз повторюсь, это касается только упомянутых ЯП с моделью «я единственный интерпретатор на всей системе, и вся система — это моя библиотека».

Сейчас некоторые могут возразить «вот же ж есть venv, полностью изолированный от хоста» — да, только кто будет этот venv инициализировать и в него ставить пакетики?

Вы, я так понимаю, искали кого-то кубер вилкой ковырять.

Это с чего ты взял?
Мы не искали, мы и есть кубер :)

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

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

Где же он тогда нужен/не нужен?

Там, где нужен, там нужен.
Где не нужен, там не нужен.

Вот тут (vkvideo.ru) очень хорошо рассказано, когда он нужен, а когда нет.

Давайте придерживаться обсуждаемого тезиса «контейнеры - они тоже не просто так. Там тоже стоит ОС, просто без ядра». В данном случае, необходимость наличия нужной версии библиотеки под нужное ядро, никак, вообще никак не подтверждает оспаривемое утверждение. Вы всё равно можете собрать статический бинарник/собрать динамический бинарник + положить нужные *.so’шки. И это гораздо меньше, нежели «ОС без ядра».

Суть в том, что модель данных и в частности их конститетнтности разработаны максимально бездарно.

С одной стороны размышлизмы ноунейма с лора, с другой — промышленные установки на десятки тысяч узлов. Даже и не знаю, что из этого важнее.

Ну типа того.

А что там вместо кубернетеса? Расскажите, вдруг мне тоже надо.

И дальше что делать будем?

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

Ты вроде шаришь в этой теме, но странные вещи пишешь.

Это потому, что я тот — кого разбудят, если что-то упадёт посреди ночи. И заставят чинить и поднимать. А я очень, очень люблю спать по ночам.

Если я обновляю … начит ли это, что мне нужно теперь перетестировать

Да. Если вам дорога ваша жизнь и здоровье, в промышленном окружении не должно быть непротестированных изменений. Причём проверка должна проходить на окружениях максимально близких к боевым. Хорошее эмпирическое правило: та же конфигурация, те же версии, но меньше данных и более дохлые машины. Соответственно у нас всё равно остаются проблемы, которые могут быть связаны с производительностью, но по крайней мере исключаем приколы «у разработчика всё работает, на qa-окружении тоже норм, а в prod’е падает, потому что там одна библиотека».

вам нужна команда девопсов+разработчиков.

Да. А ещё QA, security и compliance officer. У нас тут энетрпрайз или где?

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

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

python:3.10-alpine или python:3.10-trixie, в которые софт ставится теми самыми мерзкими пакетными менеджерами и которые постоянно обновляются

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

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

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

Кубернет прекрасно масштабирует большое число чисто stateless сервисов — с другой стороны, если у вас система остоит из кучи stateless сервисов, то возможно проблема в том, что их не должно было быть, а не в том, что кубернет решил проблему их деплоя-масштабирования. Если у людей затык в БД — как им поможет кубернет? Я как-то даже немношк неоправдано напал на сам кубернетес, но по факту это ведь одни из готовых решений для одной из задачи, да и никому не нужно оркестрировать тысячи узлов, как правильно сказано в видео...

Вот тут (vkvideo.ru) очень хорошо рассказано, когда он нужен, а когда нет.

Вот в этом моменте
https://youtu.be/CgCLPYJRxbU?t=543
Я слегка выпал в осадок — когда гигантская хренотень с БД внутри называется «микросервис». Я пытался писать статью по этому поводу, но совершенно перепутал акценты, из-за чего большая часть людей просто проигнорировала статью:
https://bykozy.me/blog/what-are-microservices-seriously/
Особенность слова «микросервис» в том, что НИКТО НЕ ЗНАЕТ ЧТО ЭТО ТАКОЕ, потому все называют микросервисом что попало — и это было организовано целенаправлено, и я нашёл людей, которые это сделали.

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

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

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

давайте придерживаться обсуждаемого тезиса «контейнеры - они тоже не просто так. Там тоже стоит ОС, просто без ядра»

Более того, я категорически не согласен с этим утверждением — никакой ОС в контейнерах нету. И это не я его писал.

Моё дополнение было про то, что контейнерам не нужно дублировать ОС, но им нужно взаимодействовать с имеющейся ОС, потому истории про «я просто запускаю один статично собранный бинарник в контейнере» очень прохладные. Как раз у статично собранного бинаря без контейнеров огромное преимущество, потому что он может просто взаимодействовать с хостовой ОС, а вот из контейнера нужно пробиваться с боем — примерно так, как я показал для куды.

С одной стороны размышлизмы ноунейма с лора, с другой — промышленные установки на десятки тысяч узлов. Даже и не знаю, что из этого важнее.

Я уже написал, что на кубернетесе нельзя сделать установки на десятки тыщ узлов — официально 5000 узлов предел, хотя проблемы начнутся намного раньше этой цифры. Это я не выдумал этот предел:
https://kubernetes.io/docs/setup/best-practices/cluster-large/

А что там вместо кубернетеса? Расскажите, вдруг мне тоже надо.

Расскажу. В видео выше упомянули Mesos. Я упоминал Nomad, у которого грамотная модель данныхи он тоже масштабируется лучше:
https://www.hashicorp.com/en/c2m
Не потому, что Номад или Mesos такие хорошие, а потому, что кубернетес так плох. Именно потому я делал акцент на модели БД кубера — она ужасна, причём, не было никакой причины делать её такой плохой. Тот факт, что тысячи компаний строят теперь на этом продукте свой бизнес, не делает реализацию кубернетеса лучше.

Что это за аргумент вообще про «промышленные установки»? Ещё бы Кобол вспомнил, призвал всех бросать мерзкий питон и бежать писать приложения на коболе под мейнфреймы.

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

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

официально 5000 узлов предел,

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

Я упоминал Nomad,

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

Что это за аргумент вообще про «промышленные установки»?

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

Ещё бы Кобол вспомнил,

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

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

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

В идеале при этом иметь возможность за 30 секунд всё пересобрать с новыми правками и запустить снова для отладки.

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

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

это не проблема технологии - это проблема настройки и/или управленческая проблема