サーバーにnginx + mod_wsgiをデプロイします

こんにちは。 長い間、私は素晴らしいdjangoフレームワークをよく見て、本を読んで、記事を読んで、ハローワールドを書き込もうとしました（jungに組み込まれたサーバーは簡単で快適でした）。 そして昨日、私は最初から最後まで戦闘サーバーを構成しようとしましたが、判明したように、それはそれほど単純ではなく、私が若くて経験の浅い場合、私はこの問題について吐き出したとさえ思えました。 それで、私は読者に完全な指示を共有し、いくつかの推論と設定を提供することにしました。 この記事は初心者を対象としていますが、誰にとっても興味深いものになると私は約束します。

なぜwsgiとnginxですか？

これにはいくつかの理由があります。 まず、解決策は高速で、メモリをほとんど消費せず、持続可能でなければなりません。 Nginxはそのように作成されました。 さらに、 パフォーマンス テストによると、nginx + wsgiバンドルは、メモリ消費量が少なく、高負荷下での高いフォールトトレランスを提供します。 第二に、システムが単純であるほど、信頼性が高いことが知られています。 wsgiとfastcgiを比較すると、後者については、アプリケーション自体が実行される別個のサーバーであると言えます。 誰かがこのサーバーがクラッシュしないことを確認する必要があります。 一方、wsgiはCのアプリケーション（nginx）からのpythonスクリプトの呼び出しであるため、インターフェイスを構成したら、エンティティの数を半分にして、Webサーバーとのみ通信します。



さらに、理論的には単にwsgiがエンドユーザーの方が高速であるという仮定がありますが、理論的には50人のユーザーが同時にサーバーに接続し、同様に重いページを要求したとします。 fastcgiの場合、nginxはすぐにfastcgiサーバーに50リクエストを行い、応答を待ちます。 純粋に理論的には、同時に到着した同じリクエストが実行中のアプリケーションを大量に生成し、プロセッサ時間を均等に競い、すべてが一度に実行されます（実行中のfastcgiアプリケーションの数に制限がない場合）。 Nginxはwsgi自体に届いたリクエストを処理し、同時リクエストの最大数はワーカーの数に等しいため、それらはキューに入れられ、ユーザーはほとんどすぐに最初の回答を受け取ります。 しかし、後者はfastcgiの場合と同じ時期に来ます。行き先はありません。

理論から実践へ

最も退屈な部分は、nginxを収集します。 mod_wsgiを接続する他の方法がないため、アセンブルする必要があります。そのため、最新の安定バージョン（現在は0.7.60 ）をIgor Sysoevのサイトから引き出して、どこかに展開します。

mod_wsgiの公式ページは、私が理解しているとおり、 ここにあります 。 そして、これは主な失望が私たちに降りかかる場所です-プロジェクトは1年以上更新されていません。 nginxの現在のバージョンとの互換性のためにソースを少し修正する必要がありますが、何も、主なことはすべてが開始する必要があるということです。 モジュールの最新バージョンをダウンロードし、Indixの近くのどこかに展開します。



正確に編集する必要があるもの：

1）mod_wsgiを使用したアーカイブのpatchフォルダーには、configとngx_http_wsgi_module.cにパッチを当てるパッチnginx-0.6.x.patchがあります。終わりは無視できますが、必要ありません。

2）mod_wsgiの最後の更新があったとき、Enginixの現在のバージョンはまだではなかったので、公式パッチでは十分ではありません。 他のコンパイルエラーを検索した結果、 このサイトにたどり着きました 。 日本語はわかりませんが、必須ではありませんでした。ページに必要なパッチがあります。 確かに、このパッチの行番号はソースの行番号と一致しなかったため、手動で編集する必要がありました。



src / ngx_http_wsgi_module.cファイルで、ファイルの先頭に近い構造を宣言します。



static ngx_path_init_t ngx_http_wsgi_temp_path = {

ngx_string(NGX_HTTP_WSGI_TEMP_PATH), { 1, 2, 0 }

};







同じ場所で、ngx_garbage_collector_temp_handler関数の最初の呼び出しはNULLに置き換えられます。



関数呼び出し



ngx_conf_merge_path_value(conf->temp_path,

prev->temp_path,

NGX_HTTP_WSGI_TEMP_PATH, 1, 2, 0,

ngx_garbage_collector_temp_handler, cf);





に変更

ngx_conf_merge_path_value(cf, &conf->temp_path,

prev->temp_path,

&ngx_http_wsgi_temp_path);







今後は、mod_wsgiソースに戻って修正する必要があると言いますが、原則として、すでにアセンブリの準備ができています。



Enginixソースがあるディレクトリに移動して実行します

./configure --add-module = / path / to / mod_wsgi /



ここに小さなプラグがありました。 実際のところ、http_cacheモジュールはindinixで提供され始めてから、openSSLを要求し始めました。 私は長い間openssl-devパッケージを検索し、このモジュールなしでビルドしたかったのですが、パッケージが見つかり、単にssl-devと呼ばれました。 ところで、エラーの説明にエラーがあります。http_cacheを無効にするパラメーターは「--without-http_cache」ではなく、「-without-http-cache」です。



ここで、make＆make installを行いました。

Nginx設定

nginx.confで最初に修正する必要があるのは、ワーカーの数です。 通常、最適なワーカー数はマシンのコア数に等しいと聞いたことがあるでしょう。 mod_wsgiを使用すると、状況は少し変わります。 実際、アプリケーションはこれらの同じワーカーのコンテキストで動作するため、同時に実行されるプロセスの数はワーカーの数に等しくなります。 理想的な条件下では、コアの数で見たワーカーの数がプロセッサーに正確に100％をロードします。 しかし、条件は完全ではなく、アプリケーションの実行は時々中断されます。 たとえば、データベースサーバーが別のマシン上にある場合、ディスク操作の実行時またはデータベースのクエリ時。 したがって、最適なワーカー数はコア数の2倍に等しいように思えます。



次に、サーバー内の場所を構成します。

mod_wsgiの例で提案されているように行う場合：



location / {

wsgi_pass /path/to/nginx/django.py;

}





次に、同じサーバーでの静的処理にさよならを言うことができます。 一般的な解決策は、一般的なファイルタイプに規則性を設定し、それらをファイルとして提供し、残りをバックエンドにダンプすることです。 しかし、私はこのオプションが好きではありません。 最初に、サーバー上にない画像を要求すると、標準のEnginixメッセージが表示されます。次に、自動生成されたpdfファイルを提供する必要がある場合はどうなりますか？ 彼はまた、pdfの拡張子を持っていることをお勧めします。 したがって、私は私のオプションを提案します：すべてのパスが最初にディスク上で検索され、そのようなファイルが見つからない場合は、ページの後ろからバックエンドに移動します（そして何も見つからない場合は、サーバーではなくアプリケーションからページ404があります）。



location / {

root /path/to/www/;

error_page 404 = @backend;

log_not_found off;

}

location = / {

#

wsgi_pass /path/to/nginx/django.py;

include wsgi_params;

}

location @backend {

wsgi_pass /path/to/nginx/django.py;

include wsgi_params;

}







また、作成する必要がある2つのファイルを使用します。



ここから wsgi_paramsを取得します 。



wsgi_var REQUEST_METHOD $request_method;

wsgi_var QUERY_STRING $query_string;



wsgi_var CONTENT_TYPE $content_type;

wsgi_var CONTENT_LENGTH $content_length;



wsgi_var SERVER_NAME $server_name;

wsgi_var SERVER_PORT $server_port;



wsgi_var SERVER_PROTOCOL $server_protocol;



wsgi_var REQUEST_URI $request_uri;

wsgi_var DOCUMENT_URI $document_uri;

wsgi_var DOCUMENT_ROOT $document_root;



wsgi_var SERVER_SOFTWARE $nginx_version;



wsgi_var REMOTE_ADDR $remote_addr;

wsgi_var REMOTE_PORT $remote_port;

wsgi_var SERVER_ADDR $server_addr;



wsgi_var REMOTE_USER $remote_user;







そして、公式のdjango.pyドキュメントから：



import os, sys

# ,

sys.path.append('/path/to/')

#

os.environ['DJANGO_SETTINGS_MODULE'] = 'project.settings'

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()







DJANGO_SETTINGS_MODULEがファイル名ではなく、モジュール名を示すことに注意してください。 特定の例では、構成ファイルの実際の場所は「/path/to/project/settings.py」である必要があります

ビッグバンマー

何も見逃していない場合は、すべてがEnginixを起動する準備ができているはずです。 ブラウザを起動し、http：// localhost /（またはそこにあるもの）に移動し、プロジェクトが新しい場合（私のものの場合）、またはメインページ（既に記述されている場合）のdzhangaのウェルカムページを表示します。 正直なところ、最大の困難は背後にあるとすでに思っていましたが、そこにはありませんでした。 http：// localhost / 1（またはルート以外のURL）を入力するとすぐに、500番目のEnginixを取得しました。 これは、500番目のdzhangiよりも悪いことは明らかです。 負の2番目の引数（文字列の長さ）がPyString_FromStringAndSize関数に渡されたことを示すエントリがログに表示されました。

ソースを逆アセンブルした後、私はモジュールがpath_info行の先頭から場所の名前をURLが取得したハンドラーに削除しようとしているという結論に至りました。 つまり この場合、すべてのページがロケーションバックエンドに分類され、モジュールがpath_infoから減算しようとするのは正確には8文字であり、単純にそれほど多くはありません。 URLに非常に多くの文字が含まれる場合、最初からパスが切り捨てられました。 httrの代わりに：// localhost / 123456789受信httr：// localhost89

コメントにはTODOの「clcf-> nameがr-> uriにあることを確認する必要があります」、つまり 「URL文字列にこの場所の名前があるかどうかを確認する必要があります。

原則として、これが行われた理由を理解しています。たとえば、



location /django {

wsgi_pass …

}







http：// localhost / django / foo / bar /という形式のURLは、jungaからhttp：// localhost / foo / bar /にブロードキャストされます。 しかし、著者がなぜurlが一般的な正規表現およびリンクである可能性があることを考慮していないのかは明らかではありません（この場合のように）。 特に必要な場合は、includesを使用してurls.pyを書き換えることにより、djangoで実行できるため、このようなバグのある機能は必要ないと判断しました。



一般に、 ngx_wsgi_run.cの 584行目を修正する必要があります。



if (clcf->name.len == 1 && clcf->name.data[0] == '/') {





if (1 || (clcf->name.len == 1 && clcf->name.data[0] == '/')) {







動作中のEnginixを消滅させた後、再度make＆make installを実行します。

サーバーの再起動

Pythonはphpではありません。 ダウンロードされたアプリケーションは、ソースから分離され、その変更については何も知りません。 したがって、コードを更新するときは、時々Enginixを再起動する必要があります。 幸い、Enginixは非常に優れたサーバーです。すべてのクライアントを切断して、それを強制終了して再度実行するスクリプトを記述する必要はありません。 これは、サービスを提供しているクライアントを即座に切断することなく、ワーカーをソフトに再起動する機能を提供します。 これは、HUPシグナルをホストプロセスに送信することで実行できます。 したがって、私たちがする必要があるのは、単純なスクリプトを書いて、それに名前を付け、例えばrestart-serverを書くことです：



sudo kill -HUP `cat /usr/local/nginx/logs/nginx.pid`







このスクリプトを実行するたびに、アプリケーションが再起動します。 さらに、1時間に1回など、このスクリプトを冠に掛けることを強くお勧めします。 これはパフォーマンスに大きな影響を与えませんが、スクリプトが流れ始めればメモリを節約できます。

軟膏で飛ぶ

残念ながら、結果のサーバーにはアキレス腱があります。 10人が何らかの種類のブレーキページを同時にロードすることを決めた場合（pdf生成またはアバターのピンチなど）、あなたが10人の労働者しかいない場合、他の要求はありません（たとえば、gif画像などの最も軽いものも処理されます）少なくとも1人の労働者は無料ではありません。 残念ながら、他の通信方法をテストしませんでした。fastcgiまたはhttp_passを使用した場合と同じ効果が得られる可能性がありますが、別のTCP接続が使用されているため、このように動作しないようです。 しかし、私が言ったように、Enginixは素晴らしいサーバーだからです。 彼はリクエストを重いものと軽いものに分けます。キューに重いリクエストがたくさんある場合でも、少なくとも1人のワーカーを解放すると、最初にすべての軽いリクエストを吐き出し、そのあとで重いリクエストを受け入れます。 言い換えれば、軽いリクエストは、受け取った順番に関係なく、常に重いリクエストよりも優先度が高くなります。