実稼働Node.jsサーバーのデプロイ
Node.jsアプリを作成しましたが、実稼働マシンの1つで実行できるようにしたいと考えています。これは非常に一般的な要求のようですが、適切な解決策が見つかりません。実稼働Node.jsアプリをデプロイするための確立されたソリューションはありませんか？
アプリはシンプル（100 LOC未満）ですが、非常に効率的で信頼性が高く、再起動せずに何年も継続して実行できる必要があります。大規模なサイトで、1秒あたり数十の接続で実行されます。 （アプリはWebサーバーとして使用されず、JSON APIのみがあります）
ここに私が検討したアプローチがありますが、まだよくわかりません：
フレームワーク（Expressなど）を使用
アプリは高性能である必要があり、非常にシンプルであるため、フレームワークの形で膨張を追加することは避けたいものです。
Nohupを使用したサーバーの起動
ここでの主な問題は例外処理にあり、例外のためにサーバー全体がクラッシュすることは望ましくありません。私が理解していることから、Javascriptインタープリターは例外後に予測不可能な状態のままになるため、try {} catch {}ループでアプリ全体をラップしても役に立ちません。あれは正しいですか？
Foreverのようなものを使用
私たちのFreeBSDマシンにForeverをインストールしましたが、非常にバグが多かったです。永遠に殺せない無限のプロセスを生み出してしまいました。マシンを元に戻すにはkill -9を実行する必要がありましたが、Foreverで実稼働アプリケーションを実行することにあまり自信がありません。また、Upstart（同様のツールですが、より一般的なツール）はFreeBSDでは実行されないようです。
ホスト型ソリューション（Heroku、Rackspace、Amazon EC2など）
これはおそらく最も簡単なソリューションですが、他のWebサーバー用の本格的なハードウェアを既に持っています。経済的な考慮のために、それは意味をなしません。
確かにこれに対する何らかの確立された解決策がなければなりませんか？何か不足していますか？
- セッション、Cookie、ミドルウェアなどを自分で処理する場合を除き、フレームワークを実際に使用する必要があります（戦闘テスト済みなのでExpressのようなものをお勧めします）。 Expressは本当に軽いです。
- Nohupを使用してサーバーを起動します。通常は「node」コマンドを使用して起動します。 Expressはルートをtry-catchでラップするため、サーバーがルートでクラッシュすることはありません。ただし、サーバーに深刻な問題がある場合、再起動を恐れる必要はありません（少なくとも2〜3個のプロセスがある場合、1つだけが死ぬため、少なくとも1〜2が残り、ユーザーは ' tものを感じる）。
- 監視のために、私は個人的に pstart や Monit のようなOSレベルのものを好みます。
- ホスティングソリューション：既に深刻なハードウェアを所有しているため、他の何かにお金を投資する必要はありません。ロードバランサー（おそらくnginxまたはnode-http-proxy）を使用して、ものをプロキシします。
Hosting Node Apps を参照してください。
このチュートリアルでは、サーバー側のJavaScriptアプリケーション用にnode.jsアプリをホストできるサーバーをセットアップする方法を説明します。現在、node.jsホスティングオプションは、Webサーバーと通信する実行中のノードデーモンプロセスに要約されています。ほとんどのWebサーバーは別のポートへの接続をプロキシできるため、Apacheまたはnginxを使用してこれを行うことができます。
ここには3つの質問があります。
質問0：「ノードアプリにフレームワークを使用する必要がありますか？」
質問1：「実稼働マシンでノードサーバーを実行するにはどうすればよいですか？」
質問2：「ノードアプリを運用環境に展開する方法」。
質問1では、私は本当に クラスター が好きです（ただし、最新のNodeバージョンにはそのようなものがありますで、チェックアウトするかもしれません）。 Monit/UpstartのようなものでOSレベルのイベントを監視し、サーバーが正常に動作していることを確認することに成功しました。 （これは、Ruby ThinサーバーのN個のクラスターを監視していましたが、同じことです）。
トラフィックに応じて、複数のマシンでクラスターを実行し、その前にロードバランサーを配置することができます。これは、トラフィック、リクエストの完了に要する時間/イベントループをブロックする時間、およびマシンごとに起動するプロセッサ/ノードインスタンスの数に依存します。
フレームワークを使用すると、エラー処理が改善され、通常のnode.jsアプリを終了するエラーをキャッチできます。フレームワークなしでそれを行う場合、node.jsのエラー処理を必ず読んでください。
Question 2については、ノードコミュニティにまだ適切なデプロイ標準がないと思います。 RubyのCapistranoツールを使用してみてください（そして、ここに Capinstranoを使用したクラスターのデプロイに関するブログエントリ ）。
Capistranoの悪い点は、それが真実ではないかもしれないという仮定を立てていることです（つまり、Railsプロジェクトを展開している）。
私のgoto展開ソリューションは、一般的にPythonの Fabric ツールであり、展開ツールを提供し、必要なことを実行できます。
もう1つの展開オプションは「クラウド」で、 Nodester のようなものを使用します。
Pm2を使用してみてください。シンプルで直感的なCLIで、NPMからインストールできます。 PM2でアプリケーションを開始するだけで、アプリケーションは大量のトラフィックを処理する準備が整います。
ServerFaultでより良い答えが得られるかもしれませんが、 1人のユーザーの経験 を使用して supervisord の説明があります。何らかのプロセス監視を使用してnodeプロセスを存続させる必要がありますが、別の一般的な推奨事項は、何らかの方法でnodeプロセスへの接続をリバースプロキシすることです。私はおそらくnginx（この方法でnginxがロギング、認証、または何らかの方法でノードにベイクするのではなく、必要な他の高レベルHTTP機能を処理できるようにする）に投票します。しかし、前述の記事では、あちこちのコメントでhaproxyに言及していますが、これはより軽量かもしれません。リバースプロキシの選択は、おそらくWebSocketサポートが必要かどうかに大きく依存します。
ノードにこれ以上の「標準」ワークフローが存在するかどうかはまだわかりません。 Railsのようなものほど成熟していないため、webappを実行し続けるための無数の方法があります。
Cloudkickのスタッフはこれに対する優れたソリューションを作成しました。 Cast、 http://cast-project.org/ と呼ばれます。
サーバーとワークステーションにキャストをインストールします。サーバー上でcast-agentを起動し、サーバーでインスタンスをキャストするようワークステーションに署名させます。その後、「バンドル」を作成し、それらをサーバーにアップロードし、それらから作成/アップグレード/破棄したり、インスタンスを起動/停止したりできます。 Castがクラッシュすると、サービスは自動的に再起動します。また、stdout/strerrをリモートで追跡し、実行中のインスタンスとPID＃のリストを取得し、ワークステーションからインスタンス/サーバーを管理することもできます（SSHは不要です）。ドキュメントは少し古くなっていますが、結果は少し余分な作業をする価値があります。すべての対話/コマンドは、HTTPSおよびRESTful APIを介して行われます。
これに先立ち、私はすべてのアップグレードをSCP/SSHで手作業で行っていました。 superviseを維持しています。振り返っていない。