This is a technical post about Capistrano, a tool that makes deploying software to servers more manageable.
I use Capistrano to deploy changes to Helicoid’s applications to our servers. However, Capistrano also comes in handy for lots of things beyond deployment. Here’s my top 5 Capistrano tips beyond deployment.
1. Signup statistics
When running advertising campaigns I find it’s useful to see the impact on signup statistics. I used Capistrano to connect to servers and query our databases to gather registration data. It’s fairly easy to output tables and graphs as well.
In Analytics with Capistrano I wrote about this in more detail with some code snippets.
2. Server backups
For a small or medium-sized project, Capistrano can be used to automate off-site backups. I wrote a Capfile to backup one server to another one in another datacentre using rsync
and mysql dumps. By relying on existing backup software (or the often used rsync) Capistrano is simply used to orchestrate remote and local backup-related tasks.
You can prompt for database passwords if you don’t want to store them in your Capfiles:
set(:mysql_password) do
Capistrano::CLI.ui.ask 'Enter mysql admin password: '
end
run "mysqldump -u username -p my_database > /home/alex/Backups/my_database.sql" do |ch, stream, out|
ch.send_data "#{mysql_password}\n" if out =~ /^Enter password:/
end
sudo "gzip /home/alex/Backups/my_database.sql"
Using rsync to backup files to the local machine would call system
rather than run
:
system "rsync -a -e ssh [email protected]:/home/alex/Backups/ #{BACKUP_TARGET}/files/"
This came in handy when I wanted an additional backup to the service the datacentre provided internally.
3. Quickly viewing remote Rails objects
When addressing a bug report I occasionally need to see the properties of live data. I use the following little snippet to let me do this:
cap show -s command='User.find(1)'
task :show, :roles => :app do
run <<-COMMAND
/u/apps/tiktrac/current/script/runner -e production ‘require “pp”; pp #{command}’
COMMAND
end
4. cap shell, distributed uptime
This is an obvious one, but if you haven’t tried it before it’s worth adding to your toolbox.
Typing cap shell
will give you a Capistrano shell on your remote machines. Issuing a command will issue it on each machine. Typing with role_name
before the command will run it on one machine.
Seeing as the commands are executed on each machine, an innocuous issuing of uptime
will let you see the state of several servers at once.
5. Upgrade more than one machine at once
Now apply the previous tip to sysadmin tasks. Consider this:
cap shell
sudo apt-get update
Capistrano get method - download files from server
Still looking if there is better way to do this (and I bet there it is :), but until I realize, add to top of deploy.rb:
# Get file remote_path from FIRST server targetted by
# the current task and transfer it to local machine as path, SFTP required
def actor.get(remote_path, path, options = {})
execute_on_servers(options) do |servers|
self.sessions[servers.first].sftp.connect do |tsftp|
logger.info "Get #{remote_path} to #{path}"
tsftp.get_file remote_path, path
end
end
end
Sample recipe to get production log from server:
task :download_log, :roles => :web, :only => { :primary => true } do
get "#{deploy_to}/current/log/production.log",
"log/production.log.web" //download server log
end
http://source.mihelac.org/2007/01/10/capistrano-get-method-download-files-from-server/
http://www.martin-probst.com/blog/2007-11-20-mysql-backup-restore-task-for-capistrano
一个和capistrano集成使用的扩展插件 moonshine 我觉得还是不错的,还没有用起来
Rails deployment and configuration management done right. ShadowPuppet + Capistrano == crazy delicious
— Read more
另外这个
也是相当的强悍
https://github.com/ascarter/capistrano-boss
namespace :db do
task :sync_to_local, :roles => :web do
sql_out = "#{environment_database}.sql"
run "mysqldump --user #{dbuser} --password=#{dbpass} #{environment_database} > #{sql_out}"
system "sftp #{user}@myhost.com:#{sql_out} /tmp/#{sql_out}"
run "rm #{sql_out}"
system "mysql -u #{dbuser} --password=#{dbpass} mydatabase_development < /tmp/#{sql_out}"
system "rm /tmp/#{sql_out}"
end
end
# invoked: cap production db:sync_to_local 这里指定了模式调用
这里的可用资源很丰富
http://help.github.com/capistrano/
有一些非常见的参数的介绍
Update:
- the basic installation can be done via “passenger-install-apache2-module –auto”
- a better script that does the whole job can be found in cap-recipes
Took me some minutes to figure this out, so here for your laziness-pleasure (for Ubuntu):
Usage
To install passenger or update to the newest release:
cap install_passenger
Install
#deploy.rb
desc "Install Passenger"
task :install_passenger do
install_passenger_module
config_passenger
end
desc "Install Passenger Module"
task :install_passenger_module do
sudo "gem install passenger --no-ri --no-rdoc"
input = ''
run "sudo passenger-install-apache2-module" do |ch,stream,out|
next if out.chomp == input.chomp || out.chomp == ''
print out
ch.send_data(input = $stdin.gets) if out =~ /(Enter|ENTER)/
end
end
desc "Configure Passenger"
task :config_passenger do
version = 'ERROR'#default
#passenger (2.0.3, 1.0.5)
run("gem list | grep passenger") do |ch, stream, data|
version = data.sub(/passenger \(([^,]+).*/,"\\1").strip
end
puts " passenger version #{version} configured"
passenger_config =<<-EOF
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-#{version}/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-#{version}
PassengerRuby /usr/bin/ruby1.8
EOF
put passenger_config, "src/passenger"
sudo "mv src/passenger /etc/apache2/conf.d/passenger"
end
Source
Basic recipe
http://grosser.it/2008/10/10/capistrano-recipe-to-install-or-update-passenger/
Puppet vs. Capistrano – a short comparison
by Matthias Marschall on September 10, 2008 · 5 comments
We’re currently using Capistrano not only to deploy our Ruby on Rails application, but also to setup and manage our physical and virtual (Xen based) servers. We have Capistrano recipes for adding users, installing packages like apache or mysql, configuring a Xen VM and more. Coming accross puppet, I started to wonder about the essential difference between the two. Puppet claims to enable the user to automate server management to a large extent, a goal which we already reached by implementing our custom Capistrano recipes. So, what are the differences between the two?
Overall Goal
First, I tried to understand the overall goal of both tools. Capistrano was built with deployment of rails applications in mind. Of course, it is very easy to extend it to manage your servers like we did, and recipe collections like deprec add exactly that functionality to it, but still, the basic problem Capistrano adresses is deployment.
Puppet on the other hand started as a lifecycle management tool from the beginning. It offers a lot of possibilities to define dependencies and desired states of services like apache should be running and needs this and that package additionally to those config files. Puppet then tries everything to reach that desired state automatically. This difference in the overall goal leads us to the different approaches both tools are using.
Approach
Capistrano uses an imperative approach where you describe in recipes how to do things. Looking at Capistrano recipes gives you a kind of “dynamic” view on your systems. You can see how a specific configuration evolves step by step. The recipes answer the questions “What do I want to do”?
Puppet uses a declarative approach where you describe a desired state for your system configuration. Your manifests answer the question: “How should it look like”? Puppet derives the steps to take from the static configuration and applies them as needed automatically.
Feature Comparison
Here is a short comparison matrix showing some features I found interesting. It is by far not complete, but I hope it might give you an overview:
|
Puppet |
Capistrano |
Configuration language |
”Meta” language |
Ruby |
noop mode |
yes |
yes (since 2.5) |
Idempotence |
yes |
no |
Transactions |
yes |
yes |
Rollback |
no |
yes |
Ad-hoc server monitoring |
no |
yes |
Mode of operation |
deamon pulls config |
user pushes changes |
Dependency definition |
Dependency trees with services, packages, and files |
Single dependencies for dir, writability, command, gem and regex match |
Dependency resolution |
automatically |
manually |
Conclusion
Puppet acts on a different level than Capistrano dealing mostly with managing dependencies rather than scripting tasks. Puppet and Capistrano can play nicely together in a scenario where puppet is responsible for ensuring a certain system configuration and Capistrano is responsible for the more dynamic aspects like deploying new releases of your custom applications or ad-hoc server monitoring. But as my own experience and the success of deprec shows, Capistrano is a great help for configuring systems, too.
Did you enjoy this article? Get new articles for free by email:
{ 3 comments… read them below or add one }
Like your blog, stumbled on the Agile one and then, whoa, Puppet.
With Puppet rollback is a feature that we hope to add eventually to the framework, but for now, since Puppet is declarative code (which I hope you have in version control) a roll back is just reverting the code and running Puppet again.
Also with Capistrano, you don’t get generalized rollback and transactions on server management tasks unless you roll them all by hand yourself. Capistrano has a lot of scaffolding for deploying rails where this is built in, but after than you are sort of on your own.