epwzf20

means you don't have to be bothered with supplying a password every time you want to SSH into a remote server.

Configuring public-key authentication is also important when setting up Capistrano to automate the deployment process, because otherwise you'll have to configure Capistrano to provide a password every time you want to deploy the latest changes to your website.

Configuring Public-key Authentication on Unix/Linux

If you're running a Linux/Unix-based system, creating a public key pair is a pretty simple process. Although I won't be covering the configuration process for Windows or OSX-based systems, I nonetheless suggest carefully reading this section as it likely won't stray too far from the steps you'll need to follow. Start by executing the following command to generate your public and private key:

$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/wjgilmore/.ssh/id_rsa):

Unless you have good reasons for overriding the default key name and location, go ahead and accept the default. Next you'll be greeted with the following prompt:

Enter passphrase (empty for no passphrase):

Some tutorials promote entering an empty passphrase (password), however I discourage this because should your private key ever be stolen, the thief could use the private key to connect to any server possessing your public key. Instead, you can have your cake and eat it to by defining a passphrase and then using a service called ssh-agent to cache your passphrase, meaning you won't have to provide it each time you login to the remote server. Therefore choose a passphrase which is difficult to guess but one you won't forget.

Once you've defined and confirmed a passphrase, your public and private keys will be created. You'll next want to securely copy your public key to the remote server. This is probably easiest done using the scp utility:

$ scp ~/.ssh/id_rsa.pub username@remote:publickey.txt

You'll need to replace username and remote with the remote server's username and address, respectively. Next SSH into the server and add the key to the authorized_keys file:

$ ssh username@remote

...

$ mkdir ~/.ssh

$ chmod 700 .ssh

$ cat publickey.txt >> ~/.ssh/authorized_keys $ rm ~/publickey.txt

$ chmod 600 ~/.ssh/*

You should now be able to login to the remote server, however rather than provide your account password you'll provide the passphrase defined when you created the key pair:

$ ssh username@remote

Enter passphrase for key '/home/wjgilmore/.ssh/id_rsa':

Of course, entering a passphrase each time you login defeats the purpose of using public-key authentication to forego entering a password, doesn't it? Thankfully, you can securely store this passphrase using a program called ssh-agent, which will store your passphrase and automatically supply it when the client connects to the server. Cache your passphrase by executing the following commands:

$ ssh-agent bash $ ssh-add

Enter passphrase for /home/wjgilmore/.ssh/id_rsa:

Identity added: /home/wjgilmore/.ssh/id_rsa (home/wjgilmore/.ssh/id_rsa)

Try logging into your remote server again and this time you'll be whisked right to the remote terminal, with no need to enter your passphrase! However, in order to forego having to manually start sshagent every time your client boots you'll want to configure it so that it starts up automatically. If you happen to be running Ubuntu, then ssh-agent is already configured to automatically start. This may not be the case on other operating systems, however in my experience configuring ssh-agent to automatically start is a very easy process. A quick search should turn up all of the information you require.

Deploying Your Website

With these general configuration steps out of the way, it's time to ready your website for deployment. You'll only need to carry out these steps once per project, all of which are thankfully quite straightforward.

The first step involves creating a file called Capfile (no extension) which resides in your project's home directory. The Capfile is essentially Capistrano's bootstrap, responsible for loading needed resources and defining any custom deployment-related tasks. This file will also retrieve any projectspecific settings, such as the location of the project repository and the name of the remote server which hosts the production website. I'll explain how to define these project-specific settings in a moment.

Capistrano will by default look for the Capfile in the directory where the previously discussed cap command is executed, and if not found will begin searching up the directory tree for the file. This is because if you are using Capistrano to deploy multiple websites, then it will make sense to define a single Capfile in your projects' root directory. Just to keep things simple, I suggest placing this file in your project home directory for now. Also, because we're using the Railsless Deploy gem to streamline Capistrano, our Capfile looks a tad different than those you'll find for the typical Rails project:

require 'rubygems'

require 'railsless-deploy' load 'config/deploy.rb'

Notice the third line of the Capfile refers to a file called deploy.rb which resides in a directory named config. This file contains the aforementioned project-specific settings, including which version control solution (if any) is used to manage the project, the remote server domain, and the remote server directory to which the project will be deployed, among others. The deploy.rb file I use to deploy my projects is presented next, followed by a line-by-line review:

35run "rm #{current_release}/public/.htaccess"

36run "ln -s #{current_release}/production/.htaccess

37#{current_release}/public/.htaccess"

38end

39

40 # After deployment has successfully completed

41 # create the .htaccess symlink

42 after "deploy:finalize_update", :create_symlinks

Because the deploy.rb is almost certainly new to most readers, a line-by-line review follows:

•Line 02 assigns a name to the application. While this setting is not strictly necessary in all deployment cases, this particular deployment file requires you to define this setting because of the particular deployment approach used on Lines 24 and 27. I'll talk about this approach and why this setting is needed in a moment.

•Line 05 defines the account name used to connect to the remote server. This user should logically possess all of the rights necessary to copy and manipulate the project files on the remote server.

•Line 08 defines the location of the project repository. It's possible to define a remote repository location, for instance pointing to a GitHub-hosted project, however because I'd imagine most readers will want to deploy a project which is hosted locally, I thought it most beneficial to present an example of the syntax used to point to a locally-hosted project.

•Line 11 defines the production server address. Capistrano will use this address when attempting to connect to the remote server.

•Line 14 defines the deployment destination's absolute path.

•Line 17 defines whether sudo must be used by the connecting user in order to carry out the deployment. If you don't know what sudo is, then chances are high this should be set to false.

•Line 20 defines the version control solution used to manage your project. Defining this setting is necessary because it will determine how Capistrano goes about deploying the project. For instance if :scm is set to :git then Capistrano will use Git's clone command to copy the project. As mentioned earlier in this chapter Capistrano supports quite a few different version control solutions. For instance, use :bzr for Bazaar, :cvs for CVS, :mercurial for Mercurial, and

:subversion for Subversion. If your project is currently not under version control, this can be set to :none.

•Line 21 defines the repository branch you'd like to deploy. Repository branching is out of the scope of this chapter, however if you are using version control and don't know what a branch is, you can probably safely leave this set to master.

•Line 24 tells Capistrano how the files should be deployed to the remote server. The :copy strategy will cause Capistrano to clone the repository, archive and compress the cloned repository using the tar and gzip utilities, and then transfer the archive to the remote server using SFTP. An even more efficient strategy is :remote_cache, which will cause Capistrano to deploy only the latest commits rather than transfer the entire project. I suggest using :remote_cache if possible, however I am using :copy in this example due to repeated issues I've encountered using :remote_cache.

•Line 27 enables the :copy_cache option, which will greatly speed the deployment process when using the :copy strategy. Enabling this option will cause Capistrano to cache a copy of your project (by default in the /tmp directory), storing the cache in a directory of the same name as the :application setting. When set, at deployment time Capistrano will update this cache with the

latest changes before compressing and transferring it, rather than copy the entire repository.

•Line 30 tells Capistrano to ignore certain repository files and directories when deploying the project. For instance, when using the :copy strategy the .git directory can be ignored because there is no need for the remote server to have access to the project's repository history. Because the .git directory can grow quite large over the course of time, excluding this directory from the transfer process can save significant time and bandwidth.

•Lines 34-38 define a Capistrano task, which like a programmatic function defines a grouped sequence of commands which can be executed using a named alias :create_symlinks). This task is responsible for setting the Zend Framework project APPLICATION_ENV variable to production by deleting the original .htaccess file found in the transferred project's public directory, and then creating a symbolic link from the public directory which points to a production-specific version of the .htaccess file residing in a directory called production. You'll of course need to create this directory and production-specific .htaccess file, however the latter task is accomplished simply by copying your existing .htaccess file to a newly created production directory and then modifying this file so that APPLICATION_ENV is set to production rather than development. It is this crucial step that will ensure your deployed Zend Framework application is using the appropriate set of application.ini configuration parameters.

•The :create_symlinks task defined on lines 34-38 is just a definition; it won't execute unless you tell it to do so. Execution happens on line 42, done by overriding Capistrano's

deploy:finalize_update task which will execute by default after the deployment process has completed.

Whew, breaking down that deployment file was a pretty laborious task. However with deploy.rb in place, you're ready to deploy your website!

Readying Your Remote Server

As I mentioned at the beginning of this chapter, one of the great aspects of Capistrano is the ability to rollback your deployment to the previous version should something go wrong. This is possible because (when using the copy strategy) Capistrano will store multiple versions of your website on the remote server, and link to the latest version via a symbolic link named current which resides in the the directory defined by the :deploy_to setting found in your deploy.rb file. These versions are stored in a directory called releases, also located in the :deploy_to directory. Each version is stored in a directory with a name reflecting the date and time at the time the release was deployed. For instance, a deployment which occurred on February 24, 2011 at 12:37:27 Eastern will be stored in a directory named 20110224183727 (these timestamps are stored using Greenwich Mean Time).

Additionally, Capistrano will create a directory called shared which also resides in the :deploy_to directory. This directory is useful for storing custom user avatars, cache data, and anything else you don't want overwritten when a new version of the website is deployed. You can then use Capistrano's deploy:finalize_update task to create symbolic links just as was done with the .htaccess.

Therefore given my :deploy_to directory is set to /home/wjgilmore/gamenomad.wjgilmore.com, the directory contents will look similar to this:

current -> /home/wjgilmore/gamenomad.wjgilmore.com/ releases/20110224184826

releases 20110224181647/ 20110224183727/ 20110224184826/

shared

Note

If you start using Capistrano to deploy your Zend Framework projects, keep in mind that you'll need to change your production website's document root to /path/to/current/

public!

deploy:pending command, which will return a list of log messages and other commit-related information associated with those commits made since the last successful deployment:

$ cap deploy:pending

*executing `deploy:pending'

*executing "cat /home/wjgilmorecom/gamenomad.wjgilmore.com /current/REVISION"

servers: ["gamenomad.wjgilmore.com"] [gamenomad.wjgilmore.com] executing command command finished

commit 0380f960af0db2b5d8cfb8893cb07caf038c9754 Author: Jason Gilmore <wj@wjgilmore.com>

Date: Thu Feb 24 11:32:28 2011 -0500

Added special offer widget to the home page.

Test Your Knowledge

Test your understanding of the concepts introduced in this chapter by answering the following questions. You can find the answers in the back of the book.

•Provide a few reasons why a tool such as Capistrano is superior to FTP for project deployment tasks.

•Describe in general terms what steps you'll need to take in order to ready your project for deployment using Capistrano.

Conclusion

Every so often you'll encounter a utility which can immediately improve how you go about creating and maintaining software. Capistrano is certainly one of those rare gems. Consider making your life even easier by bundling Capistrano commands into a Phing (http://phing.info) build file, creating a convenient command-line menu for carrying out repetitive tasks. I talk about this topic at great length in the presentation "Automating Deployments with Phing, Capistrano and Liquibase". You can download the presentation slides and a sample build file via my GitHub project page: http:// www.github.com/wjgilmore/.

Appendix A. Test Your

Knowledge Answers

This appendix contains the answers to the end-of-chapter questions located the section "Test Your Knowledge".

Chapter 1

Identify and describe the three tiers which comprise the MVC architecture.

The MVC architecture consists of three tiers, including the model, view, and controller. The model is responsible for managing the application's data and behavior. The view is responsible for rendering the model in a format best-suited for the client interface, such as web page. The controller is responsible for responding to user input and interacting with the model to complete the desired task.

How does the concept of "convention over configuration" reduce the number of development decisions you need to make?

Convention over configuration is an approach to software design which attempts to reduce the number of tedious implementational decisions a developer needs to make by assigning default solutions to these decisions. How to best go about managing configuration data, validate forms data, and structure page templates are all examples of decisions already made for you when using a web framework which embraces this notion of convention over configuration.

Name two ways the Zend Framework helps you keep your code DRY.

Although the Zend Framework reduces code redundancy in a wide variety of ways, two ways specifically mentioned in Chapter 1 include the ability to create and execute action helpers and view helpers.

Chapter 2

What command-line tool is used to generate a Zend Framework project structure?

The command-line tool commonly used to generate a Zend Framework project and its constituent parts is known as zf.