systemd

Роль Ansible :vertical_traffic_light: Systemd

GitHub release (latest by date)

Содержание

Поддерживаемые платформы
Требования
Переменные роли
Зависимости
Пример плейбука
Лицензия
Информация об авторе

Роль Ansible, которая устанавливает и настраивает Systemd единицы: системные компоненты и службы, управляемые менеджером систем/служб systemd в Linux.

Поддерживаемые платформы:

* Debian
* Redhat(CentOS/Fedora)
* Ubuntu

Требования

systemd обычно считается основным инструментом управления службами для дистрибутивов Linux и должен быть включен в большинство установок ОС. Хотя обычно это не является проблемой, стоит отметить, что ядро Linux >= 3.13 требуется для systemd, а ядро Linux >= 4.2 необходимо для поддержки унифицированной иерархии cgroup.

Смотрите README systemd для получения дополнительных деталей.

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

Переменные доступны и организованы в соответствии со следующими этапами развертывания программного обеспечения и машин:

установка
настройка
запуск

Установка

[unit_config: <config-list-entry>:] path: (по умолчанию: <строка> /etc/systemd/system)

загрузить путь к конфигурации единицы systemd.

В дополнение к /etc/systemd/system (по умолчанию), конфигурации единиц и соответствующие подкаталоги с переопределениями для системных служб могут быть размещены в /usr/lib/systemd/system или /run/systemd/system.

Файлы в /etc имеют приоритет над теми, что в /run, которые, в свою очередь, имеют приоритет над теми в /usr/lib. Переопределяющие файлы под любым из этих каталогов имеют приоритет над файлами единиц, независимо от их местоположения. Несколько файлов переопределения с разными именами применяются в лексикографическом порядке, независимо от любого из каталогов, в которых они находятся. Смотрите таблицу ниже и обратитесь к systemd(1) для получения дополнительных деталей о приоритете загрузки пути.

Пути загрузки при запуске в системном режиме (--system)

Путь файла загрузки единицы	Описание
/etc/systemd/system	Локальная конфигурация
/run/systemd/system	Временные единицы
/usr/local/lib/systemd/system	Единицы, установленные для локального администрирования системы
/usr/lib/systemd/system	Единицы установленных пакетов

Пути загрузки при запуске в пользовательском режиме (--user)

Путь файла загрузки единицы	Описание
$XDG_CONFIG_HOME/systemd/user или $HOME/.config/systemd/user	Конфигурация пользователя ($XDG_CONFIG_HOME используется, если установлен, в противном случае ~/.config)
/etc/systemd/user	Пользовательские единицы, созданные администратором
$XDG_RUNTIME_DIR/systemd/user	Временные единицы (используется только при установке $XDG_RUNTIME_DIR)
/run/systemd/user	Временные единицы
$dir/systemd/user для каждого $dir в $XDG_DATA_DIRS	Дополнительные места для установленных пользовательских единиц, одно для каждой записи в $XDG_DATA_DIRS
/usr/local/lib/systemd/user	Пользовательские единицы, установленные для локального администрирования системы
/usr/lib/systemd/user	Пользовательские единицы, установленные пакетным менеджером дистрибутива

Пример

 unit_config:
   - name: apache
     path: /run/systemd/system
     Service:
       ExecStart: /usr/sbin/httpd
       ExecReload: /usr/sbin/httpd $OPTIONS -k graceful
     Install:
       WantedBy: multi-user.target

[unit_config: <config-list-entry>:] type: <строка> (по умолчанию: service)

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

Пример

 unit_config:
   - name: apache
     type: socket
     Socket:
       ListenStream: 0.0.0.0:8080
       Accept: yes
     Install:
       WantedBy: sockets.target

Настройка

Настройка единицы systemd объявляется в конфигурационном файле в стиле ini. Конфигурация единицы INI для systemd состоит из разделов: 2 общих для всех типов единиц (Unit и Install) и 1 специфичного для каждого типа единицы. Эти конфигурации единиц могут быть выражены внутри переменной хэш unit_config роли в виде списков словарей, содержащих пары ключ-значение, представляющие имя, тип, загрузочный путь единицы и комбинацию вышеупомянутых определений разделов.

Каждое определение раздела конфигурации предоставляет словарь, содержащий набор пар ключ-значение для соответствующих опций раздела (например, спецификация ExecStart для раздела системы или веб-службы [Service] или опция ListenStream для веб-раздела [Socket]).

[unit_config: <list-entry>:] Unit | <unit-type например Service, Socket, Device или Mount> | Install: <dict> (по умолчанию: {})

определение разделов для конфигурации единицы

Любая настройка/значение пары ключей, поддерживаемая соответствующей спецификацией типа единицы Systemd, должна быть выражена в каждой коллекции unit_config и правильно отображена в соответствующей конфигурации INI.

Следующее предоставляет обзор и пример конфигурации каждого типа единицы для справки.

[Service]

Управляет демонами и процессами, из которых они состоят.

Пример

 unit_config:
   # path: /etc/systemd/system/example-service.service
   - name: example-service
     Unit:
       Description: Спящий сервис
     Service:
       ExecStart: /usr/bin/sleep infinity
     Install:
       WantedBy: multi-user.target

[Socket]

Инкапсулирует локальные IPC или сетевые сокеты в системе.

Пример

 unit_config:
   - name: docker
     type: socket
     Unit:
       Description: Слушает/принимает запросы на соединение на /var/run/docker/sock (неявно *Requires=* связанный docker.service)
     Socket:
       ListenStream: /var/run/docker.sock
       SocketMode: 0660
       SockerUser: root
       SocketGroup: docker
     Install:
       WantedBy: sockets.target

[Mount]

Управляет точками монтирования в системе.

Пример

 unit_config:
   - name: tmp_new
     type: mount
     Unit:
       Description: Новая временная директория (/tmp_new)
       Conflicts: umount.target
       Before: local-fs.target umount.target
       After: swap.target
     Mount:
       What: tmpfs
       Where: /tmp_new
       Type: tmpfs
       Options: mode=1777,strictatime,nosuid,nodev

[Automount]

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

Пример

 unit_config:
   - name: proc-sys-fs-binfmt_misc
     type: automount
     Unit:
       Description: Точка автоматического монтирования для произвольных исполняемых файловых форматов
       Documentation: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
       ConditionPathExists: /proc/sys/fs/binfmt_misc/
       ConditionPathIsReadWrite: /proc/sys/
     Automount:
       Where: /proc/sys/fs/binfmt_misc

[Device]

Предоставляет доступ к устройствам ядра и реализует активацию на основе устройств.

Этот тип единицы не имеет конкретных опций, и, следовательно, отдельный раздел [Device] не существует. Общие конфигурационные элементы настраиваются в общих [Unit] и [Install] разделах. systemd динамически создаст единицы устройств для всех устройств ядра, отмеченных тегом "systemd" udev (по умолчанию все блочные и сетевые устройства, а также некоторые другие). Чтобы пометить устройство udev, используйте TAG+="systemd в файле правил udev. Также имейте в виду, что единицы устройств именуются по путям /sys и /dev, которые они контролируют.

Пример

# /usr/lib/udev/rules.d/10-nvidia.rules

SUBSYSTEM=="pci", ATTRS{vendor}=="0x12d2", ATTRS{class}=="0x030000", TAG+="systemd", ENV{SYSTEMD_WANTS}="nvidia-fallback.service"

# Это приведет к автоматической генерации файла nvidia-fallback.device с соответствующими разделами [Unit] и [Install]

[Target]

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

Этот тип единицы не имеет конкретных опций, и, следовательно, отдельный раздел [Target] не существует. Общие конфигурационные элементы настраиваются в общих [Unit] и [Install] разделах.

Пример

 unit_config:
   - name: graphical
     path: /usr/lib/systemd/system/graphical.target
     type: target
     Unit:
       Description: Графический интерфейс
       Documentation: man:systemd.special(7)
       Requires: multi-user.target
       Wants: display-manager.service
       Conflicts: rescue.service rescue.target
       After: multi-user.target rescue.service rescue.target display-manager.service
       AllowIsolate: yes

[Timer]

Запускает активацию других единиц на основе таймеров.

Пример

 unit_config:
   - name: dnf-makecache
     type: timer
     Timer:
       OnBootSec: 10min
       OnUnitInactiveSec: 1h
       Unit: dnf-makecache.service
     Install:
       WantedBy: multi-user.target

[Swap]

Инкапсулирует разделы или файлы памяти подкачки операционной системы.

Пример

 # Убедитесь, что файл подкачки существует
 mkdir -p /var/vm
 fallocate -l 1024m /var/vm/swapfile
 chmod 600 /var/vm/swapfile
 mkswap /var/vm/swapfile

------------------------------------

 unit_config:
   - name: var-vm-swap
     type: swap
     Unit:
       Description=Включить подкачку для /var/vm/swapfile
     Swap:
       What: /var/vm/swapfile
     Install:
       WantedBy: multi-user.target

[Path]

Активирует другие службы при изменении или модификации объектов файловой системы.

Пример

 unit_config:
   - name: Триггер анализа покрытия кода репозитория
     type: path
     Unit:
       Description: Активировать анализ покрытия кода на измененных git-репозиториях
     Path:
       PathChanged: /path/to/git/repo
       Unit: code-coverage-analysis

[Scope]

Управляет набором процессов системы или удаленных процессов.

Единицы Scope не настраиваются через файлы конфигурации единиц, а создаются только программным образом с использованием интерфейсов шины systemd. В отличие от служебных единиц, единицы scope управляют внешне созданными процессами и не создают процессы самостоятельно. Основная цель единиц scope - группировка рабочих процессов системной службы для организации и управления ресурсами.

Пример

# *Эта конфигурация предназначена для временного файла единицы, созданного программным образом через API systemd. Не копировать и не редактировать.*
 unit_config:
   - name: user-session
     type: scope

     Unit:
       Description: Сессия пользователя
       Wants: [email protected]
       Wants: [email protected]
       After: systemd-logind.service systemd-user-sessions.service [email protected] [email protected]
       RequiresMountsFor: /home/user
       Scope:
         Slice: user-1000.slice
      Scope:
         SendSIGHUP=yes
         TasksMax=infinity

[Slice]

Группирует и управляет системными процессами в иерархическом дереве для управления ресурсами.

Имя раздела кодирует место в дереве. Имя состоит из сериала имен, разделенных дефисами, которые описывают путь к разделу от корневого раздела. По умолчанию служебные и scope единицы размещаются в system.slice, виртуальные машины и контейнеры, зарегистрированные с помощью systemd-machined(1), находятся в machine.slice, а пользовательские сессии обрабатываются systemd-logind(1) в user.slice.

Смотрите systemd.slice(5) для получения дополнительных деталей.

[Drop-in]

Обеспечивает возможности переопределения для единиц.

Пример

 unit_config:
   - name: override.conf
     type: conf
     path: "/lib/systemd/system/[email protected]"
     Service:
       ExecStart:
         - ""
         - "-/sbin/agetty -a muru --noclear %I $TERM"
       EnvironmentFile=/path/to/some/file

Запуск

[unit_config: <config-list-entry>:] enabled: (по умолчанию: <строка> no)

следует ли запускать службу при загрузке

[unit_config: <config-list-entry>:] state: (по умолчанию: <строка> stopped)

состояние активации единицы

Зависимости

Нет

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

стандартный пример (без указания индивидуальных конфигураций единиц):

- hosts: all
  roles:
  - role: 0x0I.systemd

пара служебных/сокетных/монтированных единиц:

- hosts: webservers
  roles:
  - role: 0x0i.systemd
    vars:
      unit_config:
      - name: "my-service"
        Unit:
          After: network-online.target
          Wants: network-online.target
          Requires: my-service.socket
        Service:
          User: 'web'
          Group: 'web'
          ExecStart: '/usr/local/bin/my_service $ARGS'
          ExecReload: '/bin/kill -s HUP $MAINPID'
        Install:
          WantedBy: 'multi-user.target'
      - name: "my-service"
        type: "socket"
        Socket:
          ListenStream: '0.0.0.0:4321'
          Accept: 'true'
        Install:
          WantedBy: 'sockets.target'
      - name: "var-data-my_service"
        type: "mount"
        path: "/run/systemd/system"
        Mount:
          What: '/dev/nvme0'
          Where: '/var/data/my_service'
        Install:
          WantedBy: 'multi-user.target'

Лицензия

MIT

Информация об авторе

Эта роль была создана в 2019 году компанией O1.IO.

О проекте

Systemd, a system and service manager for Linux operating systems

role systemd system manager

Установить

ansible-galaxy install 0x0I/ansible-role-systemd

GitHub репозиторий

31 звезд(ы)

23 форк(ов)

9 открытых задач

Лицензия

Unknown

Загрузки

7414708

Владелец

0x0I