web-dev-qa-db-fra.com

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

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

Comme 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 peu de temps à rechercher des techniques de déploiement.

Il me reste quelques questions pour parvenir à une bonne configuration qui:

  1. Est facile à déployer pour le client . Ceci est très important car notre site Web sera intégré dans leur installation TYPO3 `` en direct '' qui dessert une multitude de sites Web et fonctionne sur des serveurs qui ne sont pas gérés par le client, mais une autre organisation (centralisée) qui effectue des appels de support et des changements de serveur a processus lent.

  2. La mise à jour devrait être facile. Comme mentionné, la demande de redémarrage et la modification du serveur est un processus lent, donc, idéalement, l'installation du nœud devrait redémarrer/mettre à jour lorsqu'elle reçoit des modifications qui sont poussés sur l'installation en direct en utilisant git.

Déploiement

Le consensus général semble être d'utiliser forever quand il s'agit de déployer des applications de noeud 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 une installation globale sur l'environnement en direct, donc je préférerais qu'il s'exécute à partir de l'application node_modules répertoire, mais je n'ai pas pu créer un wrapper solide pour le faire.

De plus, forever fonctionne bien, mais il doit être démarré manuellement. Quelle serait la meilleure approche pour garantir qu'elle démarre au démarrage du serveur et continue de fonctionner?

  • Un simple init.d script?
  • Vous écrivez un wrapper de surveillance?
  • Une tâche du planificateur TYPO3 qui vérifie l'état forever?

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

Nous en sommes actuellement au stade de développement du projet et chaque fois que j'apporte des modifications à l'application node.js, je redémarre manuellement node ou forever. Cela fonctionne, mais est loin d'être idéal. Il existe plusieurs modules npm plus petits qui vérifient les modifications de fichiers et redémarrent node en cas de changements détectés, comme:

Quelqu'un at-il de l'expérience avec l'un de ces éléments?

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

Le module de cluster offre des fonctionnalités similaires via le mécanisme reload , mais ne fonctionne pas avec Node 0.5 + . Le module Cluster principal (Node 0.6 +) qui l'a remplacé n'a pas toutes ces fonctionnalités mais ne fournit que le clustering. Ce qui à son tour ne fonctionne pas bien avec socket.io =. Au moins non sans utiliser Redis (ce qui est un problème pour nous, car nous ne pouvons pas forcer un autre service préalable au client).

-

Évidemment, j'essaie de trouver la solution la plus stable qui combine une mise à jour-redémarrage avec forever avant de remettre le projet au client et j'espère vraiment que quiconque a produit une combinaison éprouvée de techniques.

node.jsdeploymentupdates
56
Rem.co

Combinant toutes les connaissances collectées (Un 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 (je pensais que ce serait bien de partager pour aider les autres avec des questions comparables):

Redémarrage automatique sur les erreurs de script et le rechargement automatique sur les changements de script est géré par forever , car il inclut également une surveillance de script, tant que Forever est généré à 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);

Cela surveille tous les fichiers du répertoire d'application pour les modifications et redémarre le script exécuté dans forever dès que l'un change. Parce que les journaux et le pidfile sont dans les sous-répertoires de l'application, ceux-ci doivent être ignorés de la surveillance des fichiers, sinon le script redémarrera en boucle:

. foreverignore 

pids/**
logs/**

Pour que tout cela démarre au démarrage du système et nous permettant de contrôler facilement le service à l'aide de start node-appet stop node-app nous utilisons pstart d'Ubunt . J'ai combiné deux exemples ( this et this one) en un seul 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 <[email protected]>"
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 le nœud en tant que root, nous allons donc changer cela en exec Sudo -u www-data /usr/local/bin/node lorsque nous passerons à de nouveaux serveurs la semaine prochaine.

Ainsi, forever démarre automatiquement par node server.js qui est lancé par upstart, et surveille les plantages et les modifications de fichiers, en gardant la configuration entière en marche aussi longtemps que nous le voulons.

J'espère que cela aide n'importe qui.

63
Rem.co

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

Il ne semble pas encore y avoir de réponse parfaite, mais il y a beaucoup de gens qui exécutent la production Node instances. J'espère que cela vous dirigera dans la bonne direction.

7
Julian Knight

Vous pourriez être mieux, pour une utilisation en production, pour regarder quelque chose comme Cluster . Vous ne souhaiterez peut-être pas les fonctionnalités du cluster, mais il comprend également d'autres fonctionnalités de production telles que les redémarrages sans interruption, la journalisation, les travailleurs, etc.

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

Je semble me souvenir vaguement que Cluster ou quelque chose de similaire peut être adopté dans Node lui-même venu v0.7

5
Julian Knight