New and improved playbook

As for the actual playbook itself, it can now be simplified to just the following:

Figure 8.21 – Ansible playbook leveraging roles

Note

Notice that we are not listing out the base_software and groups roles in the playbook as these are dependencies we have defined under the meta directories.

As you can see, instead of tasks, we are now simply referencing roles. It is very neat and organized, and much easier to understand what the playbook is set out to do. If you want to understand what a specific role does, all you need to do is look into the roles directory for the name of the respective role and examine the main.yml file in the role’s tasks folder.

When you’re ready, run the playbook just as you normally would:

$ ansib
le-playbook playbook.yml

If all went well, it should have accomplished everything that was being done in our original playbook; however, this time around we are using Ansible roles, and thus our playbook will be far easier to maintain going forward.

The source code for this recipe can be found at https://github.com/PacktPublishing/Oracle-Linux-Cookbook/tree/main/ch8/ansible-roles.

Managing secrets with Ansible Vault

This recipe aims to provide guidance on leveraging Ansible Vault for secrets management.

There are multiple ways to store secrets in Ansible. When starting out, you may be inclined to encrypt the entire hosts file. This works and keeps everything secure in the context of using a version control system without compromising your secrets/passwords; however, it is not manageable, nor does it provide any useful information in version control systems because all you’re left with is a long nonsensical string of encrypted characters.

Getting started

You will need the following for this recipe:

• Oracle Linux
• Ansible

Refer to the Technical requirements section at the beginning of this chapter if you need help installing Ansible.

How to do it…

First, let’s take a look at whole-file encryption. To begin, we’ll first need to define our Ansible host file in plain text.

Whole-file encryption

Typically, an Ansible hosts file will look something like this:
# hosts
[host1]
192.168.2.70
[host1:vars]
ansible_user=admin
ansible_password=B@by-Y0dA
ansible_connection=ssh
ansible_shell_type=powershell
[host2]
192.168.2.71
[host2:vars]
ansible_user=admin
ansible_password=B@by-Y0dA
ansible_connection=ssh
ansible_shell_type=powershell

You can encrypt the file by running the following into the terminal/console:

$ ansible-vault encrypt hosts –ask-vault-pass
New Vault password:
Confirm New Vault password:
Encryption successful

I am using a randomly generated string as my vault password.

Another way to encrypt the file is to use a vault password file so you don’t have to input the password every time you need to encrypt/decrypt something. To do this, create a file named vault_password and paste only the vault password into it.

Note

It’s a good idea to set the permissions to 0600 on the vault_password file (this can be done by running chmod 0600 ./vault_password) so it’s protected from other users.

Now, instead of using –ask-vault-pass, you can use the following:

$ ansible-vault encrypt hosts –vault-password-file vault_password
Encryption successful

Cool! Just be sure to add the vault_password file to your .gitignore list to avoid checking that into version control.

Now if you cat your hosts file, you will see the contents are encrypted:

Figure 8.22 – Contents of encrypted “hosts” file

This is great, but anytime you need to make changes to the hosts file, you are faced with two options:

• Decrypt the hosts file, make your changes, then encrypt it again
• Use ansible-vault edit hosts to leverage ansible-vault’s vim mode to edit the file

These aren’t terrible options, but in practice this can become cumbersome. I propose a better way, which is to use the encrypt_string method within Ansible Vault to encrypt only the sensitive data, and use variables in place of passwords/secrets to reference those encrypted strings.