Re: [ANN] Unicorn: UNIX+localhost/LAN-only Mongrel fork

[Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>]

Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Feb 23, 2009, at 5:03 PM, Eric Wong wrote:
> >> Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> >>> Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> >>>> Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >>>>> 	Seems to work as advertised so far, cool stuff ;) One  
> >>>>> suggestion, folks
> >>>>> are pretty standardized on rack and config.ru files these days.  
> >>>>> I'd much
> >>>>> rather see unicorn look for a APP_ROOT/config.ru to load as its  
> >>>>> config
> >>>>> file rather then the eval that returns a hash style it uses now.
> >>>>
> >>>> Ezra, thanks for testing and feedback.  Good point about config.ru,
> >>>> I'll try to make that change hopefully today to make it easier to
> >>>> migrate from existing Rack apps.
> >>>
> >>> I just pushed out the following changes.
> >>>
> >>>  * revamp configuration with Configurator DSL
> >>>  * Replace unicorn binary with something rackup-like
> >>>  * GNUMakefile: revamp for parallel 1.8/1.9 runs
> >>>  * test_exec: fix for temporary files not being cleaned
> >>>  * Fix+test reexec error handling on bad inputs
> >>
> >> <snip>
> >>
> >>> Basically the latest push includes config.ru compatibility and new  
> >>> test
> >>> cases in test/exec/test_exec.rb for binary reexecution, listener
> >>> inheritance, and reloading config files (even bad ones).
> >>>
> >>> This new config stuff is completely untested for any real apps and  
> >>> I'll
> >>> need to update the examples soonish.  But the new test cases pass in
> >>> both 1.9.1 and 1.8.7, which is a good sign.
> >>
> >> Help...
> >>
> >> I'm basically a very confused person and I'm having trouble deciding  
> >> on
> >> how/if config.ru should deal with the config file for Unicorn-specific
> >> settings.  Or if the Unicorn-specific config file should be allowed to
> >> specify/override config.ru...
> >>
> >> Any ideas would be greatly appreciated, thanks!
> >
> > Eric-
> >
> > 	I'd say just make a small dsl or just  configuration object for unicorn 
> > options and let people use the dsl/object in their config.ru files.  
> > Since config.ru is just ruby you can put any ruby code in there. Have 
> > folks put their unicron config code right at the top of config.ru. Will 
> > that work?
> 
> The new Unicorn::Configurator object is pretty much that DSL.
> 
> The main issue of handling config reloading (which should be "lighter"
> than reexecuting the binary).  Should/could that re-eval() the
> Rack::Builder bits?  How would I avoid that re-eval (without
> dirtying the config up)[1].
> 
> Or should I handle reexecution as the only way to make config changes?
> (I've strongly considered this, it's a very big hammer :)
> 
> [1] - I don't feel completly comfortable with Unicorn-specific stuff in
> config.ru, in case it makes it harder for people to try out and compare
> their app on Mongrel/Thin/Ebb/Passenger/Glassfish/whatever...  But I
> suppose conditionals that check for defined?(Unicorn) can be enough...

OK, here's some thoughts leading up to what I'm probably going
to do...

 1. APP_ROOT/config.ru is in a pretty standardized location, good.

 2. Most config.ru files out there (probably) don't contain
    environment-specific logic.  That is, developers on their
    desktop/laptops and the production app in datacenters can
    share the same config.ru without much difficulty.

    Can somebody please confirm this assumption?

 3. Unicorn-specific config options should only be needed for
    server deployments.  Things for the typical developer
    on their workstation should "just work", like running
    "script/server" and "mongrel_rails" in RAILS_ROOT does
    for old Rails apps.


This leads me to keeping the Unicorn config file separate for production
environments.  My personal experience (with old Rails apps) is that
there are multiple "production"-like environments (staging, QA,
different datacenters)...

I'd imagine some apps I support will end up with config file
layouts looking like this:

APP_ROOT/config/unicorn/prod_lax.rb
APP_ROOT/config/unicorn/prod_dfw.rb
APP_ROOT/config/unicorn/prod_nyc.rb
APP_ROOT/config/unicorn/prod_chi.rb
APP_ROOT/config/unicorn/qa.rb
APP_ROOT/config/unicorn/staging.rb
APP_ROOT/config/unicorn/demo.rb
APP_ROOT/config.ru

Thus to deploy to our Los Angeles datacenter, the script
would just run:

  unicorn -c APP_ROOT/config/unicorn/prod_lax.rb

If there's an APP_ROOT/config_prod.ru needed, then
the APP_ROOT/config/prod_*.rb files would each
be able to specify APP_ROOT/config_prod.ru instead
of APP_ROOT/config.ru.

That is, the Unicorn config file can specify an alternate
config.ru, but config.ru cannot specify a different
Unicorn config file.

Am I making sense? (it's been a long week for me so far...)

-- 
Eric Wong (no, I don't have YHBT.net running in 4 locations, yet :)