Live data from Hacker News

I host this blog from my garage

eevans.co

41–50 of 68 posts

Re: I host this blog from my garage

#41
post #17

Earlier quoted context omitted.

If all you're ever doing is hosting a static blog, then yeah, you don't need something like Kubernetes; however, if you want to host other services (e.g., database, authentication, comments, etc) then it quickly behooves you to build on some higher-level platform or else you'll end up building your own (poorly) and missing out on all of the experience, documentation, and tooling that are publicly available for Kubern…

Sorry, but we did all of that 20 years ago, and those approaches remain a lot simpler for basic use cases. You know, like serving 100k dynamic pages/hour database backed site. (That's what I was doing 20 years ago, how about you?) See https://pythonspeed.com/articles/dont-need-kubernetes/ for some of the reasons NOT to use Kubernetes for this. With, of course, a giant exception for two cases. The first is, as with th…

> Sorry, but we did all of that 20 years ago, and those approaches remain a lot simpler for basic use cases.

Yeah, we did, and they were complicated then and they're complicated now. The difference is some of us have decades of experience which make them feel simpler.

> And if you think that Kubernetes is always the right approach, then you clearly are NOT aware of the tradeoffs.

I was very explicit that Kubernetes isn't always the right approach. Allow me to quote myself: "If all you're ever doing is hosting a static blog, then yeah, you don't need something like Kubernetes". My point is that things like Kubernetes and Docker Compose are increasingly viable defaults for nontrivial cases. In other words, if you know you're going to have a bunch of services to manage, it's a lot easier for most people (i.e., those lacking decades of experience) to manage them with the aforementioned tools rather than trying to build an equivalent "platform" from scratch.

Re: I host this blog from my garage

#42

Heh, I'm actually more interested in the "garage" piece of the blog which is barely touched on. I also run a home lab, but from my climate-controlled relatively clean basement. I've thought about moving it to the garage, but I'm worried about temperature and dust/dirt ingress. Do you have a sealed cabinet or air filters or any other environmental controls around the servers? Or are you using industrial machines rated…

I have seen production servers run for ten years upstairs a dirty bus repair shop. The room is never cleaned so there's a few millimeters of black dust on everything. In fact you know the age of a server depending on the amount of dust on it. There's a defective A/C unit that sometimes throw some water all around. There's power cut 2 or 3 times a year, the batteries are old so the servers get their hard reboot. As fa…

I spent some time with a computer refurber back in the day. He used to buy old computers from mining operations these things were literally filled to the brim with dust and weird shit.

Computers are amazingly resilient if you don't need them for much more than office work.

Re: I host this blog from my garage

#44
post #17

Earlier quoted context omitted.

Sorry, but we did all of that 20 years ago, and those approaches remain a lot simpler for basic use cases. You know, like serving 100k dynamic pages/hour database backed site. (That's what I was doing 20 years ago, how about you?) See https://pythonspeed.com/articles/dont-need-kubernetes/ for some of the reasons NOT to use Kubernetes for this. With, of course, a giant exception for two cases. The first is, as with th…

> Sorry, but we did all of that 20 years ago, and those approaches remain a lot simpler for basic use cases. Yeah, we did, and they were complicated then and they're complicated now. The difference is some of us have decades of experience which make them feel simpler. > And if you think that Kubernetes is always the right approach, then you clearly are NOT aware of the tradeoffs. I was very explicit that Kubernetes i…

Kubernetes wraps several layers of abstraction around the old way of doing things. There is no world in which the operation of the site is in any way clarified by involving Kubernetes. Kubernetes also adds performance overhead. There are things which are easier with Kubernetes. But only after you've climbed a long learning curve.

From what I've seen, even people without "decades of experiment" find the non-abstracted system easier to understand and reason about than the Kubernetes version. And the difference in ease is dramatic.

Examples where it makes sense include:

1. You need to deploy multiple independent systems with similar configurations. (Even then, consider ansible.)

2. You have to deploy different clusters of connected systems with related, but different, components.

3. You need to scale up and down what needs to be deployed. (Except don't try to use autoscale. That only works in marketing blurbs.)

4. Somebody else has set it up and you never need to actually understand it. (Good luck if you need to debug.)

But there is no reason to introduce Kubernetes because you need a database, a few webservers, front end proxy, failover, etc. And if you are using Kubernetes for that, odds are that you'll save yourself a world of headaches (and potential security holes!) by migrating away. No matter how much the "chief architect" may claim otherwise. I've seen how this plays out in practice.

Re: I host this blog from my garage

#45
I am curious why you use an ingress-nginx deployment. It looks like your blog pod is also running a nginx container, which makes sense. You could just point cloudflared at the service of that pod could you not?

Maybe you just wanted an ingress/metallb setup but I guess I was wondering if it adds anything else to the mix. Maybe some security feature?

Nice post. I am interested in the flux piece. I noticed that Azure Arc uses fluxcd as well. Going to have to give that(flux) a try.

Re: I host this blog from my garage

#46

It's unfortunate that there aren't better solutions for securely exposing a part of your home network to the cloud. Imagine if it were easy to set up a secure solution to access your home lab from anywhere - you could use it as your own private cloud. And perhaps then it would also be easy to expose part of that publicly, like a blog.

I do this with Wireguard.

Re: I host this blog from my garage

#47

I am curious why you use an ingress-nginx deployment. It looks like your blog pod is also running a nginx container, which makes sense. You could just point cloudflared at the service of that pod could you not? Maybe you just wanted an ingress/metallb setup but I guess I was wondering if it adds anything else to the mix. Maybe some security feature? Nice post. I am interested in the flux piece. I noticed that Azure A…

The ingress controller is so I can have multiple public apps and configure them with Ingresses (definitely possible to do the overall setup with just cloudflared but I wanted to use built in ingress objects instead of a complicated cloudflared config).

Re: I host this blog from my garage

#48
post #18

If you wanted to 'publish' a more interactive website to the internet while still keeping all of the publishing tools safe inside an enclave/intranet somewhere, then you probably need a read-only copy of a database. But any time I look at read-replica configurations, it looks like they expect the replica to contact the master. You can't set up a proper bastion server if you have to have a secret door back into your i…

WireGuard

Re: I host this blog from my garage

#49
Fun read, thanks. I've always wondered how to securely do such a thing and cloudfare tunnel looks like a good solution.

Of course the next thing you gotta solve is that you're running 3 HA clusters, but on one host. Can you replicate a backup to a pi somewhere else in your house that enables on emergency fail over, in case a rat chews through the power cable of the garage server?

Re: I host this blog from my garage

#50
post #9
post #6

>Well, hosting a blog from home is probably not a great idea from a practical perspective. I'm not a hater, but maybe he perceives it as not practical here because of all the fun unnecessary complexity. Keeping something like this going for more than a couple years would require complex sysadmin maintainence for updates (which is fun till it isn't). But if you just install nginx from your system repositories, have yo…

(Author here) I mostly worry about security for this. If you have nothing private on your network it's probably fine, but if you have, say, a NAS that isn't using proper authentication (pretty common), an os/nginx vulnerability could end up exposing stuff. Of course there are much simpler ways to lock things down also :)

Then why are you intentionally adding another dozen attack surfaces and bleeding edge stuff constantly full of exploits? nginx remote exploits that matter are a once in a decade thing. Your setup is incomparably more insecure than nginx and a port forward.

I've been running a static webserver from my home for more than 20 years now. By avoiding dynamic languages, databases, and buzzwords, I've never been hacked. Never had any issue.

Post reply on HN