In the summer of 2013 I worked on a project that introduced me to Ansible. I was so impressed by it that I wrote a blog post. I found Ansible to be different to the catalog of software that constantly tries to grab our attention these days, and I’ve pretty much evangelised it since.
A colleague was asking me questions today about Ansible playbooks, roles, tasks etc and how they translated from Puppet nomenclature (he is coming to Ansible with Puppet experience - much the same as I did actually). He thought it would be handy to have a ‘translation guide’.
On July 23rd I gave a talk at the London Splunk User Group on automating Splunk with Ansible. You can find the slides here.
You know what, I am starting to despair of the IT industry, just a little bit.
On July 2nd I gave a talk at DevOps Cardiff related to the blog post I wrote last year, on Puppet vs Chef vs Ansible.
So you’ve decided to do some infrastructure automation as part of your DevOps workflow huh? And after reading lots of Ansible versus Puppet, Chef, Saltstack etc posts, you’ve settled on Ansible. But where to start? What tips will help you get on, faster? Here are my top five things you can do to help yourself…
As part of a log consolidation exercise I’d decided to try and put logwatch output into Splunk, to later produce some succinct analysis.
Jenkins seems to be the prevalent CI/CD software these days - but, truthfully, how many of you look at it and think it looks a bit, well, yuk?
In a previous post I mentioned that I would show a high-level design for an infrastructure operating model. This is a model I have followed to build a Linux based infrastructure, long before I even drew it as this diagram.
This week I’d been fighting with a Chef install to do something relatively simple. Bogged down in a rats nest of complexity (extra Ruby scripts referencing Chef environment files, etc etc), I decided to see if there was a easier way.