On Thursday, November 14, 2013 5:22:16 PM UTC+1, Eric Mill wrote: > > I'm totally fine being told that the Unicorn model is the wrong way to > think of things in Node. But what are the best practices for deploying a > Node app where I'd like to be able to scale the number of processes up and > down easily on a box? The model I'm used to is putting nginx in front, > having it proxy to a Unix socket, and then having Unicorn watch the same > Unix socket. > > I'm aware of node-http-proxy<https://github.com/nodejitsu/node-http-proxy> - > should I run one of these with forever<https://github.com/nodejitsu/forever> > -- > and then also manage my express processes with forever? How should I be > conceiving of the problem? >
With "the Unicorn model" I believe you are referring to the supervising, preforking server model, in which there is a master process that sets up the server socket, and then forks off multiple worker processes that each one listen on that server socket. The kernel then load balances requests between the worker processes. This single server socket is then attached to Nginx in the form of a reverse proxy. In a proper implementation of this model, a crashing worker process will be automatically restarted. I don't know why you were told that that model is the wrong way to think of things in Node. That is in fact a very good model for Node, and for web apps in general! This model allows you to scale the number of processes up and down (of course, assuming that the system actually implements it). First off, full disclosure: I am one of the Phusion Passenger authors. This "Unicorn model" is almost exactly what Phusion Passenger implements. It supervises all your processes. It restarts them when they crash. It allows you to scale the number of processes up and down with ease. It provides I/O security by buffering your requests and responses. How's Passenger any different compared to using 'cluster', pm2 etc and then attaching the result to an Nginx reverse proxy? Well, Passenger drastically reduces deployment complexity, and adds important production features that you can't easily get by just attaching Node to Nginx: - Using Passenger is much easier. If you do it yourself, you’ll have to write reverse proxy rules, write init scripts, etc. The result probably does not even handle corner cases properly, like race conditions, stale PID files, etc. Passenger takes care of all this for you and handles virtually all the corner cases. This reduces the number of moving parts and reduces complexity. - Passenger integrates much deeper into Nginx than a straight reverse proxy does, and as such can leverage Nginx features much better. For example, the load balancing and response buffering in Phusion Passenger is much better than the one you get with manual reverse proxying. - By using Nginx’s proxy module, it’s very hard to see what’s going on with the system right now. Are all connections ok? Are all processes ok? Phusion Passenger provides simple and powerful administration tools that can help you with that. Passenger is proven technology: it's already being used by the likes of New York Times, Pixar, AirBnB, Apple, American Express, Juniper, etc as well as over 350.000 websites <http://trends.builtwith.com/Web-Server/Phusion-Passenger>. I see that there are some misunderstandings about Passenger. It is not true that Passenger requires Nginx recompilation. The fact is: - Passenger provides a Standalone mode<http://www.modrails.com/documentation/Users%20guide%20Standalone.html>. You configure Passenger through command line options. Passenger Standalone is powered by an internal Nginx core and you get all the Passenger features. This Nginx core is fully internal and is precompiled -- you don't have to recompile your existing Nginx! Because it's powered by this Nginx core, you can choose to directly expose it to port 80, and it's immediately production ready. You can also attach it to an existing Nginx using a reverse proxy if you want to integrate it into your current infrastructure. - Passenger provides an *optional* Nginx integration mode<http://www.modrails.com/documentation/Users%20guide%20Nginx.html> which allows Passenger to start together with Nginx, and which allows you to configure Passenger inside the Nginx config file. It's all about ease and reducing complexity: instead of having to think and deal with yet another software component, you just deal with Nginx and treat it as if it can manage Node. If you want to use this mode (which you don't have to), then Passenger must be compiled into Nginx. But even then, you don't have to do that yourself! We provide Debian and Ubuntu packages, so it's just an apt-get upgrade away. - All of the above are available in the open source version. More information can be found in the Passenger Node.js tutorial: https://github.com/phusion/passenger/wiki/Phusion-Passenger%3A-Node.js-tutorial There's a strong support community around Passenger too. Almost every question can be answered by contacting the discussion forum, Stack Overflow, etc. There is also a ton of extremely detailed documentation at https://www.phusionpassenger.com/documentation_and_support. As one of its authors, I take pride in writing excellent documentation and making Passenger ease and stable. I guarantee that it's fit for production. If you're not satisfied with it, you get your money back, literally. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
