What is the ideal rails server? Lets assume its on a VPS, such as Linode. Lets assume that any of the sites won't become the next twitter, but they should scale well. It must also support multiple sites and all sites are rails 3. And the database must be on the same server (for now).
Should it use apache or nginx?
Ruby Enterprise Edition or just normal Ruby?
Ideal linux distro?
MySQL, PostgreSQL or something else?
How should the directories be laid out (where to put your rails sites or anything else)?
Deployment options?
Anything else?
Should it use apache or nginx?
Nginx seems to be the preferred route here, unless you need specific Apache features. If you're using Passenger, both Apache and Nginx are supported. More on Passenger here.
Ruby Enterprise Edition or just normal Ruby?
I'm pretty sure REE is only available for Ruby 1.8, which isn't really the preferred version for Rails 3 anymore. Rails 3 had some problems with 1.8, but they might have fixed them by now. Generally, though, Ruby 1.9.2 runs Rails 3 well.
Ideal linux distro?
This really doesn't matter. If you're not sure, Ubuntu is a good choice as there's a lot of knowledge out there, and it's pretty easy to use. Slicehost has a bunch of great articles on getting started with a VPS, and a lot of them focus specifically on Ubuntu: http://articles.slicehost.com/.
MySQL, PostgreSQL or something else?
This is definitely subjective. MySQL is definitely the most common out there, and if you're really unsure, it's a good starting point. However, people often argue that PostgreSQL is cleaner and easier to use that MySQL. If you're just starting, I would recommend MySQL just because of the amount of information out there already.
How should the directories be laid out (where to put your rails sites or anything else)?
You can put your rails project anywhere you like, so I like to just put it in my home directory. Just make sure that your web server has access to your static assets.
Deployment options?
Capistrano is popular. You just commit your changes and cap deploy, and you'll be up and running.
Anything else?
If this all seems overwhelming, look into a simpler solution like Heroku. They set everything up for you, and, while you loose some flexibility, you won't have to worry about any of this. Their pricing isn't too bad, and they offer a free option.
I think kyl summed it up pretty well. But I figured I would let you know exactly what I have been using since rails beta4 (and now with RC). This setup has worked well for me:
Rackspace Cloud servers - Gives you full control of the server. You can resize your servers on the fly. You can also take snapshot images if you want to duplicate your setup for another site. Its cheap and in my opinion better than Amazon cloud.
CentOS 5.4 - solid, but as kyl mentioned probably any distro will work fine.
Ruby 1.9.2RC 2 - no problems so far on Rails 3 for me. Will definitely use Ruby Enterprise when they port it to 1.9.2 (not sure if that is in the works, though??)
Nginx - fast and lightweight. I like it much better than apache. Works well in front of Passenger, mongrel and thin.
MySQL - just personal preference for this. I have been using it for years. It is easy to set up a master/slave or master/master config if you need to scale. Some people have success just using sqlite, but I prefer something a bit more robust.
Github - a must for me for source code control. Bundler works very well with github
Application Server - I am still debating what to do about this. I was happy with Passenger 2.2.15 until I saw how long it took to spawn new ruby processes to handle concurrency. It takes up to 30 seconds to spawn a new process for me and the app is locked, so no requests can go thru while it is spawning. I am investigating right now if it is my app or Rails 3 that takes so long to load. This problem is fixed with Passenger 3, though. Hopefully that will be released soon. As a result of this, I am probably going to use Thin or Mongrel until Passenger 3 comes out.
Capistrano - works great for Rails 3. I would recommend finding some cap recipes for versioning your app with git tags... or just write your own.
Anything else? Not really related to the server, but I would recommend using the new plugin API for any part of your app that is reusable. Read up on railties and engines. Its simple to create a gem with Jeweler and version it with github using jeweler rake tasks. Then you can deploy from a github tag or from master, by adding the gem and github source in your Gemfile and bundle install or update it. I recently ported all of my common app code (blog, authentication, etc..) to Rails 3 engines and it is working great. And any time I need to reuse that code, I just drop it in the new app's Gemfile.
Related
As Rails does change quite a bit fairly quickly could somebody please share their experiences maintaing an existing application as Rails develops. How does a hosting service like Heroku handle this? Do hosts support legacy versions of rails or would one be at the mercy of the host to upgrade an app?
Edit:
With a framework such as Asp.net which is not updated that frequently, it would seem to me that fewer apps would be broken due less quickly. Is a developer always chasing after the next version of rails?
With Gems and now Bundler, this isn't really an issue. To keep your application up to date, all you have to do is tell it which version of Rails to bundle with your app in the Gemfile: gem 'rails', '3.1'. This works for any version, past or current. The only thing you have to worry about is the libraries like Ruby, but any version of Rails will work on most versions of Ruby. Plus, most hosts will even allow users on shared servers to compile your own Ruby if you want.
Hosts definitely support 'legacy' versions up to a point. I think even GitHub is on Rails 2.2, though they might be self-hosted.
Hosting tends not to be that big of a deal with respect to new rails versions, however. It's the community. Gems, plugins, and systems come in and out of fashion at blinding speed in the Rails community and you can quickly find yourself committed to a pile of unmaintained contributed code. Most new gems now ONLY support Rails 3, so if you have a 2.x.x app and want to use those things, you're SOL unless you backport it yourself.
So yes, you are chasing Rails versions over the long period. There's 2 ways to solve it: either walk away from every app you write after it's finished, like a consultant, or keep your app small. If you want to build a large, feature-filled platform, you can't build it as one app. You'll get stuck on a Rails version forever and have to rewrite it eventually anyway. Just set a threshold and say when this app is over 10,000 lines, it's time to break it up into services so it doesn't get fossilized.
I use Heroku to host and deploy a lot of little apps, in the past I remember ftp'ing and then Capistrano came around and made things a lot better.
Is Capistrano still the default deployment method or are there up and coming techniques or existing methods to deploy rails apps.
Capistrano is still at the state of the art, generally used with github.
Of course the easiest way to host your apps is Heroku if don't have your own server.
+1 on the other Heroku and Capistrano answers.
Outside of that, I'm particularly looking forward to seeing what VMWare's CloudFoundry has in store for us. One step deploys (and upgrades) very similar to Heroku, and you can actually host your own clouds if you want to. It's still in beta, but looks pretty slick from what I've been following of it. Supports Ruby (Rails, Sinatra, et al), Node, Java, and others.
Is there a "best" rails server to use for development (mongral, webrick, etc..)? Or does it not really matter?
Short answer: develop on what you will deploy on.
Long answer: good Rails containers, like Unicorn, Thin, etc, really don't impact your development much but will impact production. And, each has just enough configuration related quirks that interact with your code and choice of gems that just diving in and working in that environment can save a lot of time, even if using continuous integration, but especially if not.
The "best" in my opinion is Passenger in conjunction with your choice of Apache or nginx, whichever you're familiar with. It's perhaps the only game in town when it comes to getting an application running quickly and reliably. The Phusion team has invested a lot of time and effort into building a complete package for a scalable deployment platform.
Mongrel is only designed to be part of your stack and requires a number of supporting pieces to work properly. It also has to be managed with a separate process launcher and that can be frustrating and can cause serious issues if done wrong. Mongrel2 is a better platform but will need some time to be properly assimilated by the Rails community.
Webrick was never intended as a production web server. It is only a toy server for testing. It is painfully slow and can only service one request at a time.
See my answer here Recommendations (and Differences) between different Ruby on Rails Production Web Servers
I want to develop an application in Ruby on Rails. I have used rails(vigorously) a couple of years ago. since then i haven't given it a try, i have been concentrating on core ruby. At that time, Rails(1.2.x) used to be a bit slow! so my problem is whether i should go for the earlier slower version or should i try newer versions... is it fast and STABLE? And does it have proper support for all the gems that were made for earlier versions?
Thanks
Compared to two years ago, you should be impressed with where Rails is at. Here are some things to take note of.
mongrel is still fine as a server, but many (most?) people are using Phusion Passenger. I'm running a few apps in production mode with Passenger, and it's great. It plugs into Apache with a very small and simple set of directives. You won't have to set up balancers or rewriters like you used to.
Phusion also offers RubyEE, which is their own, more efficient version of Ruby. The installer works in such a way that if you decide you don't like, it can be removed by simply deleting its directory. It's all self-contained.
rmagick is still just as awful to install as it ever was, but now there is Paperclip as an alternative.
You'll love how fast 2.3 loads the console.
named_scopes are a huge step forward. Be sure to read up on them.
There are dozens of other reasons to upgrade, most of which can be found on this site. Unless you have an axe to grind with Rails, I doubt that you'll be disappointed with it.
Now, when you ask about stability, the answer is "sure, it's stable." However, you gave no information regarding what types of user loads you're trying to support. More detailed questions could lead to more detailed answers.
Edit
Answering your comment.
10 Cool Things in Rails 2.3 by Luke Francl. This is a nice summary of the latest highlights.
No problems with Rails 2.3 yet! No Problems with gems as well! Give it a try, it rocks! ;)
2.3.4 is stable enough if you are running Ruby 1.8.6/7, not so much if you are running Ruby 1.9.1 (even though it should technically support it properly).
If you are going to run Ruby 1.9.1, good on you, the speed improvements are really good, however you will have to be aware that some things wont work as intended and will need some patching of either core Ruby or Rails.
Saying that I would still avoid REE. Anything that has malloc'd for me in development I wouldn't trust in production.
I've used straight Mongrel, I've used Mongrel clusters behind Apache, I've looked at Thin, and I'm becoming very intrigued by Passenger. I've looked at Nginx, too. I've looked at MRI, Ruby Enterprise Edition, Rubinius, and JRuby. There are a lot of options, each claiming to be the new holy grail.
What is the best option out there for a brand new, fully up-to-date deployment? The only assumptions are this:
The app is Rails 2.2 based. (I know 2.2 isn't fully released yet, but neither is this deployment.)
The server is Linux-based. Probably Ubuntu Hardy, but really, whatever works best in this case.
Rails will need to be fully functional and probably talk to a MySQL database.
Everything else is negotiable.
Given these especially broad constraints, which combination of software will yield the best result, in terms of concurrency and low overhead?
I'm leaning toward Apache with the "worker" mpm and Passenger + Ruby Enterprise Edition, simply because it offers immediate stability and simplicity of setup and maintenance.
Am I likely to be particularly better off with another option?
I switched from Mongrel Cluster to Passenger two weeks ago (Debian Linux Server). I didn't look back for a second. Passenger is probably the easiest way to get your new server up and running. Performance and reliability are reasonable too.
Personally, I like to spend my time working on exciting new Rails projects rather than dealing with deployment issues - Passenger enables me to do exactly that. However, Mongrel or something else may still be preferable if you have some kind special requirements (doesn't apply for most products).
This morning, DHH talks about this very topic on his own blog:
But somehow the message of Passenger has been a little slow to sink in. There's already a ton of big sites running off it. Including Shopify, MTV, Geni, Yammer, and we'll be moving over first Ta-da List shortly, then hopefully the rest of the 37signals suite quickly thereafter.
So while there are still reasons to run your own custom multi-tier setup of manually configured pieces, just like there are people shying away from mod_php for their particulars, I think we've finally settled on a default answer. Something that doesn't require you to really think about the first deployment of your Rails application. Something that just works out of the box. Even if that box is a shared host!
http://www.loudthinking.com/posts/30-myth-1-rails-is-hard-to-deploy
Tobias Lütke on the topic of switching Shopify (million requests/day) to Passenger:
All this means that the total amount of memory that is used by Shopify during normal operations went from average of 9GB to an average of 5GB. We evenly distributed the savings amongst more Shopify processes and more memcached space which moved our average response time from 210ms to 130ms while traffic grew 30% in the last few months.
In conclusion: I cannot see any reason to choose a different deployment strategy at this point. Its simple, complete, fast and well documented.
http://blog.leetsoft.com/2008/11/15/passenger
We've been using the old standard nginx -> mongrel stack for the last 18 months, and although it was not trivial to set up the first time around, it's proven flexible, and has dealt with some very high traffic sites for us. Nginx in particular has been absolutely rock solid and fast, and if you can get your app page-caching you can deal with a lot of requests.
Stuck mongrels have been an issue, so we use monit to kill them when they misbehave. Again, it was not totally trivial to set up, but we've used the same process on many many sites at this point.
We haven't played with passenger yet, so perhaps it's easier and more stable, I'll defer to the other responders on that one, all I can say is that there's no reason at all you can't build a solid stack with nginx and mongrel.
We have switched fron NginX+Mongrel to Passenger.
I fully believe that Passenger is going to be the new standard for rails, despite NginX and Mongrel cluster being endorsed by some very smart people. Recent advances in Passenger have really propelled it forward.
Our current configuration is something like this:
Web servers
Ubuntu 8.04 LTS
Phusion Passenger on Apache2
MRI Ruby 1.8.6 and friends (form apt)
Ruby Gems 1.3.0 (Installed from source)
Database servers
Centos 5
MySQL Cluster (we just switched to this, but it is promising)
Having standardized on the exact linux distro we've been able to write Capitrano recipes to help deployment (slight variations in configuration have been the source of MANY service outages) and otherwise simplify our lives.
Have a look at Litespeed. You can get a free version that runs on 1 cpu or pay to get multi cpu. It is a bit expensive but is rock solid and handles rails brilliantly (i.e. uses less memory and is less of an overhead to monitor and setup). I run a massive amount of apps on it and it doesn't miss a beat.
We also switched from Mongrel to mod_passenger and found stability greatly improved with this effort required to setup and maintain. Good choice.
Another bit of gold:
Josh Peek's Slicehost gem is full of Capistrano recipes that are much simpler and much more organized than Deprec. Nothing in there is especially Slicehost-specific, either.
I'm hosting my new apps with Apache2 and Passenger on Ubuntu Hardy. Seems like the easiest and best option for most scenarios. I have just joined Slicehost.com for that purpose. They seem to get good reviews and have the most competitive prices of first class hosts.
I can't really endorse them yet because I'm a new client but the set of guides and range of support options is impressive.
What you are not mentioning is how large and popular your app is/will be. This criteria could affect the decision process.
Capistrano + Deprec for actually setting up my stack on Ubuntu and physically managing the deployment.
Nginx proxying to Mongrel clusers for the server architecture. It isn't the newest, bleeding edge technique but it works well, it is getting well-documented, and it is very, very high performance even when working on small VPSes. Assuming you haven't borked the application you can Slashdot a 128 MB Slicehost VPS and it just keeps coming back for more.
Having said that: there were a lot of gotchas the first time around, until I figured out how Nginx actually worked. After that its amazing -- like a little Apachelet with a slight Russian accent.