Capistrano series - configuring Capistrano #2

So now Capistrano has created the base structure for the application deployment, we need to look at actually deploying it.

Let's look at some of the settings we need for this and then deploy the application for the first time.

---

deploy.rb

So far, the deploy.rb file looks like this:

set :application, "domain.com"
set :user, "demo"
set :repository,  "svn+project1ssh://123.45.67.890/home/demo/repository/project1"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

set :port, 30000

set :deploy_to, "/home/demo/public_html/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, application
role :web, application
role :db, application , :primary => true

Let's start by looking at how the deployment will be conducted and what we need to define for that deployment.

Subversion

We've already got subversion installed and configured on our local machine but what about the Slice?

On a default deployment, Capistrano will execute commands on the Slice and checks out the latest application version from the repository. However, we haven't setup the Slice to access the repository.

We also don't need to.

One of the problems with setting up the Slice to access the repository is that a private key will need to be placed on the Slice (if you want to have passwordless access).

This can be a security issue and the way I prefer to do it is to only allow the workstation to access the subversion repository.

This means that during a Capistrano deployment, the latest version will be checked out from the remote repository (to the workstation), compressed, sent via SSH to the Slice and then uncompressed.

This does mean it takes a few seconds longer to deploy an update but the increased security more than makes up for the slight delay.

Setting up Capistrano to use this deployment strategy is as simple as adding this to the deploy.rb file:

set :deploy_via, :copy

Mongrel user

An odd thing with the Capistrano script is that you will need to explicitly set the user that will start the mongrel instances.

If you don't set it, then the script will fail.

In this example, we'll use the same user as previously defined. You can, however, use another username if that fits better with your needs:

set :runner, user

deploy.rb

As we've added a couple of settings, let's have a reminder of what the deploy.rb file should look like:

set :application, "domain.com"
set :user, "demo"
set :repository,  "svn+project1ssh://123.45.67.890/home/demo/repository/project1"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

set :port, 30000

set :deploy_to, "/home/demo/public_html/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, application
role :web, application
role :db, application , :primary => true

set :deploy_via, :copy

set :runner, user

Initial deployment

So far, we have nearly everything setup to deploy our application.

However, one final thing we need to sort out is to let it know how to start the mongrels on the initial deployment.

This is done via a 'spin' file in the script directory.

We can create that now (remember we are still on the workstation, not the Slice):

touch script/spin

This file will contain the commands that Capistrano will use to control the mongrels.

As the file needs to be executable, we can ensure it has the correct permissions by setting the property in subversion

svn propset svn:executable on script/spin

So what do we put in the file?

At the moment, we only need one line that relates to our mongrel usage:

/home/demo/public_html/domain.com/current/script/process/spawner -p 8000 -i 2 -e production

As you can see, this sets the path to the 'spawner' script (which has been created for us), the port to start the mongrels on (8000 in this case), the number of mongrels (2 in this example) and the Rails environment to use.

Commit

We've made a few changes that need to be added to the repository.

Make sure you 'add' the files to subversion first - you can check what files need adding like this:

svn status

If any need adding (such as the script/spin file) then add them like so:

svn add script/spin

Lastly commit the changes to the subversion respository:

svn commit -m "added script/spin"

Nearly there

Again, a lot is happening here but we are very close to deploying and serving our application.

We're going to deploy the application for the first time now but I give a word of warning:

The application will not show for the domain

Eek!

Why not?

Well, the simple fact is that we haven't created a vhost for the domain yet (sure, we created a test vhost when we installed Nginx but we don't have one for the soon-to-be deployed application).

However, there is nothing stopping us from deploying the application for the first time. That only leaves us with creating a vhost for the application which, if you are super keen, can be done by referring to the original Nginx vhost article (the next article will go through the exact settings that we need though).

Initial Deployment

Let's get on with it.

To deploy the application for the first time needs a simple:

cap deploy:cold

You will see quite a lot of information scroll by in your terminal.

Once done (and it should end with a section entitled " Starting mongrel dispatchers") have a look at what Capistrano actually did.

It did everything we expected in that it checked out the latest code from subversion and compressed it to a temporary file, uploaded it, uncompressed it and then went through a quite complicated procedure of copying the code and creating symlinks, etc.

Lastly, as already mentioned, it started the two mongrel instances as defined in the script/spin file.

Nice.

Summary

Although possibly a little frustrating that we have to configure a vhost for the application, remember that Capistrano is not designed (by default) to install and configure the web servers for us.

Capistrano allows us to use an existing setup to deploy and serve our application with a single command.

The next article will create and define a vhost file so we can then view and interact with the web application.

PickledOnion