Fikus: Deploying Padrino to Engine Yard AppCloud »

Created at: 02.11.2010 18:22, source: Engine Yard Blog, tagged: cloud Technology appcloud deployment padrino sinatra

Padrino and Engine Yard AppCloud

Engine Yard AppCloud is a great platform for deploying Ruby on Rails applications quickly and easily. It's not only good for Rails, but it also makes it just as easy to deploy any application using Rack or Rack-based frameworks like Sinatra. I'm a big fan of Sinatra and use it for both internal and personal projects. I even spoke about creating "stupid simple" Sinatra micro-apps at Red Dirt Ruby Conf this past year. As a web application developer, it's a wonderful tool to have under your belt for shipping quick, small, and targeted applications or middleware. However, with increasingcomplexity in a project, I want the ease of Sinatra with a little more "oomf". Sinatra is a great web DSL and is perfect for small, isolated applications. But when crafting complex applications, one quickly longs for improved organization, such as the logical separation of an MVC architecture. I found myself writing boilerplate code for each project, setting up the same code for common components: haml, mongo_mapper, rspec, and whatever component the project required. The layout of the boilerplate Sinatra setup I used looked a lot like an ugly parody of Rails and quickly overwhelmed me with too much bloat for a "micro" Sinatra application.

The Padrino Framework

Wynn Netherland asked me at Red Dirt Ruby Conf if I had heard of a framework called Padrino, which solves a lot of these problems. I hadn't heard of it but promised him I'd take a look. Later that day I dove in and instantly fell in love. Padrino provides a well-organized MVC architecture on top of Sinatra. You can easily create complex web applications while harnessing the power of Sinatra and Rack with lots of additional goodies thrown in. You get helpers, forms, mailers, and a built-in admin interface, similar to what you get with Django and easier than implementing something like Typus in your application. You can mount multiple applications with ease and share code between applications. Routing is accomplished with Sinatra's wonderful HTTP verb declaration system instead of a router like in Rails. The feature I enjoy the most with Padrino involves its component agnosticism and generator abilities. Need mongo_mapper instead of ActiveRecord? Done. Want a project with less for CSS generation, haml for your views, jquery, and shoulda? It's easy. I encourage you all to check out Padrino and try it for yourself. If you're a fan of Sinatra, you'll likely enjoy what Padrino has to offer.

Deploying a Padrino Application

Deploying Padrino to Engine Yard AppCloud doesn't require any major changes to your deployment workflow. For example, I have a very simple CMS project called Fikus, which is a Padrino application using MongoDB for document storage. To deploy this to Engine Yard AppCloud, fork the main repository and make any local edits for configuration. You're going to need access to a MongoDB database. You can either use the unofficial chef recipe in the Engine Yard ey-cloud-recipes repository to spin up MongoDB on a utility instance, or you can use a third-party service such as Mongo Machine. The first step is to create your environment. On your Engine Yard AppCloud Dashboard, choose "Create New Environment", give it a name (I called mine fikus), and choose "Passenger" from the Web Server Stack list. You can choose "Show Advanced Options" if you wish to choose specific SSH keys to install, change your availability zone, or the name of the deployment user. Add a new application for the environment, and fill out the name and the git repository of your fork of Fikus. For the application type, choose Sinatra. Make sure to copy down the deploy key given to you and add it to your application's deploy keys on Github. This is necessary for your application to be deployed to your instances. Next you will be asked to specify the gems and UNIX packages for your application. By default it adds the sinatra gem, but you'll want to remove that and add bundler 1.0.0. You don't need to add the padrino gem as it is included in the project's Gemfile. There are no special UNIX packages to add for this application, so once you are done with the gems you can go to the Dashboard. The environment and application are in place, so now the only other piece is setting up your chef recipes for the application. Follow our HOWTO guide for using Chef to install the engineyard gem, fork the base recipe repository, and add your custom recipes. Fikus comes with a custom chef recipe already prepared in the fikus/chef directory. Copy that to your chef repository's cookbooks directory and customize as you see fit. Open up cookbooks/main/recipes/default.rb and make sure the following lines are in place:

require_recipe "mongodb"
require_recipe "fikus"

If you are using a third-party service for MongoDB such as Mongo Machine, you won't need the MongoDB recipe. Instead you can update cookbooks/fikus/templates/default/database.erb with the proper credentials. Commit your changes and push them to Github, then upload them using the ey command:

$ ey recipes upload -e fikus

Now you are ready to boot your instances! You can boot a single instance if you use a third-party MongoDB service, but if you choose to use the unofficial MongoDB recipes in the ey-cloud-recipes repository, you will need to boot up a utility instance named mongodb_master (I strongly discourage having MongoDB on the same instance as your application and/or MySQL). I set it up like this, using the "Custom" cluster option: After a while the instances will boot, and then you can deploy the application, again using the ey command:

$ ey deploy -e fikus -r master -a fikus --no-migrate

Pass in the --no-migrate since we're using MongoDB and don't have the concept of migrations. They're not needed. However, if you are using ActiveRecord instead, you would need to use the command bundle exec padrino rake ar:migrate to migrate the database. The final step involved is to ssh into your instance and run the rake task to seed the database with the basic data needed for Fikus:

$ cd /data/fikus/current
$ bundle exec padrino rake seed

That sets up an initial site, admin user, and page for you to play with. Now you can hit your application at the /admin URI, log in with the credentials provided in the "rake seed" step above, and begin adding content to your site. Fikus currently allows you to serve up content for multiple sites, but other than that it is fairly basic. Pages are authored using Markdown, and there are a few options for page caching which are still works in progress. This is a fairly new project, so if you want to contribute, contact me on Github or just send a pull request. I hope this shows you how flexible the Engine Yard AppCloud can be for deploying non-Ruby on Rails applications.

more »

Rake task for deploying to Heroku »

Created at: 13.02.2010 02:39, source: Rail Spikes - Home, tagged: deployment heroku

Deploying to Heroku is pretty easy, but I’ve often found myself needing to do additional tasks after pushing to Heroku’s git repository. For example, if you have to migrate, you have to do that after pushing; and after migrating you have to restart the app server.

So here is a Rake task to automate that. It uses Heroku’s client library to find the git remotes you need to push to. Use it like this:

rake deploy # deploys to your default app for this directory

rake deploy APP=some-other-app # deploy to another app (e.g., a staging server)

more »

Scout Improves App Monitoring for Rails Developers »

Created at: 09.10.2009 23:19, source: Rails Inside, tagged: deployment

Back in early 2008 I wrote about Scout on Ruby Inside, announcing it as a new "Ruby powered Web monitoring and reporting service." This is still true, except for the "new" bit! I've stayed in touch with the Scout team and they've not slowed down in their work on the system. They've improved the service and added some cool new features for Rails app developers in particular - even going as far as ripping out three months of development work to make the system better!

Scout has matured a lot since last year and now pitches itself as a general server and application monitoring service, though there's a sidefocus on Rails app monitoring. It's a commercial service but the entry plan is only $19 a month and there's a thirty day trial available.

Compared to other services, Scout is interesting because no Rails plugin installation is required and all analysis is separate from the request cycle. Redeployment isn't even necessary. Scout takes a more passive background role while still collecting all of the data it needs.

One of Scout's new features is the incorporation of the Request Log Analyzer by Willem van Bergen and Bart ten Brinke. This tool analyzes Rails log files and produces performance reports based around several metrics: request times, mean request time, process blockers, database and rendering times, HTTP methods used, HTTP statuses, Rails action cache stats, and similar. You can couple this with Scout's regular graphs and e-mail alert systems to get notified about "interesting" occurrences with your applications right as they happen.

Lastly, Scout has a strong plugin ethos, so it's not like it's just a Rails service - though that's what I'm focusing on here. You can write your own plugins to monitor whatever you like.. so even if you do monitor a Rails app, if you want to monitor another service "on the side" and you're willing to write a plugin, you'll be good to go, all on the same account.

Disclaimer: Scout has no relationship with Ruby/Rails Inside, other than having run a job ad on our jobs board a little while back. I promised to write about them while talking with them at RailsConf 2009, however, and genuinely think it's a service worth checking out :-)

Tweet This Post

more »

How a 1-Engineer Rails Site Scaled to 10 Million Requests Per Day »

Created at: 09.10.2009 20:31, source: Rails Inside, tagged: Case Studies deployment

Ravelry is an online knitting and crochet community run by husband and wife team Casey and Jessica Forbes. A few weeks ago they did an interview with Tim Bray where they revealed that their site has over 400,000 registered users and does 3.6 million pageviews per day - though ultimately 10 million requests a day hit Rails (they have significant API, RSS and AJAX usage).

Todd Hoff of HighScalability.com then collected together all of the details he could find about Ravelry and put it together into "How Ravelry Scales to 10 Million Requests Using Rails." It's well worth reading through Ravelry's stack info, but if you want the Cliff Notes version they're using:

• Xen virtualization
• HAProxy
• Nginx
• Tokyo Cabinet (for large object storage)
• Nagios
• New Relic
• Amazon S3
• Amazon Cloudfront (for CDN)
• Sphinx
• Memcached

Also worth a visit, if you care to know about Ravelry's history, is this 30 minute interview with Y KNIT - a popular knitting podcast.

Tweet This Post

more »

Roll your own Nginx RPM »

Created at: 14.09.2009 22:58, source: caboose - blog.caboo.se Home, tagged: deployment

Nginx just released a vulnerability fix. It's a nasty one, since it allows remote execution. Since RPMs don't exist yet, here's a quick-and-dirty way to roll your own on Fedora-based systems. I basically followed these guides: http://www.linuxweblog.com/patch-rebuild-rpm and http://perso.b2b2c.ca/sarrazip/dev/rpm-building-crash-course.html

Since on this server I'm running 0.6.3x, I'll be updating to that version. The fixed version is 0.6.39.

While they do the building from their own user account, a commenter suggests setting up an account specifically for building RPMs. The latter is probably preferable, but we're going to ignore that in the interests of expediency.

Assuming you never built an RPM before:

1. Install RPM build tools and setup your environment

   # yum install rpm-build

   Now, create ~/.rpmmacros with this line

   %topdir /home/youruserid/rpm

   And create a bunch of directories

   $ mkdir ~/rpm $ cd ~/rpm $ mkdir SOURCES SPECS BUILD SRPMS

2. Find the most recent nginx source package on rpmfind.net. This will give you a working recent RPM to fix.

3. Install the .src.rpm package with rpm -i nginx-0.6.38-1.src.rpm which installs the necessary files into ~/rpm/SOURCES

4. Here's the hacky part. Download nginx-0.6.39.tar.gz and copy it to ~/rpm/SOURCES. Then, edit the ~/rpm/SPECS/nginx.spec file and replace "6.38" with "6.39" wherever it occurs (just once, I believe).

   Now, build the RPM with rpmbuild -ba SPECS/nginx.spec

   On my system, I had to also install (with yum) pcre, pcre-devel, and perl-ExtUtils-Embed before nginx would build.

   Now, wait while it builds.

5. You now should have nginx-0.6.39-1.fc8.x86_64.rpm (or whatever your system is.)

   # rpm -Uvh nginx-0.6.39-1.fc8.x86_64.rpm

   # /etc/init.d/nginx restart

Done!

more »