Fornire Node.JS webapp "chiave in mano"

Question

Sto costruendo una semplice applicazione Node.JS per un client. La webapp dovrebbe essere facile da implementare su ogni istanza del server (che sono RedHat EL 6.3), "chiave in mano".

Qual è il modo migliore per impacchettare un'app Node.JS? Fondamentalmente, ho bisogno di un "installatore" o "pacchetto" a:

• Installare Node.JS
• Installare le dipendenze (npm install)
• Compilare i file dell'applicazione (CSS, JS, HTML, ecc)

Answer 1

È necessario fornire un pacchetto autonomo. Si prega di controllare il grande sito The Twelve-Factor App, in particolare la sezione build, release, run. C'è un sacco di saggezza conquistata da ingegneri esperti in operazioni incorporate in quel sito.

• In pronti contro termine della vostra applicazione, scrivere uno script (shell, nodo, a prescindere) in grado di generare un archivio distribuibile
• RPM o tar archivio sono le 2 scelte più ragionevoli per voi. tar è più portatile e più semplice. RPM si integrerebbe perfettamente con una distribuzione basata su RPM. Raccomanderei di iniziare con tar se non hai fatto un sacco di lavoro di packaging/gestione del software. RPM è significativamente più complesso di tar.
• L'archivio tar deve incorporare i file node.js al suo interno. Ciò renderà la tua applicazione facile da installare ed eviterà la condivisione di un'installazione di nodo a livello di sistema creando così un accoppiamento artificiale. Se si utilizza la route RPM, è possibile specificare il nodo come dipendenza nel file spec RPM (ma probabilmente non si dovrebbe - vedere di seguito).
• L'archivio deve incorporare anche tutte le dipendenze di npm. Non eseguire npm install durante l'installazione del pacchetto. Potresti utilizzare lo strumento npm shrinkwrap per gestire le tue dipendenze durante lo sviluppo, ma al momento dell'implementazione dovrebbero essere pre-raggruppate e pronte per essere eseguite.

In particolare, queste sono cattive idee si dovrebbe evitare:

• Non scaricare nulla da Internet durante l'installazione. Questo è fragile, lento e potenzialmente in grado di generare brutte sorprese, inclusi problemi di sicurezza
• Non creare artefatti al momento dell'installazione che è possibile creare in fase di produzione. Quindi i file nave pre-build CSS, requirejs file ottimizzati, i binari precompilati, ecc

Quanto alla questione se il vostro RPM applicazione deve elencare node.js come una dipendenza o nodo di incorporare nella RPM, qui ci sono alcuni punti considerare.

• Embed Node.JS nella vostra RPM
  • singolo .rpm di file da distribuire
  • consente all'applicazione di controllare strettamente la versione nodo che utilizza. (vedi sotto)
  • Maggiore affidabilità. Il fatto è che la tua app è probabilmente accoppiata abbastanza strettamente almeno alla versione minore di node.js che sviluppi su (0.8.x per esempio) o persino una versione di patch (> = 0.8.12 < 0.9 per esempio). È meglio consentire il nodo.js per disaccoppiare la tua app dal sistema operativo, ma non farti ingannare nel pensare che la tua app funzionerà in modo affidabile su una versione diversa di node.js senza testare la regolazione &. Più comunemente in questi giorni c'è solo 1 app in esecuzione sul sistema operativo, e la nozione di condivisione del nodo tra le app valuta erroneamente la conservazione dello spazio su disco rispetto al corretto disaccoppiamento e all'indipendenza operativa delle applicazioni.
  • Non è chiaro se ci siano degli RPM pre-costruiti ufficiali/affidabili là fuori in Yumland che "funzioneranno".
• Specificare node.js come una dipendenza del PRM
  • segue la filosofia generale della gestione dei pacchetti del sistema operativo (evitare la duplicazione, risparmiare spazio su disco, ecc)
  • RPM fornisce funzionalità oltre TAR intorno gestione delle scorte , disinstallazione, aggiornamento, ecc. Dato che stai facendo questa domanda, probabilmente non sei ancora pronto per affrontarli correttamente, quindi potresti iniziare con tar e una volta che hai una solida comprensione di ciò, considera gli script di aggiornamento di RPM, ecc.
  • Il punto "singolo file da distribuire" può essere veloce y diventata insostenibile una volta la vostra applicazione inizia a utilizzare un database o 3, sostenendo demoni per la posta elettronica, gli aggregatori di log, ecc