Ansible is configuration management tool and remote orchestration tool. It's kind of like Puppet, and Fabric had a baby. It can get boxes into a desired state like Puppet, but it can also run commands on a bunch of remote boxes like Fabric. It has a few difference from puppet. Namely that it pushes its configuration on demand to boxes instead of having a puppet dameon periodically check for changes and reset things. It also is configured entirely through yaml files that run tasks, instead of having a DSL for managing state.
Ansible is broken down into three major parts. Inventory, Playbooks, and Roles. I will cover these three briefly. Anyone looking for a more in-depth documentation on ansible should checkout the docs.
An inventory is a document that describes all of the hosts you want to manage, and how they are grouped. Take a look at our master inventory to get a sense of the structure.
This allows us to slice and dice boxes. For instance all our boxes might share a common configuration like the users who are allowed to login to the boxes, but only a subset will need to be setup as a web server. This allows us to address each group of machines separately.
From the ansible glossary, "Roles are units of organization in Ansible". This can be everything from an nginx role to make sure that nginx is setup and configured, to a role that will make sure a service gets deployed on a box and restarted.
Playbook bind it all together. In a playbooks you assign a number of roles to an inventory group, or host. Most of the time you are running playbooks to actually make things happen.
We organize vars roughly by
- Common vars
- Application (Global)
- Environment
- Application (Per-Env)
- Role
So, if you need to define vars, try and think about them be organized that way.
Just like everything else Ansible has continuous integration pipeline. If you need to make a change to how ansible works, you commit changes to the ansible repo, and after the style checks pass it will be automatically deployed to our jenkins server.