I previously showed-off our Rails-with-Mephisto server template so now it’s time for the Rails-all-in-One server template which makes it very easy to get your own Rails application running on Amazon EC2. We’ve made this template public, so any RightScale user can use it for free!
Let me show how you can configure and deploy your own Rails app in just minutes by using our publicly available Rails All-In-One server template.
Before we begin…
Before jumping into configuring the server template to launch your app, there are two important choices that we need to make: “How will we deploy application code to the server?” and “How will we initialize the database?”
Well, there are multiple ways in which we can proceed on either question, and the good news is that all are possible using RightScripts and we support several options with the templates we provide.
Here’s what our Rails-all-in-one template supports:
Application code:
- Download and install your rails application code from a tarball in S3.
- Checkout your rails application using an external svn repository.
- Boot with capistrano already set up, and remotely deploy your app with ‘cap deploy’.
DB initialization:
- Download and apply a mysqldump file from S3.
- Run a rake task to initialize and/or populate the DB.
- Boot with an empty DB.
Let’s start with the option of downloading the code and a mysqldump from S3, because these methods are supported out-of-the-box with our template. The example below focuses specifically on this option and I’ll follow-up shortly with a post describing the other options.
Step 1- Prepare your data
The only thing that you need to do in this step is to tar up your Rails application at your base directory, take a mysqldump of the database and store these two files somewhere accessible in S3. For example, to tar up my Rails application in my development machine I could do something like:
# cd /home/rails/myapp
# tar czf /tmp/myapp.tgz .
To generate a file with the initial DB contents, I would first populate or bootstrap the DB with the data I want to start with, and then copy the resulting file to S3. For example, to generate a dump of the “myapp_production” database I could do something like:
# suffix=`date "+%Y%m%d%H%M%S"`
# mysqldump --single-transaction -u root myapp_production | gzip -c > /tmp/myapp_prod_dump-$suffix.gz
Having generated the code tarball and the mysqldump files, we just need to upload them to S3. There’s a million and one ways in which to do that, so everyone can use his tool of choice. For convenience, the RightScale site contains an integrated S3 browser and file manager so that no external tools are necessary to perform these tasks.After logging into RightScale, go to “Manage > Storage”, select the bucket where to put the files (or create one if you don’t have any) and use the form at the bottom of the page to upload the 2 files.For example, if I wanted to store the files I generated (i.e., “myapp.tgz” and “myapp_prod_dump-20070913224229.gz” ) into the ‘bucket_for_myapp’ bucket, the page showing the listing of the bucket would look (approximately) like:
Step 2- Configure your template
Now that we have the two files ready in S3, it’s time to configure the template for our Rails application. This is done in “Design > Server Templates”, where we locate the “Rails all-in-one” template in the “Premium/Public” section, and click on the “edit” icon next to it. The edit page looks like this:
As you can see, there are a few variables that you can use to customize to your taste. However we’ve pre-set most of them to match common setups. The net effect is that you can probably get by with filling out only 6 text boxes.
Before I continue with the example of my Rails application called “myapp”, let’s address some security pre-requisites. When you try this with your own RightScale account, you need to make sure that you have an “ssh key” and select an appropriate “security group”. Since you are configuring a web server you must allow traffic to port 80 in the selected security group. If you have never done that before, please refer to the “quick troubleshooting” in our [blog entry](/2007/09/12/rails-on-ec2) for reference. Once you’ve selected a valid ssh key and security group, you can proceed to fill out the main template configuration.
Back to the example! There are only 4 things that I need to do:
- Fill in APPLICATION with the name of my Rails app: “myapp”
- Fill in APPLICATION_CODE_BUCKET and APPLICATION_CODE_PACKAGE with the location in S3 where I have stored the code tarball. That’s “bucket_for_myapp” and “myapp.tgz” respectively
- Fill in the DB_SCHEMA_NAME with the name of the mysql database my application needs to use: “myapp_production”
- Fill in the DB_MYSQLDUMP_BUCKET and DB_MYSQLDUMP_PREFIX with the location in S3 where I have stored the mysqldump file: “bucket_for_myapp” and “myapp_prod_dump-20070913224229.gz”
Here we are ready to hit the save button:
Step 3 – Wait, there is no step 3!
That’s right, since this is a simple example I just need to click on the launch button, sit back and let the RightScale infrastructure take care of the rest:
But what happens if my cool application needs some special gems to be installed in order to run? No problem, it’s as simple as editing the template again and filling in the OPT_GEMS_LIST with a space-separated list of the gems needed. (Currently the RightScript that installs these custom gems will not handle gem installations that require manual intervention, for example, gems in which one must select the appropriate architecture to install.)
Can’t wait for the server to boot, even though it takes only a couple of minutes. Less than the time to get on the phone with a traditional hosting company sales person and place an order… Soon the server will become “operational” in the taskbar on the left of the screen. Clicking on the instance name brings up the instance information page from which the “dns name” link (something like ec2-67-00-0-00.z-1.compute-1.amazonaws.com) leads straight to the web site on the instance. Tada! my application is live!
An interesting perk from using this template is that the database gets automatically backed-up to S3 every night. The backup is tagged with a timestamp and stored in the bucket configured in the template (i.e., the DB_MYSQLDUMP_BUCKET and DB_MYSQLDUMP_PREFIX variables). Also, the next time the template is launched again, the initial DB contents will be automatically restored from the latest of the mysqldump backups that match the configured prefix (i.e., the file that matches the prefix and that has the highest number suffix).
As you see, deploying your rails application doesn’t take much at all when using the RightScale infrastructure and the new Rails all-in-one template. Once you’ve done it once, it would probably take less time to configure a brand new application than reading this blog entry. In a follow-up article I’ll explore some of the details of the provided server templates and RightScripts and will show how to take advantage of it to fully customize your Rails application, however non-standard and unique it is.
If you’re interested in learning more about RightScale, please contact us at sales@rightscale.com The Rails all-in-one server template is available with RightScale’s free accounts, but more complex set-ups are reserved for the premium accounts.
Archived Comments
Michael
This is great! I’m getting close to deploying an app and can’t wait to try this out.
Thorsten
Michael, please send us email with feedback when you do! We know we have another step to go to make it yet easier and we’re eager to hear what you like and what we can improve.
Dan Croak
Great tutorial, guys.
On the gems: is there any difference between freezing gems into vendor/gems and using the OPTGEMSLIST?
Outside of gems: I have an app in development that uses the ffmpeg library to transcode .mov/.mpeg/.avi .etc files into .flv format. What is your recommended approach to installing that open source library? ffmpeg requires many other libraries and I’ve been installing them by hand on a dedicated Linux box we have without a ton of success. I’d love to see that wrapped up into a RightScript or something. Eventually, I’d love to handle the call to ffmpeg using messaging/SQS, so would you have a dedicated instance running just ffmpeg that is called from the Rails app via SQS? I assume that doubles the hourly rate charged by Amazon.
Lastly: how do you see Subversion fitting into the deployment process? Typically, our Capistrano recipes grab the current svn trunk and then run their various tasks. I’d prefer to use open source version control rather than zipping my latest app up to S3.
Keep up the good work, all. Really excited about your product.
Thorsten
Dan, thanks for the enthusiasm! If you freeze the gems, then you have a specific version in your svn repository. When you install you app on a server, you will get exactly that version. If you enter the list of gems into OPTGEMSLIST the RightScript will do a “gem install”, so you will get the latest version from rubyforge. The former is really the recommended approach for production for stability, but the latter is often more convenient.
We have a RightScript that will simulate a standard “cap deploy” of your app, which fetches from a subversion repository. Instructions forthcoming…
Regarding ffmpeg, I need to look that puppy up first to give a reasonable answer…
Dan Croak
Thorsten, thanks for the response. I followed these ridiculously-long instructions when installing ffmpeg on my local machine (Mac OS 10.4) and on our server (some flavor of Linux) …
http://www.webhostingtalk.com/showthread.php?t=565563
The Mac install went smoothly, but the server install seemed to have some hiccups (no surprise given the number of libraries).
As I think about how RightScale’s infrastructure works, I think there are two good/easy setups from an application developer’s perspective …
- When a video is uploaded to the Rails app (hosted on EC2), it looks right on the same server to make the command-line call to ffmpeg. Advantages would be: avoid paying for more hours for a separate EC2 instance, avoid using messaging/adding complexity to the app. Disadvantages would be: the end user may click away from the upload page while the processing takes place.
- When a video is uploaded to the Rails app (hosted on EC2), it calls SQS, which not only queues the work but opens up a RightScale ffmpeg template to do the actual video transcoding and closes it down when there is nothing left in the queue. Advantages would be: keeping concerns separated: the ffmpeg library is contained to the RightScale template, so if better versions of it come out, the template can change without messing with the Rails app, you still wouldn’t have to pay for a ton of extra EC2 hours, and the end user could leave the site and come back 10 minutes later but the video would still transcode and be okay. Disadvantages: a little more app complexity using messaging, a little longer processing time.
In both cases, the end .flv file would be saved in S3. I think #2 is the “right” solution architecturally for the use case … but it is even possible the way that RightScale is set up? I would think a similar setup would be perfect for similar use cases: uploading and manipulating audio files in particular. There are probably other libraries than ffmpeg that people might want to use as well for transcoding/manipulation. So, it would be great to just make a couple of clicks to completely switch out one for the other.
Cheers!
Michael
Thorsten,
After a bit of trouble with the DBMYSQLDUMPPREFIX field I managed to get an instance running. I think you should be more specific / explicit about what goes into that field.
Unfortunately when I went to look at the site al I got was a “500 Internal Server Error”. Now I’ve got to try to hunt down what’s wrong…
Thorsten
Michael – Thanks for the feedback. You are right that we need to improve the docs so you don’t need to guess. Did you get your server up? If not, please don’t hesitate to email us at support@rightscale.com, we do respond (faster than to comments here) and are happy to help.
