automation

There are far too many smart home devices which make using a device harder. Like a light switch and light bulb that requires a wireless connection to a hub in order to control the lights.

Before, you could flick a switch, and a light would come on.

Now, you have to ensure the light has power, the switch has power, and the hub has power. And the wireless connection between switch, hub, and light needs to be reliable. And the hub can't lock up or go offline. And if it's anything like most modern IoT devices, the hub needs a reliable Internet connection and cloud account, or things will start failing at some point.

That's dumb.

And that's just light switches. Can you imagine relying on this kind of 'smarts' for essential services in your home, like HVAC, water supply, etc.?

To be truly 'smart', I follow three principles for home automation. Every smart device must be:

I've dipped my toes in 'smart home' automation in the past.

Typically I approach 'smart' and 'IoT' devices as a solution to one simple problem, instead of trying to do 'all the things'.

For example, I wanted to make it easy for my kids to control a home theater with four different devices and complex audio/visual routing, so I bought a Harmony remote and programmed it to control TV, a game console, an Apple TV, and radio. I don't want Logitech to start controlling other aspects of my house, or to give intruders an avenue by which they could invade my home's network.

However, many smart devices require a persistent Internet connection to use them, and that I cannot abide.

At AnsibleFest 2021, I presented a session titled Automating the Uncommon - Ansible automates everything!.

Since watching on-demand versions of the AnsibleFest sessions requires a signup, I thought I'd also post the session to my YouTube channel, so everyone can learn from it without registering. The session seemed well-received, and I hope it shows that, as I state in my 'Rule of Golden Hammers':

I demonstrate how I use Ansible to:

Ah, the feeling of unpacking a brand new computer:

In my case, I'm actually selling the 16" MacBook Pro pictured above and replacing it with a 13" MacBook Air and 10 Gigabit Mac mini.

Once you turn on the new Mac, what's next? Do you:

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: I'm now using Fathom for my personal website analytics, and it's easy to self-host and maintain, better for privacy, and can lead to better site performance.

Since the mid-2000s, right after it became available, I started using Google Analytics for almost every website I built (whether it be mine or someone else). It quickly became (and remains) the de-facto standard for website usage analytics and user tracking.

Before that you basically had web page visit counters (some of them with slightly more advanced features ala W3Counter and Stat Counter), and then on the high end you had Urchin Web Analytics (which is what Google acquired and turned into a 'cloud' version, naming the new product Google Analytics and tying it deeply into the Google AdWords ecosystem).

For some Kubernetes cluster operations (e.g. deploying an update to a small microservice or app), I need a quick and dirty way to:

1. Build and push a Docker image to a private registry.
2. Update a Kubernetes Deployment to use this new image version.
3. Wait for the Deployment rollout to complete.
4. Run some post-rollout operations (e.g. clear caches, run an update, etc.).

There are a thousand and one ways to do all this, and many are a bit more formal than this, but sometimes you just need a shell script you can run from your CI server to do it all. And it's not too hard, nor complex, to do it this way:

For the past decade or so, I've been working to automate as much of a Jenkins server build process as possible. There are a few 'hacky' bits to doing so, like managing some Jenkins XML files (or if you really want to go crazy, storing your entire $JENKINS_HOME somewhere in a source control repository!).

One of the most annoying things about automating Jenkins is using the jenkins-cli.jar file to interact with Jenkins on the CLI. It doesn't come with any automated solution for authenticating with Jenkins, and is meant for running either on the same server where Jenkins is running, or really anywhere that has SSH access. I generally don't like putting any Jenkins bits (including the CLI tool) on servers outside the actual Jenkins instance itself, so I've traditionally used the --username and --password method of authenticating with jenkins-cli.

However, it seems those CLI flags were deprecated and removed at some point in the past few months (maybe around 2.130 or so?), and now I get the following error when running CLI commands that way:

Over the past month, I started rebuilding the Raspberry Pi Dramble project using Kubernetes instead of installing and configuring the LEMP stack directly on nodes via Ansible (track GitHub issues here). Along the way, I've hit tons of minor issues with the installation, and I wanted to document some of the things I think turn people away from Kubernetes early in the learning process. Kubernetes is definitely not the answer to all application hosting problems, but it is a great fit for some, and it would be a shame for someone who could really benefit from Kubernetes to be stumped and turn to some other solution that costs more in time, money, or maintenance!

September 2018 Update: Ansible 2.7 (to be released around October 2018) will include a new reboot module, which makes reboots a heck of a lot simpler (whether managing Windows, Mac, or Linux!):

- name: Reboot the server and wait for it to come back up.
  reboot:

That's it! Much easier than the older technique I used in Ansible < 2.7!

One pattern I often need to implement in my Ansible playbooks is "configure-reboot-configure", where you change some setting that requires a reboot to take effect, and you have to wait for the reboot to take place before continuing on with the rest of the playbook run.

For example, on my Raspberry Pi Dramble project, before installing Docker and Kubernetes, I need to make sure the Raspberry Pi's /boot/cmdline.txt file contains a couple cgroup features so Kubernetes runs correctly. But after adding these options, I also have to reboot the Pi.