Ansible – Looking at commands & Playbooks (Raspberry Pi)

With Ansible installed and connections to other devices set up, it is now time to have some fun and start using Ansible.

For this project I am using a Raspberry Pi 3 running Raspbian OS (Buster) with Ansible installed and two Raspberry Pi Zero Ws running Raspbian OS (Buster). The two previous blog entries discussed installing Ansible, the Ansible inventory (hosts file) and setting up SSH connections so that Ansible can talk to other devices.

The two Raspberry Pi Zero Ws are stored in a group called Pi_Collection within the Ansible inventory. When I’m running commands against Pi_Collection they should go to both Pi Zeros. Although I’m only controlling 2 devices Ansible should be able to scale up against many devices.

Singular Commands

Ansible can be used with modules, ad-hoc commands and playbooks. First I am going to look at some singular commands that may be useful for controlling multiple devices.

Ping

The first command I tested with Ansible was the ping command:

ansible Pi_Collection -m ping

Breaking down this command:

ansible calls the ansible program.

Pi_Collection tells ansible that it should be talking to the group with that name.

-m tells ansible that I’m about to use a module.

ping tells ansible that I want to use the module called ping.

Apt Update

ansible Pi_Collection -a “apt update” -b

Breaking down this command:

-a tells ansible that I am sending an ad-hoc command.

“apt update” is the command I want to send.

-b tells ansible to use “become” to change roles/users, as I’ve not defined what to become it will become the default.

As you can see this interacts successfully with the Pi Zeros and reports back that 27 packages can be upgraded.

Apt List

ansible Pi_Collection -a “apt list –upgradable” -b

This command is very similar to the “apt update” command above but outputs all the packages on the device that could be upgraded.

Shut Down

ansible Pi_Collection -a “shutdown” -b

As with the above commands this is sending an ad-hoc command to the devices to shutdown using the regular Raspbian shutdown command. Instead of a shutdown I could have used “reboot” to have rebooted the devices.

Playbooks

Ad-Hoc commands are great for accomplishing small tasks, however if large (or more complicated) tasks are needed then it is time to create an ansible playbook. Playbooks are in YAML format and contain plays, which contains tasks (they run sequentially) and the tasks call on modules.

The first playbook I am looking to create and use will be to turn my Pi Zeros into Apache web servers. I’ve called this playbook “apache.yml”.

The first line is a comment, just to explain what the playbooks aim is.

The second line (-hosts) is what I am aiming the playbook at.

The third line is the beginning of the tasks. The tasks have a name (this will display when the playbook runs), and then some options including the become option which I use once with the default settings and once to become root.

For the apache2 install I am calling apt to check that the package (pkg) apache2 is present, if it is not present then Ansible will ask apt to install it.

For the apache2 service I am asking ansible to start the service and make sure it is enabled at start-up using the root account.

The playbook was saved into my home directory and then ran using:

ansible-playbook apache.yml

The playbook starts by gathering facts (e.g. making sure the devices in Pi_Collection are available) and then starts the tasks.

After a few moments (longer depending on the complexity of the playbook and/or the systems it is running on) ansible should output a play recap. Green means good and orange means a change has taken place. In the above image Apache was installed but the service did not need to be set to start.

If the same playbook is replayed:

Then all is ok (green) as the systems are online (1), already have apache installed (2) and have the apache service running (3) giving the play recap an ok of 3.