Tip 7: Configuration

Hard-line system administrators are used to having exactly one configuration file for central services. They unconsciously transfer this principle to Ansible, leading them to assume that there is only one /etc/ansible/ansible.cfg that sets the configuration for all Ansible calls on the system. I have already shown that this cannot be true. An ansible.cfg created to replace the logging component and stored in the folder with the ansible call is a place where the automation engineer will definitely see it.

The urgent appeal here is: If you want to influence the behavior of Ansible, it is best to use the options available for doing so in ansible.cfg. In addition to the folder from which an Ansible call is made, the tool also searches for configuration parameters in ~/.ansible.cfg, among other places. If you do not follow this advice, things can quickly turn nasty.

In the wild, you sometimes encounter playbooks and roles with bloated code designed to work around shortcomings in the Ansible configuration. The argument that this is at least independent of the system and works the same way everywhere does not hold water. It would be just as easy to deliver a local ansible.cfg.

Tip 8: Reusable Code

When dealing with Ansible, you regularly see a problem with roles or playbooks for specific services not existing in Ansible itself. For example, if you want to roll out PowerDNS, you will not find any preparations for this in Ansible out of the box. In this situation, inexperienced administrators turn to radical measures and start writing a role for deploying the service themselves.

As experience shows, there is no lack of justifications for this questionable step. You often hear that a role for your own company is tailor-made and perfectly adapted to the conditions onsite. Here is where the mantra of the customized IT solution probably plays tricks on many administrators. Salespeople have been using this approach for decades to catch customers, only to end up selling them off-the-shelf solutions again – in the best case scenario. In the worst case scenario, they ensnare their clients in expensive, lengthy development contracts in the scope of these projects, and often enough the projects end up in a glaring fireball. Where failed projects do this on a large scale, Ansible can – on a smaller scale – trick unwary admins into trying to reinvent the wheel for individual programs.

Admins are likely to be frustrated to discover that rolling out PowerDNS automatically it is not that simple. Depending on the target system and distribution version, different packages with different configurations need to be installed, which means you need matching switches in Ansible. The automation tool itself can do this without any problems; after all, the tool has an if directive. You can use several variables from the Ansible inventory to find out which OS and which OS versions are available. It's a similar thing when you need to fill different templates with content.

The problems don't stop there, though. Depending on the service required, various steps need to be processed in a specific order and potentially across system boundaries. You need to implement, test, and possibly debug the setup. If only one admin or a small group of admins are working on this development, finalizing a workable Ansible role will drag on interminably in the worst case.

A word of advice: If you are looking for an Ansible role for a specific program, first check out repositories such as GitHub or Ansible Galaxy to see if a solution already exists. Although it might contain a mass of code that you do not need for the local system, on the upside, it has been tested and curated by the open source community and will typically be fully functional, for the most part.

Tip 9: Encryption

You might find this difficult to believe, but even in 2023 you will still find Ansible implementations that store passwords in plain text. The administrators involved really can't be serious. On the one hand, it makes it effectively impossible to maintain the Ansible infrastructure in a (publicly accessible) Git directory – after all, no one wants to have their passwords for internal services posted on the web. On the other hand, passwords in plain text in files on the system should be completely unacceptable in any scenario.

Ansible provides a tool called ansible-vault that can be used to work around the password problem in a smart way (Figure 4). Ansible Vault should not be confused with its namesake by HashiCorp, but if you prefer to use HashiCorp Vault with Ansible, you certainly have the option of doing so with the Ansible hashi_vault function, which reads passwords from a HashiCorp Vault.

Figure 4: Ansible Vault provides a convenient approach to managing passwords reliably and securely within the automation tool. © Martin Loschwitz