Lessons from working and playing with things like AWS, Ansible, and others
This post touches on a key component of my Managing Kubernetes is Easy With Ansible talk that I gave at AnsibleFest 2018. Since giving that talk, I’ve also solved some of the unforeseen consequences, and go into further detail here.
Performing tasks locally is a common operation when working with an API of some
kind—typical use cases are cloud services, network devices, cluster
management. There are three ways of achieving this in Ansible: connection:
local, delegate_to: localhost and local_action. The last is rarely seen these
days and can be deemed equivalent to delegate_to: localhost in terms of
advantages and disadvantages, but with the additional disadvantage of being
a very unusual style, adding a readability penalty.
While there are ways of managing multiple AWS account consoles in a single browser (such as assuming roles to access other accounts), various constraints might prevent that (e.g. accounts owned by third parties to which access should be segregated).
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.
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 command and
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.
ansible-review
is coming up to the three month anniversary of the first commit,
and I’ve given it little publicity other than an
ignite talk at the last
DevOps Brisbane Meetup.
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 pgrep and 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=no to 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.