We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies.

We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies. Less

We use cookies and other tracking technologies... More

Login or register
to publish this job!

Login or register
to save this job!

Login or register
to save interesting jobs!

Login or register
to get access to all your job applications!

Login or register to start contributing with an article!

Login or register
to see more jobs from this company!

Login or register
to boost this post!

Show some love to the author of this blog by giving their post some rocket fuel πŸš€.

Login or register to search for your ideal job!

Login or register to start working on this issue!

Login or register
to save articles!

Login to see the application

Engineers who find a new job through WorksHub average a 15% increase in salary πŸš€

You will be redirected back to this page right after signin

Blog hero image

Ansible File Structure, destructured

Azeez Lukman 11 October, 2021 | 3 min read

The big question, Is there a recommended way to structure Ansible projects?

Well, Ansible doesn’t have enforce patterns on how you put files into folders. But there are a few common approaches popular in the ecosystem you may want to consider. This guides walks you through.

Keeping it simple πŸ˜‰

A pattern recommended though is to keep things as simple as you can, do things simply. Use advanced features only when necessary, if it begins to feel complex for the task, then it's probably complex. The documentation asks you to take the time to look for a simpler solution.

Look no further, one solution is to start with the minimum pattern that is easy to build upon when you need to, and that is what this article is all about.

A typical Ansible file-structure

Keep your files organized in your working Ansible project directory like this:

...
ansible
	β”œβ”€β”€ ansible.cfg
	β”œβ”€β”€ first_playbook.yml
	β”œβ”€β”€ inventory
	β”œβ”€β”€ group_vars
	β”‚Β Β  β”œβ”€β”€ vyos.yml
	β”‚Β Β  └── eos.yml
	β”œβ”€β”€ roles
	β”‚Β Β  β”œβ”€β”€ static_route
	β”‚Β Β  └── system
	β”œβ”€β”€ second_playbook.yml
	└── third_playbook.yml

With this you can expand your inventory and create and run more network playbooks, let's destructure all these and what goes into them.

Ansible.cfg

This is the ansible config file, commonly referred to as the brain and the heart of Ansible. It is file that defines Ansible config, and is responsible for how all processes in Ansible functions.

By default Ansible reads its configuration file in /etc/ansible/ansible.cfg, however this behavior can be altered. The recommended practice is either to have an ansible.cfg in your current project working directory or to set it as an environment variable.

Playbooks

Ansible Playbooks are way to automate deployment tasks by using a repeatable, re-usable, simple configuration management and multi-platform deployment system.

Each playbook contains one or more plays and each play defines the managed nodes to target and runs one or tasks on it. Each task calls an Ansible module. When you run a playbook, the plays are executed sequentially, play by play and each play also executes it's tasks sequentially from top to bottom.

Ansible lets you define more than one playbook with each paybook focused on one function, you can have one playbook to create your deployment and another one to destroy it. Our example structure show firstplaybook.yml, secondplaybook.yml and third_playbook.yml.

Join our newsletter
Join over 111,000 others and get access to exclusive content, job opportunities and more!

Inventory

The Ansible inventory file defines the groups of hosts, commands, modules, and tasks a playbook can operate on. It functions as a list of managed nodes. An inventory can specify information like IP address for each managed node, you can designate different servers into groups like webservers, or databases

Group_vars

Ansible uses a combination of a hosts file and a groupvars directory to pull variables per host group and run Ansible plays/tasks against hosts. groupvars/all is used to set variables that will be used for every host that Ansible is ran against.

The group_vars in Ansible are a convenient way to apply variables to multiple hosts at once, they also provide a pattern for the reusability of group variables, saving you efforts to sort the hosts and also enhance the flexibility in your code.

Roles

Roles allows to easily reuse your grouped content, One way to use roles is with the roles option for a play, then ansible follow your file structure and the order listed below to execute the role and replace the play task with its values.

  • AnyΒ pre_tasksΒ defined in the play.
  • Any handlers triggered by pre_tasks.
  • Each role listed inΒ roles:, in the order listed. Any role dependencies defined in the role’sΒ meta/main.ymlΒ run first, subject to tag filtering and conditionals.
  • AnyΒ tasksΒ defined in the play.
  • Any handlers triggered by the roles or tasks.
  • AnyΒ post_tasksΒ defined in the play.
  • Any handlers triggered by post_tasks.

Time for an example

In addition to the above recommendations, i also recommend that you practalize your knowledge, Rafael has written an amazing article on how to automate the setup of a Kubernetes cluster on GCP following a similar structure.

This is the format he implemented

...
└── ansible                    # Ansible top-level folder
    β”œβ”€β”€ ansible.cfg            # Ansible config file
    β”œβ”€β”€ create-k8s.yml         # Ansible playbook to provision env
    β”œβ”€β”€ destroy-k8s.yml        # Ansible playbook to destroy env
    β”œβ”€β”€ inventory             
    β”‚   └── gcp.yml            # Ansible inventory file
    └── roles
        β”œβ”€β”€ destroy_k8s        # Ansible role to remove k8s cluster        
        β”‚   └── tasks
        β”‚       └── main.yml
        β”œβ”€β”€ destroy_network    # Ansible role to remove VPC
        β”‚   └── tasks
        β”‚       └── main.yml
        β”œβ”€β”€ k8s                # Ansible role to create k8s cluster
        β”‚   └── tasks
        β”‚       └── main.yml
        └── network            # Ansible role to create VPC
            └── tasks
                └── main.yml

Conclusion

Ansible makes deploying your infrastructure easier and it's best when used as intended, Don't over complicate it, start simple and with time you would discover what structure works best for your organization.

Thank you for reading, I hope you learned a lot already. I'm Azeez Lukman and here's a developer's journey building something awesome every day. Please let's meet on Twitter, LinkedIn, GitHub and anywhere else @robogeeek95

Originally published on dev.to

Author's avatar
Azeez Lukman
Lifelong learning machine, Full-stack node {MERN,MEAN} web developer

Related Issues

open-editions / corpus-joyce-ulysses-tei
open-editions / corpus-joyce-ulysses-tei
  • Open
  • 0
  • 0
  • Intermediate
  • HTML
open-editions / corpus-joyce-ulysses-tei
open-editions / corpus-joyce-ulysses-tei
  • Started
  • 0
  • 1
  • Intermediate
  • HTML
open-editions / corpus-joyce-ulysses-tei
open-editions / corpus-joyce-ulysses-tei
  • Open
  • 0
  • 0
  • Intermediate
  • HTML
open-editions / corpus-joyce-ulysses-tei
open-editions / corpus-joyce-ulysses-tei
  • Open
  • 0
  • 0
  • Intermediate
  • HTML

Get hired!

Sign up now and apply for roles at companies that interest you.

Engineers who find a new job through WorksHub average a 15% increase in salary.

Start with GitHubStart with Stack OverflowStart with Email