Hacker News Reader

Comment by CactusBlue | Hacker News Reader

For me, the main benefit of Kubernetes is declarative deployments. You can have the entire deployment automated through this and GitHub actions, without much fiddling with the production environment manually. I know, it's overkill and I don't like it that much either, but it's the industry standard.

View on HN

For a tiny deployment like this, Docker Compose gets you declarative deployments in much the same way with arguably a much smaller learning curve and fewer moving parts.

I self-host ~10 services on a single physical server in my home, defined in a series of docker-compose.yaml files stored in a git repo. It's trivial to set up, declarative, and easier to run locally than k8s.

It’s a bit weird to me to mention compose and kubernetes without bringing up Docker Swarm which feels like a nice middle ground. We actually run it at my very small SaaS company and it seems like a good fit for us though it’s still relatively early days for us; it’s been a very slow transition.

I've never used Swarm myself, so I don't recommend it. I've heard several people like you, though, who found it works.

Obviously not needed for a single node, though.

Overkill is an understatement and “industry standard” is a misrepresentation. There are PLENTY of more appropriate options here, for this scale, without going off the beaten track. This is wanting to use the big kids’ tools when it doesn’t make sense to.

You can get declarative deployments via a systemd config. If you really want to use Docker then use a Compose file.

If jobs are what you are concerned about then I can assure you no company is skipping on software developers because they don't know Kubernetes syntax.

That doesn't capture the same thing. It doesn't capture volumes, versions of binaries, nginx/postgres/whatever configs, etc.

Ansible/Salt/Puppet/Chef/CFEngine are closer comparisons.

With Docker Compose you can define volumes, versions, and configs can be volumes that point to a file that lives alongside your compose.yaml.

Sure, depending on how you want to draw a line around features. Compose won’t do multi-node orchestration of deploys (I.e. update backends 1-3 sequentially, and revert the change on all of them if any fail to deploy).

It also doesn’t manage your configs; ie if you need to roll back, it won’t do that for you (though git will let you do that pretty easily).

I think Compose is great for the niches it serves; I have a lot of stuff that still runs on Compose because it doesn’t need any k8s stuff yet. I just don’t think it can be honestly called a k8s replacement. Compose offers equivalent features for some kinds of apps in certain situations, but k8s is a broader tool by far (for better or worse).

Agreed—people on here are only recommending compose because OP only has the single node, which places their app squarely within the realm of what compose is very good at.

For this, you can use nix with deploy-rs, and define those configurations declaratively.

imo systemd is more complicated than k3s

Use docker compose or ansible for this scenario.

Those seem like different things, I thought Ansible was more for configuring individual boxes.. then you would use something like Helm to configure Kubernetes.

Tech stack at my last workplace was insane like that. To deploy, they woud have a Buildkite job would launch Terraform, which would then be configured by Ansible, then k8s would deploy on the cluster. I think they could have avoided all this ess k8s and probably Terraform and gotten away with one big box and shell scripts (which they had plenty of anyway), and used swarm/compose, but what do I know.

If I have to choose I’d rather learn k8s than ansible.

A different angle -- Ansible and many others provide declarative deployments too.

No, … Ansible is not declarative. Nowhere near the same as a k8s workload.

And I know they say that, but it's more or less YAML-as-a-programming language. It is pretty trivial to have side-effects that will persist well beyond and outside an Ansible playbook.

It's certainly better than a complete snowflake of a VM, but it's really closer to saying "we init this VM with this shell script."

> but it's the industry standard.

I strongly disagree with this statement. Even at the most bubbly of Silicon Valley events you will not see kubernetes for a smaller deployment be an industry standard.

It’s ok to make architectural mistakes, or otherwise over engineer a thing. We all do it. Let’s not standardize it.

And to your credit thank you for publishing this example as a learning opportunity to others.

k3s is a teensy sqlite based orchestrator, something tons of devs run on their laptops for local dev. I think those are all single box clusters, why is it crazy to run it on a server but not a laptop?

I mean as in what the big (and small) clouds support. I haven't seen any clouds supporting Hashicorp Nomad or Docker Swarm!

You shoudl be able to run any of those things on any cloud. A box with sshd is a box with sshd.

Reply on news.ycombinator.com