jump to navigation

Syncing bundle_fu assets to s3 for Cloudfront April 2, 2009

Posted by John Dewey in Amazon, CDN, Rake, Vlad.
1 comment so far

I wanted to automatically upload my bundle_fu assets to Amazon’s s3, and use their Cloudfront CDN for SnGs. I came up with the following rake task, which can be hooked into Vlad.

It’s as simple as adding the following to production.rb, and running the rake task ‘cloud:upload’.

ActionController::Base.asset_host = "cloudfront_url"

using geminstaller with vlad the deployer February 28, 2009

Posted by John Dewey in Configuration, Deployment, Example, Rake, Vlad.
1 comment so far

I really really really like vlad the deployer. I recently switched my apps over to geminstaller vs Rails’ config.gem.

This gist adds in geminstaller functionality to vlad’s update task.

Coverage Nagging October 10, 2008

Posted by John Dewey in Code, Command Line, Example, Rails, RSpec.
add a comment

I like to keep an eye on my coverage every so often. I run the following in my applications root, for occasional coverage reminders.

while : ; do rake spec:rcov ; open coverage/index.html; sleep 3600 ; done

mrocstat – Mongrel pROCess title information stats August 18, 2008

Posted by John Dewey in Command Line, Mongrel, Plugins & Gems, Ruby, WebServers.
add a comment

I wrote a little tool which reports Mongrel’s process title information when using the mongrel_proctitle plugin. There is a gem which reports similar information, however, I like bundling utility scripts as SVN externals with my applications.

You can find the script on github.

Disable mongrel mod_proxy_balancer workers via Capistrano August 15, 2008

Posted by John Dewey in Capistrano, Configuration, Deployment, Mongrel, Rails, WebServers.
add a comment

I created a Capistrano task for disabling workers inside a given balancer, from Daniel Wharton’s Deploying Rails post.

Here’s the pastie. BTW I really hate linking off to pastie for these things. Any suggestions?

The task disables the worker, and is not specific to Mongrel.

Rails Cron — Craken July 18, 2008

Posted by John Dewey in Capistrano, Code, Command Line, Configuration, Rails, Rake, Ruby.
1 comment so far

My good buddy Doug Mciness wrote a rake task to manage and install cronjobs. We have it hooked into our Capistrano deployments, which allows for uber simple cron management. I added a few modifications such as, erb’ed raketab templates, and global/system specific crontabs.

It’s up on GitHubhttp://github.com/latimes/craken/tree/master

In the process of determining if these rakefiles should be yaml instead, would probably be the “more railsy rails way” of doing it.

Giles Bowkett gets props for the groovy name, and improved SEO of this post!

Run a Capistrano task on a single server in a given role February 7, 2008

Posted by John Dewey in Capistrano, Code, Command Line, Deployment, Monkey Patch.

There are times I want to run a Capistrano task on a single server, rather than every system in the role. Adding this monkey patch to deploy.rb adds this functionality. To utilize this feature append ‘server=IP_ADDRESS’ to the Cap command. Tasks are defined to run on particular role(s), this feature will target the server inside a particular tasks role. It will not execute a task on an arbitrary server.  CJ Kihlbom filled me in and stated this can be accomplished with `cap deploy HOSTS=IP_ADDRESS`.  See his comments attached to this post.

Rake tasks :through Capistrano January 27, 2008

Posted by John Dewey in Capistrano, Example, Rake.
1 comment so far

Executing Rake tasks on host(s) through Capistrano is nothing new, and there are quite a few ways to do it. Some of the configurations out there, use a common Capistrano task to execute all Rake tasks. This works quite well, but you run into problems when scoping tasks to specific roles. The common Rake exec task is not scoped to a specific role (because it could run any task on any given role), so if you call it from a Cap task scoped to :db, it will still execute across all roles.

This was corrected by creating a Rake exec method instead of a Cap task. The method can pass any arbitrary variables and/or Rakefile to Rake.An example Capistrano task, displays it’s usage. There are a few Cap variables already set, such as rake and rails_env. Using the rakefile variable allows the execution of a specific Rakefile, which comes in handy when wanting to ignore the Rails Rakefile.

Why ignore the Rails Rakefile? In our configuration the Rakefile loads environment.rb, which sets the load_paths to our custom rubygems path – that means loading Rails! What happens when Rails is not installed, and you need a bootstrap task. The ability to pass in a Rakefile all of the sudden becomes useful.

Multi-App Mongrel Cluster Init Script January 22, 2008

Posted by John Dewey in Capistrano, Configuration, Deployment, Mongrel, Rails.

I found the mongrel_cluster.sh script, everyone uses — doesn’t quite cut it.   Especially, when a system may host several RoR applications.  Why, you ask?  The ability to easily control, and dynamically discover applications is missing.  In most cases, this doesn’t matter.  Especially when the applications are deployed with Capistrano, since it is leveraged for various tasks (including stop, starts, and restarts).

The SAs on the other hand, usually do not use Capistrano (they should!), or have a recent version of the app checked out.  Having a standard init script across all your applications and servers becomes useful.

You get bonus points for dynamically discovering new application installs.We can make certain assumptions in our environment.

We use Capistrano, apps run as the same user,  live under the same base directory, and link to common Subversion Rake tasks.  That enables the use of a generic Rake task to control all RoR applications. Furthermore, the Rake task can be wrapped by a system init script for use under /etc/init.d/.

Advanced Rails Recipes Contribution January 6, 2008

Posted by John Dewey in Capistrano, Configuration.

Giles and I had our contributions selected for the upcoming Advanced Rais Recipes Book — pretty cool!