I was recently tasked with re-developing our workflow for our Drupal applications. With this task I was faced with several challenges:
- We needed to develop a workflow to maintain and manage client feature requests, updates, and upgrades in order for us to offer good support to the numerous clients we have.
- We needed to develop a workflow that did not take up large amounts of resources to develop or maintain.
- We needed to make sure we developed a workflow with tools that were modular enough so that we could customize ourselves, that would grow as we grow, and that used technology that would not become so outdated in the next year that we would have to repeat the process all over again.
- We needed a open source solution that was proven to work, be secure, and allow our team to develop a workflow that would manage our full Drupal stack.
You would think that with all these requirements the solution would be difficult to find, however that was not the case for us. A proven solution was already well developed, adopted, and advocated by various Drupal teams with similar needs. That solution was Ansible, a devops and open source developers dream world where IT teams can create customized repetitive tasks to deploy, configure, and orchestrate commands to do one thing: work.
To understand Ansible and how it works, you have to understand its 6 basic concepts (described best on its documentation page, but I will paraphrase the best I can):
Control Node
The machine where Ansible will run from. You could think of it as the control center (or brain) where you will run all your commands to control every aspect of your workflow. You need at least one, but you can essentially have as many as you would like.
Managed Nodes
This is where you would want Ansible to run all your commands on. You could think of these as the hosts (or body parts) that Ansible will actually connect to, control and work with & on.
Inventory
If you have a wide variety of hosts (or body parts), you will need a way to keep track of all of them and specify if you want ansible to run commands on one or all of your hosts. The beauty of this concept is that you can even group them together based on different categories. For our team, since the development stage of our apps determines what server it lives on, we created groups based on the stages of our release cycle.
Modules
These are units of work that we want to take place on the host (or the series of actions a specific body would complete in order to meet a goal).
Tasks
These are the actual commands that make up a unit of work (or the commands that come from the brain to get the work done). The beauty of these tasks is that they can be setup to respond in different ways based on variables passed to them during run time (or variables that are defined in the inventory), if a previous tasks fails or responds with a specific message, and/or based on the managed node that you are running on.
Playbooks
Here the control center (or brain) can have a predefined set of modules and tasks with variables and various other options, packaged up and ready to deploy at a moments notice.
The best thing about any open source software is the documentation and the community, and Ansible gets an ‘A’ in both of those subjects. The documentation is very thorough and is not hard to understand. It is complete with plenty of examples that allow you to get the full idea (for us developers, these are the pictures that are worth a thousand words). Then there is the community, which helps extend Ansible into a multi-purpose knife that can be used in an endless amount of situations. In fact, the Ansible community world is so expanse that it even has its own galaxy of contributions that developers can post and reuse a full suite of modules (called roles) that you can manipulate and use in your own playbooks. One popular and well-used roles is the Ansistrano role (more on this wonderful tool in a follow up post).