Are there any features in Linux that are essential for hosting Ruby on Rails?
I'm on a project where we're going to be hosting a Ruby on Rails app on a Linux server we own. Are all flavors of Linux equally capable of hosting Rails apps? If not, what features are present in some Linux distros but not others that are essential for hosting Rails apps?
You should use whatever distribution you're most comfortable with.
The only thing I can think of off the top of my head that would really matter which distribution would be 'better' would be if you planned to use the OS supplied versions of Ruby, rails, etc. There's nothing stopping you from building your own version on any distribution, but that may be more hassle than it's worth for you.
RHEL / CentOS do not keep updating versions as they are released. This may be good thing because it should eliminate compatibility problems when you upgrade the OS. This may be a bad thing because you may want a feature that was added in a later version. You may be able to side-step this issue by adding an additional repository that has newer versions.
I'm not a Debian guy so I can't speak to any specifics, but I'm under the impression Debian typically supplies newer versions. This may be a good thing because you won't have to search around for a feature that was recently added. This may be a bad thing because you may install an update and break your application.
But really the best answer is to use whatever you're most comfortable with.
All of the Unix variants are "equally capable" of hosting Ruby/Rails -- at least in the sense that Ruby, the Rails framework, and a huge number of gems will run on them. So in that sense "Use whatever OS you and your team are most comfortable with" is the right answer.
Some stuff I personally look for in an operating system --
Is the Ruby shipped with the OS (or available in ports, etc.) reasonably current?
All the new shiny requires Ruby 1.9.x these days, so if an OS is only shipping Ruby 1.8 I'm going to kick it to the curb. Yeah, I COULD install it by hand, but I have more than enough work building a stable environment - why would I accept more work maintaining my own Ruby package?Are the Ruby support packages (
rvm
, gems, etc.) reasonably current?
Same logic as (1) -- I would like to be able to use the operating system's package management as much as possible, but if I have to override the package manager and manually install every gem I'm going to use - well I can live with that, but it makes things harder.-
Is the OS itself suitable for my goals?
This is a fuzzy one - the best way to determine if an OS is "suitable" is to beat the living daylights out of it in testing/benchmarking with your workload.
This is where you discover that FooOS has awful multithreaded performance, and BarOS has a disk subsystem which demands that every other operation on the system stop whenever a thread wants to write data out, so BazOS (which is decidedly mediocre at both) actually has better performance because your application is both multithreaded and write-intensive.
If you're just looking at "Linux" the differences here will be negligible (or "fixable" by turningsysctl
knobs). If you expand your OS search to include other systems (BSD, OS X, Solaris, AIX, HP-UX, Windows) you may start to see some real variation in performance characteristics or load capacity.There are some non-technical considerations here too. If you have the choice between two hypothetical systems, one a free OS and another a pay-for-license system that's twice as fast but costs $5000 per CPU core to license, grab the free one. Your dual-processor quad-core server is going to cost you $40,000 in licensing fees, and even if we're erring on the expensive side of hardware that's a LOT more servers running the free OS. Even if you're paying for power and cooling it's pretty clear who wins on a cost-per-unit-performance metric...
Can we manage the OS?
Does the OS have tools that will let you manage it (or does it play nicely with tools you already use / know how to use / want to use, like Puppet and Chef)?
Is your team comfortable enough with the OS to manage it? Will you be able to handle the next major version upgrade, or will you panic and just stagnate on whatever you installed the day you deployed it and be perpetually frustrated when new features you want are missing?