Skip to content
This repository has been archived by the owner on Jan 23, 2018. It is now read-only.

technomancy/harker

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

36 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Harker

github.com/technomancy/harker

Description

Harker means Rails deployments via RubyGems–because a package manager is a terrible thing to waste.

Motivation

This will mean you can use the same infrastructure you already rely on for your dependencies to manage your application itself. It means never having to keep a checkout of your app just for deployment. It also becomes very easy to see what versions are installed on a given box and run multiple instances (of the same or different versions) at the same time on different ports.

Your app code will live in your gem home, but all the files specific to a given instance will live in an instance directory.

In short: you’ve already got a package manager. Why are you handling installation of your deployed apps with a one-off tool?

Setup

Your Rails app will need to be modified a bit to become a gem and work with Harker. But don’t worry, these modifications will improve your app and make it more awesome. Running “harker /path/to/rails/app” will attempt to turn it into a gem that uses Hoe. You may need to perform a bit of tweaking in order to get it to build cleanly since every app is different–see the one in test/sample/ for an example of how this works. In particular, be sure Manifest.txt does not include any files that shouldn’t go in the gem, such as pid or log files.

You don’t have to use Hoe if you want to turn your app into a gem manually or using another library, but it helps.

Usage

Once your app is a gem, install it locally with “rake install_gem”, and you should be able to use the bin wrapper to generate a new instance:

$ your_app init ~/apps/your_app_3001

Then edit ~/apps/your_app_3001/database.yml with your database settings. At that point you should be able to bring up your database:

$ your_app migrate ~/apps/your_app_3001

Test it out by dropping into the console:

$ your_app console ~/apps/your_app_3001

Then you can start and stop your application server via Rack:

$ your_app start ~/apps/your_app_3001 --daemon --port=3001
$ your_app stop ~/apps/your_app_3001

The start command takes all the same arguments as script/server. To configure it in a way that doesn’t require command-line arguments, create a config.ru file in your instance directory, and Rails will pick that up with Rack.

If you omit the second argument, it defaults to the current directory.

For deployment, simply publish your gem to a gem server (public or private), install it on the target server, and launch it via the bin wrapper as shown above.

Extensions

Sometimes it becomes necessary to hot-patch a deployed app. Instead of editing the code inside your gem home, (which is Fraught with Peril) you can place .rb files inside your instance directory’s extensions/ directory. These will be loaded immediately after the application is required.

Requirements

  • rails (at least 2.3.2)

  • a Rails app to use it with

  • rubygems

  • hoe (technically optional)

Install

Todo

  • rake tasks for remotely installing gem

  • make it easy to “rake release” to a private gem repo

  • test, test, test. try it out with more rails apps!

License

Copyright © 2009 Phil Hagelberg.

Licensed under the same terms as Ruby.

About

Rails deployments via RubyGems. Because a package manager is a terrible thing to waste.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published