常用capistrano技巧
https://gist.github测试数据/111597
使用capistrano同步本地和远程的mysql
Top 5 uses for Capistrano
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 alex@example测试数据:/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 endSample 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 endhttp://source.mihelac.org/2007/01/10/capistrano-get-method-download-files-from-server/http://HdhCmsTestmartin-probst测试数据/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
http://railsmachine.github测试数据/moonshine/
另外这个
capistrano-boss
也是相当的强悍
https://github测试数据/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测试数据:#{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测试数据/capistrano/
有一些非常见的参数的介绍
Capistrano Recipe to Install or Update Passenger
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-recipesTook 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_passengerInstall
#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" endSource
http://grosser.it/2008/10/10/capistrano-recipe-to-install-or-update-passenger/
Basic recipe
Puppet vs. Capistrano – a short comparison
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 manuallyConclusion
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:
Enter your email address:
Related Posts
{ 3 comments… read them below or add one }
1 Andrew Shafer November 24, 2008 at 8:50 amLike 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.