I’ve brought a second node into the cluster but it didn’t go perfectly right off the bat so the third brick will be the proof. The reason it failed is that I had some fancy automation set up that already created an unattached volume on the second node, but adding pre-existing volumes is ludicrous, now that I think about it, and I only thought about it once I tried to do it and was told “No.”

Before I add bricks and expand the cluster, I want to see if I can use what I’ve got so far. I’m not concerned about the Kubernetes side, but as mentioned I have never used Gluster before, and I’m sure there are some kinks to work out.

The first concrete step in rebuilding my services infrastructure is building a virtual Gluster node, or two. I’m going to start with one to see how easy it is to add nodes. Actually I may as well install k8s as well and I’ll have my first brick.

Currently my Kubernetes cluster is based on Kubespray, with a single node on the control plane, dedicated to that task. The control node has experienced some hard drive errors which has caused it to go read-only a number of times, failing it out. Thinking about what to do has led me to thinking about a broader reconfiguration of my home data centre, with two major approaches.

In the recent past I’ve typically versioned software based on either its most recent tag or, for non-release versions, the commit short SHA–the seven- or eight-digit hexadecimal hash of the latest update. Because commit hashes are neither ordered nor intrinsically memorable, I’ll add the commit’s date in the form YYYYMMDD to remind myself at a glance how old is the thing I’m looking at. A major utility of this is to let me know I’m debugging the most recent version of the software–with automated deployments it’s possible some technohiccup or stray gamma radiation interferes and the updated app isn’t deployed yet.

Introducing Commentry, a simple commenting system for static websites. Commentry consists of a JavaScript client and a Python+Flask server. Simplicity and privacy drove the design.

This blog will be a disjointed mess and will go dormant after eleven articles (and three drafts I never publish). This I Foretell.

Some time ago I described more carefully documenting my home data centre. In the months since I’ve found it useful to informally replicate at home some of the best-practices stuff I’ve used professionally for years. This isn’t amazing stuff. It’s just documentation. I’m a bit of a documentation geek though. Description of problem (Did you see what I did there.) I’ve had documentation before for the various computers and network devices and layouts I tinker with in my late-night leisure, but they’ve typically suffered from various, serious deficiencies:

Now that the broken laptops are mostly in a usable state (well, about 67% anyway) and I have some spare time at the end of vacation, I want to get Kubernetes running on them. First, I need a base install. And I don’t want to have to do that manually. Setting up a PXE boot server so these things automatically install an OS should be fairly straightforward, right?

Before I describe the overall plan, I’ll describe my plan for documenting everything. There are a couple of reasons I’m going rather formal for my home data centre. They’re actually pretty close to the reasons you go formal with an actual data centre, to be honest.