Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

github.com

Post reply on HN
Print view View original

141–150 of 159 posts

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#141

Post by megous »

a-dub wrote: post #133
megous wrote: post #106

Earlier quoted context omitted.

Daemon is just something running in a loop.

actually no. there are a bunch of properties to properly daemonize in unix. things like special handling for stdin/stdout/stderr, reparenting, signal handling... look it up. classic rookie mistake to just call a program that doesn't exit a daemon... proper daemons can stay up for years.

Infinite loop will stay up for years too.

Running "in the background", handling of stdin/out/err, logging, detaching from tty, creating a new process group/session, closing fds, and much more is handled these days mostly by systemd. No need to put all this into your program at all.

I'll give you that signal handling still needs to be done in the target process, if the defaults don't satisfy you.

But you really don't need anything special anymore to make any old script into a daemon.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#142

Post by nonameiguess »

jjeaff wrote: post #113
skynet-9000 wrote: post #46

Earlier quoted context omitted.

Or k3s ( https://k3s.io ), which is Rancher's awesome and lightweight Kubernetes distribution.

I use k3s in production, and it is great. But as far as daily use, it is not any simpler than kuberenetes. Initial setup and clustering is a breeze with k3s. But after that, you are mostly just working with the same k3s api as a full kuberenetes setup.

k3s is kubernetes. Simpler to install and get a cluster running and much smaller, but still kubernetes, with an identical feature set and API. That is part of the point of kubernetes, that it is a standard and anyone can implement it, with Google's original implementation only being a reference, not canonical.

Part of what something like k3s enables is this: https://www.acc.af.mil/News/Article-Display/Article/2557413/...

They don't mention that this was accomplished via k3s, but I happen to know it was because it was colleagues of mine that did this. The point of being able to do something like this is you can deploy a completely identical stack of admin/controller level software to systems running in data centers and systems running in airplanes. As long as they can run kubernetes, you're good to go, and with k3s, just about any piece of hardware can run kubernetes. This has huge implications for defense because it means you can develop and test software that isn't directly responsible for specialized hardware control without having to build emulators or lab equipment identical to what is installed in the actual weapons platforms. You just need to ensure they can both run kubernetes.

It doesn't have to be kubernetes, obviously, but you get the advantage of a fairly rich ecosystem that includes things like k3s, which doesn't even require bash or a shell at all to work.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#143

Post by a-dub »

megous wrote: post #141
a-dub wrote: post #133

Earlier quoted context omitted.

actually no. there are a bunch of properties to properly daemonize in unix. things like special handling for stdin/stdout/stderr, reparenting, signal handling... look it up. classic rookie mistake to just call a program that doesn't exit a daemon... proper daemons can stay up for years.

Infinite loop will stay up for years too. Running "in the background", handling of stdin/out/err, logging, detaching from tty, creating a new process group/session, closing fds, and much more is handled these days mostly by systemd. No need to put all this into your program at all. I'll give you that signal handling still needs to be done in the target process, if the defaults don't satisfy you. But you really don't…

so if your daemon is ever started by hand or is used on a system without systemd it won't work correctly? that doesn't sound great.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#144

Post by rualca »

skynet-9000 wrote: post #138
rualca wrote: post #134

Earlier quoted context omitted.

I don't understand your type of comment. If people involved with a project decide to advertise it on HN, specially following questionable clickbait methods, is it reasonable to demand that all posts must be exclusively comprised of high praises and compliments?

> specially following questionable clickbait methods The title seems both true (for the author's situation) and falsifiable. I don't think it's clickbait.

You should check the discussion because the submitter already admitted that the title was clickbaity.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#145

Post by megous »

a-dub wrote: post #143
megous wrote: post #141

Earlier quoted context omitted.

Infinite loop will stay up for years too. Running "in the background", handling of stdin/out/err, logging, detaching from tty, creating a new process group/session, closing fds, and much more is handled these days mostly by systemd. No need to put all this into your program at all. I'll give you that signal handling still needs to be done in the target process, if the defaults don't satisfy you. But you really don't…

so if your daemon is ever started by hand or is used on a system without systemd it won't work correctly? that doesn't sound great.

Only time I'm starting daemon by hand is to debug it. So having it stay in foreground and log to console is good in that case.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#146

Post by johnnycerberus »

humbleMouse wrote: post #109
motoboi wrote: post #20

Kubernetes might follow the sad path of spring. Perfect, complete and too complex. For big and great applications, spring if the obvious choice. It makes incredible complex and difficult things easy. But, unfortunately, makes simple and quick applications incredible complex and difficult.

The hate against spring on hacker news is so ridiculous. Spring boot is one of the easiest lowest boilerplate ways to build anything, period. Especially if you use a type dynamic language on top, like groovy or kotlin or whatever.

Some people are just masochistic or they just want to distract themselves by solving problems that have already been solved by Spring circa 10 years ago. Most of them don't even use the technology that they preach around here, it's borderline trolling.

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#147

Post by a-dub »

megous wrote: post #145
a-dub wrote: post #143

Earlier quoted context omitted.

so if your daemon is ever started by hand or is used on a system without systemd it won't work correctly? that doesn't sound great.

Only time I'm starting daemon by hand is to debug it. So having it stay in foreground and log to console is good in that case.

so if someone else starts it by hand it won't work correctly?

if someone else runs it on a system without systemd it won't work correctly?

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#148

Post by l0b0 »

thomasbacklund wrote: post #131
l0b0 wrote: post #130

Unsolicited review of sync.sh ahoy! The easy stuff: - Non-exported variables are by convention lower_case, while exported variables are UPPER_CASE. - Function names are by convention lower_case. - There's a "quite" signature string and variable; should it be "quiet"? - The lines like `local hosts=` can be simplified as `local hosts`. You can also join such lines, as with `export`, into `local foo bar baz …`. - `[[` i…

Thanks for taking the time l0b0! A lot of good points. Coding in shell sure is a challenge, I try to avoid bashims where I can, that's why most scripts are .sh not .bash, since they run also with dash/ash (that's why preferring `[` over `[[`). The only Bash requirement we have is the `podc` (pod compiler) since it parses YAML docs, I couldn't pull that one off without the more powerful Bash. The code base as a whole…

Very good reasons all round. Good luck, we need simpler solutions in the cloud space!

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#149

Post by megous »

a-dub wrote: post #147
megous wrote: post #145

Earlier quoted context omitted.

Only time I'm starting daemon by hand is to debug it. So having it stay in foreground and log to console is good in that case.

so if someone else starts it by hand it won't work correctly? if someone else runs it on a system without systemd it won't work correctly?

Why would it not work correctly?

Without systemd you can use daemonize from shell, for example. I either run these kinds of service scripts via systemd in production, or via my special program that takes care of starting and monitoring, and restarting when the code of the script changes.

Why should I stuff daemonization machinery into every single script I might want to run as a daemon, especially when it's cumbersome in many languages where I want to do it, like bash or PHP, and in general less flexible than using some external tool?

Re: Show HN: Simplenetes – I replaced Kubernetes with 17k lines of shell script

#150

Post by karmakaze »

johnnycerberus wrote: post #139
karmakaze wrote: post #33

Earlier quoted context omitted.

Not in any particular order (choose what fits your team): Kotlin or Java and a lighter framework (e.g. Javalin is to Spring as Sinatra is to Rails, with JDBI), a newer big framework (e.g. Micronaut, maybe Play, others), Phoenix/Elixir, Rails/Ruby+Sorbet, Go with libraries. Edit: I just did a google search for "Java Framework" and get a lot of useless top-N lists with old content retitled "in 2020" with hits like: Hib…

Cmon, you can't be serious, do you really recommend Play, Micronaut, etc. over Spring ecosystem? Also if you want the benefits of GraalVM you can stay in the ecosystem today with Spring Native, moreover if you are ideologically against Spring then you should go with Quarkus because that's the next technology by maturity/popularity. How can you not go with Spring when REST services are today a solved problem? Why do y…

I'm not ideologically against Spring since I mentioned Micronaut being a modern take on it, without the outdated assumptions. I'm not familiar with Quarkus but someone else recommended it so may have a look at it. I'm currently at a Rails shop, but I see patterns evolving as teams get larger toward program construction patterns like Spring, persistence, repository, application model, etc. ActiveRecord as big as it is, is still much simpler than Spring/Hibernate with an EntityManager.

BTW, I did work at a startup for years building microservices with Spring which is where I ran into it's limitations. I basically worked around the EntityManager, JPQL, and query template caching where ever it was necessary, which was frequent. I'm not against query builders or data mappers, having worked on making one myself[0]. I'm just more performance/resource conscious than most.

[0] https://github.com/karmakaze/safeql

Post reply on HN