To me, when I read "unicorn model", I look at it as a combination of 2 things: - a master-slave relationship which allows for multiple servers to share a port/socket in order to load balance - a signaling pattern to manage the whole thing.
As others have pointed out, node's built-in cluster module already handles part 1 for you really nicely. What might not be so obvious up front is that children in a cluster can share *any* socket, not just HTTP connections. One of the trickier things unicorn does which you can do simply in node is monitor the health of the child processes. You get events for children booting and dying so you can tell if you should spawn a new worker, etc. I was heavily influenced by Unicorn's design and signal patterns when I implemented actionHero's cluster module<https://github.com/evantahler/actionHero/blob/master/bin/methods/startCluster.js>. At it's heart is is just a wrapper around `cluster` with some signal handling. The trickier part was actually building my application to be comfortable in transitional states. For example, if the TCP/TLS server was signaled to shut down, it needs to ignore all incoming new connections and send a 'goodbye' message to all existing ones. It's nothing overly complicated, but it's a little more to keep in mind when developing, assuming your goal is 0-downtime deployments. All in all, I really like Unicorn's patterns. It makes it possible to 'roll' code without taking your server down, signal that you need more or less workers, and have a single parent application to monitor and control everything. That said, I tend to always keep nginx in front of *every* application I create (regardless of language) to handle static assets, rate-limit, etc. On Thursday, November 14, 2013 8:22:16 AM UTC-8, 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? > > -- Eric > > -- > konklone.com | @konklone <https://twitter.com/konklone> > -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
