Open Sourcery

Nothing like some possitive feedback to keep you looking after your own projects, and the feedback on daemon-kit has been great so far. My TODO list is growing every day with more features that I need, and others need as well. I mostly add features to daemon-kit as I need them right away, for this reason the docs is still lacking and the support site hasn’t been setup yet.

However, I’ve setup the following channels for daemon-kit communication (and updated the README):

• daemon-kit@googlegroups.com
• #daemon-kit on Freenode

I’ll be doing my best to stay on top of these channels and garner more feedback from the community at large.

Today’s sprint was one of the very first things I planned, support for capistrano.

When generating a daemon, use the ‘-d’ flag to specify which deployer to use. Currently only capistrano is supported, but I’ve left the door open for anyone willing to add support for Vlad the Deployer.

$ daemon_kit /path/to/project -d capistrano

This will leave you with a Capfile, which you don’t need to edit, as well as config/deploy.rb and config/deploy/*.rb. The environment specific files in config/deploy is used by the capistrano-ext gem to support multistage deployments for testing your daemons. Shared configuration details go into config/deploy.rb. You need the following gems installed to leverage the deployment options:

• capistrano
• capistrano-ext

Capistrano is historically built around Rails applications, but I lifted the capistrano ‘deploy’ recipe from capistrano-2.5.5 and customized it to fit in with the requirements of daemons. Some steps have been removed, and some added. Here is the tasks available:

$ cap -T
cap deploy                     # Deploys your project.
cap deploy:check               # Test deployment dependencies.
cap deploy:cleanup             # Clean up old releases.
cap deploy:cold                # Deploys and starts a `cold' application.
cap deploy:copy_configs        # Copies any shared configuration files from :...
cap deploy:get_current_version # Get the current revision of the deployed code
cap deploy:pending             # Displays the commits since your last deploy.
cap deploy:pending:diff        # Displays the `diff' since your last deploy.
cap deploy:restart             # Restarts your application.
cap deploy:rollback            # Rolls back to a previous version and restarts.
cap deploy:rollback:code       # Rolls back to the previously deployed version.
cap deploy:setup               # Prepares one or more servers for deployment.
cap deploy:start               # Start the daemon processes.
cap deploy:stop                # Stop the daemon processes.
cap deploy:symlink             # Updates the symlink to the most recently dep...
cap deploy:update              # Copies your project and updates the symlink.
cap deploy:update_code         # Copies your project to the remote servers.
cap deploy:upload              # Copy files to the currently deployed version.
cap invoke                     # Invoke a single command on the remote servers.
cap multistage:prepare         # Stub out the staging config files.
cap production                 # Set the target stage to `production'.
cap shell                      # Begin an interactive Capistrano session.
cap staging                    # Set the target stage to `staging'.

Very close to the original recipes. I’ve still got to clean this up even further, and add some documentation on how to leverage capistrano for daemons, but for the time being this works very well. The recipe can be found in lib/daemon_kit/deployment/capistrano.rb if you have the urge to review it.

Heading towards 0.2, here are the main highlights:

• god & monit config file generation
• Improved rdoc’s and supplementary documentation files
• Finishing off some issues with error handlers
• Better logging

Strangely enough this started as a request from Tyler Bird after reviewing my Capistrano presentation. He was interested in learning how I use Capistrano to update external site dependencies, like a local cached copy of the Google Analytics JavaScript files.

Originally all I did was have this task in my Capfile, and hooked it in after the “deploy:symlink” task:

desc "Update local urchin.js file"
task :update_urchin, :role => :web do
  run "wget -O #{current_path}/public/urchin.js http://www.google-analytics.com/urchin.js"
end

I then simply changed the configurations of the Google Analytics plugin to point to local urchin.js file.

Wow, thats simple enough, but what’s the catch?

Two things bothered me, support for the newer ga.js file, and not having access to Rails’ timestamping of assets for far future caching.

I pointed out to Tyler that I’m revisiting a lot of things we do with Capistrano and will post them here as I go along. The Analytics issue was one that bothered me constantly, so I set out to correct it.

I made my own fork of the Google Analytics plugin over at GitHub, and added support for having local copies of both the legacy and new Analytics JavaScript files, complete with Rails timestamping in the mix. I also added a rake task to help out with keeping the files up to date.

So the capistrano task I mentioned earlier would be changed to look like this now:

desc "Update local Analytics cached files"
task :update_analytics, :role => :web do
  run "cd #{current_path} && rake google_analytics:update RAILS_ENV=#{rails_env}"
end

Now you can neatly update your cached copies on each deployment.

Please visit the GitHub fork for more information on the plugin itself. I’ll set up a local project page on this blog tomorrow. The whole excercise was aimed at showing how to use Capistrano for updating external dependencies, although I have to admit it got a little lost in the noise as I carried on.

Yip, its yet another Capistrano presentation… Grab it here.

I had the fortunate pleasure of guest lecturing at the Tshwane University of Technology a couple of weeks ago on Capistrano. The class was a group of final year students that are just learning Rails. The lecturer had already covered Capistrano with the students to some degree and called me in to get them excited and show them how it works in the wild.

The presentation itself doesn’t really do the session justice, it was driven more by the Q&A session afterwards.

I really enjoyed this session in particular since the students really interacted well with me and came up with some good questions and counter-arguments. I think one of the successes of the lecture was staying as far away from Rails as possible, and just focus on the dynamics of Capistrano and what an awesome tool it really is.

I’d also like to thank Jamis for this awesome tool, and all the members on the Capistrano Google Group who tirelessly help other people out with their deployment woes. Several members of the group also reviewed the presentation before my class, giving valuable feedback that I could convey to the students as well.

Capistrano Presentation @ TUT (20080529)

The basic “cap deploy:cleanup” does its job well, but can leave traces behind.

I recently picked up that one of my servers in a Rails cluster had plenty more release directories than its peers, and they were very old. I was baffled, how does this happen when I run “cap deploy:cleanup” religiously after a release has stabilized… I decided to figure out why, and how to dodge it. Who knows how many other release directories are scattered around the network.

It seems that cap gets the directory contents of the “releases” directory from the first server in its internal list. It then uses that directory content to remove stale releases from all servers. This is a sane approach, but things do go wrong and releases will build up over time.

Running the task once for every host seems the quick solution without messing with cap itself.

$ cap deploy:cleanup HOSTS=10.0.0.1

This gives each individual host a fresh start. From here, lather, rinse, repeat.

Later