ansible

I maintain a large number of Ansible Galaxy roles, and publish hundreds of new releases every year. If the process weren't fully automated, there would be no way I could keep up with it. For Galaxy roles, the process of tagging and publishing a new release is very simple, because Ansible Galaxy ties the role strongly to GitHub's release system. All that's needed is a webhook in your .travis.yml file (if using Travis CI):

For collections, Ansible Galaxy actually hosts an artifact—a .tar.gz file containing the collection contents. This offers some benefits that I won't get into here, but also a challenge: someone has to build and upload that artifact... and that takes more than one or two lines added to a .travis.yml file.

Until recently, I had been publishing collection releases manually. The process went something like:

Every successful software project I've worked on reaches a point where architectural changes need to be made to ensure the project's continued success. I've been involved in the Drupal community for over a decade, and have written about the successes and failures resulting from a major rearchitecture in version 8. Apple's Macintosh OS had two major failed rewrites which were ultimately scrapped as Apple moved on to Mac OS X.

It's a common theme, and because change is hard, the first response to a major shift in a software project is often negative. Distrust over the project's stewards, or anger about a voice not being heard are two common themes. Even though it has nothing to do with the change (which was being discussed 3 years ago), the acquisition of Red Hat by IBM last year didn't do anything to assuage conspiracy theorists!

October 2020 Update: This post still contains relevant information, but one update: the community.kubernetes collection is moving to kubernetes.core. Otherwise everything's the same, it's just changing names.

The Ansible community has long been a victim of its own success. Since I got started with Ansible in 2013, the growth in the number of Ansible modules and plugins has been astronomical. That's what happens when you build a very simple but powerful tool—easy enough for anyone to extend into any automation use case.

Five years ago, I set out to write a book. For a topic, I picked Ansible, since I was familiar with the software, and noticed there weren't any other books about it. I struck gold with Ansible for DevOps, and have since sold over 22,000 copies between eBook and paperback copies.

I've written about self-publishing before, and my opinion about publishing technical works is stronger than ever:

• Don't write for a publisher (usually)
• Use the Lean Publishing process

I wrote an entire article (Self-Publish, don't write for a Publisher) on the first topic. Regarding the second topic, I see writing a technical book on the same plane as building a software project:

I recently needed to force the /etc/resolv.conf file to be immutable on a set of CentOS servers, since the upstream provider's DHCP server was giving me a poorly-running set of default DNS servers, which was getting written to the resolv.conf file on every reboot.

There are a few different ways to force your own DNS servers (and override DHCP), but one of the simplest, at least for my use case, is to change the file attributes on /etc/resolv.conf to make the file immutable (unable to be overwritten, e.g. by the network service's DHCP on reboot).

Typically you would do this on the command line with:

chattr +i /etc/resolv.conf

And Ansible's file module has an attributes (alias: attr) parameter which allows the setting of attributes. For example, to set the attributes to i, you would use a task like:

Note: Please note that the Tower Operator this post references is currently in early alpha status, and has no official support from Red Hat. If you are planning on using Tower for production and have a Red Hat Ansible Automation subscription, you should use one of the official Tower installation methods. Someday the operator may become a supported install method, but it is not right now.

I have been building a variety of Kubernetes Operators using the Operator SDK. Operators make managing applications in Kubernetes (and OpenShift/OCP) clusters very easy, because you can capture the entire application lifecycle in the Operator's logic.

tl;dr: You can now sponsor my open source development work via GitHub Sponsors.

GitHub Sponsors is the latest foray into building a more sustainable future for open source software development. There have been many attempts before, a few of which I tried (Gratipay, Patreon, etc.), but most of them never reached a critical mass, and at most you'd end up getting maybe $20-50/month out of the platform. Another prolific open source contributor I've long followed wrote about the topic of open source support and developer burnout in a post this year, Webform, Drupal, and Open Source...Where are we going?.

I hit this problem every once in a while; basically, I run molecule test or molecule converge (in this case it was for a Kubernetes Operator I was building with Ansible), and it says the instance is already created/prepared—even though it is not—and then Molecule fails on the 'Gathering Facts' portion of the converge step:

The following is a transcript of the content in my AnsibleFest Atlanta 2019 session, There's a role for that! How to evaluate community roles for your playbooks.

• Presentation slides
• Presentation video

Introduction

I'm Jeff Geerling, I wrote a book on Ansible (Ansible for DevOps), I have used Ansible on an almost daily basis for hundreds of different projects since 2013, and I now work with Red Hat's Ansible team as a technical contractor.

Some people wonder ask how teams can be productive while maintaining many applications on a variety of cloud providers. One of the key reasons is reliance on Ansible content contributed and maintained by others.

This is the third Ansible Contributor Summit I've attended, and the one with by far the most attendees. Contributor Summit is an Ansible community-focused day spent giving Ansible contributors updates on the current status and direction of the Ansible project, as well as an open mic to give feedback to the Ansible core team and other Ansible component teams.

As I have in the past, I thought I'd jot down a few notes from the Summit, with things I learned during the day, for the benefit of those who couldn't attend remotely, or don't have the time to watch all the meeting recordings (see a recap here).