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

а доступ к другим mounts (ну скажем /mnt/my_secrets), полный что ли останется?

Проверил. Да.

ProtectSystem=full

Это не защищает другой mount point. Все mount-ы копируются в новый нэймспэйс, и если у пользователя есть туда доступ (chmod), то и всё, всё есть, даже на запись..

К слову о важности чтения этих системд-простыней, которые никто не читает. И потом путаются. Ты ведь думал что «со всем требуемым сендбоксингом»? :)

В каком-то смысле это должно бы быть дефолтом для многих сервисов.

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

А у нас есть какие-то третьи альтернативы годные по состоянию на 2026?

Контейнеры и их оркестраторы со своими декларативными настройками ресурсов?

со всем требуемым сендбоксингом

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

Есть ли простой способ ограничить доступ сервисов к некоторым mount points? Знаю про InaccessiblePaths из systemd.exec, это то что надо. Но его не применить system-wide в systemd-system.conf, чтобы стало для всех сервисов.

Моё решение – написать «башговно» (издеваюсь над тобой; конечно баш это супер-клей) которое будет проходить по всем service юнитам и добавлять/менять в них эти строки. А как сделать по уму, по-системд-эшному?

Контейнеры и их оркестраторы со своими декларативными настройками ресурсов?

Ты udev и crond в Docker Swarm предлагаешь запускать? К сожалению, в тесно интегрированных системах контейнера создают больше проблем, чем решают.

Ты udev и crond

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

в Docker Swarm предлагаешь запускать?

А что, systemd уже стал распределённым?

Почему не просто Docker или Podman?

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

Каких проблем?

в Docker Swarm предлагаешь запускать?

А что, systemd уже стал распределённым?
Почему не просто Docker или Podman?

Podman создаёт сервисы systemd — по итогу ты используешь systemd или systemd.

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

Каких проблем?

Докер изначально был создан не для управления ресурсами и доступами — ресурсами и доступами управавляли прекрасно без докеров десять лет до этого, cgroups тоже не Docker Inc. создал.

Основная фишка докера заключалась в том, что он создавал виртуальную систему, независимую от хоста, что позволяло делать всякие безобразия, вроде биндинга на 80 порт, установки любого софта в /usr и любых конфигов в /etc. Тут как бы больше вопрос «а какого чёрта софту под линуксом нужно обязательно нужно устанавливаться так, будто он единственная программа в системе» — и это как бы вопрос к олдам, почему они запустили инфру до такого состояния и ничего с этим не делали. Больнее всего это было для всяких там Python, PHP, Perl.

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

Podman создаёт сервисы systemd — по итогу ты используешь systemd или systemd.

Это обязательное его поведение?

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

На что это влияет в контексте нашей дискуссии? Разве это аргумент против контейнеров?

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

и без systemd?

cgroups тоже не Docker Inc. создал.

и не Лёня?

Основная фишка докера заключалась в том, что он создавал виртуальную систему, независимую от хоста

И что в этом плохого? :)

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

Независимый от чего?

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

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

Podman создаёт сервисы systemd — по итогу ты используешь systemd или systemd.

Это обязательное его поведение?

Кратко, суть в том, что докер-подман — это не инструмент оркестрации сервисов на локальной машине. Когда подману нужно оркестрировать, он берёт тот же системд.

На что это влияет в контексте нашей дискуссии? Разве это аргумент против контейнеров?

Докер — это инструмент для узкой задачи. Ну вот когда я llama.cpp собирал на старой убунте — я брал официальный образ от nvidia, потому что они каждые два года ломающие изменения вносят. Если мне нужно запустить сервис под свою текущую платформу — зачем мне докер?

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

и без systemd?

cgroups тоже не Docker Inc. создал.

и не Лёня?

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

Основная фишка докера заключалась в том, что он создавал виртуальную систему, независимую от хоста

И что в этом плохого?

В том, что мягко говоря не всем сервисам нужно существовать в вакууме. Веб-серверу нужно связываться с сервисами логики, сервисам логики нужно связываться с БД.

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

Ну с этого можно было начинать. Кубернет тебе тоже не нравится, я правильно понимаю?

Кратко, суть в том, что докер-подман — это не инструмент оркестрации сервисов на локальной машине. Когда подману нужно оркестрировать, он берёт тот же системд.

docker/podman compose тоже не инструмент оркестрации?

Если мне нужно запустить сервис под свою текущую платформу — зачем мне докер?

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

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

Хорошо, есть сходство?

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

В докере контроль ресурсов не хуже? А где гарантия, что твой сервис окажется «недебильным» (c)? Мало тебе CVE?

В том, что мягко говоря не всем сервисам нужно существовать в вакууме. Веб-серверу нужно связываться с сервисами логики, сервисам логики нужно связываться с БД.

А в docker-compose и даже в обычном докере сеть отсутствует?

Кубернет тебе тоже не нравится, я правильно понимаю?

По твоему Kubernetes тесно интегрирует сервисы? Что там про это написано в 12 заповедях?

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

Это в обе стороны можно крутить — как насчёт «держать на сервере софт с уязвимостями, исправленными два года назад»?

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

Хорошо, есть сходство?

Ты к чему? Я это писал к тому, что и у systemd, и у докера, и у того же docker compose декларативные файлы.

В докере контроль ресурсов не хуже? А где гарантия, что твой сервис окажется «недебильным» (c)?

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

  ├─snap.ollama.listener.service 
  │ ├─170688 /bin/bash /snap/ollama/101/bin/snap_launcher.sh serve
  │ └─170750 /snap/ollama/101/bin/ollama serve

А в docker-compose и даже в обычном докере сеть отсутствует?

Зачем «удобно настраивать» докер, если можно вообще его не иметь и ничего не настраивать? Чисто теоретически можно в контейнер прокинуть корень ФС и все неймспейсы с хоста, но зачем тогда докер?

По твоему Kubernetes тесно интегрирует сервисы? Что там про это написано в 12 заповедях?

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

Это в обе стороны можно крутить — как насчёт «держать на сервере софт с уязвимостями, исправленными два года назад»?

Ведь если постоянно апдейтить дистрибутив, то это получается latest из стабильной ветки? Что мешает аналогично указать тег latest при наличии стабильного канала образов контейнеров или просто major версию при поддержке semver?

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

Если бы только это, там ещё 100500 разного ненужноД, и может сломаться в любой момент.

Ты к чему? Я это писал к тому, что и у systemd, и у докера, и у того же docker compose декларативные файлы.

К тому, что docker-compose прекрасно оркестрирует сервисы на одноноде.

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

Зачем контейнер портить снаружи системдой?

крутится в snap контейнере:

А он этот снэп сам не того самого в твоей терминологии?

Зачем «удобно настраивать» докер, если можно вообще его не иметь и ничего не настраивать?

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

Что-то там про «чем больше страдает девопс — тем больше ему воздастся на небесах».

А девопсы страдают?

Я убежал из конторы, которая начала вводить кубернет.

Сбежал от прогресса?

Там как бы дело не про интеграцию сервисов на уровне одного хоста, а про создание сплошного комка сервисов на уровне кластера.

Это же твоё любимое, когда много инстансов с консенсусом? А как их деплоить без Кубера? Ансиблой?

Ведь если постоянно апдейтить дистрибутив, то это получается latest из стабильной ветки? Что мешает аналогично указать тег latest при наличии стабильного канала образов контейнеров или просто major версию при поддержке semver?

Я напоминаю, что для этого кому-то нужно собирать образы со стабильной веткой базового дистрибутива. Далеко не каждый апстрим так делает. Особенно пет проекты-переростки на гитхабах любят собираться с последним мусором, который они успеши натаскать в репу. Дистрибутивы аля Debian или RHEL служат как раз для того, чтобы подобрать стабильные конфигурации и поддерживать их после того, как апстрим забил болт на эту поддержку.

Для сборки софта из сорцов на хостовом стабильном дистре докер является просто лишним звеном. Он нужен как раз для моего случая с llama.cpp — когда нужно собраться не для той системы, которая хост.

Если бы только это, там ещё 100500 разного ненужноД, и может сломаться в любой момент.

Офигенная история, а на докере логирование-мониторинг резко не нужны становятся? Я просто из-за одного того факта, что в докере нет своего удобного логирования, готов отказаться от докера.

К тому, что docker-compose прекрасно оркестрирует сервисы на одноноде.

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

Вот на моей последней работе был деплой через docker+docker-compose, и при этом система была приколочена гвоздями к железу — я честно не понимаю такого прикола.

А он этот снэп сам не того самого в твоей терминологии?

Да, и подман тоже. Я об этом и писал. Systemd и Docker совершенно разные функции выполняют, потому говорить «я использую докер вместо systemd» просто неграмотно. Я же писал про то, что зачем использовать докер, когда всё то же самое можно сделать без докера? Элементарная бритва Оккама.

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

Чтобы была изоляция и иммутабельность нужно Firecracker, если уже на то пошло. А докер — это ни рыба, ни мясо. Я ещё раз повторюсь, что докер прежде всего нужен деплойщикам всякого мусора на питоне и PHP — для людей со статично линкованными бинарями вся иммутабельность окружения заключается в том, что байты бинаря не поменялись.

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

docker run --rm -v $(pwd):/app -v /home/user/.cache/llama.cpp/:/root/.cache/llama.cpp/ \
        --cap-add=SYS_PTRACE --security-opt seccomp=unconfined \
        --device /dev/nvidia0:/dev/nvidia0 --device /dev/nvidiactl:/dev/nvidiactl \
        --device /dev/nvidia-uvm:/dev/nvidia-uvm  -it localhost/llama-builder

Что-то там про «чем больше страдает девопс — тем больше ему воздастся на небесах».

А девопсы страдают?

Как грил один мой коллега «любой каприз за ваши деньги. Весь WhatsApp разрабатывался и обслуживался командой из 11 человек, от начала и до конца — как ты думаешь, какую версию кубернетеса они использовали?

Там как бы дело не про интеграцию сервисов на уровне одного хоста, а про создание сплошного комка сервисов на уровне кластера.

Это же твоё любимое, когда много инстансов с консенсусом? А как их деплоить без Кубера? Ансиблой?

Я ХЗ, в какой момент ты решил, что это моё любимое. Я щитаю себя экспертом по распределёнке, но именно по этой причине я щитаю, что консенсусы должны быть исключительной мерой, а не „первое, за что хватаюсь“.

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

Я напоминаю, что для этого кому-то нужно собирать образы со стабильной веткой базового дистрибутива. Дистрибутивы аля Debian или RHEL служат как раз для того, чтобы подобрать стабильные конфигурации и поддерживать их после того, как апстрим забил болт на эту поддержку.

Для популярного софта нет постоянно обновляемых готовых образов из тех же самых дистрибутивов?

LinuxServer.io

Docker Hardened Images (с 2025–2026) — ещё лучше для тех, кто параноит: distroless-подход, near-zero CVE, non-root по умолчанию, SBOM. Каталог огромный, и они бесплатны/OSS.

https://hub.docker.com/hardened-images/catalog

При привязке к правильным semver-тегам получаешь предсказуемые security-обновления, очень близкие к политике Debian stable.

Для сборки софта из сорцов на хостовом стабильном дистре докер является просто лишним звеном.

Открою страшную тайну. Большинство современных CI (GitLab, Woodpecker, и даже Jenkins K8s operator) систем построено на контейнерах.

Офигенная история, а на докере логирование-мониторинг резко не нужны становятся? Я просто из-за одного того факта, что в докере нет своего удобного логирования, готов отказаться от докера.

https://docs.docker.com/engine/logging/configure

local	Logs are stored in a custom format designed for minimal overhead.
json-file	The logs are formatted as JSON. The default logging driver for Docker.
syslog	Writes logging messages to the syslog facility. The syslog daemon must be running on the host machine.
journald	Writes log messages to journald. The journald daemon must be running on the host machine.
gelf	Writes log messages to a Graylog Extended Log Format (GELF) endpoint such as Graylog or Logstash.
fluentd	Writes log messages to fluentd (forward input). The fluentd daemon must be running on the host machine.
awslogs	Writes log messages to Amazon CloudWatch Logs.
splunk	Writes log messages to splunk using the HTTP Event Collector.
etwlogs	Writes log messages as Event Tracing for Windows (ETW) events. Only available on Windows platforms.
gcplogs	Writes log messages to Google Cloud Platform (GCP) Logging.

Через vector.dev оно интегрируется с любым ингестом логов

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

Портируемость и иммутабельность — образ гарантированно запустится одинаково везде (с теми же зависимостями). Никогда не сталкивался с невозможностью установить или обновить пакет даже из Debian stable, потому что он ломал те или иные зависимости?

Вот на моей последней работе был деплой через docker+docker-compose, и при этом система была приколочена гвоздями к железу — я честно не понимаю такого прикола.

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

Systemd и Docker совершенно разные функции выполняют, потому говорить «я использую докер вместо systemd» просто неграмотно.

Заметь, я упоминал Alpine Linux, т.е. OpenRC + Docker вместо systemd.

Чтобы была изоляция и иммутабельность нужно Firecracker, если уже на то пошло.

А ещё лучше по отдельной железке с OpenBSD под каждый несистемный сервис?

А докер — это ни рыба, ни мясо.

Докер покрывает потребности большинства пользователей одноноды.

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

Это лишь показывает то, что при желании точечно можно интегрировать и докер, но при этом остальные несистемные сервисы изолировать по умолчанию?

Как грил один мой коллега «любой каприз за ваши деньги. Весь WhatsApp разрабатывался и обслуживался командой из 11 человек, от начала и до конца — как ты думаешь, какую версию кубернетеса они использовали?

Как ты думаешь, сколько на рынке таких специалистов, и сколько они стоят? Сколько компаний пишут на Erlang/Elixir? Меньше 1% ? Кто потом будет поддерживать их велосипед? Традиционный вопрос, почему не на асме или в машкодах.

Я ХЗ, в какой момент ты решил, что это моё любимое.

Много твоих постов, где ты с удовольствием рассказывал про консенсусы в самых разных проявлениях?

Я щитаю себя экспертом по распределёнке

Спешите видеть, эксперт по распределёнке предлагает непрофильным компаниям (которых большая часть), деплоить распределёнку на велосипедных самодельных аналогах Кубера.

Скажем так: когда компания дорастает до масштаба гугла, то она проходит много этапов перед тем, как у неё возникает вопрос „у нас больше десятка хостов и мы уже не можем руками запускать-тушить сервера — как нам масштабироваться?“.

Managed K8s, нет не слышали, ведь мы же иксперд по распределёнке! :)

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

Дооо, Strimzi Kafka и Redpanda смеётся над твоими «гениальными» мыслями.

Docker Hardened Images (с 2025–2026) — ещё лучше для тех, кто параноит: distroless-подход, near-zero CVE, non-root по умолчанию, SBOM. Каталог огромный, и они бесплатны/OSS.

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

Открою страшную тайну. Большинство современных CI (GitLab, Woodpecker, и даже Jenkins K8s operator) систем построено на контейнерах.

Ноуп, родные раннеры на GitLab и GitHub прежде всего сделаны на microVM, и потом уже внутри них можно запустить контейнера при желании.

Например:
https://github.com/bcit-ci/CodeIgniter/blob/develop/.github/workflows/test-ph...
Они тестятся прямо на хосте, но postgresql/mysql сервера запускают как контейнера.

Или вот сам postgresql:
https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto
https://github.com/postgres/postgres/tree/master/src/tools/ci
Опять же VM- и metal-based по большей части, никаких контейнеров.

Так или иначе, все серьёзные хостеры крутят контейнера внутри microVM, никто на хосте контейнера не выдаёт.

https://docs.docker.com/engine/logging/configure
journald Writes log messages to journald. The journald daemon must be running on the host machine.
Через vector.dev оно интегрируется с любым ингестом логов

А кто будет journald реализовывать? Тебе обязательно нужен логер к докеру — а в systemd уже есть systemd-journald. В том и прикол: systemd — это законченная система локальной оркестрации. А докер — это просто один молоток.

Портируемость и иммутабельность — образ гарантированно запустится одинаково везде (с теми же зависимостями).

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

Я напоминаю, что контейнера — это linux-only решение, потому какая нафик портируемость? Ты изначально писал про изоляцию и иммутабельность — это валидный набор требований для контейнеров. А вот портируемость — нет, контейнера не портируемы. Даже на ARM той же версии линя ты x86 контейнера не запустишь.

Заметь, я упоминал Alpine Linux, т.е. OpenRC + Docker вместо systemd.

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

А ещё лучше по отдельной железке с OpenBSD под каждый несистемный сервис?

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

Самый элементарный пример — в линуксе отсутствуют инструменты точного контроля потребления RAM, и при этом чрезмерное использование памяти может привести к выносу кэшей с катастрофическим влиянием на производительность. К слову, мне на LOR-е подсказали классный сервис, Early OOM, больше у меня подобных проблем нет. Другое дело, что в проде идея «убить случайный сервис БД, потому что мы не подрасчитали ресурсы хоста» — это так-себе затея, а вот для десктопа самое оно.

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

Это лишь показывает то, что при желании точечно можно интегрировать и докер, но при этом остальные несистемные сервисы изолировать по умолчанию?

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

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

Как ты думаешь, сколько на рынке таких специалистов, и сколько они стоят? Сколько компаний пишут на Erlang/Elixir? Меньше 1% ? Кто потом будет поддерживать их велосипед? Традиционный вопрос, почему не на асме или в машкодах.

Вопрос в 2026 не актуален, поскольку рынок труда завален сеньорами, ищущими работу. То, что 90% соискателей пишут на JS и Python, говорит просто про то, что большинство из них не смогут найти работу за приемлимые деньги.

Много твоих постов, где ты с удовольствием рассказывал про консенсусы в самых разных проявлениях?

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

Спешите видеть, эксперт по распределёнке предлагает непрофильным компаниям (которых большая часть), деплоить распределёнку на велосипедных самодельных аналогах Кубера.

Может быть я не совсем понятно выразился, но Ansible+systemd — это не совсем «самодельные велосипеды», хотя определённая доля ручной работы есть. Но в кубернетесе доля ручной работы выше, по крайней мере если цель — получить на k8s high availability, а не отвалиться с первым хостом, как это может произойти в топорном варианте с Ansible+systemd (хотя не факт, опять же, как настроишь).

Если нужно что-то чуть более сложное — есть Nomad. Опять же, как и в случае с systemd, сервисы могут быть чем угодно, не обязательно контейнерами.

От того, что ты настроил self-healing/failover на кубернетесе ты ещё не решил автоматически проблему «самовылечившаяся система теперь пускает пакеты от логики до БД через три хоста» — именно потому я пытался пояснить, что иметь изначально хорошо координирующийся сервис намного удобнее, чем пытаться лепить совершенно беспорядочно разработанные сервисы в единый комок в кубернете. Ну типа «столько-то экземпляров сервиса должны быть на том же хосте, что и БД, для БД нужен выделенный PV, такая-то доля запросов балансируется на удалённые хосты» — это как бы база, это даже не сложный сценарий, есть и повеселее, вроде эксплуатации со смешанными версиями при миграции.

Managed K8s, нет не слышали, ведь мы же иксперд по распределёнке!

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

По этой причине и по указанной выше проблеме с конфигурацией PV пользователи managed k8s часто предпочитают облачные БД вместо собственных БД на managed k8s. А если у тебя по итогу сплошные stateless сервисы в кубере, то там уже и не ясна ценность широких возможностей кубера по конфигурации кластера.

Дооо, Strimzi Kafka и Redpanda смеётся над твоими «гениальными» мыслями.

Ну я же написал «есть и такие извращенцы». Это я про Strimzi Kafka. Там поесть говна можно больше, чем получить преимуществ — но зато «клауд натив».

Вот Redpanda — это да, аргумент. Но это не Kafka, а отдельная protocol-compatible софтина.

А у нас есть какие-то третьи альтернативы годные по состоянию на 2026?

Давай конкретизируем. Пусть речь о сайте, мелкого бизнеса. Мой вариант: любой runit / openrc / etc.

Кмк, systemd-эшный сэндбоксинг должен интересовать (хозяина бизнеса) примерно в последнюю очередь. Баг скорее будет в бэке чем в ядре. Злоумышленник ломает бэк, копирует себе базу, удаляет всё через sql, и требует выкуп. Баг в gunicorn кмк примерно равносилен багу в бэке; баг в nginx скорее даже менее критичен. systemd-эшный «сэндбоксинг» здесь вообще нипричём. Это дополнительная защита от установки бэкдора для будущих заходов. Дополнительная – потому что и без нэймспэйсов сама система с её пёмишенами не позволит пользователю бэка установить бэкдор.

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

Соответственно я бы зашёл с противоположной стороны чем sanyo1234: предлагать не альтернативы с паритетным и выше функционалом (докер), а наоборот, ну его (функционал) нафик. Сделать сайт в стиле начала нулевых.

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

Знаю про NoNewPrivileges, ок, реальный плюс. В альтернативах его можно выставить с python3-prctl.

...офигел от такого отношения...

Та это сплошь и рядом. Все люди разные.

Так что не парься.

Злоумышленник ломает бэк, копирует себе базу, удаляет всё через sql, и требует выкуп

Ну тут системд не поможет. Правда, ХЗ что вообще поможет. Пытаться изолировать систему, в которой сам по себе уязвим ключевой сервис — это история про «корзинка цена — яйца всмятку», то есть, от того, что выжила система, легче никому не будет.

Ну для логики всякие там жавы придуманы — но это всё уже не про системы оркестрирования и прочую системщину.

И я напоминаю, что я сам изначально писал, что докеры — это про решение проблем деплоя, а не про безопасность.

Я не про деплой или изоляцию, а про альтернативы systemd (вынес в цитату). Там где деньги, там первым делом безопасность. systemd для безопасности сайта мелкого бизнеса +- ниочём. А значит альтернатива – любая. Но я нуб, и хотел уточнить-убедиться.

ХЗ что вообще поможет

На/пере-писать бэк для select+insert-only доступа к базе. Тяжело, да. И бэкапы желательно тоже специфические сделать. К слову, сообщения тут на лоре похоже именно так сделаны (не обновляются и не удаляются). ИИ подсказал это называется event sourcing pattern. Может в джаве такое прямо встроено, не знаю.

Там где деньги, там первым делом безопасность. systemd для безопасности сайта мелкого бизнеса +- ниочём. А значит альтернатива – любая. Но я нуб, и хотел уточнить-убедиться.

Я тебя умоляю. Там, где деньги — там куча д****в, которых интересует деньги и больше ничего:
https://dixken.de/blog/i-found-a-vulnerability-they-found-a-lawyer - I found a Vulnerability. They found a Lawyer
У челов утекли все данные, потому что у них был один пароль на всех, и к каким выводам они пришли? Что нужно подать в суд на чела, который этот факт обнаружил.

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

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

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

Не то чтобы мне «было удобно» – я тогда ничего не хостил. Сейчас я хочу быть уверенным. Уверенность придёт только после чтения манов. А маны системд это боль (извиняюсь за ссылку, ну правда, не копи-пастить же). И по твоему красочному выражению, я говна в системд манах поем больше чем получу преимуществ. Поэтому выберу альтернативы и скрипты.

Так, держу в курсе. Выбираю меньшее из зол, благо выбор очевиден.

PS.

Да, и спасибо за прояснение! (я конечно проконсультировался у ИИ перед постом, но получить коммент специалиста всегда лучше)

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

Между чтением манов и изучением очередного «несложного» башетворения, вроде

awk '
    /\.PP/ {pp_line = NR; next}
    NR==pp_line+1 && /^[[:space:]]*\\fI.*=\\fR.*([,[:space:]]*\\fI.*=\\fR.*)*$/ {
        split($0, parts, ",")
        for (i in parts) {
            if (parts[i] ~ /\\fI.*=\\fR.*/) {
                gsub(/\\fI|=\\fR.*|[[:space:]]*/, "", parts[i])
                print parts[i]
            }
        }
    }
    pp_line = 0
' cm >> all_kw.txt

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

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

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

А если нужно слепить что-то временное-одноразовое, только чтобы ткнуть ликсиса в его ошибку, то конечно, «башеговно» – это супер клей, и вообще, наше всё!

Ноуп, родные раннеры на GitLab и GitHub прежде всего сделаны на microVM, и потом уже внутри них можно запустить контейнера при желании.

И что, это отменяет популярность использования контейнеризации в CI пайплайнах? DevOps-у главное контейнеризация, а SecOps-ы уже могут выбирать изоляцию в виде доп виртуалок и т.п.

В Кубике просто выбираешь CRI совместимый рантайм, а что там под капотом - Kata, gVisor или Firecracker или просто containerd - это уже дело десятое, работает оно почти одинаково, потому что унифицировано через CRI.

Речь о том, что именно с контейнерами (в доп. виртуалках или нет) мы получаем максимальный профит от GitLab, Jenkins, Woodpecker, etc. Толку от твоих виртуалок без контейнеров немного, ибо удобный деплой (и деплой инструментов во время сборки тоже) таки идёт через контейнеры.

А кто будет journald реализовывать? Тебе обязательно нужен логер к докеру — а в systemd уже есть systemd-journald. В том и прикол: systemd — это законченная система локальной оркестрации. А докер — это просто один молоток.

В том то и прикол, почему многим не нравится комбайн systemd, всего по немножку и абы как, а если норм. логирование - нужен внешний сервис через vector.dev

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

Можно поподробнее?

Я напоминаю, что контейнера — это linux-only решение, потому какая нафик портируемость?

Между дистрами и их версиями очевидно?

Этого по твоему мало?! Это был прорыв (в хорошем смысле) в индустрии.

А вот портируемость — нет, контейнера не портируемы. Даже на ARM той же версии линя ты x86 контейнера не запустишь.

Я не упоминал портируемость между разными архитектурами.

OpenRC не решает вопросов сложной оркестрации,

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

это просто инструмент чуть более продвинутее баша.

Ну бред же? Это инит система со своим вариантом юнитов с синтаксисом расширения и настройки на bash, которые можно посмотреть в Alpine Linux.

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

Чаще всего в качестве основы для контейнеров.

Но теперь это ещё и идеальная база для хоста без systemd, с ZFS на борту:

https://github.com/psy0rz/alpinebox

Лучшее, что можно найти для ноды Кубика на обычном линупс дистре, если не устраивает Sidero Talos.

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

Изоляция внешних кэшей?

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

Разве это плохо?

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

Так я не утверждаю, что Docker - это образцовый эталон изоляции процессов, но уж точно, не хуже systemd. Впрочем как и виртуалки x86/amd64, escape from vm - нет не слышали?

Вопрос в 2026 не актуален, поскольку рынок труда завален сеньорами, ищущими работу.

Поэтому они за 2 месяца тебе напишут намного более лучшую альтернативу K8s со всем CNCF стеком в придачу?

Может быть я не совсем понятно выразился, но Ansible+systemd — это не совсем «самодельные велосипеды», хотя определённая доля ручной работы есть. Но в кубернетесе доля ручной работы выше, по крайней мере если цель — получить на k8s high availability, а не отвалиться с первым хостом, как это может произойти в топорном варианте с Ansible+systemd (хотя не факт, опять же, как настроишь).

С чего бы вдруг? Можно пруфы?

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

Разве Кубик такого не умеет?

Managed K8s хорош если кто-то за вас уже сделал типовую конфигурацию от и до, весь софт запакетирован в контейнера и всё это ставится через Helm — то есть, ты используешь не k8s, а готовую конфигурацию, для запуска которой нужен k8s.

А для не managed K8s разве это плохо? :)

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

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

Предлагаешь Heroku like Kubero или его Docker аналоги типа Coolify?

По этой причине и по указанной выше проблеме с конфигурацией PV пользователи managed k8s часто предпочитают облачные БД вместо собственных БД на managed k8s.

Которые и сами построены на Кубике? Использование Managed - это компенсация нехватки экспертизы и компетенций у клиентов. Причём тут Кубик?

А если у тебя по итогу сплошные stateless сервисы в кубере, то там уже и не ясна ценность широких возможностей кубера по конфигурации кластера.

Так ведь удобный деплой, HA, автоматические DNS имена сервисов и 100500 других плюсов из CNCF.

Ну я же написал «есть и такие извращенцы». Это я про Strimzi Kafka. Там поесть говна можно больше, чем получить преимуществ — но зато «клауд натив».

А вот если бы ставить через Ansible на bare-metal! LOL

В Кубике просто выбираешь CRI совместимый рантайм, а что там под капотом - Kata, gVisor или Firecracker или просто containerd - это уже дело десятое, работает оно почти одинаково, потому что унифицировано через CRI.

Проектирование системы под cloud-native подразумевает радикальную смену архитектуры, способов мониторинга и отладки. Очень сложно существующую систему перенести на докер, а уж способ запуска готовых контейнеров как-нибудь можно придумать, с кубернетом или без (ХЗ вообще зачем ты кубер тут упомянул).

Речь о том, что именно с контейнерами (в доп. виртуалках или нет) мы получаем максимальный профит от GitLab, Jenkins, Woodpecker, etc.

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

Ну типа разница между монтированием каталога проекта в контейнер с node:20 и установкой этой ноды 20 в систему на постоянной основе минимальна.

В том то и прикол, почему многим не нравится комбайн systemd, всего по немножку и абы как, а если норм. логирование - нужен внешний сервис через vector.dev

То, что кому-то нужен экскаватор, не значит, что лопаты уже стали бесполезными.

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

Можно поподробнее?

ВСЕ контейнера работают на хостовом ядре ОС и хостовом CPU. Контейнера вообще нифига не портируемые, и с чего бы им быть такими? Они независимы только от других установленных в систему прикладных сервисов, но от ядра ОС и от железа они зависимы как самые обычные программы, которые работают без контейнейров.

Если у тебя ядро не поддерживает IORING_OP_SETXATTR, а твой сервис делает операцию через него, то твой сервис не будет работать на этом ядре. А на моей текущей работе ВСЕ сервера не поддерживают IORING_OP_SETXATTR. И AVX2 на них тоже нету.

Этого по твоему мало?! Это был прорыв (в хорошем смысле) в индустрии.

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

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

Docker-like не решает такие проблемы. Кубер решает, докер сам по себе не решает. Из повторений с твоей стороны я вижу только что ты продолжаешь путать разные категории инструментов.

Но теперь это ещё и идеальная база для хоста без systemd, с ZFS на борту:
https://github.com/psy0rz/alpinebox

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

Изоляция внешних кэшей?

У Linux ядерная память является общим ресурсом, не принадлежащим никому. На самом деле чисто количественно в Linux намного больше типов ресурсов, не подлежащих строгому учёту, чем те, которые подлежат таковому. То есть все io mmap, hugepage, объекты ядра — это всё плохо учитываемые ресурсы. И это только ресурсы RAM — а есть CPU, на котором можно делать невыровненные атомарные операции, и только совсем недавно производители процов научились хоть как-то контролировать эту проблему.

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

Поэтому они за 2 месяца тебе напишут намного более лучшую альтернативу K8s со всем CNCF стеком в придачу?

Да. Внезапно. Я про BEAM.

С чего бы вдруг? Можно пруфы?

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

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

Разве Кубик такого не умеет?

Умеет, если БД cloud-native. Если нет, то получишь в десятый раз за день подвисший кластер, потому что координатору не понравились медленные ответы и он решил «оптимизировать» размещение. Миграция на самом деле сложна даже на cloud-native, потому что в отличие от stateless сервисов ты не может свой деплоймент вернуть на старый репликасет, «вход рубль — выход десять».

Managed K8s хорош если кто-то за вас уже сделал типовую конфигурацию от и до, весь софт запакетирован в контейнера и всё это ставится через Helm — то есть, ты используешь не k8s, а готовую конфигурацию, для запуска которой нужен k8s.

А для не managed K8s разве это плохо?

А для unmanaged k8s тебе нужно выполнять «упражнения» — и цена этих упражнений может не оправдываться решаемыми задачами.

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

Предлагаешь Heroku like Kubero или его Docker аналоги типа Coolify?

При чём тут они? Они не решают проблемы «у нас нет готового cloud native софта, и теперь мы должны сами адаптировать имеющийся».

По этой причине и по указанной выше проблеме с конфигурацией PV пользователи managed k8s часто предпочитают облачные БД вместо собственных БД на managed k8s.

Которые и сами построены на Кубике? Использование Managed - это компенсация нехватки экспертизы и компетенций у клиентов. Причём тут Кубик?

На масштабе Google, Amazon, Microsoft кубернетес-совместимые реализации оркестраторов перестают работать. В основе кубрнетеса заложены патологические решения, и у меня даже была теория, что это было сделано отчасти специально, но каких-то особенных доказательств я пока что не нашел. Так или иначе, бекенд у managed кубернетесов сделан не на кубернетесе.

Так ведь удобный деплой, HA, автоматические DNS имена сервисов и 100500 других плюсов из CNCF.

Казалось бы, при чём тут вообще кубернет? AWS даёт это же безо всяких контейнеров.

Ну я же написал «есть и такие извращенцы». Это я про Strimzi Kafka. Там поесть говна можно больше, чем получить преимуществ — но зато «клауд натив».

А вот если бы ставить через Ansible на bare-metal! LOL

Да, ставить на bare metal через ансибл — если хочешь хорошую железячную пропускную способность. А иначе зачем вам кафка?

Да, ставить на bare metal через ансибл — если хочешь хорошую железячную пропускную способность.

И велик выигрыш в пропускной способности по сравнению с контейнерами? Способность больше зависит от IO или от запуска в контейнере vs bare metal ?

А убытки от неудобства деплоя без контейнеров кто-то посчитал?

AWS даёт это же безо всяких контейнеров.

Ты про ECS? Без контейнеров? :)

Казалось бы, при чём тут вообще кубернет?

Предлагаешь завендорлочиться на AWS? Серьёзно? :)

Так или иначе, бекенд у managed кубернетесов сделан не на кубернетесе.

А на чём? :)

И уточни, про какого именно провайдера managed K8s ты пишешь?

Даже боюсь представить, сколько новых боргов рождено в недрах Yandex, MTS, Timeweb, Сбер, Selectel, etc.

А для unmanaged k8s тебе нужно выполнять «упражнения» — и цена этих упражнений может не оправдываться решаемыми задачами.

Talos, нет не слышали?

Если бы в k8s было всё так просто, то их конторы бы не существовало.

Ты забываешь уровень тех, с кем споришь.
На уровне трех клиентов или подкроватного сервера они правы, это не нужно. А вот если хайлоад, то уже ой, но в мире адептов локалхоста такого не бывает :)

При чём тут они? Они не решают проблемы «у нас нет готового cloud native софта, и теперь мы должны сами адаптировать имеющийся».

Но ведь такие App платформы пиарятся якобы более простым деплоем, чем классический GitLab/Jenkins + Flux?

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

А ещё ты про базу упоминал, так вот такие платформы предлагают PaaS сервисы из каропки.

Но в кубернетесе доля ручной работы выше, по крайней мере если цель — получить на k8s high availability, а не отвалиться с первым хостом,

Если бы в k8s было всё так просто, то их конторы бы не существовало.

Managed K8s так сложен? Yandex или Selectel multi AZ, - нет, как всегда не слышали, поэтому пилим свой «намного более простой» HA велосипед на Ansible + systemd, Yandex и Selectel вместе обзавидуются. :) (сарказм)

А вот если хайлоад, то уже ой,

Но Ansible + systemd же лучше и более HA? Ну!? :) (сарказм)