#139 ✓resolved
James

Add mechanism for automatically configuring databases, backgrounDRb, etc during Capistrano deployment

Reported by James | December 12th, 2008 @ 01:13 PM | in 1.2

database.yml, backgroundrb.yml, etc should be generated automatically based on configuration options in config/deploy.rb or config/deploy/*.rb.

This will simplify deployment and provide a standard way to store production/staging/etc environment configurations.

Possible Implementation Details

  1. Add Capistrano methods to generate the necessary configuration files
  2. Add Capistrano recipes to generate the necessary files automatically during deployment
  3. Add specific declarations for the files to deployment files, update UPGRADE readme, etc

Cheers,

James

Comments and changes to this ticket

  • Kieran P

    Kieran P December 22nd, 2008 @ 01:25 PM

    I created a command on a few hosts that basically uses alias to run a set of commands in one go:

    Mongrel hosts:

    alias upgrade_kete='script/backgroundrb stop && rake db:migrate RAILS_ENV=production && rake kete:upgrade RAILS_ENV=production && script/backgroundrb start'

    (then run mongrel_rails manually)

    Passenger hosts:

    alias upgrade_kete='script/backgroundrb stop && rake db:migrate RAILS_ENV=production && rake kete:upgrade RAILS_ENV=production && script/backgroundrb start && touch tmp/restart.txt'

    It speeds up deployment a bit, but would be nice to just run deploy locally and not even have to the server.

    Walter also mentioned clearing the tmp cache before deploying (probably to avoid archiving old caches). Some type of before deploy method would be handy here.

  • Walter McGinnis

    Walter McGinnis December 22nd, 2008 @ 03:08 PM

    • State changed from “new” to “open”

    I asked Kieran to mention his bash shell alias command mainly because it gives a good road map for what should go into some rake tasks to support deployments. Note that I say rake tasks, not cap recipes, as these tasks are more general than just deployments.

    As far as tmp:cache:clear. In a cap deployment scenario, to cut down file system space used, I usually run that task in the current directory before it is switched to the new release. I.e. the OLD current directory.

    It's not a bad idea to do it before a non-cap code update, too.

    Cheers, Walter

    P.S. - we'll also now want to handle Google Maps API key configuration files that are different for staging/production deployments.

  • Walter McGinnis

    Walter McGinnis December 27th, 2008 @ 05:51 PM

    This blog post has a task definition for restarting passenger... not a huge mystery, but nice to have some example code:

    http://advent2008.hackruby.com/p...

  • Kieran P

    Kieran P January 6th, 2009 @ 11:01 AM

    This is the current format for configuration we have at the moment. Thoughts?

    configure :database do
      environment :production do
        config :database, "site_staging_production"
        config :username, "site_staging"
        ..
      end
      environment :development do
        ..
      end
    end
    configure :backgroundrb do
      ..
    end
    
    

    Am looking for open source projects that already do this (plugins, gems, etc).

  • Walter McGinnis

    Walter McGinnis January 6th, 2009 @ 11:08 AM

    • Tag changed from capistrano, configuration, deployment, enhancement, settings, yaml to capistrano, configuration, deployment, enhancement, mod_rails, mongrel, nginx, settings, yaml

    Along with my last comment link, I would take a look at the stuff in Capistrano Bells plugin (http://github.com/nakajima/capis... for example code and stuff to pinch (give credit if you copy and modify, etc).

    I don't think I would grab the entire plugin since it is might have a good amount of non-relevant stuff for Kete, but it might be worth weighing that option.

    Note, I think it is probably worth disabling or at least modifying it so it can be turned off the problematic mongrel restart stuff that is in the Kete recipes now. This may mean that http://kete.lighthouseapp.com/pr... is no longer an issue.

    Basically aim for deployments based on mod_rails for our work.

  • Walter McGinnis

    Walter McGinnis January 6th, 2009 @ 11:43 AM

    Other passenger related links:

    http://tomcopeland.blogs.com/jun...

    The comments of this one: http://jimneath.org/2008/05/10/u...

    Unfortunately the previously link passenger recipes page hangs, even in google cache. Weird.

    Some other good background stuff:

    http://www.scottmoe.info/2008/10... # we may want something like this to handle maintenance page, but not a priority yet

  • Kieran P

    Kieran P January 6th, 2009 @ 07:40 PM

    • State changed from “open” to “to-review”
    • Assigned user changed from “James” to “Kieran P”

    I've written code for this functionality and made it into a gem on the kete account. To take a look, clone git://github.com/kete/capistrano-configuration.git , and to use, run

    sudo gem install kete-capistrano-configuration

    Is there anything left for this (aside from updating repos and editing their deployment tasks).

  • Walter McGinnis

    Walter McGinnis January 6th, 2009 @ 08:15 PM

    • State changed from “to-review” to “open”

    If you have tested this successfully, no. I've looked at the code and it seems fine.

    However, if you plan on making this a code a gem, I would rather it be placed there first and then a new gem requirement added be the code we push to master.

  • Kieran P

    Kieran P January 7th, 2009 @ 02:10 PM

    • State changed from “open” to “resolved”

    I have tested now. Updates were made to the gem (so make sure you gem update kete-capistrano-configuration). This work has now been merged to master. Resolving ticket.

  • winslet.jessica (at gmail)

    winslet.jessica (at gmail) April 8th, 2009 @ 05:56 PM

    Its main intent is to be used with Ruby on Rails applications for offloading long-running tasks. Since a Rails application blocks while serving a request it is best to move long-running tasks off into a background process that is divorced from site de jeux de casino http request/response cycle. I did as said but still I am experiencing problems with starting the BackgroundRB server: I keep on getting that error ... ruby/lib/ruby/gems/1.8/gems/activesupport-2.2.2/lib/active_support/dependencies.rb:102:in const_missing': uninitialized constant Packet::Reactor::UNIXSocket (NameError) even when using cygwin. Any ideas?

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Kete was developed by Horowhenua Library Trust and Katipo Communications Ltd. to build a digital library of Horowhenua material.

People watching this ticket

Pages