Déploiement d'un serveur Node.js de production

Question

J'ai écrit une application Node.js, je cherche à la faire fonctionner sur une de nos machines de production. Cela semble être une demande assez courante, mais je n'arrive pas à trouver une solution adéquate. N'y a-t-il pas de solutions établies pour déployer des applications Node.js de production ?

L'application est simple (<100 LOC), mais elle doit être très efficace, fiable et pouvoir fonctionner en continu pendant des années sans redémarrage. Elle sera exécutée sur un grand site, avec des dizaines de connexions par seconde. (l'application n'est pas utilisée comme un serveur web, elle a seulement une API JSON)

Voici les approches que j'ai envisagées mais dont je ne suis toujours pas sûr :

Utilisation d'un cadre (ex. Express)

Étant donné que l'application doit être très performante et qu'elle est très simple, je veux éviter d'ajouter du superflu sous la forme d'un framework.

Démarrer le serveur avec nohup

Le principal problème ici concerne la gestion des exceptions. Nous ne voulons (évidemment) pas que le serveur entier se bloque à cause d'une exception. D'après ce que j'ai compris, le fait d'envelopper l'ensemble de l'application dans un fichier de type try {} catch {} ne sera d'aucune utilité car l'interpréteur Javascript est laissé dans un état imprévisible après une exception. Est-ce exact ?

En utilisant quelque chose comme Forever

J'ai installé Forever sur une de nos machines FreeBSD et il était très bogué. Il a fini par engendrer des processus sans fin qui ne pouvaient pas être tués par Forever. Je devais lancer kill -9 pour récupérer ma machine et je ne me sens pas très confiant pour faire tourner une application de production sur Forever. Il semble également que Upstart (outil similaire, mais plus générique) ne fonctionne pas sur FreeBSD.

Solutions hébergées (par exemple Heroku, Rackspace, Amazon EC2, etc.)

C'est probablement la solution la plus simple, mais nous avons déjà un matériel sérieux pour le reste de nos serveurs web. Pour des considérations financières, cela n'a pas de sens.

Il doit bien y avoir une solution établie à ce problème ? Est-ce que quelque chose m'échappe ?

Answer 1

• Vous devriez vraiment utiliser un framework (je recommande quelque chose comme Express puisqu'il a été testé en situation de combat) à moins que vous ne vouliez vous occuper vous-même des sessions, des cookies, des intergiciels, etc. Express est vraiment léger.
• Démarrage du serveur avec nohup : vous ne devriez pas faire cela, il suffit de le démarrer avec la commande "node" normale. De plus, Express englobe les routes dans un try-catch, de sorte que votre serveur ne se plantera pas dans une route. Cependant, si votre serveur a un problème sérieux, vous ne devez pas craindre de le redémarrer (de plus, si vous avez au moins 2 ou 3 processus, un seul mourra, il en restera donc au moins 1 ou 2 et l'utilisateur ne sentira rien).
• Pour la surveillance, je préfère personnellement quelque chose de plus au niveau du système d'exploitation, tel que Upstart y Monit .
• Solution d'hébergement : puisque vous avez déjà votre propre matériel, pas besoin d'investir de l'argent dans autre chose. Il suffit d'utiliser un équilibreur de charge (peut-être nginx ou node-http-proxy) pour faire du proxy.

Answer 2

Voir Hébergement d'applications Node .

Ce tutoriel vous explique comment configurer un serveur capable d'héberger des applications node.js pour les applications JavaScript côté serveur. À l'heure actuelle, les options d'hébergement de node.js se résument à l'exécution de processus node daemon qui communiquent avec un serveur Web. La plupart des serveurs web peuvent proxyer les connexions vers un port différent, vous pourrez donc utiliser Apache ou nginx pour ce faire.

Answer 3

Il y a trois questions ici, je pense.

Question 0 : "Dois-je utiliser un framework pour mon application node ?"

Question 1 : "Comment faire fonctionner des serveurs de nœuds sur des machines de production ?"

Question 2 : "Comment déployer des applications nodales en production".

Pour Question 1 J'aime vraiment Cluster (bien que la dernière version de Node ait intégré quelque chose comme ça, vous pouvez donc vérifier). J'ai eu de bons résultats avec quelque chose comme Monit/Upstart pour surveiller les événements au niveau du système d'exploitation et m'assurer que vos serveurs sont en bonne santé. (Il s'agissait de surveiller N clusters de serveurs Ruby Thin, mais c'est la même chose).

En fonction du trafic, vous pouvez faire tourner le cluster sur plusieurs machines, puis placer un équilibreur de charge en amont. Cela dépend de votre trafic, de la durée de traitement des requêtes / de la durée de blocage de la boucle d'événements, et du nombre de processeurs / instances de nœuds que vous lancez par machine.

Un framework vous offre une meilleure gestion des erreurs, et attrape les erreurs qui feraient sortir les applications node.js normales. Si vous le faites sans framework, assurez-vous de vous renseigner sur la gestion des erreurs dans node.js.

Pour Question 2 Je ne pense pas que la communauté node ait encore un bon standard de déploiement. Vous pourriez essayer d'utiliser l'outil Capistrano de Ruby (et voici un article de blog parlant du déploiement d'un cluster avec Capinstrano ).

L'inconvénient de Capistrano est qu'il fait des suppositions qui peuvent ne pas être vraies (par exemple, que vous déployez un projet Rails), donc vous pouvez finir par vous battre avec le framework.

La solution de déploiement que je privilégie en général est la méthode Python. Tissu qui vous donne des outils de déploiement et vous permet de faire ce que vous devez faire.

Une autre option de déploiement est le "nuage", avec des choses comme Nodester : laissez-les s'en occuper.

Answer 4

Vous obtiendrez peut-être de meilleures réponses sur ServerFault, mais il y a une description de l'expérience d'un utilisateur ici en utilisant supervisord . Vous allez avoir besoin d'utiliser une sorte d'observateur de processus pour garder la node en vie, et une autre recommandation courante semble être de faire un reverse-proxy des connexions à la node d'une manière ou d'une autre. Je voterais probablement pour nginx (de cette façon, vous pouvez avoir nginx gère la journalisation, l'authentification ou toute autre fonctionnalité HTTP de plus haut niveau dont vous avez besoin, plutôt que de les intégrer d'une manière ou d'une autre à node), mais l'article susmentionné mentionne que haproxy dans les commentaires ici et là qui peuvent être plus légers. Votre choix de reverse-proxy dépendra probablement en grande partie de la nécessité ou non de prendre en charge WebSocket.

Je ne suis pas sûr qu'un flux de travail plus "standard" existe pour node pour l'instant ; il n'est pas aussi mature que quelque chose comme Rails qui a une myriade de façons de faire fonctionner une application web.

Answer 5

Les gars de Cloudkick ont écrit une excellente solution à ce problème. Elle s'appelle Cast , http://cast-project.org/ .

Installez cast sur votre serveur et sur votre station de travail. Vous démarrez l'agent cast sur le serveur et votre station de travail se connecte à l'instance cast du serveur. Vous pouvez alors créer des "bundles", les télécharger sur le serveur, créer/mettre à niveau/détruire à partir de ceux-ci ainsi que démarrer/arrêter vos instances. Cast redémarre automatiquement vos services lorsqu'ils tombent en panne. Vous pouvez également écouter le stdout/strerr à distance, obtenir une liste des instances en cours d'exécution et des PID# et gérer vos instances/serveurs depuis votre poste de travail (pas besoin de SSH). La documentation est légèrement dépassée, mais les résultats valent la peine de faire un peu de travail supplémentaire. Toutes les interactions/commandes se font via HTTPS et une API RESTful.

Avant cela, je faisais toutes les mises à jour à la main avec SCP/SSH. Nous avons supervise en maintenant les choses en place. Nous n'avons pas regardé en arrière.