4 ms·
Having been around that particular block in Ruby, and seen similar things happen in other languages, I'd say that the primary problem with them isn't that the i
by regularfry 8y ago
Having been around that particular block in Ruby, and seen similar things happen in other languages, I'd say that the primary problem with them isn't that the interpreters or basic tech makes it difficult. It's that the community rallies round ways of doing things that don't focus on the "uberbinary" story, and the knowledge of how to do that sort of thing is not well distributed.
For instance, it's not particularly hard to wrap everything from the app down to the ruby interpreter in a single directory that you can then drop into a .deb, but because deployment stories in the Ruby community, from at least Capistrano onwards, focused on getting the app code onto the server and then working from there, with all the problems that entails, the folk knowledge of how to do it just never spread that far. You had commonplace craziness like using RVM to install Ruby on the production servers because it was convenient, and once that mindset was embedded, the community as a whole (and I'm tarring with a very broad brush here, but it's not inaccurate) ignored simpler solutions that worked better, and didn't need tooling with as many points of failure. Bundler is another case in point: you just don't need it in production. Or at least, I never found it necessary past the build pipeline, and I think a lot of folk never found out whether they did or not.
The point is, a lot of the apparent deployment difficulty in interpreted languages is entirely incidental and self-inflicted. Now, there is a real argument that Docker removes the need to learn all the ecosystem-specific folk knowledge you need to get to a point where you can do painless, sensible deployments in a new environment, but I think it's just moving the problem around.
- forknore 8y agoThank you for your comment, I'm very interested in deployments of Ruby applications that come as close as possible to a single binary. Do you have any pointers to the mentioned folk knowledge that you can share?
- regularfry 8y agoThere are a couple of different approaches you can take. The "traditional" way to do it would be something like exerb, which is a packager for building standalone Windows executables (although I'm not sure whether it works for recent rubies), and you literally end up with a single file. Similar ideas crop up every now and again. But that's not the only way to do it; it's in keeping with the "uberbinary" idea to have a single tarred up directory and a known entry-point, such that once that's copied to the server you don't need anything else, no post-install build steps to get running. I built something to do everything-but-the-interpreter a while ago: https://github.com/regularfry/au.git https://github.com/regularfry/au.git. The tricks that let these things work almost always boil down to knowing about the existence of a very few environment variables, and when in the build process you need them set to which values. `au` relies on $GEM_HOME, $GEM_PATH, and $PATH, and knowing what to do with $DESTDIR and `ruby-install` ought to get you a ruby interpreter as well (although `ruby-install` is just a shortcut to `make` in the MRI source). Where you'd look to learn that stuff now, I don't know.