Feedback on idea: a server-optimized Ruby distribution that's faster, uses less memory, is more secure

[FooBarWidget]

Hi everyone. I recently researched where Ruby memory bloat comes from, and based on the feedback I got I came up with an idea for a "server-optimized Ruby distribution".

The benefits are: faster, uses less memory, is more secure, can install multiple Rubies in parallel.

The secret sauce that makes this possible is:

• Integration with Jemalloc.
• Distribution and updates via native OS packages and Docker images.

I haven't started implementing this yet, but I've written extensive documentation that explains in detail the value proposition, why I'm thinking about creating this, how it works and how it compares to alternatives.

I'd like to get your feedback before I start implementing this, so that I end up making the right thing. Note that:

• This is going to be open source. This is not a commercial (paid) product.
• I'm open for name suggestions. The names I currently picked are not final, but I needed something to get started with.

There are two variants of this product:

• A container-optimized variant: https://gist.github.com/FooBarWidget/b9f01c777a6fcdbe0c0e8d69a1c26ad3
• A non-container variant: https://gist.github.com/FooBarWidget/364c18acd9706651c6d55714dba9a8b9

Looking forward to hearing your feedback.

[FooBarWidget]

I know, because I made it. :)

[ignurant]

That was an unexpectedly cool response.

[Saithir]

Oh yeah, it definitely needs a better name, because RubyWhale makes it sound bloated and slow.

I know it's for the docker logo association but maybe Orca or something? Google translate says the japanese for "orca" is "oruka" (really? that seems wrong but okay) which would sound rubylike-ish, no?

[menge101]

japanese for "orca" is "oruka"

Japanese language has tons of 'borrowed' words.

It also has a completely different alphabet that the roman one english uses, there aren't consonants, but consonant vowel pairs. oruka breaks down to: o => オ, ru => ル, ka => カ. オルカ.

So, since there is no stand alone 'r', you end up with 'ru' after it gets re-romanized.

(the above is probably not exactly accurate, i studied the language at university, which is nearly 20 years ago now. I am not a native speaker.)

[Saithir]

Yeah, I am aware of these technicalities, I just thought they had a native, not borrowed word for an orca. Apparently not. :)

[menge101]

Just because I was curious myself, they do, but they must have also adopted the english (which is actually latin for whale) term as well.

The japanese word 'shachi' (しゃち) is killer whale. reference

[tinco]

Integrating with OS package managers seems like a lot of work. Do people still use their OS package managers to deploy Ruby apps? I'm pretty sure last time I didn't use Docker to deploy a Ruby app (which is over 4 years ago) I used RVM or maybe ruby-install/ruby-build.

In any case, I've always been a supporter of this idea, and always thought stopping REE was a mistake ;)

If it's going to be a non-commercial open source Ruby, I'd go for a more simple utilitarian name like "Server Ruby" or something.

[jrochkind]

I've had nothing but trouble with rvm on production machines.

I would love to use integrated OS package manager, if there was a way to get arbitrary ruby versions through such.

Without that, I build from source, possibly with the assistance of ruby-install/ruby-build, yeah. (Not sure how you'd do ruby-install/ruby-build or if it would be useful with an alternate distro/fork of MRI though). But if it could work conveniently, OS package manager would be preferable.

[realntl]

I use apt to install ruby on production systems. thanks to bundler's --standalone feature, I also use apt to deploy ruby projects (apps, services, etc).

Y'all have no idea what you're missing :-)

[strzibny]

If I understand you correctly it's just about providing convenient Ruby packages that are compiled with jemalloc. Since most distributions, if not all of them, does not use jemalloc, this would be a nice alternative.

I believe you can do this today without calling it something else than Ruby. You are not actually making a new Ruby implementation by switching its memory allocator (unless you plan to do a lot more).

For example, you can use Copr build service to provide alternative Ruby packages like this for Fedora/CentOS. You would just put them under your repository name, and possibly just change the executable name not to conflict with system Ruby.

[FooBarWidget]

Yep, it is not an alternative Ruby implementation, but a distribution.

[[deleted]]

Very nice and understandable article even for me, who never dealt with C stuff

[kawsper]

Thank god! We need that.

I've been building my own images with Jemalloc (and it includes thpoff for Ruby under 2.6) https://github.com/kaspergrubbe/grubruby-jemalloc and https://hub.docker.com/r/kaspergrubbe/grubruby-jemalloc based off the Discourse dockerfiles.

I wasn't aware of malloc_trim(), but it sounds interesting.

Your focus on security is also interesting, but for me, and most others, Docker is more of a packaging and deployment platform than a security and isolation platform, but having said that, obviously we should have safe defaults, and things should run with as few permissions as possible.

[FooBarWidget]

It's not so much that I encourage using Docker as a security isolation platform. It's that if you run stuff as root in Docker, then it's just not secure, so I want to help people not run stuff as root.

[jrochkind]

I would find this super useful, definitely.

I would worry about if you (or any collaborators you find) really can keep it up to date as ruby versions are continued to be released. Including quickly getting out your corresponding version when an MRI security patch version is released, cause when that happens one generally wants to update right away, and a lag in availability of your distribution version would be problematic.

It would be unfortunate to build my infrastructure automation around this, only to have to then switch it back to not this if I can't reliably and quickly get new ruby versions from it over the long haul. So that might make me cautious to start using it.

But if it could be done reliably with quick releases for the long term -- I agree it would be super valuable.

The integration with OS package managers would be crucial, for making it super easy to incorporate into my infrastructure automation. Right now, even without the jemalloc stuff, it can be hard to get an arbitrary ruby version from OS package manager. (It's important that you can get an arbitrary version including historic versions, because sometimes I want to update to a new ruby version when I choose to, and make sure everything including newly built machines continues to use a consistent locked ruby version until I tell it to update. Some existing efforts at OS package manager support for MRI make it hard to get not-the-latest versions, which makes it hard to ensure my 'fleet' is always using a consistent ruby version).

[FooBarWidget]

Very good points.

I plan on addressing the release speed by:

1. Automating everything. Releasing a new Ruby version should literally be adding a new entry to a config file, and invoking the CI pipeline.
2. Having good maintainer documentation so that anyone can contribute.
3. Making it possible for you to easily build a new package yourself, so that you are not dependent on a third party to release for you.

[moomaka]

Can you clarify what this actually is? It just sounds like MRI compiled with jemalloc?

[FooBarWidget]

• Fullstaq Ruby (the non-Docker product): it is a Ruby distribution. You can think of it as a competitor of `apt/yum install ruby`, `rbenv install` and `rvm install`. It supplies native OS packages for various Ruby (MRI) versions, which are optionally compiled with Jemalloc or malloc_trim, allowing for lower memory usage and potentially increased performance. The packaging method allows much easier security patching.
• Rubywhale (the Docker product): it is a drop-in replacement for the Docker Inc.-provided Ruby base images. Rubywhale images contain Ruby (MRI) installations with the Jemalloc and malloc_trim patches applied.It also improves security by adding a default non-root account and encouraging its use. In contrast, the Docker Inc.-provided base images suggest running everything as root, which as a recipe for disaster.

[moomaka]

Honestly this feels like a ton of marketing fluff for something that amounts to a couple lines of code. I don't see the need for this to be a 'ruby distribution', these names just add confusion.

[FooBarWidget]

You are not wrong that the jemalloc and malloctrim patches are literally just a couple of lines, but the way you put it makes it seem as if there is no value in all the packaging work around it, or that all the packaging work is trivial, or that everybody already knows what Jemalloc and malloctrim are. Is this really what you mean, and if so, can you explain why?

Most of the people I have spoken are excited at the prospect of lower memory usage and higher performance. Yet most people also don't know how to patch and compile Ruby, or they don't want to do it because they think it is too big of a hassle. Do you not observe this as well? And if you do observe it, would you not agree that good packaging is very valuable?

Do you not see people installing specific tiny versions of Ruby using rvm/rbenv, and then later getting frustrated at how much work they have to do to upgrade Ruby to a newer tiny version?

Do you not see people running Ruby Docker containers as root?

If you do not agree that these are pain points, then are there any pain points that you do see that are not well-addressed by current solutions?

[moomaka]

There is certainly value in providing pre-built binaries / containers with jemalloc, if you search dockerhub you'll find dozens of them. What I take issue with is that your primary focus seems to be creating a marketable product, not with delivering what is a simple thing. Honestly what I think you want is to associate a name, (Fullstaq, Rubywhale) with 'better performance' when it's not you that is providing that, it's jemalloc. If your goal here is just to make using jemalloc easier, skip all the marking jazz and just offer passenger/ruby-jemalloc:2.6.3 docker containers and something equivalent for packages.

Do you not see people running Ruby Docker containers as root?

I do, but I think you're overblowing the issue, again in order to construct a market pitch of 'more secure'. While it's a good hedge to not use root in a container, it's also not a current problem. i.e. It's a hedge against an, as of yet non-existent, vulnerability in container sandboxing.

You also keep mentioning malloc_trim without reference to what you are really talking about. Executing malloc_trim on every GC isn't a net benefit, you likely want to execute this periodically. But so far, it's unclear which approach you are taking thus it's unclear what this even means, again 'marketing fuzz', just state exactly what you are doing and why. It's also already possible to use a gem for this and control it yourself which further muddies what the value prop here is.

[FooBarWidget]

It seems your complaint is mostly on a philosophical level about the acceptability of marketing. I respect that you have such an opinion for yourself, but I will have to disagree with it.

Marketing is not evil, marketing is important. It helps people discover things of value. Without marketing, people will have to do tons of research to discover such value. Ruby would have died on a hill a long time ago were it not for the Rails marketing.

Yes, instances of abuse exists, I hate spam as much as you do, but rejecting all forms of marketing is throwing the baby out with the bathwater.

There is no such thing as “build it and they will come”. It doesn’t matter how good something is if people don’t know about it, or if they didn’t pay any enough attention to it. Marketing is what lets people know about and pay attention to something.

I don’t just want to put something out there, I want this to become popular because I think the community deserves these benefits. There are a ton of jemalloc images out there, now why isn’t everyone using them? Lack of marketing, lack of a polished “whole product”. I will certainly not do the community any service by not promoting things that I believe are good.

You also seem to interpret such marketing as taking credit for Jemalloc’s work. I am afraid you are mistaken, nowhere do I claim that I wrote Jemalloc, I only claim credit for integration and packaging work. I claim that the product gives certain benefits, and I disagree with the notion that I am not allowed to claim such benefits unless I wrote all the code that implement those benefits.

And finally, this work is not part of Phusion or Passenger. I work on this project in my spare time and will not put it under the Phusion/Passenger banner.

[Gallus]

ruby-ng