Starting late in 2020 and wrapping things up today, I streamed a new 10-episode series, Kubernetes 101 (the first episode is embedded below).
The first episode will be available here on YouTube: Kubernetes 101 - Episode 1 - Hello, Kubernetes!.
In the spring, I presented a similar livestream series, Ansible 101, covering all the basics of Ansible and setting people up for success in infrastructure automation.
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?
I'm Jeff Geerling; you probably know that because my name appears in huge letters at the top of every page on this site, including the post you're reading right now. I currently work at Acquia as a Senior Technical Architect, building hosting infrastructure projects using some buzzword-worthy tech like Kubernetes, AWS, and Cloud.
Over the past decade, I've enjoyed presenting sessions at many DrupalCamps, DrupalCon, and other tech conferences. The conferences are some of the highlights of my year (at least discounting all the family things I do!), and lately I've been appreciative of the local communities I meet and get to be a part of (even if for a very short time) at Drupal Camps.
One of my most popular Ansible roles is the
geerlingguy.jenkins role, and for good reason—Jenkins is pretty much the premiere open source CI tool, and has been used for many years by Ops and Dev teams all over the place.
As Jenkins (or other CI tools) are adopted more fully for automating all aspects of infrastructure work, you begin to realize how important the Jenkins server(s) become to your daily operations. And then you realize you need CI for your CI. And you need to have version control and deployment processes for things like Jenkins updates, job updates, etc. The
geerlingguy.jenkins role helps a lot with the main component of automating Jenkins install and configuration, and then you can add on top of that a task that copies config.xml files with each job definition into your
$JENKINS_HOME to ensure every job and every configuration is in code...
Since this is something I think I've bumped into at least eight times in the past decade, I thought I'd document, comprehensively, how I get Munin to monitor Apache and/or Nginx using the
nginx_* Munin plugins that come with Munin itself.
Besides the obvious action of symlinking the plugins into Munin's plugins folder, you should—to avoid any surprises—forcibly configure the
env.url for all Apache and Nginx servers. As an example, in your munin-node configuration (on RedHat/CentOS, in
/etc/munin/plugin-conf.d, add a file named something like
# For Nginx:
# For Apache:
Now, something that often trips me up—especially since I maintain a variety of servers and containers, with some running ancient forms of CentOS, while others are running more recent builds of Debian, Fedora, or Ubuntu—is that
localhost doesn't always mean what you'd think it means.
For almost all my Ansible roles on Ansible Galaxy, I have a comprehensive suite of tests that run against all supported OSes on Travis CI, and the only way that's possible is using Docker containers (one container for each OS/test combination).
For the past year or so, I've been struggling with some of the test suites having strange issues when I use
docker exec --tty (which passes through Ansible's pretty coloration) along with Ansible playbooks running inside Docker containers in Travis CI. It seems that certain services, when restarted on OSes running sysvinit (like Ubuntu 14.04 and CentOS 6), cause
ansible-playbook to hang indefinitely, resulting in a build failure:
The following post is an excerpt from chapter 11 in my book Ansible for DevOps. The example used is an Ansible role that installs Java—since the role is supposed to work across CentOS 6 and 7, Fedora 24, Ubuntu 12.04, 14.04, and 16.04, and Debian 8, I use Docker to run an end-to-end functional test on each of those Linux distributions. See an example test run in Travis CI, and the Travis file that describes the build.
Note: I do the same thing currently (as of 2019), but now I'm using Molecule to tie everything together; see Testing your Ansible roles with Molecule.
Last night I presented the following slides at the Ansible St. Louis meetup at Riot Games. In the presentation, I mention the motivation behind Ansible and Galaxy 2, and run through most of the major changes and new features:
I've incorporated many of the new features in Ansible 2.0 in my book, Ansible for DevOps, and will be rewriting a few of the examples in the book to take advantage of new features in Ansible 2 soon!