Comment déployer Node.js dans le cloud pour une haute disponibilité en utilisant plusieurs noyaux, proxy inverse et SSL

Question

J'ai posté ceci à ServerFault, mais l'Node.js la communauté semble minuscule, donc je suis en espérant que cela apporte plus de visibilité.

J'ai un Node.js (0.4.9) application et fais des recherches sur la meilleure façon de déployer et à maintenir. Je veux l'exécuter dans le cloud (EC2 ou RackSpace) et à haute disponibilité. L'application devrait fonctionner sur HTTPS. Je vais vous soucier de l'Est/Ouest/UE plein de basculement plus tard.

J'ai fait beaucoup de lecture sur keep-alive (Upstart, pour Toujours), multi-core services publics (Fugue, multi-nœud de Cluster), et proxy/équilibreurs de charge (nœud de-http-proxy nginx, Varnish, et de la Livre). Cependant, je ne suis pas sûr de savoir comment combiner les différents services disponibles pour moi.

J'ai cette configuration à l'esprit et à la nécessité d'aplanir certaines des questions et obtenir des commentaires.

1. Cluster est la plus activement développé et apparemment populaires multi-core utilitaire pour Node.js donc de l'utiliser que pour courir 1 nœud "cluster" par application serveur sur le non-port privilégié (disons 3000). Q1: Doit Jamais être utilisé pour garder le cluster en vie ou bien est-ce un pléonasme?
2. Utilisation 1 nginx par application serveur qui tourne sur le port 80, il suffit de proxy inverse de nœud sur le port 3000. Q2: Serait - nœud-http-proxy - être plus adapté pour cette tâche, même si elle n'a pas gzip ou serveur de fichiers statiques rapidement?
3. Avoir minimum 2x serveurs comme décrit ci-dessus, avec un serveur indépendant agissant comme un équilibreur de charge à travers ces boîtes. L'utilisation de la Livre à l'écoute 443 pour mettre fin à HTTPS et passer de HTTP à Vernis qui serait round robin équilibrer la charge entre les IPs des serveurs ci-dessus. Q3: Doit nginx être utilisé pour faire les deux à la place? Q4: Doit AWS ou RackSpace équilibrage de la charge de la place, de considérer (ce dernier n'est pas arrêter HTTPS)

Questions Générales:

1. Voyez-vous un besoin de (2) ci-dessus?
2. Où est le meilleur endroit pour mettre fin à HTTPS?
3. Si les WebSockets sont nécessaires à l'avenir, ce qui nginx substitutions feriez-vous?

J'aimerais vraiment entendre la façon dont les gens sont à la configuration actuelle des environnements de production et de la combinaison des outils qu'ils préfèrent. Très apprécié.

Answer 1

Cela fait plusieurs mois depuis que j'ai posé cette question, et pas beaucoup de réponse flux. Les deux Samyak Bhuta et nponeccop avait de bonnes suggestions, mais je voulais discuter les réponses que j'ai trouvé à mes questions.

Voici ce que j'ai réglé à ce point pour un système de production, mais des améliorations sont toujours effectuées. J'espère que cela aide quelqu'un dans un scénario similaire.

1. L'utilisation de Cluster à reproduire le plus grand nombre de processus enfant que vous le désir de traiter les demandes entrantes sur multi-core virtuel ou physique des machines. Cela se lie à un seul port et facilite l'entretien. Ma règle d'or est de n - 1 groupe de travailleurs. Vous n'avez pas besoin de Toujours sur cette question, comme Cluster respawns processus de travail qui meurent. Pour avoir la résilience, même sur le Cluster de niveau parent, assurez-vous d'utiliser un Arriviste script (ou l'équivalent) pour daemonize l'Node.js application et utilisation Monit (ou équivalent) pour regarder le PID du Cluster parent et respawn si elle meurt. Vous pouvez essayer d'utiliser le temps de réapparition de la fonctionnalité de Retrait, mais je préfère avoir Monit de regarder les choses, alors plutôt que de partager les responsabilités, je trouve que c'est mieux de laisser Monit gérer le respawn.

2. Utilisation 1 nginx par application serveur qui tourne sur le port 80, il suffit de proxy inverse pour votre Cluster sur n'importe quel port vous lié à un (1). nœud-http-proxy peut être utilisé, mais nginx est plus mature, plus plein de fonctionnalités, et plus rapide à servir les fichiers statiques. Exécuter nginx maigre (ne vous connectez pas, ne pas gzip de petits fichiers) afin de réduire la surcharge.

3. Avoir minimum 2x serveurs comme décrit ci-dessus dans un minimum de 2 zones de disponibilité, et si dans AWS, utiliser un ELB qui se termine HTTPS/SSL sur le port 443 et communique sur le port HTTP 80 à l'node.js application des serveurs. ELBs sont simples et, si vous le désirez, de le rendre un peu plus facile pour auto-échelle. Vous pouvez exécuter plusieurs nginx soit le partage d'une adresse IP ou round-robin équilibré eux-mêmes par votre fournisseur de DNS, mais j'ai trouvé cela exagéré pour l'instant. À ce point, il fallait retirer la nginx instance sur chaque serveur d'application.

Je n'ai pas besoin de les WebSockets donc nginx continue à être adapté et je vais revenir sur cette question lorsque les WebSockets venir dans l'image.

Commentaires sont les bienvenus.

Answer 2

Vous ne devriez pas la peine de servir les fichiers statiques rapidement. Si votre charge est petit nœud - statique des serveurs de fichiers va faire. Si votre charge est grande, il est préférable d'utiliser un CDN (Akamai, les Feux de la rampe, CoralCDN).

Au lieu de toujours vous pouvez utiliser monit.

Au lieu de nginx vous pouvez utiliser HAProxy. Il est connu pour bien travailler avec les websockets. Considèrent également l'utilisation de proxy flash prises comme ils sont une bonne solution de contournement jusqu'à ce que websocket soutien est omniprésent (voir socket.io).

HAProxy a un certain appui pour HTTPS équilibrage de la charge, mais pas la résiliation. Vous pouvez essayer d'utiliser stunnel pour HTTPS résiliation, mais je pense que c'est trop lent.

Round-robin de charge (ou d'autres statistiques) d'équilibrage fonctionne assez bien dans la pratique, il n'ya donc pas besoin de connaître d'autres serveurs de charge dans la plupart des cas.

Pensez également à utiliser ZeroMQ ou RabbitMQ pour les communications entre les nœuds.

Answer 3

C'est un excellent fil! Merci à tous ceux qui ont contribué informations utiles.

J'ai été aux prises avec les mêmes problèmes depuis quelques mois de la configuration de l'infrastructure pour le démarrage de notre entreprise.

Comme les personnes mentionnées précédemment, nous avons voulu un Nœud de l'environnement avec un support multi-core + web sockets + vhosts

Nous avons fini par créer une sorte d'hybride entre le maternelle cluster module et http-proxy et l'a appelé Drone - bien sûr, c'est open source:

https://github.com/makesites/drone

Nous avons également dégagé comme un AMI avec Monit et Nginx

https://aws.amazon.com/amis/drone-server

J'ai trouvé ce thread recherche comment ajouter la prise en charge SSL pour Drone - tnx pour recommander ELB, mais je ne voudrais pas compter sur une solution propriétaire pour quelque chose de si important.

Au lieu de cela, j'ai étendu le proxy par défaut pour gérer toutes les demandes SSL. La configuration est minimale alors que les demandes SSL sont convertis à la plaine de http - mais je suppose que c'est préférable lorsque vous êtes trafic entre les ports...

N'hésitez pas à regarder dans le et laissez-moi savoir si cela correspond à vos besoins. Tous les commentaires bienvenus.

Answer 4

J'ai vu l'équilibreur de charge AWS équilibrer la charge et la terminaison + proxy-nœud-proxy pour le proxy inverse, si vous souhaitez exécuter plusieurs services par boîte + cluster.js pour la prise en charge mulicore et le basculement au niveau des processus.

forever.js sur cluster.js pourrait être une bonne option en cas de basculement, mais cela n’est guère nécessaire.