Recently I’ve started using the gradle axion-release plugin; it’s a nice idea since I agree with its core precepts. It means that I don’t have to think about what the next version number will be since that is now derivable from git history. This post isn’t about that though, it’s about gradle plugin dependency management and the rabbit hole I found myself in.

You know what they say, you can always run Linux on your old hardware to make it useful again. I have a Mac Mini, more specifically a Apple Inc. Macmini7,1/Mac circa 2015/2016 whose usefulness is now at an end. It’s worth pointing out here that I don’t think this particular Mac was actually ever any good as a long term piece of kit; soldered RAM and having to break out my torx screw driver set never equates to fun times in my book. Still, it should be fine with Linux running on it, being a spare Kubernetes node in my homelab…

Last time I ended spending far longer wrestling with microk8s on windows than actually doing Kubernetes based things. I’ve tried microk8s on my RPi instances, and it plays absolutely fine so it was definitely the interoperability between Windows and microk8s. As a result I decided to do the same thing with kind just to reflect on the differences.

TLDR; My opinion is that kind is much better for creating sandbox test environments; I might consider something like talos as well for building out a K8S environment. Since Kind has fewer opinions, you’re not wrestling with your search engine, and you can mostly follow the vanilla K8S install guides for whatever you want. I’m still going to bootstrap K8S with an ingress controller running ActiveMQ, Elasticsearch and Kibana. KEDA is installed, and I’ll be installing Interlok later on into the cluster.

I’ve been making my first foray into deploying some things into K8S. I’ve never really used it in anger to deploy something that I have a personal relationship with. My trusted peers tell me that kind is probably one of the better ways to start with K8S; I’ve also got a use case where I’m intending to build a cluster at home (via a bunch of RPIs) and since microk8s touts itself has being zero-ops and it has a KEDA add on I thought I’d give it a spin.

This is 2 days worth of fun, mostly wrestling with my search engine of choice for the right terms to narrow down to my specific problem (with microk8s). In many respects nothing that I’m doing is new or special and should have been painless; but once you get past the most trivial of examples you’re in a world of search pain or stack overflow noise if you aren’t already an Kubernetes expert. So, this is a blog post that tries to save you pain with a non-trivial trivial example of deploying something into kubernetes via MicroK8S

I’m going to bootstrap a single kubernetes node with an ingress controller running ActiveMQ, Elasticsearch and Kibana. This is easy to do if you were using docker compose, and that’s what I would usually do, but I wanted to play with KEDA since I have more than a passing interest in understanding how to autoscale workers that are attached to JMS, and what gotcha’s I need to think about.

I’ve been using direnv to control my environment variables on a per-directory basis for a while. It all really started because I needed to use my personal AWS credentials for some projects and my corporate AWS credentials for others. While it was certainly possible, the hoops I had to jump through to try and provision KMS against my corporate credentials just made me lose the will to live. Sometimes it’s just more expedient to use my personal AWS credentials depending on what technology I want to play around with.

I’m back on Windows after a couple of years with a Mac. I might eventually go back to a Mac but at the moment the lack of arm64 docker images for the things that I commonly use makes me a little wary. Windows means I that use scoop.sh to install software, but I will use a combination of Windows git-bash, WSL v1 and WSL v2 depending on my mood. WSL v2 is faster to startup, but has crap performance when attaching to your windows filesystem. WSL v1 has better performance against the windows filesystem but takes more time to startup because of corporate AV scanning. This just means more hoops for me to make my direnv configuration consistent across all 3 bash instances.