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.
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
nah you're probably not going to get any benefits from it. The best way to make your setup more maintainable is to start putting your compose/kubernetes configuration in git, if you're not already.
I don't want to derail this thread, but you piqued my interest in something I've always wanted to do, maybe just for the learning aspect, and to see what I could accomplish.
I've always wanted to see if I could have all my docker compose/run files, and various associated files to a git where I could just reinitialize a server, with everything I already have installed previously. So, I could just fire up a script, and have it pull all my config files, docker images, the works from the git, and set up a server with basically one initial script. I have never used github or others of that genre, except for installation instructions for a piece of software, so I'm a little lost on how I would set that up or if there are better options.
Yeah, what you're talking about is called GitOps. Using git as the single source of truth for your infrastructure. I have this set up for my home servers.
https://codeberg.org/jlh/h5b
nodeshas NixOS configuration for my 5 kubernetes servers and a script that builds a flash drive for each of them to use as a boot drive (same setup forporygonz, but that's my dedicated DHCP/DNS/NTP mini server)mikrotikhas a dump of my Mikrotik router config and a script that deploys the config from the git repo.applicationshas all my kubernetes config: containers, proxies, load balancers, config files, certificate renewal, databases, clustered raid, etc. It's all super automated. A pretty typical "operator" container to run in Kubernetes is ArgoCD, which watches a git repo and automatically deploys any changes or desyncs back to the Kubernetes API so it's always in sync with git. I don't use any GUI or console commands to deploy or update a container, I just edit git and commit.The kubernetes cluster runs about 400 containers, most of them just automatic replicas of services for high-availability. Of course there's always some manual setup steps outside of git, like partitioning drives, joining the nodes to the cluster, writing hardware-specific config, and bootstrapping Argocd to watch git. But overall, my house could burn down tomorrow and I would have everything I need to redeploy using this git repo, the secrets git repo, and my backups of my databases and container
/datadirs.I think Portainer supports doing GitOps on Docker compose? Never used it.
https://docs.portainer.io/user/docker/stacks/add
Argocd is really the gold standard for GitOps though. I highly recommend trying out k3s on a server and running ArgoCD on it, it's super easy to use.
https://argo-cd.readthedocs.io/en/stable/getting_started/
Kubernetes is definitely different than Docker Compose, and tutorials are usually written for Docker
compose.yml, not KubernetesDeployments, but It's super powerful and automated. Very hard to crash once you have it running. I don't think it's as scary as a lot of people think, and you definitely don't need more than one server to run it.Man, I really appreciate all this info. Very helpful. It will take me some time to digest everything and put it into an action plan. I just thought, hey that would be cool and a nice project I can sink my teeth into and learn a lot on the way while deploying. Again, thank you for taking the time to give some direction and inspiration.