There are many reasons to want to use newer modules than a chosen stable Ansible core release:
As mentioned in yesterday’s blogpost, using a combination of environments, applications and operations can cause a cartesian explosion in hosts and groups to manage.
When using Ansible to consume APIs such as cloud services, the
logic runs from the controller machine. As a result, people tend
to think that as this runs locally, using
hosts: localhost is
the best option.
You’re a (prospective) contributor to Ansible, and you have some great improvements to make to an existing module or a brand new module. As a conscientious developer, you know that having tests will ensure that you don’t break existing behaviour, and that other people’s future enhancements won’t break your desired behaviour. The standard tests for AWS modules are integration tests as most of them rely on creating some resources in AWS, updating them, and then cleaning up afterwards.
Most software development teams have long been doing code reviews, and while it’s not uncommon amongst system administrators, it’s not universally practised.
At Ansible Brisbane October 2016, I gave a talk on Automating Ansible Code Reviews
My three hour workshop on Ansible from Zero to Best Practices
I realise I have quite strong opinions on the
shell modules in Ansible. There are now four independent checks in
ansible-lint for ways to
use the modules badly. Let me count the ways…
Tonight we had the first Ansible Brisbane Meetup. It was relatively well attended, and there were a lot of interesting questions following the talks.
For DevOps Chennai, I revisited my What Ops Can Learn From Dev talk
I was sitting with a colleague helping with some Ansible stuff and I couldn’t help noticing his playbook runs were taking a minute before the first connection to a host.
At Devops Days Melbourne I gave a companion talk to last year’s talk. This year’s is called “What Operations can learn from Developers” and talks about how Ops can make use of the same practices and techniques that developers use to maintain great code.
This post is an example of how to use versioning of roles with playbooks. The initial premises are these:
I noticed at work recently that Ansible seemed to be taking a really long time. On further inspection of the start and end time of tasks, each task seemed to be taking three seconds.
This is a replacement post for my most recent entry on techniques for versioning ansible. The motivations described within that post remain valid. We do versioning for the following reasons:
First, let’s start with the why. With source control and inventory, do we actually need to version Ansible playbooks or roles?
I first wrote ansible-lint nearly a year ago. The aim behind my implementation was to be able to spot common antipatterns and indeed bugs and report them to users.
At Devops Days Brisbane I gave a talk called “Designing and Devoloping Software for Operations”, providing my thoughts and advice to help write software that is easy to operate.
I wrote a slide deck for work for internal training on Ansible. I’ve created a public-facing version.
A colleague reported some strange behaviour regarding Ansible, in particular with
pkill in the shell module.
Ansible’s unarchive module has been around a while but it’s not always been suitable for use on archives local to the destination node (especially when running ansible-playbook on the destination host using the local connection. There are two key elements to this tip:
copy=noto ensure that no attempt is made to copy the archive from the host running ansible to the destination node
Inspired by my recent efforts to handcraft Ansible inventory graphs, and wanting to be able to quickly see what groups are used for a particular host in Ansible inventory, I decided to generate some graphs.
One of the most common things to configure in an application is some kind of credentials based connection. Typically this will be to a database or an API endpoint, but it doesn’t really matter too much - the examples in this post will be database configuration, but the principles are the same.
When tweeting about my recent Ansible post I mentioned that graphviz selection problems were the cause of some delay. @magneticnorth responded that it was dismaying given the size of the underlying font handling libraries. So I thought I’d give a more detailed breakdown.
Ansible’s system for managing configuration of hosts is inventory. The documentation on inventory - both static and dynamic - is a good reference but I’d like to provide further context through example.
A new year brings a new blog. I’ve been doing lots of cool things recently in the world of tech, particularly with AWS and Ansible, and it’s time to write some of my learnings down so that others can benefit.