Media Temple Tames the Beast - New Ruby on Rails Hosting Service with Mongrel
-bloggers-logo.jpg){kind=logo}
For a long time deployment has been the giant stinky Grey elephant in the beautiful Ruby colored room. Rails makes developing an app a joy but for many, including me, deployment has been a bit of a nightmare. If you wanted shared hosting you went with folks who seemingly built their Rails set up by the seat of their pants; only allowed production apps with no errors (yeah right), killed your apps (sans restart), had non-existent tech support, or worst of all a magical combination of all of the above (I think I’m still waiting for my Dreamhost activation letter). The other solution, which I opted for, was to roll your own hosting on a VPS or dedicated server which involved a lot of research, conflicting docs, and the horror that is FastCGI. Mongrel has saved my arse on the private server front, and now it will be the foundation of Rails hosting for Media Temple’s new Grid Server (gs).
Putting the dog in the box
Each (gs) account has the ability to create Rails Containers into which you install Rails, MySQL AND/or PostgreSQL bindings and of course Mongrel. You then create your Rails app ‘rails appname’, create a user for managing the app, generate a .htaccess file, create a sym link and um… that’s it! You can then start/stop/restart your app with ‘mtr start appname’.
That is by far the easiest Rails install I’ve ever done shared or otherwise. A lot of gems are installed already and if anything is missing you can install it. There’s also up to 1GB of dedicated RAM for Ruby Apps. I’ve been helping beta test the setup and my apps are running on the (gs) as fast if not faster than on my VPS server that Media Temple also hosts.
Bu wait there’s more… Capistrano support is baked right in.
What else do I get?
I mentioned you can choose between MySQL or PostgreSQL dbs, PHP4 or PHP5 (if you must), plans start with 50GB of storage space and 1TB of Bandwidth, multi-site hosting with unique users for each host (i.e. sales@site1.com and sales@site2.com won’t conflict) and the whole reason it’s called the grid - you can expand instantly in case of traffic emergencies. Last but not least 24/7 tech support online or by phone.
I know this sounds like they’re paying me (no, but if you sign up make sure to put ‘vixiom.net’ in the referral box). I’m excited because they’ve met or surpassed all my Rails hosting needs and I don’t even have to switch companies! A lot of my projects for smaller clients can now be hosted for a fraction of a VPS or dedicated server.
Thank you (mt)! With a special thanks to Nate for answering all my RoR questions.
*UPDATE* Here’s a coupon for 10% off
Here’s a shot of the new control panel:
Like this post? subscribe to the feed.
Can you share some more details about your setup? Are you running on the 64MB container? How many RoR apps do you think can be run on a 64MB container? Do your mongrel instances run in this 64MB space?
Comment by Davy Campano — October 17, 2006 @ 6:26 pm
I was testing the 64MB container, I forget where I read it but I think a mongrel instance wants to use around 15MB+ depending on the traffic, so you could safely run two rails apps in one 64MB container (and yes they run in the 64MB space).
My VPS (dv) server with Media Temple has 256MB and I’m running three rails apps on there (with one mongrel instance each) + 30 other PHP sites and it’s all golden (knock on wood).
Comment by KreeK — October 17, 2006 @ 6:55 pm
I’ve started testing a 64MB container, too, and so far am having a very positive experience.
Could you elaborate on “baked-in capistrano support”? Do you have a recipie that you could share?
Comment by Galen — October 20, 2006 @ 12:12 pm
This comes from the beta forum so I can’t 100% gurantee it still works. Whenever it says CODE that’s the start of a code block (I can’t copy their CSS on here). Baked in might have been a bit strong but here’s how to do it.
1. Apply Capistrano to your application.
CODE
cd
cap -A .
This creates the Capistrano rake tasks file in lib/tasks and a sample deploy.rb recipe in config.
2. Download the (gs) deploy.rb recipe.
CODE
wget http://gems.mediatemple.net/deploy.rb –output-document config/deploy.rb
3. Customize the config/deploy.rb recipe.
CODE
set :site, “14″
Set this to your site number. Your site number is right after the ’s’ in your access domain, so s14.gridserver.com’s site number is 14.
CODE
set :application, “app1″
This is the name of your application. Use a short, recognizable name with no whitespace. This is the name that will be used to identify this application when using the mtr command (mtr start).
CODE
set :webpath, “app1.example.com”
This is the web location of your application. This is used when adding your application to your container.
CODE
set :domain, “example.com”
set :user, “serveradmin%example.com”
set :password, “xxxxxxxx”
These are your credentials for logging into your (gs) service. You must use your “serveradmin@domain.com” user.
CODE
set :repository, “svn+ssh://#{user}@#{domain}/home/#{site}/data/repo/app1/trunk”
This is the subversion repository where your application lives. The above example is how to specify one on your (gs), and included in the recipe are examples of other repository locations. Do not use a file:/// style url, as these are known to not work with Capistrano. Also, if your subversion password is different than your (gs) password, specify it with the “:svn_password” setting.
4. Customize additional hooks in the recipe.
CODE
#task :after_update_code, :roles => :app do
# put(File.read(’deploy/database.yml.mt’), “#{release_path}/config/database.yml”, :mode => 0444)
#end
Uncommenting this will upload a database.yml.mt file after your code is checked out. This is one way of deploying your production configuration. Of course, this will fail if there is no deploy/database.yml.mt file.
CODE
task :after_symlink, :roles => :app do
run “#{mtr} -u #{user} -p #{password} generate_htaccess #{application}”
end
This demonstrates calling an mtr command from within Capistrano. This particular one makes sure that the .htaccess file in your application has the right mod_rewrite rules.
5. Add the application.
CODE
cap mt_add
cap setup
This adds the application to your (gs) container and sets up the initial Capistrano directories. Applications are placed in /home/##/containers/rails/.
6. Prepare for the initial migration.
a. Create a database through the Control Panel.
b. Configure your database.yml (or database.yml.mt) with the proper database credentials.
CODE
cap update_code
cap symlink
Once these commands are done, your application is ready for it’s initial migration. The code is checked out and the ‘current’ symlink points to the latest revision.
7. Migrate
CODE
cap migrate
This just runs ‘rake migrate’ on your database.
8. Create symlink from your html folder.
CODE
cap mt_create_link
This uses your application’s webpath and creates a symlink in your site’s html directory that points to the public directory in your application’s current revision.
9. Start the application
CODE
cap mt_start
Congratulations. Your application is now running. Now to deploy new changes, it’s as easy as:
CODE
cap deploy
Note: If your application does not use a database, then after step 5 above, running ‘cap deploy’ is all that is needed.
Comment by KreeK — October 21, 2006 @ 3:26 pm
Do yoyu know where the mt-capistrano file is? deploy.rb requires it
Thanks :-)
Comment by John Kopanas — October 23, 2006 @ 7:48 pm
That’s a good question, so good that I don’t know the answer :(
Are you getting an error when you test locally? It might only be installed on the (mt) side, then is included (required) in the same way that Rmagick is (ie you don’t need a plug-in or whatever it’s just always there).
If all else fails call ‘em up 1.877.578.4000, actually an email might be better as it would be routed to a Rails expert.
Comment by KreeK — October 23, 2006 @ 8:12 pm
I did not even try it because capistrano is run from my computer so the mt-capistrano needs to be local as well. No use trying it if I know it will not work :-).
Comment by John Kopanas — October 24, 2006 @ 10:34 am
Hi John. From your local machine:
% gem list –source=http://gems.mediatemple.net/
…
mt-capistrano (0.0.2)
Capistrano tasks to deploy Ruby on Rails applications on a (mt) Grid
Server.
…
% gem install mt-capistrano –source=http://gems.mediatemple.net/
…
I hope that helps.
Comment by Galen — October 24, 2006 @ 11:04 pm
Hi Kreek, nice post. I’m switching, can’t stand more DH.
Btw your coupon for 10% off is invalid, I just tried to use it, any idea?
Thanks.
Comment by Peter — November 19, 2006 @ 2:48 am
A client of mine had trouble using the coupon the other day I think it might have expired.
Comment by KreeK — November 20, 2006 @ 11:11 am
[…] Finally, after a little more than a month, Bamtastic! is up again. We joined the migrating flock of bloggers, designers, and developers to media temple’s grid server. Is it any better? I have no idea. Some say it’s all hype. The 1-click application installation of wordpress proved to be useless though. It’s installing an old version of wordpress for crying out loud. […]
Pingback by Bamtastic! is @ media temple » Bamtastic! — March 5, 2007 @ 5:43 am
The following lines do not seem to work in Capistrano 1.4.1:
…
task :after_update_code, :roles => :app do
put(File.read(’deploy/database.yml.mt’), “#{release_path}/config/database.yml”, :mode => 0444)
end
…
because release_path uses a current timestamp to locate the release folder, and when this line is run, the Time.now timestamp will not match up with the recently created release folder name. Because it cannot locate the correct folder, SFTP will spit out a ‘file not found’ error. It seems ‘release_path’ has been replaced with ‘current_release’, so use this code instead:
…
task :after_update_code, :roles => :app do
put(File.read(’deploy/database.yml.mt’), “#{current_release}/config/database.yml”, :mode => 0444)
end
…
As long as you have a file in the Rails root directory on your LOCAL machine called deploy/database.yml.mt, this should now work.
Comment by Micah — August 30, 2007 @ 1:49 am
[…] My non-stop quest to find decent shared Rails hosting may be complete. I was pretty pumped about Media Temple’s Grid supporting Rails but each of the half-dozen RoR sites I’ve deployed to the Grid haven’t been ripping it up performance wise. An issue with an unresolved grid error when trying to cache pages had me scrambling to SliceHost. However, SliceHost is a bare bones and system administration makes me want to shoot myself in the noggin. SliceHost did introduce me to LiteSpeed which in my opinion is the easiest/most stable way to deploy Rails. If I only had one app that I was working on full time SliceHost would be fine, I use Rails mainly to build CMS solutions for my clients websites so I still need email, stats, ftp etc. to be easy for them (not me) to manage. The brief was to find a shared host with all the bells and whistles that runs Rails on LiteSpeed with a healthy RAM allocation. […]
Pingback by Vixiom Axioms » Rails on Mosso — October 3, 2007 @ 7:06 pm
ephedra pills…
news…
Trackback by ephedra pills — November 10, 2007 @ 5:10 pm
How come the coupon doesn’t work? Im fairly interested in switching, do they stick you on a server with “unlimited bandwidth” which is actually, just many people stacked on the same server?
Thanks,
Tal Lifschitz
http://www.cashrichmoney.com
Comment by Tal Lifschitz — January 1, 2008 @ 1:47 pm
@Tal the coupon was an introductory offer from last year. I’m not sure how many people they put on the sam server but the only issue I’ve has is with the speed of the shared MySQL (which you can solve by gettting a MySQL container all to yourself).
Comment by Alastair — January 2, 2008 @ 8:17 am
hosting…
Comment by adi — March 28, 2008 @ 1:46 pm