урезанный Systemd в докере для CI

запрос на github: systemd docker container

там есть скриптец с примерно 1.3K звёзд, который имитирует systemd в способности запускать его юниты.

спасибо

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

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

Положи буханку обратно на стол и сделай троллейбус из материалов, для этой задачи подходящих.

P. S.: ты уже спрашивал, ответ с тех пор не изменился.

Если нет необходимости использовать именно systemd, то: состояния enable/disable это ничто иное, как симлинк на юнит systemd в /etc/systemd/что-то-там-взависимости/от-уровня-запуска/и-дистрибутива Соответственно, Вам нужно проверить наличие симлинка. Ну а запущен или нет, проверьте, запущен ли процесс.

А что именно в CI тестируется? Запуск юнита?

Для ситуации когда в докере надо стартануть несколько демонов и на них прогнать тесты - я supervisord использовал.

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

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

И в целом podman лучше docker

ну началось.
85% документации и примеров это о докере.
с другой стороны podman - drop-in замена докеру.

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

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

Есть ли какой-то рабочий пример урезанной имплементации systemd в докере? Мне вот чисто для enable/disable/start и всё

Есть замена докеру, podman называется. Там и systemd, и не systemd работают из коробки. Но тебе похоже всё же нужен lxc/lxd или виртуалка, а не контейнер.

тебе просто интеллекта и навыков не хватает понять смысл CI, вот ты и тупишь

Ага, угу, пиши ещё, похохочем с твоего недостатка интеллекта для настройки CI с systemd)

зачем тащить ещё один инструмент в инструмент для запуска приложений, если нужна виртуальная ос запускай lxc

А зачем это делать в другое? Вот есть ci. Ну пусти ты её на KVM, не мучай бабушку.

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

В общем, подозреваю XY problem.

Все тесты, вообще всё итак бегает в докере, это стандарт.

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

Очевидно, что тупизна анонимуса, который не видел как CI поднимает качество софта, не является достаточной причиной.

ответил s-warus. Зрелось инструментария докера и абсолютная незрелость аналогичного инструментария вокруг виртуалок.

чем отличается докер контейнер от lxc контейнера (кроме более полной эмуляции os и более правильной работой с сетью, меня докер заколебал своим рукоблудием) не по ресурсам не по CI отличий не вижу

Окей.

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

Соответственно, никому в голову не приходит проверять, запустилось ли приложение в контейнере, потому что если экземпляр контейнера есть, то приложение запущено 100%.

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

Ты может и правильно говоришь, но

Ты наркоман

зачем грубить на ровном месте?
два чая не поставлю по этой причине

Увы, заразился токсичностью от некоторых пациентов этого форума)

Пример есть https://github.com/just-containers/s6-overlay

Но это не systemd.

Если все это запускается в докере, то зачем systemctl? Если в докер притаскивается «скрипт» который обычно запускается НЕ в докере, то это странно. Лучше это запускать в окружении как в проде, на виртуалке с полноценной ОС.

PS лучше вообще сделать все таки отдельный докер образ и там запускать flussonic как положено, и в проде разворачивать из кубера-композа все ;))

А просто если systemd запустить то чем не устраивает?

FROM ubuntu:22.04

RUN set -ex \
    && apt-get update && apt-get install -y --no-install-recommends \
       systemd less \
    && ln /bin/systemd /sbin/init

ENV PAGER less

STOPSIGNAL SIGRTMIN+3

ENTRYPOINT ["/sbin/init"]

docker build . -t systemd
docker run --rm -it --name systemd --hostname systemd -d \
       --tmpfs /run \
       --tmpfs /run/lock \
       -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
       systemd

docker exec -it systemd bash -l

root@systemd:/# systemd-run --unit test-backup --no-block --uid backup --gid backup \
    --on-calendar='*:*:10' --service-type=oneshot                                   \
    -p SyslogIdentifier=test-backup -p WorkingDirectory='~'                         \
    id

root@systemd:/# systemctl status test-backup 
○ test-backup.service - /usr/bin/id
     Loaded: loaded (/run/systemd/transient/test-backup.service; transient)
  Transient: yes
     Active: inactive (dead) since Tue 2024-02-06 11:35:13 UTC; 18s ago
TriggeredBy: ● test-backup.timer
    Process: 93 ExecStart=/usr/bin/id (code=exited, status=0/SUCCESS)
   Main PID: 93 (code=exited, status=0/SUCCESS)

Feb 06 11:35:13 systemd systemd[1]: Starting /usr/bin/id...
Feb 06 11:35:13 systemd test-backup[93]: uid=34(backup) gid=34(backup) groups=34(backup)
Feb 06 11:35:13 systemd systemd[1]: test-backup.service: Deactivated successfully.
Feb 06 11:35:13 systemd systemd[1]: Finished /usr/bin/id.

урезанной имплементации systemd

Как ты монолит урежешь? В виртуалке тестируй.

В Devuan 5 есть systemctl на Python. Что-то делает, что-то нет.

мне же не столько запустить, сколько просто проверить, что apt-get install отработал, все скрипты правильно прошли и софт в правильной последовательности запущен.

Виртуалка — понятно, но там сильно хуже все инструменты.

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

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

Больше похоже что кто-то делает костыль в существующем CI :)

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

Основная масса моих клиентов в принципе не сможет запустить докер контейнер в фоне, а вот с пакетом очень даже справляются и получают пользу.

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

https://github.com/gdraheim/docker-systemctl-replacement

Может, нужен просто chroot?

это мысль, спасибо.

Осталось научиться запускать init в chroot, LOL