depending on what, exactly "bash commands don't work" <https://github.com/Megapixel99/nodejs-k8s/blob/master/functi...> is talking about, but a thing that bites A LOT of folks when dealing with command: [] (and its args:[] friend) is that they are exec style, not "sh -c" style as one might experience with a Dockerfile RUN command. I think Dockerfile's RUN [""] syntax is also exec style, but I don't use it much because it's horrifically verbose
As a concrete example, command: ["bash -c uptime"] will not work because there is no such command '/usr/bin/bash -c uptime' and the actual form is command: ["bash", "-c", "uptime"]
Related, it often bites people that exec does no shell interpolation, neither resolving variables nor redirection, so command: ["doit", ">/dev/null"] will not shake out, nor will command: ["echo", "$HOSTNAME"] (although there is a nuance to that since kubernetes itself will actually resolve any env:[] references in a (regrettably horrible) syntax of command: ["echo", "$(USERNAME)"], env: [{name: USERNAME, value: megapixel99}]
Really a feature though. No quote issues, no shell interpolation, explicit variable resolution in the application’s scope — for most scripts I much prefer this as the default behavior.
Off the top of my head I do not remember what the issue was (the changes to the code are from a month ago). Looking at the code now, `dockerExec` <https://github.com/Megapixel99/nodejs-k8s/blame/master/funct...> uses `child_process` so that may have something to do with it... however, as I have said in other replies, I just wanted to learn more about the inner workings of k8s and I personally learn best when I create (or recreate) something, I doubt this project will take off, but if it does I will try to fix that when the time comes.
I may read the source code to your project for fun.
If you ever feel inspired to do so, I *really* wish somebody would write a decent way to do controllers in JS rather than golang (metacontroller is a lovely idea but somewhat limited in what you can build with it).
I would really welcome more experimentation in the cluster process management space. Right now it's Kubernetes, Nomad, or solutions embedded into applications (e.g. cephadm).
It's a shame that this is an exact copy in a different language.
Kubernetes is nice but I can't wait to see what the next generation of tools will look like.
I really wish Flynn[1] had taken hold before Kubernetes became so popular. Deploying and managing apps was a hell of a lot less complex, and very Heroku-like.
Sadly, it's no longer being developed as of 3-4y ago.
I was thinking about making something that could compete with kubernetes, but I also wanted to use this project to learn more about the inner workings of kubernetes since I personally learn best when I create (or recreate) something.
Maybe in the future I will create something that could be a competitor.
Not to be audacious, but I’m working on a post and will HN Show it, soon.
It’s called “lattice”, and it’s a software architecture with similar intentions as Kubernetes, but a vanilla approach that leans into existing frameworks instead of inventing things from scratch
Haha so true. I noticed there's a part of HN that hates JavaScript and NoSQL.
Usually for bad reasons like a false dichotomy between SQL & NoSQL (you usually want both) or some performance comment about JS when they're using like a Rails, Django, or Laravel (some old/slow cult framework that doesn't hold a candle to Node).
Feels like Rust found its place with Next.js' Turbopack (basically Webpack but in Rust), and is good for use cases like that. I think reinventing wheels in other languages makes sense when they bring obvious value like performance or some convenience - and this Show HN fits that description.
Like someone else said - it might've been even cooler as not a re-write but a new approach in Node.
I would love to see Node eat more of Linux personally. To me JavaScript is like the "English" of programming (C is "Latin"?), with JSON being the standard transfer format and the browser being a major (if not the major) platform. Not to mention it's by far the most performant of the dynamic web languages (compared with PHP, Ruby, Python).
While I am not opposed to creating something that could be a competitor I wanted to learn how k8s worked. I suspect I would be hesitant to create the specs though.
1. Speed: NoSQL is way faster than SQL for most access
2. Ease: Dev time is lower as the data is kept in the way you'll use it, not in relational tables - skip the ORM, skip the db migrations, etc.
3. You need NoSQL at scale anyway: As the sole db of an app, NoSQL isn't ideal at scale because of data duplication and storage size. But when/if you need to add SQL you probably still keep the NoSQL too for the faster access, storing temp data, etc. Most companies use both SQL and NoSQL.
Scenario:
Imagine an API for a video game that fetches data for an Auction House type feature. If every single time your millions of players were running SQL queries, it would be an incredibly slow and expensive feature. Much better to have that data cached in a NoSQL layer so people can access it quickly/concurrently, and only periodically hit SQL to populate out NoSQL caches. Could also use an ORM with SQL, or another in-memory solution, but NoSQL is nice if there are many nodes or maybe due to your cloud setup you can't run it in memory.
Really is not a "SQL vs NoSQL" you use both for different things. To me at this point it doesn't matter if someone "starts with" SQL or NoSQL, in almost all cases I would use both eventually. For hobby projects, even a slight preference toward NoSQL for ease of use and data flexibility, but getting into subjective territory. Sequelize is just as cool/easy
It is the database I am most comfortable with, if this project were to ever blow up (which I highly doubt) I would want to add support for other databases.
Kubernetes' API-server is a fairly small shim over etcd, another ReST data-store. MongoDB provides a similar web-ful data-store that probably greatly eases implementation, is low-impedance.
Not that I would do the same, but I can understand to some degree.
It kinda makes sense if you render objects as json (vanilla apiserver use protobufs on the wire except for crds). Im curious if mongodb supports CAS semantic properly - i heard transactions are still a pain there
Readit News
As a concrete example, command: ["bash -c uptime"] will not work because there is no such command '/usr/bin/bash -c uptime' and the actual form is command: ["bash", "-c", "uptime"]
Related, it often bites people that exec does no shell interpolation, neither resolving variables nor redirection, so command: ["doit", ">/dev/null"] will not shake out, nor will command: ["echo", "$HOSTNAME"] (although there is a nuance to that since kubernetes itself will actually resolve any env:[] references in a (regrettably horrible) syntax of command: ["echo", "$(USERNAME)"], env: [{name: USERNAME, value: megapixel99}]
All in all, congratulations on your Show HN!
Regardless, thank you for the feedback.
If you ever feel inspired to do so, I *really* wish somebody would write a decent way to do controllers in JS rather than golang (metacontroller is a lovely idea but somewhat limited in what you can build with it).
It's a shame that this is an exact copy in a different language.
Kubernetes is nice but I can't wait to see what the next generation of tools will look like.
Sadly, it's no longer being developed as of 3-4y ago.
[1]: https://github.com/flynn/flynn
Maybe in the future I will create something that could be a competitor.
It’s called “lattice”, and it’s a software architecture with similar intentions as Kubernetes, but a vanilla approach that leans into existing frameworks instead of inventing things from scratch
Kubernetes in Rust: Straight to the top
Usually for bad reasons like a false dichotomy between SQL & NoSQL (you usually want both) or some performance comment about JS when they're using like a Rails, Django, or Laravel (some old/slow cult framework that doesn't hold a candle to Node).
Feels like Rust found its place with Next.js' Turbopack (basically Webpack but in Rust), and is good for use cases like that. I think reinventing wheels in other languages makes sense when they bring obvious value like performance or some convenience - and this Show HN fits that description.
Like someone else said - it might've been even cooler as not a re-write but a new approach in Node.
I would love to see Node eat more of Linux personally. To me JavaScript is like the "English" of programming (C is "Latin"?), with JSON being the standard transfer format and the browser being a major (if not the major) platform. Not to mention it's by far the most performant of the dynamic web languages (compared with PHP, Ruby, Python).
1. Speed: NoSQL is way faster than SQL for most access
2. Ease: Dev time is lower as the data is kept in the way you'll use it, not in relational tables - skip the ORM, skip the db migrations, etc.
3. You need NoSQL at scale anyway: As the sole db of an app, NoSQL isn't ideal at scale because of data duplication and storage size. But when/if you need to add SQL you probably still keep the NoSQL too for the faster access, storing temp data, etc. Most companies use both SQL and NoSQL.
Scenario:
Imagine an API for a video game that fetches data for an Auction House type feature. If every single time your millions of players were running SQL queries, it would be an incredibly slow and expensive feature. Much better to have that data cached in a NoSQL layer so people can access it quickly/concurrently, and only periodically hit SQL to populate out NoSQL caches. Could also use an ORM with SQL, or another in-memory solution, but NoSQL is nice if there are many nodes or maybe due to your cloud setup you can't run it in memory.
Really is not a "SQL vs NoSQL" you use both for different things. To me at this point it doesn't matter if someone "starts with" SQL or NoSQL, in almost all cases I would use both eventually. For hobby projects, even a slight preference toward NoSQL for ease of use and data flexibility, but getting into subjective territory. Sequelize is just as cool/easy
I find NoSQL document databases harder to maintain over time, and you can always have tables with JSON columns.
But moreover, my question was about MongoDB, not about SQL vs NoSQL. And it has been answered, the developer was familiar with it.
Not that I would do the same, but I can understand to some degree.