thelastknowngod

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.

I used to be in love with Awesome but I think it’s been more than 10 years since I used it last. I remember the software being wonderful and the people in the people in the community being stereotypical, smug, “rtfm” types… That was more frustrating than anything else about Awesome.

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.

Is there anything he can’t do? What an inspiration!

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.

Gimme dat poo poo

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.

Every two weeks. I’ve been following from the beginning… It’s the best show on the tubes.

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.