Какую универсальность добавила systemd

Никак. Это сделано не для удобства админов.

utf8nowhere отписался от темы

Подозрительно.

админу

хз как админу. [оффтоп] Но для продвинутого пользователя, коим является разработчик, есть преимущества. 'journalctl -f', например. Хоть это и опосредовано к systemd относится, а только результат систематизации логгирования.

А что касается примера с докером - то это неприятно, да.

А причём здесь systemd вообще? Если разработчик не написал юниты/скрипты для запуска своего софта в systemd/sysvinit соответственно, то это делает мейнтейнер, но если и мейнтейнеру это не надо, то это остаётся на пользователе. systemd, как и sysvinit, предоставляет лишь возможность автоматизации.

Ну и как тут systemd помог условному админу чувствовать себя одинаково в любом дистрибутиве?

А тебя волнует, там сокет-активация внутри или нет? systemctl enable docker и systemctl start docker работают совершенно одинаково вне зависимости от этого.

Какую универсальность добавила systemd
если наличие/поведение юнитов всё так же зависит от опакечивателей?

При достаточном желании саботировать можно что угодно. Просто что-то проще, а что-то сложнее.

может он всегда отписывается?

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

Пока от systemd встречал только проблемы, продолжаю наблюдать

На счет примера с докером, кстати, хорошим, стоит сказать о принципах организации демонов вообще.

Не разбирался с дебианом, но допускаю, что в нем принято для сетевых демонов делать <daemon>.socket, который запускает сервис при обращении к сокету. Есть там такое для других? Тогда в этом ничего такого нет, обычные плюшки дистрибутива

systemctl enable docker и systemctl start docker

systemctl enable --now docker. Не позорься.

все что делает docker.socket - это запускает лежащий рядом docker.service и пробрасывает туда нужный сокет. Что там, что там никто тебе не мешает работать с docker.service.

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

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

Это нормально, если персонаж просто вбросил и ушел.

Отсутствие docker.socket не означает, что нет его поддержки в systemd. Достаточно создать и получить то же, что в условном debian.

Универсальный интерфейс оно добавило. И это хорошо, все остальное плохо.

Речь про каждую из операций в отдельности. systemctl enable --now — это «синтаксический сахар».

В centos никакого docker.socket нет, docker.service нужно стартовать руками.

Я даже больше скажу. В центоси надо стартовать не docker.

https://www.projectatomic.io/blog/2018/02/reintroduction-podman/

Как выжить в такой ситуации админу, просто уму непостижимо. Постоянно приходится что-то читать.

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

Безопасность или баги вероятно.

https://bugzilla.redhat.com/show_bug.cgi?id=1457978

Since he now has docker socket activated the call to `docker version` in container-storage-setup [1] actually will try to activate docker. This is because `docker version` by default will try to report the version of both the client and the server. Since it tries to access the socket the systemd unit for the docker socket tries to start the docker-daemon, which will attempt to start but will wait forever because docker-storage-setup.service must complete first.

В общем все встали и пошли переползать на podman от этого безобразия.

В общем все встали и пошли переползать на podman от этого безобразия.

Манямирок то какой. Кто эти все? Сотрудники RH и фанбои?

Podman стал работать на freebsd? macos? windows? Даёт хоть какую-то кроссплатформенность?

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

Откуда знать-то, пробовал один раз (в 2016), пожалел.

Пользуйся OpenRC.

Для podman есть аналог docker-compose, в нем можно в 2 шага создать для своей закрытой сети (без выхода во внешний мир) registry?

podman - это запускалка контейнеров, или групп контейнеров (pod)

https://github.com/containers/libpod/issues/341

registry - это внешний отдельно стоящий сервис, в podman его нет и не должно быть

podman может тащить образ из любого registry. И в отличие от докера позволяет нормально сконфигурировать список registry с приоритетами и т.п. а не хардкодит везде свой dockerhub.

При этом podman и buildah могут работать вообще без каких-либо сервисов и registry: buildah собирает и складывает файлы образа например в хомяке пользователя. Podman оттуда их читает и запускает с ними контейнер.

Я даже больше скажу.

Не по делу стоит говорить меньше.

В центоси надо стартовать не docker.

Я вот смотрю в https://kubernetes.io/docs/setup/independent/#configure-cgroup-driver-used-by... и вижу:

When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet and set it in the /var/lib/kubelet/kubeadm-flags.env file during runtime.
If you are using a different CRI, you have to modify the file ...

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

Не по делу

А у тебя тут какой-то дело было? Я заметила только очередной бессмысленный наброс про systemd. Кто ж знал.

Если podman, buildah, skopeo так хороши, то почему они находятся только в репозитории Феди/Цента/Шапки?

Странный вопрос. В Fedora и systemd на 3-5 лет раньше чем к остальным пришел.

Базовая поддержка Debian/Ubuntu есть

https://github.com/containers/libpod/blob/master/install.md

Работы ведутся.

Пакетирование Go + системы конфигов под Debian Guidelines не простой и не быстрый процесс.

Для маководов тоже планируют обертку над виртуальной машиной делать.

Всё будет, чуть погодя.

Ок. Ты можешь писать сколько угодно по делу и не по делу.

Спасибо за инфо про podman.

Придётся запастись попкорном на ближайшие 2-5 года.

Впереди увлекательная битва Docker vs podman и Ko.

Ванную то, что всё хейтеры systemd забудут про него и накинутся на podman и Ко.

Ванную то, что всё хейтеры systemd забудут про него и накинутся на podman и Ко.

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

Потому что структурно и идейно podman, buildah и skopeo - это гораздо более unix-way и KISS и вот это всё, чем Docker CE.