K8s is better anyway, at least if you have the hardware for it. It’s just slightly more complex to set up, but it sounds like you may already be over that hurdle.
If you want a new technology to have to resist dropping everything to play with, may I suggest CUE? Stands for Configure, Unify, Execute. If you’re not familiar, it’s a json superset that turns json-style data into networks of programmed relationships. Like if you want to send the same deployment to three different clusters, which have differently configured CD components, and (for example) you want to vary the databases or message queues you use based on the core microservice or what else has been deployed in the cluster, you can build out these relationships in CUE and merge them with another .cue module that defines how to render files for each destination cluster, automatically producing all yaml manifests that you would otherwise have to write by hand.
But absolutely, do what you were going to get done today. It’s not a cool technology at all, there’s really no need to keep thinking about it.
Well, I started setting up my homelab on an old dell rackmount server I got for cheap, but then paused it for a year and electricity costs doubled. Costs half as much to run a droplet with what I need for now (server has like 200 cores, even idle it sucks juice)
I’ll have forgotten all I know about kubernetes and prox mox by the time proces drop again 😔
Note says “Totally not a K3s cluster”
K8s (short for kubernetes)
K3s is a Rancher-based lightweight Kubernetes, more geared toward deploying on resource-constrained environments like ARM devices.
Oh?
Thanks for the correction and new knowledge! (And a new tech temptation to resist)
K8s is better anyway, at least if you have the hardware for it. It’s just slightly more complex to set up, but it sounds like you may already be over that hurdle.
If you want a new technology to have to resist dropping everything to play with, may I suggest CUE? Stands for Configure, Unify, Execute. If you’re not familiar, it’s a json superset that turns json-style data into networks of programmed relationships. Like if you want to send the same deployment to three different clusters, which have differently configured CD components, and (for example) you want to vary the databases or message queues you use based on the core microservice or what else has been deployed in the cluster, you can build out these relationships in CUE and merge them with another .cue module that defines how to render files for each destination cluster, automatically producing all yaml manifests that you would otherwise have to write by hand.
But absolutely, do what you were going to get done today. It’s not a cool technology at all, there’s really no need to keep thinking about it.
Thanks I’ll investigate cue.
Well, I started setting up my homelab on an old dell rackmount server I got for cheap, but then paused it for a year and electricity costs doubled. Costs half as much to run a droplet with what I need for now (server has like 200 cores, even idle it sucks juice)
I’ll have forgotten all I know about kubernetes and prox mox by the time proces drop again 😔
So, let’s modify CoreDNS and update the cluster version then. Don’t want to? Interesting.