0x0i.systemd

概要 バージョン 洞察

ansible logo

redhat logo

Ansibleロール :vertical_traffic_light: Systemd

Galaxy Role GitHubリリース（最新日付） ライセンス: MIT

目次

このAnsibleロールは、Linuxのsystemdシステム管理者によって管理されるシステムコンポーネントとサービスであるSystemd ユニットをインストールおよび設定します。

サポートされているプラットフォーム:
* Debian
* Redhat（CentOS/Fedora）
* Ubuntu

要件

systemdは、一般的にLinuxディストリビューションの事実上のサービス管理ツールと見なされており、ほとんどのOSインストールに含まれています。通常は問題になりませんが、systemdにはLinuxカーネル >= 3.13が必要であり、統合cgroup階層サポートにはLinuxカーネル >= 4.2が必要です。

詳細については、systemdのREADMEを参照してください。

ロール変数

変数は利用可能で、次のソフトウェアおよびマシンプロビジョニング段階に従って整理されています。

  • install
  • config
  • launch

インストール

[unit_config: <config-list-entry>:] path: （デフォルト: /etc/systemd/system）

  • systemdユニット設定へのロードパス。

    /etc/systemd/system（デフォルト）に加えて、ユニット設定ファイルや関連する*.d*ディレクトリのオーバーライドは、/usr/lib/systemd/systemまたは/run/systemd/systemディレクトリに配置できます。

    /etc内のファイルは、**/run内のファイルよりも優先され、/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（*$XDG_DATA_DIRSの各$dir*に対して） インストールされたユーザーユニットの追加の場所、*$XDG_DATA_DIRS*の各エントリに対して1つ
/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: <string> （デフォルト: 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スタイルの設定ファイルで宣言されます。systemdユニットのINI設定は、すべてのユニットタイプに共通する2つのセクション（UnitとInstall）と、各ユニットタイプに特有の1つのセクションで構成されています。これらのユニット構成は、ロールのunit_configハッシュ変数内で、ユニットの名前、タイプ、ロードパス、前述のセクション定義の組み合わせを含む辞書のリストとして表現できます。

各設定セクション定義は、対応するセクションオプションのキーと値のペアを含む辞書を提供します（例：ExecStart仕様のシステムまたはWebサービスの[Service]セクションや、Webの[Socket]セクションのListenStreamオプション）。

[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ルールファイルでudevデバイスをタグ付けするには、TAG+="systemdを使用します。また、デバイスユニットは制御する*/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"

# 結果として、適切な[Unit]および[Install]セクションが設定されたnvidia-fallback.deviceファイルが自動生成されます

[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]

システムまたは外部/リモートプロセスのセットを管理します。

スコープユニットは、ユニット設定ファイルを介して構成されるのではなく、systemdのバスインターフェースを使用してプログラム的にのみ作成されます。 サービスユニットとは異なり、スコープユニットは外部で作成されたプロセスを管理し、独自にプロセスを派生させることはありません。スコープユニットの主な目的は、システムサービスの作業プロセスを整理し、リソースを管理することです。

例

# *この設定は、systemd APIを介してプログラム的に作成された一時的なユニットファイル用です。コピーまたは編集しないでください。*
 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]

リソース管理の目的で、システムプロセスを階層ツリーでグループ化および管理します。

スライスの名前は、ツリー内の位置をエンコードします。名前は、スライスのルートスライスからのパスを説明するダッシュで区切られた名前の連なりで構成されています。デフォルトでは、サービスおよびスコープユニットは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

著者情報

このロールはO1.IOによって2019年に作成されました。

プロジェクトについて

Systemd, a system and service manager for Linux operating systems

role systemd system manager
インストール
ansible-galaxy install 0x0i.systemd
GitHub リポジトリ
34 スター
22 フォーク
0 オープンな問題
ライセンス
Unknown
ダウンロード
8.3M
所有者