Node.js
実稼働環境でのNode.jsアプリケーションのデプロイ
サーチ…
NODE_ENV = "production"を設定する
NODE_ENV環境でのデプロイメントはさまざまですが、 NODE_ENV環境にデプロイする際の標準的な規則は、 NODE_ENVという環境変数を定義し、その値を"production"に設定することです。
ランタイムフラグ
アプリケーション内で実行されているコード（外部モジュールを含む）は、 NODE_ENVの値をチェックできます。
if(process.env.NODE_ENV === 'production') {
// We are running in production mode
} else {
// We are running in development mode
}
依存関係
NODE_ENV環境変数が'production'に設定されている場合、 package.jsonファイル内のすべてのdevDependenciesは、 npm install実行すると完全に無視されます。 --productionフラグでこれを強制することもできます：
npm install --production
NODE_ENVを設定するには、これらの方法のいずれかを使用できます
方法1：すべてのノードのアプリケーションにNODE_ENVを設定する
Windows：
set NODE_ENV=production
Linuxやその他のUNIXベースのシステム：
export NODE_ENV=production
これは、設定NODE_ENVこの文がありますので、後に任意のアプリケーションが起動し、現在のbashのセッションにNODE_ENVに設定しproduction 。
方法2：現在のアプリにNODE_ENVを設定する
NODE_ENV=production node app.js
これにより、現在のアプリだけにNODE_ENVが設定されます。これは、さまざまな環境でアプリをテストするときに役立ちます。
方法3： .envファイルを作成して使用する
これはここで説明されている考え方を使用します 。より詳しい説明については、この記事を参照してください。
基本的に.envファイルを作成し、環境に設定するbashスクリプトをいくつか実行します。
bashスクリプトの作成を避けるため、 env-cmdパッケージを使用して、 .envファイルで定義された環境変数を読み込むことができます。
env-cmd .env node app.js
方法4： cross-envパッケージを使用する
このパッケージを使用すると、プラットフォームごとに環境変数を設定できます。
npmでインストールした後、次のようにpackage.json内のデプロイメントスクリプトに追加することができます：
"build:deploy": "cross-env NODE_ENV=production webpack"
プロセスマネージャーでアプリを管理する
プロセスマネージャーによって制御されるNodeJSアプリケーションを実行することは良い習慣です。プロセスマネージャーは、アプリケーションを永遠に生かし、障害時に再起動し、ダウンタイムなしで再ロードし、管理を簡素化します。それらの中で最も強力なもの（ PM2のようなもの）にはロードバランサが組み込まれています。また、PM2を使用すると、アプリケーションのロギング、監視、およびクラスタリングを管理できます。
PM2プロセスマネージャ
PM2のインストール：
npm install pm2 -g
ロードバランサが統合されたクラスタモードでプロセスを開始すると、プロセス間で負荷を分散できます。
pm2 start app.js -i 0 --name "api" （- iは、生成するプロセスの数を指定するためのもので、0の場合はプロセス数はCPUのコア数に基づいています）
本番環境では複数のユーザーがいるが、PM2には単一のポイントが必要である。したがって、pm2コマンドにはプレフィックスを付ける必要があります（PM2 configの場合）。それ以外の場合は、それぞれのホームディレクトリにconfigを持つすべてのユーザーに対して新しいpm2プロセスを生成します。そしてそれは矛盾するでしょう。
使用法： PM2_HOME=/etc/.pm2 pm2 start app.js
PM2を使用した導入
PM2は、 Node.jsアプリケーションのプロダクションプロセスマネージャです。アプリケーションを永久に生かし、ダウンタイムなしでリロードすることができます。また、PM2を使用すると、アプリケーションのロギング、監視、およびクラスタリングを管理できます。
pm2グローバルにインストールします。
npm install -g pm2
次に、 PM2.を使用してnode.jsアプリケーションを実行しPM2.
pm2 start server.js --name "my-app"
以下のコマンドは、 PM2作業する場合に便利です。
実行中のプロセスをすべて一覧表示する：
pm2 list
アプリを停止する：
pm2 stop my-app
アプリを再起動する：
pm2 restart my-app
アプリに関する詳細情報を表示するには：
pm2 show my-app
PM2のレジストリからアプリを削除するには：
pm2 delete my-app
プロセスマネージャを使用した展開
プロセスマネージャは、通常、ノードjアプリケーションを配備するために本番環境で使用されます。プロセスマネージャの主な機能は、クラッシュした場合にサーバを再起動し、リソースの消費量をチェックし、実行時のパフォーマンスを改善し、監視するなどです。
ノード・コミュニティーによって作られた一般的なプロセス・マネージャーの一部は、永遠に、pm2などです。
Forvever
foreverは、指定されたスクリプトが継続的に実行されるようにするためのコマンドラインインターフェイスツールです。 foreverのシンプルなインターフェイスは、 Node.jsアプリケーションやスクリプトの小規模な展開を実行するのに理想的です。
foreverプロセスを監視し、クラッシュした場合はプロセスを再起動します。
世界中にforeverにインストールしてください。
$ npm install -g forever
アプリケーションを実行する：
$ forever start server.js
これはサーバを起動し、プロセスのIDを与える（0から始まる）。
アプリケーションを再起動する：
$ forever restart 0
ここで、 0はサーバーのIDです。
アプリケーションを停止：
$ forever stop 0
restartと同様に、 0はサーバーのIDです。永遠に与えられたidの代わりにプロセスIDやスクリプト名を与えることもできます。
その他のコマンド： https : //www.npmjs.com/package/forever
dev、qa、stagingなどの異なる環境に異なるプロパティ/設定を使用する
大規模なアプリケーションでは、異なる環境で動作させるときに異なるプロパティが必要になることがよくあります。 NodeJsアプリケーションに引数を渡し、特定の環境プロパティファイルをロードするためにノードプロセスで同じ引数を使用することで、これを実現できます。
異なる環境に2つのプロパティファイルがあるとします。
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" } }
アプリケーションの次のコードは、使用するそれぞれのプロパティファイルをエクスポートします。
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;
}
}
});
我々は、次のようにアプリケーションに引数を与えます
node app.js env=dev
私たちは同じくらい簡単として永遠にそれ以上のようなプロセス・マネージャを使用している場合、
forever start app.js env=dev
クラスタを活用する
Node.jsの単一のインスタンスは、単一のスレッドで実行されます。マルチコアシステムを利用するには、負荷を処理するNode.jsプロセスのクラスタを起動する必要があることがあります。
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');
}
