The task I am doing today is very simple. So the importance is not in the task itself but the approach I am giving.
We know that ansible is used for configuration management. But there are cases when we have to manage the configuration management too. Let me explain by an example. Let’s say you have to installed several packages in the target nodes but after few months the company decides to change certain softwares. For example they decide for proxy servers they want to use haproxy in place nginx or change the location of certain files.
In complex playbooks this task can be tiring as well as prone to error. We might miss some keyword here and there which might crash the target nodes.
So to avoid this we can specify all the keywords in a separate variables file and when trying to mention the names of the keywords we mention the variables. This is much more easy to maintain since we only have to manage the names of keywords at one location and as long as we don’t have to edit the task we don’t even need to open the main configuration file. This makes our work easy as well as less prone to errors.
So today I would be giving a demonstration on how to do this by configuring a simple apache web server.
In today’s task I would be using one of the dynamic IP to be configured as web server.
Let’s have a look at the variables file.
Notice that all the data which we would have specified in the setup playbook is already defined in the variables file. Notice the name of the file RedHat.yml. I would tell the significance of the name as I tell about the playbook.
Ansible facts play an important role here. Usually there are scenarios where some of the commands or tasks are keyword specific to the OS at the target so when calling the vars_files I used the distribution of the target node.
How does it help?
By doing this there is an elimination of if conditions where we have to specify various keywords for different OS that might show up as target. In this case we can have different keywords and variables in the different variable files that can be explicitly managed without having to deal with the playbook.
So after running let’s see if the web server is configured or not in the target.
So the server is up and running.
Like I mentioned in the beginning the task I did has not that much of importance when compared to the approach I suggested. Using the variable files allow the easy management which I tried to show in the given task.