<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 https://www.facebook.com/tr?id=1063935717132479&amp;ev=PageView&amp;noscript=1 "> Bitovi Blog - UX and UI design, JavaScript and Front-end development
Loading

DevOps |

5 Best Practices to Simplify Ansible Playbooks

Using Ansible playbooks can be tricky! Check out these Ansible best practices to simplify your workflow and make using Ansible IaC even more convenient.

Phil Henning

Phil Henning

Twitter Reddit

Working with Ansible playbooks can be tricky. Whether you’re an expert or you’re new to the tool, you need to know the best practices to simplify Ansible playbooks.

In this post, we'll review the top 5 best practices that make working with Ansible IaC more convenient and your playbooks more scalable for your DevOps team!

1. Create Playbooks with Purpose

The first Ansible best practice is to create playbooks with a purpose. This drastically improves development time by providing developers with a blueprint for the intention of the playbook (name), and how the intention is achieved (content).

When both the name and content are in sync, developers will be able to easily parse through the playbook selections to find the one they need. This allows you to make changes with confidence because the context is contained in a single place. 

ansible-playbooks-name-content

Example

  • A need has arisen that requires a new yum module to be installed along with MySQL on fresh servers.
    • We have a MySQL.yaml playbook file that contains all of your MySQL content; let’s add it to the playbooks/ directory.

2. Smaller playbooks > Bigger playbooks = Better playbooks

Continuing on the topic of purpose, another Ansible best practice is to identify and break up grouped tasks that are "large" or time-consuming into their own playbooks.

Specialized playbooks support rapid development & testing as individual, small components of a playbook can be tested and tweaked quickly. By breaking up larger tasks into their own playbooks, you can work with the more cumbersome playbook tasks when it is convenient for you.

ansible-playbooks-name-content

Examples

  • A need has arisen that requires a new yum module to be installed along with MySQL on fresh servers.
    • We have a MySQL.yaml playbook file that contains all of your MySQL content, so let's add it to the playbooks/ directory, like before.

  • A new database is being added to the SeedDB step.
    • No problem, you can add the new database to the SeedDB.yaml playbook and run it at your next convenience if the seed takes a while, for example.

3. Using tags for granular control

The next Ansible best practice you need to know is using tags to specify custom runs! This trick is great for controlling playbooks and creating quick custom playbook pipelines in the CLI.

Using Ansible tags also enables rapid testing and development, as playbooks can be run either individually or within a subset of a playbook's normal run.

To accomplish this, you’ll need to create a top level playbook that will act as a manager for your specialized playbooks. For this example, you'll use a top level manager playbook called statics.yaml. This will install all "static" components onto a server and will also run dynamic tasks in between to prepare the server for usage. 

# file: main.yaml
# Static Content installed via Ansible

name: Statics
   hosts: all

#~#~#~#~# APACHE #~#~#~#~#
name: Apache
    import_playbook: statics/apache.yaml
    tags: apache
#~#~#~#~#~#~#~#~#~#~#~#~#

#~#~#~#~# MYSQL #~#~#~#~#
name: MySQL
    import_playbook: statics/mysql.yaml
    tags: mysql
#~#~#~#~#~#~#~#~#~#~#~#~#

#~#~#~#~# SEED DB #~#~#~#~#

name: Seed the DB
    import_playbook: dynamics/seeddb.yaml
    tags: seeddb

#~#~#~#~#~#~#~#~#~#~#~#~#

All of the specialized playbooks are added into your static's playbook as they normally are, and you tag them all with unique tags relevant to their playbook name. Now from the CLI, all that needs to be done is specifying the tag(s).

[root] $ ansible-playbook statics.yaml --tags=mysql,seeddb

This will run the statics.yaml playbook in a modified way in which only MySQL and SeedDB playbooks are acted on, thereby skipping the Apache playbook step at the beginning.

Examples

  • A new database is being added to the SeedDB step and you are being asked to run it on a new server.
    • No problem, you can add the new database to the SeedDB.yaml playbook and select which specialized playbook you'd like to run using tags:
[root] $ ansible-playbook statics.yaml --tags mysql,seeddb

  • A new database is being added to the SeedDB step and you are being asked to run it on an existing server.
    • No problem, you can add the new database to the SeedDB.yaml playbook and select which specialized playbook you'd like to run using tags:
[root] $ ansible-playbook statics.yaml --tags seeddb

4. Folder Structure Suggestions

It’s important to keep things organized. The next Ansible best practice is to keep a consistent folder structure.

One valuable way to approach folder structuring with Ansible is tool + thing + env. This structure utilizes an inner folder structure that will have Statics, which are components that should be installed during server creation, and dynamics, which are playbooks that can be run during or after creation.

The tool in this example is Ansible, so you would start your folder structure with that.

The thing is the project name, such as phoenix or unicorn.

The environment is just that, the environment. If your team uses a lower/upper environment context, then Dev/Prod distinction is all you need.

<tool>/<thing>/<env>

Ansible/        <-- Tool        
  Phoenix/      <-- Thing              
    Dev/        <-- Env                     
      Statics.yaml                     
      Dynamics.yaml                     
      Dynamics/                 <-- Dynamics can be run during and after creation                            
        task-that-runs-often.yaml                     
      Statics/                  <-- Statics are run once during server creation                           
        task-that-runs-once.yaml

The advantage of this pattern is that at a smaller scale, the grouping makes navigation for SREs/SysAdmins intuitive because the folder structure passively provides context to what is being worked on. Similar project IaC can be centralized into a single repository and made distinct through the projects name + tool.

5. Future planning: Scaling

The final Ansible best practice is to plan for the future. In short: as you work on today's problems, you should be cognizant of tomorrow's potential issues. By creating repeatable, context-driven IaC, you lessen the required workload for tomorrow by maintaining best practices today. Or, in other words, implementing good working habits will decrease the amount of daily tech debt.

Conclusion

Now that you know our 5 best practices for simplifying Ansible playbooks, you’re ready to go and do great things! These straightforward tricks will help organize your infrastructure and enforce best practices.

Need more help?

Looking for some help championing these best practices? Or possible some assistance maturing your team and tools? Book your free consult call to learn more!