bgror

Engine Yard AppCloud CLI »

Created at: 20.07.2010 12:00, source: Engine Yard Blog, tagged: Uncategorized

At Engine Yard we've been helping developers ship Ruby applications for almost four years. Our approach to deployment has changed a few times but at its core our focus has always been helping people deploy and scale Ruby on Rails applications on virtualized hardware. Almost two years ago, we started experimenting with Amazon's AWS service and realized that people wanted more of a self service setup. For the first time, we decided to take a stab at providing the same kind of service on other people's hardware instead of our own. This has grown into our AppCloud offering. Today, we're happy to announce an awesome new addition to AppCloud that enables developers to ship code faster, easier, and straight from the command line.

A Bit of EY History

In our early days, we provided our customers with customized capistrano recipes to deploy their ruby applications to our clusters. A problem quickly arose because we also needed to help them maintain this recipe as we helped them scale their applications. We learned that keeping our customers' capistrano recipes up to date was a truly painful exercise, so when we built AppCloud we went with a more centralized approach.

Early AppCloud Direction

We thought that solving the problem of keeping most of the deployment related information in sync was so painful that we built a web based deployment strategy. It wasn't the worst idea ever, but the disconnect between leaving your shell and going to a web browser isn't really what developers want. In addition, we were so excited about the idempotency that chef offered at a configuration level that we felt it was imperative to "verify" the state of the system with a chef run each time we shipped code. This made pushing code slower than necessary and occasionally created panic situations if the chef run failed for some strange reason. People could still use capistrano with AppCloud, but it required them to re-download their deployment recipes every time their environment changed. There also wasn't an easy way to maintain customizations if customers kept having to re-download the capistrano recipe. Over and over again, we kept hearing the same complaints from customers. Customers liked the provisioning flexibility on AWS but shipping code on AppCloud was suboptimal. A few months ago, we finally admitted that our intentions were correct but we hadn't been doing the best things for our customers. We started working on a way to help our customers ship code more effectively.

Customer Feedback is Awesome

We accepted that idempotency is extremely important when it comes to system configuration but that doesn't mean you need to re-run chef each time you ship application code. We realized that people want to see their code running on their servers ASAP. Finally, we embraced the idea that people want to ship code with a command line tool similar to the way most people use rake to run their test suite. We're happy to introduce a more pleasant way to ship code to AppCloud, the engineyard gem.

A Better Workflow

The old way of deploying with chef works, but it forces you to reconfigure your servers every single time you deploy. The workflow looked like this: * Boot some instances (provision, configure, deploy) * Ship code (run configuration, deploy code) * Ship code (run configuration, deploy code) * Ship code (run configuration, deploy code) * Tweak system configuration (configure) * Ship code (configure, deploy) * Ship code (configure, deploy) * ... With the Engine Yard CLI, you can deploy without verifying your system's configuration, so it's quite a bit faster to ship new code. The new workflow looks like this: * Boot some instances (provision, configure) * Ship code (deploy) * Ship code (deploy) * Ship code (deploy) * Tweak system configuration (configure) * Ship code (deploy) * Ship code (deploy) * ... We really think our customers are going to prefer this approach because, let's face it, we ship code way more often than we reconfigure systems.

Get Started

* gem install engineyard * cd ~/myapp * ey deploy One of the things we like most about the new CLI is that it shows you, in real time, what's going on with your deploy. If something goes wrong, you don't have to scroll through a huge log in your browser; the error messages are right there in your terminal. When it succeeds, the process exits, so you know immediately that it's done. No more staring at the dashboard waiting for a spinning dot to turn into a green one. How about ey deploy && mpg123 woohoo.mp3 || mpg123 sad-trombone.mp3? That's immediate, unmistakable, annoying, audible feedback. You can't get that from a green dot.

Other Great Features

* Full Bundler Support * Maintenance Pages * Deploy Hooks for Extra Configuration * Advanced Deployment Customization * Ensure System Configuration is Current You can do a lot more than just deploy with the engineyard gem. Check out the docs and the FAQ. Go forth and ship!

more »

Concurrency and the AASM Gem »

Created at: 19.07.2010 12:13, source: Engine Yard Blog, tagged: Uncategorized

Your Ruby on Rails code is run concurrently, whether you like it or not. Concurrency is a staple term when talking about hosting infrastructure, but it is too often brushed aside when discussing actual code bases. This attitude is especially prevalent in the Ruby on Rails community: I can't name one popular plugin that gets it right. In this post I will address problems with the typical state machine pattern used by Rails applications, and show you how to address them and make your code bullet-proof.

The Problem

Consider the following controller action, backing a big green "ship button" next to a purchase order:

def ship
  @order = PurchaseOrder.find(params[:id])
  @order.ship!
  redirect_to order_path(@order)
end

Imagine two users both press the "ship" button at the same time. (Or as often happen, one user double clicks the button.) The two requests will hit the load balancer and be distributed out to run on different processes. What happens when the above code---typical of many rails applications---is run in two different places at the same time? Both processes will load the order from the database at line 2. At line 3 when the ship! method is run, both processes will check the attributes of the order and see that it is currently unshipped. As a result, both execute shipping code, which may include sending emails, updating caches, and transferring funds. As a result, the customer will receive duplicate emails, or worse, be charged twice. All versions of acts_as_state_machine (AASM) exhibit this behavior.

The Fix

Any time you read data from the database with the intention of making changes based on that data ("ship the order if it isn't already shipped") you must obtain an exclusive database lock on the row (or employ some form of optimistic locking strategy when updating, a topic not covered in this post). The database will block any processes trying to access that row until the session that obtained the lock concludes its transaction (COMMIT or ROLLBACK). ActiveRecord allows us to do this using the :lock flag:

def ship
  PurchaseOrder.transaction do
    @order = PurchaseOrder.find(params[:id], :lock => true)
    @order.ship!
  end
  redirect_to order_path(@order)
end

Working through the above example again, the first process to execute the find will issue the following SQL:

SELECT * FROM purchase_orders WHERE id = 1 FOR UPDATE

Notice the "FOR UPDATE" on the end; this instructs the database to place an exclusive lock on the row. When the second process executes the find and submits the above SQL to the database, the database will wait for the first transaction to complete (after calling ship! and updating the state of the order) before reading and returning the row. The returned row will now have a state of "shipped", and as such the ship! method will effectively be a noop (no operation). The customer will only receive one email. It is also possible using ActiveRecord to lock an object that has been already loaded from the database:

def ship
  @order = PurchaseOrder.find(params[:id])
  PurchaseOrder.transaction do
    @order.lock!
    @order.ship!
  end
  redirect_to order_path(@order)
end

This is equivalent to a reload, but adds the "FOR UPDATE" suffix necessary for a database lock. It is an extra SQL statement (the order is selected twice), but is an easier pattern to abstract away.

class Order < ActiveRecord::Base
  # This method is usually provided by AASM
  def ship!
    return if shipped?
  # Important emails and computations
  end
  def ship_with_lock!
    transaction do
      lock!
      ship_without_lock!
    end
  end
  alias_method_chain :ship!, :lock
end

With alias_method_chain, we can continue to use exactly the same controller code we started with (just a plain call to ship!), and locking is handled for us in the background. Lost updates or duplicate execution won't be a problem for every website, but if you are starting to worry about the concurrency of your hosting infrastructure, it's worth having a look over your code too. If you’d like to join me for some hands-on work with this, I’ll be running classes at Engine Yard's San Francisco office on the 24th and 31st of July. Visit www.dbisyourfriend.com for course and registration details.

more »

RailsConf, Here We Come! »

Created at: 08.06.2010 00:22, source: Engine Yard Blog, tagged: Uncategorized

It's another year, and time for another RailsConf! The Engine Yard crew is on-site in force, as usual, and we're excited to meet you! We're set up right in the center of the Exhibit Hall, with swag, demos, and a gaggle of Rails experts who'd love to meet you. On the schedule we've got Keynotes from Yehuda Katz and Evan Phoenix (Engine Yard's Open Source Love Affair), along with talks from Andre Arko (Bundler: Painless Dependency Management), Evan Phoenix and Charles Nutter (Ruby's Dark and Dusty Corners + Rubinius 1.0), Jon Crosby (Engine Yard's Community Powered Cloud) and last but not least, Nick Sieger (Rails 3 + JRuby: Awesome Framework, Awesome Platform)—so whether you're looking to get up to date on JRuby, Rubinius, Rails 3 or anything else, we've got all the info you'll need. Got a question about your app or setup? Curious about Rails 3? We've got engineers, sales reps, support techs—all on site and waiting to help. Just want the latest n' greatest Engine Yard tee (new design!)? We've got that too, complete with awesome attendee giveaways! Stop by and say hello—we'll see you there!

more »

Baltimore Welcomes RailsConf With Open Arms »

Created at: 18.05.2010 05:39, source: Rails Inside, tagged: Uncategorized

Baltimore's Rails community has been eagerly anticipating RailsConf next month. They've organized a few different projects to welcome Rails programmers to the city:

Ignite RailsConf: an unofficial pre-party held on June 6th with a variety of lightning talks, featuring Ruby luminaries like Chris Wanstrath, Gregg Pollack, and Ilya Grigorik.

Stay with a Local, a website to connect RailsConf attendees with Baltimore Rubyists. 9 Bmore on Rails members have opened up a total of 12 rooms in their homes to host attendees traveling to Baltimore.

BohConf, a free unconf running in parallel with RailsConf. It will be held in the convention center for the duration of RailsConf. This hacking-centric event will include community code drives featuring well known OSS authors, a code retreat, a programming competition, and "BarCamp"-style discussions.

[post by] Mike Subelsky is co-founder of the Rails-backed startup OtherInbox. He occasionally blogs at subelsky.com and lives in Baltimore.

Tweet This Post

more »

Announcing Engine Yard University: Zero to Rails 3 »

Created at: 13.04.2010 20:00, source: Engine Yard Blog, tagged: Uncategorized training

It’s been a busy few months at Engine Yard! We’ve been working on numerous new projects and programs, and today, we’re proud to announce the launch of Engine Yard University, a new program designed to help new and old Rails developers keep their skills up to date, and up to snuff.

Our first training class, Zero to Rails 3, will be held on May 17-19, right here in San Francisco! The course was designed by Rails experts Tammer Saleh and Randall Thomas, with help from our Rails core committers and partners; of course, it covers the latest in Rails 3. Based on real-world best practices distilled from working with over 1,000 customers, Engine Yard University courses are designed to get enterprise development teams up to speed quickly on Rails, JRuby, Agile development, and other technologies.

Zero to Rails 3 is an introductory class for developers who are new to Rails, and covers everything developers need to know to get started developing successful Rails 3 applications. Following this course, we’ve got several courses queued up for more experienced developers, including classes in Advanced Rails 3, JRuby and Scaling Rails.

In addition to providing developers with solid Rails instruction, the Engine Yard University program was designed with our valued partners in mind. In the coming months we’ll announce training partners, and a full program to get others up and running teaching their own Rails courses—so if we can’t make it to your area, we can get you set up to bring the course to town yourself.

As an added bonus, Engine Yard customers receive a discount on all classes offered and taught by Engine Yard! Email training@engineyard.com and we’ll get you set up with a discount code.

Reserve your seat for Zero to Rails 3 now!

more »