После завершения этого раздела вы сможете запустить и остановить контейнер как службу systemd, а также проверить его состояние.
systemd
Как правило, при развертывании служб (например, баз данных и веб-серверов) в виде контейнеров необходимо, чтобы эти контейнеры автоматически запускались вместе с сервером.
Создавая пользовательские файлы юнитов systemd для контейнеров без прав root, вы можете управлять ими с помощью команд systemctl аналогично обычным службам. Если включить эти службы, связанные контейнеры будут запускаться при запуске хост-машины. Если контейнер работает без прав root, можно управлять этими службами из учетной записи непривилегированного пользователя для повышения безопасности.
systemctl
Для более сложных операций масштабирования и оркестровки большого количества контейнеризованных приложений и служб можно использовать корпоративную платформу оркестровки на основе Kubernetes, например Red Hat OpenShift Container Platform.
Помимо системных служб, утилита systemd также может управлять пользовательскими службами. С пользовательскими службами systemd пользователи могут создавать файлы юнитов для собственных служб и управлять этими службами с помощью команд systemctl без прав root.
root
Если вы включаете (enable) пользовательскую службу от имени пользователя без прав root, эта служба запускается автоматически, когда вы открываете первый сеанс через текстовую или графическую консоль либо с помощью SSH. Служба останавливается при закрытии последнего сеанса. Это поведение отличается от поведения системных служб, которые запускаются при запуске системы и останавливаются при ее выключении.
Однако вы можете изменить это поведение по умолчанию, сделав так, чтобы включенные службы принудительно запускались вместе с сервером и останавливались во время выключения системы. Для этого используется команда loginctl enable-linger. Чтобы отменить операцию, используйте команду loginctl disable-linger. Чтобы посмотреть текущее состояние, используйте команду loginctl show-user имя пользователя, указав в качестве параметра свое имя пользователя.
loginctl enable-linger
loginctl disable-linger
loginctl show-user имя пользователя
имя пользователя
[user@host ~]$ loginctl enable-linger [user@host ~]$ loginctl show-user user ...output omitted... Linger=yes [user@host ~]$ loginctl disable-linger [user@host ~]$ loginctl show-user user ...output omitted... Linger=no
[user@host ~]$
loginctl show-user user
Linger=yes
Linger=no
Чтобы задать пользовательские службы systemd, создайте каталог ~/.config/systemd/user/ для хранения файлов юнитов. Синтаксис этих файлов такой же, как у системных файлов юнитов. Дополнительные сведения см. на man-страницах systemd.unit(5) и systemd.service(5).
~/.config/systemd/user/
systemd.unit
systemd.service
Для управления новыми пользовательскими службами используйте команду systemctl с опцией --user. Следующий пример отображает список файлов юнитов в каталоге ~/.config/systemd/user/, указывает утилите systemd принудительно перезагрузить свою конфигурацию, а затем включает и запускает пользовательскую службу myapp.
--user
myapp
[user@host ~]$ ls ~/.config/systemd/user/ myapp.service [user@host ~]$ systemctl --user daemon-reload [user@host ~]$ systemctl --user enable myapp.service [user@host ~]$ systemctl --user start myapp.service
ls ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable myapp.service
systemctl --user start myapp.service
Для использования команд systemctl --user необходимо выполнить вход на консоли или напрямую через SSH. Команды sudo и su в этом случае не работают.
systemctl --user
sudo
su
Команда systemctl взаимодействует с пользовательским процессом systemd --user. Система запускает этот процесс только при первом входе пользователя через консоль или с помощью SSH.
systemd --user
В следующей таблице показаны различия между системными и пользовательскими службами systemd.
Таблица 13.2. Сравнение системных и пользовательских служб
/etc/systemd/system/unit.service
unit
~/.config/systemd/user/unit.service
# systemctl daemon-reload
#
systemctl daemon-reload
$ systemctl --user daemon-reload
$
# systemctl start UNIT # systemctl stop UNIT
systemctl start UNIT
UNIT
systemctl stop UNIT
$ systemctl --user start UNIT $ systemctl --user stop UNIT
systemctl --user start UNIT
systemctl --user stop UNIT
# systemctl enable UNIT
systemctl enable UNIT
$ loginctl enable-linger $ systemctl --user enable UNIT
systemctl --user enable UNIT
Если на одном хосте работает небольшое количество контейнеров, вы можете создать пользовательские файлы юнитов systemd и настроить их на автоматический запуск контейнеров вместе с сервером. Это простой подход, используемый в основном для очень простых и небольших развертываний, которые не нужно масштабировать. Для более практичных производственных установок рекомендуется использовать платформу Red Hat OpenShift Container Platform, которая упоминается в конце этого раздела.
Чтобы упростить управление контейнерами без прав root, можно создать специальную учетную запись пользователя для всех контейнеров. Так вы сможете управлять контейнерами из одной учетной записи.
Учетная запись, создаваемая для группировки всех контейнеров, должна быть учетной записью обычного пользователя. Когда вы создаете учетную запись с помощью команды useradd, команда резервирует диапазон пользовательских идентификаторов для контейнеров пользователя в файле /etc/subuid. Однако, когда вы создаете системную учетную запись с помощью опции --system (или -r) команды useradd, команда не резервирует диапазон. Как следствие, вы не можете запускать контейнеры без прав root, используя системные учетные записи.
useradd
/etc/subuid
--system
-r
Команда podman может создать файл юнита systemd из существующего контейнера. В следующем примере с помощью команды podman generate systemd создается файл юнита для существующего контейнера web:
podman
podman generate systemd
web
[user@host ~]$ cd ~/.config/systemd/user/ [user@host user]$ podman generate systemd --name web --files --new /home/user/.config/systemd/user/container-web.service
cd ~/.config/systemd/user/
[user@host user]$
podman generate systemd --name web --files --new
Команда podman generate systemd использует контейнер в качестве модели для создания файла конфигурации. После создания файла необходимо удалить контейнер, так как systemd ожидает, что контейнер изначально не существует.
Команда podman generate systemd принимает следующие опции:
--name container_name
container_name
Опция --name указывает имя существующего контейнера, который должен использоваться в качестве модели для создания файла юнита. Podman также использует это имя для формирования имени файла юнита: container-container_name.service.
--name
container-container_name.service
--files
Опция --files указывает утилите Podman создать файл юнита в текущем каталоге. Без этой опции утилита Podman отображает файл в стандартном потоке вывода.
--new
Опция --new указывает утилите Podman настроить службу systemd на создание контейнера при запуске службы и его удаление при остановке службы. В этом режиме контейнер является временным, а для сохранения данных обычно требуется постоянное хранилище. Без опции --new утилита Podman настраивает службу на запуск и остановку существующего контейнера без его удаления.
В следующем примере показаны директивы запуска (start) и остановки (stop) в файле юнита при выполнении команды podman generate systemd с опцией --new:
[user@host ~]$ podman run -d --name web -v /home/user/www:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105 [user@host ~]$ podman generate systemd --name web --new ...output omitted... ExecStart=/usr/bin/podman run --conmon-pidfile %t/%n-pid --cidfile %t/%n-cid --cgroups=no-conmon -d --name web -v /home/user/webcontent:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105 ExecStop=/usr/bin/podman stop --ignore --cidfile %t/%n-cid -t 10 ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/%n-cid ...output omitted...
podman run -d --name web -v /home/user/www:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105
podman generate systemd --name web --new
ExecStart
podman run
ExecStop
podman stop
ExecStopPost
podman rm
С директивой start утилита systemd выполняет команду podman run, чтобы создать и запустить новый контейнер.
С директивой stop утилита systemd выполняет команду podman stop, чтобы остановить контейнер.
После остановки контейнера утилита systemd удаляет его с помощью команды podman rm.
Для сравнения в следующем примере показаны директивы запуска (start) и остановки (stop) при выполнении команды podman generate systemd без опции --new:
[user@host ~]$ podman run -d --name web -v /home/user/www:/var/www:Z registry.redhat.io/rhel8/httpd-24:1-105 [user@host ~]$ podman generate systemd --name web ...output omitted... ExecStart=/usr/bin/podman start web ExecStop=/usr/bin/podman stop -t 10 web ...output omitted...
podman generate systemd --name web
podman start
С директивой start утилита systemd выполняет команду podman start, чтобы запустить существующий контейнер.
С директивой stop утилита systemd выполняет команду podman stop, чтобы остановить контейнер. Обратите внимание, что systemd не удаляет контейнер.
Используйте команду systemctl для управления контейнерами.
Запуск контейнера:
[user@host ~]$ systemctl --user start container-web
systemctl --user start container-web
Остановка контейнера:
[user@host ~]$ systemctl --user stop container-web
systemctl --user stop container-web
Получение состояния контейнера:
[user@host ~]$ systemctl --user status container-web
systemctl --user status container-web
Контейнеры, которыми вы управляете с помощью команды systemctl, контролируются утилитой systemd. Утилита systemd отслеживает состояние контейнеров и перезапускает их при сбое.
Не используйте команду podman для запуска и остановки этих контейнеров. Это может помешать осуществлению мониторинга утилитой systemd.
По умолчанию включенные пользовательские службы systemd запускаются, когда пользователь открывает первый сеанс, и останавливаются, когда пользователь закрывает последний сеанс. Чтобы пользовательские службы автоматически запускались с сервером, выполните команду loginctl enable-linger.
[user@host ~]$ loginctl enable-linger
Чтобы включить запуск контейнера при запуске хост-машины, используйте команду systemctl.
[user@host ~]$ systemctl --user enable container-web
systemctl --user enable container-web
Чтобы отключить запуск контейнера при запуске хост-машины, используйте команду systemctl с опцией disable.
disable
[user@host ~]$ systemctl --user disable container-web
systemctl --user disable container-web
Контейнерами, которые необходимо запускать с правами root, также можно управлять с помощью файлов юнитов systemd. Одно из преимуществ такого подхода заключается в том, что вы можете настроить эти файлы юнитов, чтобы они работали как обычные системные файлы юнитов, а не от имени конкретного пользователя.
Процедура настройки этих файлов аналогична той, которая использовалась ранее для контейнеров без прав root, со следующими исключениями:
Нет необходимости настраивать специального пользователя.
Создавать файл юнита с помощью команды podman generate systemd необходимо в каталоге /etc/systemd/system, а не в каталоге ~/.config/systemd/user.
/etc/systemd/system
~/.config/systemd/user
При настройке службы контейнера с помощью команды systemctl использовать опцию --user не нужно.
Не нужно выполнять команду loginctl enable-linger от имени пользователя root.
Демонстрация данной процедуры доступна в видео на YouTube-канале Red Hat Videos, указанном в справочных материалах в конце этого раздела.
В этой главе вы узнали, как вручную настроить контейнеры и управлять ими из командной строки на одном хосте, а также как настроить утилиту Systemd на автоматический запуск контейнеров вместе с сервером. Такой подход можно использовать в системах с небольшим количеством контейнеров, а также для изучения методов работы с контейнерами.
Однако на практике для большинства корпоративных развертываний требуется более эффективное решение. В начале этой главы мы упоминали о том, что для управления сложными приложениями, которые состоят из нескольких контейнеров, взаимодействующих друг с другом, обычно используется Kubernetes. Red Hat OpenShift ― это платформа Kubernetes, которая добавляет такие возможности, как пользовательский веб-интерфейс, мониторинг, запуск контейнеров в любом месте кластера хостов контейнеров, автоматическое масштабирование, ведение журнала и аудит, а также многие другие.
Эти возможности не рассматриваются в данном курсе. Если вы хотите узнать больше, Red Hat Training предлагает другие курсы, в числе которых бесплатный курс технического обзора Deploying Containerized Applications (DO080) и курс Red Hat OpenShift I: Containers & Kubernetes (DO180). Дополнительные сведения см. на сайте https://www.redhat.com/training.
Вы также можете узнать больше о Kubernetes и Red Hat OpenShift на сайте https://www.openshift.com. Там доступны различные ресурсы, а также предоставляется возможность опробовать OpenShift с помощью таких инструментов, как Контейнеры CodeReady. Дополнительные сведения см. на странице https://www.openshift.com/try.
Man-страницы loginctl(1), systemd.unit(5), systemd.service(5), subuid(5) и podman-generate-systemd(1)
loginctl
subuid
podman-generate-systemd
Улучшенная интеграция systemd с Podman 2.0
Управление контейнерами в Podman с помощью файлов юнитов systemd
Что такое OpenShift
Знакомство с OpenShift
Дополнительные сведения см. в главе Running Containers as Systemd Services with Podman руководства Red Hat Enterprise Linux 8 Building, Running, and Managing Containers: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/building_running_and_managing_containers/index#using-systemd-with-containers_building-running-and-managing-containers