Introduction - An Overview of the Ansible Syntax

In this post, we will be discussing how to use various built-in modules to accomplish commonplace system tasks. Nothing crazy - the main point of this post is to demonstrate, using an Ubuntu VM, how easy Ansible playbooks are to use. At least, at a beginner’s level. Something to note is that I assume you will be using some kind of text editor for your .yml files, which is the filetype that Ansible playbooks can be run within. The general CLI syntax for running an Ansible command is as follows: ansible-playbook -i hostnamehere playbooknamehere.yml

For Ansible playbooks, there are a number of things to keep in mind, For starters, you will need to specify hosts upon which your Ansible Playbook commands will be run against. For the purpose of this demonstration, I will use the host localhost to run commands (you guessed it) on my local Ubuntu VM. There are numerous reasons why you may want to use differnet hosts, but in this tutorial, we are primarily concerned with demonstrating the syntax that Ansible uses.

For starters, every playbook you will ever write starts with three dashes, and you will specify the hosts and tasks you want the playbook to perform. Here’s an example.

Notice the hyphen/dash behind hosts. This hyphen/dash is used to specify list items, put simply. Don’t let it scare you -it’s just a syntax thing! Also notice become: yes below hosts. This is essentially granting this playbook sudo permissions. Let’s keep it as simple as that for now. Depending on what you plan to achieve with Ansible, you may require sudo permissions, and become: yes allows your playbook to run to its full potential and become generall uninhibited. It is a good idea to keep this right under hosts for this early testing phase.

Ansible Task Explanation

Let’s discuss the meat and potatoes of Ansible playbooks: tasks. We are going to start with installing Apache while also enabling Apache modules, and then restart Apache when changes are made so that these changes can be applied. Let’s show you a picture of what this looks like.

Let’s start with explaining what the first task Install Apache really does. Since we are running this playbook in an Ubuntu environment, we use the apt function to install a program, in this case apache2 (note: there is essentially no difference between apache and apache2, other than that Ubuntu calls it Apache2. source ).

We want to update our cache, so we say update_cache=yes. Not much to explain there. However, under the state field, we specify state=present. This is a useful state to run this installation in. It is important to understand that you may be running this Ansible playbook many times, both for testing purposes as well as for actual use across different machines. With this in mind, we only want to install Apache2 IF it has not been installed yet - thus, if a present installation is found of this service, state=present ensures you will save a little time by checking whether the program you are installing using apt is there, and if it is, then it will not install the program again.

Similar syntax follows below in the picture above. There is not much to explain here, other than that apache2_module is how you enable modules, and the name=xyz is the module you wish to enable for Apache. State works the same way as described above.

The notify: and handlers portion of all of this is very important to understand. When any program is updated, regardless of whether it is Apache or not, you should restart the application as a general rule of thumb. The notify tag essentially triggers when changes are made, and can be made to display whatever text you want. (In this case, we are stating that we are restarting apache2). The handlers section is where the magic happens. Since in this playbook we are modifying apache2 by enabling modules, we should restart it in the handlers: section by running a service command. As shown above, the service’s name is apache2 and the state we want it to enter is restarted. This restarts apache2 when any changes are made, and only if changes are made. The state=present enabling of the modules above helps us in this regard, as explained above.

Checking if Apache Modules Were Enabled

Of course, whenever you use an Ansible playbook, you should always check if your changes to the system were successful. (in this case we are workign with a fully completed playbook that installs and configures apache, but HOPEFULLY you will be running this playbook after each change and verifying it worked as necessary AS you work instead of ALL AT ONCE at the very end of writing the playbook…) In this case, we need to check if the Apache modules we enabled were indeed enabled at all.

The picture above illustrates what output apache2 help produces. We are interested in the -t -D DUMP_MODULES option, so we will now type apache2ctl -t -D DUMP_MODULES to display a list of enabled modules.

If you look reeaaaally closely, this outputs what we expect - the loaded modules include headers, expires, macro and rewrite.

Now of course, we really are just scratching the surface of what is possible with Ansible. However, hopefully this gives you a look at the basic functions of Ansible and how one might use it at a very rudimentary level. Thanks for tagging along if you made it this far!