Ansible Automation Best Practices for Production

Ansible can be used to automate IT infrastructure and DevOps tasks. Because of its flexible and modular architecture, we can implement large, complex automation use cases using Ansible. But at the same time, we need to keep the simplicity and reusability of the automation artifacts and methods.

In this chapter, you will learn about the important and well-known best practices for implementing efficient automation solutions.

First, you will learn how to organize the playbooks, roles, collections, and inventories in an Ansible project. After that, we will discuss the best practices for storing managed node information in the inventory and different methods for storing and maintaining multiple inventories. You can store the remote nodes separately based on their function, criticality, or location; these details will be explained in the upcoming sections.

You will also learn about the most efficient ways to store the variables...

Technical requirements

You will need the following technical requirements to complete this chapter:

• A Linux machine for the Ansible control node.
• One or more Linux machines as managed nodes with Red Hat repositories configured (if you are using non-RHEL machines, then make sure you have the appropriate repositories configured to get packages and updates).

All the Ansible artifacts, Ansible playbooks, commands, and snippets for this chapter can be found in this book’s GitHub repository at https://github.com/PacktPublishing/Ansible-for-Real-life-Automation/tree/main/Chapter-16.

Organizing Ansible automation content

In Chapter 4, Exploring Collaboration in Automation Development, you learned about version control systems (VCSs) and source control management (SCM) and how to use GitHub services to store Ansible artifacts.

It is the best practice to create project-specific directories (that is, repositories) to keep all related items at a single location, such as project-specific ansible.cfg files, playbooks, roles, collections, or libraries. If there are external roles or collections dependencies, then mention the details inside the requirements.yaml (or requirements.yml) file.

Use the tree command in Linux to list the directories and files recursively and understand the structure of the directory’s content. A sample project directory can be organized like so:

Figure 16.1 – Typical Ansible project directory

Your roles will be under the roles directory, as shown in the following screenshot:

...

Storing remote host information – inventory best practices

Managed nodes or remote host information is critical data in Ansible automation since, without the proper host details, Ansible will not be able to execute the automation tasks. You learned about the Ansible inventory and its basic details in Chapter 1, Ansible Automation – Introduction. In Chapter 4, Exploring Collaboration in Automation Development, you learned about the importance of storing an inventory in a GitHub repository for version control and better management. If your managed nodes are hosted in cloud platforms, then it is a best practice to use Ansible dynamic inventories, as you learned in Chapter 5, Expanding Your Automation Landscape.

Using meaningful hostnames

When you create your Ansible static inventory files, use meaningful and user-friendly names for your managed nodes instead of complex Fully Qualified Domain Names (FQDNs) or IP addresses. It will help you while executing the Ansible...

Ansible host variables and group variables

As you learned previously, like many other automation tools, Ansible allows you to use variables for dynamically executing playbooks. It is possible to configure the same playbook so that it can be executed for different desired states using variables and values. We can keep the variables inside the playbooks, external variable files, inventory files, and many other places. You learned more about variables in Chapter 6, Automating Microsoft Windows and Network Devices.

The same variable can be specified in multiple places but depending on the location of your variable and variable precedence, Ansible will apply the appropriate value for the variable.

Ansible uses the appropriate variable values and executes the playbooks based on them; the following diagram shows the typical flow where Ansible combines the variable values with the playbook:

Figure 16.9 – Ansible combines playbooks and variables for the final...

Ansible credentials best practices

Ansible supports multiple credentials and authentication methods, such as username and password, SSH keys, API tokens, webhooks, and even the ability to create custom credentials. You should use a simple authentication mechanism as a starting point, but you need to consider the best practices to ensure security and safety are in place.

Avoid using default admin user accounts

It is common for engineers to configure the default administrator accounts as a remote_user such as root in Linux or as an administrator in Microsoft Windows. This is not a best practice; you should create dedicated accounts for Ansible and configure them for managed nodes.

Split the login credentials for environments and nodes

In the previous examples, you created user accounts in Linux and Microsoft Windows for Ansible to log in and execute tasks. It is possible to create the same user account for all of your nodes, but this is not required or recommended. It is...

Ansible playbook best practices

It is important to develop your Ansible playbooks with reader-friendliness and reusability in mind. Since the YAML format is human readable, it is easy to develop and follow some style guides for your Ansible playbooks.

In Chapter 15, Using Raw Commands for Network Operations, you learned when to use the raw module and commands. Always check the documentation and see if there are modules available for your task. The command, shell, raw, and script modules can be used if no suitable modules are available for the task. But always keep in mind that the command, shell, raw, and script modules are not idempotent and will always report as changed when executed.

Always give your tasks names

Even though the name parameter is an optional component, it is a best practice to provide an appropriate and meaningful name for the plays, tasks, blocks, and other components in your Ansible playbooks. Refer to Figure 16.22, where you can see the sample names that...

Summary

In this chapter, you learned about some of the best practices that can be implemented in your Ansible development workflow. You explored the best practices for organizing Ansible artifacts, including playbooks, roles, variables, inventories, and other Ansible content. Then, you learned about the importance of storing the inventory separately based on the managed node environment, criticality, and other facts. You also learned how to use host variables and group variables to organize variables.

After that, you learned about some of the best practices for storing and managing credentials in Ansible, such as avoiding plain text passwords and separating secrets from regular variable files. Finally, you learned about the different best practices and optimization techniques for improving the efficiency of Ansible playbooks. Refer to the Further reading section to learn more about Ansible best practices.

Congratulations! With this chapter, you have reached the end of this book...

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

• Reusing Ansible artifacts (Include and Import): https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse.html#playbooks-reuse
• Ansible tips and tricks: https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html
• Ansible Best Practices (Presentation Deck archive): https://aap2.demoredhat.com/decks/ansible_best_practices.pdf
• 10 habits of great Ansible users: https://www.redhat.com/sysadmin/10-great-ansible-practices