Роль Ansible для службы systemd

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

Роль включает в себя следующие задачи:

1. Создание файла службы systemd в /etc/systemd/system/ с указанным именем service_name.service для каждого элемента systemd_service.
2. Настройка важных параметров секций Unit, Service и Install.
3. Уведомление systemd о том, что новые файлы службы существуют. Перезапуск службы.
4. Включение автостарта службы при загрузке, если это необходимо.

Требования

Эта роль требует прав root, поэтому либо запустите её в плейбуке с глобальным параметром become: yes, либо вызовите роль в вашем плейбуке следующим образом:

- hosts: apps
  roles:
    - role: systemd_service
      become: yes

Переменные роли

Все необходимые службы могут быть указаны с помощью переменной словаря systemd_service (см. defaults/main.yml):

systemd_service: {}

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

systemd_service:
  service:
    service_name:
    enabled:

Все остальные доступные параметры, которые должны быть указаны для конкретного ключа service_name (как вложенные параметры), перечислены ниже.

Параметры секции Unit

Эта группа параметров включает общую информацию о юните.

description:   # Произвольная строка, описывающая юнит

Следующие два параметра настраивают зависимости на другие юниты. Если служба активируется, указанные там юниты также будут активированы. Если один из юнитов из requires не может быть запущен или внезапно завершится, служба также будет остановлена. Что касается списка wants, служба не будет остановлена, если какой-либо юнит из него деактивируется. Параметры могут состоять из нескольких имен юнитов, разделенных пробелами. Их также можно указывать несколько раз.

requires:   # Юниты, которые должны быть запущены вместе со службой
wants:      # Юниты, которые должны быть запущены вместе со службой

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

after:   # Юниты, которые должны быть запущены после службы
before:  # Юниты, которые должны быть запущены до службы

Параметры секции Service

Эта секция включает информацию о службе и процессе, который она контролирует. Параметр type настраивает тип запуска процесса для этого юнит файла службы.

type:

Он может принимать следующие значения:

• simple - предполагает, что служба будет запущена немедленно. Процесс не должен разветвляться. Не используйте этот тип, если другие службы зависят от запуска данной службы. Если служба предоставляет функциональность другим процессам в системе, каналы связи должны быть установлены перед запуском демона.
• forking - предполагает, что служба запускается один раз, и процесс разветвляется по завершении родительского процесса. Этот тип используется для запуска классических демонов. Если используется этот режим, рекомендуется также использовать параметр pid_file (см. ниже), чтобы systemd мог идентифицировать главный процесс демона.

Другие значения ведут себя похоже на simple. Однако они имеют некоторые отличия:

• oneshot - ожидается, что служба завершит работу до того, как systemd запустит последующие юниты;
• dbus - предполагается, что демон получает имя в шине D-Bus;
• notify - демон отправляет уведомление через sd_notify(3) или аналогичный вызов, когда он завершил запуск;
• idle - фактическое выполнение бинарного файла службы откладывается до тех пор, пока все активные задания не будут обработаны. Обратите внимание, что этот тип полезен только для улучшения вывода в консоль; он не полезен в качестве инструмента для общего упорядочивания юнитов.

Установите путь к PID файлу, чтобы использовать тип запуска forking.

pid_file:    # Абсолютное имя файла указывающее на PID файл этого демона

Вы можете указать UNIX пользователя и группу, от имени которых должна выполняться служба. Параметры принимают одно имя пользователя или группы, или числовой идентификатор в качестве значения. Для системных служб и пользовательских служб root пользователя значение по умолчанию - root, которое может быть изменено на другое. Для пользовательских служб любого другого пользователя переключение идентичности пользователя не допускается. Таким образом, единственное допустимое значение - это тот же пользователь, от имени которого работает менеджер пользовательских служб. Если группа не задана, используется группа пользователя по умолчанию.

user:
group:

Установите приоритет планирования для юнита с помощью следующего параметра. Он принимает целое число от -20 (самый высокий приоритет) до 19 (самый низкий приоритет).

nice:    # Уровень приоритета для службы

Уровень настройки для Операции с памятью (OOM) для процесса указывается следующим параметром. Он принимает целое значение от -1000 (выключить OOM killer) до 1000 (OOM killing предпочтительнее).

oom_score_adjust:

Следующие параметры позволяют вам указать команды, которые будут выполняться в зависимости от состояния вашей службы. Параметры могут использоваться несколько раз или их значения могут включать несколько команд. Несколько строк команд могут быть объединены в одной директиве, разделив их точкой с запятой. Команда для выполнения должна иметь абсолютный путь. Она может содержать пробелы, но управляющие символы недопустимы. Для каждой команды первый аргумент должен быть абсолютным путем к исполняемому файлу. Пустая строка сбросит список ранее заданных команд для параметра.

# Команды, которые выполняются при запуске этой службы
# Если `type` не равен `oneshot`, здесь должно быть задано ровно одна команда
exec_start:

# Команды, которые выполняются перед командами `exec_start`
exec_start_pre:

# Команды, которые выполняются после команд `exec_start`
exec_start_post:

# Команды, которые выполняются для остановки службы, запущенной через `exec_start`
exec_stop:

# Команды, которые выполняются после остановки службы
exec_stop_post:

# Команды, которые выполняются для вызова перезагрузки конфигурации в службе
exec_reload:

Укажите, должна ли служба перезапускаться, когда процесс службы (основной процесс службы или один из процессов, указанных параметрами 'exec_start_pre', 'exec_start_post', 'exec_stop', 'exec_stop_post' или 'exec_reload') завершает работу, убивается или превышает лимит времени. Параметр restart принимает одно из следующих значений:

• no (по умолчанию) - служба не будет перезапущена;
• on-success - служба будет перезапущена только тогда, когда процесс службы завершится корректно (с кодом выхода 0 или одним из сигналов SIGHUP, SIGINT, SIGTERM или SIGPIPE);
• on-failure - служба будет перезапущена, когда процесс завершается с ненулевым кодом выхода, был завершен сигналом, когда операция превышает лимит времени, и когда срабатывает установленный таймаут наблюдателя;
• on-abnormal - служба будет перезапущена, когда процесс завершен сигналом, когда операция превышает лимит времени или когда срабатывает таймаут наблюдателя;
• on-watchdog - служба будет перезапущена только если процесс службы завершается из-за неконтролируемого сигнала, который не указан как статус чистого завершения;
• on-abort - служба будет перезапущена только если таймаут наблюдателя для службы истекает;
• always - служба будет перезапущена в любом случае.

# Когда служба должна быть перезапущена
restart:

Вы можете указать время задержки для вышеуказанных команд с помощью следующих параметров. Они принимают значение в секундах или значение диапазона времени, например, '5min 20s'. Параметр restart_sec настраивает время ожидания перед перезапуском службы (как настроено с помощью restart). Параметр timeout_sec определяет время, отведенное на обработку команд запуска/остановки.

restart_sec:
timeout_sec:

Используйте параметр environment, чтобы установить список переменных окружения для выполняемых процессов. Он включает словарь переменных и их значений. Если какое-то значение содержит пробел, используйте двойные кавычки для присвоения.

Вы также можете прочитать переменные окружения из текстового файла. Для этого установите значение параметра environment_file как путь к файлу.

environment:       # Словарь с ENV переменными
environment_file:  # Путь к файлу с переменными окружения

Рабочий каталог задается следующим параметром. Он устанавливается как текущий перед запуском команд.

working_directory:

Следующие параметры позволяют выбрать, куда должны направляться файловые дескрипторы (STDIN, STDOUT, STDERR) выполняемых процессов. Параметр standard_input принимает значения "null", "tty", "tty-force", "tty-fail", "socket" или "fd". Параметр standard_output может быть равен "inherit", "null", "tty", "journal", "syslog", "kmsg", "journal+console", "syslog+console", "kmsg+console", "socket" или "fd". Доступные значения standard_error аналогичны standard_output.

standard_input:
standard_output:
standard_error:

Если для любого из параметров "standard_*" указано "tty", "tty-force" или "tty-fail", то вы можете указать путь к tty.

tty_path:

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

state:

Она может принимать значения: restarted (по умолчанию) reloaded started stopped

Параметры секции Install

Эти переменные несут информацию об установке для юнита. Следующие два параметра могут использоваться несколько раз, или могут быть указаны списки имен юнитов, разделенных пробелами. Списки включают юниты, которые ссылаются на эту службу из своих полей requires и wants.

wanted_by:
required_by:

Зависимости

Нет

Пример плейбука

- hosts: app
  roles:
    - role: systemd_service
       systemd_service:
        # Имя службы по умолчанию
        railsapp:
          # Имя службы
          service_name: railsapp
          # Автоматически запускать службу при загрузке
          enabled: Yes
          # Выполнять команду с указанными аргументами при запуске службы
          exec_start: "/bin/bash -lc 'puma -C config/puma.rb'"
          # Использовать указанную директорию как текущую
          working_directory: "/var/www/myapp"
          # Указать переменную окружения
          environment: {ENVVAR: value}
          # Выполнять процессы от имени этого пользователя и группы
          user: "deploy"
          group: "deploy"
          # Перезапускать службу только в случае неудачного завершения
          restart: "on-failure"
          # Попробовать активировать 'redis', если это возможно
          wants: "redis.service"
          # Активировать 'postgresql' или остановить работу в случае неудачи
          requires: "postgresql.service"
          # юнит multi-user.target предпочитает, чтобы служба была запущена
          wanted_by: "multi-user.target"

Лицензия

Лицензия MIT License.