The Ansible-powered architect

Do you already Ansible? If yes, have fun with the hidden puns, if not, follow the links too.


A solution implementation architect’s workflow nowadays might look like magic for an outsider. Past sketches towards reality: not only can you ramp up components of your architecture with few clicks of a mouse (e.g. powerful columnar database like RedShift to the cloud..clickety-click...need more oomph? clickety-click…scaled!) but you can conjure whole multi-machine-solution infrastructures in a neatly organized, modular, portable and repeatable way.

For a solution architect, building even test environments yourself in a matter of minutes used to be a pipe-dream. You ended up waiting for infrastructure team to allocate their time, company internal hardware, negotiate operating system and basic software component selections, setup network, give you IP-addresses to contact, access keys…time. Now, with approachable, easy to use, almost self-documenting tools like Ansible the architect can do that all by him/herself. You can take the nice plan of your solution architecture to a simple reader-friendly list (YAML) and take the whole setup live to your instances in cloud yourself, letting the infrastructure team use their time for more important activities. You read that right. You. Not needing a dev-ops team. How?

So, you already know what you want to run, you might have gone as far as deciding which hosts would have which types of roles (e.g. you might want to have a control/monitoring machine with Jenkins running as a scheduler/orchestrator and in the same instance host components monitoring your whole setup, something like Nagios). Now, with Ansible's playbooks you can take the next step in a clean way and just decide and deploy it all yourself: which softwares you want installed, present or absent in which hosts, which services you want stopped, started where. You could of course do that all with shell-scripts like during the last millennia, but why would you want to? While Ansible lets you include direct shell commands all willy nilly if you want, I experienced that almost everything I wanted to do already had an easy to use module offered (yes, with examples), and thus instead of a heap of shell scripts, I had neatly indented readable playbooks, which in an idempotent way can be run any times you want, pushing your target machines to the states you want them to be in.

Installation of Ansible is a breeze and leaves a light footprint, no database, no daemon. On a Centos7 machine with EPEL...

Ansible install

That was it. After this the most complex thing is to ensure the Ansible client can SSH to your hosts, since Ansible talks over SSH - and then you are good to go!

A simple Ansible example

You have your hosts listed at /etc/ansible/hosts. Now let's say for starters you want all hosts to have a Nagios agent to get some monitoring on them.

See this tiny example playbook installing Nagios NRPE into as large a plethora of Centos-slaves as you have bothered to put to your aforementioned hosts -file, to tell Ansible what to do, you just put this YAML list of tasks into a file, for example to a file "my_playbook".


OK, so now you have machines to change in your "hosts" and things to do to them in your "my_playbook" - now at your Ansible machine's command prompt you just utter:

ansible playbook

...and see magic happen..


Yes - that WAS all. All your target machines now have EPEL, they have NRPE agent. Was that hard? No.

But why Ansible?

Compared to Chef or Puppet the learning curve is something else, as you might have deduced from the example above..and there are many people feeling like that. (Here is a tweet from Aaron Patterson of Rails core team...). One of the central reasons for the draw of Ansible is that Ansible's components are documented in a readable and approachable manner. Not only is the basic configuration easy as pie, the documentation is top notch and can be trusted and for the hasty person there is a heap of examples, attached to documentation of modules and their parameters.

The range of easy control mechanisms offered to manage your hosts in customized ways in tagged groups like "webservers", "db-servers"...whatever is staggering, just see the examples in the hosts-file template /etc/ansible/hosts for starters to open your mind to the possibilities. And you of course can run only a part of the tasks in your playbooks, only on a limited set of your host-army if you many powerful choices.

The example above is naturally just a first, simplified taste of Ansible. With only a little organizing, you can make any components of your system roles to be applied to any machine you want in a way that can be re-used across projects and with that also introduce a clear structure to your Ansible projects to avoid clutter and monolithic playbooks.

Key point to take away:

Ansible lets you abstract your whole solution infrastructure ramp-up to the complexity level of a grocery shopping list (yes, that is what YAML looks like to my eyes). And you will not be even going to the shop, Ansible will do that.

If you are not already using Ansible, ask yourself, why? 20% of Fortune 100 are and so are several of our clients.

(P.S. Pro-tip, yum2. Try it.)

(P.P.S. RedHat just bought them - Ansible is developed further all the time: with Ansible 2.0 you don't even need to use apt or yum to install software...just call "package"..)

(P.P.P.S. While you can divide each little tweak not only into it's own task but into it's own tasks file, you might want to reconsider that: in case you want to know "what was done to this host", having to open 20 small .yml -files is not going to make your day necessarily better. You CAN make Ansible pretty complex if you really try, but why would you? Working memory of humans is not that big - save it.)

(P.P.P.P.S. ..Linux..)

Further reading:

Especially for the cautious ye-olde ssh person - educational and funny read:

Thank you for your time!