This post was originally published at thbe.org.
The last open part is, how does this look in action and where do I find the code. Before we start and in case you missed it, here are the previous two posts about this topic:
First, I set up some minimal virtual machines that should act as target nodes for this demonstration. I used different distributions to demonstrate how flexible Ansible could be configured:
In the next step I will execute the configuration run:
$ ansible-playbook -i production.yml common.yml
Ansible now connects to target nodes and start its magic. It will go through the list of defined tasks and execute them. When Ansible finishes, the screen will look like this:
Ansible in fact does, in the end, two different things, it set the desired state and it checks the desired state. This is quite important because it means if the Ansible detects a wrong state, it will correct it to the desired state. It protects the IT landscape against configuration drifts (small fixes or enhancements performed on one node but not the rest of the nodes).
This finally means that all nodes look pretty much the same, even on different distributions (not everything is equal, Debian distributions still use dpkg instead of rpm etc., but most of the things will be the same):
This is it for the moment, I've shown how the role-based approach for Ansible look like and what you can achieve. If we look forward we still need to extend the role-based approach with roles for specific applications like web-servers, but I hope the basic idea is clear. If you would like to see the full Ansible code that I had used for this demo, you need to check out my corresponding Github project:
Top comments (0)