A small container running in kubernetes on an old laptop.

Fuck if this isn’t the truth… Saying this as a Sr. SRE with no degree or certs.

Don’t overthink this. Just start using something.

Mostly as kodi/plex front ends. I’ve set them up as a kubernetes cluster in the past but they didn’t have enough ram to run my torrent client. Now I just use an old Thinkpad running talos.

I still don’t really see the argument. OpenTofu exists because of internal drama about licensing on a tool that you don’t use…

Someone building a different banana picker that looks just like another banana picker doesn’t need to explain their reasoning in terms a coal miner would understand…

Also, literally just clicking the intro doc linked from the main page tells you everything you need to know…

If you’re asking why aren’t DevOps/SRE mentioned specifically on the OpenTofu front page, I don’t think you understand how common this software is… Like if someone forked Google, you wouldn’t need to describe what Google is. Everyone already knows it. For the people in this industry, terraform is essentially a defacto monopoly. Even if you don’t use it, if you’re working in SRE, you know what it is and what it does.

Yeah this is just not for you. In the DevOps/SRE space, EVERYONE knows terraform and most of those names will be recognizable to the people most deeply involved in using/managing terraform.

Not who you were responding to but, my company does this in AWS. To be fair, the entire platform is running in EKS so it’s not much more difficult than updating the CI build pipelines to build multi-arch containers, adding additional nodepools, and scaling down the amd64 ones. This was tedious but not difficult to do. I keep a small set of amd64 nodes for off the shelf software that doesn’t support arm… I think the only thing left on those now is newrelic agents. Once we move off of them the x86_64 nodes can be killed entirely.

This ended up saving us tens of thousands of dollars per month. The next step is to move the bulk of workloads to spot instances. I’ll be preferring arm but if there is only capacity for x86_64, I’ll have that option because of the multi-arch containers. This is going to save even more money and force developers to build applications more tolerant of node failure in the process.

Fair. For what it’s worth though, macbooks have been the default laptop at every startup I’ve worked at over the last ~8 years… The first M1 mbp was released in 2020 and most of those companies I was at had a policy of replacing machines after 2-3ish years too. it’s getting to the point where entire companies can be/are running on arm.

Might be more specific to particular industries or company maturity level but this has been my personal experience.

Yeah but you have to write Javascript. :-D

The cross-compiling point makes sense but, since this is a 4.5 year old message, the state of ARM in the cloud has changed. Now developers do actually have ARM-based machines because of Apple. AWS has Graviton2 instances now and they are a lot cheaper than similarly specced x86_64 instances. ARM is a viable consideration that can be made.

Certbot in cron if you’re still managing servers.

I’m using cert-manager in kube.

I haven’t manually managed a certificate in years… Would never want to do it again either.

Meh… Planet of the Alien was better.

It auto discovers machines/instances/VMs/containers in the mesh and figures out the secure routing on the fly. If you couldn’t ensure a consistent IP from the home address it wouldn’t matter… The service mesh would work it out.

It is probably overkill for this project though… Something to think about…

With Prometheus I would add a section to the scrap config to rewrite the labels attached to each metric. Does such a thing exist for telegraf? I’ve never used it.

Or could you change the grafana query to just aggregate the values for all pods in that deployment?

Istio is a service mesh. You basically run proxies on the vps and the rpi. The apps make calls to localhost and the proxy layer figures out the communication between each proxy.

Duck dns is just a dynamic dns service. It gives you a stable address even if you don’t have a static ip.

This would be nice because I don’t need a static ip and I don’t have to leak my ip address.

How does the VPS know how to find your rpi?

Could you not just use something like duck dns on a cronjob and give out that url?

I would also need to figure out how to supply ejabberd with the correct certificates for the domain. Since it’s running on a different computer than the reverse proxy, would I have to somehow copy the certificate over every time it has to be renewed?

Since the VPS is doing your TLS termination, you would need an encrypted tunnel of some sort. Have you considered something like Istio? That provides mTLS out of the box really… I’ve never seen it for this kind of use case but I don’t see why it wouldn’t work.

Figured this would be one of the responses. Thanks. I don’t interact with node very often. I assumed there was a better option but wasn’t sure which… This is just the first result.

You can do it bro. Dockerfiles are basically just shell scripts with a few extras.

It uses npm to build so start with a node base container. You can find them on docker hub. Alpine-based images are a good starting point.

FROM appdynamics/nodejs-agent:23.5.0-19-alpine 

RUN git clone https://github.com/stophecom/sharrr-svelte.git && \ 
    cd sharrr-svelt/ && \
    npm run build

If you need to access files from outside of the container, include a VOLUME line. If it needs to be accessible from a specific network port, add an EXPOSE line. Add a CMD line at the end to start whatever command needs to be run to start the process.

Save your Dockerfile and build.

docker build . -t my-sharrr-image

There are build instructions in the readme. What’s stopping you?