Ansible Playbooks
In the last post about executing commands via ansible, it showed how easy it was to run commands on remote systems. If you want to change files or similar in the remote clients this becomes a lot harder using only raw or command or shell modules. For this reason you can create playbooks. It kind of reminds me of when you do things on command line and then realise that tasks that are repetitive you start to use scripts. I see the difference between executing commands and creating playbooks to be quite similar.
Example 1:
So below I want to create a playbook and show how to build it up and execute tasks in different ways using a playbook. Ansible playbooks are usually written in the YAML format. The first example below here is basically checking if the ntp demon (chrony) is running on the CentOS hosts.
The three lines on top specifies that the file is a YAML file and should be treated as such.
The hosts line specifies which hosts it should be run against. Here you should recognise the fact that we have been running everything against the CentOS group so far.
Next we start the tasks session, which is where we tell ansible what it should do when connecting to each host. First we have a name section, this section is what you will see below as the task description and is important for the user. Then we have the task that is carried out.
In this case, since it is against CentOS boxes, we use yum to check if chrony is installed. (In CentOS 8 the ntpd has been retired).
In the second part of the tasks we check that the service is running and is enabled on startup. When executing the playbook it looks like this:
As you can see all is “green”, everything is ok. One thing to notice is that before running the tasks ansible gathers facts about the client where it is about to execute the task. This is a normal thing for ansible where it tries to find out as much as possible about the system. Next it checks if ntp is Installed, and secondly if it us running. If it is all successful then you get an OK below. Else you get errors and warnings and it is color coded, as you can see below where I removed the “become: yes”. We get an error that says we need to run it as root user.
Example 2:
Another example of using Ansible is to use it to install packages. In the below we install the apache httpd daemon using the command module, where we used the yum module above to check if the ntp package was installed. So here is the working file
In line 7 the command module is used to install httpd and httpd-devel packages.
In line 9 and 10 the httpd service is started and enabled for start on boot.
In line 12 the service is verified as started.
The outcome of the run is here:
The difference from the file above with chrony is that here we are installing something and you can see that there are changes made to each of the two CentOS boxes. Also we can see that the changes are ok. and that the service is running. Potentially the missing things here is to open the firewall. So lets edit the file and open the firewall on port 80 for the two servers.
So now the file looks like this:
You can see that the lines 13-22 are new.
I wanted to add one thing here, the above will not open the ports. For that you need to enable the firewall change immediately, this requires one extra paratmer:
When running it we see that again commands are changed.
Everything runs ok and there are changes to the configuration.
This was kinda intended to show a little bit more about what you can do. Again make use of the modules to perform things and the possibilities are almost endless. The documentation really is amazingly good.
we can also clean up the setup we have done here. This is done by removing the packages and their dependencies and also close the firewall ports again.
The script for this looks like this.
Probably the main difference is that we use the service command of the firewalld to close the firewall again. Else the script should seem fairly familiar by now.
Here is the run of the job:
Example 3:
In this example I want to demonstrate another useful operational feature of Ansible. When you have to patch your linux hosts you can of course use ansible for this task. It should be quite simple really in comparison to the above. For this case I installed a third CentOS machine, aocanscl05. First here is the YAML file:
As you can see it is really simple. You could add a second task to reboot it also but we aren’t working with Windows so lets leave that out for now.
The result of running the file for the first two CentOS boxes are here and as you can see, there were no updates for them. You can see it ran, it connected but there were no changes (for this reason the new CentOS box).
Now after adding the third CentOS machine and copying the ssh key etc and running the example005.yml again it looks a bit different (Also it takes a bit longer because it has to run through 400 packages unlike all the other examples so far).
Now we see that aocanscl05 is ok also, we got prompted for the new key pairing and then the patching section made changes to 05. We see the recap reflects that all was executed ok and one box was changed. There were no errors.
That’s about it for this post.