How to enable services on boot on remote hosts with Ansible?
I’m going to show you a live Playbook with some simple Ansible code. I’m Luca Berton and welcome to today’s episode of Ansible Pilot.
Ansible enable services on boot on remote hosts
- ansible.builtin.service_facts
- Return service state information as fact data
- ansible.builtin.service
- Manage services
Today we’re talking about Ansible modules service_facts and service.
First, you need to acquire the information of the services on the target machine.
This task is performed by the Ansible module service_facts. You can’t enable a service that doesn’t exist, can you?
The effective actions are performed by the Ansible module service.
The full name is ansible.builtin.service which means that both these modules are part of the collection of modules “builtin” with Ansible and shipped with it.
This module is pretty stable and out for years and its purpose is to manage services on remote hosts.
For Windows targets, use the ansible.windows.win_service module instead.
Parameters
- name path - name of the service
- state string - started / stopped / restarted / reloaded
- enabled boolean - no/yes
- arguments/args string - extra args
The parameter list is pretty wide but I’ll summarize the most useful. The only required parameter is “name” that specifies the name of the service. At least one between the “state” and “enabled” parameters is mandatory. The “state” parameter defines the action that we are going to take. It has four alternative options: “started” and “stopped” options allow you to run or stop the service. “restarted” is a combination of stop and start - you could also customize the number of seconds between using the “sleep” parameter The “reloaded” option is useful if the service needs to reload the configuration file. The “enable” parameter allows you to decide if the service should start on boot or not. The “arguments or args” parameter allows you to specify some additional arguments provided on the command line.
Playbook
Enable services on boot and start on remote hosts with Ansible Playbook. Included code and Playbook with chronyd.service NTP server on a RedHat Enterprise Linux 8.
code
- service_enable_on_boot.yml
---
- name: service module Playbook
hosts: all
become: true
vars:
services_on_boot:
- "chronyd.service"
tasks:
- name: populate service facts
ansible.builtin.service_facts:
- name: enable services on boot
ansible.builtin.service:
name: "{{ item }}"
enabled: true
state: started
when: "item in services"
with_items: '{{ services_on_boot }}'
execution
$ ansible-playbook -i virtualmachines/demo/inventory enable\ services\ on\ boot/service.yml
PLAY [service module Playbook] ************************************************************************
TASK [Gathering Facts] ****************************************************************************
ok: [demo.example.com]
TASK [populate service facts] *********************************************************************
ok: [demo.example.com]
TASK [enable services on boot] ************************************************************************
changed: [demo.example.com] => (item=chronyd.service)
PLAY RECAP ****************************************************************************************
demo.example.com : ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
before execution
$ ssh [email protected]
[devops@demo ~]$ sudo su
[root@demo devops]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.4 (Ootpa)
[root@demo devops]# rpm -qa | grep chrony
chrony-3.5-2.el8.x86_64
[root@demo devops]# systemctl status chronyd.service
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:chronyd(8)
man:chrony.conf(5)
[root@demo devops]#
after execution
$ ssh [email protected]
[devops@demo ~]$ sudo su
[root@demo devops]# systemctl status chronyd.service
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-11-29 11:29:53 UTC; 49s ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 1729 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCC>
Process: 1725 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1727 (chronyd)
Tasks: 1 (limit: 4943)
Memory: 844.0K
CGroup: /system.slice/chronyd.service
└─1727 /usr/sbin/chronyd
Nov 29 11:29:53 demo.example.com systemd[1]: Starting NTP client/server...
Nov 29 11:29:53 demo.example.com chronyd[1727]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLO>
Nov 29 11:29:53 demo.example.com chronyd[1727]: Frequency -491.773 +/- 29.501 ppm read from /var/l>
Nov 29 11:29:53 demo.example.com chronyd[1727]: Using right/UTC timezone to obtain leap second data
Nov 29 11:29:53 demo.example.com systemd[1]: Started NTP client/server.
Nov 29 11:29:59 demo.example.com chronyd[1727]: Selected source 81.25.28.124
Nov 29 11:29:59 demo.example.com chronyd[1727]: System clock TAI offset set to 37 seconds
Nov 29 11:29:59 demo.example.com chronyd[1727]: System clock wrong by 1.840437 seconds, adjustment>
Nov 29 11:30:00 demo.example.com chronyd[1727]: System clock was stepped by 1.840437 seconds
[root@demo devops]# reboot
Connection to demo.example.com closed by remote host.
Connection to demo.example.com closed.
ansible-pilot $ ssh [email protected]
[devops@demo ~]$ sudo su
[root@demo devops]# systemctl status chronyd.service
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-11-29 11:31:32 UTC; 28s ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 825 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCE>
Process: 811 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 820 (chronyd)
Tasks: 1 (limit: 4943)
Memory: 1.5M
CGroup: /system.slice/chronyd.service
└─820 /usr/sbin/chronyd
Nov 29 11:31:32 demo.example.com systemd[1]: Starting NTP client/server...
Nov 29 11:31:32 demo.example.com chronyd[820]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOC>
Nov 29 11:31:32 demo.example.com chronyd[820]: Frequency -389.145 +/- 224.519 ppm read from /var/l>
Nov 29 11:31:32 demo.example.com chronyd[820]: Using right/UTC timezone to obtain leap second data
Nov 29 11:31:32 demo.example.com systemd[1]: Started NTP client/server.
Nov 29 11:31:39 demo.example.com chronyd[820]: Selected source 81.25.28.124
Nov 29 11:31:39 demo.example.com chronyd[820]: System clock TAI offset set to 37 seconds
Nov 29 11:31:39 demo.example.com chronyd[820]: System clock wrong by 2.026567 seconds, adjustment >
Nov 29 11:31:41 demo.example.com chronyd[820]: System clock was stepped by 2.026567 seconds
Nov 29 11:31:43 demo.example.com chronyd[820]: Selected source 89.221.210.188
[root@demo devops]#
Conclusion
Now you know how to start and enable services on boot on Linux remote hosts with Ansible. Subscribe to the YouTube channel, Medium, and Website, X (formerly Twitter) to not miss the next episode of the Ansible Pilot.
Academy
Learn the Ansible automation technology with some real-life examples in my
Udemy 300+ Lessons Video Course.
My book Ansible By Examples: 200+ Automation Examples For Linux and Windows System Administrator and DevOps
Donate
Want to keep this project going? Please donate