thomasbacklund

I am still curious.

As a FB software engineer you can probably work at any company you want to, so one must assume you want to work at Meta. And why is this?

Serious question here, please respond.

I made this nice little client/server socket lib which has the same interface both for TCP sockets and WebSockets. Free to use, MIT licensed.

You all know that browsers require WebSockets but when doing server to server communication regular TCP sockets are leaner and faster.

With pocket-sockets you can switch the underlying sockets as you need but use the same interface for both TCP and WebSockets.

Small, neat and few dependencies. Written in TypeScript with a bunch of tests to it :)

It also supports SSL/TLS encryption.

Happy SYN/ACK day!

Sure :) follow me as @bashlund on twitter but also star the repo on github https://github.com/simplenetes-io/simplenetes

Thanks for asking :) Writing this much Bash is quite straining because there is a lot of typing, but it is also liberating in the sense of coding very close to the OS (utils).

Also, most of it is not written in Bash, it's written in Posix standard, which is even more spartanic, but is then compatible with Dash and Ash (BusyBox) also, which is good because Bash is not always available.

To make Simplenetes we used another tool we also created which is meant for writing shell script apps and to perform agent-less automation, it is called Space.sh [1]

About tools for getting an overview of the cluster, there is only the command line tooling as for now, which does parts of the job, but tools for analyzing traffic and such is not created yet.

1: https://space.sh/

Indeed, the goal has to keep the number of moving parts down as much as possible so it can be easy to understand the full cluster and how to troubleshoot it. But of course, it still requires knowledge about the architecture to do so.

Thanks,

We use haproxy pods for inbound traffic, they perform TLS termination and simply pass the traffic over to a local proxy pod.

The haproxy pod (and all other pods) communicate with each other over this local proxy service which is running on each host.

We have a very simplified and robust overall architecture, were each pod allocates a specific virtual port and the proxy will try each host for that pod (and remember status), meaning we don't need to keep track of global routing tables and update each host's ip tables (shivering) when pods come and go. We don't use iptables.

If some instance of a pod is unavailable the proxy will seamlessly try another instance of the pod.

Initially we tried to config haproxy to do all this proxying for us, but it was asking too much.

Good to know is that Simplenetes is still in beta.

I have really enjoyed using Podman and will keep using it. I have found it be to stable (running on CentOS) for our production stuff.

Shameless plug: We built Simplenetes[1] around Podman (a simpler alternative to Kubernetes, but written in 100% shell script :)

1: https://simplenetes.io/

I like the detailed questions :)

The line count is a rough (overestimate) summoning the source of the three projects involved, simplenetes, simplenetesd and podc, and it also includes comments and blank lines.

The compiled output pulls in some dependency modules which is reusable code (STRING, etc). So it's not clear where to draw the line :)

Reason the compiled output gets bigger is because the compilation process `(make.sh)` includes compilations of actions, which I use when connecting over SSH agentless to manage the nodes. This tough part is handled by Space.sh [1]

[1] https://github.com/space-sh

You are looking at the `./release/sns` file, which is the "compiled" release, it's like looking at the .exe (404 kb isn't that bad for an ".exe")

The source files involved are smaller [1].

[1] https://github.com/simplenetes-io/simplenetes/tree/master/in...

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 absolutely needs testing and shellchecks all over the place to be labelled as mature in any sense.

Our other large shell project is Space.sh [1] where go overboard on testing, each module is tested under a bunch of distributions. [2] [3] Next step would be to do the same for Simplenetes.

Given that in shell that the only way to protect a variable from functions down the call stack accessing it is to redeclare/shadow it as "local" brings some murky waters.

BUT, isn't it amazing what is actually possible to do with Shell??

For me Simplenetes in the long run is not about it being written in Shell, I'm perfectly happy rewriting it in Rust if we get traction on it.

Simplenetes is primarily about having a simpler architecture of what a container cluster is and is not. I think many projects just get too complex because they want to fill every single use case out there, while the interesting part is saying no to things.

[1] https://github.com/space-sh/space [2] https://github.com/space-sh/space/tree/master/test [3] https://github.com/space-sh/space/blob/master/.github/workfl...

Thanks for sharing, I'll have a peek :) Heroku is ACE

Thank you :)

Thank you aabhay for a nice comment.

Seems like my click-baity title brought out some strong feelings :)

I do actually like Kubernetes. I recommend it to clients, I assess candidates who are to work with it, but I do really think it is a Beast. Because it is.

Kubernetes is like C++, extremely useful but it just keeps growing and nobody really knows all of it.

While Simplenetes is like... Lua, batteries not included, your boss will not approve, it doesnt't hit the buzzspot, but some people will secretely use it and be happy about it.

If you want something simpler and use podman you can try `podc` [1] which compiles a pod yaml spec into a single executable shell script with a nice managagement CLI api to it.

[1] https://github.com/simplenetes-io/podc

Thanks!! We do use it in production, it is however fresh from the keyb so giving it some time before putting sensitive stuff in there. About the state, it's perfectly doable, but requires some more Ops than k8s and isn't as flexible, naturally.

No, don't build the next Netflix on Simplenetes.

However, if you are just dealing with a three node cluster (Yes I know many of you are running tri-cycles with k8s stickers on it) then maybe it can be fine for many applications to not have a scheduler.

Simplenetes does however support multiple replicas of pods so if one node fails it can be OK.

Oh geez.. Hehe, thank you for pointing that out facepalm

Haha :) Well, the learning has been great I can confirm that. My script-fu is on a whole new level now, it was already quite up there after creating Space.sh [1]

Waste of time... Well... Let's not think too much about that. I'm at least a very happy user of this :)

[1] https://github.com/space-sh/space

Thanks :)

The real use case is super simple clusters, which could be just 1 node, no etcd, no API (SSH managed), no iptables.

Simplenetes is not a living breathing thing which auto heals it self, it's a deterministic approach where you can see your cluster with all hosts in the git repo which represents the cluster.

Also, it's focused on making local development easy, so you can develop in a micro services architecture straight on your laptop with very quick iterations.

Simplenetes does support state, no sweat. But it can't pull a disk out of the cloud for you, there is some traditional Ops involved.

Thanks!

We just moved Space.sh from GitLab to GitHub (hurts in my heart, but yeah community is on GitHub).

Also we are lousy at promoting our stuff, maybe April 1st is not the best day to do this either...

Thank you for noticing! :)

Yeah, this represent a few months of full time work.

This is why Simplenetes is built with Space.sh [1], a tool to build shell script applications.

About the tests, can't disagree with you, they will come.

[1] https://github.com/space-sh/space

As long as you have multiple replicas of the pods they keep serving traffic.

Ok, I though it was to catch CTRL-c :)

trap EXIT, does work for me in ash/dash/bash, though, when just letting the code flow exit with and without errors.

Not sure your use case, but I can for sure concur that traps are very painful to get right, especially when getting into child/grandchild processes land, taking terminal session, etc in regard.

Indeed, it's such a messy job coding for shell..

Comes with a lot trial and error.

The above will work as (tested in ash/dash/bash):

  #!/usr/bin/env sh
  trap "echo exiting" INT
  sleep 1h

But to your point, yes, how to actually know that without doing trial n' error & stackoverflow.

Thanks for the `sleep 1h`, didn't know that you could do hour as unit :)

(edited: turned out INT is enough to trap)

Yeah, I agree..

I was listening to the Command Line Heroes podcast the other day, about Bash. First version was stored on tape. So it has some legacy, hehe. Already then the requirement was to be backwards compatible with sh, so yeah, corner cases are around for sure.

If writing bash I do aim at version 3, because as you say they got that on MacAttack.

It sounds like you need Bash then :)

I totally agree Bash has some powerful features, some I go out of my way to reimplement in sh (as for example string operations [0]). But not all can ofc be replicated then bash it is.

Maybe then: sh->bash->python/perl

[0] https://gitlab.com/space-sh/string/-/blob/master/Spacefile.s...

If you need some bash specific features, I'm not going to argue with that.

In my experience, having portability of the script is quite nice when not necessarily controlling the environment it is going to run in, and aiming for ash/dash/bash does take it a long way.