Installazione di Node.js per una facile implementazione e aggiornamento

Question

Attualmente stiamo sviluppando un sito Web (TYPO3 in Apache) per un cliente supportato da un'applicazione node.js/socket.io che fornisce aggiornamenti in tempo reale al contenuto servito dal CMS.

Poiché questo è il nostro primo progetto node.js, non ho alcuna procedura da seguire quando si tratta di "l'installazione perfetta", quindi ho dedicato del tempo a ricercare le tecniche di implementazione.

Un paio di domande rimangono per me, per ottenere una buona messa a punto, che:

1. è facile per il cliente di implementare. Questo è molto importante perché il nostro sito web sarà integrato nella loro installazione "live" di TYPO3 che serve un'abbondanza di siti Web e funziona su server che non sono gestiti dal cliente ma un'altra organizzazione (centralizzata) che rende le chiamate di supporto e le modifiche del server un processo lento.

2. Dovrebbe essere facile da aggiornare. Come accennato, la richiesta di riavvio e l'esecuzione delle modifiche al server è un processo lento, quindi è consigliabile che l'installazione del nodo venga riavviata/aggiornata quando riceve le modifiche inviate all'installazione live utilizzando git.

Deployment

La general consensus sembra essere quella di utilizzare forever quando si tratta di distribuzione di applicazioni nodo per tenerli in esecuzione. Ho provato forever e sembra funzionare bene quando installato da npm install forever -g (globale). Ciò richiederebbe comunque un'assistenza esterna per l'installazione globale sull'ambiente live, quindi preferirei che fosse in esecuzione dalla directory node_modules dell'applicazione, ma non sono stato in grado di creare un wrapper solido per farlo.

Inoltre, forever funziona correttamente, ma deve essere avviato manualmente. Quale sarebbe l'approccio migliore per garantire che venga avviato all'avvio del server e continui a funzionare?

• Un semplice script init.d?
• Scrivere un wrapper watchdog?
• Un'attività scheduler TYPO3 che verifica lo stato forever?

Il rapido sviluppo/Restart aggiornata

Siamo attualmente ancora in fase di sviluppo del progetto e ogni volta che faccio modifiche all'applicazione node.js ricomincio manualmente node o forever. Questo funziona, ma è lontano dall'ideale. Ci sono diversi piccoli npm moduli che verificano modifiche file e riavviare node dalle variazioni rilevate, come:

• Nodemon
• Node.js Supervisor
• Bounce
• Nodules (che non richiede il riavvio nodo, così potrebbe essere più facile da combinare con forever)
• Up

Qualcuno ha esperienza con qualcuno di questi?

Aggiornamento: Perché non usi solo Cluster?

Il Cluster module fornisce funzionalità simili tramite il meccanismo reload, ma doesn't work with Node 0.5+. Il core Cluster module (Node 0.6+) che lo ha sostituito non ha tutte queste caratteristiche ma fornisce solo il clustering. Che a sua volta doesn't play well with socket.io. Almeno not without using Redis (che è un problema per noi, perché non possiamo forzare un altro servizio prereq al cliente).

-

Ovviamente sto cercando di trovare la soluzione più stabile che combina un update-restarter con forever prima di consegnare il progetto al cliente e sono davvero sperando chiunque ha prodotto una comprovata combinazione di tecniche.

Answer 1

Combinando tutta la conoscenza raccolta (Grande ringraziamento a Julian Knight per le idee) e ai metodi testati la scorsa settimana, ho deciso di accontentarsi della soluzione di distribuzione descritta di seguito (ho pensato che sarebbe stato bello condividere per aiutare gli altri con le domande comparabili):

Auto-riavvio in caso di errori di script e ricaricamento automatico su script modifica è gestito dal forever, in quanto comprende anche un orologio sceneggiatura, a patto che sempre viene generato all'interno di un node.js script.

Per farlo, ho aggiunto un server.js per lanciare lo script app.js vogliamo davvero a correre:

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); 

Questo orologi tutti i file nella directory dell'applicazione per cambia e riavvia lo script in esecuzione in forever non appena si cambia. Poiché i registri e pidfile sono in sottodirectory dell'applicazione, quelli devono essere ignorati dal orologio file o lo script sarà riavvio del ciclo:

.foreverignore

pids/** 
logs/** 

Per rendere tutto questo inizio su sistema di avvio e ci consente di controllare facilmente il servizio utilizzando start node-app e stop node-app usiamo Ubuntu's Upstart. Ho unito due esempi (this e this uno) in uno che fa il lavoro abbastanza bene:

/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 

Come Kevin wisely mentions in his article è sconsigliabile esegui il nodo come root, quindi lo cambieremo in exec sudo -u www-data /usr/local/bin/node quando passeremo a nuovi server la prossima settimana.

Quindi, forever viene avviato automaticamente dal node server.js che viene lanciato da upstart, e monitor per gli arresti e le modifiche dei file, mantenendo l'intera impostazione in esecuzione tutto il tempo che vogliamo.

Spero che questo aiuti chiunque.

Answer 2

Potrebbe essere meglio, per uso di produzione, guardare qualcosa come Cluster. Potresti non volere le funzionalità del cluster ma include anche altre funzionalità di produzione come zero tempi di riavvio, logging, lavoratori, ecc.

Come dici tu, Forever è OK per i test ma non ha davvero quello che serve per la produzione uso.

mi sembra di ricordare vagamente che Cluster o qualcosa di simile possono essere adottate in nodo stesso venire v0.7

Answer 3

Dalla mia ultima risposta è per il futuro! Qui ci sono alcuni altri link per aiutare:

• 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 (vedi slide 35)
• http://www.slideshare.net/the_undefined/nodejs-in-production (diapositive 31 alla fine)
• When node.js goes down, how can I bring it back up automatically?

non ci ha ancora sembra una risposta perfetta ma ci sono molte persone che eseguono istanze di Node di produzione. Spero che questo ti indicherà la giusta direzione.