About Unicorn Rack handler

About Unicorn Rack handler

[Lin Jen-Shin (aka godfat 真常)]

Hi,

A couple days ago, I was trying to run Unicorn for Ramaze,
and found that `Unicorn.run' didn't share the same interface
with other Rack handlers, i.e. `options[:Host]' and `options[:Port]'

Because of this, I can't just use:

  Rack::Handler.register('unicorn', 'Unicorn')

And invoke this:

  Ramaze.start(:adapter => 'unicorn', :port => 8080)

To address this, I added a simple wrapper in
Innate (which is the core of Ramaze):

http://github.com/godfat/innate/commit/9d607f41fdeeca366a9a07155e685ae2605c7025

In short, simply hack the config to:

  {:listeners => ["#{config[:Host]}:#{config[:Port]}"]}

Should we adapt to this interface in Unicorn::Configurator,
or provide an additional Rack handle to adapt to this,
or maintain this Rack handler in Rack repository, just like the others?
http://github.com/rack/rack/tree/master/lib/rack/handler

I'm looking forward to your opinion, many thanks!
cheers,

Re: About Unicorn Rack handler

[Eric Wong]

"Lin Jen-Shin (aka godfat 真常)" <godfat@godfat.org> wrote:
> Hi,
> 
> A couple days ago, I was trying to run Unicorn for Ramaze,
> and found that `Unicorn.run' didn't share the same interface
> with other Rack handlers, i.e. `options[:Host]' and `options[:Port]'
> 
> Because of this, I can't just use:
> 
>   Rack::Handler.register('unicorn', 'Unicorn')
> 
> And invoke this:
> 
>   Ramaze.start(:adapter => 'unicorn', :port => 8080)
> 
> To address this, I added a simple wrapper in
> Innate (which is the core of Ramaze):
> 
> http://github.com/godfat/innate/commit/9d607f41fdeeca366a9a07155e685ae2605c7025
> 
> In short, simply hack the config to:
> 
>   {:listeners => ["#{config[:Host]}:#{config[:Port]}"]}
> 
> Should we adapt to this interface in Unicorn::Configurator,
> or provide an additional Rack handle to adapt to this,
> or maintain this Rack handler in Rack repository, just like the others?
> http://github.com/rack/rack/tree/master/lib/rack/handler

I think making Unicorn.run add to :listeners if :Host or :Port are set
will work.  I'm not sure if launching Unicorn directly from `rackup' can
ever work right without being too intrusive to the other servers, so
having a Unicorn Rack handler in distributed with Rack would't make
sense.   Unicorn needs to capture ARGV (before option parsing) and parse
its own config file, neither of which is doable out-of-the-box with
rackup.

Does something like this work? (not tested).

diff --git a/lib/unicorn.rb b/lib/unicorn.rb
index 0f2b597..d4a00e0 100644
--- a/lib/unicorn.rb
+++ b/lib/unicorn.rb
@@ -17,6 +17,14 @@ module Unicorn
 
   class << self
     def run(app, options = {})
+      # compatibility with other interfaces (Ramaze)
+      host = options.delete(:Host)
+      port = options.delete(:Port)
+      if host || port
+        port ||= Const::DEFAULT_PORT
+        host ||= Const::DEFAULT_HOST
+        (options[:listeners] ||= []) << "#{host}:#{port}"
+      end
       HttpServer.new(app, options).start.join
     end
   end

On the other hand, does Innate make it possible to do transparent
upgrades (since rackup does not)?  I'll look into it a bit more later...

-- 
Eric Wong
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Re: About Unicorn Rack handler

[Lin Jen-Shin (aka godfat 真常)]

On Thu, Nov 5, 2009 at 1:07 AM, Eric Wong <normalperson@yhbt.net> wrote:
> I think making Unicorn.run add to :listeners if :Host or :Port are set
> will work.  I'm not sure if launching Unicorn directly from `rackup' can
> ever work right without being too intrusive to the other servers, so
> having a Unicorn Rack handler in distributed with Rack would't make
> sense.   Unicorn needs to capture ARGV (before option parsing) and parse
> its own config file, neither of which is doable out-of-the-box with
> rackup.

I see. On the other hand, it would be great if `rackup' could work with
Unicorn directly. Perhaps something like:

  rackup -r config/unicorn.rb -s unicorn -p 12345 config.ru

This would require unicorn config to change to something like:

  Unicorn::Configurator.instance.instance_eval{
    # original config content
  }

Then `Unicorn.run' should check if Configurator
singleton has been configured, and use it instead.

I would want this because I have a rackup cluster script.
If this would work, then I don't have to change the existing
script to adapt to Unicorn with a -c option, along with
changing `rackup' to `unicorn'.

Here's the script:
http://github.com/godfat/app-deploy/blob/master/lib/app-deploy/rack_cluster.rb

Here's an example config for `rack_cluster':
http://github.com/godfat/app-deploy/blob/master/example/rack_cluster.yaml

I know I won't need rack "cluster" once I switch to Unicorn.
Perhaps what I should do is just drop rack cluster support,
then many things could be simplified.

> Does something like this work? (not tested).
>
> diff --git a/lib/unicorn.rb b/lib/unicorn.rb
> index 0f2b597..d4a00e0 100644
> --- a/lib/unicorn.rb
> +++ b/lib/unicorn.rb
> @@ -17,6 +17,14 @@ module Unicorn
>
>   class << self
>     def run(app, options = {})
> +      # compatibility with other interfaces (Ramaze)
> +      host = options.delete(:Host)
> +      port = options.delete(:Port)
> +      if host || port
> +        port ||= Const::DEFAULT_PORT
> +        host ||= Const::DEFAULT_HOST
> +        (options[:listeners] ||= []) << "#{host}:#{port}"
> +      end
>       HttpServer.new(app, options).start.join
>     end
>   end

Yes, work fine at first try. Many thanks for your work!
The working `start.rb' for Ramaze is:

  require 'unicorn'
  Rack::Handler.register('unicorn', 'Unicorn')
  Ramaze.start(:adapter => 'unicorn', :port => 7000)

> On the other hand, does Innate make it possible to do transparent
> upgrades (since rackup does not)?  I'll look into it a bit more later...

I am not sure what do you mean transparent here,
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Re: About Unicorn Rack handler

[Lin Jen-Shin (aka godfat 真常)]

2009/11/5 Lin Jen-Shin (aka godfat 真常) <godfat@godfat.org>:
> On Thu, Nov 5, 2009 at 1:07 AM, Eric Wong <normalperson@yhbt.net> wrote:
>> On the other hand, does Innate make it possible to do transparent
>> upgrades (since rackup does not)?  I'll look into it a bit more later...
>
> I am not sure what do you mean transparent here,

Oops, accidentally sent incomplete mail, sorry.

I am not sure what do you mean transparent here,
but I would guess Innate work better than rackup. :p

cheers,
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Re: About Unicorn Rack handler

[Eric Wong]

"Lin Jen-Shin (aka godfat 真常)" <godfat@godfat.org> wrote:
> On Thu, Nov 5, 2009 at 1:07 AM, Eric Wong <normalperson@yhbt.net> wrote:
> > I think making Unicorn.run add to :listeners if :Host or :Port are set
> > will work.  I'm not sure if launching Unicorn directly from `rackup' can
> > ever work right without being too intrusive to the other servers, so
> > having a Unicorn Rack handler in distributed with Rack would't make
> > sense.   Unicorn needs to capture ARGV (before option parsing) and parse
> > its own config file, neither of which is doable out-of-the-box with
> > rackup.
> 
> I see. On the other hand, it would be great if `rackup' could work with
> Unicorn directly. Perhaps something like:
> 
>   rackup -r config/unicorn.rb -s unicorn -p 12345 config.ru

As I explained in the other email, this unfortunately can't ever give
you all the features that Unicorn has.

I've made an effort to keep everything else as compatible and the
migration paths as easy as possible.

> I would want this because I have a rackup cluster script.
> If this would work, then I don't have to change the existing
> script to adapt to Unicorn with a -c option, along with
> changing `rackup' to `unicorn'.
> 
> Here's the script:
> http://github.com/godfat/app-deploy/blob/master/lib/app-deploy/rack_cluster.rb
> 
> Here's an example config for `rack_cluster':
> http://github.com/godfat/app-deploy/blob/master/example/rack_cluster.yaml
> 
> I know I won't need rack "cluster" once I switch to Unicorn.
> Perhaps what I should do is just drop rack cluster support,
> then many things could be simplified.

Yeah, it's probably simpler to just use "unicorn" than to wrap it.

It's really hard use the process management functionality in a libified
form since we rely on things like $0 and ARGV.  On the other hand, since
Unicorn is designed to work with nginx, you can use the same
scripts/signals for managing both.

> > Does something like this work? (not tested).
> >
> > diff --git a/lib/unicorn.rb b/lib/unicorn.rb
> > index 0f2b597..d4a00e0 100644
> > --- a/lib/unicorn.rb
> > +++ b/lib/unicorn.rb
> > @@ -17,6 +17,14 @@ module Unicorn
> >
> >   class << self
> >     def run(app, options = {})
> > +      # compatibility with other interfaces (Ramaze)
> > +      host = options.delete(:Host)
> > +      port = options.delete(:Port)
> > +      if host || port
> > +        port ||= Const::DEFAULT_PORT
> > +        host ||= Const::DEFAULT_HOST
> > +        (options[:listeners] ||= []) << "#{host}:#{port}"
> > +      end
> >       HttpServer.new(app, options).start.join
> >     end
> >   end
> 
> Yes, work fine at first try. Many thanks for your work!
> The working `start.rb' for Ramaze is:
> 
>   require 'unicorn'
>   Rack::Handler.register('unicorn', 'Unicorn')
>   Ramaze.start(:adapter => 'unicorn', :port => 7000)
> 
> > On the other hand, does Innate make it possible to do transparent
> > upgrades (since rackup does not)?  I'll look into it a bit more later...
> 
> I am not sure what do you mean transparent here,

Can you try and see if the USR2 handling of Unicorn allows
a transparent upgrade here?  If it doesn't then I don't think
it's worth supporting an interface that's crippled compared
to using the plain `unicorn' command.

-- 
Eric Wong
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Re: About Unicorn Rack handler

[Eric Wong]

"Lin Jen-Shin (aka godfat 真常)" <godfat@godfat.org> wrote:
> 2009/11/5 Lin Jen-Shin (aka godfat 真常) <godfat@godfat.org>:
> > On Thu, Nov 5, 2009 at 1:07 AM, Eric Wong <normalperson@yhbt.net> wrote:
> >> On the other hand, does Innate make it possible to do transparent
> >> upgrades (since rackup does not)?  I'll look into it a bit more later...
> >
> > I am not sure what do you mean transparent here,
> 
> Oops, accidentally sent incomplete mail, sorry.
> 
> I am not sure what do you mean transparent here,
> but I would guess Innate work better than rackup. :p

Transparent, zero-downtime upgrades (USR2 + QUIT) that Unicorn
can do like nginx[1].

The issue here with rackup is that it changes ARGV with the option
parser before Unicorn can get to it.  So when Unicorn receives the USR2
signal and respawns itself, it won't be able to spawn a child with the
same command-line options as its parent.  Using the "unicorn" script
will allow it to always save its ARGV before OptionParser has a chance
to mangle it.

[1] - http://unicorn.bogomips.org/SIGNALS.html
-- 
Eric Wong
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Re: About Unicorn Rack handler

[Lin Jen-Shin (aka godfat 真常)]

2009/11/5 Eric Wong <normalperson@yhbt.net>:
> As I explained in the other email, this unfortunately can't ever give
> you all the features that Unicorn has.
>
> I've made an effort to keep everything else as compatible and the
> migration paths as easy as possible.

Many, many thanks for your effort on Unicorn.
It's awesome, in all ways. I would switch all services
at my working place to Unicorn at some point.

> Can you try and see if the USR2 handling of Unicorn allows
> a transparent upgrade here?  If it doesn't then I don't think
> it's worth supporting an interface that's crippled compared
> to using the plain `unicorn' command.

I think it does work. This is start.rb:

###
#!/usr/bin/env ruby
require File.expand_path('app', File.dirname(__FILE__))
require 'unicorn'
Rack::Handler.register('unicorn', 'Unicorn')
Ramaze.start(:adapter => 'unicorn', :port => 7000)
###

It won't work if I invoke start.rb like this:
$ ruby start.rb
(perhaps it's impossible to get the `ruby' ?)
but it does work if I invoke this way:
$ ./start.rb
(tested with different debug output in lib/unicorn.rb)

On the other hand, `ramaze' command won't work,
and I guess it's because it uses `rackup', which
you've explained why it won't.

I am wondering.. Could `rackup' be fixed for this?
For instance, use the same way as `unicorn' in `rackup'?
If so, I would be glad to try to fix that in rackup.
I would try it later in my free time.

cheers,
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Re: About Unicorn Rack handler

[Eric Wong]

"Lin Jen-Shin (aka godfat 真常)" <godfat@godfat.org> wrote:
> 2009/11/5 Eric Wong <normalperson@yhbt.net>:
> > As I explained in the other email, this unfortunately can't ever give
> > you all the features that Unicorn has.
> >
> > I've made an effort to keep everything else as compatible and the
> > migration paths as easy as possible.
> 
> Many, many thanks for your effort on Unicorn.
> It's awesome, in all ways. I would switch all services
> at my working place to Unicorn at some point.

Cool, good to know :)

> > Can you try and see if the USR2 handling of Unicorn allows
> > a transparent upgrade here?  If it doesn't then I don't think
> > it's worth supporting an interface that's crippled compared
> > to using the plain `unicorn' command.
> 
> I think it does work. This is start.rb:
> 
> ###
> #!/usr/bin/env ruby
> require File.expand_path('app', File.dirname(__FILE__))
> require 'unicorn'
> Rack::Handler.register('unicorn', 'Unicorn')
> Ramaze.start(:adapter => 'unicorn', :port => 7000)
> ###
> 
> It won't work if I invoke start.rb like this:
> $ ruby start.rb
> (perhaps it's impossible to get the `ruby' ?)
> but it does work if I invoke this way:
> $ ./start.rb
> (tested with different debug output in lib/unicorn.rb)

Yeah, running "ruby start.rb" throws off $0 unless start.rb is in $PATH.
"ruby ./start.rb" should work, too, but it's ugly.  I think there
are/were cases where "#!/usr/bin/env ruby" won't even work as a shebang,
too.

> On the other hand, `ramaze' command won't work,
> and I guess it's because it uses `rackup', which
> you've explained why it won't.
> 
> I am wondering.. Could `rackup' be fixed for this?
> For instance, use the same way as `unicorn' in `rackup'?
> If so, I would be glad to try to fix that in rackup.
> I would try it later in my free time.

It would require `rackup' to do a "require 'unicorn'" before it does any
option parsing.  That would be unnecessarily intrusive if one has
Unicorn installed but wants to test with a different server.

-- 
Eric Wong
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn