Harnessing Capistrano: Notes Part 1

First off, I can not overstate how overwhelmingly popular the mac is. There are probably 100 laptops in the room right now and I see 4 non macs. It was the same this morning in the JRuby session which is where you would expect to find the more corporate people. Those who do have non macs appear to be running Ubuntu. I think I’m the only person with a windows box in the room. And I am a Mac user who only has this dell because work gave it to me. Not that this is news or anything, just thought I would mention it while I’m waiting for the room to fill out.

Presentation Slides

Capistrano started out as a deploy tool when basecamp got pushed to multiple servers. Now it is used for more, It can be used for

• ad-hoc monitoring
• server maintenance (they edited nfs mounts against 6 app servers with one command)
• troubleshooting - grep logs across multiple servers

Capistrano is a tool for executing tasks on remote servers.

Capfile

• internalruby dsl similar syntax to rake, but not compatible.
• specifies what servers to run against and what task to do.
• Gateways - Allow you to manage a cluster by tunneling through your 1 gateway server. Useful when the individual cluster servers aren’t publicly accessible.
• Can specify multiple roles (a role is a collection of servers) and limit takes to particular roles.

invoke lets you run a particular command against whatever servers you want (even without a capfile)
shell lets you run a shell (better than invoke because less typing and faster bc connections are cached) this is experimental so beware, but I can see how it would be crazy useful.

Namespaces

• new in Cap 2.0.
• default tasks, task named :default can be executed as the namespace name.

Variables

• set, eg. set :deploy_to, "$HOME/rails-apps/#{application}"
• -s foo = bar (sets after recipes loaded)
• -S foo=bar (sets _before recipes loaded)
• in capfiles check if the variable exists before setting to avoid conflict with command line parameters

Transactions

• not overwhelmingly robust, but is pretty cool and definitely helps

Deployment

• love how opinionated about the need for source control they are. I agree 100% if your code needs deployment it needs source control.
• looks really easy. Like everything with rails I’ve dealt with well thought out.
• deployment tree looks like a good way to manage releases

Dependencies

dependency checking is a good idea. lets you check things about servers like whether the expected directories exist, their permissions are correct, and subversion exists. you can add your own dependencies as well. Custom dependencies let you check if arbitrary directories, gems, permissions, PATH. this is effin brilliant. still sort of experimental, only does what Jamis needed but will be growing.

script/spin tells how to start server. see slides for details. compare to process supervision tools like init, svscan, runit. You can override deploy:start

some tasks use sudo by default.

deploy:cold - first deploy. laughs at “it never works the first time.” Problems are normally that the webserver / mongrel / fcgi setup.

cap deploy will push a new version. cap deploy:rollback does exactly that. Note: deploy doesn’t run migrations by default. Jamis thinks any prod DB changes should be explicit. I agree (not that my opinion is very valuable ;) )

Deployment Strategies

• different ways of deploying apps. pretty cool. extensible so you can write custom ways of deploying apps.

Can use other types of source code control other than subversion. none of the stuff we use at work is supported. lots of other things are.