Handlers in Ansible

Task 11.3 : Restarting HTTPD Service is not idempotence in nature and also consume more resources suggest a way to rectify this challenge in Ansible playbook.

Ansible’s Features and Capabilities

1. Configuration Management

Ansible is designed to be very simple, reliable, and consistent for configuration management. If you’re already in IT, you can get up and running with it very quickly. Ansible configurations are simple data descriptions of infrastructure and are both readable by humans and parsable by machines. All you need to start managing systems is a password or an SSH (Secure Socket Shell, a network protocol) key. An example of how easy Ansible makes configuration management: If you want to install an updated version of a specific type of software on all the machines in your enterprise, all you have to do is write out all the IP addresses of the nodes (also called remote hosts) and write an Ansible playbook to install it on all the nodes, then run the playbook from your control machine.

2. Application Deployment

Ansible lets you quickly and easily deploy multitier apps. You won’t need to write custom code to automate your systems; you list the tasks required to be done by writing a playbook, and Ansible will figure out how to get your systems to the state you want them to be in. In other words, you won’t have to configure the applications on every machine manually. When you run a playbook from your control machine, Ansible uses SSH to communicate with the remote hosts and run all the commands (tasks).

3. Orchestration

As the name suggests, orchestration involves bringing different elements into a beautifully run whole operation — similar to the way a musical conductor brings the notes produced by all the different instruments into a cohesive artistic work. For example, with application deployment, you need to manage not just the front-end and backend services but the databases, networks, storage, and so on. You also need to make sure that all the tasks are handled in the proper order. Ansible uses automated workflows, provisioning, and more to make orchestrating tasks easy. And once you’ve defined your infrastructure using the Ansible playbooks, you can use that same orchestration wherever you need to, thanks to the portability of Ansible playbooks.

4. Security and Compliance

As with application deployment, sitewide security policies (such as firewall rules or locking down users) can be implemented along with other automated processes. If you configure the security details on the control machine and run the associated playbook, all the remote hosts will automatically be updated with those details. That means you won’t need to monitor each machine for security compliance continually manually. And for extra security, an admin’s user ID and password aren’t retrievable in plain text on Ansible.

5. Cloud Provisioning

The first step in automating your applications’ life cycle is automating the provisioning of your infrastructure. With Ansible, you can provision cloud platforms, virtualized hosts, network devices, and bare-metal servers.

About Idempotency

Idempotence is a term given to certain operations in mathematics and computer science whereby:

an action which, when performed multiple times, has no further effect on its subject after the first time it is performed.

About Handlers

Ansible handlers have same contents as a task can have.

But few points should be noted and remembered while using notify and handlers, otherwise you might not get desired results:

• Name of a handler should be unique and this is used for calling it by notifier.
• A handler is called at the end of playbook by default, so even if a handler is notified multiple times, the tasks under handler will only run once. Also, this is only when one of the calling tasks have state changed.
• If two handlers have the same name, only the one will run. Which is defined later in playbook.
• You can mention a variable in handler’s tasks section. But avoid using variables in name of a handler. As handler names are templated early on.
• We can use listen with mentioning topics when need to call multiple handlers by single notify.
• Handler’s name and listen topics live in global namespace.
• Handlers will always run in same order in which handlers are defined and they run only once if one of the calling tasks have state change. Handlers don’t run in the order of notify. Same case is with those handlers which used listen topic.

If state of a task is not changed, then attached notify will not call handler.

Lets get started with the task

First we install and configure the config and inventory of ansible.

We check the hosts list and ping them to confirm the connection.

Let’s have a look at the playbook:

GitHub URL: arth/apache server with handler at main · gursimarh/arth (github.com)

Here in this playbook , we need to install the ansible.posix.selinux collection. We do so by the following command:

ansible-galaxy collection install ansible.posix

It used to configure the SELinux like enabling and disabling it.

We store all the variables used in the playbook in the myvar.yml file.

Now, we check the syntax of the playbook using the command:

ansible-playbook --syntax-check server.yml

Finally, we run the playbook

We can confirm the services are running by logging into the hosts.

Now, if we run the playbook again, it shows that the service is started so no need the restart it. This become possible because of the handlers and notify keywords in ansible.

We can modify the myvar.yml file and run the playbook again.

We can use the curl command or simply open the page in the browser and confirm if the service is running.