# \[ANN\] RubyWorks 0.0.1 - early preview alpha "who knows, it m **URL:** \ **Category:** Deployment\ **Created:** [May 16, 2007, 10:53am UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281 "2007-05-16T10:53:30Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 10:53am UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/1 "2007-05-16T10:53:30Z")
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](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](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](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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 11:11am UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/2 "2007-05-16T11:11:41Z")
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 removed\_email\_address@domain.invalid Purico Consulting ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 11:20am UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/3 "2007-05-16T11:20:43Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > removed\_email\_address@domain.invalid > > > RubyWorks is a yum repository (collection of binary RPM packages) that > > > > Further details are at [http://rubyworks.rubyforge.org](http://rubyworks.rubyforge.org) > > Ruby). – Jeff X. Software Journeyman - [http://gigix.thoughtworkers.org](http://gigix.thoughtworkers.org) Open Source Contributor - [http://rubyworks.rubyforge.org](http://rubyworks.rubyforge.org) Technical Evangelist - [http://www.infoq.com/cn/](http://www.infoq.com/cn/) ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 4:10pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/4 "2007-05-16T16:10:33Z")
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. 🙂 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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 11:32am UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/5 "2007-05-16T11:32:44Z")
On 5/16/07, Jeff X. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 🙂 – Alex ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 7:08pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/6 "2007-05-16T19:08:56Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 6:00pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/7 "2007-05-16T18:00:49Z")
On 5/16/07, Jeff A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 7:16pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/8 "2007-05-16T19:16:56Z")
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](http://fedoraproject.org/wiki/Projects/Mock)) 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. 🙂 Thanks, Jeff ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 8:17pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/9 "2007-05-16T20:17:04Z")
On 5/16/07, Craig W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 8:31pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/10 "2007-05-16T20:31:07Z")
On 5/16/07, Jeff A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://fedoraproject.org/wiki/Projects/Mock)) 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. 🙂 > 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. 🙂 > 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 ---
**Author:** ![alexeyv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/46a35a/32.png) [@alexeyv](https://www.ruby-forum.com/u/alexeyv)\ **Post date:** [May 16, 2007, 10:21pm UTC](https://www.ruby-forum.com/t/ann-rubyworks-0-0-1-early-preview-alpha-who-knows-it-m/104281/11 "2007-05-16T22:21:18Z")
On 5/16/07, Alexey V. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 😉 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/](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