Estou procurando algum feedback sobre a implantação de aplicativos Node.js no Google Cloud Compute.
No momento, estamos usando o Balanceador de carga HTTP do Google e enviando tráfego para o pool de caixas Node.js.
Minha pergunta especificamente é como os outros estão fazendo isso? Você está permitindo que o tráfego do Balanceador de carga HTTP da GCE atinja seu aplicativo Node.js diretamente OU você está colocando outro proxy reverso dentro de sua rede privada, como HAProxy ou NGINX, para transferir tráfego para o Node.js?
Parece um pouco redundante para mim ter outro proxy reverso, mas estou curioso para saber se há alguma questão de segurança, etc. Estou ignorando a exposição do Node ao GCE HTTP LB.
Obrigado
Se você seguir as instruções mencionadas neste artigo da Central de Ajuda a>, o tráfego está sendo encaminhado no back-end usando um proxy depois de atingir o endereço IP do LB. Assim, o endereço IP público da sua aplicação será o IP da regra de encaminhamento.
Eu criei recentemente uma implantação semelhante na Rackspace e optei por executar várias instâncias de node.js em cada VM (igual ao número de CPUs) e equilibrar a carga entre elas com o NGINX. Eu estava pensando em usar o HAProxy, mas estou mais familiarizado com o NGINX, mas ambos funcionariam igualmente bem. Então usei o Load Balancer fornecido pela Rackspace para balancear a carga entre as máquinas virtuais. Eu escolhi essa abordagem porque eu faço terminação SSL na instância NGINX, bem como a compactação. Outro motivo para essa abordagem é que eu provisiono instâncias com SaltStack e é muito mais fácil controlar nós NGINX com ele do que o LB da Rackspace.
Embora a camada NGINX / HAProxy pareça redundante, ela mantém o sistema modular com funcionalidade claramente dividida. Em teoria, a camada extra deve adicionar um pouco de latência, mas é tão minúsculo que eu não me preocuparia com isso.