Selfhosted

41581 readers

458 users here now

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.

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!

founded 2 years ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz

Should I stick with Docker Swarm for self-hosting? (lemmy.world)

submitted 7 months ago* (last edited 7 months ago) by UncommonBagOfLoot@lemmy.world to c/selfhosted@lemmy.world

12 comments fedilink hide all child comments

Hi! I'm starting out with self-hosting. I was setting up Grafana for system monitoring of my mini-PC. However, I ran into issue of keeping credentials secure in my Docker Compose file. I ended up using Docker Swarm since it was the path of least resistance. I've managed to set up Grafana/Prometheus/Node stack and it's working well.

However, before continuing with Docker Swarm, I want to check if this is a good idea or will I potentially dig myself into a corner? Some of the options I've found while searching:

Continue with Docker Swarm and look into automation of stack/swarm in future
- Ansible playbook has plugins for Docker Swarm.
Self-hosted vault: I want to avoid hosting my own secret/password manager at the moment.
Kubernetes (k8s / k3s) - I don't wanna 😭
- More seriously, I'm actually learning this for work but don't see the point of implementing it at home. The extra overhead doesn't seem worth it for a single node cluster.
~~Live dangerously - Store crdentials in plaintext. Also use admin as password for everything~~

Edit: Most of the services I'm planning on hosting will likely be a single replica service.

you are viewing a single comment's thread
view the rest of the comments

[–] farcaller@fstab.sh 8 points 7 months ago (1 children)

I run k3s in my homelab as a single node cluster. I’m very familiar with kubernetes in general, so it's just easier for me to reason with a control plane.

Some of the benefits I find useful:

ArgoCD set to fire and forget will automatically update software versions as they happen. I use nix to lower the burden of maintaining my chart forks. Sometimes they break, but
VictoriaMetrics easily collects all the metrics from everything in the cluster with very little manual tinkering, so I am notified when things break, and
zfs-localpv provides in-cluster management for data snapshots, so when things do break I can easily roll back to a known good state.

k3s is, of course, a memory hog, I'd estimate it and cilium (my CNS of choice) eat up about 2Gb ram and a bit under one core. It's something you can tune to some extent, though. But then, I can easily do pod routing via VPN and create services that will automatically get a public IP from my endless IPv6 pool and get that address assigned a DNS name in like 10 lines of Yaml.

[–] curled@lemm.ee 1 points 7 months ago

I'm curious about your IPv6 setup, how does that work with services you don't want to be publicly available? Or if it does need to be public, how do you interact with your firewall to allow the right ports for the new IP?