web-dev-qa-db-ja.com

簡単な展開と更新のためのNode.jsセットアップ

現在、CMSから提供されるコンテンツのリアルタイム更新を提供するnode.js/socket.ioアプリケーションでサポートされている顧客向けのWebサイト（ApacheのTYPO3）を開発しています。

これが最初のnode.jsプロジェクトであるため、「完璧なセットアップ」に関してはベストプラクティスがありませんので、展開テクニックの研究に時間を費やしました。

良いセットアップを達成するためのいくつかの質問が残っています：

  1. お客様は簡単に展開できます。これは非常に重要です。なぜなら、当社のウェブサイトは、豊富なウェブサイトを提供し、顧客によって管理されていないサーバーで実行されている「ライブ」TYPO3インストールに統合されるからです。遅いプロセス。

  2. 簡単に更新できます。前述したように、再起動の要求とサーバーの変更は遅いプロセスです。 gitを使用してライブインストールにプッシュされます。

展開

一般的なコンセンサス は、ノードアプリケーションをデプロイして実行し続けるためにforeverを使用するようです。 foreverをテストしましたが、npm install forever -g（グローバル）でインストールすると正常に動作するようです。ただし、これはライブ環境にグローバルにインストールするために外部からの支援が必要になるため、アプリケーションのnode_modulesディレクトリから実行することを希望しますが、そのための堅牢なラッパーを作成することはできません。

また、foreverは正常に機能しますが、手動で開始する必要があります。サーバーの起動時に開始され、実行を継続することを保証する最良の方法は何ですか？

  • 簡単なinit.dスクリプト？
  • ウォッチドッグラッパーを作成していますか？
  • foreverステータスをチェックするTYPO3スケジューラタスク？

迅速な開発/更新時に再起動

現在、プロジェクトの開発段階にあり、node.jsアプリケーションに変更を加えるたびに、nodeまたはforeverを手動で再起動します。これは機能しますが、理想からはほど遠いです。ファイルの変更をチェックし、変更が検出されるとnpmを再起動するいくつかの小さなnodeモジュールがあります。

誰でもこれらの経験がありますか？

更新：なぜクラスターを使用しないのですか？

クラスターモジュール は reload メカニズムを介して同様の機能を提供しますが、 Node 0.5 + では機能しません） 。 コアクラスターモジュール（ノード0.6 +） は、これらすべての機能を備えておらず、クラスター化のみを提供します。これは、 socket.ioでうまく動作しません =。少なくとも Redisを使用しない場合 （これは、お客様に別の前提条件サービスを強制できないため、これは問題です）。

-

明らかに、プロジェクトを顧客に引き渡す前に、更新リスタータとforeverを組み合わせた最も安定したソリューションを見つけようとしています。そして、誰もが実証済みの技術の組み合わせを生み出してくれることを本当に望んでいます。

node.jsdeploymentupdates
56
Rem.co

集められたすべての知識（ Julian Knight のおかげで大いに感謝します）と先週テストされた方法を組み合わせて、以下に説明する展開ソリューションに落ち着くことに決めました（私はいいと思った比較可能な質問で他の人を助けるために共有します）：

スクリプトエラーでの自動再起動andスクリプト変更時の自動再読み込みは forever 。node.jsスクリプト内からForeverが生成される限り、スクリプトウォッチも含まれます。

そのために、実際に実行したいserver.jsスクリプトを起動するapp.jsを追加しました。

server.js

var forever = require('forever'),
    child = new(forever.Monitor)('app.js', {
        'silent': false,
        'pidFile': 'pids/app.pid',
        'watch': true,
        'watchDirectory': '.',      // Top-level directory to watch from.
        'watchIgnoreDotFiles': true, // whether to ignore dot files
        'watchIgnorePatterns': [], // array of glob patterns to ignore, merged with contents of watchDirectory + '/.foreverignore' file
        'logFile': 'logs/forever.log', // Path to log output from forever process (when daemonized)
        'outFile': 'logs/forever.out', // Path to log output from child stdout
        'errFile': 'logs/forever.err'
    });
child.start();
forever.startServer(child);

これにより、アプリケーションディレクトリ内のすべてのファイルの変更が監視され、foreverで実行されているスクリプトが変更されるとすぐに再起動します。ログとpidfileはアプリケーションのサブディレクトリにあるため、ファイル監視から無視する必要があります。無視すると、スクリプトが再起動をループします。

。foreverignore

pids/**
logs/**

これをすべてシステムブートで開始し、start node-appおよびstop node-appを使用してサービスを簡単に制御できるようにするには、 buntu's Upstart を使用します。 2つの例（ this および this one）を組み合わせて、非常にうまく機能する例を示しました。

/ etc/init/node-app.conf

# This is an upstart (http://upstart.ubuntu.com/) script
# to run the node.js server on system boot and make it
# manageable with commands such as
# 'start node-app' and 'stop node-app'
#
# This script is to be placed in /etc/init to work with upstart.
#
# Internally the 'initctl' command is used to manage:
# initctl help
# initctl status node-app
# initctl reload node-app
# initctl start node-app

description "node.js forever server for node-app"
author      "Remco Overdijk <[email protected]>"
version "1.0"

expect fork

# used to be: start on startup
# until we found some mounts weren't ready yet while booting:

start on started mountall
stop on shutdown

# Automatically Respawn:
respawn
respawn limit 99 5

env HOME=/home/user/node-app-dir

script
    # Not sure why $HOME is needed, but we found that it is:
    export HOME=$HOME
    chdir $HOME
    exec /usr/local/bin/node server.js > logs/node.log &
end script

#post-start script
#   # Optionally put a script here that will notifiy you node has (re)started
#   # /root/bin/hoptoad.sh "node.js has started!"
#end script

ケビンは賢明に彼の記事で言及しています rootとしてノードを実行するのは賢明ではないので、来週新しいサーバーに移動するときにそれをexec Sudo -u www-data /usr/local/bin/nodeに変更します。

したがって、foreverはupstartによって起動されるnode server.jsによって自動的に開始され、クラッシュやファイルの変更を監視し、セットアップ全体を必要な限り実行し続けます。

これが誰にも役立つことを願っています。

63
Rem.co

私の最後の答えは未来のためですから！その他のリンクは次のとおりです。

まだ完璧な答えはないようですが、実動Nodeインスタンスを実行している人がたくさんいます。うまくいけば、これが正しい方向を指し示してくれることを願っています。

7
Julian Knight

実稼働で使用する場合は、 Cluster のようなものを見る方が良いかもしれません。クラスター機能は必要ないかもしれませんが、ゼロダウンタイム再起動、ロギング、ワーカーなどの他の本番機能も含まれています。

おっしゃるように、Foreverはテストには問題ありませんが、実際の運用に必要なものはありません。

Clusterまたは類似のものがNodeそれ自体にv0.7が採用される可能性があることを漠然と覚えているようです。

5
Julian Knight