Live data from Hacker News

My self-hosting infrastructure, fully automated

github.com

211–220 of 228 posts

Re: My self-hosting infrastructure, fully automated

#211
post #77
post #57

Earlier quoted context omitted.

I've come from bare metal, to virtualisation, to Cloud. I then went from AutoScaling Groups and AMIs to K8s and Docker Images. Recently I went from K8s to Nomad+Consul and Docker Images. Now I'm building a small platform to host a business I've started and I'm going back to ASGs with simple EC2 Instances. There's really no need for the features Nomad/K8s offer at almost any scale outside of a few big companies.

It depends. Orchestrators like Nomad can give you a lot of leverage as a small team. It's not very difficult to manage and can give you lots of redundancy, control, and a path to scalability while utilizing best practices so you don't have to think about it. There are lots of ways to do this and not every app needs this but as you begin to get traction, you either have a choice of outsourcing your devops or bringing…

Orchestration engines can give you a lot of leverage if you run a managed solution because all you're doing there is deciding on the size you need and providing a credit card number. This is absolutely a great way of your DevOps to the next level with little effort.

If you're going DIY, however, then you're not doing yourself any favours by starting out with an orchestration engine.

In the case of Nomad you'll also need Consul for it to be truly useful. That means six EC2 Instances (for example) for a truly production trade system - 3x for Nomad, 3x for Consul. Of course you also need mTLS as well - may as well throw Vault into the mix too, then... that's another three EC2 Instances to support that cluster... 9x EC2 Instances into the DIY solution and all you have is an orchestration engine and you've not even started on the workers yet. That cost so far is USD$30,416.04 for the reference architecture for all nine nodes: https://learn.hashicorp.com/tutorials/consul/reference-archi...

On the other hand if you keep it simple and just work with AMIs you bake your self when you need to release something new, you need two EC2 Instances. The cost of the compute resources for this for 12 months: UDSD$330.

There's no raft consensus which needs three nodes to be stable (but a single AZ failure can result in split brain, so really you need five AZs), no new technologies to understand, no new vendor to work with or pay capital to, nothing more to support.

These things - these orchestration engines - have their place, and that place is outside of 99.9% of businesses (large or small.)

As for moving away from Nomad: too expensive and too complex. I ran Consul, Nomad and Vault on the same master instances (which is a risk and against best practice) without mTLS (just TLS) and it took a week to get it all running. None of that includes monitoring, backups, auto-scaling, etc.

I believe the work involved with going DIY on the orchestration front is not worth the benefits in the short to medium term. In the long term you'll likely outgrow your own simpler solution and at which point you'll likely have the capital to switch to a managed service anyway /shrug

It's all relative, after all.

Re: My self-hosting infrastructure, fully automated

#212

Earlier quoted context omitted.

Yea I think I missed the whole web-complexity bus and am probably out of touch, but I still don’t get the use case for docker and containers and kubernets and and orchestration and all that stuff, just for a simple home setup. I serve a tiny web site, email, backups, a NAS and a few other internet services for my family, and my “stack” is vanilla Debian Stable. Maybe I don’t know what I don’t know, but my setup works…

> but I still don’t get the use case for docker and containers and kubernets and and orchestration For docker there's a simple motivating case: some services are difficult to configure securely with minimal permissions, and having a standard docker image provided by people who know what they're doing would be a big net win for security on the internet. There are a lot of poorly configured and insecure http server's o…

I would argue that poorly configured docker images as far bigger issue than insecure http servers: https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... Security wasn’t the motivation imho, but being able to package your app with all it’s dependencies, including OS libs and deliver it extremely easy, sure was.

Re: My self-hosting infrastructure, fully automated

#213
post #211
post #77

Earlier quoted context omitted.

It depends. Orchestrators like Nomad can give you a lot of leverage as a small team. It's not very difficult to manage and can give you lots of redundancy, control, and a path to scalability while utilizing best practices so you don't have to think about it. There are lots of ways to do this and not every app needs this but as you begin to get traction, you either have a choice of outsourcing your devops or bringing…

Orchestration engines can give you a lot of leverage if you run a managed solution because all you're doing there is deciding on the size you need and providing a credit card number. This is absolutely a great way of your DevOps to the next level with little effort. If you're going DIY, however, then you're not doing yourself any favours by starting out with an orchestration engine. In the case of Nomad you'll also n…

There's no need to go truly production grade initially. I run some projects in production on single node deployments (with Nomad, Vault, and Consul all on one node, i.e. bootstrap_expect = 1) and it's solid. The hardware specs required are no different than if you were to just use systemd to run everything.

The beauty with HashiStack is you don't need to go fully monty. There's also no need to use ACLs which I agree adds a lot of unnecessary complexity if you're only at the MVP phase or doing things solo/in a small team. And you can run everything on a Digital Ocean $10/mo droplet -- it's very lightweight. I even have one HashiStack deployed on a Raspberry Pi running Home Assistant and other ancillary wares and it works great. But there's always the path to building a proper cluster if you need the redundancy.

I'm very bullish on HashiCorp. They can do a much better job though of communicating that not every deployment needs to be enterprise-grade and offer better ways of bootstrapping the type of cluster that fits your needs. I think a lot of that messaging gets lost due to their ongoing war with Kubernetes and what large companies are looking for.

Re: My self-hosting infrastructure, fully automated

#214
post #203
post #201

Earlier quoted context omitted.

Nothing happens to the data -- it's still intact when the host comes back up. Happy to clarify further though if that's not what you meant.

Ah, so your systems are down until you fix a node, and if the drive(s) fail you have a dead node you're stuck restoring backups. I guess that's fine, I'm just used to having labs to test how I can avoid single instance failures. :)

The path to redundancy is there if you need it but it's not something you have to go with from the start. You can also run a database with replicas to handle any drive failures, etc. I have been running a production-grade system with thousands of customers like this for a few years.

Re: My self-hosting infrastructure, fully automated

#216
It's sad to see so many people that are dismissive of this setup, because they have some preconceived notions about Kubernetes and other tooling that's used. What has happened to curiosity? Of course nothing about this is "necessary", but the fun is in trial and error. In my experience running Kubernetes in my homelab and colo, every issue has been a learning opportunity, and was usually because of my own mistakes.

Re: My self-hosting infrastructure, fully automated

#217
post #205

Earlier quoted context omitted.

Sure, using K8S in your learning envornment because you're managing 800 different services in your dayjob is fine. Personally I have my learning environment as part of my day job though. At home I just want things to work, hence a nice simple LAMP

Agreed. I don't even want Kubernetes at work.

I can see benefits of something like ansible if you have a command-and-control environment where you deploy 300 machines from a central database. Still allows you destroy 300 machines in one single misconfiguration or mishandled error though, ouch. If you have a federated environment where you have many actors all managing their own machines though I don't see the point.

The number of times I have to do something to the 160 machines I'm responsible for is about 3 times a year. Clusterssh does the job in 10 minutes, and inevitably shines a light on some unexpected error somewhere. If I was doing it on a weekly basis though, using ansible would be beneficial.

Personally I don't like ansible's way of throwing everything in a file in /tmp, then running it as root. authlog gets sent to my central syslogs servers so I've got a record of what happened. With ansible I'm never quite sure, and I'd have to look in two different places for logs.

Instead we just have a lightweight phone home agent which reports processes/diskspace/mounts/interfaces/hostname/ownership etc so you can identify who owns a device on your network and what it's responsible for without consulting out of date documentation that relies on humans to do things.

Kubernetes I guess is useful if you're building a cluster of 100 machines scaling and doing the same service because you're handling a million users a day. Most companies don't do that, most services don't need that.

Use the right tool for the right job, and don't assume the stuff google use is the right tool (unless you're building a lab because you want experience to get a job working for google. If you tried that shit on my network you'd be starting your job search far earlier)

Re: My self-hosting infrastructure, fully automated

#218

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.

> homelabs that aren't using kubernetes or some other scheduler and how they're doing it/what the full stack looks like.

I've had great success with Ansible+Proxmox. The proxmox CLI interface is good enough that you can basically do DIY terraform like setup straight against CLI without any agents / plugins etc. (I know declarative vs imperative but hopefully the comparison makes sense)

Lately I've been toying with local gitlab-CI building and deploying images directly into the environment so that any changes to the code redeploy it (to prod...this is home after all haha)

Considered terraform too but not a big fan of their mystery 3rd party plugin provider system

Re: My self-hosting infrastructure, fully automated

#219
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.

I just stumbled on a self hosted project similar to tailscale: https://github.com/gravitl/netmaker . There is also https://github.com/juanfont/headscale which is an open sourced implementation of the Tailscale coordination server. Tailscale "just works" and makes things incredibly easy for personal use, but it's awesome that there are also similar self-hosted options out there

What about zerotier for an alternative? Seems to have a bit more market and mindshare (and thus perhaps continuity).

Re: My self-hosting infrastructure, fully automated

#220

Earlier quoted context omitted.

> but I still don’t get the use case for docker and containers and kubernets and and orchestration For docker there's a simple motivating case: some services are difficult to configure securely with minimal permissions, and having a standard docker image provided by people who know what they're doing would be a big net win for security on the internet. There are a lot of poorly configured and insecure http server's o…

I would argue that poorly configured docker images as far bigger issue than insecure http servers: https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabi... Security wasn’t the motivation imho, but being able to package your app with all it’s dependencies, including OS libs and deliver it extremely easy, sure was.

> I would argue that poorly configured docker images as far bigger issue than insecure http servers

I think the number of router vulnerabilities alone refutes this argument. Yes, security wasn't the original motivation, but it could be one good motivation.

Post reply on HN