running passenger and nginx on different hosts

[greg]

I have an existing Nginx front-end in EC2. I would like to start
multiple Passenger servers on back end hosts. These Passengers would
be "naked", without a web server on the same host.

1) Can you point out the locations where Passenger checks for an
installed Nginx?

2) Can the front-end Nginx control the starting and stopping of
individual Passengers if they are on distant machines? If not, can you
suggest a starting point in the Passenger code to add support for
remote restarts?

Many thanks,

Greg

[Cody Caughlan]

Passenger is really coupled with a local web server. If you want a naked app server than Passenger might not be the best solution for.

You might want to look into Unicorn/Thin/Mongrel as your app server, which you reverse proxy to via nginx

Although in my experience, nginx is nor the best at proxying. For that I recommend haproxy, so your architecture would be

Nginx <-> haproxy <-> unicorn/thin, etc.

More moving parts for sure.

> --
> You received this message because you are subscribed to the Google Groups "Phusion Passenger Discussions" group.
> To post to this group, send email to phusion-...@googlegroups.com.
> To unsubscribe from this group, send email to phusion-passen...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/phusion-passenger?hl=en.
>

[Greg Holmberg]

On Aug 25, 2011, at 9:18 PM, Cody Caughlan <too...@gmail.com> wrote:

> Passenger is really coupled with a local web server. ...

The monitorized deploy in Passenger is a nice feature. Our developers would be reluctant to give it up.

I will look into Unicorn. Thanks for the insight.

>
> ... nginx is nor the best at proxying. For that I recommend haproxy ...
>

Interesting! I have not had any serious problems with nginx, but I have seen haproxy mask some very hard-to-debug problems. Back to the drawing board.

Thanks again for your thoughtful reply,

Greg

[gonzoprosperity]

Nginx is super fantastic, dont get me wrong. But its *native* lack of
reverse proxying flexibility is where it falls down. Flexibility such
as weighted proxying or alternate algorithms like least-connection.

Granted - those are provided in community provided modules, such as:

EY Balancer: https://github.com/ry/nginx-ey-balancer

Sticky: http://code.google.com/p/nginx-sticky-module/

Upstream Fair: http://wiki.nginx.org/HttpUpstreamFairModule

All of these are available out-of-the-box in haproxy.

If you need one of those modules then you will have to compile nginx
yourself.

If you deploy Passenger via Puppet/Chef than your recipe has now just
gotten more complicated as you cannot rely on installing nginx and
passenger via your OS Package Manager (aptitude, for instance), and
you need to provide a patched nginx source tree for your Passenger
compilation, like:

/var/lib/gems/1.9.1/gems/passenger-3.0.8/bin/passenger-install-nginx-
module --auto --prefix=/usr --nginx-source-dir=/tmp/nginx-1.0.4 --
extra-configure-flags="--conf-path=/etc/nginx/nginx.conf --http-log-
path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/
error.log --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/
var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --
http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --with-md5-asm --with-
md5=/usr/include --with-sha1-asm --with-sha1=/usr/include --without-
http_fastcgi_module --with-http_stub_status_module --with-
http_ssl_module"

Where "/tmp/nginx-1.0.4" contains a patched nginx source tree with any
community modules you need.

Just something to keep in mind.


On Aug 26, 8:29 am, Greg Holmberg <gregholmb...@gmail.com> wrote:

[Greg]

On Fri, Aug 26, 2011 at 10:40 AM, gonzoprosperity <too...@gmail.com> wrote:

Nginx is super fantastic, dont get me wrong. But its *native* lack of

reverse proxying flexibility is where it falls down. ... 

Yes, if you must use only the basic version, then you will be in trouble if you try any kind of serious application load balancing.

Since we test everything together -- web server, addons, my glue code -- in a fairly rigorous way, I don't mind building from source if a package provides important functionality.

 

If you deploy Passenger via Puppet/Chef than your recipe has now just

gotten more complicated ...

Ah. That is where we differ. Here we don't package or deploy Passenger with our code. The application lives in a separate repository, away from the infrastructure code that runs it. I build and then version the platform itself, and then we test the code against a specified platform.

If I run into a problem with a new configuration (like now), I can usually find good help upstream.

Naturally, I am trying to keep the number of packages in the platform build down to the bare minimum. :)

This morning, that minimalism means swapping in Unicorn to replace nginx->Passenger. Thanks again for all your help and insight.

Best regards,

Greg