A mouthful, indeed
I'm currently developing a super duper secret project which uses Rails 3.1 and is hosted on Heroku. With the release of Rails 3.1 RC5, I've decided to migrate to Heroku's Cedar stack after reading Michael's article about how easily unicorn can be implemented on the new stack.
I've already migrated one app, Wasted on Steam, and the performance enhancements are amazing, as you might expect. Using siege, it was able deal with 100 concurrent requests repeated 10 times in 2.5 seconds per request. Previously, it had taken 10 seconds per request. This is amazing, especially considering Wasted on Steam uses a network blocking request to update data.
For this other app, this super duper secret one, I thought I would detail the process.
The initial setup
Currently, there's no way to migrate the stack automatically, so we have to clone and proceed:
Next, create the app on the new stack:
The code changes
Rails 3.1.rc5 separated the asset-building gems into their own group in the Gemfile, called
:assets, so we need to make some changes and clean it up so it looks like this:
Please note, we no longer need to include the old version of rake, nor the therubyracer (the Cedar stack now includes node.js). It's very important that you update the path to use the native node.js by typing:
Supposedly, this is supposed to happen on new apps by default, but I had issues. Now, make sure you run
bundle update now to update the Gemfile!
Next, we need to update our
application.rb; it's changed in RC5. Around line, replace with the following:
Now, if you're using Compass like I am, you'll need to create an initializer in
Thanks to Ken Collins for that bit! I imagine, as some point when Rails 3.1 is released this will be done automatically.
Next, in your
production.rb, change the
If you use sendgrid
The Cedar stack is supposed to be less magical and black-boxy then the others, so if you use sendgrid, we have to accommodate for it in our
Using unicorn instead of thin
Procfile tells Heroku exactly which process groups need to exist for various reasons. Like a
web group to run our unicorn. Our
Procfile is quite simple as we only need the main web process, Unicorn.
The unicorn config
Place this in your
config directory and call it
You'll have to play around with the configuration depending on how memory-heavy your app is. Wasted on Steam uses a ton of gems and it can easily run 4 worker processes.
Push the changes to heroku
If you have any configuration variables, you'll want to go to the old app and do
heroku config -s and migrate them over using
heroku config:add <VARIABLE>=<DATA> <HELLO>=<MOREDATA>.
Finally, we have to pull the database from our old app. This will only work if you have the gem
taps installed, so
gem install taps. Go to your old app folder and type the following:
If you have any issues, simply type
git remote rm heroku; git remote add heroku firstname.lastname@example.org:<new_app_name>.git then proceed with the steps above. This usually fixes everything.
Hopefully, everything should work now as planned. Make sure you go to
http://<yourapp>.herokuapp.com and not
http://<yourapp>.heroku.com, and you should see the site!
This app is a simple app, but to give you an idea of how it performs, again with 100 concurrent requests repeating 10 times: