Ansible talk at Devops Brisbane

Archives Ansible Project
1

I spoke at Devops Brisbane last night about configuration management development principles by example with Ansible.

I don’t claim to speak for the Ansible community - my goal is to raise awareness of Ansible and sound approaches to take to configuration management. I don’t expect people to agree with everything I said.

The feedback was very good and I had a good chat with a few people who either hadn’t heard of Ansible, had heard of it but not used it much, or using it themselves for significant projects. All in all, a positive contribution to Ansible awareness I hope.

Slides are at
http://willthames.github.io/devops-bris-ansible/#/

and the examples are at
https://github.com/willthames/devops-bris-ansible

Will

2

Thanks for spreading Ansible, though there are a lot of things in here I want to correct.

I do wish you wouldn’t spread things like “requires homogeneity” as that’s not true at all.

Group_by and when exist for dealing with those things, and just abstracting the choice of package manager never solves the need for different package names of the way apps are managed differently in Ubuntu and Red Hat (see Apache for a great example). Lots of folks do that, including the main AWX setup playbooks which you can take a look at.

The convergence stuff is also pretty well wrong, in fact, all the modules are very resource based, with a model copied directly from Puppet. Order matters, just like Chef – however, unlike either, the language is MUCH simpler and you can more easily decide how to do things. Is it true that it doesn’t build a model of what that system does up front? Yes, it’s resource-by-resource based so one result is allowed to influence another, which is how it makes most of the IT orchestration possible.

Installing logstash could also be done in a role prior to role deps :slight_smile:

The easiest way to handle secret data is just have it in a different repo. IIRC, Ansible-vault isn’t so much a work in progress as something that needs to be designed, which is on the list, but not always the most pressing thing to tackle :slight_smile:

No, there aren’t frameworks like cucumber for Ansible. There shouldn’t be, because these suck (once again, you’re going down the Infrastructure-as-Code route, which is NOT US), and I will throw big heavy rocks at them. However, its super easy to call any kind of unit test you want in your main playbook.

I also disagree that any abstractions to allow for reuse are missing.

3

It’s certainly not my intention to spread misinformation. I’ll tone down some of the assertions in the next version (I take your point on the problem of packages having different names for example). I’d say it was as convergence aware as puppet if ansible could tell you the difference between what is there and what should be there. I concede that there’s not really any difference between chef and ansible in that sense - both make idempotency a lot easier to achieve.

I’ll take a look at the strategies for common playbooks from AWX. Do you think there is actually a desire for shared common playbooks for reuse in the community (like puppet forge or chef community cookbooks - the latter being the better example of doing it properly). If a community of playbooks emerged I’d say that there are no barriers to reuse. I think the abstractions I had in mind were the ease of creating new providers and libraries in chef so that higher level operations are easier to achieve without needing to modify core (or even install new libraries under core)

The stuff about logstash and role dependencies is more a non-sequitur in my presentation - the two statements aren’t intentionally linked. I’m aware that roles (and indeed task includes before that) made modularising the installation of logstash easier.

I’m not really sure I understand your problem with infrastructure as code that you think it’s some kind of terrible thing. Infrastructure as configuration shouldn’t really be treated any differently from code - it should be versioned, testable, modular etc. There are always going to be best practices, and making awareness of them easier should be a valid goal.

Will

4

We are looking into ways to make sharing possible.

I can’t announce anything yet, but stay tuned and I think you’ll be quite happy.

“Infrastructure as configuration shouldn’t really be treated any differently from code - it should be versioned, testable, modular etc.”

This is “automation best practices”, the idea though that the infrastructure is modelled with code is the problem. It brings the complexity of software development (debugging, long release cycles, complexity) to the automation. Thus Ansible prefers to think of “infrastructure as data”. Do you still want to use a SCM? Absolutely.