systemd сервис для запуска контейнера docker с dhcpd (РЕШЕНО)

Anton8830	# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)
Темы: 23 Сообщения: 175 Участник с: 16 ноября 2013	Доброго дня. Прошу помощи у знающих товарищей по systemd. Задача настроить запуск и работу dhcpd, находящегося в контейнере docker через сервис systemd Сделано 1. Создан образ на основе archlinux/base с dhpcd и его конфигом внутри Dockerfife `FROM archlinux/base RUN echo "y" \| pacman -Sy dhcp COPY ./dhcpd.conf /etc EXPOSE 67 CMD ["/usr/sbin/dhcpd", "-f", "-4"]` `docker build -t dhcpd .` 2. Образ запущен в контейнере с именем dhcpd `docker run -d -p 67:67 --name dhcpd dhcpd docker ps ... be1ab5c28f70 dhcpd:latest "/usr/sbin/dhcpf -f ..." 17 hours ago Up 1 second 0.0.0.0:67->67/tcp dhcpd ps -ef \| grep dhcp ... root 1178 1161 9 09:25 ? 00:00:01 /usr/sbin/dhcpd -f -4` 3. Cоздан сервис /etc/systemd/system/docker_dhcpd.service `[Unit] Description=DHCP server in docker container Requires=docker.service Conflicts=dhcpd4.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/docker start dhcpd ExecStop=/usr/bin/docker stop dhcpd [Install] WantedBy=multi-user.target` 4. Сервис включен. Проблема Запуск и остановка сервиса делают то, что и планировалось, но при падении процесса dhcpd ничего не происходит, сервис остается запущенным. Предпринятые действия В сервисе изменил тип Type=forking - получил цикличный перезапуск сервиса... Т. е. при старте, запускается контейнер, процесс умирает и systemd считает, что сервис упал, запускает ExecStop, в результате контейнер останавливается. Вопрос Как правильно настроить сервис, чтобы он отслеживал процесс dhcpd?

# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)

Сообщения: 175

Участник с: 16 ноября 2013

Доброго дня.

Прошу помощи у знающих товарищей по systemd.

Задача
настроить запуск и работу dhcpd, находящегося в контейнере docker через сервис systemd

Сделано

1. Создан образ на основе archlinux/base с dhpcd и его конфигом внутри
Dockerfife

FROM archlinux/base
RUN echo "y" | pacman -Sy dhcp
COPY ./dhcpd.conf /etc
EXPOSE 67
CMD ["/usr/sbin/dhcpd", "-f", "-4"]

docker build -t dhcpd .

2. Образ запущен в контейнере с именем dhcpd

docker run -d -p 67:67 --name dhcpd dhcpd
docker ps
...
be1ab5c28f70    dhcpd:latest    "/usr/sbin/dhcpf -f ..."    17 hours ago    Up 1 second    0.0.0.0:67->67/tcp    dhcpd

ps -ef | grep dhcp
...
root    1178    1161    9    09:25    ?    00:00:01 /usr/sbin/dhcpd -f -4

3. Cоздан сервис
/etc/systemd/system/docker_dhcpd.service

[Unit]
Description=DHCP server in docker container
Requires=docker.service
Conflicts=dhcpd4.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/docker start dhcpd
ExecStop=/usr/bin/docker stop dhcpd

[Install]
WantedBy=multi-user.target

4. Сервис включен.

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

Предпринятые действия
В сервисе изменил тип Type=forking - получил цикличный перезапуск сервиса... Т. е. при старте, запускается контейнер, процесс умирает и systemd считает, что сервис упал, запускает ExecStop, в результате контейнер останавливается.

Вопрос
Как правильно настроить сервис, чтобы он отслеживал процесс dhcpd?

vs220	# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)
Темы: 25 Сообщения: 8482 Участник с: 16 августа 2009	Anton8830 Type=forking - получил цикличный перезапуск сервиса. PIDFile указывать не пробовали? что то вроде `[Service] Type=forking PIDFile=/run/dhcpcd-%I.pid` и рестарт при отсутствии процесса /run/dhcpcd-%I.pid `Restart=always` PIDFile=¶ Takes a path referring to the PID file of the service. Usage of this option is recommended for services where Type= is set to forking. The path specified typically points to a file below /run/. If a relative path is specified it is hence prefixed with /run/. The service manager will read the PID of the main process of the service from this file after start-up of the service. The service manager will not write to the file configured here, although it will remove the file after the service has shut down if it still exists. The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service. Из закладок https://habr.com/ru/company/southbridge/blog/255845/

vs220

# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)

Темы: 25

Сообщения: 8482

Участник с: 16 августа 2009

Anton8830
Type=forking - получил цикличный перезапуск сервиса.

PIDFile указывать не пробовали?
что то вроде

[Service]
Type=forking
PIDFile=/run/dhcpcd-%I.pid

и рестарт при отсутствии процесса /run/dhcpcd-%I.pid

Restart=always

PIDFile=¶
Takes a path referring to the PID file of the service. Usage of this option is recommended for services where Type= is set to forking. The path specified typically points to a file below /run/. If a relative path is specified it is hence prefixed with /run/. The service manager will read the PID of the main process of the service from this file after start-up of the service. The service manager will not write to the file configured here, although it will remove the file after the service has shut down if it still exists. The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service.

Из закладок
https://habr.com/ru/company/southbridge/blog/255845/

Anton8830	# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)
Темы: 23 Сообщения: 175 Участник с: 16 ноября 2013	vs220 PIDFile пробовал, но проблема в том, что он не создается. Принудительно его создавать тоже пробовал - не прокатило. Restart=always приводит к тому, что сервис запускается, через секунду останавливается, запускается снова, останавливается и так по кругу... Реальный PIDFile, насколько я понимаю, создается внутри контейнера...

Anton8830

# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)

Темы: 23

Сообщения: 175

Участник с: 16 ноября 2013

vs220 PIDFile пробовал, но проблема в том, что он не создается. Принудительно его создавать тоже пробовал - не прокатило.
Restart=always приводит к тому, что сервис запускается, через секунду останавливается, запускается снова, останавливается и так по кругу...

Реальный PIDFile, насколько я понимаю, создается внутри контейнера...

vs220	# 4 года, 9 месяцев назад
Темы: 25 Сообщения: 8482 Участник с: 16 августа 2009	Anton8830 что он не создается Ну его как бы процесс должен создавать, может как то с контейнером связано что системд его не видит Не имел дела с контейнерами посмотрите → Может при запуске в контейнере он находится не в /run а в /run контейнера `ls /run \| grep pid ls путь/run \| grep pid`

vs220

# 4 года, 9 месяцев назад

Темы: 25

Сообщения: 8482

Участник с: 16 августа 2009

Anton8830
что он не создается

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

ls /run | grep pid
ls путь/run | grep pid

Anton8830	# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)
Темы: 23 Сообщения: 175 Участник с: 16 ноября 2013	vs220 Эмм... Есть `/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/mody/be1ab5c28f70e78f57af90e84afd04b65f80e0359c2b15789092cb577e7ce1a9/init.pid` В нём реальный pid dhcpd. В таком подходе проблема следующая: при обновлении контейнера - этот путь изменится, тогда и сервис придётся переделывать...

Anton8830

# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)

Темы: 23

Сообщения: 175

Участник с: 16 ноября 2013

vs220 Эмм... Есть

/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/mody/be1ab5c28f70e78f57af90e84afd04b65f80e0359c2b15789092cb577e7ce1a9/init.pid

В нём реальный pid dhcpd.

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

vs220	# 4 года, 9 месяцев назад
Темы: 25 Сообщения: 8482 Участник с: 16 августа 2009	Anton8830 В таком подходе Может тогда менять подход, запускать системд в контейнере и его сервисом dhcpd или еще как Интересно а так не прокатит? /run/docker/containerd/daemon/*/init.pid

Anton8830	# 4 года, 9 месяцев назад
Темы: 23 Сообщения: 175 Участник с: 16 ноября 2013	vs220 Запускать systemd внутри контейнера, конечно, можно, но тогда весь смысл контейнера нивелируется... Образы получаются тяжелыми и бессмысленными. /run/docker/containerd/daemon/*/init.pid может и прокатит, но только когда контейнер один. А если добавить второй, например с bind? Тогда - уже нет...

Anton8830

# 4 года, 9 месяцев назад

Темы: 23

Сообщения: 175

Участник с: 16 ноября 2013

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

/run/docker/containerd/daemon/*/init.pid может и прокатит, но только когда контейнер один. А если добавить второй, например с bind? Тогда - уже нет...

vs220	# 4 года, 9 месяцев назад
Темы: 25 Сообщения: 8482 Участник с: 16 августа 2009	Anton8830 нет ¯ \ _ (..) _ / ¯ Может кто еще что подскажет Пойти другим путем? https://habr.com/ru/post/270165/

Anton8830	# 4 года, 9 месяцев назад
Темы: 23 Сообщения: 175 Участник с: 16 ноября 2013	vs220 Ну, docker вообще не совсем для ограничения прав (или совсем не для того). Он позволяет создать изолированную область, где работает нужное приложение, минимально зависимое от системы, позволяет не устанавливать в систему само приложение. Т. е. есть только базовая система и docker, а все остальное изолировано друг от друга в контейнерах. Не знаю, как ещё объяснить... Для меня dhcp и bind внутри контейнеров - просто для практики. Создать образ, запустить контейнер - у меня получилось. Теперь я пытаюсь сделать так, чтобы контейнеры запускались и процессы контролировались через systemd

Anton8830

# 4 года, 9 месяцев назад

Темы: 23

Сообщения: 175

Участник с: 16 ноября 2013

vs220 Ну, docker вообще не совсем для ограничения прав (или совсем не для того). Он позволяет создать изолированную область, где работает нужное приложение, минимально зависимое от системы, позволяет не устанавливать в систему само приложение. Т. е. есть только базовая система и docker, а все остальное изолировано друг от друга в контейнерах. Не знаю, как ещё объяснить...

Для меня dhcp и bind внутри контейнеров - просто для практики. Создать образ, запустить контейнер - у меня получилось. Теперь я пытаюсь сделать так, чтобы контейнеры запускались и процессы контролировались через systemd

vasek	# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)
Темы: 47 Сообщения: 11742 Участник с: 17 февраля 2013	Не работаю с docker (вещь, конечно, очень интересная), но насколько мне известно, в данной ситуации, когда важно состояние одной ключевой службы/процесса (точнее, работа зависит от одного процесса), то создают docker-контейнер таким образом, чтобы он падал (завершал работу) с падением (завершением работы) этого основного процесса. А далее, если это необходимо, простой перезапуск контейнера (что то типа --restart=always). Хотя все зависит от поставленной задачи - иногда проще создать отдельный docker контейнер dhcpd (тогда проще и перезапуск). PS - хотя встречались и статейки с описанием контроля за процессами внутри контейнера, запуска приложений ... и возможен даже просмотр логов. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 4 года, 9 месяцев назад (отредактировано 4 года, 9 месяцев назад)

Темы: 47

Сообщения: 11742

Участник с: 17 февраля 2013

Не работаю с docker (вещь, конечно, очень интересная), но насколько мне известно, в данной ситуации, когда важно состояние одной ключевой службы/процесса (точнее, работа зависит от одного процесса), то создают docker-контейнер таким образом, чтобы он падал (завершал работу) с падением (завершением работы) этого основного процесса. А далее, если это необходимо, простой перезапуск контейнера (что то типа --restart=always).
Хотя все зависит от поставленной задачи - иногда проще создать отдельный docker контейнер dhcpd (тогда проще и перезапуск).

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

Ошибки не исчезают с опытом - они просто умнеют