7 Easy Ways to Manage Services with Ansible Service Module

Ansible Service Module Example

The Ansible service module allows you to control services (start, stop, restart, enable, disable) on remote hosts across various init systems like Systemd, SysV, and Upstart. This makes it a key component in system administration and DevOps automation.

In this comprehensive guide, you’ll learn how to use the service module with both playbooks and ad-hoc commands, including conditional tasks and handlers.

Basic Syntax

The basic syntax of the Ansible service module is as follows:

- name: Manage a service
  ansible.builtin.service:
    name: service_name
    state: state

Explanation:

  • name: The name of the service you want to manage.
  • state: The desired state of the service (started, stopped, restarted, reloaded, enabled, disabled).

Starting and Stopping Services

You can use the state: started parameter to start the service on specified remote hosts.

This Ansible playbook starts the Apache web server on all machines listed under the webservers group.

---
- name: Start Apache Service
  hosts: webservers
  become: yes
  tasks:
    - name: Ensure Apache is started
      ansible.builtin.service:
        name: apache2
        state: started

You can use the state: stopped option to stop the service on specified remote hosts.

The following playbook stops the Apache service on all remote hosts listed under the webservers group.

---
- name: Stop Apache Service
  hosts: webservers
  become: yes
  tasks:
    - name: Ensure Apache is stopped
      ansible.builtin.service:
        name: apache2
        state: stopped

Enabling and Disabling Services at Boot

You can use the enabled and disabled states to enable and disable services on remote hosts.

The following playbook enables the Apache service on all remote hosts specified in the webservers group.

---
- name: Enable Apache Service at Boot
  hosts: webservers
  become: yes
  tasks:
    - name: Ensure Apache is enabled at boot
      ansible.builtin.service:
        name: apache2
        enabled: yes

The following playbook disables the Apache service on all remote hosts specified in the webservers group.

---
- name: Disable Apache Service at Boot
  hosts: webservers
  become: yes
  tasks:
    - name: Ensure Apache is disabled at boot
      ansible.builtin.service:
        name: apache2
        enabled: no

Checking Service Status

To check the status of a service, you can use the state: started parameter, and Ansible will automatically check if the service is running. If you want to perform an action based on the service status, you can use the register keyword to capture the service status.

The below Ansible playbook checks whether the Apache service is running on all machines listed under the “webservers” group, stores the status in a variable called apache_status, and then prints the status information using the debug module.

---
- name: Check Apache Service Status
  hosts: webservers
  become: yes
  tasks:
    - name: Get Apache service status
      ansible.builtin.service:
        name: apache2
        state: started
      register: apache_status

    - name: Debug Apache service status
      debug:
        var: apache_status

Restarting Services

You can use the state: restarted parameter to restart service on the specified hosts.

The following playbook restarts the Apache service on all hosts listed in the webservers group.

---
- name: Restart Apache Service
  hosts: webservers
  become: yes
  tasks:
    - name: Ensure Apache is restarted
      ansible.builtin.service:
        name: apache2
        state: restarted

Using Handlers to Manage Services

Handlers in Ansible are tasks that run only when notified. They are typically used to restart services after a configuration file has been changed.

Let’s consider a scenario where you have a web server that uses Nginx and wants to update its configuration file. After updating the configuration, you must restart the Nginx service to apply the changes. You can use handlers to ensure that Nginx is only restarted if the configuration file is changed.

Here is an example playbook.

---
- name: Manage Nginx web server
  hosts: webservers
  become: yes
  tasks:
    - name: Update Nginx configuration file
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart Nginx

    - name: Ensure Nginx is started and enabled
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes

  handlers:
    - name: Restart Nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

The above example updates the Nginx configuration file using a template and notifies a handler to restart Nginx if the file changes. Then, it ensures that the Nginx service is running and enabled to start on boot. If the configuration file is updated, the handler will restart the Nginx service at the end of the play.

Managing Services with Ansible Ad-Hoc Commands

Ansible ad-hoc commands are a quick and easy way to perform one-off tasks on remote servers without needing to write a full playbook. You can use them to manage services, such as starting, stopping, or restarting a service, checking its status, and enabling or disabling it at boot.

Starting a Service

To start a service, use the service module and specify the service name along with the state=started parameter.

 # ansible webservers -m ansible.builtin.service -a "name=httpd state=started" -b

This command starts the Apache HTTP server (httpd) on all hosts in the webservers inventory group, using the -b flag to become a privileged user.

Stopping a Service

To stop a service, specify state=stopped.

 # ansible webservers -m ansible.builtin.service -a "name=httpd state=stopped" -b

This stops the Apache HTTP server on the target hosts.

Restarting a Service

To restart a service, use state=restarted.

 # ansible webservers -m ansible.builtin.service -a "name=httpd state=restarted" -b

This restarts the Apache HTTP server on the target hosts.

Checking the Status of a Service

To check if a service is running, you can use the service_facts module to gather service status information and then extract the desired service’s state.

 # ansible webservers -m ansible.builtin.service_facts

To see if a specific service like httpd is active, you can use:

 # ansible webservers -m ansible.builtin.command -a "systemctl is-active httpd"

Enabling a Service to Start on Boot

To enable a service to start on boot, use enabled=yes.

 # ansible webservers -m ansible.builtin.service -a "name=httpd enabled=yes" -b

This ensures the Apache HTTP server is enabled to start automatically when the system boots.

Disabling a Service from Starting on Boot

To disable a service from starting on boot, use enabled=no.

 # ansible webservers -m ansible.builtin.service -a "name=httpd enabled=no" -b

This prevents the Apache HTTP server from starting automatically at boot.

Conclusion

The Ansible service module offers a clean and consistent way to manage system services. Whether you’re working with Systemd or legacy init systems, this module helps you:

  • Start/stop services
  • Enable/disable services on boot
  • Restart/reload services after changes

When combined with ad-hoc commands and handlers, it brings full automation to service lifecycle management. For finer-grained control on Systemd-only systems, consider using the systemd module instead.

FAQs

1. Can I use the service module to reload a service?

Yes, use the state: reloaded parameter to reload a service's configuration without a full restart, if the service supports reloading.

2. Can I manage services on non-systemd servers with the service module?

Yes, the service module can manage services on non-systemd servers, such as those using init.d or upstart, based on the service management system available.

3. How can I ensure a service is both started and enabled at boot?

Use the service module with state: started and enabled: yes to start the service and configure it to start on boot.

4. What should I do if the service fails to start using the Ansible service module?

Use the failed_when or ignore_errors parameters to handle failure conditions, and check the service logs for more information.

About Hitesh Jethva

Experienced Technical writer, DevOps professional with a demonstrated history of working in the information technology and services industry. Skilled in Game server hosting, AWS, Jenkins, Ansible, Docker, Kubernetes, Web server, Security, Proxy, Iptables, Linux System Administration, Domain Name System (DNS), and Technical Writing.

View all posts by Hitesh Jethva