Ansible: Up and Running, 3rd Edition

Chapter 24. Best Practices

In this chapter, we propose a set of best practices as a conversation starter, knowing that best practices don’t transpose to other contexts very well. What works for Spotify or Netflix does not necessarily work for other companies. Our main goal is to get you thinking about these matters and discussing the ones that trigger your imagination or concern. The best practices are based on design principles and experience using Ansible in various settings. On the management level, we need to consider how practitioners perform and how to benchmark DevOps teams.

Simplicity, Modularity, and Composability

Michael DeHaan designed Ansible to automate the boring stuff in the simplest conceivable way because he wanted to spend his time doing more interesting things. Inexperienced users can now browse the Ansible Galaxy site for roles and collections to get something up and running within hours using Ansible.

Ever since DeHaan and Greg DeKoenigsberg started the Ansible community, they’ve been thinking and writing about best practices—the documentation, however, changed its terminology from “best practices” in 2.9 to “tips and tricks” in 2.10. They point out that open source projects are more likely to gain and keep contributors when they have two particular properties: high modularity and high option value. High modularity, or loose coupling, allows freedom to add to Ansible. High option value, also known as composability, allows you to pick and choose: you might ...