[ANN] RubyWorks 0.0.1 - early preview alpha "who knows, it m

Rails Deployment
1

Dear world at large,

In the spirit of “release early, release often”, with special emphasis
on “early”, we are making available to you RubyWorks 0.0.1.

RubyWorks is a yum repository (collection of binary RPM packages) that
provides all software components needed to host a Rails application on
a RedHat Enterprise Linux 4 or CentOS 4, pre-configured and ready to
go.

Usage scenario for this product is as follows:

  1. Point your package manager (up2date or yum) to
    http://rubyworks.rubyforge.org/RPMS/i386

  2. Type “up2date rubyworks” (“yum install rubyworks” on CentOS)

  3. Sit back and relax. Two minutes later you can browse to
    http://localhost:3001 and see a Welcome To Rails page, served by a
    cluster of four Mongrels, running in production mode, proxied behind
    HAProxy and monitored by monit.

  4. Automatically get upgrades, bug fixes and security patches, tested
    for backward-compatibility with a specific minor version of Rails (1.2
    at present).

  5. Live happily ever after…

As the version number (and, indeed, the title of this message)
suggests, this is an early release. Our primary intention is that
people who have a need for something like this have something to look
at and tell us about anything wrong or missing.

On the other hand, it works as advertised on developers’ computers, so
if you need to deploy Rails on CentOS or RHEL today, you now have a
choice of spending half a day to set everything up manually, or half
an hour to install RubyWorks.

Further details are at http://rubyworks.rubyforge.org

If you are attending RailsConf this weekend, and want to talk about
this project, feel free to seek me out in corridors, or leave me a
note at ThoughtWorks booth. Especially if you think that RubyWork
sucks - I will be delighted to hear about it. Honestly, that’s what
versions 0.0.1 are for.

I’m also doing a talk on Saturday in Products & Services track, which
will cover hows, whys and the bright future of RubyWorks (hint: it’s
not just a bunch of RPMs and a phone number, nor a rerun of J2EE in
Ruby).

With crossed fingers,
Alexey V.
RubyWorks team
ThoughtWorks

2

Is there any chance that RubyWorks will support .deb/apt-get at some
point in the future as well? There are a lot of Debian and Ubuntu
servers out there that could use this.

Just a thought.

Jun-Dai Bates-Kobashigawa

[email protected]
Purico Consulting

3

That’s our next target…developers of RubyWorks are all using Ubuntu
but it doesn’t support Ubuntu yet, that’s weird enough.

So definitely YES. Hopefully we’ll support Ubuntu/Debian next week.

On 5/16/07, Jun-Dai Bates-Kobashigawa [email protected]
wrote:

[email protected]

RubyWorks is a yum repository (collection of binary RPM packages) that

Further details are at http://rubyworks.rubyforge.org
Ruby).

–
Jeff X.
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://rubyworks.rubyforge.org
Technical Evangelist - http://www.infoq.com/cn/

4

Alexey V. wrote:

RubyWorks is a yum repository (collection of binary RPM packages) that
provides all software components needed to host a Rails application on
a RedHat Enterprise Linux 4 or CentOS 4, pre-configured and ready to
go.

This is very cool, and is something I myself was considering doing.
Thanks much for providing this to the world! Since you asked for
feedback, though, I’ve got some. :slight_smile:

I dislike managing Rails with gems on systems with package management.
I feel the same way about Perl and CPAN, for what it’s worth. What I’ve
been doing for our internal Rails hosting is basically converting the
gems to RPMs, pushing them to our Rails yum repo (which also has updated
Ruby packages, along with gems itself), and then doing “yum install
ruby-rubygems-rails” which pulls in Acti(ve|on).*, Ruby, rubygems, etc.
It’s worked very well for us so far, especially since all we need to
do to update our web hosting boxes is push the packages to the
production Rails yum repo and wait for the nightly yum update to run at
~4AM.

It is more work for me to do this and maintain these packages, and it’s
a bit of a hassle pulling all the gems together, but I throw a day at it
when a new Rails release comes out, I put those in our test Rails repo,
tell our developers to update their development boxes (most of which
point at the test repo anyway), and let me know what breaks.

Is this simply something RubyWorks doesn’t do /yet/, or is this an area
where we differ in opinion on how things should be done? I’d love to
chat with you about this at RailsConf but I unfortunately couldn’t make
it there this time around. Besides, we can hit a wider audience on the
mailing lists anyway.

Thanks,
Jeff

5

On 5/16/07, Jeff X. [email protected] wrote:

That’s our next target…developers of RubyWorks are all using Ubuntu
but it doesn’t support Ubuntu yet, that’s weird enough.

For Ubuntu, there is deprec. And for RHEL, until today, there was
nothing.

Meantime, most ThoughtWorks’ Ruby customers (and our very own internal
IT organisation) are using RHEL 4. Hence the choice of a target
platform.

Once we made it for one Linux flavor, it shouldn’t be too hard to port
it to another. Especially one, that has an up-to-date Ruby package
available from the distro (unlike RedHat/CentOS 4).

Next week or not, we’ll get there :slight_smile:

–
Alex

6

On Wed, 2007-05-16 at 02:52 -0600, Alexey V. wrote:

Usage scenario for this product is as follows:

sucks - I will be delighted to hear about it. Honestly, that’s what
versions 0.0.1 are for.

I’m also doing a talk on Saturday in Products & Services track, which
will cover hows, whys and the bright future of RubyWorks (hint: it’s
not just a bunch of RPMs and a phone number, nor a rerun of J2EE in
Ruby).

Interesting - thanks for sharing. I have updated our main server to RHEL
5 which does have Apache 2.2.x and mod_proxy_balancer which was the
obstacle to running mongrels on CentOS/RHEL versions 4 but there
obviously are a lot of virtual hosts that aren’t going to get the
upgrade all that soon which makes attractive candidates for this.

–
Craig W. [email protected]

7

On 5/16/07, Jeff A. [email protected] wrote:

I dislike managing Rails with gems on systems with package management.

Having to deal with two package managers is a bit awkward, indeed.
But… repackaging however many gems there are at the RubyForge
repository as RPMs is an insane amount of work. That is the problem.

Ruby world has chosen RubyGems. You can fight it, or roll with it. For
something like RubyWorks, “roll with it” is arguably the only
reasonable path.

Using private package repositories for staged deployment is quite
obviously The Right Way ™ in many scenarios, so we will be
addressing that in near future. One can do that with gem repositories
just as easily as with yum.

By the way, there is another issue with RubyGems that I’m aware of.
The need to have gcc and header files on production boxes (for
building native extensions). Not every Linux admin likes that. So far,
we are demanding it (our rubygems RPM has a dependency on gcc and
ruby-devel), but I would appreciate it if someone could suggest
another way.

–
Alex

8

Alexey V. wrote:

Having to deal with two package managers is a bit awkward, indeed.
But… repackaging however many gems there are at the RubyForge
repository as RPMs is an insane amount of work. That is the problem.

It would be quite difficult to package up gem, to the point where I
wouldn’t even try without some sort of automated method (say, “gem rpm
foo”). If all you’re looking to do, though, is cover Rails and Mongrel,
that’s not that difficult; I’ve done it.

Using private package repositories for staged deployment is quite
obviously The Right Way ™ in many scenarios, so we will be
addressing that in near future. One can do that with gem repositories
just as easily as with yum.

That’s good, and is an architectural feature that has paid off heavily
for us since all we need to do to move a set of Rails packages to
production is copy the files over and re-build the repo.

By the way, there is another issue with RubyGems that I’m aware of.
The need to have gcc and header files on production boxes (for
building native extensions). Not every Linux admin likes that. So far,
we are demanding it (our rubygems RPM has a dependency on gcc and
ruby-devel), but I would appreciate it if someone could suggest
another way.

This is another problem I encountered, and one that also was able to be
resolved in our environment by repackaging gems. Since we don’t have
any compilers or headers on our production systems, which is frightfully
easy to do with any package-based distribution, and we aren’t going to
install them just for gems, having the packages built on a build machine
in a build environment (using Mock –
Subprojects/Mock - Fedora Project Wiki) we can get consistent
results for all our systems.

The biggest hassle so far has been Ruby’s multilib support (or the lack
thereof), requiring us to build and maintain separate i386 and x86_64
packages for the appropriate /usr/lib/ruby or /usr/lib64/ruby
directories, but I’ve heard that should be improving shortly, allowing
us to build noarch packages, which is what they should be.

Please don’t misunderstand me as slighting your work at all, either!
One of my ideals is that people ask, “What’s the best OS or distribution
to run a Rails server with,” and we could reply, “CentOS, and then load
up this yum repo.” I’m pretty sure we’re both on the same page with
that. :slight_smile:

Thanks,
Jeff

9

On 5/16/07, Craig W. [email protected] wrote:

Interesting - thanks for sharing. I have updated our main server to RHEL
5 which does have Apache 2.2.x and mod_proxy_balancer which was the
obstacle to running mongrels on CentOS/RHEL versions 4

Being unavailable on RHEL 4 is not the only problem with
mod_proxy_balancer (although the most obvious one).

Another problem is that it has no idea that downstream server
(Mongrel) is essentially single-threaded, when it’s running Rails. So,
when one of your (say) four Mongrels is stuck on a deadlock or an
endless loop, you are losing every 4th request, i.e. all of your users
experience downtime. Even if it’s just a long-running request, it
makes other requests long-running.

RubyWorks setup doesn’t have that problem, because HAProxy is
configured to send one request at a time to any given Mongrel. When
one node in the cluster gets stuck, all subsequent requests are
routed to other nodes.

HAProxy is also somewhat better than mod_proxy_balancer at dealing
with cluster nodes going up and down while under heavy load.

To be fair, the downside of HAProxy is that it’s yet another process
to manage, and yet another socket. I personally think, the trade-off
is still worth it.

–
Alex

10

On 5/16/07, Jeff A. [email protected] wrote:

Having to deal with two package managers is a bit awkward, indeed.
But… repackaging however many gems there are at the RubyForge
repository as RPMs is an insane amount of work. That is the problem.

If all you’re looking to do, though, is cover Rails and Mongrel,
that’s not that difficult; I’ve done it.

We will be repackaging Mongrel as an RPM, because it’s basically part
of the hosting infrastructure. Not Rails, however. Rails belongs in
your_app/vendor/rails.

The need to have gcc and header files on production boxes
having the packages built on a build machine
in a build environment (using Mock –
Subprojects/Mock - Fedora Project Wiki) we can get consistent
results for all our systems.

I’ll look at that. Thanks.

The biggest hassle so far has been Ruby’s multilib support (or the lack
thereof), requiring us to build and maintain separate i386 and x86_64
packages for the appropriate /usr/lib/ruby or /usr/lib64/ruby
directories, but I’ve heard that should be improving shortly, allowing
us to build noarch packages, which is what they should be.

Please don’t misunderstand me as slighting your work at all, either!
I specifically asked everybody to tell me what sucks. :slight_smile:

One of my ideals is that people ask, “What’s the best OS or distribution
to run a Rails server with,” and we could reply, “CentOS, and then load
up this yum repo.” I’m pretty sure we’re both on the same page with
that. :slight_smile:
Almost. We have a slightly different conversation in mind.

Q: “As an overworked sysadmin managing this zoo of COBOL, Java and
.NET applications, how do I host this shiny new Rails thingie
development is pushing down my throat?”
A: “create some virtual machines, load up this yum repo and read this
document. By the way, here is a phone number to call if you run into
problems.”

The underlying idea is same though. Rails production deployment should
not be a pain in the butt. Nor should it require reading blogs for two
weeks, trying to figure out what’s the best deployment practice du
jour.

–
Alex

11

On 5/16/07, Alexey V. [email protected] wrote:

reasonable path.

I think is a good approach what RubyWorks provide, if there was (4
years back) a similar solution for distributing Python packages, many
of my developments/deployments had been a joy, but they weren’t

Using private package repositories for staged deployment is quite
obviously The Right Way ™ in many scenarios, so we will be
addressing that in near future. One can do that with gem repositories
just as easily as with yum.

I also do something similar, on Windows, with pre-compiled gems o my
private repository.
(These packages requires a change in the Rakefile/RubyGem spec file
but is something that could be handled easily).

By the way, there is another issue with RubyGems that I’m aware of.
The need to have gcc and header files on production boxes (for
building native extensions). Not every Linux admin likes that. So far,
we are demanding it (our rubygems RPM has a dependency on gcc and
ruby-devel), but I would appreciate it if someone could suggest
another way.

I hate the “you need a compiler, always” part of some rubygems. An
update of rubygems specs should raise soon, since tattle reports [1]
showed 20% of rubyst running on Windows (i386-mswin32) and no proper /
good packaging of binary gems for us :wink:

Also, you could add there, that dependencies like RubyInline not only
require gcc and devel package always, even on production boxes, but
made these available to the user running your application/rubygem
update process. (since binaries generated by RubyInline are stored in
$HOME).

Anyway, excellent work!

[1] http://tattle.rubygarden.org/

–
Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi