Questo contenuto non è disponibile nella lingua selezionata.
Chapter 28. Managing systemd units by using RHEL system roles
By using the systemd
RHEL system role, you can automate certain systemd-related tasks and perform them remotely. You can use the role for the following actions:
- Manage services
- Deploy units
- Deploy drop-in files
28.1. Managing services by using the systemd RHEL system role
You can automate and remotely manage systemd units, such as starting or enabling services, by using the systemd
RHEL system role.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudo
permissions on them.
Procedure
Create a playbook file, for example
~/playbook.yml
, with the following content. Use only the variables depending on what actions you want to perform.--- - name: Managing systemd services hosts: managed-node-01.example.com tasks: - name: Perform action on systemd units ansible.builtin.include_role: name: rhel-system-roles.systemd vars: systemd_started_units: - <systemd_unit_1>.service systemd_stopped_units: - <systemd_unit_2>.service systemd_restarted_units: - <systemd_unit_3>.service systemd_reloaded_units: - <systemd_unit_4>.service systemd_enabled_units: - <systemd_unit_5>.service systemd_disabled_units: - <systemd_unit_6>.service systemd_masked_units: - <systemd_unit_7>.service systemd_unmasked_units: - <systemd_unit_8>.service
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.systemd/README.md
file on the control node.Validate the playbook syntax:
$ ansible-playbook --syntax-check ~/playbook.yml
Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
$ ansible-playbook ~/playbook.yml
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.systemd/README.md
file -
/usr/share/doc/rhel-system-roles/systemd/
directory
28.2. Deploying systemd drop-in files by using the systemd RHEL system role
Systemd applies drop-in files on top of setting it reads for a unit from other locations. Therefore, you can modify unit settings with drop-in files without changing the original unit file. By using the systemd
RHEL system role, you can automate the process of deploying drop-in files.
The role uses the hard-coded file name 99-override.conf
to store drop-in files in /etc/systemd/system/<name>._<unit_type>/
. Note that it overrides existing files with this name in the destination directory.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudo
permissions on them.
Procedure
Create a Jinja2 template with the systemd drop-in file contents. For example, create the
~/sshd.service.conf.j2
file with the following content:{{ ansible_managed | comment }} [Unit] After= After=network.target sshd-keygen.target network-online.target
This drop-in file specifies the same units in the
After
setting as the original/usr/lib/systemd/system/sshd.service
file and, additionally,network-online.target
. With this extra target,sshd
starts after the network interfaces are actived and have IP addresses assigned. This ensures thatsshd
can bind to all IP addresses.Use the
<name>.<unit_type>.conf.j2
convention for the file name. For example, to add a drop-in for thesshd.service
unit, you must name the filesshd.service.conf.j2
. Place the file in the same directory as the playbook.Create a playbook file, for example
~/playbook.yml
, with the following content:--- - name: Managing systemd services hosts: managed-node-01.example.com tasks: - name: Deploy an sshd.service systemd drop-in file ansible.builtin.include_role: name: rhel-system-roles.systemd vars: systemd_dropins: - sshd.service.conf.j2
The settings specified in the example playbook include the following:
systemd_dropins: <list_of_files>
- Specifies the names of the drop-in files to deploy in YAML list format.
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.systemd/README.md
file on the control node.Validate the playbook syntax:
$ ansible-playbook --syntax-check ~/playbook.yml
Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
$ ansible-playbook ~/playbook.yml
Verification
Verify that the role placed the drop-in file in the correct location:
# ansible managed-node-01.example.com -m command -a 'ls /etc/systemd/system/sshd.service.d/' 99-override.conf
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.systemd/README.md
file -
/usr/share/doc/rhel-system-roles/systemd/
directory
28.3. Deploying systemd units by using the systemd RHEL system role
You can create unit files for custom applications, and systemd reads them from the /etc/systemd/system/
directory. By using the systemd
RHEL system role, you can automate the deployment of custom unit files.
Prerequisites
- You have prepared the control node and the managed nodes.
- You are logged in to the control node as a user who can run playbooks on the managed nodes.
-
The account you use to connect to the managed nodes has
sudo
permissions on them.
Procedure
Create a Jinja2 template with the custom systemd unit file contents. For example, create the
~/example.service.j2
file with the contents for your service:{{ ansible_managed | comment }} [Unit] Description=Example systemd service unit file [Service] ExecStart=/bin/true
Use the
<name>.<unit_type>.j2
convention for the file name. For example, to create theexample.service
unit, you must name the fileexample.service.j2
. Place the file in the same directory as the playbook.Create a playbook file, for example
~/playbook.yml
, with the following content:--- - name: Managing systemd services hosts: managed-node-01.example.com tasks: - name: Deploy, enable, and start a custom systemd service ansible.builtin.include_role: name: rhel-system-roles.systemd vars: systemd_unit_file_templates: - example.service.j2 systemd_enabled_units: - example.service systemd_started_units: - example.service
For details about all variables used in the playbook, see the
/usr/share/ansible/roles/rhel-system-roles.systemd/README.md
file on the control node.Validate the playbook syntax:
$ ansible-playbook --syntax-check ~/playbook.yml
Note that this command only validates the syntax and does not protect against a wrong but valid configuration.
Run the playbook:
$ ansible-playbook ~/playbook.yml
Verification
Verify that the service is enabled and started:
# ansible managed-node-01.example.com -m command -a 'systemctl status example.service' ... ● example.service - A service for demonstrating purposes Loaded: loaded (/etc/systemd/system/example.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2024-07-04 15:59:18 CEST; 10min ago ...
Additional resources
-
/usr/share/ansible/roles/rhel-system-roles.systemd/README.md
file -
/usr/share/doc/rhel-system-roles/systemd/
directory