Towards a Fedora Ruby appserver

[Gaveen Prabhasara]

Hi,

On Sat, Oct 23, 2010 at 6:21 AM, David Lutterkort <lutter at redhat.com> wrote:
> Hi,
Glad the discussion has started.

>
> one of the great things about Ruby webapps is the many, many options you
> have to deploy them. Besides choosing a web server, as a developer you
> also get to choose a Rails or Sinatra version, and to pick your favorite
> rack or Rails plugin(s).
>
> The downside of all this is that it's a crazy duplication of work, and
> following all your choices, you might discover that the versions of some
> of your plugins conflict with rubygem-* RPM's in Fedora.
Ruby ecosystem is famously developer friendly. But for ops, not always so.
Certainly not because people are difficult. It's rather because the community
is mostly concentrating on building things, not deploying.

>
> To make all this easier, it would be great if we could come up with the
> Grand Useful Fedora Ruby Appserver (yes, GUFRA ;). I see this whole
> effort consisting of two parts:
That's a horrible name IMHO, but let's get to the important parts. :)

>
>      * discuss the tradeoffs at each level of the stack and come up
>        with a recommendation for what we like (hopefully some document
>        on the Wiki)
>      * package whatever needs to be packaged for Fedora
>
> The end result should make it easier for budding Ruby web developers to
> start with a well-tested set of tools, rather than have to go and figure
> all this out for themselves. And, of course, packages for all these
> things in F15.
One important thing I'd like to bring up is how this effort is going to benefit
people who deploy web apps. Having a proper stack always helps a lot.
Everyone's aware the hardships to endure if you plan to host Ruby webapps.

>
> To kick this off, here's what I think belongs into GUFRA:
>
>      * Ruby interpreter
>      * frontend webserver
>      * Ruby webserver
>      * Rails and Sinatra
>      * Rack plugins (which ones ?)
>      * Rails plugins (which ones ?)
>      * Devtools (rspec, rinari, ...)
* Deployment tools (Eg: capistrano, etc.)

>
> Some thoughts on the tradeoffs:
>
> Ruby interpreter
> ================
>
> Only MRI seems practical for now, and there the big question is whether
> we'll make the switchover to 1.9.x in F15, and how.
As you've said this is tricky. F14 is shipping with MRI 1.8.7 and it's not yet
decided if F15 will use 1.9.x. Eventhough Rubinius 1.1.0 is out, it
still doesn't
seem to fully compatible with Rails 3 (which takes us to Rails version as well).
Personally I don't have enough experience with rbx to comment about the
performance or suitability for deployment.

Sometime ago I remember seeing (on this list) about an attempt to have
parallel 1.8.x and 1.9.x stacks. If that effort has progressed we could probably
benefit from it. Or should we look into having some sort of a rvm based setup?

>
> Frontend webserver
> ==================
>
> Frontrunners are probably httpd and nginx. Apache httpd is hte Swiss
> army knife, nginx is more limited, but people like how easy it is to
> configure.
>From deployment point of view this is a decision or sometimes a choice. IMHO,
this however doesn't affect a developer that much. Since a Ruby webserver
can serve the app, I think it'd be sufficient and simple enough unless we aim
for production envs. I suggest we should.

>
> Ruby webserver
> ==============
>
> Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that
> it can be loaded as a module into httpd, but packaging it has proven
> somewhat interesting.
Phusion team promised that they'd make Passenger 3 more easy to package.
I haven't been able to verify that they've kept the promise. ;) However with
the final release of 3.0 we have another entry to this list; Passenger
Standalone [1]. Given the fact it's uses an Nginx core it might be worth a
look for packaging.

>
> OTOH, thin and unicorn are a nightmare to manage, since you get to
> babysit a good number of processes, and can't take advantage of httpd's
> ability to spin threads up and down depending on load.
>
> Rails
> =====
>
> For F15, the big question is whether to go with 3.0.x or the latest
> 2.3.x. And that mostly depends on whether people's favorite plugins are
> available for Rails 3.
It's still too early to talk about adotion. But give that F15 has more than
6 months for release, we could look into the inclusion of Rails 3.

>
> As a sidenote, we'll also have to worry about Bundler, since that's what
> people are told to use for their Rails3 apps; Bundler doesn't play nice
> with RPM.
Unfortunately, there's nothing I can suggest to avoid this case. It can cause
headaches.

>
> Plugins
> =======
>
> Mostly an exercise in collecting people's favorite plugins, and making
> sure they are in F15, in the right version.
Here's a wild thought (not original, came up in Twitter discussions). Why
don't we try to work with rubygems.org to generate (or at least get some
level of integration to) native packages; in our case RPMs? It's bit
ambitious. But it's certainly worth looking into. This could eliminate the
need to use *.gem instead of replying on rubygem-*.rpm

>
> David
One more note regarding the above mentions tools. Since some of them
have never been packaged for Fedora before (Eg: passnger standalone),
among other things it'll be necessary to make sure they play nice with
SELinux.

I'm not officially a package maintainer yet. But I'd love to become one and
take part in the work ahead.

[1] http://www.modrails.com/documentation/Users%20guide%20Standalone.html

-- 
Gaveen Prabhasara