Node.js
Distribuera Node.js-applikationer i produktionen
Sök…
Ställer NODE_ENV = "produktion"
Produktionsinstallationer kommer att variera på många sätt, men en standardkonvention vid distribution i produktion är att definiera en miljövariabel som kallas NODE_ENV
och ställa in dess värde till "produktion" .
Runtime-flaggor
Varje kod som körs i din applikation (inklusive externa moduler) kan kontrollera värdet på NODE_ENV
:
if(process.env.NODE_ENV === 'production') {
// We are running in production mode
} else {
// We are running in development mode
}
beroenden
När NODE_ENV
miljövariabeln är inställd på "produktion" kommer alla devDependencies
i din package.json- fil att ignoreras helt när du kör npm install
. Du kan också verkställa detta med en - --production
:
npm install --production
För inställning av NODE_ENV
du använda någon av dessa metoder
metod 1: Ställ in NODE_ENV för alla nodappar
Windows:
set NODE_ENV=production
Linux eller annat unix-baserat system:
export NODE_ENV=production
Detta ställer in NODE_ENV
för den aktuella bash-sessionen, vilket innebär att alla appar som startats efter detta uttalande har NODE_ENV
inställd på production
.
metod 2: ställ NODE_ENV för aktuell app
NODE_ENV=production node app.js
Detta kommer att ställa in NODE_ENV
för den aktuella appen. Detta hjälper när vi vill testa våra appar i olika miljöer.
metod 3: skapa .env
fil och använda den
Detta använder idén som förklaras här . Se detta inlägg för mer detaljerad förklaring.
I .env
och botten skapar du .env
filen och kör några bash-skript för att ställa in dem på miljön.
För att undvika att skriva ett bash-skript kan env-cmd- paketet användas för att ladda miljövariabler som definierats i .env
filen.
env-cmd .env node app.js
metod 4: Använd cross-env
paket
Detta paket gör det möjligt att ställa in miljövariabler på ett sätt för varje plattform.
När du har installerat det med npm kan du bara lägga till det i ditt distributionsskript i package.json
enligt följande:
"build:deploy": "cross-env NODE_ENV=production webpack"
Hantera appen med processhanteraren
Det är bra att köra NodeJS-appar som kontrolleras av processchefer. Processhanteraren hjälper till att hålla applikationen vid liv för alltid, starta om felet, ladda om igen utan drifttid och förenklar administrationen. De mest kraftfulla av dem (som PM2 ) har en inbyggd lastbalans. Med PM2 kan du också hantera applikationsloggning, övervakning och klustering.
PM2-processchef
Installera PM2:
npm install pm2 -g
Processen kan startas i klusterläge med integrerad belastningsbalans för att sprida belastningen mellan processerna:
pm2 start app.js -i 0 --name "api"
( -i är att ange antalet processer som ska spaja. Om det är 0 kommer processnumret att baseras på CPU-kärnans räkning)
Medan flera användare är i produktion, måste det ha en enda punkt för PM2. Därför måste pm2-kommandot förinställas med en plats (för PM2-konfigurering), annars kommer det att skapa en ny pm2-process för alla användare med config i respektive hemmakatalog. Och det kommer att vara inkonsekvent.
Användning: PM2_HOME=/etc/.pm2 pm2 start app.js
Distribution med PM2
PM2
är en produktionsprocesschef för Node.js
applikationer, som gör att du kan hålla applikationer vid liv för alltid och ladda dem utan driftstopp. Med PM2 kan du också hantera applikationsloggning, övervakning och klustering.
Installera pm2
globalt.
npm install -g pm2
node.js
appen node.js
med PM2.
pm2 start server.js --name "my-app"
Följande kommandon är användbara när du arbetar med PM2
.
Lista alla processer som körs:
pm2 list
Stoppa en app:
pm2 stop my-app
Starta om en app:
pm2 restart my-app
Så här visar du detaljerad information om en app:
pm2 show my-app
Så här tar du bort en app från PM2: s register:
pm2 delete my-app
Distribution med hjälp av processhanterare
Processhanterare används vanligtvis i produktionen för att distribuera en nodejs-app. Huvudfunktionerna i en processhanterare är att starta om servern om den kraschar, kontrollera resursförbrukningen, förbättra körtidens prestanda, övervakning etc.
Några av de populära processcheferna som skapats av nodsamhället är för alltid, pm2, etc.
Forvever
forever
är ett kommandoradsgränssnittsverktyg för att säkerställa att ett givet skript körs kontinuerligt. forever
enkla gränssnitt gör det idealiskt för att köra mindre distributioner av Node.js
appar och skript.
övervakar forever
din process och startar om den kraschar.
Installera för forever
globalt.
$ npm install -g forever
Kör ansökan:
$ forever start server.js
Detta startar servern och ger ett id för processen (startar från 0).
Starta om applikationen:
$ forever restart 0
Här 0
är serverns id.
Stoppa ansökan:
$ forever stop 0
I likhet med omstart är 0
id-servern. Du kan också ge process-id eller skriptnamn istället för id som ges av evigt.
För fler kommandon: https://www.npmjs.com/package/forever
Använda olika egenskaper / konfiguration för olika miljöer som dev, qa, iscensättning etc.
Stora applikationer behöver ofta olika egenskaper när de körs i olika miljöer. Vi kan uppnå detta genom att överföra argument till NodeJs applikation och använda samma argument i nodprocessen för att ladda specifik miljöegenskapsfil.
Anta att vi har två fastighetsfiler för olika miljöer.
dev.json
{ "PORT": 3000, "DB": { "host": "localhost", "user": "bob", "password": "12345" } }
qa.json
{ "PORT": 3001, "DB": { "host": "where_db_is_hosted", "user": "bob", "password": "54321" } }
Följande kod i applikationen kommer att exportera respektive fastighetsfil som vi vill använda.
process.argv.forEach(function (val) {
var arg = val.split("=");
if (arg.length > 0) {
if (arg[0] === 'env') {
var env = require('./' + arg[1] + '.json');
exports.prop = env;
}
}
});
Vi ger argument till ansökan som följande
node app.js env=dev
om vi använder process manager som för evigt än så enkelt som
forever start app.js env=dev
Utnyttja kluster
En enda instans av Node.js körs i en enda tråd. För att dra fördel av flerkärniga system kommer användaren ibland att vilja starta ett kluster av Node.js-processer för att hantera belastningen.
var cluster = require('cluster');
var numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
// In real life, you'd probably use more than just 2 workers,
// and perhaps not put the master and worker in the same file.
//
// You can also of course get a bit fancier about logging, and
// implement whatever custom logic you need to prevent DoS
// attacks and other bad behavior.
//
// See the options in the cluster documentation.
//
// The important thing is that the master does very little,
// increasing our resilience to unexpected errors.
console.log('your server is working on ' + numCPUs + ' cores');
for (var i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('disconnect', function(worker) {
console.error('disconnect!');
//clearTimeout(timeout);
cluster.fork();
});
} else {
require('./app.js');
}