CSCI E-168

[Draft!]

I should say a word or two about why deploying is so annoying.

The big problem with deploying is that even if we do it every other day or so, we do it infrequently. Because we do it infrequently, we don’t really spend a lot of time refining it. We get it to work, and forget about it, hoping that our deployment scripts will work the next time. When the deployment scripts break, we typically go into “open book” mode, spending a lot of time with Google.

Like a lot of things in Rails, when Capistrano came out it was somewhat ahead of the curve. Now it’s somewhat behind the curve, but is still something of a standard. Capistrano is not getting a lot of active development, so keep your eye for a new deployment system. One that has some mindshare these days is Vlad the Deployer (http://rubyhitsquad.com/Vlad_the_Deployer.html).

So . . . the following recipe should work. But deployment scripts break. Be prepared for some scrounging to get this to work if you find you have to alter some aspect of it to your own requirements.

A few assumptions: You will need to be able to ssh to your remote host, so review that from the last couple of screencasts. You will need to remember how to use sudo. You will need to know the name of your application and the directory in which it will live — in the example below, we’re going to use the “ajax” example application, and called it “ajax-capified.”

1. Install the Capitrano gem, and “capify” your application:

   gem install capistrano
   cd your/app/path
   capify .
   

   Note that the last command is “capify” followed by a space, followed by a period, which means: Create the Capfile and config/deploy.rb files for the project in the current directory (.).

2. Once this is all set up, the application is going to live in /home/ubuntu/sites/ajax-capified/current. Let’s update the Passenger (see Part 2) setup now so that once everything is in place, Passenger will find the code. So ssh over, do “sudo bash”, and edit /etc/apache2/sites-available/default, and change the two occurrences of /home/ubuntu/myapp/public to /home/ubuntu/sites/ajax-capified/current/public — after doing this, mine looks like this:

   <VirtualHost *:80>
     ServerName ec2-174-129-169-212.compute-1.amazonaws.com
     DocumentRoot /home/ubuntu/sites/ajax-capified/current/public
     <Directory /home/ubuntu/sites/ajax-capified/current/public>
       AllowOverride all
       Options -MultiViews
     </Directory>
   </VirtualHost>
   

   Also, you should restart Apache right now; after this, we will restart
   the application in a different manner:

   /etc/init.d/apache2 restart
   

3. Now, we need to make some changes to the default config/deploy.rb file. We’re going to need to go through this line-by-line. Here’s what ours looks like. You should study the comments, and compare this file to the default one that is created by the capify command.

   # Used by logging
   set :application, 'ajax-capified'
   
   # The directory on the remote system that will contain release versions
   # and the "current" release (which is a symlink to the last good release).
   # NOTE: This should be an absolute path (beginning with /).
   set :deploy_to, '/home/ubuntu/sites/ajax-capified'
   
   # If your code is checked into a repository for source control . . .
   #   set :repository,  "set your repository location here"
   #   set :scm, :subversion
   # In this example, we're going to skip source control.
   set :repository, '.'
   set :scm, :none
   set :deploy_via, :copy
   
   # Log in as this user for setup and deployment
   set :user, 'ubuntu'
   
   # We want to avoid using the root user
   set :use_sudo, false
   
   # Our single server will serve all of the available roles; Capistrano
   # is designed to allow for having the different roles be served by
   # different computers.
   server 'ec2-174-129-169-212.compute-1.amazonaws.com', :web, :app, :db, :primary => true
   
   # Specify the private key you will use
   ssh_options[:keys] = [File.join(ENV['HOME'], 'Desktop', 'e168', 'id-jgn-demo')]
   
   # For Passenger
   namespace :deploy do
    task :start do
    end
    task :stop do
    end
    desc "Restart the application in Passenger"
    task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
    end
   end
   

4. For production, we’re going to switch the database to MySQL. If you did what I suggested in prior screencasts, and didn’t define a password for the root MySQL user, all you need to do is change the “production” block in config/database.yml to . . .

   production:
    adapter: mysql
    database: ajax_capified_production
    pool: 5
   

5. Let’s create that database. ssh to your system, and . . .

   mysqladmin -u root create ajax_capified_production
   

6. Now we’ll do cap deploy:setup — this creates the directory structure.

   cap deploy:setup
   

   At this point, you might want to ssh over to your system and see what’s there. What you should find is a “sites” directory, and inside of that, a directory named after our app (ajax-capified). Then within that, directories called releases/ and shared/. Your code will be copied into releases/ under a timestamped directory name; when the deploy is finished, a directory under ajax-capified named current/ will be symlinked to the last release that successfully deploy.

7. and . . . finally . . .

   cap deploy:migrations
   

   This is the most important command in your arsenal, because it will run your migrations
   and deploy the latest code. Once you’re set up, this is the command you’ll
   run over and over: Make changes to your code, add migrations, etc.; test
   them in development mode, and run tests. Then when everything’s right, deploy
   to product with cap deploy:migrations

8. That’s it! Next screencast: DNS.