Distribuzione di un server Node.js di produzione

Question

Ho scritto un'app Node.js, sto cercando di farlo funzionare su una delle nostre macchine di produzione. Sembra una richiesta abbastanza comune, ma non riesco a trovare una soluzione adeguata. Non ci sono soluzioni consolidate per la distribuzione di app Node.js di produzione?

L'app è semplice (< 100 LOC), ma deve essere molto efficiente, affidabile e potrebbe funzionare continuamente per anni senza riavviare. Sta per essere eseguito su un sito grande, con decine di connessioni al secondo. (L'applicazione non è usato come un server web, ha solo un API JSON)

Qui ci sono gli approcci Ho considerato, ma non sono ancora sicuro di:.

Utilizzando un quadro (ad esempio espresso)

Perché l'applicazione deve essere ad alte prestazioni ed è così semplice, l'aggiunta di gonfiarsi sotto forma di un quadro è qualcosa che voglio evitare.

Avvio del server con nohup

Il problema principale è con la gestione delle eccezioni, siamo (ovviamente) non vogliamo l'intero server in crash a causa di un'eccezione. Da quello che ho capito, avvolgere l'intera app in un ciclo try {} catch {} non sarà di aiuto perché l'interprete Javascript è lasciato in uno stato imprevedibile dopo un'eccezione. È corretto?

Usando qualcosa di simile per sempre

Ho installato sempre in una macchina FreeBSD nostro ed è stato molto buggy. Finì per generare processi infiniti che non potevano essere uccisi da Forever. Ho dovuto eseguire kill -9 per riavviare la mia macchina e non mi sento troppo sicuro di eseguire un'applicazione di produzione su Forever. Sembra anche che Upstart (strumento simile, ma più generico) non verrà eseguito su FreeBSD.

soluzioni hosted (ad es. Heroku, Rackspace, Amazon EC2, etc.)

Questa è probabilmente la soluzione più semplice, ma abbiamo già un dell'hardware serio per il resto dei nostri server web. Per considerazioni finanziarie, non ha senso.

Sicuramente ci deve essere una soluzione consolidata a questo? Mi sto perdendo qualcosa?

Answer 1

• Si dovrebbe davvero usare un quadro (mi raccomando qualcosa come espresso da quando è stata battaglia-testato) a meno che non si vuole affrontare con le sessioni, biscotti, ecc middleware da soli. Express è veramente leggero.
• Avvio del server con nohup: non dovresti farlo, basta avviarlo con il normale comando "nodo". Anche Express racchiude i percorsi in un try-catch, quindi il tuo server non si bloccherà in una rotta. Tuttavia se il tuo server ha un problema serio, non dovresti temere di riavviarlo (inoltre, se hai almeno 2-3 processi, solo uno morirà, quindi resterà almeno 1-2 e l'utente avrà vinto " t sentire una cosa).
• Per il monitoraggio personalmente preferisco qualcosa di più a livello di sistema operativo, ad esempio Upstart e Monit.
• Soluzione di hosting: dal momento che hai già una tua roba hardware seria, non è necessario investire denaro in qualcos'altro. Basta usare un load balancer (forse nginx o node-http-proxy) per i proxy.

Answer 2

È possibile ottenere risposte migliori su ServerFault, ma c'è una descrizione di one user's experience here utilizzando supervisord. Avrai bisogno di utilizzare una sorta di watcher di processo per mantenere in vita il processo node e un altro consiglio comune sembra essere quello di invertire le connessioni al processo node in qualche modo. Probabilmente voterò per nginx (in questo modo è possibile avere nginx gestire la registrazione, l'autenticazione o qualsiasi altra funzionalità HTTP di livello superiore di cui si ha bisogno invece di unirli in un nodo), ma l'articolo citato riporta haproxy nei commenti qui e lì che potrebbe essere più leggero. La scelta del proxy inverso dipenderà probabilmente in gran parte dall'assistenza o meno del supporto WebSocket.

Non sono sicuro che esista ancora un flusso di lavoro "standard" per il nodo; non è così maturo come qualcosa come Rails che ha una miriade di modi per mantenere in esecuzione una webapp.

Answer 3

Vedere Hosting Node Apps.

Questo tutorial illustra come configurare un server in grado di ospitare le app node.js per le applicazioni JavaScript lato server. Al momento, le opzioni di hosting node.js si riducono ai processi del daemon del nodo in esecuzione che comunicano con un server web. La maggior parte dei server Web è in grado di effettuare connessioni proxy a una porta diversa, quindi sarà possibile utilizzare Apache o nginx per farlo.

Answer 4

Ci sono tre domande qui, penso.

Domanda 0: "Devo utilizzare un framework per l'app del mio nodo?"

Domanda 1: "Come si eseguono i server di nodo su macchine di produzione?"

Domanda 2: "Come distribuire le app di nodo in produzione".

Per Domanda 1, mi piace molto Cluster (anche se la versione più recente Node ha qualcosa di simile costruito in, per cui si potrebbe verificare che fuori). Ho avuto un buon successo con qualcosa come Monit/Upstart per monitorare gli eventi a livello di sistema operativo e assicurarsi che i server siano in buona salute. (Questo stava monitorando N cluster di server Ruby Thin, ma la stessa cosa).

A seconda del traffico, è possibile eseguire il cluster su più macchine, quindi posizionare un servizio di bilanciamento del carico di fronte a tale traffico. Ciò dipende dal traffico, dalla durata delle richieste di completamento/da quanto tempo si blocca il ciclo degli eventi e dal numero di processori/istanze del nodo avviate per ogni computer.

Un framework offre una migliore gestione degli errori e rileva errori che potrebbero uscire dalle normali app node.js. Se lo fai senza un framework, assicurati di leggere la gestione degli errori in node.js.

Per Domanda 2, Non credo che la comunità dei nodi abbia ancora una buona implementazione standard. Potresti provare a utilizzare lo strumento Capistrano di Ruby (ed ecco lo a blog entry talking about deploying cluster with Capinstrano).

La cosa brutta di Capistrano è che fa alcune supposizioni che potrebbero non essere vere (cioè: stai implementando un progetto Rails), quindi potresti finire a combattere molto con il framework.

La mia soluzione di distribuzione goto in generale è lo strumento Python Fabric, che offre strumenti di distribuzione e consente di fare ciò che è necessario fare.

Un'altra opzione di implementazione è "the cloud", con cose come Nodester: lasciare che si occupino di esso.

Answer 5

I ragazzi di Cloudkick hanno scritto un'ottima soluzione a questo. Si chiama Cast, http://cast-project.org/.

Installa il cast sul server e sulla workstation. Avvia il cast-agent sul server e fai firmare la tua workstation con l'istanza di cast dei server. È quindi possibile creare "pacchetti", caricarli sul server, creare/aggiornare/distruggere da essi e avviare/arrestare le istanze. Cast riavvierà automaticamente i tuoi servizi quando si bloccano. È inoltre possibile eseguire lo stdout/strerr in remoto e ottenere un elenco di istanze e PID in esecuzione e gestire istanze/server dalla workstation (non è necessario SSHing). I documenti sono leggermente obsoleti, ma i risultati valgono un po 'di lavoro extra. Tutte le interazioni/comandi sono su HTTPS e un'API RESTful.

Prima di questo stavo facendo tutti gli aggiornamenti a mano con SCP/SSH. Abbiamo supervise tenere le cose in ordine. Non abbiamo guardato indietro.