If a task within your playbook, for example, needs a value from the result of a preceding task, we can use the register attribute.
The following directory contains all the resources for exercises in this section:
$ cd ~/modern-devops/ch9/vars-exercise
Let’s look at the following example register.yaml file:
- hosts: webservers tasks:
- name: Get free space
command: free -m
register: free_space
ignore_errors: true - name: Print the free space from the previous task debug:
msg: “{{ free_space }}”
The playbook contains two tasks. The first task uses the command module to execute a command, free -m, and registers the result in the free_space variable. The subsequent task uses the previous task’s output using the debug module to print free_space as a message to the console.
Let’s run the playbook to see for ourselves:
$ ansible-playbook register.yaml
PLAY [webservers]
TASK [Gathering Facts] * ok: [web] TASK [Get free space] **
changed: [web]
TASK [Print the free space from the previous task] * ok: [web] => { “msg”: { free shared buff/cache available\nMem: 3.3G 170M 2.6G 2.2M 642M 3.0G\nSwap: 0B 0B 0B”, } PLAY RECAP **
web: ok=3 changed=1 unreachable=0 failed=0 skipped=0
rescued=0 ignored=0
Now that we’ve understood variables, let’s look at other aspects that will help us improve the last playbook.
Jinja2 templates
Ansible allows for templating files using dynamic Jinja2 templates. You can use the Python syntax within the file, starting with {{ and ending with }}. That will allow you to substitute variables during runtime and run complex computations on variables.
To understand this further, let’s modify the index.php file to supply the MySQL username and password dynamically during execution:
…
<?php
mysqli_connect(‘db’, ‘{{ mysql_user }}’, ‘{{ mysql_password }}’) or die(‘Could not connect the database : Username or password incorrect’);
echo ‘Database Connected successfully’;
?>
…
As we can see, instead of hardcoding the username and password, we can use templates to substitute the variable values during runtime. That will make the file more reusable and will fit multiple environments. Ansible provides another important aspect of coding reusability within your playbooks—Ansible roles. Let’s have a look at this in the next section.
Ansible roles
Well, the last playbook looks a bit cluttered. You have a lot of files within it, and none of them are reusable. The code we’ve written can only set up the configuration in a particular way. This may work fine for smaller teams with limited configurations to manage, but it is not as simple as it looks for most enterprises.
Ansible roles help to standardize an Ansible setup and promote reusability. With roles, you can automatically load var files, handlers, tasks, and other Ansible artifacts using a standard directory structure relative to your playbooks. The directory structure is as follows:
.yaml
roles/
/
tasks/
handlers/
library/
files/
templates/
vars/
defaults/
meta/
The roles directory contains multiple subdirectories for each role. Each role directory contains multiple standard directories:
• tasks: This directory contains a list of tasks’ YAML files. It should contain a file calledmain. yaml (or main.yml or main), containing an entire list of tasks or importing tasks from other files within the directory.
• handlers: This directory contains a list of handlers associated with the role within a file called main.yaml.
• library: This directory contains Python modules that can be used with the role.
• files: This directory contains all files that we require for our configuration.
• templates: This directory contains the Jinja2 templates that the role deploys.
• vars: This directory contains amain.yaml file with a list of variables associated with the role.
• defaults: This directory contains amain.yaml file containing the default variables associated with the role that can be easily overridden by any other variable that includes inventory variables.
• meta: This directory contains the metadata and dependencies associated with the role within a main.yaml file.
Some best practices revolve around managing your Ansible configuration through the folder structure.
Let’s look at some of these next.
Leave a Reply