NodeJSとDjangoが連携したアプリケーション開発(4)――展開

シリーズ

NodeJSとDjangoが共同で開発した(0)node.js基礎知識

NodeJSとDjangoが共同で開発した(1)原型構築

NodeJSとDjangoが連携したアプリケーション開発(2)業務フレームワーク

NodeJSとDjangoの共同アプリケーション開発(3)テストと最適化

NodeJSとDjangoの共同アプリケーション開発(4)の展開

はい、やっと最終的な部署に着きました.サービスが正式にオンラインになる前に、まだいくつかの仕事があります.この中にドメイン名、nginx配置、ドメインを越えて設定して守るプロセスが含まれています.
ドメイン名
ドメイン名は必然的にあります.これはみんなが知っています.同じように真実のipをinxサーバーの後ろに隠します.分散型のnodeサービスに対して、複数の二級ドメインを使用するか、それとも経路によって区別されるかは別に問題ないです.パスでより柔軟に区別できるかもしれません.これは実際の応用シーンによって異なります.
NRBC
inxでは明らかに新しいドメイン名の構成が必要です.websocketアプリケーションに対して、inxの構成は少し違っています.通常の構成はこうです.

location / {
    proxy_set_header Host $host;
    proxy_set_header REMOTE_ADDR $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://node.yourdomain.com;
}

しかし、websocketデータを転送するには、追加の数行が必要です.

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_redirect off;

ドメインをまたぐ設定
私達は簡単に私達のサーバーをネットに露出することができませんので、ドメインをまたぐ設定が必要です.ただし、二級ドメイン名であっても、socketioはマスタ局からの要請を拒否します.幸いなことに、socketio自体はクロスドメインオプションを設定することができます.

var io = sio.listen(server, {
    log: true,
    origins:'http://yourdomain.com:* ',
});

origgins項目を設定すれば、ドメイン名からの要求を許可することができます.ローカルテストは使わなくてもいいです.オンラインしたら忘れないでください.
デーモンセット
一般的なオススメはforeverでnodejsを守るプロセスです.

LOG=/tmp/node.process.log
PID=/tmp/node/forever.pid
APP_PATH=/your/path/to/node
APP=$APP_PATH/app.js
ACCESS_LOG = $LOG/access.log
ERROR_LOG = $LOG/error.log
OUT_LOG = $LOG/out.log

mkdir $LOG -p
echo ===================start forever====================
forever -p $APP_PATH -l $ACCESS_LOG -e $ERROR_LOG -o $OUT_LOG -a --pidFile $PID start $APP

設定と使用は非常に簡単で、残りの内容は文書を見ることができます.ここでは詳しく説明しません.
これまでのシリーズのすべての内容を説明しましたが、全体としてはnode.jsとdjangoの共同使用のポイントは通信システムにあります.これ以外は通常のウェブserverの開発です.ここを見て、皆さんに啓発できると思います.