Deploying with Capistrano
What is Capisrano?
Capistrano is a deployment tool and is popularly used for deploying rails applications to your servers. But its a good configuration tool too. You can setup your servers using capistrano. You can preform tasks like adding users, installing and configuring packages like apache, mysql or postfix, a xen vm etc on your desired network host from a central server(wherever you kept the configuration repository).
Puppet and Capistrano?
Well., you might have heard about puppet – another popular network host configuration tool. Great..Now it will be easy to understand capistrano. If you haven’t, dont worry, I will make it clear for you.
The puppet is working in such a way that a puppet server will be running on one host in the nerwork. And all the desired hosts would run a puppet client daemon. You can configure your client manully and can automate installation on your clients. Whenever you want to change the configuration just do it on the server. It will be updated to the client as the client puppet daemons updates from the server in each interval that you specify. Now you would note that the client daemon pulls the configuration from puppet server. But in capistrano the user pushes the configuration to the desired client when he needs it. Puppet uses “meta language” for the configurations. Whereas capistrano uses ruby. And you know that you got several modules and feautres with ruby and so you may can write your additions to cap if you are well versed with that. One more thing you should note that puppet does its dependency resolution automatically, but in capistrano, you may have to handle the dependency manually in some cases. But as I said earlier you can overcome this if you know well and I would say it may be little difficult to go to that extent. But when you have done with a perfect configuration you feel it greatly helpful.
Installation and Configuration
To install just enter the command:
$gem install capistrano
Provided you have rubygems installed on your machine. If not, install it with apt or yum.
$gem install deprec
Note: I have found several docs without mentioning this..and it made my cap commands haden’t worked till I found this and installed..
Now create a repository as the source (central configuration repo) using svn. Svn is common version control system that is used in cordination with the cap. If you like git go with that.
$svnadmin create sparkconf
Sparkconf is the repository name where you will keep all the configuration of your servers. You can use your own repository name.
Configure this repo for access to the desired users. I wont go with svn details because its beyond the context of our topic.
now you can checkout your repo
$svn co <ur-repo-ulr> sparkconf
$cd sparkconf
$capify .
This “capify” command will initiate your cap repo. It will create a file named Capfile and a deploy.rb file in a directory named config. In capfile you can see that there is a statement to load deploy.rb file. So you can define your own tasks in Capfile or in deploy.rb. But usually this is not the convention. You would leave your Capfile without any changes. And you may specify some information about your setting in the deploy.rb file. The sample deploy.rb which is generated automatically, needs some explanation.
<br />
set :application, "agileblazeworks"<br />
set :repository, "report"</p>
<p>set :scm, :subversion<br />
# Or: `accurev`, `bzr`, `cvs`, `darcs`, `git`, `mercurial`, `perforce`, `subversion` or `none`</p>
<p>role :web, "rails.spark.com" # Your HTTP server, Apache/etc<br />
role :app, "rails.spark.com" # This may be the same as your `Web` server<br />
role :db, "rails.spark.com", :primary = true # This is where Rails migrations will run<br />
#role :db, "your slave db-server here"</p>
<p># If you are using Passenger mod_rails uncomment this:<br />
# if you're still using the script/reapear helper you will need<br />
# these http://github.com/rails/irs_process_scripts</p>
<p># namespace :deploy do<br />
# task :start do ; end<br />
# task :stop do ; end<br />
# task :restart, :roles =&gt; :app, :except =&gt; { :no_release =&gt; true } do<br />
# run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"<br />
# end<br />
# end<br />
Dont worry about the configuration here. Most of them are needed if you are deploying a rails application for a web server. After breifing this we will go for some other configuration options that you are really looking for…to install and configure packages on your hosts.
If your application (means your rails application) is not separated into application, web and database servers, you can either set them to be the same value; or comment out, or remove the one you do not require. The “:primary => true” part of the role definitions allows you to have more than one database server. If you dont have two skipp this primary option. If, for example when deploying a Rails application you only wanted db1 to run migrations, in the first example both might. Essentially when using the Rails deployment recipes, the :primary option defines where database migrations are run. Similar attributes include :no_release often used for the :web role by some of the recipes in circulation to decide which servers should not have the code checked out to them. Attributes like these are arbitrary and you can define some of your own, and use them to filter more precisely where your own tasks run.
You may add these options to the deploy.rb file
<br /> set :user, 'jaseer' #This is the user you have on the target machine. Capistrano try to login to the target machine using this account.<br /> ssh_options[:keys] = %w(/home/users/mylocalname/.ssh/jas_rsa)<br /> set :use_sudo, true #if you want to append all commands with sudo.<br /> set :password, "yourpassword" #You can login using key (above) or with password. Use either key or password..not both.</p> <p>default_run_options[:pty] = true #this is really helpful. If you dont have this you will struggle in runnig sudo tasks. I had lost some time searching around this.<br />
Some cap commands
$ cap -h
This will give out a list of all the options it accepts.
$ cap -H
It will give you a description of each option.
Next, let’s ask Capistrano what all tasks it will do. Capistrano comes bundled with several built-in tasks. You can also write your own to automate workflows of your own. For now, let’s see what tasks Capistrano knows:
$ cap -T
And finally, to get a detailed description of a command, type
$cap -e <task>
Example
Suppose you want install and configure nagios on one of your servers.
cap deprec:nagios:install HOSTS=monitor.spark.com
This command will install nagios on the host monitor.blocksglobal.com (You can use ip also). Iif you want to override the user in deploy.rb, or any other files, use the option USER=<username> option. This will ask your sudo password, as you know for some task you may need the administrator privileges.
Now generate configuration files
#cap deprec:nagios:config_gen
The configuration files are created in your localrepo not in the installed server. A directry tree is created under sparkconf/config/ with the name nagios. It will contain all configuration files of nagios like hosts.cfg, service.cfg etc. You can change each according to your needs. Update svn. Push those configuration to your client.
$cd config/nagios
Change and configure the files as your needs, commit the changes and update svn. Go back to the root of your repository, here it is sparkconf. Now push the config to your nagios server.
$cap deprec:nagios:config HOSTS=monitor.spark.com
Defining Tasks
Now let me explain how to define tasks. Often I would define my own tasks in config/*/recipes.rb for example config/nagios/recipes.rb. * Can be any thing like postfix, mysql as you generate the config directory for them using config_gen.
<br />
namespace : one do<br />
task :default do<br />
test<br />
one.test<br />
two.test<br />
end<br />
task :test do<br />
puts "Test One Successful!"<br />
end<br />
end<br />
namespace :two do<br />
task :test do<br />
puts "Test Two Successful"<br />
end<br />
end<br />
Here these are the available commands I can use with cap…
$cap one
$cap one:default
$cap one:test
$cap two
Hope you understood how to define them. Note in how many ways I called the task “test” inside the task default. This is easy right? Now go, create your repo and try your cap tasks..I will stop with a final simple example:
<br />
task :backup_database, :roles => :db, : only => { :backup => true } do<br />
run "#{sudo} mysqldump ... > /tmp/backup.sql"<br />
run "#{sudo} bzip2 /tmp/backup.sql"<br />
run "scp /tmp/backup.sql.bz2 offsite.host:/u/backups"<br />
run "#{sudo} rm /tmp/backup.sql.bz2"<br />
end<br />
Next time I will write one more article on deploying rails app using cap.. Have fun..bye
