LINUX.ORG.RU
решено ФорумAdmin

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

 ,


0

0

если наличие/поведение юнитов всё так же зависит от опакечивателей?

Дисклеймер: этот тред не против systemd, а против маркетоидного бреда вместо перечисления реальных преимуществ/недостатков.

В общем, есть docker. В Debian/Ubuntu он ставится вместе с docker.socket-юнитом, так что даже при не запущенном докере он будет автоматически запущен при обращении к его сокету.

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

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

админу

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)

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

mord0d ★★★ ()

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

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

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

Deleted ()

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

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

anonymous ()

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

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

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 от этого безобразия.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

В центоси надо стартовать не 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 как только он вышел и потенциально нагрузить себя ручной правкой конфигов и стать бета-тестером (хотя до бета- хипсторские поделия обычно не дотягивают, их бросают в стадии пре-альфа и начинают пилить новое поделие) для новой хипсторской игрушки?

utf8nowhere ★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

alpha ★★★★★ ()