101–110 of 120 posts
I really don't get why people make things so complicated. Here's how to fix Kubernetes and systemd: make a non-sucky build system and then use it to build systems. Systemd builds a running system. Kubernetes builds a distributed system. Make a build system that can build both. Then you're golden. And it will also not be monolithic (i.e., it will follow the Unix philosophy) because a build system just hooks together s…
I think there’s a few things in here that I completely unashamedly love.
Ipv6 by default too was something I assumed would make kubernetes easier (since no double NAT traversal).
Since you can’t make a comment on hacker news without having something critical to say: I wish they hadn’t chosen discord for their chat platform; when things like zulip exist for free and are used already by the rust community.
I really don't get why people make things so complicated. Here's how to fix Kubernetes and systemd: make a non-sucky build system and then use it to build systems. Systemd builds a running system. Kubernetes builds a distributed system. Make a build system that can build both. Then you're golden. And it will also not be monolithic (i.e., it will follow the Unix philosophy) because a build system just hooks together s…
So many things in UNIX are monolithic....
systemd is better than "fine" or "great" - systemd is awesome. systemd is a real power tool and the more I learn about it the better I like it. When you need to get something done, systemd often as not has your back. Simple example - recently I needed to ensure a given service could not send more data than a given limit. Easy - systemd includes traffic accounting on a per service basis - all I needed to do was switch…
systemd is better than "fine" or "great" - systemd is awesome. systemd is a real power tool and the more I learn about it the better I like it. When you need to get something done, systemd often as not has your back. Simple example - recently I needed to ensure a given service could not send more data than a given limit. Easy - systemd includes traffic accounting on a per service basis - all I needed to do was switch…
What is the relationship between the users 'andrewstuart', 'andrewstuart2', 'andrewstuart3', and 'customkitchen', if any?
I saw he was commenting in the thread on this page and I said "Hey we're in the same thread!"
Then some other HN joker created an account called andrewstuart3 and joined in the thread.
Now you know!
I do not know what customkitchen is.
Earlier quoted context omitted.
Yes but you need semi-competent people to manage it and have actual ops dept. Then again we got a bunch of racks and our ops dept is 3 people. We have few dozen different apps running on it, anything from "just a wordpress" to k8s cluster (mostly because our customers want us to deploy app they are paying us to develop on k8s). So far the only actual value k8s provides is self-service aspect of it. Nothing that is ru…
I’ve never seen a functioning org that has not had dedicated ops people for their cloud systems. AWS skills are as arcane or more than traditional hardware management skills; I’m not sure I could make the argument in good faith that you need less people overall with cloud. An (anecdotal) example: I worked on an e-commerce SaaS platform responsible for 1% of internet traffic in 2011 with a team of 6 sysadmins, with 60…
And it always ends with a bunch of people doing essentially same thing but with different job title.
> AWS skills are as arcane or more than traditional hardware management skills; I’m not sure I could make the argument in good faith that you need less people overall with cloud.
The main difference is that it is impossible to dig deep. You can do the deep dive, almost to the bare hardware level when you own the hardware. If you just call a bunch of APIs you're essentially talking with black box.
Like, I do not exactly miss the time spent finding out why our Ceph cluster misbehaves and getting to some driver bug causing ~0.5-1% packet drop after few weeks running with irqbalance daemon on, but it is possible and it can be mitigated, meanwhile in cloud, black box, tough shit, live with it.
Earlier quoted context omitted.
So many things in UNIX are monolithic....
Well, yeah, just because the philosophy isn't perfectly followed doesn't mean it's not good to strive for in certain cases. This is one of those cases because it means the build system will be more easily extended and still be simple.
Earlier quoted context omitted.
Systemd do things in as friendly a way as kubernetes? No one should ever confuse kubernetes for user-friendly.
> 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 . How long would it take to get systemd to…
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/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.
Does anyone know if it’s possible to run multiple instances of an app via systemd that all listen on the same port and it does some kind of round robin load balancing to the services? I could introduce my own load balancer proxy like Envoy but I want to reduce complexity as much as possible for systemd to be a viable alternative to k8s.
systemd is better than "fine" or "great" - systemd is awesome. systemd is a real power tool and the more I learn about it the better I like it. When you need to get something done, systemd often as not has your back. Simple example - recently I needed to ensure a given service could not send more data than a given limit. Easy - systemd includes traffic accounting on a per service basis - all I needed to do was switch…