In this conclusion to a five-part series on application deployment with Ruby on Rails, you'll learn how to create and use the Capistrano Deployment recipe. This article is excerpted from chapter 12 of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).
Application Deployment with Capistrano - Running the Setup Task (Page 2 of 2 )
To prepare the production server for deployment, we’ll use the setup task, which creates the required directory structure. To simulate a deployment to a clean environment, first delete the/udirectory we created earlier:
$ sudo rm -rf /u
Then kill any Ruby or LightTPD processes that might be running with the following commands:
By default, Capistrano deploys your application to the/udirectory. This directory can be created only by the root user, which means the deployment will fail if you run it now. To fix this, we’ll use a Capistranobeforefilter that creates the directory and then changes the access rights. Add the following task to the end of the deployment recipe (config/deploy.rb):
task :before_setup do sudo "mkdir -m 770 /u" sudo "chgrp rails /u" end
Note that we use thesudocommand to create the directory. Earlier, we also added therailsuser to thesudoerslist.
Now run thesetuptask in the root of the application directory:
By inspecting the output of the command, you can see that it executes thebefore_setuptask we added. If you log in to the remote machine, you will notice that Capistrano created the following directory structure:
Note that you need to run thesetup task only once.
Deploying to Production
Now that we have run the setup task, we can continue and start the Emporium application on the production server. We could check out the source from Subversion and execute thespawnerscript manually, but instead, we’ll introduce you to thecold_deployCapistrano task.
Thecold_deploytask does exactly what we need: first it executes the Capistranodeploytask and then thespawnertask. Recall that thedeploytask checks out the source code on the remote machine and thespinnertask starts the FastCGI processes. Executerakeas shown here:
Theappsdirectory contains a separate directory for all applications that have been deployed. Now there’s only one directory for Emporium, which contains a subdirectory namedreleases.
Thereleasesdirectory is where your application is deployed into a directory named after the time and date the build was created. Thereleasesdirectory is not referred to directly by scripts; instead, they refer to the symbolic linkcurrent. Thecurrentlink is updated by thedeploy task and points to the latest version of your application.
The next time you deploy your application, you can runrake deployinstead ofrake cold_deploy.
Note You should configure the Ferret search engine (introduced in Chapter 4) to store the index outside your application directory (for example,/u/apps/emporium/shared). This is because Capistrano deploys your application to a different directory each time you perform a deployment. If the index were in the application directory, Ferret wouldn’t be able to find it, and would create a new, empty one. One option is to put the indices inshared/index, and create anafter_deployhook that creates asymlinkfromcurrent/indextoshared/index.
Capistrano also has a built-in task that you can use for running database migrations during deployment on the remote machine. This means that you don’t need to create the database schema yourself, as you do when you deploy your application manually. Use the following command to run migrations along with the deployment:
$ rake remote:deploy_with_migrations
This checks out the latest version of the source on the remote machine. After the checkout has completed,rakeruns the migrations, which create the Emporium database.
The last step we need to perform is to start up LightTPD, which acts as a reverse proxy for the FastCGI processes. Again, we’ll create a new task in our deployment recipe to save us the trouble of having to manually log in to the remote server(s) and execute the command each time we want to start the web server.
Add the following task to the deployment recipe (config/deploy.rb):
task :start_lighttpd, :roles => 'web' do sudo "lighttpd -f /u/apps/emporium/current/config/lighttpd-production.conf" end
Notice that we have told Capistrano to run the task only on servers having thewebrole.
Next, run the task by executing the following command:
Tip You should need to start LightTPD web server only once. Rebooting the machine will, of course, kill your processes, so remember to create a start script that runs at reboot and that starts LightTPD and thespawnerprocess.
Open Emporium in your browser and do a quick test. You shouldn’t see any errors, which means that you have completed the deployment.
Before we wrap up this chapter, we should tell you that FastCGI processes are known to start acting crazy once in a while. The only option, usually, is to restart the processes. This is one of the reasons why you should install a system monitoring tool like Nagios (http://nagios.org/) or monit (www.tildeslash.com/monit/). These tools help you notice when things go bad—not only with FastCGI, but also with other processes and protocols.
In this chapter, you learned how to set up a real-world production environment. We showed you how to install LightTPD and FastCGI by compiling from source. We also explained how to configure LightTPD for use in a production environment. Then we showed you how to deploy an application manually. Finally, you saw how to automate the deployment process with Capistrano, which makes your life as a developer easier and drastically lowers the barrier for deploying new features into production (at least for procrastinators).
In the next chapter, we’ll show you how to tune an application’s performance.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.