Configuration Node.js pour un déploiement et une mise à jour faciles

Question

Nous développons actuellement un site web (TYPO3 sous Apache) pour un client qui est soutenu par une application node.js/socket.io qui fournit des mises à jour en temps réel du contenu servi par le CMS.

Étant donné qu'il s'agit de notre premier projet node.js, je n'ai pas de meilleures pratiques à suivre en ce qui concerne la "configuration parfaite". J'ai donc passé un certain temps à rechercher des techniques de déploiement.

Il me reste quelques questions à régler pour obtenir une bonne installation :

1. est facile à déployer pour le client . C'est très important car notre site web sera intégré dans leur installation TYPO3 "en direct", qui sert une multitude de sites web et fonctionne sur des serveurs qui ne sont pas gérés par le client mais par une autre organisation (centralisée), ce qui rend les appels au support et les changements de serveur très lents.

2. La mise à jour devrait être facile. Comme nous l'avons mentionné, demander des redémarrages et effectuer des modifications sur le serveur est un processus lent. Idéalement, l'installation du nœud devrait redémarrer / mettre à jour lorsqu'elle reçoit des modifications qui sont poussées sur l'installation en direct en utilisant les éléments suivants git .

Déploiement

El consensus général semble être d'utiliser forever quand il s'agit de déployer des applications de nœuds pour les faire fonctionner. J'ai testé forever et il semble fonctionner correctement lorsqu'il est installé par npm install forever -g (global). Cela nécessiterait cependant une assistance externe pour l'installation globale sur l'environnement réel, et je préférerais donc qu'elle soit exécutée à partir de la page d'accueil de l'application. node_modules mais je n'ai pas été capable de créer une enveloppe solide pour le faire.

En outre, forever fonctionne bien, mais il doit être démarré manuellement. Quelle serait la meilleure approche pour s'assurer qu'il est lancé au démarrage du serveur et qu'il continue à fonctionner ?

• Un simple init.d script ?
• Écrire une enveloppe de chien de garde ?
• Une tâche du planificateur TYPO3 qui vérifie forever statut ?

Développement rapide / Redémarrage à la mise à jour

Nous sommes actuellement toujours dans la phase de développement du projet et chaque fois que je fais des changements à l'application node.js, je redémarre manuellement. node o forever . Cela fonctionne, mais c'est loin d'être idéal. Il y a plusieurs petits npm des modules qui vérifient les modifications de fichiers et redémarrent node sur les changements détectés, comme :

• Nodemon
• Superviseur Node.js
• Rebondir
• Nodules (ce qui ne nécessite pas de redémarrer le nœud, donc peut être plus facile à combiner avec forever )
• Up

Quelqu'un a-t-il de l'expérience dans ce domaine ?

Mise à jour : Pourquoi n'utilisez-vous pas simplement Cluster ?

El Module en grappe fournit une fonctionnalité similaire par le biais de la recharger mécanisme, mais ne fonctionne pas avec Node 0.5+. . Le site Module de base Cluster (Node 0.6+) qu'il a remplacé il n'a pas toutes ces fonctionnalités mais fournit seulement le clustering. Qui à son tour ne joue pas bien avec socket.io . Au moins pas sans utiliser Redis (ce qui est un problème pour nous, car nous ne pouvons pas imposer un autre service préalable au client).

--

Il est évident que j'essaie de trouver la solution la plus stable qui combine une mise à jour du démarrage avec forever avant de remettre le projet au client et j'espère vraiment que quelqu'un a produit une combinaison de techniques qui a fait ses preuves.

Answer 1

En combinant toutes les connaissances recueillies (grand merci à Julian Knight pour les idées) et les méthodes testées la semaine dernière, j'ai décidé de me contenter de la solution de déploiement décrite ci-dessous (j'ai pensé qu'il serait bon de partager pour aider d'autres personnes ayant des questions comparables) :

Redémarrage automatique en cas d'erreurs de script. et le rechargement automatique sur les changements de script est géré par pour toujours car il comprend également une montre script, tant que Forever est créé à partir d'un script node.js.

Pour ce faire, j'ai ajouté un server.js pour lancer le app.js script que nous voulons réellement exécuter :

server.js

var forever = require('forever'),
    child = new(forever.Monitor)('app.js', {
        'silent': false,
        'pidFile': 'pids/app.pid',
        'watch': true,
        'watchDirectory': '.',      // Top-level directory to watch from.
        'watchIgnoreDotFiles': true, // whether to ignore dot files
        'watchIgnorePatterns': [], // array of glob patterns to ignore, merged with contents of watchDirectory + '/.foreverignore' file
        'logFile': 'logs/forever.log', // Path to log output from forever process (when daemonized)
        'outFile': 'logs/forever.out', // Path to log output from child stdout
        'errFile': 'logs/forever.err'
    });
child.start();
forever.startServer(child);

Ceci surveille tous les fichiers dans le répertoire de l'application pour des changements et redémarre le script s'exécutant en forever dès qu'il y a un changement. Parce que les logs et le pidfile sont dans des sous-répertoires de l'application, ceux-ci doivent être ignorés de la surveillance des fichiers, ou le script bouclera les redémarrages :

.foreverignore

pids/**
logs/**

Pour faire en sorte que tout cela démarre au démarrage du système et nous permettre de contrôler facilement le service à l'aide de start node-app et stop node-app nous utilisons Le démarrage d'Ubuntu . J'ai combiné deux exemples ( este y este un) en un qui fait très bien le travail :

/etc/init/node-app.conf

# This is an upstart (http://upstart.ubuntu.com/) script
# to run the node.js server on system boot and make it
# manageable with commands such as
# 'start node-app' and 'stop node-app'
#
# This script is to be placed in /etc/init to work with upstart.
#
# Internally the 'initctl' command is used to manage:
# initctl help
# initctl status node-app
# initctl reload node-app
# initctl start node-app

description "node.js forever server for node-app"
author      "Remco Overdijk <remco@maxserv.nl>"
version "1.0"

expect fork

# used to be: start on startup
# until we found some mounts weren't ready yet while booting:

start on started mountall
stop on shutdown

# Automatically Respawn:
respawn
respawn limit 99 5

env HOME=/home/user/node-app-dir

script
    # Not sure why $HOME is needed, but we found that it is:
    export HOME=$HOME
    chdir $HOME
    exec /usr/local/bin/node server.js > logs/node.log &
end script

#post-start script
#   # Optionally put a script here that will notifiy you node has (re)started
#   # /root/bin/hoptoad.sh "node.js has started!"
#end script

Comme Kevin mentionne judicieusement dans son article il n'est pas judicieux d'exécuter node en tant que Root, donc nous allons changer cela en exec sudo -u www-data /usr/local/bin/node lorsque nous passerons à de nouveaux serveurs la semaine prochaine.

Donc, forever est lancé automatiquement par node server.js qui est lancé par upstart et surveille les pannes et les modifications de fichiers, afin que l'ensemble de l'installation fonctionne aussi longtemps que nous le souhaitons.

J'espère que cela vous aidera.

Answer 2

Puisque ma dernière réponse est pour l'avenir ! Voici d'autres liens pour vous aider :

• https://serverfault.com/questions/274857/how-to-use-node-js-as-a-production-web-server
• http://www.slideshare.net/the_undefined/nodejs-best-practices-10428790 (voir diapositive 35)
• http://www.slideshare.net/the_undefined/nodejs-in-production (diapositives 31 à la fin)
• Lorsque node.js tombe en panne, comment puis-je le remettre en marche automatiquement ?

Il ne semble pas encore y avoir de réponse parfaite mais il y a beaucoup de personnes qui utilisent des instances Node en production. Espérons que cela vous orientera dans la bonne direction.

Answer 3

Il serait préférable, pour une utilisation en production, de regarder quelque chose comme Cluster . Il se peut que vous ne souhaitiez pas les fonctionnalités de cluster, mais il inclut également d'autres fonctionnalités de production telles que les redémarrages sans temps d'arrêt, la journalisation, les travailleurs, etc.

Comme vous le dites, Forever est bon pour les tests mais n'a pas vraiment ce qu'il faut pour une utilisation en production.

Il me semble me souvenir vaguement que Cluster ou quelque chose de similaire pourrait être adopté dans Node lui-même à partir de la v0.7.