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
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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn >
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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >> > > _______________________________________________ > mongrel-unicorn mailing list > mongrel-unicorn at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicornDylan Stamat ELC Technologies (TM) 1921 State Street Santa Barbara, CA 93101 dstamat at 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
On Wed, Nov 18, 2009 at 4:35 AM, John-Paul Bader <hukl at 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 at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >> > > _______________________________________________ > mongrel-unicorn mailing list > mongrel-unicorn at 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
Thank you all very much for you time. I will have a look at the configuration examples today. regards Huet Bartels> Dear all, > > I know members of the list use nginx to forward to unicorn. Wouldsome> be so kind as to share a code snippet on how they have configurednginx> to use unicorn. > > thanks in advance > > Huet Bartels > > >
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 at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn >>> >> >> _______________________________________________ >> mongrel-unicorn mailing list >> mongrel-unicorn at rubyforge.org >> http://rubyforge.org/mailman/listinfo/mongrel-unicorn > > Dylan Stamat > > ELC Technologies (TM) > 1921 State Street > Santa Barbara, CA 93101 > dstamat at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicorn >
huet bartels <hbartels at 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
On Nov 22, 2009, at 2:53 PM, Eric Wong wrote:> huet bartels <hbartels at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-unicornHey 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 at 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
Dylan Stamat <dstamat at 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