1

I have a web-site that needs to be up all the time. I also, of course, need to do new releases. Each page tends to be very long-lived, with lots of JavaScript doing AJAX calls to the server.

What I do is build a new WAR file and put it in Tomcat's webapps directory, which ends up looking like this:

20110701-7f077d 20110711-aa8db4 20110715-6f4a12 
20110701-7f077d.war 20110711-aa8db4.war 20110715-6f4a12.war  live

The war file is named after the date of its release and the first few characters of its GIT commit-id, just so I can keep track of everything. Tomcat automatically unpacks the war file into a directory of the same name. The live directly just contains a file giving the name of the "live" version.

This way, each user can continue using the version of the back-end that works with the version of the front-end that he has loaded into his browser. And obviously, version upgrade and reversion is painless.

Now, I'm switching to node.js and I want to do the same thing. I am reliably informed that node.js doesn't support independent applications in one instance. So, what to do?

The only thing I can thing of is to designate n slots (where n is some small number like 10 or 100), and each slot corresponds to a port (i.e., slot 1 is 8001 and so on), put Apache in front of several node.js instances, each representing a slot, and Apache would use mod_proxy or mod_redirect to proxy requests like '/slot01' to port 8081. "live" would point to the current slot.

This would be clumsy and error prone and require an otherwise useless Apache instance and most of all I cannot believe that node.js doesn't have a good solution to what seems like a near-universal problem.

Improve this question
3
  • Put nginx in front of node. Node is very lightweight. It doesnt allow you to hot-reload itself or swap in and out. Or put node infront of other node instances. Commented Jul 22, 2011 at 17:28
  • I'd only heard of nginx about 10 minutes ago and thought it was a typo for something else. Now that I've done some preliminary reading, nginx just seems like a slimmer version of Apache. Are you suggesting I just do my "bad" solution, but with nginx? Commented Jul 22, 2011 at 17:40
  • I'm suggesting you use a mature http engine that is as performant as node and put it in front of node. Node.js is not mature enough to expect it to just solve the problem you want it to solve Commented Jul 22, 2011 at 17:49

1 Answer 1

Reset to default
1

You can use node-http-proxy and write some code to monitor your 'deployment directory' for new versions and when such versions are found you can start the corresponding script and proxy it under the directory name (to make myself clear if you find a new directory 'version-11-today' your parent node-http-proxy script could start the new script assigning it a port passed as a parameter and then proxy to the new app under the path '/version-11-today').

A similar solution could be done with nginx only in this case you could write a script to monitory the deployment directory and generate some new nginx configuration when new apps are found.

If you are afraid you might run out of ports I believe both node.js and nginx can run on and proxy unix sockets besides inet sockets.

An advantage of the above is that each app runs in its own process protecting the other apps from crashes and enabling individual app restarts.

A third solution if you are not afraid some bug will crash your app is to have a parent script that loads all the app versions in the same process and maps them under different paths depending on the directory they were found in. You can still restart your server without downtime such as in this example http://codegremlins.com/28/Graceful-restart-without-downtime

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

That first one sounds like a genius idea to me because I could basically make as many worker apps as I want, Apache-style, assigning several workers to any version that seems busy (so I can use multiple cores). Although I'm in no real fear of running out of ports (I'm guessing 100 is the realistic upper limit on workers I'll need), I like the idea of unix sockets too. I am little worried about running the apps in the same process, because of crashes and because they'll all be in the same global JS namespace (although maybe require could take care of that for me...)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.