Advanced server definitions in Capistrano

What if you have several servers with different users, ssh-keys, and even port numbers? How to manage all this stuff flexibly ? This tutorial covers poorly documented Capistrano features for advanced servers and roles configuration. Many of them obtained via digging into Capistrano sources.

This article covers following Capistrano topics:

• roles configuration
• server configuration
• The way HOSTS, ROLES, HOSTFILTER, HOSTROLEFILTER variables affect configuration
• :roles and :hosts settings in the task and run methods
• How to specify server settings with :hosts option?

Before we start lets create minimal recipe.

Bootstrap

$ gem install capistrano
$ mkdir test
$ cd test
$ capify .

Capistrano loads only two standard recipes by default:

$ cap -T
cap invoke    # Invoke a single command on the remote servers.
cap shell     # Begin an interactive Capistrano session.

Let’s create our own simple configuration from scratch. Before we choose good server names!

Assume we have several servers with following DNS names:

• mr-white.reservoir.dogs
• mr-orange.reservoir.dogs
• mr-blonde.reservoir.dogs

Lets give our servers some roles at config/deploy.rb:

  role :dog, 'mr-white.reservoir.dogs', 'mr-orange.reservoir.dogs', 'mr-blonde.reservoir.dogs'
  role :boss, 'mr-white.reservoir.dogs'
  role :nerd, 'mr-orange.reservoir.dogs', 'mr-blonde.reservoir.dogs'

Alternatively you may declare it with server option:

  server 'mr-white.reservoir.dogs',  :dog, :boss
  server 'mr-orange.reservoir.dogs', :dog, :nerd
  server 'mr-blonde.reservoir.dogs', :dog, :nerd

Read the rest of this entry »

Capistrano delivery via Patch

Today we’ll talk about lightweight deployment method for your applications via Capistrano.

Preface

Standard capistrano deployment via ‘cap deploy’ is quite sufficient, but the standard deployment isn’t very fast. Each time, you have to do following:

• check out the code
• create symbolic links
• run your custom tasks
• switch to a new release
• reload your back-end (passenger, unicorn, etc) processes
• reload your background (daemons, resque-workers, etc) processes
• and run deployment notifications

On top of that, real projects are big and often have several megabytes of code. Sometimes, you need to quickly apply a ‘hotfix’ for a critical bug. Usually, a fix like that is small enough (containing only several lines of code) and affects only a part of the application. If so. it’s not necessary to restart the whole application – you need to restart only part of the running processes. In the end, you don’t need to go through the entire deployment process.

The simple, but NOT RECOMMENDED, solution is to go to each server, manually change bad code, and then restart the back-end processes. It’s a bad idea for many reasons:

• you must change the same code N times where N is number of servers
• it is painful to switch back to original code
• it’s a boring process and so there’s always the opportunity for mistakes because of the human factors

But then, how can you deliver a ‘hotfix’ in the right way? Try another approach called, capistrano patch.
Read the rest of this entry »