roles

Ansible Galaxy error 'Unable to compare role versions'

Ansible Galaxy was recently updated to the 'Next Generation' (Galaxy-NG) codebase.

There are some growing pains, as a lot of Galaxy NG was built up around Collections, and Ansible role support was written into the codebase over the past year or so, after it became obvious Galaxy roles would not be deprecated.

Unfortunately, one of the major issues right now—which I'm seeing pop up in many places—is an error that occurs upon installation of Galaxy roles for any playbook (e.g. when you run ansible-galaxy install to download a role), for any role that has had a new version released in the past few weeks.

You wind up with an error like:

Ansible best practices: using project-local collections and roles

Note for Tower/AWX users: Currently, Tower requires role and collection requirements to be split out into different files; see Tower: Ansible Galaxy Support. Hopefully Tower will be able to support the requirements layout I outline in this post soon!

Since collections will be a major new part of every Ansible user's experience in the coming months, I thought I'd write a little about what I consider an Ansible best practice: that is, always using project-relative collection and role paths, so you can have multiple independent Ansible projects that track their own dependencies according to the needs of the project.

Early on in my Ansible usage, I would use a global roles path, and install all the roles I used (whether private or on Ansible Galaxy) into that path, and I would rarely have a playbook or project-specific role or use a different playbook-local version of the role.

Everyone might be a cluster-admin in your Kubernetes cluster

Quite often, when I dive into someone's Kubernetes cluster to debug a problem, I realize whatever pod I'm running has way too many permissions. Often, my pod has the cluster-admin role applied to it through its default ServiceAccount.

Sometimes this role was added because someone wanted to make their CI/CD tool (e.g. Jenkins) manage Kubernetes resources in the cluster, and it was easier to apply cluster-admin to a default service account than to set all the individual RBAC privileges correctly. Other times, it was because someone found a new shiny tool and blindly installed it.

One such example I remember seeing recently is the spekt8 project; in it's installation instructions, it tells you to apply an rbac manifest:

kubectl apply -f https://raw.githubusercontent.com/spekt8/spekt8/master/fabric8-rbac.yaml

What the installation guide doesn't tell you is that this manifest grants cluster-admin privileges to every single Pod in the default namespace!

Patching or using a forked version of an Ansible Galaxy role

I maintain a lot of Ansible Galaxy roles. I probably have a problem, but I won't admit it, so I'll probably keep adding more roles :)

One thing I see quite often is someone submitting a simple Pull Request for one of my roles on GitHub, then checking in here and there asking if I have had a chance to merge it yet. I'm guessing people who end up doing this might not know about one of the best features of Ansible Galaxy (and more generally, open source!): you can fork the role and maintain your changes in the fork, and it's pretty easy to do.

I just had to do it for one project I'm working on. I am using the rvm_io.ruby role to install specific versions of Ruby on some servers. But there seems to have been a breaking change to the upstream packages RVM uses, summarized in this GitHub issue. I found a pretty simple fix (removing one array item from a variable), and submitted this PR.

Speaking about Ansible Roles at AnsibleFest SF 2016

I'm excited to announce that I'll be speaking at AnsibleFest San Francisco 2016, on July 28th, giving a session titled Ansible Roles - for Fun and Profit!

Image from AnsibleFest London
Image from AnsibleFest London, earlier in the year.

AnsibleFest is the major bi-annual Ansible conference, full of case studies, sessions and announcements. I'm excited to finally be able to attend, as I've been an avid user of Ansible since 2013, even to the point of writing one of the most popular introductory books on Ansible, Ansible for DevOps.

Adding a role to a user programmatically in Drupal 8

Since a quick Google search didn't bring up how to do this in Drupal 8 (there are dozens of posts on how to do it in Drupal 7), I thought I'd post a quick blog post on how you can modify a user's roles in Drupal 8. Hint: It's a lot easier than you'd think!

In Drupal 7, $user was an object... but it was more like an object that acted like a dumb storage container. You couldn't really do anything with it directly—instead, you had to stick it in functions (like user_multiple_role_edit()) to do things like add or remove roles or modify account information.

In Drupal 8, $user is a real, useful object. Want to modify the account name and save the change?

Testing Ansible Roles with Travis CI on GitHub

This post was originally written in 2014, using a technique that only easily allows testing on Ubuntu 12.04; since then, I've been adapting many of my roles (e.g. geerlingguy.apache) to use a Docker container-based testing approach, and I've written a new blog post that details the new technique: How I test Ansible configuration on 7 different OSes with Docker.

Since I'm now maintaining 37 roles on Ansible Galaxy, there's no way I can spend as much time reviewing every aspect of every role when doing maintenance, or checking out pull requests to improve the roles. Automated testing using a continuous integration tool like Travis CI (which is free for public projects and integrated very well with GitHub) allows me to run tests against my Ansible roles with every commit and be more assured nothing broke since the last commit.

Using Ansible Galaxy

2020 Update: This article is still as relevant as ever, though Galaxy now has tens of thousands of roles and also has 'Collections' now, which can include plugins, modules, and roles! If you want to learn the latest about all this stuff, check out my fully updated Ansible for DevOps, now in it's 2nd edition! It has two chapters covering roles and collections on Ansible Galaxy.

Ansible Galaxy Logo

Ansible Galaxy was launched just a few short months ago, and already has over 500 roles maintained by over 225 users. The idea behind Galaxy is to give greater visibility to one of Ansible's most exciting features: reusable Roles for server configuration or application installation.