Live data from Hacker News

My self-hosting infrastructure, fully automated

github.com

191–200 of 228 posts

Re: My self-hosting infrastructure, fully automated

#191

I recently wanted to give my current RPi4 home server a GitOps makeover, migrating services (Home Assistant, Nextcloud and others) to k3s in the process. What has been an obstacle is the availability of officially maintained Docker images for some of the components I've been wanting to use - afaict neither Argo CD nor Rook have official armv7/aarch64 images (though it seems Argo will release one soon). Until then, I'…

For various reasons I started building all container images myself. In most cases when arm64 images aren't provided, they will build just fine anyway.

Running you own registry is super simple.

https://docs.docker.com/registry/deploying/

Re: My self-hosting infrastructure, fully automated

#192
post #161
post #2

This is very cool! Have you considered something like Tailscale so you can securely access it from outside your home? I've been thinking about spinning up my own home server that way, seeing as Tailscale makes it easy to securely access it from my phone when I'm out and about.

It's not quite the same as a VPN, but in addition to Tailscale and some of the alternatives suggested in other comments, it may be worth looking at using HTTPS client certificates. Done right, you get a pretty simple second line of defence - you can validate the client has an appropriate certificate (running your own CA is pretty straightforward for small-scale home use or for a small group of users). Without such a…

The headache I find with client side certs is that it's annoyingly common for client side apps to have their own CA store which you have to track down and install your CA.crt in.

Re: My self-hosting infrastructure, fully automated

#193
What do you use to provision Kubernetes persistent volumes on bare metal? I’m looking at open-ebs (https://openebs.io/).

Also, when you bump the image tag in a git commit for a given helm chart, how does that get deployed? Is it automatic, or do you manually run helm upgrade commands?

Re: My self-hosting infrastructure, fully automated

#194
post #187

Earlier quoted context omitted.

Dependencies of software I didn't write (e.g. Graylog)

This is what I'm getting at. That is an enormous overkill for a single server, and exactly the problem with kubernetes: It drives so much complexity that you kind of need this type of heavy-duty enterprise grade solutions even in an area where you really shouldn't need it. If it's just a single server, you're fine with logrotate and grep.

So first of all: I do have to clarify that I just use bare podman containers deployed by ansible and not a while k8s setup, so I'm defending containers and not k8s. But anyway:

Who said graylog is only logging on that single server? That server is by far the biggest and hence why I run multiple services with big dependencies on it, but I have that server, 2 cloud servers (one running my personal web page and other publically accessible services, one running a couple of game servers) + a couple of Raspberry Pis.

Even if I didn't have all that, a web interface to configure it to email on ssh login or send me a mobile notification that my offsite backups are still happening and/or not happening for devices or similar items would still be a nice feature, even if you personally feel it's too complex or you could write a cron job for each of them.

Re: My self-hosting infrastructure, fully automated

#195

What do you use to provision Kubernetes persistent volumes on bare metal? I’m looking at open-ebs ( https://openebs.io/ ). Also, when you bump the image tag in a git commit for a given helm chart, how does that get deployed? Is it automatic, or do you manually run helm upgrade commands?

I'm currently using Longhorn for storage, but if I find some reasonably priced HDDs, I may add or switch to Rook.

When you make a change in git, it is automatically deployed without the need for human intervention.

Re: My self-hosting infrastructure, fully automated

#196

What do you use to provision Kubernetes persistent volumes on bare metal? I’m looking at open-ebs ( https://openebs.io/ ). Also, when you bump the image tag in a git commit for a given helm chart, how does that get deployed? Is it automatic, or do you manually run helm upgrade commands?

I'm currently using Longhorn for storage, but if I find some reasonably priced HDDs, I may add or switch to Rook. When you make a change in git, it is automatically deployed without the need for human intervention.

Can you elaborate a bit more on how the automatic helm upgrades are performed?

Re: My self-hosting infrastructure, fully automated

#197

I enjoy reading about homelabs that aren't using kubernetes or some other scheduler and how they're doing it/what the full stack looks like. This is just another "how I installed kubernetes" thing only without any real scale behind it. There are other ways to deploy and run things, and it takes people toying around with alternatives for something unique to spring up.

My "homelab" is just debian stable, with a moratorium against containerization. Systemd keeps the services going. Updates are manual. It's a bit incredible how clean and easy such a set-up can be. Like there's almost nothing to say. It's extremely reliable and just keeps ticking. I actually did use to have a bunch of virtualization and kubernetes and crap, but got rid of it because it ate literally half the systems'…

I've transitioned from a single server running services on baremetal Debian, to running services with Docker on Debian, to running services with Docker on Debian VMs under Proxmox (aka Debian with a repo), to running services on a three-node Kubernetes cluster using k3os (I was using Talos, but it doesn't have Longhorn support yet, and Rook/Ceph was a nightmare).

The baremetal server was the easiest to set up, obviously, but the hardest to maintain. Where did I put that random config? Wait, why did this break when I upgraded X? Switching to Docker (and later Compose) wasn't that difficult, and made maintaining services much easier. Going to k8s has been challenging, mostly because of how I'm doing it - a controlplane and worker node on each physical node in Proxmox. Writing the YAML is, well YAML.

I'm mostly looking forward to not having to keep my VMs updated. I automated a lot of that (VMs are Packer templates) with Ansible, but it's still annoying. Upgrading k8s nodes is a lot easier, IMO.

Re: My self-hosting infrastructure, fully automated

#198
post #187

Earlier quoted context omitted.

Dependencies of software I didn't write (e.g. Graylog)

This is what I'm getting at. That is an enormous overkill for a single server, and exactly the problem with kubernetes: It drives so much complexity that you kind of need this type of heavy-duty enterprise grade solutions even in an area where you really shouldn't need it. If it's just a single server, you're fine with logrotate and grep.

I like practicing enterprise at home; it makes me feel more comfortable using them at work, where they're needed.

Re: My self-hosting infrastructure, fully automated

#199

I enjoy reading about homelabs that aren't using kubernetes or some other scheduler and how they're doing it/what the full stack looks like. This is just another "how I installed kubernetes" thing only without any real scale behind it. There are other ways to deploy and run things, and it takes people toying around with alternatives for something unique to spring up.

I've used everything under the sun and for homelab use IMO nothing beats using docker-compose and salt. 1. Unless you have crazy dynamic scaling needs, there's literally no point in using k8s or nomad 2. Unless you want RBAC and fine tuned ACL, theres literally no point in using k8s or Nomad I hate this idea that you need a Ceph cluster and a 3 node HA cluster to have a home lab. Not saying don't do it because you wa…

I was settled on Docker-Compose and Ansible for a long time, and while it was indeed quite easy to use once everything was tweaked correctly, what finally got me to move to k8s was HA. Having a single node with nginx, DNS resolution and Unifi controller running on it meant if I ever took the node down down for something, everything broke. Plex being down because I wanted to play with something unrelated wasn't ideal.

Agree that Ceph is ridiculously overkill though, I tried. Longhorn is much easier and perfectly fine for distributed storage.

Post reply on HN