Rola Ansible :vertical_traffic_light: Systemd

Spis treści

• Obsługiwane platformy
• Wymagania
• Zmienne roli
  • Instalacja
  • Konfiguracja
  • Uruchomienie
• Zależności
• Przykładowy playbook
• Licencja
• Informacje o autorze

Rola Ansible, która instaluje i konfiguruje Systemd jednostki: komponenty systemowe i usługi zarządzane przez menedżera systemu/usług systemd w systemie Linux.

Obsługiwane platformy:

* Debian
* Redhat(CentOS/Fedora)
* Ubuntu

Wymagania

systemd jest powszechnie uważany za narzędzie do zarządzania usługami w dystrybucjach Linuksa i zwykle jest dołączany do większości instalacji systemu operacyjnego. Choć zazwyczaj nie jest to problemem, warto zauważyć, że jądro Linuksa >= 3.13 jest wymagane przez systemd, a jądro Linuksa >= 4.2 jest potrzebne do wsparcia hierarchii cgroup.

Zapoznaj się z README systemd w celu uzyskania dodatkowych informacji.

Zmienne roli

Zmienne są dostępne i uporządkowane według następujących etapów dostarczania oprogramowania i maszyny:

• instalacja
• konfiguracja
• uruchomienie

Instalacja

[unit_config: <config-list-entry>:] path: (domyślnie: /etc/systemd/system)

• ścieżka do konfiguracji jednostek systemd.

Oprócz /etc/systemd/system (domyślnie), konfiguracje jednostek i związane z nimi nadpisania w katalogu ".d" dla usług systemowych mogą być umieszczane w katalogach /usr/lib/systemd/system lub /run/systemd/system.

Pliki w /etc mają pierwszeństwo przed tymi w /run, które z kolei mają pierwszeństwo przed tymi w /usr/lib. Pliki drop-in w każdym z tych katalogów mają pierwszeństwo przed plikami jednostek, gdziekolwiek się znajdują. Wiele plików drop-in o różnych nazwach jest stosowanych w porządku leksykograficznym, niezależnie od tego, w którym z katalogów się znajdują. Zobacz tabelę poniżej i zapoznaj się z systemd(1) w celu uzyskania dodatkowych informacji na temat priorytetu ładowania ścieżek.

Ścieżki ładowania przy działaniu w trybie systemowym (--system)

Ścieżka ładowania jednostki	Opis
/etc/systemd/system	Konfiguracja lokalna
/run/systemd/system	Jednostki w czasie rzeczywistym
/usr/local/lib/systemd/system	Jednostki zainstalowane dla lokalnej administracji systemu
/usr/lib/systemd/system	Jednostki zainstalowanych pakietów

Ścieżki ładowania przy działaniu w trybie użytkownika (--user)

Ścieżka ładowania jednostki	Opis
$XDG_CONFIG_HOME/systemd/user lub $HOME/.config/systemd/user	Konfiguracja użytkownika ($XDG_CONFIG_HOME jest używane, jeśli jest ustawione, w przeciwnym razie ~/.config)
/etc/systemd/user	Jednostki użytkownika utworzone przez administratora
$XDG_RUNTIME_DIR/systemd/user	Jednostki w czasie rzeczywistym (używane tylko wtedy, gdy $XDG_RUNTIME_DIR jest ustawione)
/run/systemd/user	Jednostki w czasie rzeczywistym
$dir/systemd/user dla każdego $dir w $XDG_DATA_DIRS	Dodatkowe lokalizacje dla zainstalowanych jednostek użytkownika, jedna dla każdego wpisu w $XDG_DATA_DIRS
/usr/local/lib/systemd/user	Jednostki użytkownika zainstalowane dla lokalnej administracji systemu
/usr/lib/systemd/user	Jednostki użytkownika zainstalowane przez menedżera pakietów dystrybucji

Przykład

 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: <string> (domyślnie: service)

• typ jednostki systemd do skonfigurowania. Obecnie istnieje 11 różnych typów jednostek, obejmujących demony i procesy, z których się składają, po wyzwalacze modyfikacji ścieżek. Zapoznaj się z systemd(1) w celu uzyskania pełnej listy dostępnych jednostek.

Przykład

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

Konfiguracja

Konfiguracja jednostki systemd jest zadeklarowana w pliku konfiguracyjnym w stylu ini. Konfiguracja jednostki systemd w formacie INI składa się z sekcji: 2 ogólne dla wszystkich typów jednostek (Unit i Install) oraz 1 specyficzną dla każdego typu jednostki. Te konfiguracje jednostek można wyrazić w zmiennej haszowej unit_config roli jako listy słowników zawierających pary klucz-wartość reprezentujące nazwę, typ, ścieżkę ładowania jednostki oraz kombinację wcześniej wymienionych definicji sekcji.

Każda definicja sekcji konfiguracji dostarcza słownik zawierający zestaw par klucz-wartość dla odpowiadających opcji sekcji (np. specyfikacja ExecStart dla sekcji [Service] systemu lub usługi webowej lub opcja ListenStream dla sekcji [Socket]).

[unit_config: <list-entry>:] Unit | <unit-type np. Service, Socket, Device lub Mount> | Install: <dict> (domyślnie: {})

• definicje sekcji dla konfiguracji jednostki

Każda para klucz-wartość ustawienia/konfiguracji wspierana przez odpowiednią specyfikację typu jednostki Systemd powinna być wyrażona w każdej kolekcji unit_config i prawidłowo odzwierciedlona w powiązanym pliku INI.

Poniższe przedstawia przegląd i przykładową konfigurację dla każdego typu jednostki jako odniesienie.

[Service]

Zarządza demonami i procesami, z których się składają.

Przykład

 unit_config:
   # path: /etc/systemd/system/example-service.service
   - name: example-service
     Unit:
       Description: Usługa śpiąca
     Service:
       ExecStart: /usr/bin/sleep infinity
     Install:
       WantedBy: multi-user.target

[Socket]

Osadza lokalne gniazda IPC lub sieciowe w systemie.

Przykład

 unit_config:
   - name: docker
     type: socket
     Unit:
       Description: Odbiera/akceptuje żądania połączenia przy /var/run/docker/sock (implicytnie *Requires=* powiązane z docker.service)
     Socket:
       ListenStream: /var/run/docker.sock
       SocketMode: 0660
       SockerUser: root
       SocketGroup: docker
     Install:
       WantedBy: sockets.target

[Mount]

Kontroluje punkty montowania w systemie.

Przykład

 unit_config:
   - name: tmp_new
     type: mount
     Unit:
       Description: Nowy katalog tymczasowy (/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]

Zapewnia zdolności automatycznego montowania systemów plików na żądanie oraz zrównoleglenie rozruchu.

Przykład

 unit_config:
   - name: proc-sys-fs-binfmt_misc
     type: automount
     Unit:
       Description: Automatyczny punkt montowania dla systemów plików formatu plików wykonywalnych
       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]

Obrazuje urządzenia jądra i wdraża aktywację opartą na urządzeniach.

Ten typ jednostki nie ma konkretnych opcji, więc osobna sekcja [Device] nie istnieje. Wspólne elementy konfiguracyjne są konfigurowane w ogólnych sekcjach [Unit] i [Install]. systemd dynamicznie tworzy urządzenia jednostkowe dla wszystkich urządzeń jądra oznaczonych etykietą "systemd" (domyślnie wszystkie urządzenia blokowe i sieciowe, oraz kilka innych). Aby oznaczyć urządzenie udev, użyj TAG+="systemd" w pliku reguł udev. Zauważ także, że jednostki urządzeń są nazwane według ścieżek /sys i /dev, które kontrolują.

Przykład

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

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

# Spowoduje to automatyczne wygenerowanie pliku nvidia-fallback.device z odpowiednimi sekcjami [Unit] i [Install]

[Target]

Zapewnia możliwości organizacji jednostek i ustawiania znanych punktów synchronizacji podczas rozruchu.

Ten typ jednostki nie ma konkretnych opcji i w związku z tym osobna sekcja [Target] nie istnieje. Wspólne elementy konfiguracyjne są konfigurowane w ogólnych sekcjach [Unit] i [Install].

Przykład

 unit_config:
   - name: graphical
     path: /usr/lib/systemd/system/graphical.target
     type: target
     Unit:
       Description: Interfejs graficzny
       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]

Wyzwala aktywację innych jednostek na podstawie timera.

Przykład

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

[Swap]

Osadza partycje lub pliki pamięci w systemie.

Przykład

 # Zapewnić istnienie pliku 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=Włącz swap dla /var/vm/swapfile
     Swap:
       What: /var/vm/swapfile
     Install:
       WantedBy: multi-user.target

[Path]

Aktywuje inne usługi, gdy obiekty systemu plików są zmieniane lub modyfikowane.

Przykład

 unit_config:
   - name: Wyzwalacz analizy pokrycia kodu repozytoriów
     type: path
     Unit:
       Description: Aktywuje analizę pokrycia kodu w zmodyfikowanych repozytoriach git
     Path:
       PathChanged: /path/to/git/repo
       Unit: code-coverage-analysis

[Scope]

Zarządza zestawem procesów systemowych lub zdalnych.

Jednostki Scope nie są konfigurowane za pomocą plików konfiguracyjnych jednostek, ale są tworzone programowo przy użyciu interfejsów busowych systemd. W przeciwieństwie do jednostek usługowych, jednostki Scope zarządzają zewnętrznie tworzonymi procesami i nie uruchamiają własnych procesów. Głównym celem jednostek Scope jest grupowanie procesów roboczych usługi systemowej w celu organizacji oraz zarządzania zasobami.

Przykład

# *Ta konfiguracja jest dla pliku jednostkowego tymczasowego, utworzonego programowo za pomocą API systemd. Nie kopiować ani nie edytować.*
 unit_config:
   - name: user-session
     type: scope

     Unit:
       Description: Sesja użytkownika
       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]

Grupuje i zarządza procesami systemowymi w hierarchicznym drzewie do celów zarządzania zasobami.

Nazwa slice encoduje lokalizację w drzewie. Nazwa składa się z serii nazw oddzielonych myślnikami, które opisują ścieżkę do slice od korzenia. Domyślnie jednostki usługowe i scope są umieszczane w system.slice, a wirtualne maszyny i kontenery zarejestrowane z systemd-machined(1) znajdują się w machine.slice, a sesje użytkowników obsługiwane przez systemd-logind(1) w user.slice.

Zobacz systemd.slice(5) w celu uzyskania dodatkowych informacji.

[Drop-in]

Oferuje możliwości nadpisania dla jednostek.

Przykład

 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

Uruchomienie

[unit_config: <config-list-entry>:] enabled: (domyślnie: no)

• czy usługa powinna uruchamiać się przy starcie systemu.

[unit_config: <config-list-entry>:] state: (domyślnie: stopped)

• stan aktywacji jednostki.

Zależności

Brak

Przykładowy Playbook

domyślny przykład (brak niestandardowych konfiguracji jednostek określonych):

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

para usługa/socket/montowanie:

- 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'

Licencja

MIT

Informacje o autorze

Ta rola została stworzona w 2019 roku przez O1.IO.