3 ms·

> No one should ever confuse kubernetes for user-friendly. Kubernetes is user-friendly, specially when compared to each and any of its alternatives. And more

> No one should ever confuse kubernetes for user-friendly. Kubernetes is user-friendly, specially when compared to each and any of its alternatives. And moreso when compared with systemd. We live in a day and age where it's possible to get a whole web app up and running in a Kubernetes cluster from a fresh Ubuntu install with a single snap installation and a kubectl apply -k <kustomize dir>. How long would it take to get systemd to containerize a single app?

tadfisher 4y ago
systemd-nspawn -x -a [command] [args]
mike_hearn 4y ago
Isn't that skipping the work involved in writing the kustomize directory? Seems like Kustomize [1] was explicitly created to make Kubernetes easier to use, also. Anyway, you're right in the general case, but specific cases really depend on how complicated your app actually is. If we're allowed to introduce extra tools then gosh darn it I'm going to promote Conveyor again because in that case it gets easier to use systemd too. Here's what a server config looks like: https://gist.github.com/mikehearn/5485a7343d9fe838d33d0b028161ae35 https://gist.github.com/mikehearn/5485a7343d9fe838d33d0b0281... All of ~25 lines, some of which is just optional demo stuff. To use it you'd compile your app (a JVM app in this case), run "conveyor make debian-package", upload the resulting package and install it with "apt install ./whatever.deb". Or alternatively upload it to a static file server (s3 bucket or whatever) and then run "apt-get update && apt-get upgrade" on each host. The server will start/restart automatically. It's not containerized in the Docker sense but it does run in a lightweight sandbox using the DynamicUser feature, and you can lock it down further if you want by setting the right systemd keys. Now, you're going to say that Kubernetes does a lot more for you, that it can deploy many kinds of apps simultaneously, configure networking, let replicas find each other etc and so it's easier to use for 'real' apps. Granted, all true. The above workflow isn't optimized, does less and would need more work to be competitive. Also the resulting packages assume there's an apt repository somewhere, which takes a bit of work to set up (this isn't strictly needed in the server case and we'll fix it at some point). Still, whilst maybe it's better for everyone to just learn Kubernetes at some point, but a lot of us have learned Linux/UNIX in the past and have needs that can be met cheaply with that toolset. [1] https://kustomize.io/ https://kustomize.io/

tadfisher 4y ago

systemd-nspawn -x -a [command] [args]

mike_hearn 4y ago

Isn't that skipping the work involved in writing the kustomize directory? Seems like Kustomize [1] was explicitly created to make Kubernetes easier to use, also. Anyway, you're right in the general case, but specific cases really depend on how complicated your app actually is. If we're allowed to introduce extra tools then gosh darn it I'm going to promote Conveyor again because in that case it gets easier to use systemd too. Here's what a server config looks like: https://gist.github.com/mikehearn/5485a7343d9fe838d33d0b028161ae35 https://gist.github.com/mikehearn/5485a7343d9fe838d33d0b0281... All of ~25 lines, some of which is just optional demo stuff. To use it you'd compile your app (a JVM app in this case), run "conveyor make debian-package", upload the resulting package and install it with "apt install ./whatever.deb". Or alternatively upload it to a static file server (s3 bucket or whatever) and then run "apt-get update && apt-get upgrade" on each host. The server will start/restart automatically. It's not containerized in the Docker sense but it does run in a lightweight sandbox using the DynamicUser feature, and you can lock it down further if you want by setting the right systemd keys. Now, you're going to say that Kubernetes does a lot more for you, that it can deploy many kinds of apps simultaneously, configure networking, let replicas find each other etc and so it's easier to use for 'real' apps. Granted, all true. The above workflow isn't optimized, does less and would need more work to be competitive. Also the resulting packages assume there's an apt repository somewhere, which takes a bit of work to set up (this isn't strictly needed in the server case and we'll fix it at some point). Still, whilst maybe it's better for everyone to just learn Kubernetes at some point, but a lot of us have learned Linux/UNIX in the past and have needs that can be met cheaply with that toolset. [1] https://kustomize.io/ https://kustomize.io/