Ansible - Getting started…

Ansible MeetUp in Sydney is one of the fewest opportunities for DevOps enthusiasts to come in and learn about Ansible from people who are already using it. Last week wasn’t different…

On the speakers panel we had Mick Pollard, Ansible devotee and his talk was all about HA Laptops with Ansible. As he is currently working remotely from his place in ‘the middle of nowhere’ (jealous much! He showed us pictures and it looks amazing!) He talked about how to stay employed living in such location and what to do if your laptop dies I could be offline for a few days or more. In his talk he shared with us how he has been doing this with Ansible + github + dropbox. 

Michael Battison, our next speaker gave us an introduction to Ansible – lighting talk for those who haven’t used the tool before – and what a great talk that was.

Mikey have been using Ansible for quite a while now and he thinks it is really simple, reliable and pretty easy to tackle.

According to Ansible in Depth (Whitepaper), ‘Ansible is designed to be minimal in nature, consistent, secure, and highly reliable, with an extremely low learning curve for administrators, developers, and IT managers’.

So how Ansible does the thing:

• Ansible uses SSH to connect to hosts that makes it fast and agentless
• It describe your environments using yaml
• Ansible recommend using the os package manager on RHEL, centOS, fedora, debian, Ubuntu

 How do you make Ansible do the thing?

 Inventory file

• Inventory files are how Ansible keeps track of how it’s connecting to whatever it’s connecting to.
• These are super simple text files with IP addresses and hostnames.
• You can use a different more dynamic system of inventory if you like (i.e. from a cloud provider).
• You can group entries in the inventory file and then refer to those groups later (i.e. tell Ansible to run on all your webservers).

Vars

• You can set variables in different scopes (you can set role)
• Host level variable could be the http port of your web servers - that would be applied to the webserver group of hosts

Roles

• Roles are an abstraction level above playbooks. they allow you to define smaller sets of tasks that make sense together and are generally for a specific purpose.
• A webserver role, a database role, sometimes there are roles for different system (like nginx or mysql)

Ad-hoc

• Ad-hoc tasks are things you will probably only run once.

Playbooks

• Playbooks & roles are where the power lives! Ansible uses playbooks to run one or more “plays” on your systems. Playbooks can declare configurations but not only that; they can also orchestrate steps of any process ordered manually. By using Playbooks you tell Ansible what you want it to do with your systems, like pretty much everything else in Ansible, playbooks are expressed in yaml.

Ansible is proving popular as it is simple and efficient at the same time. Great job Mikey for explaining this to the Sydney Ansible Network! 

What do you think?

Is Ansible a perfectly viable alternative to Chef or a Puppet?