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).
Full disclosure I haven’t tried this but I’m curious if you have. The main component of a controller is its k8s client, so go will always have an advantage, but this JS client looks somewhat decently maintained
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
Docker Swarm mode has been in maintenance mode for at least 5 years now. It's way to late to bet the house on a product that exists pretty much to support people that have bet on it, not to completely pull the rug under their feet.
I introduced Docker Swarm at work in 2018 and already there were rumours that since Kubernetes had won it was just a matter of time until Docker Swarm was fully abandoned.
What's strange is Docker Compose is very slowly resurging. I almost feel like that with a few more primitves (e.g. nodes with tags) and you'd have a much simpler Kubernetes. Which a lot of people might like.
I agree it would, and I think it's unlikely, but I also think there's a gap between Docker Compose and Kubernetes, and while I know the implementation gap is large, the configuration syntax gap is small. If someone could extend the Compose syntax to include some sort of way to declare what node tags it should/shouldn't run on, and how many, it might be really interesting as a good power for config complexity tradeoff.
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
Do you have a source about the 10x speed gain for NoSQL? It doesn’t really make sense to me and the benchmarks I found say it’s about the same, which makes sense to me.
They're also backed by the CIA lol. To your point, I should have said "NoSQL" not "MongoDB" per se. I took the question to mean "Why not SQL" but they could very well be asking "Why not another NoSQL"
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
I wanted to learn more about the inner workings of k8s and I personally learn best when I create (or recreate) something. I doubt this will ever contend with k8s and I am okay if it does not.
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!