Como implantar o Node.js na nuvem para alta disponibilidade usando multi-core, proxy reverso e SSL

Question

Eu publiquei isso no ServerFault, mas a comunidade do Node.js parece pequena lá, então espero que isso traga mais exposição.

Eu tenho um aplicativo Node.js (0.4.9) e estou pesquisando como melhor distribuí-lo e mantê-lo. Eu quero executá-lo na nuvem (EC2 ou RackSpace) com alta disponibilidade. O aplicativo deve ser executado em HTTPS. Vou me preocupar com o failover completo do Leste / Oeste / UE mais tarde.

Eu tenho lido muito sobre keep-alive (Upstart, Forever), utilitários multi-core (Fugue, multi-node, Cluster) e balanceadores proxy / de carga (node-http-proxy, nginx, Varnish, e libra). No entanto, não sei como combinar os vários utilitários disponíveis para mim.

Eu tenho essa configuração em mente e preciso esclarecer algumas dúvidas e obter feedback.

1. O Cluster é o utilitário multi-core mais desenvolvido e aparentemente popular para o Node.js, então use isso para executar um "cluster" de nó por servidor de aplicativos em uma porta não privilegiada (por exemplo, 3000). Q1: O Forever deve ser usado para manter o cluster ativo ou é apenas redundante?
2. Use 1 nginx por servidor de aplicativos em execução na porta 80, simplesmente inverta o proxy para o nó na porta 3000. Q2: O node-http-proxy ser mais adequado para esta tarefa, mesmo que não gzip ou servidores de arquivos estáticos rapidamente?
3. Tenha no mínimo dois servidores como descrito acima, com um servidor independente atuando como um balanceador de carga nessas caixas. Use Pound ouvindo 443 para encerrar o HTTPS e passar o HTTP para o Varnish , que arredondaria o balanceamento de carga entre os IPs dos servidores acima. Q3: O nginx deve ser usado para fazer as duas coisas? Q4: o balanceador de carga AWS ou RackSpace deve ser considerado (o último não encerra o HTTPS)

Perguntas gerais:

1. Você vê a necessidade de (2) acima em tudo?
2. Qual é o melhor local para encerrar o HTTPS?
3. Se WebSockets forem necessários no futuro, quais substituições nginx você faria?
4. Como você lida com um único ponto de falha no balanceador de carga externo?

Eu realmente gostaria de saber como as pessoas estão configurando os ambientes de produção atuais e qual combinação de ferramentas eles preferem. Muito apreciado.

    

Answer 1

Seis longos anos e ninguém arriscou uma resposta. Bem, eu tenho um pouco de retrospectiva para complementar a experiência, então vou oferecer uma.

Q1. Talvez. Se você não se importar em adicionar a complexidade do cluster ao seu aplicativo e tiver o cuidado de evitar qualquer coisa que possa ocorrer no processo mestre, o cluster funciona muito bem. Caso contrário, você certamente desejará algo para controlar o processo do nó e reiniciá-lo quando o aplicativo falhar. Seu sistema operacional pode fornecer alternativas, como daemon ou systemd.

Q2. Não. Na melhor das hipóteses, em um bom dia com o vento em suas costas, o node-http-proxy é quase tão bom quanto o nginx ou o haproxy. Excluindo SSL, onde haproxy e nginx são muito melhores. Seria muito difícil construir um caso para ser mais adequado.

Q3. Sim ou haproxy. Até que você tenha a necessidade de introduzir verniz. Quando você chegar a esse ponto, você não terá que se perguntar se deve usar verniz. (Ou você vai usar um CDN).

Q4. Sua chamada. Haproxy é a minha ferramenta padrão de escolha para terminação e proxy TLS. Eu não me odeio o suficiente para colocar algo tão crítico como um balanceador de carga no servidor de outra pessoa, onde não posso executar o tcpdump ou outras ferramentas de solução de problemas.

1. Sim. Se você conhece bem o nginx, use-o para manipular a terminação HTTPS e fazer proxy das solicitações para os servidores de aplicativos. Se você já não gosta muito do nginx, considere haproxy . Com um nome como haproxy, você esperaria que fosse realmente bom em HA e proxy e não desapontaria.

2. haproxy / nginx. Sempre. Melhor gerenciamento de certificados, listando em cipherli.st , etc. Há também um impacto menor no seu aplicativo para atualizar o proxy quando as vulnerabilidades do openssl forem liberadas.

3. haproxy. (O nginx suporta websockets de proxy agora, então esta questão já passou da data de expiração).

4. Vários sites e BGP. A introdução de ferramentas como keepalived ou outros mecanismos de failover TCP peer-to-peer para a sua pilha provavelmente será a causa de uma interrupção para evitar uma. O uso de tais ferramentas é tipicamente raro, então o ser humano com conhecimento do local está fora de prática quando surge a necessidade. Mantenha a pilha mais simples e dependa das habilidades da sua equipe de rede. Eles são bem treinados no encaminhamento de problemas.