4 ms·

How many things do you self host and how do you manage them all?

abound 3y ago
$ kubectl get deployments.apps | wc -l 25 Minus the header, looks like ~24. I use a single-node Kubernetes cluster running Talos [1]. Running a single-node cluster is kinda dumb architecturally, but adding a new service takes <10 minutes most of the time, which is nice. I've standardized on Cuelang [2] for my configs, so adding a new service is some DNS/Caddy config fiddling, then: deployment: <service>: spec: template: spec: { containers: [{ ports: [...] command: [...] volumeMounts: [...] }] volumes: [...] } And then running: cue export \ --out yaml \ --expression 'deployment.<service>' \ --expression 'service.<service>' \ kube.cue <service>/<service>.cue | kubectl apply -f - Where `kube.cue` sets reasonable defaults (e.g. image is <local registry>/<service>). The "cluster" runs on a mini PC in my basement, and I have a small Digital Ocean VM with a static IP acting as an ingress (networking via Tailscale). Backups to cloud storage with restic, alerting/monitoring with Prometheus/Grafana, Caddy/Tailscale for local ingress. [1] https://www.talos.dev/ https://www.talos.dev/ [2] https://cuelang.org/ https://cuelang.org/
- reidjs 3y ago
  Interested in how you're using DO as an ingress. I currently run a droplet that's reaching its capacity because I'm running all the services directly on that underpowered machine. I would much rather run them from a local computer. Is it pretty straightforward to set that kind of thing up with tailscale?
  - abound 3y ago
    Indeed! I use Headscale (though hosted Tailscale will work just fine), DO hosts the controlplane, and is also on the tailnet itself. My Caddy config has something like: <list of public hosts> { reverse_proxy 100.64.0.<mini PC> } The mini PC IP is a Tailscale container in a pod with a second Caddy instance that routes within the cluster. For sensitive/personal services, they're only configured in the cluster-internal Caddy config, and thus only accessible over the tailnet. One can optionally add other "hardening" at the DO layer, like Crowdsec, to minimize automated/malicious/bot traffic into your home.

$ kubectl get deployments.apps | wc -l 25 Minus the header, looks like ~24. I use a single-node Kubernetes cluster running Talos [1]. Running a single-node cluster is kinda dumb architecturally, but adding a new service takes <10 minutes most of the time, which is nice. I've standardized on Cuelang [2] for my configs, so adding a new service is some DNS/Caddy config fiddling, then: deployment: <service>: spec: template: spec: { containers: [{ ports: [...] command: [...] volumeMounts: [...] }] volumes: [...] } And then running: cue export \ --out yaml \ --expression 'deployment.<service>' \ --expression 'service.<service>' \ kube.cue <service>/<service>.cue | kubectl apply -f - Where `kube.cue` sets reasonable defaults (e.g. image is <local registry>/<service>). The "cluster" runs on a mini PC in my basement, and I have a small Digital Ocean VM with a static IP acting as an ingress (networking via Tailscale). Backups to cloud storage with restic, alerting/monitoring with Prometheus/Grafana, Caddy/Tailscale for local ingress. [1] https://www.talos.dev/ https://www.talos.dev/ [2] https://cuelang.org/ https://cuelang.org/

reidjs 3y ago
Interested in how you're using DO as an ingress. I currently run a droplet that's reaching its capacity because I'm running all the services directly on that underpowered machine. I would much rather run them from a local computer. Is it pretty straightforward to set that kind of thing up with tailscale?
- abound 3y ago
  Indeed! I use Headscale (though hosted Tailscale will work just fine), DO hosts the controlplane, and is also on the tailnet itself. My Caddy config has something like: <list of public hosts> { reverse_proxy 100.64.0.<mini PC> } The mini PC IP is a Tailscale container in a pod with a second Caddy instance that routes within the cluster. For sensitive/personal services, they're only configured in the cluster-internal Caddy config, and thus only accessible over the tailnet. One can optionally add other "hardening" at the DO layer, like Crowdsec, to minimize automated/malicious/bot traffic into your home.