I'm looking for some feedback on deploying Node.js apps in Google Cloud Compute.

We're currently using Google's HTTP Load Balancer and having it funnel traffic directly to our pool of Node.js boxes.

My question specifically, is how are others doing this? Are you letting traffic from the GCE's HTTP Load Balancer hit your Node.js app directly, OR are you sticking another reverse proxy inside your private network like HAProxy or NGINX to pass traffic to Node.js?

Its seems a bit redundant to me having another reverse proxy but I'm curious if there are any security considerations etc. I'm overlooking by exposing Node to the GCE HTTP LB.



If you follow the instructions mentioned in this Help Center article, the traffic is being forwarded on the backend using a proxy after hitting the LB IP address. So the public IP address for your application will be the forwarding rule IP.

| improve this answer | |

I've recently built a similar deployment in Rackspace and I opted for running several node.js instances on each VM (equal to number of CPUs) and balance load between them with NGINX. I was considering using HAProxy but I'm more familiar with NGINX but they both would work equally well. Then I used Load Balancer provide by Rackspace to balance load between virtual machines. I've chosen this approach because I do SSL termination on NGINX instance as well as compression. Another reason for this approach is that I provision instances with SaltStack and it is much easier to control NGINX nodes with it than the Rackspace's LB.

Even though NGINX/HAProxy layer seems redundant it keep system modular with clearly divided functionality. In theory, the extra layer should add some latency, but it is so miniscule that I would not worry about it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.