nomad

In a previous post, I had noted that due to HashiCorp’s recent decisions about the licensing for their tools, I was thinking about switching away from Nomad as my workload scheduler. Since then, HashiCorp made a change to the Terraform registry’s Terms of Service which only allowed usage with HashiCorp Terraform. This was obviously an action against OpenTOFU, and it reeked of pure spite. That turned my musings about the future of my Homelab from “okay, this leaves a bad taste” to “Okay, I just lost all trust in HashiCorp”....

Basically my entire Homelab is build upon HashiCorp’s products. On August 10th, HashiCorp announced that they would switch all of their products to the BSL, the Business Source License, where they had been licensed under the Mozilla Public License before. From my (rather rudimentary!) understanding, the license basically says that all “non-production” use is perfectly fine. I’m pretty confident that that covers all of my own personal usage. But as it was pointed out to me today, that formulation also creates a lot of uncertainty for commercial entities of all kinds....

I updated my Nomad and Consul clusters recently. Especially Consul was a large jump, getting from 1.13.5 to 1.15.1. After about three days, I suddenly started getting 500: Internal server error from a lot of my services. In this article, I will be going into the debugging process and explain a little bit about what Consul Connect is and how it works. Why Consul Connect? So Consul Connect, or Consul Service Mesh, creates a sort-of overlay network to connect services running on multiple machines, in a secure manner....

I’ve just had a major success: My docker-compose like Nomad script can now use the nomad binary with the job run -output command to transform a HCL file into JSON for use in the Nomad API. Before, my tool was using the Nomad API’s /v1/jobs/parse endpoint. This meant that I was not able to make use of any of the HCL2 functions recently introduced. I’m mostly interested in using the file and fileset functions, and I want to tell you why....

As mentioned in my previous post on migrating the Consul/Vault/Nomad servers from a VM to a Raspberry Pi, I was still waiting for some more Pis to arrive to extend the Nomad/Consul/Vault clusters to a HA configuration for all three. The main reason for this is not necessarily fault tolerance, but rather gaining the ability to restart the controllers without taking down the entire Nomad cluster. Now I’d like to give a short overview of the experience, and end with a bit of an overview on the resource consumption (spoiler: Raspberry Pi 4 4GB are absolutely sufficient)....