thelastknowngod

A small container running in kubernetes on an old laptop.

Don’t overthink this. Just start using something.

Not scrolling through all the comments to see if someone mentioned this yet or not but every December I check what is on the best albums of the year lists… Generally I check per-genre that I’m into. Like best black metal of 2023, best jazz of 2023, etc etc…

Other than that, bandcamp and YouTube are the biggest. I honestly buy more on bandcamp these days than I torrent though. It’s such a great site.

It’s completely overkill for pretty much everyone but I have been thinking about building a kubernetes native client for months now.

Like the torrent should be treated as a normal resource with a Torrent CRD. It should be scheduled onto whichever node has available capacity and rescheduled onto a different node if it goes down. If allowed by the tracker, multiple instances could be run. You could set resource limits programmatically, easily configure block storage, build dashboards, export logs/metrics… It would be open ended enough that you could have interfaces built as browser extensions, web ui, mobile app, tui, cli and be unopinionated so much that the method for torrent ingestions could be left up to the used. HTTP request, watch directory, rss client, download manager… You could even do stuff like throw magnet links into a queue… etc, etc…

I keep thinking it would be a great project but I just do not have the spare time to dedicate to it… I imagine it could be used for large scale deployments for something like the Internet archive or whatever.

In the case of small little indie bands, they often aren’t on torrent sites at all. Given the choice between Spotify and Bandcamp, I’m going to buy the album on Bandcamp 100% of the time. I can contribute to the artist more and usually end up with a vinyl copy on the process.

Pirating has always been a solution to poor ease of access to content. If I could pay a legitimate subscription for a site with the catalog of PTP or RED, I would do it in a heartbeat. It will never happen though.

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.

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.

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?

Yep. IO.

OP, this might be overkill for you but it might be worth standing up a grafana/prometheus stack… You’d be able to see this stuff a lot faster and potentially narrow in on a root cause.