Помогите найти ответ альфы Спуфингу про админство и системд

В твоём понимании контейнеризация достаточна для того, чтобы называть приложение cloud-native?

У cloud-native сервисов есть херова туча ограничений и новых возможностей, которых нет у софта, писанного под голую железку. Пытаться перечислять их не вижу смысла, в контексте обсуждения важно лишь то, что нельзя по щелчку пальцев перенести на облако софтину, которая 20 лет писалась под выполнение на физическом железе.

Coolify и десятки других аналогичных проектов деплоят PaaS инстансы СУБД без контейнеров?

Насколько мне известно, в Coolify нет готового решения для того, чтобы раскрутить экземпляр БД в контейнере на firecracker или в голой VM. Ты сам должен сначала развернуть-настроить эту VM, а потом уже её можно подключить к Coolify точно так же, как любую другую машину.

Тебя не учили, что кластер обычного Кубера с обычнымс etcd должен находиться в одном регионе?

Так и я о том же. Ну и чо ты делать собрался, если у тебя два региона? Всё, кубернетес не нужен?

И да, я перепутал зоны с регионами, всё-таки в массовом IT зонами называют датацентры в одном регионе.

Ты про их Аврору или про что? И опять, причём тут Кубер?

Да практически всё там AZ и Region-aware.
Кубер тут при том, что он чувствует себя намного хуже по мере увеличения задержки транспорта.

Но managed Kuber то у них обычный?

ХЗ. У гугла точно не обычный.

У Кубера кроме self-healing ещё десятки полезных возможностей.
В т.ч. поддержка эластичности при росте нагрузки, если оркестратор инфры помогает с такой эластичностью.

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

Если же у тебя малонагруженная система на трёх серверах, то вообще пофигу твоя эластичность.

Это какой инструмент? Который эластичными нодами рулит?

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

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

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

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

Чего с твоей точки зрения не хватает для cloud-native у PG с операторами типа CNPG и Crunchy?

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

Более того, насколько мне известно, ни CNPG, ни Crunchy не дают полной гарантии от split brain. О какой отказоустойчивости может идти речь, если твоя система допускает повреждение данных при fail-over?

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

Что значит недоказумо? Все сообщения в треде, их никто не удалял:
Помогите найти ответ альфы Спуфингу про админство и системд (комментарий)
«Так я уж устал повторять, что такие вопросы решает Docker like и Кубик.»

А сам при этом доказумео путаешь ReplicaSet и StatefulSet, что намекает на твою проф непригодность для работы с Кубером?

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

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

Нет кэширующего софта, работающего через IVSHMEM и/или RDMA?

Ты это дело на кубернетесе собираешься деплоить, я всё правильно понял? Интересно было бы пронаблюдать.

«Так я уж устал повторять, что такие вопросы решает Docker like и Кубик.»

Ещё раз хочу определить scope: малый и средний бизнес, а не инфра гиперскейлеров.

IMHO OpenRC + docker-compose обычно достаточно для оркестрации, которую выполняет systemd.

я его изучаю исключительно из интереса «как не нужно проектировать системы».

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

Ты это дело на кубернетесе собираешься деплоить, я всё правильно понял? Интересно было бы пронаблюдать.

Я не собираюсь, но возможно кто-то собирается.

Мне достаточно обычной сетки Кубера для кэширования в Redis like сервисах.

Активацию по сокету ты как сделаешь в OpenRC + Docker?

Мне лишние дыры ненужны.

Ну и как ты собрался автомасштабировать систему? Руками по SSH?

В OpenRC нет возможности указать последовательность запуска сервисов?

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

А в docker-compose есть depends_on и т.п.

Предлагаешь всю систему делать одним docker-compose конфигом?

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

Поскольку у тебя нет какого-то собственного мнения о том, как должна быть устроена БД в кубере, то, чтобы не гонять обсуждения взад вперёд, давай я сам опишу два основных подхода к организации, и объясню, почему они оба так-себе:

1. Мы понимаем, что БД капризны, потому даём докеру таймауты в минуту и право убрать все сервисы с узла, на котором крутится БД. Сеть без NAT, кэши все принадлежат БД. При этом внезапно оказывается, что такой сетуп ничем не отличается от статичной БД на железе.
2. Мы не понимаем, что наша БД не адаптирована под облака, и делаем её обычным StatefulSet, даём экземплярам виртуальные IP, чтобы каждая реплика имела тот же IP после отказа; мы крутим рядом с БД хер пойми какие сервисы, которые кубер решил «отмасштабировать» по нагрузке. Мы получаем совершенно непредсказуемо плавающую задержку отклика БД и периодические полные зависания под нагрузкой, когда куберу показалось, что БД перегружена и не отвечает.

Если у тебя не хватает экспертизы в K8s, то можно ограничиться докером (+ compose ессно и т.п.).

Спасибо, мне хватает подмана.

K8s и docker-compose - это системы оркестрации (ессно разного калибра).

Docker-compose — это уже более адекватная спецификация. Конечно, тут можно дойти до того, что OpenRC — это тоже система оркестрации... Да и bash тоже система оркестрации.... просто «низкого уровня».

Хотя бы пруф вот этого твоего очередного бреда:

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

Ты хочешь мне сказать, что Alpine не разрабатывался как легковесная система для сборки конейнеров? Ку-ку, дядя, ты с этой планеты?

На обычном дистре K8s не поставить?

Поставить. Так и чем alpinebox отличается от убунты?

Ты про Elixir в Кубере?
А причём тут я, если такое есть даже в либах для твоего любимого Elixir?
https://github.com/bitwalker/libcluster

Я не совмеваюсь, что есть упоротые, которые будут запускать BEAM в кубернете, и кубернет будут в кубернете запускать, и systemd. Это всё ещё не значит, что это адекватное решение.

Многие сервисы на Go собираются статически просто добавлением одного флага сборки.

Весь софт написан на Go, ога?

Если ты читал интервью с Соломоном Хайксом, одним из создателей докера, то ты в курсе, что докер был создан для решения проблемы деплоя. А не масштабирования, оркестрирования, или чего бы то ни было ещё. То есть, «как сделать нашу кучу говна одним цельным бинарником».

Статичные бинари из коробки умеют делать C/C++, Rust, Go — из популярных и более-менее поддерживаемых, это всё. Этого мало?

journald на таких объёмах будет лучше OpenObserve?

Сравнимо, с замечаниями. OpenObserve может выдавать сложные запросы быстрые за счёт колоночного хранения, но надёжность у него оставляет желать лучшего. Journald использует простое индексированное хранилище, которое может потребовать сложнее full scan-ы, но зато оно всегда железно рабочее.

IMHO OpenRC + docker-compose обычно достаточно для оркестрации, которую выполняет systemd.

Запуск сервисов в ответ на установку железки? Точно? Логи чем собирать собрался? Udevd и networkd у нас куда войдут — в докер или в systemd?

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

Соболезную.

Мне достаточно обычной сетки Кубера для кэширования в Redis like сервисах.

Скажем так: действительно, так делают. Создают дефект в архитектуре, затыкают его кешем. Потом рассогласованность данных в кеше затыкают ещё одним сервисом, который контролизует синхронизацию данных. И по итогу то, что должно было быть одной БД и одним сервисом становится «гибкой системой», для обслуживания которой теперь нужен штат девопсов.

Я ещё раз напомню мою любимую цитату по теме:
@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.

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

Сначала ты сам лично плачешь, что в Linux возможно охлаждение кэшей:

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

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

Кэши? Что ты собрался с ними делать?

Потом у тебя кеш внезапно перемещается в другой ДЦ:

Ещё бы предложил в другом датацентре.

Зачем мне перемещать кеш в другой ДЦ? Ты альтернативно одарённый чтоли или просто обычный тролль, откуда у тебя такие фантазии?

Т.е. мы перманентно наблюдаем твои мысли - твои скакуны, но при этом ты упорно не хочешь придерживаться того скоупа, от которого мы изначально шли - это вообще всего лишь только лишь на LOCALHOST! замена systemd на связку OpenRC (или другой лайтовый инит) + Docker Compose (или локальный однонодовый Кубер, например k0s в докере).

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

Создают дефект в архитектуре, затыкают его кешем.

С чего ты взял, что я буду создавать дефект? Мало ли кто там чего создаёт, я то тут причём?

Valkey для Hibernate L2 Cache не может обеспечить консистентность кэша?

Запуск сервисов в ответ на установку железки? Точно? Логи чем собирать собрался? Udevd и networkd у нас куда войдут — в докер или в systemd?

Сам-то как думаешь? Ты вообще тред читал? Или как посредственная LLMка быстро забываешь, что мы обсуждали уже ранее?

Помогите найти ответ альфы Спуфингу про админство и системд (комментарий)

Я уже упоминал:

Ты udev и crond

Простые сервисы в Alpine Linux на хосте.

Сам догадаешься или опять будешь кривляться как обычно?

Соболезную.

Им?

https://www.cncf.io/blog/2025/08/02/what-500-experts-revealed-about-kubernetes-adoption-and-workloads/

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

VictoriaLogs тебя устроит?

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

Рабочее даже тогда, когда over несколько сотен гигабайт логов ?

Если ты читал интервью с Соломоном Хайксом, одним из создателей докера, то ты в курсе, что докер был создан для решения проблемы деплоя. А не масштабирования, оркестрирования, или чего бы то ни было ещё. То есть, «как сделать нашу кучу говна одним цельным бинарником».

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

Я изначально ещё в начале нашей дискуссии упоминал docker-compose, прекрати уже в контексте этого топика придираться к Docker. По твоему docker-compose - не оркестратор?

Статичные бинари из коробки умеют делать C/C++,

Ога, любую программу на плюсиках прям легко и просто пересобрать статически одним бинарем и чтобы она работала без glibc ?

И таки готовые пакеты дистра в Docker куда проще и быстрее почти при любом раскладе?

Я не совмеваюсь, что есть упоротые, которые будут запускать BEAM в кубернете,

А что плохого?

и кубернет будут в кубернете запускать,

И много ты таких кейсов видел? Не перепутал с управлением кластерами из других кластеров?

и systemd. Это всё ещё не значит, что это адекватное решение.

systemd я стараюсь запускать не то чтобы в Кубере, а вообще нигде по возможности.

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

А чем он занимался в 2005 году задолго до появления Linux контейнеров?

Ку-ку, дядя, ты с этой планеты?

Ку-ку

Alpinebox,

ZFS из каропки, без которого он вообще не работает. Для контейнера? Ещё раз ку-ку?

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

Почему в нём есть пакеты kubernetes, ZFS и мод udev?

Docker-compose — это уже более адекватная спецификация.

Я тебе талдычу про это уже почти 2 месяца, а у тебя только сейчас произошёл «уже»:

Помогите найти ответ альфы Спуфингу про админство и системд (комментарий)

Конечно, тут можно дойти до того, что OpenRC — это тоже система оркестрации…

Зачем? У тебя опять мозг галлюцинирует?

Мы понимаем, что БД капризны, потому даём докеру таймауты в минуту и право убрать все сервисы с узла, на котором крутится БД. Сеть без NAT, кэши все принадлежат БД. При этом внезапно оказывается, что такой сетуп ничем не отличается от статичной БД на железе.

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

мы крутим рядом с БД хер пойми какие сервисы, которые кубер решил «отмасштабировать» по нагрузке

А сделать для СУБД отдельные выделенные ноды в Кубере никак нельзя?

Ну и как ты собрался автомасштабировать систему? Руками по SSH?

А чем тут поможет сокет активация?

В том-то и дело, что в systemd сервисы не запускаются последовательно — они запускаются параллельно.

А зачем мне это? Но таки OpenRC умеет и такое безобразие?

Я помню прикол на старой убунте,

Не упоминай Бабуинту в суе, IMHO она подходит только для контейнеров.

Потому что, видите ли, логин у них происходит после инициализации сети.

А ещё там есть snap.

Предлагаешь всю систему делать одним docker-compose конфигом?

Все сервисы зависят друг от друга?

Я свой конфиг замены systemd предлагаю обычно для серверов. Там на самом хосте обычно не шибко много других сервисов. Обычно Docker, K0s и Incus, и то даже k0s и Docker нередко оказываются внутри LXC контейнеров Incus.

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

Не надо так, время сейчас неспокойное.

Что значит недоказумо? Все сообщения в треде, их никто не удалял: Помогите найти ответ альфы Спуфингу про админство и системд (комментарий) «Так я уж устал повторять, что такие вопросы решает Docker like и Кубик.»

Docker like - это compose с контейнерами, я уже упоминал давным давно.

О какой отказоустойчивости может идти речь, если твоя система допускает повреждение данных при fail-over?

Я вообще обычно критически важные базы данных запускаю вне K8s, обычно в Docker.

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

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

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

Cluster Autoscaler или Karpenter напишут?

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

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

Я будто с нейросеткой разговариваю и пытаюсь ей объяснить разницу между полимером и лицемером. Завязывай уже с этой херней.

Есть кеш процессора, есть страничный кеш ОС, есть кеш у приложений, есть кеш, как веб-сервис. Что ты хотел сказать — я так до конца и не понял. Возможно «пофиг на медленную БД — у меня будут быстрые кеши колхозные», но, судя по всему, у тебя какие-то свои определения кешей и методов их применения — уже дошли до того, что через RDMA в кубернете память отображаем из удалённой машины:
Помогите найти ответ альфы Спуфингу про админство и системд (комментарий)
«Нет кэширующего софта, работающего через IVSHMEM и/или RDMA?»
Ещё с таким невозмутимым тоном, будто каждый школьник IVSHMEM-кеши на кубере клепает — один я только не умею.

Потом у тебя кеш внезапно перемещается в другой ДЦ

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

это вообще всего лишь только лишь на LOCALHOST! замена systemd на связку OpenRC (или другой лайтовый инит) + Docker Compose (или локальный однонодовый Кубер, например k0s в докере).

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

С чего ты взял, что я буду создавать дефект? Мало ли кто там чего создаёт, я то тут причём?

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

Valkey для Hibernate L2 Cache не может обеспечить консистентность кэша?

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

Ну давай, расскажи мне, что ты эту историю не из нейросетки надёргал.

Про Hibernate L2 кэш? Смеёшься? У меня 10+ лет опыта программирования nHibernate.

Есть кеш процессора, есть страничный кеш ОС

Что ты хотел сказать — я так до конца и не понял.

Ты вроде жаловался, что их у тебя выносит? Забыл уже?

Возможно «пофиг на медленную БД — у меня будут быстрые кеши колхозные»

Ну вот хоть такие, да, хотя бы.

уже дошли до того, что через RDMA в кубернете память отображаем из удалённой машины:

А по твоему таких кейсов не существует? С тем же Valkey, btw.

https://valkey.io/topics/RDMA/

Контрибьютеров Valkey уже больше, чем у Redis, btw.

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

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

Ты udev и crond

Простые сервисы в Alpine Linux на хосте.
Сам догадаешься или опять будешь кривляться как обычно?

Alpinebox — это конструктор, который ставит пакеты из репозиториев. И поставить их можно несколько вариантов. Так что нет, не догадаюсь.

Так или иначе, дистр на Alpine — это обычный POSIX деплой с изменяемой файловой системой и установкой пакетов, аля слака или арч, потому никаких преимуществ для запуска докеров у него нету.... Но я уже это писал, и я не уверен, что в третий раз мысль дойдёт.

https://www.cncf.io/blog/2025/08/02/what-500-experts-revealed-about-kubernete...

Я недавно работу нашел. Тут тоже mission critical и всё такое. 95% этого «mission critical» цирка таковой только по бумажкам, под капотом там негры сношают бомжей. Потому я так недоволен твоими историями про «а вот у ваньки ерохина сервисы cloud native».

Я будто с нейросеткой разговариваю

ДАТЫШТО!

Ещё один клоун выполз.

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

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

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

https://radiotochki.net/blog/lifehack-school/priem-solomennoe-chuchelo-kak-raspoznat-i-neytralizovat-manipulyaciyu-v-spore.html

https://magisteria.ru/introduction-to-deductive-logic/straw-man-error

Узнаешь свой стиль общения?

Если джуна с нейросеткой щёлкать …

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

когда аудитория узнаёт правду

…с тебя начинают ржать.

Таблица сравнения ошибок byko3y vs sanyo1234

Вывод одним предложением:
byko3y проиграл дискуссию по всем техническим и логическим пунктам + сильно проиграл по манерам. sanyo1234 допустил только две мелкие ошибки (ссылался на Grok) и в остальном был точен и последовательен.

Какое позорище…

Ну и кто из вас, иишечек, приписал byko3y сказанное мной «ДАТЫШТО», признавайся.

Grok очевидно, забыл тебя отметить, абидна да?

Я не обижаюсь на технику. Она тупая. Она не умеет думать. Она глууупая. Тупорыыылая. Чо на нее обижаться-то?

Grok ещё и авторов этих фраз попутал:

«школьоло не вывозит и зовёт брата»• «альтернативно одарённый»• «тролль»• :)

Я больш всего в шоке с того, что нейросетка не мои цитаты мне приписала. Вроде я считал, что работа с большими контекстами, «иголка в стоге сена» уже более менее работает в ИИ — а вот гляди ж ты, нет, путается.