Nginx Conf

Nginx Conf

[huet bartels]

Dear all,

I know members of the list use nginx to forward to unicorn.  Would some
be so kind as to share a code snippet on how they have configured nginx
to use unicorn.

thanks in advance

Huet Bartels

Re: Nginx Conf

[John-Paul Bader]

On  a FreeBSD 7.2

varnish:80 -> nginx:8080 -> unicorn

and for ssl

nginx:443 -> varnish:80 -> nginx 8080 -> unicorn


Config: http://pastie.textmate.org/703919


Kind regards, John


On 18.11.2009, at 09:58, huet bartels wrote:

> Dear all,
> 
> I know members of the list use nginx to forward to unicorn.  Would some
> be so kind as to share a code snippet on how they have configured nginx
> to use unicorn.
> 
> thanks in advance
> 
> Huet Bartels
> 
> 
> 
> _______________________________________________
> mongrel-unicorn mailing list
> mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> 

Re: Nginx Conf

[Dylan Stamat]

Hey Huet!  On CentOS, I'm using something like this:
http://pastie.org/704551

I'd like to be using the UDS's, but our architecture requires the use of TCP at the moment.

John, how do you like having Varnish up front, and, what do you use it for?
I was thinking about throwing it up simply for serving static assets, but I read somewhere that
Nginx was definitely sufficient for doing so.


On Nov 18, 2009, at 1:35 AM, John-Paul Bader wrote:

> On  a FreeBSD 7.2
> 
> varnish:80 -> nginx:8080 -> unicorn
> 
> and for ssl
> 
> nginx:443 -> varnish:80 -> nginx 8080 -> unicorn
> 
> 
> Config: http://pastie.textmate.org/703919
> 
> 
> Kind regards, John
> 
> 
> On 18.11.2009, at 09:58, huet bartels wrote:
> 
>> Dear all,
>> 
>> I know members of the list use nginx to forward to unicorn.  Would some
>> be so kind as to share a code snippet on how they have configured nginx
>> to use unicorn.
>> 
>> thanks in advance
>> 
>> Huet Bartels
>> 
>> 
>> 
>> _______________________________________________
>> mongrel-unicorn mailing list
>> mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> 
> 
> _______________________________________________
> mongrel-unicorn mailing list
> mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Dylan Stamat

ELC Technologies (TM)
1921 State Street
Santa Barbara, CA 93101
dstamat@elctech.com

(866)863-7365 Tel
(866)893-1902 Fax

+44 (0)20 7504 1346 Tel - London Office
+44 (0)20 7504 1347 Fax - London Office

http://www.elctech.com

Re: Nginx Conf

[Matt Mongeau]

On Wed, Nov 18, 2009 at 4:35 AM, John-Paul Bader <hukl@berlin.ccc.de> wrote:
> On  a FreeBSD 7.2
>
> varnish:80 -> nginx:8080 -> unicorn
>
> and for ssl
>
> nginx:443 -> varnish:80 -> nginx 8080 -> unicorn
>
>
> Config: http://pastie.textmate.org/703919
>
>
> Kind regards, John
>
>
> On 18.11.2009, at 09:58, huet bartels wrote:
>
>> Dear all,
>>
>> I know members of the list use nginx to forward to unicorn.  Would some
>> be so kind as to share a code snippet on how they have configured nginx
>> to use unicorn.
>>
>> thanks in advance
>>
>> Huet Bartels
>>
>>
>>
>> _______________________________________________
>> mongrel-unicorn mailing list
>> mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>>
>
> _______________________________________________
> mongrel-unicorn mailing list
> mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>

server {
 47     listen 80;
 48     server_name unicorn.local;
 49     location / {
 50       proxy_pass http://unicorn;
 51     }
 52   }
 53
 54   upstream unicorn {
 55       server
unix:/Users/mattmongeau/projects/test/unicorn/tmp/sockets/unicorn.sock;
 56   }

minus the line numbers of course

Re: Nginx Conf

[John-Paul Bader]

Hey Dylan,

I like varnish a lot as it is so flexible and fast. It really is! I've used Apaches and Nginx built in caching but they simply cannot match what varnish has to offer. You have full control and what i would call deep request introspection for debugging which helped me debug issues not related to caching. 

So yeah - If you need serious caching (and who does not) than I'd recommend trying varnish

Kind regards, John

On 18.11.2009, at 19:17, Dylan Stamat wrote:

> Hey Huet!  On CentOS, I'm using something like this:
> http://pastie.org/704551
> 
> I'd like to be using the UDS's, but our architecture requires the use of TCP at the moment.
> 
> John, how do you like having Varnish up front, and, what do you use it for?
> I was thinking about throwing it up simply for serving static assets, but I read somewhere that
> Nginx was definitely sufficient for doing so.
> 
> 
> On Nov 18, 2009, at 1:35 AM, John-Paul Bader wrote:
> 
>> On  a FreeBSD 7.2
>> 
>> varnish:80 -> nginx:8080 -> unicorn
>> 
>> and for ssl
>> 
>> nginx:443 -> varnish:80 -> nginx 8080 -> unicorn
>> 
>> 
>> Config: http://pastie.textmate.org/703919
>> 
>> 
>> Kind regards, John
>> 
>> 
>> On 18.11.2009, at 09:58, huet bartels wrote:
>> 
>>> Dear all,
>>> 
>>> I know members of the list use nginx to forward to unicorn.  Would some
>>> be so kind as to share a code snippet on how they have configured nginx
>>> to use unicorn.
>>> 
>>> thanks in advance
>>> 
>>> Huet Bartels
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mongrel-unicorn mailing list
>>> mongrel-unicorn@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>>> 
>> 
>> _______________________________________________
>> mongrel-unicorn mailing list
>> mongrel-unicorn@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> 
> Dylan Stamat
> 
> ELC Technologies (TM)
> 1921 State Street
> Santa Barbara, CA 93101
> dstamat@elctech.com
> 
> (866)863-7365 Tel
> (866)893-1902 Fax
> 
> +44 (0)20 7504 1346 Tel - London Office
> +44 (0)20 7504 1347 Fax - London Office
> 
> http://www.elctech.com
> 
> _______________________________________________
> mongrel-unicorn mailing list
> mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> 

Re: Nginx Conf

[Eric Wong]

huet bartels <hbartels@i-neda.com> wrote:
> Thank you all very much for you time.  
> 
> I will have a look at the configuration  examples today.

Sorry for the late reply, I forgot about this thread (and I'm lazy
about following links).

One general thing about the nginx configs I've seen is that they're
missing the fail_timeout=0 directive in the "server" lines.

I highly recommend setting it since it's a low cost to try an upstream
for nginx, and you can avoid 502 errors in case there's a bug in your
app that causes a Unicorn worker to not send a valid HTTP response
(including hitting the app timeout).

I actually have this in the Configurator documentation[1]:

    #    # See http://wiki.nginx.org/NginxHttpUpstreamModule for more details
    #    # on nginx upstream configuration:
    #    upstream unicorn_backend {
    #      # for UNIX domain socket setups:
    #      server unix:/path/to/unicorn.sock fail_timeout=0;
    #
    #      # for TCP setups
    #      server 192.168.0.7:8080 fail_timeout=0;
    #      server 192.168.0.8:8080 fail_timeout=0;
    #      server 192.168.0.9:8080 fail_timeout=0;
    #    }

[1] - http://unicorn.bogomips.org/Unicorn/Configurator.html

We've had fail_timeout=0 deployed to several places (many non-Unicorn
servers) here and there and have experienced no negative effects
(we're pretty good about keeping our backends up :)

If anybody can recommend a better place in the Unicorn docs to put this,
that'd be great, too...  Maybe I'll drop something in the examples/
directory.

-- 
Eric Wong

Re: Nginx Conf

[Dylan Stamat]

On Nov 22, 2009, at 2:53 PM, Eric Wong wrote:

> huet bartels <hbartels@i-neda.com> wrote:
>> Thank you all very much for you time.  
>> 
>> I will have a look at the configuration  examples today.
> 
> Sorry for the late reply, I forgot about this thread (and I'm lazy
> about following links).
> 
> One general thing about the nginx configs I've seen is that they're
> missing the fail_timeout=0 directive in the "server" lines.
> 
> I highly recommend setting it since it's a low cost to try an upstream
> for nginx, and you can avoid 502 errors in case there's a bug in your
> app that causes a Unicorn worker to not send a valid HTTP response
> (including hitting the app timeout).
> 
> I actually have this in the Configurator documentation[1]:
> 
>    #    # See http://wiki.nginx.org/NginxHttpUpstreamModule for more details
>    #    # on nginx upstream configuration:
>    #    upstream unicorn_backend {
>    #      # for UNIX domain socket setups:
>    #      server unix:/path/to/unicorn.sock fail_timeout=0;
>    #
>    #      # for TCP setups
>    #      server 192.168.0.7:8080 fail_timeout=0;
>    #      server 192.168.0.8:8080 fail_timeout=0;
>    #      server 192.168.0.9:8080 fail_timeout=0;
>    #    }
> 
> [1] - http://unicorn.bogomips.org/Unicorn/Configurator.html
> 
> We've had fail_timeout=0 deployed to several places (many non-Unicorn
> servers) here and there and have experienced no negative effects
> (we're pretty good about keeping our backends up :)
> 
> If anybody can recommend a better place in the Unicorn docs to put this,
> that'd be great, too...  Maybe I'll drop something in the examples/
> directory.
> 
> -- 
> Eric Wong
> _______________________________________________
> mongrel-unicorn mailing list
> mongrel-unicorn@rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn

Hey Eric,

Yeah, an nginx.conf in examples/ would be great.
It's probably going to be the most widely used front for Unicorn/Rainbows!, so
a sample config with some explanations here and there would be awesome.
It was great setting up Unicorn and being able to just grab the init.sh out of there!

In terms of the fail_timeout, I haven't seen a nginx.conf with that entry yet!
Maybe I'm looking at configuration files on the wrong projects ;)
So, since the upstream attempts are cheap, the combination of a max_fail of 1
and fail_timeout of 0 is ideal?  If the fail_timeout was at 10, and all the
upstreams timed out, wouldn't it restart at the beginning of the round-robin, and
not block... or... would it actually not retry on any due to the inoperable state?

Thanks!
==
Dylan Stamat

ELC Technologies (TM)
1921 State Street
Santa Barbara, CA 93101
dstamat@elctech.com

(866)863-7365 Tel
(866)893-1902 Fax

+44 (0)20 7504 1346 Tel - London Office
+44 (0)20 7504 1347 Fax - London Office

http://www.elctech.com

Re: Nginx Conf

[Eric Wong]

Dylan Stamat <dstamat@elctech.com> wrote:
> On Nov 22, 2009, at 2:53 PM, Eric Wong wrote:
> > One general thing about the nginx configs I've seen is that they're
> > missing the fail_timeout=0 directive in the "server" lines.
> > 
> > I highly recommend setting it since it's a low cost to try an upstream
> > for nginx, and you can avoid 502 errors in case there's a bug in your
> > app that causes a Unicorn worker to not send a valid HTTP response
> > (including hitting the app timeout).
> 
> Hey Eric,
> 
> Yeah, an nginx.conf in examples/ would be great.
> It's probably going to be the most widely used front for
> Unicorn/Rainbows!, so a sample config with some explanations here and
> there would be awesome.  It was great setting up Unicorn and being
> able to just grab the init.sh out of there!

OK, I'll push out an nginx example in a bit, need to make sure things
are adequately explained and linked.

> In terms of the fail_timeout, I haven't seen a nginx.conf with that
> entry yet!  Maybe I'm looking at configuration files on the wrong
> projects ;) So, since the upstream attempts are cheap, the combination
> of a max_fail of 1 and fail_timeout of 0 is ideal?  If the
> fail_timeout was at 10, and all the upstreams timed out, wouldn't it
> restart at the beginning of the round-robin, and not block... or...
> would it actually not retry on any due to the inoperable state?

max_fails doesn't seem to have any effect when fail_timeout=0.  Setting
max_fails=0 means the same thing as fail_timeout=0 in nginx >=0.6.33
(it would segfault before :x)  I've just been using fail_timeout=0
since what seems like forever in nginx...

Reading ngx_http_upstream_round_robin.c again, it appears seems that
fail_timeout/max_fails is supposed to get ignored if *all* upstreams are
failing.  So if you have a single upstream it looks like you're safe
even if your Unicorn master nukes workers.  On the other hand I remember
this not being the case at some point a while back; an entire cluster
got effectively shut down because of it.  Just set fail_timeout=0
and stop worrying about it :)

-- 
Eric Wong