Robby on Rails: Tag deployment

Boxcar Conductor: Rails deployment made easy

Robby Russell — Tue, 15 Apr 2008 12:16:00 -0500

In a previous post, I showed how we’ve been working on an interactive deployment process for Rails applications to reduce the time it takes to deploy to a Boxcar.

We began to move our Boxcar deployment recipes into it’s own Rails plugin and just made it available on GitHub.

Introducing Boxcar Conductor

The Boxcar Conductor plugin aims to automate the entire process for deploying to your Boxcar. We’re down to just a few simple commands to run to get your application up and running. While mileage may vary with other hosting providers, we did want to open up this work to the community and centralize our work with the community of Boxcar customers who have helped us build and test these tools.

Install Boxcar Conductor

If you’re running on Edge Rails… you can take advantage of the new support for installing plugins in git repositories.


  $ ./script/plugin install git://github.com/robbyrussell/boxcar-conductor.git

note: If you’re not using edge rails, you can download a tarball and install the plugin manually.

Installing the plugin will add a custom Capfile and config/deploy.rb, which has a few things for you to define based on your Boxcar subscription.

Configure Your Boxcar

Once the plugin is installed, you can run the following task:


  $ cap boxcar:config

This will ask you a few questions about your deployment needs.

Uploaded with plasq’s Skitch!

Which database server will you be using? (along with db user/pass info)
How many mongrels should run in your cluster?

After a few quick multiple choice answers, you’re application is ready to be deployed and you can run an Boxcar-specific deployment task.


  $ cap deploy

We’ve also created a new public project on Lighthouse so that you can submit tickets and ideas to us. With Boxcar, we’re really aiming to remove as many steps from the deployment process that aren’t necessary.

To follow along, visit the project on lighthouse or GitHub.

If you’re interested in learning more about Rails Boxcar, feel free to drop us a line.

Deploying Rails with an interactive Capistrano recipe to your Boxcar

Robby Russell — Thu, 28 Feb 2008 16:27:00 -0600

I wanted to share something that I’ve been meaning to share on here.

When we began planning Rails Boxcar, we really want to reduce the amount of work that it took to setup and deploy a VPS for a Rails application. During this period, we began to look at the deployment process itself and began working on an interactive tool for developers for setting up their deployment environment on their Boxcar instances. So, we worked with few customers to develop an interactive Capistrano recipe.

The Goal? Spend less time configuring the server or editing recipe files.

During the initial setup, we can have the customer provide a few details from the safety of their Rails application directory by answering the following.

What database server will you be using? (PostgreSQL or MySQL)
What port does your database run on? (if different than the default for your db server)
What is your database username?
What is your database user’s password?
What port will your mongrel cluster start with?
How many mongrel servers should your cluster run?

Great… setup the server and let’s deploy!

Uploaded with plasq’s Skitch!

Feel free to snag our interactive Capistrano2 recipe.

We’re trying to take the pain out of deploying your Ruby on Rails applications with Boxcar.

On a side note, we’re in the process of expanding our team and recently hired Alex Malinovich. Do stay tuned as we’ll be posting important announcements about changes to our Rails hosting services in the next few weeks. (grin)

Master/Slave Databases with Ruby on Rails

Robby Russell — Thu, 15 Nov 2007 16:02:00 -0600

Not terribly long ago, I announced Active Delegate, which was a really lightweight plugin that I developed to allow models to talk to multiple databases for specific methods. The plugin worked great for really simple situations, like individual models.. but when it came time to test with associations it fell apart. I haven’t had a chance to work on any updates and knew that it was going to take more work to get it going.

Earlier this week, we helped one of our bigger clients launch their new web site¹. For the deployment, we needed to send all writes to a master database and a reads to slaves (initial deployment is talking to almost 10 slaves spread around the globe!). We needed something to get integrated quickly and decided to ditch Active Delegate for the time being and began looking at the following options.

I spoke with Rick Olson² and he pointed me to a new plugin that he hasn’t really released yet. So, I’m going to do him a favor and announce it for him. Of course… I got his permission first… ;-)

Announcing Masochism!

Masochism³ is a new plugin for Ruby on Rails that allows you to delegate all writes to a master database and reads to a slave database. The configuration process is just a few lines in your environment file and the plugin takes care of the rest.

Installing Masochism

With piston, you can import Masochism with:


  $ cd vendor/plugins
  $ piston import http://ar-code.svn.engineyard.com/plugins/masochism/

To learn more about piston, read Every Second Counts with a Piston in your trunk

You can also install it with the old-fashioned way:


  $ ./script/plugin install -x http://ar-code.svn.engineyard.com/plugins/masochism/

Configuring Masochism

The first thing that you’ll need to do is add another database connection in config/database.yml for master_database. By default, Masochism expects you to have a production database, which will be the read-only/slave database. The master_database will be the connection details for your (you guessed it…) master database.


# config/database.yml  
production:
  database: masochism_slave_database
  adapter: postgresql
  host: slavedb1.hostname.tld
  ...

master_database:
  database: masochism_master_database
  adapter: postgresql
  host: masterdb.hostname.tld
  ...

The idea here is that replication will be handled elsewhere and your application can reap the benefits of talking to the slave database for all of it’s read-only operations and let the master database(s) spend their time writing data.

The next step is to set this up in your environment file. In our scenario, this was config/environments/production.rb.


# Add this to config/environments/production.rb
config.after_initialize do 
  ActiveReload::ConnectionProxy.setup!    
end

Voila, you should be good to go now. As I mentioned, we’ve only been using this for this past week and we’ve had to address a few problems that the initial version of the plugin didn’t address. One of our developers, Andy Delcambre, just posted an article to show how we had a problem with using ActiveRecord observers and masochism, which we’re sending over a patch for now.

As we continue to monitor how this solution works, we’ll report any findings on our blog. In the meantime, I’d be interested in knowing what you’re using to solve this problem. :-)

¹ Contiki, a cool travel company we’re working with

² Rick just moved to Portland… welcome to stump town!

³ The Masochism plugin README

Boxcar: Open for business

Robby Russell — Tue, 04 Sep 2007 13:04:00 -0500

We’ve been quietly rolling out our new Rails hosting solution over the past month, each week… inviting more people to ask questions and place orders. Initially, we invited some of our business hosting customers, and then sent out invites to those who signed up on the Rails Boxcar announcement list. We’ve been taking orders for the past few weeks and have had sites running on Boxcar for over a month now.

You’ll also notice that we’ve begun to phase out all of our older shared hosting solutions for new customers and are focusing solely on our Business and Boxcar accounts (aside from custom managed/dedicated solutions that we’ve been offering upon request).

To learn more about Rails Boxcar, read the announcement on the PLANET ARGON blog.

In other news, Daniel Johnson, our Lead Systems Administrator broke his arm while riding his bike while participating in Zoo Bomb (and cracked his helmet in the process). He’s at home today on pain medicine and we hope that he has a swift recovery.

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

Robby Russell — Fri, 27 Jul 2007 13:40:00 -0500

Yesterday, I started to dig deeper into YSlow and decided to pick an application that we recently launched for a client. The performance grade that I saw at first was an F, which wasn’t surprising to me because we knew that there was going to be some fine tuning in the near future.

There is a lot of JavaScript in this application and we have several files to break up stuff to make it more maintainable. However, in production, we really don’t need to send the client (browser) 19 different JS files. We’ve been using mod_deflate to compress these files, but it doesn’t solve the problem of having several connections opening to download all the necessary JavaScript. The same is true for our CSS files.

At RailsConf, DHH announced that an upcoming version of Rails would bundle all the stylesheet and javascript files into one file and compress it. We’re running on 1.2.x for this application and decided to look at the AssetPackager plugin as a good solution to this problem.

I installed the plugin via piston and ran the following task, which is provided by AssetPackager.

rake asset:packager:create_yml

This went ahead and created config/assets_packager.yml. I then went ahead and updated our capistrano configuration to call the rake task after updating the code on the server when deploying.


desc "all of our other tasks/commands to run after updating the code" 
task :after_update_code do
  #
  # all of our other tasks/commands
  #
  run "cd #{release_path} && rake RAILS_ENV=production asset:packager:build_all" 
end

The first thing that I noticed was that the yml file that gets generated will not make any assumption as to what order the javascript libraries should be loaded. So, immediately, line 1 of our compressed javascript file was causing an error as the code was trying to reference a library that hadn’t been defined yet (showed up later in the file). So, when you do this, you’ll need to organize the yml file to load things in order that they are needed. This was also a good opportunity for us to say, “oh, we’re not using that one anymore. Let’s remove it.”


--- 
javascripts: 
- base: 
  - prototype  
  - effects
  - scriptaculous
  - controls
  - dragdrop
  - application
  - slider
  - pngfix
  - nav
  - lowpro
  - lightbox
  - folder
  - builder

Great, so we re-dployed and everything at first glance seemed fine… or so we thought!

We used the unobtrusive javascript plugin for this project and it seems that we couldn’t just compress every single file. Each page has a behaviors javascript file and since everything was being compressed into one file (and cached), RJS calls quickly broke throughout the site. OH NO!

So, I opted to merge all of the other javascript files and use the standard way of including unobtrusive javascript in the application layout.


<%= javascript_include_merged :base %>
<%= javascript_include_tag :unobtrusive %>

We also removed lowpro from the list of javascript files to compress since the ujs plugin is currently including this when we call <%= javascript_include_tag :unobtrusive %>. I plan to look into modifying this so we it’ll only include the page-specific behaviors and not load the lowpro javascript file (so we can compress that as well).

Once this was re-deployed, we saw that the RJS issues were resolved and everything felt to be loading quicker. But, let’s look at YSlow again for step 1 in improving the performance of the application.

side note: the following grading was also after making some other adjustments that were suggested by YSlow, which I’ll discuss in another blog post soon.

So, where we once had a grade F, we now have an D… which is due to the client having us add several (four) external javascript files for mint, google analytics, etc. We’re only loading 3 javascript files for the application, when we were originally loading many more.

Obviously, there is some more tuning to be done, but we went from a grading of 43 to 74 in about three hours of time spent reading the YSlow documentation, adding asset_packager, and making various tweaks to our web servers (as suggested by YSlow).

Until next time…

Every Second Counts with a Piston in your Trunk

Introducing Boxcar... coming soon to a train station near you!

Robby Russell — Tue, 08 May 2007 15:35:00 -0500

As I just announced on the PLANET ARGON blog... our new hosting solution is almost here!

Last month, we put a freeze on new orders on several of our Rails hosting packages so that we could do some remodeling. Well, we’re almost done and excited about what we’re going to be reopening with. :-)

We’ll be posting updates on the PLANET ARGON blog over the coming days/weeks… so yo might consider subscribing to our feed.

Be sure to sign up on our mailing list to be amongst the first to be notified when Boxcar gets launched!

quote of the day: server tricks

Robby Russell — Tue, 27 Feb 2007 13:03:00 -0600

...overheard on an internal forum…

“My my passion for nifty server tricks will blow peoples minds”—Daniel Johnson

Goodbye Instiki, Hello JunebugWiki

Robby Russell — Tue, 06 Feb 2007 10:46:00 -0600

If you’ve spent much time on the Ruby on Rails wiki, you know that the spam situation smells like rotten fruit.

We’ve been using Instiki, the same software as the Rails wiki for the PLANET ARGON Documentation Project and the spam situation was becoming an annoyance. So, we’ve switched to JunebugWiki as step one, to see how it holds up. The default styling was a nice improvement because we haven’t had much chance to update the instiki one. It might not solve all of our spam problems, but in the short term, it appears to be a more elegant solution. It’s also the first application built with camping that I have personally deployed.

So… I present to you… the new PLANET ARGON Documentation Project.

In other news, it appears that RubyURL has caught the eye of spammers, which sucks. I’m still thinking over a few possible ways to try and prevent that. :-/

Remember When?

Robby Russell — Fri, 02 Feb 2007 00:49:00 -0600

I was looking through some old code from over two years ago, when I was playing with my first Rails applications. I noticed this hidden file in the public/ directory, called .htaccess.

Do you remember the good ‘ole days?


RewriteRule ^(.*)$ /dispatch.cgi?$1 [QSA,L]

I remember when we at PLANET ARGON first starting hosting Ruby on Rails applications (two years ago now!) and we had to continually explain to people that running on FastCGI was going to significantly improve speed over their default CGI deployment. This was one of the first FAQs that we posted on our website.

...oh how we’ve come a long way.

Before you know it, we’ll be on IRC and talking about the good ‘ole Rails days… like we do about the BBS days. ;-)

Do you have a remember when story related to Rails?

Goodbye Pound, Hello Nginx

Robby Russell — Thu, 01 Feb 2007 13:48:00 -0600

I’ve been using pound for several months and it’s been a good relationship. Except, for some strange reason, I noticed that I was getting development mode errors when it was running in production mode. I thought there might be an issue with my mongrel cluster… but that wasn’t the case.

Let me give you a little background to how we’re encouraging customers to handle their deployment on PLANET ARGON.

Most of our hosting customers¹ have three tiers (unless you have your own static IP address), one which we manage, two that you manage.

We handle the main web server/proxy server and proxy to your desired load balancer/proxy/server, which is generally any of the following options… depending on your preference.

Pound
Lighttpd
Nginx
Apache 2.x or Apache 1.3.x
Mongrel

Each customer has a unique proxy server port and a range of other ports for their mongrel clusters.

So… the typical setup is…

Apache(external:80) [proxies to]==> Pound(localhost:8050) [proxies to]==> Mongrel::Cluster(localhost:10500-10503)

Well, when a request comes in through Apache, it gets passed off to Pound and each tier has it’s own headers. By the time that it reaches Mongrel, all the requests appear to be coming from localhost.. not the remote address of the person using your application. Notice nothing but localhost requests in your production.log? ...this is the reason.

So, what side-effects does this have? Well, aside from every request looking local… Rails will, by default, output a normal development-mode error message if the request is coming from localhost.


    # found in...
    # actionpack/lib/action_controller/rescure.rb

    # Exception handler called when the performance of an action raises an exception.
    def rescue_action(exception)
      log_error(exception) if logger
      erase_results if performed?

      if consider_all_requests_local || local_request?
        rescue_action_locally(exception)
      else
        rescue_action_in_public(exception)
      end
    end

It seems that this currently causes the exception notification plugin, which we often use, to not work. We noticed this in a staging environment for an application that we’re building for a client about a month ago. After debugging SMTP servers, mongrel configuration… I was baffled.

Nginx to the `rescue`

After some investigation and attempts to find a workaround in Pound, I decided to redeploy my blog with Nginx. This was a pretty painless process and I was able to use the example posted on the PLANET ARGON Documentation Project.

Nginx allows you to do the following to overwrite the headers being passed to Mongrel.


    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

Problem Solved!

If there is a workaround for this in Pound, I’d love to be able to relay this information to our customers that haven’t made the switch yet.

Thank you, Brian and Timothy for encouraging me to finally switch my blog to Nginx. ;-)

If you have questions related to deploying Rails applications, be sure to check out the Rails Deployment google group.

¹ For more information about our hosting, visit http://planetargon.com/hosting.html.

Let's not forget the little people

Robby Russell — Wed, 24 Jan 2007 14:27:00 -0600

Yesterday, I announced the new Ruby on Rails Deployment group, which has attracted over 200 people and boasts over 50 messages in just the first 24 hours of it’s life.

While this is a greater turnout than I expected… I made a huge mistake yesterday. I forgot to invite the man behind the cutrain.


14:25 < zedas> robbyonrails: rubyonrails-deployment and i wasn't invited?
14:26 < zedas> i think i need to revoke some licenses. :-)
...
14:26 < jarkko> sounds robby just lost his mudcrap belt

I forgot to invite… Zed Shaw.

Zed,
I know that I’ve only met you briefly, but I feel like I’ve known you for years. With each and every mongrel I install, configure, and start… you’re always… right there… with me. This love goes deep.

Please forgive me for not inviting you to the show. I’ve asked the person sitting in the first row to move back a few rows to an empty seat… so you can sit here… right here… with me.

Please accept this letter and invite as an apology.
Robby

For everyone else, we have a few seats available near the back of the room, which you can reserve here. ...but before you do, be sure to recommend his work. [1]

¹ king of the world

Announcement: New Ruby on Rails Deployment Group

Robby Russell — Tue, 23 Jan 2007 14:52:00 -0600

Our team is working on a new hosting solution¹ for Rails applications. Throughout this process, we’ve been reviewing all the various methods that our team and customers have been using to deploy and host applications written with Ruby on Rails. Our team has been able to closely watch the technologies change on our servers for almost two full years to accommodate the latest in deployment solutions.

Recently, a few deployment savvy customers of ours and us decided that it was time to take some of our experiences and conversations out into the public. We’d like to invite all of you that are interested in Rails deployment to join the new Deploying Rails google group. Whether you’re trying to setup a staging server, deploy to a shared solution like we offer at PLANET ARGON, managing your own VPS, or configuring a cluster of servers for your big launch, we’d love to talk with you about this stuff.

I’m secretly hoping that all the talented Rails deployment experts, like our friends at Rails Machine and Engine Yard, will join us in our effort. :-)

If you’re still hosting your Rails application on Apache and FCGI in a shared environment, this list is for you! ;-)

Join the group today!

UPDATE Zed Shaw has entered the building…

¹ Stay tuned in early February… ;-)

Rails applciation caching with memcache

Robby Russell — Sat, 14 Oct 2006 18:24:00 -0500

Courtenay has posted a step by step tutorial on using memcache within your Rails application. He not only discusses caching… but also how to “precache the data so that each page load is blazing fast without sacrificing user experience.“

Read more about it on the caboo.se blog.


< court3nay> robbyonrails: hey, i wrote that line just for you
< court3nay> robbyonrails: the one you quoted. i was actually thinking, "hmm, i bet robby will like this quote"

I’m touched… and it’s great to hear that people are thinking more about these problems. :-)

Rails and Mongrel go to the Pound

Robby Russell — Tue, 08 Aug 2006 19:35:00 -0500

We’ve been encouraging our Rails hosting customers to give Pound and Mongrel a try for deploying their Ruby on Rails applications. David Gibbons has been adding some recipes for doing this on the PLANET ARGON Documentation Project

Check out:

...and today David posted an article on his blog titled, Why you need multiple mongrel instances with rails!