Ansible rola usługi systemd

Rola Ansible, która tworzy i konfiguruje pliki jednostek usług systemd (systemd service unit). Umożliwia automatyczne uruchamianie niektórych usług w tle, włączanie i wyłączanie ich w odpowiednich sytuacjach, zarządzanie grupami procesów oraz konfigurowanie zależności z innymi jednostkami.

Rola obejmuje następujące zadania:

1. Tworzenie pliku usługi systemd w /etc/systemd/system/ z określoną nazwą service_name.service dla każdego elementu systemd_service.
2. Konfigurowanie ważnych opcji w sekcjach Unit, Service i Install.
3. Powiadomienie systemd, że nowe pliki usług istnieją. Restart usługi.
4. Włączenie automatycznego uruchamiania usługi przy starcie systemu, jeśli to konieczne.

Wymagania

Ta rola wymaga dostępu roota, dlatego uruchom ją w playbooku z globalnym parametrem become: yes lub wywołaj rolę w swoim playbooku w następujący sposób:

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

Zmienne roli

Wszystkie niezbędne usługi mogą być określone za pomocą zmiennej słownikowej systemd_service (patrz defaults/main.yml):

systemd_service: {}

Dla każdej usługi musisz ustawić service_name i niezbędne wartości parametrów. Na przykład, aby określić, czy usługa ma się uruchamiać przy starcie, użyj parametru enabled.

systemd_service:
  service:
    service_name:
    enabled:

Wszystkie inne dostępne parametry, które należy określić dla konkretnego klucza service_name (jako zagnieżdżone parametry), są opisane poniżej.

Opcje sekcji Unit

Ta grupa parametrów zawiera ogólne informacje o jednostce.

description:   # Dowolny ciąg opisujący jednostkę

Dwa kolejne parametry konfigurowane są dla zależności z innymi jednostkami. Jeśli usługa zostanie aktywowana, wymienione jednostki również zostaną uruchomione. Jeśli jedna z jednostek requires nie może być uruchomiona lub nagle się nie powiedzie, usługa również zostanie zatrzymana. W przypadku listy wants, usługa nie zostanie zatrzymana, jeśli któraś z jej jednostek zostanie dezaktywowana. Parametry mogą zawierać kilka nazw jednostek oddzielonych spacjami. Mogą być również określane więcej niż raz.

requires:   # Jednostki, które muszą być uruchomione razem z usługą
wants:      # Jednostki, które powinny być uruchomione razem z usługą

Aby skonfigurować kolejność, w jakiej usługi są uruchamiane lub zatrzymywane, użyj następujących parametrów. Zauważ, że jeśli jednostki nie mają między sobą zależności dotyczących kolejności, są wyłączane lub uruchamiane jednocześnie. Oba parametry są ustawiane przez listy jednostek oddzielone spacjami.

after:   # Jednostki, które muszą być uruchomione po usłudze
before:  # Jednostki, które muszą być uruchomione przed usługą

Opcje sekcji Service

Ta sekcja zawiera informacje o usłudze i procesie, którym ona zarządza. Parametr type konfiguruje typ uruchamiania procesu dla tej jednostki usługi.

type:

Może przyjmować wartości:

• simple - ten typ zakłada, że usługa będzie uruchamiana natychmiast. Proces nie może się rozgałęziać. Nie używaj tego typu, jeśli inne usługi mają zależności dotyczące kolejności od uruchamiania tej usługi. Jeśli usługa oferuje funkcjonalność innym procesom w systemie, jej kanały komunikacyjne powinny być zainstalowane przed uruchomieniem demona.
• forking - zakłada, że usługa jest uruchamiana raz, a proces rozgałęzia się po zakończeniu procesu nadrzędnego. Ten typ jest używany do uruchamiania klasycznych demonów. Jeśli ten tryb jest używany, zaleca się również użycie parametru pid_file (patrz poniżej), aby systemd mógł zidentyfikować główny proces demona.

Inne wartości działają podobnie do wartości simple, jednak mają pewne różnice:

• oneshot - oczekuje się, że usługa zakończy działanie, zanim systemd uruchomi kolejne jednostki;
• dbus - oczekuje się, że demon uzyska nazwę w busie D-Bus;
• notify - demon wysyła wiadomość powiadamiającą za pomocą sd_notify(3) lub podobnego wywołania, gdy zakończy uruchamianie;
• idle - faktyczne wykonanie binarki usługi jest opóźnione, aż wszystkie aktywne zadania zostaną zakończone. Zauważ, że ten typ jest przydatny tylko w celu poprawy wydruku na konsoli, nie jest przydatny jako ogólny narzędzie do ustalania kolejności jednostek.

Ustaw ścieżkę do pliku PID, aby użyć typu uruchamiania forking.

pid_file:    # Przyjmuje absolutną nazwę pliku wskazującą na plik PID tego demona

Możesz określić użytkownika UNIX i grupę, pod którymi usługa powinna być wykonywana. Parametry przyjmują jedną nazwę użytkownika lub grupy, lub identyfikator numeryczny jako wartość. Dla usług systemowych i dla usług użytkownika roota domyślnym użytkownikiem jest root, który może zostać zmieniony na innego. Dla usług użytkowników innych niż roota, zmiana tożsamości użytkownika nie jest dozwolona. Dlatego jedyną dozwoloną wartością jest ten sam użytkownik, pod którym działa menedżer usług. Jeśli nie ustawiono grupy, używana jest domyślna grupa użytkownika.

user:
group:

Ustaw priorytet planowania dla jednostki za pomocą następującego parametru. Przyjmuje liczbę całkowitą od -20 (najwyższy priorytet) do 19 (najniższy priorytet).

nice:    # Domyślny poziom nice dla usługi

Poziom dostosowania dla zabójcy Out-Of-Memory dla procesu określany jest za pomocą następującej opcji. Przyjmuje wartość całkowitą od -1000 (wyłączenie zabijania OOM) do 1000 (preferowane zabijanie OOM).

oom_score_adjust:

Następne parametry pozwalają określić polecenia, które będą wykonywane w zależności od stanu usługi. Parametry mogą być używane więcej niż raz lub ich wartości mogą zawierać kilka poleceń. Wiele linii poleceń można połączyć w jednym dyrektywie, oddzielając je średnikami. Polecenie do wykonania musi być absolutną ścieżką. Może zawierać spacje, ale znaki sterujące są niedozwolone. Dla każdego polecenia pierwszy argument musi być absolutną ścieżką do pliku wykonywalnego. Pusty ciąg zresetuje listę poleceń określonych wcześniej dla parametru.

# Polecenia, które są wykonywane, gdy ta usługa jest uruchamiana
# Chyba że `type` to `oneshot`, tutaj musi być podane dokładnie jedno polecenie
exec_start:

# Polecenia, które są wykonywane przed poleceniami `exec_start`
exec_start_pre:

# Polecenia, które są wykonywane po poleceniach `exec_start`
exec_start_post:

# Polecenia do wykonania w celu zatrzymania usługi uruchomionej za pomocą `exec_start`
exec_stop:

# Polecenia, które są wykonywane po zatrzymaniu usługi
exec_stop_post:

# Polecenia do wykonania w celu wywołania ponownej konfiguracji w usłudze
exec_reload:

Ustaw, czy usługa powinna być ponownie uruchamiana, gdy proces usługi (główny proces usługi lub jeden określony przez parametry 'exec_start_pre', 'exec_start_post', 'exec_stop', 'exec_stop_post' lub 'exec_reload') zakończy działanie, zostanie zabity lub osiągnięty zostanie limit czasu. Parametr restart przyjmuje jedną z następujących wartości:

• no (domyślnie) - usługa nie będzie ponownie uruchamiana;
• on-success - usługa zostanie ponownie uruchomiona tylko wtedy, gdy proces usługi zakończy się poprawnie (z kodem zakończenia 0 lub jednym z sygnałów SIGHUP, SIGINT, SIGTERM lub SIGPIPE);
• on-failure - usługa zostanie ponownie uruchomiona, gdy proces zakończy się z kodem zakończenia różnym od zera, zostanie zakończony sygnałem, gdy operacja przekroczy czas, a zdefiniowany limit czasu watchdog zostanie wywołany;
• on-abnormal - usługa zostanie ponownie uruchomiona, gdy proces zostanie zakończony sygnałem, gdy operacja przekroczy czas, lub gdy wywołany zostanie limit czasu watchdog;
• on-watchdog - usługa zostanie ponownie uruchomiona tylko, jeśli proces usługi zakończy się z powodu nieprzechwyconego sygnału, który nie jest określony jako stan zakończenia czystego;
• on-abort - usługa zostanie ponownie uruchomiona tylko wtedy, gdy limit czasu watchdog dla usługi wygaśnie;
• always - usługa zostanie ponownie uruchomiona bez względu na wszystko.

# Kiedy usługa musi być ponownie uruchomiona
restart:

Możesz określić opóźnienie czasowe dla wyżej wymienionych poleceń za pomocą następujących parametrów. Przyjmują one wartość w sekundach lub wartość czasu, taką jak '5min 20s'. Parametr restart_sec konfiguruje czas oczekiwania przed ponownym uruchomieniem usługi (jak skonfigurowano z restart). Opcja timeout_sec definiuje czas oczekiwania na przetwarzanie poleceń start/stop.

restart_sec:
timeout_sec:

Użyj parametru environment, aby ustawić listę zmiennych środowiskowych dla wykonywanych procesów. Zawiera słownik zmiennych i ich wartości. Jeśli jakaś wartość zawiera spację, użyj podwójnych cudzysłowów do przypisania.

Możesz również odczytać zmienne środowiskowe z pliku tekstowego. W tym celu ustaw wartość parametru environment_file na ścieżkę do pliku.

environment:       # Słownik z zmiennymi ENV
environment_file:  # Ścieżka do pliku ze zmiennymi środowiskowymi

Katalog roboczy określa się za pomocą następnego parametru. Jest ustawiany jako bieżący przed uruchomieniem poleceń startowych.

working_directory:

Następujące parametry pozwalają wybrać, gdzie deskryptory plików (STDIN, STDOUT, STDERR) wykonywanych procesów powinny być połączone. Parametr standard_input przyjmuje wartości "null", "tty", "tty-force", "tty-fail", "socket" lub "fd". Parametr standard_output może być równy "inherit", "null", "tty", "journal", "syslog", "kmsg", "journal+console", "syslog+console", "kmsg+console", "socket" lub "fd". Dostępne wartości standard_error są identyczne jak dla standard_output.

standard_input:
standard_output:
standard_error:

Jeśli "tty", "tty-force" lub "tty-fail" jest określone dla któregokolwiek z parametrów "standard_*", możesz określić ścieżkę do tty.

tty_path:

Jeśli usługa ma być w stanie ponownie uruchomionym/wczytanym/uruchomionym/zatrzymanym po utworzeniu lub modyfikacji usługi.

state:

Może przyjmować wartości: restarted (domyślnie) reloaded started stopped.

Opcje sekcji Install

Zmienne tej sekcji zawierają informacje o instalacji jednostki. Można używać następujących dwóch parametrów wielokrotnie lub określać listy jednostek oddzielone spacjami. Listy zawierają jednostki, które odnoszą się do tej usługi ze swoich pól requires i wants.

wanted_by:
required_by:

Zależności

Brak

Przykładowy playbook

- hosts: app
  roles:
    - role: systemd_service
       systemd_service:
        # Domyślna nazwa usługi
        railsapp:
          # Nazwa usługi
          service_name: railsapp
          # Uruchom usługę przy starcie
          enabled: Yes
          # Wykonaj polecenie z określonymi argumentami, gdy usługa jest uruchamiana
          exec_start: "/bin/bash -lc 'puma -C config/puma.rb'"
          # Użyj określonego katalogu jako bieżącego
          working_directory: "/var/www/myapp"
          # określ zmienną środowiskową
          environment: {ENVVAR: value}
          # Uruchom procesy jako ten użytkownik i grupa
          user: "deploy"
          group: "deploy"
          # Ponownie uruchom usługę tylko wtedy, gdy nie otrzymano czystego kodu wyjścia lub sygnału
          restart: "on-failure"
          # Spróbuj aktywować 'redis', jeśli to możliwe
          wants: "redis.service"
          # Aktywuj 'postgresql' lub przestań działać w przypadku niepowodzenia
          requires: "postgresql.service"
          # jednostka multi-user.target preferuje uruchomienie usługi
          wanted_by: "multi-user.target"

Licencja

Licencjonowane na mocy Licencji MIT.