Rectifying the challenge of ‘Restarting HTTPD Service is not idempotence in nature’ using Ansible playbook
So before we start with the solution part let’s have a look at what is ansible and httpd server and what they do for us…
Designed for multi-tier deployments since day one, Ansible models your IT infrastructure by describing how all of your systems inter-relate, rather than just managing one system at a time.
It uses no agents and no additional custom security infrastructure, so it’s easy to deploy — and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English.
Ansible works by connecting to your nodes and pushing out small programs, called “Ansible modules” to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules (over SSH by default), and removes them when finished.
About Apache HTTPD Server
The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
When Apache is running under Unix, its process name is
httpd, which is short for "HTTP daemon".
Apache supports a variety of features, many implemented as compiled modules which extend the core functionality. These can range from authentication schemes to supporting server-side programming languages such as Perl, Python, Tcl and PHP. Popular authentication modules include mod_access, mod_auth, mod_digest, and mod_auth_digest, the successor to mod_digest. A sample of other features include Secure Sockets Layer and Transport Layer Security support, a proxy module, a URL rewriting module, custom log files, and filtering support.
Idempotency in Ansible
Idempotence is “the property of certain operations in mathematics and computer science that can be applied multiple times without changing the result beyond the initial application”. For Ansible it means after 1 run of a playbook to set things to a desired state, further runs of the same playbook should result in 0 changes. In simplest terms, idempotency means you can be sure of a consistent state in your environment.
Now, this is the ansible code for installing httpd server and activating it’s services
After running the playbook
Running the same playbook for the second time
Now as we can see, the service task changed state and again restarted i.e this task doesn’t support idempotence. As it doesn’t support idempotence, it will restart every time we execute a playbook and thus will consumes more system resources. So here we will find a way in this blog to overcome this challenge.
Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses Handlers to address this use case. Handlers are tasks that only run when notified. By default, handlers run after all the tasks in a particular play have been completed. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts.
Changed code after using Hnadlers:
Now let’s run the playbook
So now our handler will only run when any change is made on config file which we have used in template module and notify keyword used with template module will notify to handler if any if change is made or not.
Let us again run the playbook without making any changes
So here this time handler won’t run as no changes are made. And thus we rectified the challenge of ‘Restarting HTTPD Service is not idempotence in nature’.