Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Honest question, why are you looking to buy hardware to do this when you can mess with K8S in VMs on your existing proxmox host?
I tried this on proxmox and ran into a lot of installation issues. Any tips?
Have you watched the Learn Linux TV video series on YouTube? He does a good job at walking you through k8s from nothing using cloud init images, but you don't need that part.
Will check it out thanks
Fair point. If I don't want to just run a single node cluster, I will need at least 2-3 nodes aka VMs. Looking at like 2-4GB (as a bare minimum imho) memory for each, I would already eat into like half of my current 16GB of available memory. And this mini server is already running a lot of my critical apps, using more than half of the memory.
I run a single node cluster.
My single node has 256 gb of ram and 24 cores. I do this because, if you want a lot of ram/cores/storage, it is cheaper to get a used "tower server" type device and then upgrade it as you go over time, than it is to buy entirely new devices for every bit of ram you want to add to the cluster.
I like kubernetes because I like configuration as code, gitops, the way it abstracts over components so I can swap components out easily, the way that helm charts are an easier way of orchestrating containers, and a bunch of other things.
Clustering is merely one of many benefits of kubernetes, one that isn't particularly important to me. Although, my opinion on that has changed somewhat recently. Waiting for a reboot is annoying, since I am rebooting the whole thing and I have to wait for each service to go down or come up before the machine reboots properly. But if I was running kubernetes as a virtual machines inside incus with multiple nodes, I could update each node one by one without the whole thing going down. Or, I could snapshot them, allowing me to reboot the host without waiting for kubernetes. But these things are mostly just somewhat nice to have, rather than a core feature I really require.
have you found many self-hosted services that suppprt that kind of HA? I can't imagine services like torrent clients allowing you to stream writes to one node while replicating to the other, though maybe I'm misunderstanding the setup
They don't have to support it. It's more that the database they are connecting to supports HA, and/or both are using shared storage. So when one container dies, kubernetes restarts another container on another node with the same shared storage attached.
Docker is often configured to automatically restart containers when a container dies, just in case it's a one off bug or something like that, and kubernetes is like a more resilient version of that.
I'm aware of databases that support HA, but the vast majority of self-hosted apps I've encountered use file storage, even if they have a database as well. It sounds like you're proposing shared storage like an NFS share. But if you're upgrading nodes, at some point you have to upgrade the node hosting the shared storage right? Wouldn't that take down all services? Unless you use a distributed storage system, but I've heard those can get very complicated...
Kubernetes makes distributed storage easy.
Basically, all the components get deployed for you, since that's part of what kubernetes is good at.
And then, services/containers can provision storage by requesting storage via making a "claim" and whatever distributed storage providee you have gives it to you.
Have you tried using Ceph or other distributed storage systems in your kubernetes cluster?
Well, I run a one node cluster...
But yes, I did use ceph via rook-ceph, because Openstack (a locally hosted AWS alternative), at least the Kubernetes version, wanted a ceph "cluster" to store stuff on.
Longhorn is much easier. Although again, my "cluster" was one node. I deployed it because I wanted snapshots.
Wow cool! I believe you're the first person I've met that actually used a cluster FS (in their homelab at least). I looked into it myself but it felt like nobody was really using it so I didn't bother.
Does it involve much more work or is it a fairly transparent replacement to traditional storage options? Assuming one is already using Kubernetes. I'm wondering if it's worth it to switch to a cluster FS for everything, like Radicale or Tiddlywiki.
On kubernetes it's pretty much the same amount of work. Every possible storage option exposes a generalized, abstracted "storageclass", from which storage can be provisioned and mounted into containers.
https://kubernetes.io/docs/concepts/storage/storage-classes/
Oh wow okay, if I'd go down that route I would definitely do multiple VMs on that host. In my opinion, the whole clustering and self healing / HA aspect of Kubernetes is why I want to switch to it. I can do gitops with Podman/Docker as well, in fact I already do that including a renovate pipeline on my sel-hosted Forgejo instance. But having the redundancy of several nodes, if one goes down the service will still work or at least will be re-deployed within a couple of seconds, provided there is distributed storage (longhorn, ceph or even nfs cis) if its a stateful app.
That's fair.