4 ms·

For me, the main benefit of Kubernetes is declarative deployments. You can have the entire deployment automated through this and GitHub actions, without much fi

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.

ben_jones 2y ago
> 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.
- CactusBlue 2y ago
  I mean as in what the big (and small) clouds support. I haven't seen any clouds supporting Hashicorp Nomad or Docker Swarm!
  - SJC_Hacker 2y ago
    You shoudl be able to run any of those things on any cloud. A box with sshd is a box with sshd.
- jitl 2y ago
  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?
paxys 2y ago
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.
- jitl 2y ago
  imo systemd is more complicated than k3s
- everforward 2y ago
  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.
  - lolinder 2y ago
    With Docker Compose you can define volumes, versions, and configs can be volumes that point to a file that lives alongside your compose.yaml.
    - everforward 2y ago
      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).
      - lolinder 2y ago
        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.
  - LorenzoGood 2y ago
    For this, you can use nix with deploy-rs, and define those configurations declaratively.
cqqxo4zV46cp 2y ago
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.
dboreham 2y ago
Use docker compose or ansible for this scenario.
- kikimora 2y ago
  If I have to choose I’d rather learn k8s than ansible.
- SJC_Hacker 2y ago
  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.
lolinder 2y ago
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.
- silverquiet 2y ago
  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.
  - lolinder 2y ago
    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.
firxworx 2y ago
A different angle -- Ansible and many others provide declarative deployments too.
- deathanatos 2y ago
  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."

ben_jones 2y ago

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

CactusBlue 2y ago
I mean as in what the big (and small) clouds support. I haven't seen any clouds supporting Hashicorp Nomad or Docker Swarm!
- SJC_Hacker 2y ago
  You shoudl be able to run any of those things on any cloud. A box with sshd is a box with sshd.
jitl 2y ago
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?

paxys 2y ago

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.

jitl 2y ago
imo systemd is more complicated than k3s
everforward 2y ago
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.
- lolinder 2y ago
  With Docker Compose you can define volumes, versions, and configs can be volumes that point to a file that lives alongside your compose.yaml.
  - everforward 2y ago
    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).
    - lolinder 2y ago
      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.
- LorenzoGood 2y ago
  For this, you can use nix with deploy-rs, and define those configurations declaratively.

cqqxo4zV46cp 2y ago

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.

dboreham 2y ago

Use docker compose or ansible for this scenario.

kikimora 2y ago
If I have to choose I’d rather learn k8s than ansible.
SJC_Hacker 2y ago
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.

lolinder 2y ago

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.

silverquiet 2y ago
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.
- lolinder 2y ago
  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.

firxworx 2y ago

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

deathanatos 2y ago
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."