bgror

0-60: Deploying Goliath on Heroku Cedar »

Created at: 02.06.2011 20:02, source: igvita.com, tagged: ruby goliath heroku

Earlier this week Heroku rolled out a major upgrade to their webstack. The HTTP/1.1 support and the billing upgrades are both great improvements, but the "process model" definitely takes the crown: all of the sudden Heroku is much more than a Ruby+Rack hosting platform. Prior to this release, Heroku hosted Ruby only apps on top of the Thin web-server. Each "dyno" represented an instance of Thin, and as long as you deployed a Rack-compatible app, then Heroku would spin it up and run it for you. This was great, but also somewhat limiting - for one, you couldn't run non-Rack apps!

The process model changes all that. You can now run any application within their cloud, with the help of a simple Procfile. In fact, it doesn't even have to be Ruby! Node, Clojure apps, long-running Ruby workers, it is all fair game.

Goliath on Heroku Cedar

Goliath is an async web server and framework we developed at PostRank. While it does follow the Rack spec, it is also substantially different: it requires Ruby 1.9 runtime for Fiber support, and it uses an entirely different HTTP parser from Thin. Combined, these differences meant that up until now, deploying Goliath on any existing cloud environment was a no-go. However, with the new cedar stack, this is no longer an issue:

goliath (Goliath is an async Ruby web server framework)

Downloads: 537 File Size: 0.0 KB

A simple "Hello World HTTP proxy" example. Our API will parse an incoming request, dispatch an async HTTP request and return the results back to the user - no callbacks! We specified our libraries in a Gemfile, and we provided a Procfile with the startup parameters for our API. Believe it or not, that is all what we need. Let's deploy it:

git init .
git add * && git commit -a -m 'hello world'
heroku create --stack cedar goliath-demo
git push heroku master
curl http://goliath-demo.herokuapp.com/

Running a simple benchmark and checking the logs ("heroku logs" on command prompt) shows that an average request to our new Goliath API takes approximately 0.35ms (2500+ req/s). Not enough to handle the load? Simply start another API: heroku scale web=2.

Goliath, Heroku & the Cloud

Combine easy deployment, support for HTTP/1.1 and the async nature of Goliath, and all of the sudden you can develop and deploy simple streaming API's and async API endpoints with near minimal effort! If you can't tell, definitely something I am very excited about - a huge step for Heroku! Now, we just need to wait for a response from the CloudFoundry team - this should get interesting.

Migrate from Heroku to Engine Yard AppCloud »

Created at: 17.03.2011 18:30, source: Engine Yard Blog, tagged: Tips & Tricks appcloud ey-migrate heroku

Before arriving to work at Engine Yard I ran a Rails consultancy called Mocra. We would deploy our draft Rails apps on Heroku and then migrate them to Engine Yard AppCloud or perhaps a small VPS at some stage. I still have over 30 little apps on Heroku, I think. Back when I was at Mocra, I would have loved a migration tool to help us migrate an initial Heroku app to a production environment like Engine Yard AppCloud. Migrating an application and its data is kind of a pain. Fortunately I had a couple weeks at home recently after the birth of my third child, so I finally had the time to create the tool I always wanted - a migration tool to onboard on to Engine Yard AppCloud from other places, called ey-migrate. Source - https://github.com/engineyard/engineyard-migrate

ey-migrate heroku .

• A running Heroku application with your data in its SQL database
• A Gemfile, rather than Heroku's deprecated .gems format
• Added mysql2 to your Gemfile
• This upgraded application running on AppCloud without any of your data

gem install engineyard-migrate
ey-migrate heroku .

What's next?

Moving (again) http://onrails.org from Heroku to EC2 »

Created at: 21.09.2010 00:48, source: OnRails.org, tagged: Ruby on Rails heroku ec2

If you read this then this blog is now running Typo 5.5 on Rails 2.3.9 on EC2.

I really love the ease of deployment to heroku and the fact that they manage the whole stack. However I receive regularly emails from Heroku stating that I get a specific number of “backlog too deep errors” indicating the app is receiving more requests than it is capable of responding to, or in other words that that my blog is outgrowing their developer instance. So I have the option to increment the number of requests my application can handle, which is easy thanks to the the heroku command line: heroku dynos +1 —app onrails. So I can increase the HTTP performance by cranking up the “dynos” to 2 which would be an additional $36 a month. I still think it’s a good deal for a managed environment.

However you also saw on my last blog entry that there are other issues with running Typo on Heroku and therefore I started playing with running Rails on EC2. And I like what I see and now that Amazon has an official and secured Amazon Linux AMI, I’ll be using that. Here are a few notes on how I did set it up.

I started with the new Basic 32-bit Amazon Linux AMI 1.0 (http://aws.amazon.com/amazon-linux-ami/). I take basically only a few clicks to get a server started. You can use the ec2 console (https://console.aws.amazon.com/ec2) to create and connect to the server, however you need to use ec2-user instead of root to connect due to the way the Amazon Linux AMI is setup.

Note Lee is right that if I continue to moving host I should create a Chef recipe for this.

Install dev tools

$ sudo yum install git
$ sudo yum install make gcc-c++ zlib-devel openssl-devel
$ sudo yum install ruby-devel ruby-libs ruby-mode ruby-rdoc ruby-irb ruby-ri ruby-docs

Install MySQL

$ sudo yum install mysql mysql-server
$ sudo /etc/init.d/mysqld restart
$ mysql_secure_installation
$ sudo yum install mysql-libs mysql-devel

Install ruby-mysql

$ sudo gem install mysql —no-ri —no-rdoc

Install rubygems

$ wget http://production.cf.rubygems.org/rubygems/rubygems-1.3.7.zip
$ tar xzvf rubygems-1.3.7.tgz
$ cd rubygems-1.3.7
$ sudo ruby setup.rb
$ cd ..

Install Rails (note I use 2.3.9 for Typo )

$ sudo gem install rails —no-ri —no-rdoc
$ sudo gem install rails —no-ri —no-rdoc -v=2.3.9

Install Apache (2.2.15)

$ sudo yum install httpd

Install Passenger

$ sudo gem install passenger —no-ri —no-rdoc
$ sudo yum install httpd-devel
$ passenger-install-apache2-module

Configure Passenger

nano /etc/httpd/conf/httpd.conf

   LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.15/ext/apache2/mod_passenger.so
   PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.15
   PassengerRuby /usr/bin/ruby

Suppose you have a Rails application in /somewhere. Add a virtual host to your
Apache configuration file and set its DocumentRoot to /somewhere/public:

  <VirtualHost *:80>
      ServerName www.yourhost.com
      DocumentRoot /somewhere/public   
      <Directory /somewhere/public>
         AllowOverride all             
         Options -MultiViews  
      </Directory>
   </VirtualHost>

Installing Typo (from source)

see http://wiki.github.com/fdv/typo/install-typo-from-sources

$ wget http://rubyforge.org/frs/download.php/71779/typo-5.5.zip

then unzip, that’s it. That’s your typo instance, now let’s configure it’s database.
Note I moved it to /var/www/typo/

Create config/database.yml i.e.
production adapter: mysql host: localhost username: yourusername password: secret database: onrails_prod

Change the Rails version in config/environment.rb, replace 2.3.8 with 2.3.9

RAILS_GEM_VERSION = ‘2.3.8’ unless defined? RAILS_GEM_VERSION

setups gems required for Typo:
$ sudo rake gems:install

Creating/Copying database:

Note I migrated my blog so I need to copy the database to the new server.

$ scp -i .ssh/linux_ami.pem onrails_org.sql ec2-user@ec2-184-73-20-188.compute-1.amazonaws.com:onrails_org.sql
$ mysql -u yourusername -p
create database onrails_prod;
exit
$ mysql -u yourusername -p onrails_prod < onrails_org.sql

As I also update Typo to a new version I had to run a migration:

$ rake db:migrate RAILS_ENV=production

Note if you want a clean install you can just to a rake db:create and rake db:migrate.

Et voila! Well Heroku made it simpler but I always have fun playing with EC2.

Enjoy!
Daniel

Double Shot #663 »

Created at: 08.03.2010 13:55, source: A Fresh Cup, tagged: Double Shot git heroku highlight ruby testing

I'll just be over here in the corner, trying to write some code.

• Public Beta: Deployment Stacks: You now have a choice of Debian and Ruby versions on Heroku.
• Smart HTTP Transport - Interesting, setting up your own git server might get easier now.
• Smack a Ho.st - Easier testing for Rails apps with subdomains.
• Ruby's Metaprogramming Toolbox - An introduction.
• Highlight - Syntax highlighting for Rails projects via a plugin that wraps pygments.
• Stubbing and Setting Expectations on HTTP Requests Is Now Easy With WebMock - Looks like a potential alternative to fakeweb with a bit more spice.
• identity-map - Simple Identity Mapper implementation for Active Record.

Bundler and I are breaking up »

Created at: 18.02.2010 23:41, source: Rail Spikes - Home, tagged: heroku

Bundler may be the future, but after way too many hours of trying to get my app working with Rails 2.3.5, bundler 0.9.x, and Heroku I have decided to throw in the towel and switch back to Heroku’s gem manifest system.

I had Bundler 0.8 working very nicely but for whatever reason I couldn’t get the gems to play nice with each other in the new version. I had the app working locally and the tests passing, but on Heroku the app wouldn’t boot. This could have something to do with Heroku running Bundler 0.9.5 while I was running 0.9.7 locally. Whatever the reason, I’ve decided to take a break from bundler and wait until its development stabilizes a bit—at least on Heroku.

If you’re in the same boat, you can use this script to convert your Gemfile back to a .gems file and config.gem statements.