3 ms·

To be fair, at the small scales you're talking about (maybe 1-2 machines) systemd does the same stuff, just better with less complexity. And there's various muc

To be fair, at the small scales you're talking about (maybe 1-2 machines) systemd does the same stuff, just better with less complexity. And there's various much simpler ways to automate your deployments. If you don't have a distributed system then personally I think k8s makes no sense.

kachapopopow 2y ago
I did say with few machines it can be overkill, but when you have more than a dozen of 2-3 machines or 6+ machines it gets overwhelming really fast. Kubernetes in it's smallest form is around 50MiB of memory and 0.1cpu.
Too 2y ago
How do you deploy to systemd? How do you run a container in systemd? Now you need a second and third system, perhaps Ansible and docker-compose, which is simple on the surface but quickly grows in complexity with home made glue to keep all the loose components together. I agree that for a handful of pet-servers for a team with more existing Linux experience than k8s experience, this is a better starting point, because of the shorter learning curve. Just not kid ourselves that the end product has any less complexity, it's only a different skill set.
- consteval 2y ago
  > How do you deploy to systemd? ... write a unit file and put it in your CI? > How do you run a container in systemd? systemd-nspawn config, which you put in your aforementioned unit files. > perhaps Ansible and docker-compose Definitely don't need docker compose and, in my opinion, don't need Ansible. It's trivial to deploy systemd config and it's trivial to automate. I'm not kidding myself - the complexity is significantly lower. But it only works if you're deploying to one, or two, machines. This won't make a distributed system and I acknowledge that. Not to mention I'm only scraping the surface of what systemd can do here. Containers and automating services is just part of it. There's also remoting logging, monitoring and email alerts, periodic health checks.

kachapopopow 2y ago

I did say with few machines it can be overkill, but when you have more than a dozen of 2-3 machines or 6+ machines it gets overwhelming really fast. Kubernetes in it's smallest form is around 50MiB of memory and 0.1cpu.

Too 2y ago

How do you deploy to systemd? How do you run a container in systemd? Now you need a second and third system, perhaps Ansible and docker-compose, which is simple on the surface but quickly grows in complexity with home made glue to keep all the loose components together. I agree that for a handful of pet-servers for a team with more existing Linux experience than k8s experience, this is a better starting point, because of the shorter learning curve. Just not kid ourselves that the end product has any less complexity, it's only a different skill set.

consteval 2y ago
> How do you deploy to systemd? ... write a unit file and put it in your CI? > How do you run a container in systemd? systemd-nspawn config, which you put in your aforementioned unit files. > perhaps Ansible and docker-compose Definitely don't need docker compose and, in my opinion, don't need Ansible. It's trivial to deploy systemd config and it's trivial to automate. I'm not kidding myself - the complexity is significantly lower. But it only works if you're deploying to one, or two, machines. This won't make a distributed system and I acknowledge that. Not to mention I'm only scraping the surface of what systemd can do here. Containers and automating services is just part of it. There's also remoting logging, monitoring and email alerts, periodic health checks.