Come posso eseguire un'applicazione Node.js come processo proprio?

Qual è il modo migliore per distribuire Node.js?

Ho un VPS Dreamhost (è quello che chiamano a virtuale ) e sono stato in grado di installare Node.js e impostare un proxy. Funziona alla grande finché mantengo aperta la connessione SSH con cui ho avviato il nodo.

Risposta 2016 : quasi ogni distribuzione Linux viene fornita con systemd, il che significa che per sempre, monit, PM2, ecc. Non sono più necessari - il tuo sistema operativo gestisce già queste attività .

Crea un myapp.servicefile (sostituendo "myapp" con il nome della tua app, ovviamente):

[Unit]
Description=My app

[Service]
ExecStart=/var/www/myapp/app.js
Restart=always
User=nobody
# Note Debian/Ubuntu uses 'nogroup', RHEL/Fedora uses 'nobody'
Group=nobody
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/var/www/myapp

[Install]
WantedBy=multi-user.target

Nota se sei nuovo su Unix: /var/www/myapp/app.js dovrebbe avere#!/usr/bin/env node la prima riga.

Copia il tuo file di servizio in /etc/systemd/system cartella.

Informa systemd del nuovo servizio con systemctl daemon-reload .

Inizia con systemctl start myapp .

Attivalo per l'avvio con systemctl enable myapp .

Vedi i log con journalctl -u myapp

Questo è tratto da Come implementiamo le app nodo su Linux, edizione 2018 , che include anche i comandi per generare un AWS / DigitalOcean / Azure CloudConfig per costruire server Linux / nodo (incluso il .servicefile).

Usa per sempre . Esegue i programmi Node.js in processi separati e li riavvia se muore.

Uso:

• forever start example.js per iniziare un processo.
• forever list per vedere l'elenco di tutti i processi avviati da sempre
• forever stop example.jsper interrompere il processo o forever stop 0per interrompere il processo con l'indice 0 (come mostrato da forever list).

Ho scritto del mio metodo di distribuzione qui: Distribuzione di app node.js

In breve:

• Usa il gancio post-ricezione git
• Jake per lo strumento di compilazione
• Avvia come wrapper di servizio per il nodo
• Monit per monitorare e riavviare le applicazioni che vanno giù
• nginx per instradare le richieste a diverse applicazioni sullo stesso server

PM2 fa i trucchi.

Le caratteristiche sono: monitoraggio, ricarica di hot code, bilanciamento del carico integrato, script di avvio automatico e processi di resurrect / dump.

È possibile utilizzare monit, forever, upstarto systemdper avviare il server.

Puoi usare Varnish o HAProxy invece di Nginx (è noto che Nginx non funziona con i websocket).

Come una soluzione rapida e sporca è possibile utilizzare nohup node your_app.js &per evitare che la vostra applicazione che termina con il server, ma forever, monite le altre soluzioni proposte sono meglio.

Ho creato uno script Upstart attualmente utilizzato per le mie app:

description "YOUR APP NAME"
author "Capy - http://ecapy.com"

env LOG_FILE=/var/log/node/miapp.log
env APP_DIR=/var/node/miapp
env APP=app.js
env PID_NAME=miapp.pid
env USER=www-data
env GROUP=www-data
env POST_START_MESSAGE_TO_LOG="miapp HAS BEEN STARTED."
env NODE_BIN=/usr/local/bin/node
env PID_PATH=/var/opt/node/run
env SERVER_ENV="production"

######################################################

start on runlevel [2345]
stop on runlevel [016]

respawn
respawn limit 99 5

pre-start script
    mkdir -p $PID_PATH
    mkdir -p /var/log/node
end script

script
    export NODE_ENV=$SERVER_ENV
    exec start-stop-daemon --start --chuid $USER:$GROUP --make-pidfile --pidfile $PID_PATH/$PID_NAME --chdir $APP_DIR --exec $NODE_BIN -- $APP >> $LOG_FILE 2>&1
end script

post-start script
    echo $POST_START_MESSAGE_TO_LOG >> $LOG_FILE
end script

Personalizza tutto prima di #########, crea un file in /etc/init/your-service.conf e incollalo lì.

Allora puoi:

start your-service
stop your-service
restart your-service
status your-service

Ho scritto una guida piuttosto completa alla distribuzione di Node.js, con file di esempio:

Tutorial: come distribuire le applicazioni Node.js, con esempi

Copre cose come http-proxy, SSL e Socket.IO .

Ecco un articolo più lungo sulla risoluzione di questo problema con systemd: http://savanne.be/articles/deploying-node-js-with-systemd/

Alcune cose da tenere a mente:

• Chi inizierà il monitoraggio del processo? Per sempre è un ottimo strumento, ma ha bisogno di uno strumento di monitoraggio per mantenersi in funzione. È un po 'sciocco, perché non usare semplicemente il tuo sistema init?
• Puoi monitorare adeguatamente i tuoi processi?
• Stai eseguendo più backend? In tal caso, sono in atto disposizioni per impedire a qualcuno di loro di abbattere gli altri in termini di utilizzo delle risorse?
• Il servizio sarà sempre necessario? In caso contrario, prendere in considerazione l'attivazione del socket (consultare l'articolo).

Tutte queste cose possono essere facilmente eseguite con systemd.

Se si dispone dell'accesso root, è meglio impostare un demone in modo che funzioni in modo sicuro in background. Puoi leggere come fare proprio questo per Debian e Ubuntu nel post del blog Esegui Node.js come servizio su Ubuntu .

Per sempre farà il trucco.

@Kevin: dovresti essere in grado di uccidere bene i processi. Vorrei ricontrollare un po 'la documentazione. Se riesci a riprodurre l'errore, sarebbe bello pubblicarlo come problema su GitHub.

Prova questo: http://www.technology-ebay.de/the-teams/mobile-de/blog/deploying-node-applications-with-capistrano-github-nginx-and-upstart.html

Un'ottima guida dettagliata per la distribuzione di app Node.js con Capistrano, Upstart e Nginx

Come detto Box9, Forever è una buona scelta per il codice di produzione. Ma è anche possibile continuare un processo anche se la connessione SSH è chiusa dal client.

Sebbene non sia necessariamente una buona idea per la produzione, questo è molto utile quando si è nel mezzo di lunghe sessioni di debug o per seguire l'output della console di lunghi processi o quando è utile per disconnettere la connessione SSH, ma mantenere il terminale attivo nel server per riconnettersi in un secondo momento (come avviare l'applicazione Node.js a casa e riconnettersi alla console più tardi al lavoro per verificare come stanno andando le cose).

Supponendo che il server sia una casella * nix, è possibile utilizzare il comando screen dalla shell per mantenere il processo in esecuzione anche se il client SSH è chiuso. Puoi scaricare / installare lo schermo dal Web se non è già installato (cerca un pacchetto per la tua distribuzione se Linux o usa MacPorts se OS X).

Funziona come segue:

1. Quando si apre per la prima volta la connessione SSH, digitare 'screen' - questo avvierà la sessione dello schermo.
2. Inizia a lavorare normalmente (ovvero avvia l'applicazione Node.js)
3. Al termine, chiudere il terminale. I processi del server continueranno a essere eseguiti.
4. Per riconnetterti alla tua console, torna al server, accedi e inserisci 'screen -r' per riconnetterti. Il vecchio contesto della console tornerà pronto per riprendere a utilizzarlo.
5. Per uscire dalla schermata, mentre sei connesso al server, digita "esci" sul prompt della console, che ti farà cadere sulla shell normale.

Puoi avere più sessioni dello schermo in esecuzione contemporaneamente in questo modo, se necessario, e puoi collegarti a qualsiasi di esso da qualsiasi client. Leggi la documentazione online per tutte le opzioni.

Per sempre è una buona opzione per mantenere le app in esecuzione (ed è npm installabile come modulo che è bello).

Ma per una "distribuzione" più seria - cose come la gestione remota della distribuzione, del riavvio, dell'esecuzione di comandi ecc. - Userei capistrano con l'estensione del nodo.

https://github.com/loopj/capistrano-node-deploy

https://paastor.com è un servizio relativamente nuovo che esegue la distribuzione per te, su un VPS o su un altro server. C'è una CLI per inviare il codice. Paastor ha un livello gratuito, almeno al momento della pubblicazione.

Nel tuo caso puoi usare il demone upstart . Per una soluzione di distribuzione completa, posso suggerire capistrano . Due guide utili sono Come configurare Node.js env e Come distribuire via capistrano + upstart .

Prova il nodo-deploy-server . Si tratta di un set di strumenti complesso per la distribuzione di un'applicazione sui server privati. È scritto in Node.js e utilizza npm per l'installazione.