ansible

This is the third video in a series discussing cluster computing with the Raspberry Pi, and I'm posting the video + transcript to my blog so you can follow along even if you don't enjoy sitting through a video :)

It started with a tweet, how did it end up like this?

Use Ansible to build a 10,041 node K8S cluster in AWS, deploy a single the HelloWorld container, then tear them down at the end of the script.

— Dan Linder (@dan_linder) May 13, 2020

I've had a YouTube channel since 2006—back when YouTube was a plucky upstart battling against Google Video (not Google Videos) and Vimeo. I started livestreaming a couple months ago on a whim, and since that time I've gained more subscribers than I had gained between 2006-2020!

So it seems fitting that I find some nerdy way to celebrate. After all, if Coline Furze can celebrate his milestones with ridiculous fireworks displays, I can do ... something?

For many new Ansible-based projects, I build my tests in Molecule, so I can easily run them locally or in CI. I also started using GitHub Actions for many of my new Ansible projects, just because it's so easy to get started and integrate with GitHub repositories.

I'm actually going to talk about this strategy in my next Ansible 101 live stream, covering Testing Ansible playbooks with Molecule and GitHub Actions CI, but I also wanted to highlight one thing that helps me when reviewing or observing playbook and molecule output, and that's color.

By default, in an interactive terminal session, Ansible colorizes its output so failures get 'red' color, good things / ok gets 'green', and changes get 'yellow-ish'. Also, warnings get a magenta color, which flags them well so you can go and fix them as soon as possible (that's one core principle I advocate to make your playbooks maintainable and scalable).

This post is based on one of the videos in my series on Raspberry Pi Clustering, and I'm posting the video + transcript to my blog so you can follow along even if you don't enjoy sitting through a video :)

In the first episode, I talked about how and why I build Raspberry Pi clusters.

I mentioned my Raspberry Pi Dramble cluster, and how it's evolved over the past five years.

In March, I made my DevOps books free to help anyone who wanted to learn new skills during the global pandemic lockdown. In April, Device42 generously extended that offer for another month.

I originally had the idea to give the books away on a whim on a Sunday night, thinking I'd give up a fair chunk of revenue, but nothing too substantial. The response I did get was overwhelming, to say the least!

As with many other metrics during these unprecedented times, book sales shot through the roof while they were free. The top chart is Ansible for DevOps, and the bottom is Ansible for Kubernetes:

I will be posting a few videos discussing cluster computing with the Raspberry Pi in the next few weeks, and I'm going to post the video + transcript to my blog so you can follow along even if you don't enjoy sitting through a video :)

This is a Raspberry Pi Compute Module.

And this is a stack of 7 Raspberry Pi Compute Modules.

For many of my Ansible playbooks and roles, I have CI tests which run over various distributions, including CentOS, Ubuntu, Debian, and Fedora. Many of my Docker Hub images for Ansible testing include systemd so I can test services that are installed inside. For the most part, systemd-related issues are rare, but it seems with Fedora and DNF, I often encounter random test failures which invariably have an error message like:

No such file or directory: '/var/lib/dnf/rpmdb_lock.pid'

The full Ansible traceback is:

Last month I announced I was going to make my books Ansible for DevOps and Ansible for Kubernetes available free on LeanPub through the end of March, so people who are in self-isolation and/or who have lost their jobs could level up their automation skills.

The response floored me—in less than two weeks, I had given away over 40,000 copies of the two books, and they jumped to the top of LeanPub's bestseller lists.

Purchases (over 99% with price set to 'free') of both books spiked within hours of the announcement.

After the incredible response I got from making my Ansible books free for the rest of March to help people learn new automation skills, I tried to think of some other things I could do to help developers who may be experiencing hardship during the coronavirus pandemic and market upheaval.

So I asked on Twitter:

Considering adding a weekly livestream “Ansible 101” teaching Ansible automation following the book https://t.co/jk6G0An9gb — would you be interested?

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.