centosflask + uWSGI + nginxの展開

centosflask + uWSGI + nginxの展開

 

1.コンセプト

自身のウェブサーバをフラスコ - WERKZEUG、サイトを実行するサービスを構築することができます。しかし、開発中の、一般的にプロ--uWSGIと。

加えて、そこに多くの場合、nginxのと。

 

1.1。uWSGI

uWSGIは、アプリケーションサーバ（複数のプログラミング言語をサポートしています）、薬、プロセスマネージャ、モニターを実装してフルストップホスティングサービスです。それは最初のWSGI Python言語と認識されたためUWSGIが命名します。

WSGI：解析のpythonを実装するための共通のインターフェース/プロトコルは、汎用インタフェースの標準インターフェースプロトコルである、またはサーバープログラムとのpythonwebの相互作用の間に共通性を達成します。

それを使用して、簡単に別のウェブサーバ上に展開することができweb.pyまたはボトルやジャンゴなどpythonweb開発フレームワーク。

uwsgi：同様WSGIは、通信プロトコルであります

uwsgi uWSGIサーバプロトコルは、それがWSGIと比較され、情報伝送のタイプを定義する独自のプロトコルであり、二つのことです。

uWSGI：サーバ/ゲートウェイと呼ばれる一種またはpythonwebserver

uWSGI同様のtornadowebまたはFLUP、pythonwebserverは、uWSGIは、WebサーバーとWSGI uwsgi 2つのプロトコル、Web要求に応答する責任のpythonを達成することです。

などのApache、nginxの、ので、彼ら自身が、PHPの関数のような動的言語を解決しませんが、Apacheなど行うには、他のモジュールに割り当てられた内蔵のPHPモジュールと言うことができ、それは同じApacheのサポートは、PHPのように感じています。

uWSGIはWSGI契約、uwsgiプロトコル、HTTPおよびその他のプロトコルを実現しました。HttpUwsgiModule uWSGIでnginxの役割は、サーバーと交換されます。

uWSGIは、C言語で書かれ、パフォーマンスが比較的高いです。uWSGIは、次の4つの部分を含みます：

 

1.2。nginxの

 

nginxの効率的なWebサーバーとリバースプロキシサーバーは、負荷分散を使用することができ、それがセキュリティフィルタリング、アンチDDOS攻撃かもしれ（Nユーザーがサーバーにアクセスしたときに、シャントを達成することができ、サーバー上の圧力を緩和します）。Apacheのと比較すると、nginxのは、導入が簡単な百万のTCP接続、同時接続の10万レベル、少ないメモリ消費、低コストをサポートすることができ、高い同時実行をサポートしていますが、NginxはApacheのモジュールは豊富ではありません。

uwsgi契約のnginxのサポートuWSGIので、私たちはuWSGIプロセスにuwsgi_pass動的コンテンツによってNginxは、nginxのと組み合わせるuWSGIことができます。

 

1.3。なぜnginxのを使用します

uWSGIは、Webサーバとして機能することができますので、なぜuWSGI nginxのは、それを必要がありますか？

最も一般的な引数は、nginxの利点、静的ファイルのためのより良いパフォーマンスです。実際には、サイトが小さい場合には、静的ファイルに対処する必要がない、唯一のuWSGIも可能ですが、Nginxはこの層で、利点は非常に特異的であることができます。

サーバーは、IPスプーフィングであれば運用・保守のためにのみuWSGIは、その後、あなたはコードを変更する必要がある場合は、nginxの設定ファイルでブラックリストにIPを追加し、より便利です。

nginxのWebサーバーがベテランである一方、uWSGIは、例えばuWSGIは、以前のバージョンでは、HTTPSをサポートしていませんが、パフォーマンスで、より専門的なように見える、あなたはより安全nginxのを言うことができます。

nginxの機能は、負荷分散とHTTPキャッシングを行う能力である、複数のサーバー場合は、nginxのの基本は必須であり、nginxのことで、リソースが十分にパフォーマンスを向上させることができ、唯一のサーバー、別のサーバー・ノードに割り当てることができますnginxのは、動的なリソースのために、I / O用に最適化された、C言語で書かれているだけでなく、すべての後に、関数呼び出しがネイティブであるなどExpiresorEタグ、gzip圧縮のヘッダを静的リソースを扱うことができるので、 nginxのは、また、CDNの最適化（uWSGIこれは不可能である）で、キャッシング機能を実装することができます。など、効率的なようnginxのサポートのepoll / kqueueのネットワークライブラリは、uWSGIがハイに分からないの短い接続要求の同時高い性能比でうまく動作します。

あなたが複数のアプリケーションのPHP、Pythonとサーバホスト上で書かれた他の言語を実行する場合は、あなたがポート80でリッスンする必要があり、この時間nginxのは、必要なオプションです。我々は転送サービスを必要とするので。

だから、nginxのは、基本的には必須です。uWSGI自体がWebサービスをしているが、ここでもそれがリバースプロキシとしてnginxのnginxのの導入を置くことですので、他の人が、なぜ我々があるuWSGI、に転送されつつ、いくつかの写真は、JSおよびその他の静的なリソースは、nginxのとサービスを提供することができますこの展開アーキテクチャの究極の目標。

 

2.展開

2.1。システム環境

centos6.5

python3.6.5

1.10.3 nginxn

uwsgi 2.0.18

 

2.2。uWSGI

uWSGIは、PythonのWebコンテナによって実装され、より優れた互換性がようにpythonwebアプリケーションフレームワークジャンゴ、フラスコを公開することができます。基本的にuwsgiのpythonモジュールですので、それをインストールpipinstalluwsgi直接使用することができます。

インストールが完了した後Uwsgiは、適切なディレクトリにサーバーの設定ファイルを作成することができます。例えば、私はプロジェクトのルートディレクトリはuwsgiconfig.iniのファイルを作成します選択します。ちなみに、設定INI形式に加えて、JSONサポート、および構成のXML形式の他のさまざまなuwsgiします。ここでは、iniファイル形式へのたとえば。

 

2.2.1。設定

直接、次のようにコンフィギュレーション・ファイルを実行しているuwsgi：

[Uwsgi]

HTTP = 0.0.0.0:9000

CHDIR = /ホーム/ WEB_SERVER /フラスコ/ウェブサイト

WSGIファイル= run.py

呼び出し可能=アプリ

プロセス= 4

スレッド= 2

pidファイル= /home/web_server/flask/uwsgi.pid

デーモン化= /home/web_server/flask/server.log

 

パラメータは次のとおりです。

あなたは（uwsgiが運営実行、実際の変数の後に呼び出し可能与えられ、ポートのフラスコを実行する必要がもはやuwsgiが指定したポートを指定した後）

ソケット：ソケット通信ポート、外の世界へのインタフェースuWSGIサーバーを残す同等は、nginxのはと通信するための責任があるが、httpリクエストが成功した経由でノートソケットが直接アクセスすることはできません。

PYTHONPATH：プロジェクトディレクトリ。

呼び出し可能：アプリは=フラスコ（__ name__）だからここのアプリであり、一般的には、アプリケーション・プログラム内の変数名を、有効にします。

プロセス：プロセッサの数。

スレッド：スレッドの数。

プロセスやスレッドがサーバを起動uwsgi、サーバは複数の並列プロセスを開きます指摘した後、各プロセスが待機しているリクエストを処理するためのいくつかのスレッドを開き、明らかにこの数が小さすぎて、合理的ではないすべきであり、あまりにも多くの処理性能を行いますこれは、サーバー自体にあまり負担をもたらすでしょう。

統計：統計情報サービスのアドレスを取得するuwsgi

デーモン化：バックグラウンドで実行されているuWSGIプロセス、および指定されたログファイルまたはUDPサーバーをヒットしてログインします。

 

 

 

2.2.2。スタート/ストップ

uWSGIがxxx.ini起動ファイルで同じディレクトリにxxx.pidを生成します、ただ一つのラインがuWSGIのメインプロセスのプロセスIDであります。

開始uWSGI：

uwsgi --ini xxx.ini

 

uwsgiリブート：

uwsgi --reload xxx.pid

 

uwsgi停止：

uwsgi --stop xxx.pid

 

指定手動で生成されるPIDファイル

 

2.2.3。問題

 

閉じる問題

手動でpidファイルを指定した後、実際のプロセスは、-stopのみだけで殺すことができる残りの3つに記録されているプロセスのpidファイルを閉じるオフ使用して、4、一つだけのPID PIDを開始しました

バッチプロセスを強制終了させます。

pkillはuwsgi

pkillは-f uwsgi -9＃よりも一般的に少ないです

 

 

2.3。nginxの

2.3.1。インストール

yumをnginxのインストール

 

ビューのバージョン

nginxのバージョン：nginxの/ 1.10.3

 

2.3.2。設定

YUMのCentOSにインストールされている場合、プロファイルのパスは、一般的なプロファイル/etc/nginx/nginx.confを変化させます

設定ファイルを変更Nginx.confが、これは直接変更しないと、別の方法を使用する（推奨）

 

デフォルトのインストール設定ファイルをnginxのは、テール/etc/nginx/nginx.confを以下の

              /etc/nginx/conf.d/*.confが含まれます。

それはまた、他の設定ファイルを導入/etc/nginx/conf.d/フォルダの外部ディレクトリから、です。

そう、デフォルトの設定ファイルを変更しないことにより、プロファイルシステムの堅牢性を高め、/etc/nginx/conf.d/ディレクトリに新しいwebapp.confを追加します。

 

次のようにwebapp.confを読み取ります。

サーバー{

    9002を聞く; // Webアクセスポート

    サーバー名はlocalhost; //サーバ名

    文字セットUTF-8;

    access_logの/var/www/webapp/access.log; //サーバは、リクエストログを受け取り作成する必要がある場合があるディレクトリをログに記録し、それ以外の場合はnginxのエラー

    error_logに/var/www/webapp/error.log; //エラーログ

    100Mをclient_max_body_size。

    位置/ {

       uwsgi_paramsが含まれます。

       アドレスソケット内の同じ項目の// uwsgiニーズやプロファイル、または要求を受信uwsgi作ることはできません。127.0.0.1:9000 uwsgi_pass。

       #uwsgi_param UWSGI_PYHOMEは/ var / www /のWebアプリケーション/ Venv。

       uwsgi_param UWSGI_CHDIR /ホーム/ WEB_SERVER /フラスコ/ web_test; //ルートディレクトリプロジェクト

       #uwsgi_param UWSGI_SCRIPTラン：アプリは、メインプログラムのプロジェクトを開始//（ローカルで実行されています

                                 //メインプログラムはのフラスコ内に構築することができます

                                 //サーバー上のプロジェクトへのアクセス）、実際には、uwsgiで指定することができます

       }

 

    error_page 404 /404.html。

        位置= /40x.html {

        }

   

    error_page 500 502 503 504 /50x.html。

        位置= /50x.html {

        }

}

 

問題：

未知のディレクティブは、「聞く」に

コンフィギュレーションファイルのタブスペースは、通常のスペースに置き換えることができます。

 

2.3.3。スタート/ストップ

開始：nginxの-c /usr/local/nginx/conf/nginx.conf

 

停止：

閉じるnginxのアプローチ：

（1）コマンド

nginxのが起動すると、あなたはnginxののnginxの管理プロセス（つまり、マスター・プロセス）を制御するために「-s」パラメータを使用することができますことは、信号を送信しますnginxの-s信号を

これは、信号が次の値を指定できます。

  [1]停止：高速閉じます

  [2]終了：安全シャットダウンを

  [3]リロード：設定ファイルをリロード

  [4]再び開く：ログファイルを再度開き、主にログを切断するために使用

終了後、現在の要求で終了通知nginxのワーカープロセスを待ち、信号を終了し、このコマンドは、Linuxのアカウントのnginxの開始によって行うことができます。

nginxのリロード設定ファイルnginx.confを通知する信号をリロードしてください。設定ファイルへの変更は、リアルタイムではありません後に外のリロードを使用することに加えて、nginxのは、唯一のプロセスがすでに有効になりますnginxの上で実行され、起動時に設定ファイルをロードします。

このコマンドを実行すると、プロファイルは問題ありません場合は、マスター・プロセスは、（？問題のコンフィギュレーション・ファイルは、それを確認する方法下記参照）、コンフィギュレーション・ファイルを読み込むしようとします。

マスター・プロセスは、新しいコンフィギュレーション・ファイルを実行するために、新しいワーカープロセスを開始し、要求を処理し、現在のタスクを処理した後、新たな要求と終了を処理していない古いワーカープロセスに通知します。

設定ファイルに問題があるが実行できない場合は、マスター・プロセスは古い設定ファイルが作業を続けロールバックし、全体のプロセスは、nginxの異常終了につながることはありません。

Linuxのkillコマンドも、その後、同じ効果をリロードやめ123456を終了し、-s HUP 123456を殺し、以下の2つのコマンドの前に-s殺す、nginxののマスター・プロセスID（PID）123456であると仮定すると、同じ効果を得ることができます。

閉じるnginxのコマンド1：

nginxのはやめ-s

 

[3]構成をリロード

設定ファイルをリロード

（1）コマンド

nginxの-sリロード

 

2.4。UWSGI再構成

uwsgi構成は時に独立した動作と使用nginxのと同じではありません

プロフィール：uwsgi_nginx.ini

[Uwsgi]

ソケット=：9000

CHDIR = /ホーム/ WEB_SERVER /フラスコ/ウェブサイト

WSGIファイル= run.py

呼び出し可能=アプリ

プロセス= 4

スレッド= 2

pidファイル= /home/web_server/flask/uwsgi.pid

デーモン化= /home/web_server/flask/server.log

 

3.試験結果

3.1。uWSGI

nginxのは使用しないでください、直接実行uWSGI

uwsgi uwsgi_independent.ini

 

3.1.1。結果は

訪問のhttp：// IP：9000 /成功。

 

3.2。uWSGI + nginxの

あなたは絶対パスが現在のパスでのiniファイルで実行する必要が書いていない場合はまず、uwsgi開始

[ソフトフラスコ@ルート]＃uwsgi uwsgi_nginx.ini

 

nginxの開始

nginxの-c /etc/nginx/nginx.conf

 

3.2.1。結果は

訪問のhttp：// IP：9002 /成功。

注意：nginxのを構成するときに指定します。

 

 

4.付録

4.1。共通のコマンド

PS -ef | grepをuwsgi

uwsgi uwsgi.ini

uwsgi --stop uwsgi.pid

殺す-9