序章


Python Webサーバーの比較の記事で紹介したように、uWSGIは広大なプロジェクトであり、Webアプリケーションだけを提供する以上のことができます。 ただし、その幅広い機能と、比較的簡単な構成を組み合わせることで、特にNginxと組み合わせた場合に、多くの展開ニーズに最適です。

このDigitalOceanの記事では、uWSGIについて詳しく説明し、サーバーをインストールするだけでなく、さまざまなフレームワークに基づいてPythonアプリケーションを実際にデプロイするために必要な手順を説明し、小規模、中規模、さらには比較的大規模なもののすべての重要な手順をカバーします。製造。

また、NginxとuWSGIは相互に連携するようにネイティブに構築されており、ほとんどのデプロイメントに最適なスタックを形成するため、このセットアップでNginxを使用する方法(およびその理由)についても説明します。

用語集


1. uWSGIを理解してNginxを使用する


  1. uWSGIの概要
  2. Nginxを使用したWebアプリケーションのデプロイ
  3. uWSGIでリバースプロキシとしてNginxを使用する

2. 生産のための液滴の準備


  1. デフォルトのオペレーティングシステムを更新する
  2. Python、pip、virtualenvのセットアップ
  3. 仮想(Python)環境の作成
  4. uWSGIのダウンロードとインストール
  5. Nginxのダウンロードとインストール

3. uWSGIを使用したPythonWSGIアプリケーションの提供


  1. WSGI
  2. WSGIアプリケーションオブジェクト(呼び出し可能):wsgi.py
  3. サーバーの実行
  4. uWSGIの構成
  5. uWSGIの一般的な構成
  6. シグナルを使用したuWSGIサーバーとプロセスの管理

4. Nginxの構成

5. uWSGIの構成

6. 本番サーバーに関するその他のヒント、提案、およびセットアップ

uWSGIを理解してNginxを使用する


uWSGIは野心的なプロジェクトです。 そのツールセットを使用すると、単にWebアプリケーションをホストするだけではありません。 それは非常にうまく機能し、そのようなパフォーマンスの高い方法であるため、アプリケーションの展開に関しては、長年にわたって多くのシステム管理者と開発者にとって不可欠なツールであることが証明されています。

Nginx、バージョン0.8.40以降、 uwsgiプロトコル(uWSGI独自)がサポートされています。 これにより、 uWSGI で実行されているWSGIアプリケーションが、Nginxと可能な限り最良の方法で通信できるようになります。 これがあなたにとって意味することは、非常に柔軟で(そして機能的で)、それに伴う多くの内部最適化の恩恵を受ける、非常に簡単に構成できる展開の可能性です。 全体として、これにより、uWSGIとNginxを組み合わせることで、多くの展開シナリオに最適な選択肢になります。

uWSGIの概要


以下は、上記のDigitalOceanPythonサーバー比較の記事からの抜粋です。

「非常に紛らわしい命名規則にもかかわらず、uWSGI自体は、ホスティングサービスを構築するための完全なソフトウェアスタックを提供することを目的とした、多くのコンポーネントを備えた広大なプロジェクトです。 これらのコンポーネントの1つであるuWSGIサーバーは、PythonWSGIアプリケーションを実行します。 SCGIとほぼ同一の独自のuwsgiワイヤプロトコルを含むさまざまなプロトコルを使用できます。 アプリケーションサーバーの前でスタンドアロンHTTPサーバーを使用するという理解できる要求を満たすために、NGINXおよびCherokee Webサーバーはモジュール化されており、uWSGIの[独自の]最高のパフォーマンスを発揮するuwsgiプロトコルをサポートしてプロセスを直接制御します。」

uWSGIのハイライト

  • uWSGIにはWSGIアダプターが付属しており、WSGIで実行されるPythonアプリケーションを完全にサポートします。

  • libpythonとリンクします。 起動時にアプリケーションコードをロードし、Pythonインタープリターのように機能します。 着信リクエストを解析し、Python呼び出し可能オブジェクトを呼び出します。

  • 人気のあるNGINXWebサーバー(Cherokee +およびlighttpdとともに)を直接サポートします。

  • Cで書かれています。

  • そのさまざまなコンポーネントは、アプリケーションの実行よりもはるかに多くのことを実行できます。これは、拡張に便利な場合があります。

  • 現在(2013年後半現在)、積極的に開発されており、リリースサイクルが高速です。

  • アプリケーションを実行するためのさまざまなエンジンがあります(非同期および同期)。

  • これは、実行するメモリフットプリントが低くなることを意味します。

Nginxを使用したWebアプリケーションのデプロイ


Nginxは、非常に高性能なWebサーバー/(リバース)プロキシです。 軽量で、操作が比較的簡単で、拡張も簡単なため(アドオン/プラグインを使用)、人気を博しています。 そのアーキテクチャのおかげで、多くのリクエスト(実質的に無制限)を処理できます。これは、アプリケーションやWebサイトの負荷によっては、他の古い代替手段を使用して対処するのが非常に難しい場合があります。

覚えておいてください:接続を「処理する」とは、技術的には、接続を削除せず、何かでサービスを提供できることを意味します。 Nginxがエラーメッセージではないクライアントの応答を提供するためには、アプリケーションとデータベースが正常に機能している必要があります。

uWSGIでリバースプロキシとしてNginxを使用する


多くのフレームワークとアプリケーションサーバーは静的ファイルを提供できます(例: javascript、css、imagesなど)と実際のアプリケーションからの応答。 ただし、より良い方法は、Nginxなどの(リバースプロキシ)サーバーに、これらのファイルの提供と接続の管理(リクエスト)のタスクを処理させることです。 これにより、アプリケーションサーバーからの負荷が大幅に軽減され、全体的なパフォーマンスが大幅に向上します。

アプリケーションが成長するにつれて、アプリケーションを最適化し、必要に応じてサーバー(VPS)に分散して、より多くの接続を同時に処理し、一般的により堅牢なアーキテクチャーを実現できるようにします。 アプリケーションサーバーの前にリバースプロキシを配置すると、最初からこれを行うのに役立ちます。

Nginxの拡張性(例: フェイルオーバーやその他のメカニズムを備えたネイティブキャッシングも、(より単純な)アプリケーションサーバーとは異なり、Webアプリケーションにメリットをもたらす素晴らしい偉業です。

基本的なサーバーアーキテクチャの例:

Client Request ----> Nginx (Reverse-Proxy)
                        |
                       /|\                           
                      | | `-> App. Server I.   127.0.0.1:8081
                      |  `--> App. Server II.  127.0.0.1:8082
                       `----> App. Server III. 127.0.0.1:8083

注:アプリケーションが127.0.0.1で着信接続をリッスンするように設定されている場合、ローカルでのみアクセスできます。 ただし、0.0.0.0を使用すると、外部からの接続も受け入れます。

生産のための液滴の準備


このセクションでは、仮想サーバーを本番環境に向けて準備します(つまり、 アプリケーションをデプロイするため)。

まず始めます:

  • デフォルトのオペレーティングシステムを更新する

  • 一般的なPythonツールのダウンロードとインストール(つまり pip、virtualenv)

  • アプリケーションを含む仮想環境の作成(uWSGIなどの依存関係が存在する環境)

注:ここに記載されている手順は簡潔にしています。 詳細については、pipおよびvirtualenvに関するハウツー記事をご覧ください:一般的なPythonツール:virtualenvの使用、Pipでのインストール、パッケージの管理

デフォルトのオペレーティングシステムを更新する


注:最新バージョンのオペレーティングシステムを使用して、新しいVPSで次のセットアップと準備を実行します。 理論的には、サーバーでそれらを試すのに問題はないはずです。 ただし、すでに積極的に使用している場合は、試す前に新しいシステムに切り替えることを強くお勧めします。

デフォルトアプリケーションの最新バージョンを確実に入手するには、システムを更新する必要があります。

Debianベースのシステムの場合(つまり Ubuntu、Debian)、以下を実行します:

aptitude    update
aptitude -y upgrade

RHELベースのシステムの場合(つまり CentOS)、以下を実行します:

yum -y update

Python、pip、virtualenvのセットアップ


CentOS / RHELユーザーへの注意:

CentOS / RHEL は、デフォルトで、非常に無駄のないサーバーとして提供されます。 そのツールセットは、ニーズに合わせて古くなっている可能性がありますが、アプリケーションを実行するためではなく、サーバーのシステムツールを強化するためにあります(例: YUM)。

CentOSシステムを準備するには、Pythonをセットアップする必要があります(つまり、 ソースからコンパイル)および pip / virtualenv は、そのインタープリターを使用してインストールする必要があります。

CentOS6.4および5.8でPython2.7.6および3.3.3をセットアップする方法、pipおよびvirtualenvについては、Python2.7.6および3.3をセットアップする方法を参照してください。 CentOSでは3。

UbuntuおよびDebianでは、使用できるPythonインタープリターの最新バージョンがデフォルトで提供されます。 インストールする追加パッケージの数は限られています。

  • python-dev(開発ツール)

  • pip(パッケージを管理するため)

  • virtualenv(分離された仮想環境を作成するため)

python-dev:

python-dev は、Pythonモジュールを構築するための拡張開発ツールを含むオペレーティングシステムレベルのパッケージです。

次のコマンドを実行して、aptitudeを使用してpython-devをインストールします。

aptitude install python-dev

ピップ:

pip は、必要なアプリケーションパッケージのインストールを支援するパッケージマネージャーです。

次のコマンドを実行してpipをインストールします。

curl https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py | python -
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python -
export PATH="/usr/local/bin:$PATH"

sudo権限が必要になる場合があります。

virtualenv:

Pythonアプリケーションをそのすべての依存関係とともに独自の環境内に含めるのが最善です。 環境は、(簡単に言えば)すべてが存在する孤立した場所(ディレクトリ)として最もよく説明できます。 この目的のために、virtualenvと呼ばれるツールが使用されます。

次のコマンドを実行して、pipを使用してvirtualenvをインストールします。

sudo pip install virtualenv

自己完結型の仮想(Python)環境の作成


必要なすべてのツールを自由に使用できるようになったら、アプリケーションをデプロイする環境を作成できます。

覚えておいてください:プロジェクトの開発(ローカル)マシンにvirtualenvがない場合は、virtualenvを作成し、アプリケーション(およびその依存関係)を内部に移動することを検討する必要があります。

仮想環境アプリケーションモジュールの両方を含むフォルダーの作成から始めましょう。

ここでは、ニーズに合わせて任意の名前を使用できます。

mkdir my_app

このフォルダに入り、内部に新しい仮想環境を作成し続けることができます。

仮想環境に任意の名前を選択することもできます。

cd my_app
virtualenv my_app_venv

Pythonアプリケーションモジュールも含めるために、そこに新しいフォルダを作成しましょう。

これは、アプリケーションモジュールが存在するフォルダーです。

mkdir app

そして、仮想環境内でインタープリターをアクティブにして、それを使用します。

「my_app_venv」以外の名前を使用する場合は、仮想環境に選択した名前を使用してください。

source my_app_venv/bin/activate

最終的に、メインアプリケーションのデプロイメントディレクトリは次のようになります。

my_app              # Main Folder to Contain Everything Together
  |
  |=== my_app_venv  # V. Env. folder with the Python Int.
  |=== app          # Your application module
  |..
  |.

uWSGIのダウンロードとインストール


これは、アプリケーションに関連するすべての要素を可能な限り仮想環境内にまとめて含めるための推奨される方法です。 そのため、uWSGIをダウンロードしてインストールします。

環境内で作業していない場合、uWSGIはグローバル(つまり、 システム全体で利用可能)。 これはお勧めしません。 常にvirtualenvの使用を選択してください。

pipを使用してuWSGIをインストールするには、以下を実行します。

pip install uwsgi

覚えておいてください: pip 、その使用法と機能の詳細については、一般的なPythonツールに関する次の記事を参照してください:virtualenvの使用、Pipでのインストール、パッケージの管理[X201X ]。

Nginxのダウンロードとインストール


CentOS / RHELユーザーへの注意:

以下の手順は、CentOSシステムでは機能しません。 CentOSについては、こちらの説明をご覧ください。

次のコマンドを実行して、デフォルトのシステムパッケージマネージャー aptitude installNginxを使用します。

sudo aptitude install nginx

Nginxを実行するには、次を使用できます。

sudo service nginx start

Nginxを停止するには、次を使用できます。

sudo service nginx stop

Nginxを再起動するには、次を使用できます。

Nginxを再構成するたびに、新しい設定を有効にするために再起動またはリロードが必要です。

sudo service nginx restart

注: UbuntuでのNginxの詳細については、記事 Ubuntu12.04にNginxをインストールする方法を参照してください。

uWSGIを使用したPythonWSGIアプリケーションの提供


このセクションでは、PythonWSGIアプリケーションがuWSGIWebサーバーでどのように機能するかを確認します。 uWSGIを使用してPythonWSGIアプリケーションを提供することは、他のアプリケーションコンテナーと同じです。 uWSGIに必要なのは、他のサーバーと同様に、アプリケーションがエントリポイント(呼び出し可能)を提供することです。 起動時に、この呼び出し可能変数は、構成変数とともにuWSGIに渡され、そのジョブの実行を開始します。 リクエストが到着すると、リクエストを処理し、アプリケーションのコントローラーに渡して処理します。

建築:

........
      /|\                           
     | | `-> App. Server I.   127.0.0.1:8080  <--> Application
     |  `--> App. Server II.  127.0.0.1:8081  <--> Application
      .....

WSGI


一言で言えば、WSGIは、Webサーバーとアプリケーション自体の間のインターフェイスです。 これは、さまざまなサーバーとアプリケーション(フレームワーク)間の標準化された方法が相互に連携し、必要に応じて互換性を確保できるようにするために存在します(例: 開発環境から本番環境への切り替え)、これは今日の必須のニーズです。

注: WSGIおよびPythonWebサーバーの詳細については、記事PythonベースのWebサーバーの比較をご覧ください。 Webアプリケーション

WSGIアプリケーションオブジェクト(呼び出し可能):「wsgi.py


上記のように、WSGIで実行されているWebサーバーにはアプリケーションオブジェクトが必要です(つまり、 アプリケーションの)。

ほとんどのフレームワークとアプリケーションでは、これは wsgi.py で構成され、サーバーで使用されるアプリケーションオブジェクト(または呼び出し可能)を含み、提供します。

まず、模範的な wsgi.py を作成します。これは、uWSGIによってインポートされ、アプリケーションを実行するために使用されます。

wsgi.pyの代わりに任意の名前を選択できます。 ただし、これらは一般的に使用されるものです(例: Djangoによる)。

基本的なWSGIアプリケーションを含むwsgi.pyファイルの作成から始めましょう。

次のコマンドを実行して、テキストエディタnanoを使用してwsgi.pyを作成します。

nano wsgi.py

そして、基本的なWSGIアプリケーションコードを内部に移動(コピー/貼り付け)し続けましょう(これは、本番用に呼び出し可能な独自のアプリケーションに置き換える必要があります)。

def application(env, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    return ["Hello!"]

これはサーバーに含まれているファイルであり、リクエストが来るたびに、サーバーはこのアプリケーション呼び出し可能オブジェクトを使用して、アプリケーションのリクエストハンドラーを実行します(つまり、 URLを解析する際のcontrollers)(例: mysite.tld / controller / method / variable)。

アプリケーションコードを配置した後、CTRL + Xを押し、Yで確定して、このファイルを仮想環境および実際のアプリケーションを含むアプリモジュールと一緒に「my_app」フォルダー内に保存します。

注:このWSGIアプリケーションは、この種の最も基本的な例です。 アプリケーションモジュールから独自のアプリケーションオブジェクトを含めるには、このコードブロックを置き換える必要があります。

完了すると、メインのアプリケーションデプロイメントディレクトリは次のようになります。

my_app              # Main Folder to Contain Everything Together
  |
  |=== my_app_venv  # V. Env. folder with the Python Int.
  |=== app          # Your application module
  |
  |--- wsgi.py      # File containing application callable
  |..
  |.

サーバーの実行


uWSGIには多くのオプションと構成があり、その柔軟性のおかげでそれらを使用するための多くの可能な方法があります。 最初から複雑にすることなく、できるだけ簡単に作業を開始し、さらに高度な方法で作業を続けていきます。

簡単な使用例:

uwsgi [option] [option 2] .. -w [wsgi file with app. callable]

uWSGIを実行して、 wsgi.py からアプリケーションの提供を開始するには、次のコマンドを実行します。

uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi

これにより、サーバーがフォアグラウンドで実行されます。 停止したい場合は、CTRL+Cを押してください。

サーバーをバックグラウンドで実行するには、次を実行します。

uwsgi --socket 127.0.0.1:8080 --protocol=http -w wsgi &

[!]重要:セクション Nginxの構成の構成を使用してサーバーを実行してNginxを操作する場合は、引数のチェーンから--protocol=httpを必ず削除してくださいそうしないと、NginxとuWSGIが相互に通信できなくなります。

アプリケーションをバックグラウンドで実行する場合は、プロセスマネージャーを使用する必要があります(例: htop)それを殺す(または止める)。 詳細については、以下のセクションを参照してください。

シグナルを使用したuWSGIサーバーとプロセスの管理


uWSGIの管理は、実行時に実行されるアクションで構成されます。 プロセスを操作するために、このタスクにはさまざまなコマンドが設定されています。

  • SIGHUP -HUP gracefully reloads the workers and the application

  • SIGTERM -TERM “brutally” reloads

  • SIGINT -INT and SIGQUIT -QUIT kills all the workers immediately

  • SIGUSR1 -USR1 prints statistics (stdout)

  • SIGUSR2 -USR2 prints worker status

  • SIGURG -URG restores a snapshot

  • SIGTSTP -TSTP pauses, suspends or resumes an instance

  • SIGWINCH -WINCH wakes up a worker blocked in a システムコール

シグナルによる管理の例:

SIGHUPを使用してサーバーを再起動します

このコマンドは、サーバーを正常に再起動します。 これが意味するのは、現在のワーカーのジョブが完了するのを待ってから、それらを終了してから再びスポーンし、その設定を継承するということです。

使用法:kill -HUP [PID]

PIDを指定したくない場合は、pidfileオプションを使用して、uWSGIにPIDをファイルに書き込んでもらい、それを使用してプロセスを管理できます。

SIGINTでサーバーを停止する

サーバーとそのプロセスを停止するには、-INT信号を使用する必要があります。 これにより、バックグラウンドですべてが終了します。

例:kill -INT [PID]

Nginxの構成


アプリケーションを実行するようにuWSGIを設定した後、uWSGIサーバーと通信するためにNginxで同じことを行う必要があります。 このために、Nginxの構成ファイルを変更する必要があります:nginx.conf

次のコマンドを実行してnginx.confを開き、nanoテキストエディターを使用して編集します。

sudo nano /etc/nginx/nginx.conf

その後、ファイルを次の設定例に置き換えて、Nginxをリバースプロキシとして機能させ、アプリケーションと通信することができます。

注: SSLサポートの組み込みについては、最初に次の記事をお読みください:NginxでのSSL証明書の作成。

Webアプリケーションの構成例:

worker_processes 1;

events {

    worker_connections 1024;

}

http {

    sendfile on;
    
    gzip              on;
    gzip_http_version 1.0;
    gzip_proxied      any;
    gzip_min_length   500;
    gzip_disable      "MSIE [1-6]\.";
    gzip_types        text/plain text/xml text/css
                      text/comma-separated-values
                      text/javascript
                      application/x-javascript
                      application/atom+xml;

    # Configuration containing list of application servers
    upstream uwsgicluster {
    
        server 127.0.0.1:8080;
        # server 127.0.0.1:8081;
        # ..
        # .
    
    }

    # Configuration for Nginx
    server {
    
        # Running port
        listen 80;

        # Settings to by-pass for static files 
        location ^~ /static/  {
        
            # Example:
            # root /full/path/to/application/static/file/dir;
            root /app/static/;
        
        }
        
        # Serve a static file (ex. favico) outside static dir.
        location = /favico.ico  {
        
            root /app/favico.ico;
        
        }

        # Proxying connections to application servers
        location / {
        
            include            uwsgi_params;
            uwsgi_pass         uwsgicluster;

            proxy_redirect     off;
            proxy_set_header   Host $host;
            proxy_set_header   X-Real-IP $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Host $server_name;
        
        }
    }
}

構成の変更が完了したら、CTRL + Xを押し、Yで確定して保存して終了します。 変更を有効にするには、Nginxを再起動する必要があります。

次を実行してNginxを再起動します。

sudo service nginx stop
sudo service nginx start

注: Nginxの詳細については、記事VPSでNginxWebサーバーを構成する方法を参照してください。

uWSGIの構成


アプリケーションを提供するためにuWSGIを起動する場合、実行するソケット、プロセスの数、マスタープロセスの設定など、必要な構成を提供する方法がいくつかあります。 このセクションでは、そのうちの3つについて説明します。

  • 構成を引数として渡す

  • 構成に.iniファイルを使用する

  • 構成に.jsonファイルを使用する

注: uWSGIは、stdinHTTPなど、これらの構成ファイルを取得するためのさまざまなプロトコルと方法をサポートしています。

オプション#1:引数として構成を渡す:

混乱しやすく、管理が難しい場合もありますが、uWSGIを実行する最も基本的な方法は、他のシェルスクリプトと同じように、必要な構成を引数として指定することです。

使用例:

# uwsgi [option] [option 2] .. -w [wsgi.py with application callable]

# Simple server running *wsgi*
uwsgi --socket 127.0.0.1:8080 -w wsgi

# Running Pyramid (Paster) applications
uwsgi --ini-paste production.ini

# Running web2py applications
uwsgi --pythonpath /path/to/app --module wsgihandler

# Running WSGI application with specific module / callable names
uwsgi --module wsgi_module_name --callable application_callable_name
uwsgi -w wsgi_module_name:application_callable_name

uWSGIの実行方法のその他の例については、構成例のドキュメントにアクセスすることを検討してください。

オプション#2:構成に.iniファイルを使用する

uWSGIに構成を提供する別の(そしておそらく)より良い方法は、.iniファイルを使用することです。 これらのファイルは単純な構造であり(以下の例を参照)、uWSGI起動スクリプトが実行されるたびに明示的に渡す必要があります。

.ini構造の例( example_config.ini ):

[uwsgi]
# -------------
# Settings:
# key = value
# Comments >> #
# -------------

# socket = [addr:port]
socket = 127.0.0.1:8080

# Base application directory
# chdir = /full/path
chdir  = /my_app

# WSGI module and callable
# module = [wsgi_module_name]:[application_callable_name]
module = app:application

# master = [master process (true of false)]
master = true

# processes = [number of processes]
processes = 5

..

使用例:

uwsgi --ini example_config.ini    

オプション#3:構成に.jsonファイルを使用する

.jsonファイルの操作は、構造を除けば、上記の例と同じです。

.json構造( example_config.json ):

{
    "uwsgi": {
        "socket": ["127.0.0.1:8080"],
        "module": "my_app:app",
        "master": true,
        "processes": 5,
    }
}

使用例:

uwsgi --json example_config.json

uWSGIの構成の詳細については、構成のドキュメントを読むことを検討してください。

uWSGIの一般的な構成


デフォルトでは、このサーバーはデフォルトでフレームワーク/アプリケーション/プラットフォームに依存しないように設計されています。 おそらく必要なものすべてをサポートしますが、要件に準拠するために特定のオプションを明示的に設定する必要があります。

独自のドキュメントに記載されているように、uWSGIを構成するための可能な方法の数はほぼ無限です。 このセクションでは、最も一般的に使用される、または重要なものを調べ、実装について説明します。これを前のセクションと組み合わせると、uWSGIを必要な方法で正確に実行できるようになります。

最適化については、このセクションの後の次のセクションを参照してください。

以下の例で使用されている構文は、.iniファイルを対象としています。 必要に応じて、特定のニーズに合わせて変更できます(例: 前のセクションで説明したように、.jsonベースの構成の場合)。

ソケット

http-ソケット

uWSGIを特定のHTTPソケットにバインドするように設定します。

例:http-socket = :8080

ソケット

デフォルトのプロトコルを使用して、指定されたソケットにバインドされるようにuWSGIを設定します。

例:socket = 127.0.0.1:8080

プロセス(労働者)

どちらの用語も同じことを指すために使用できます。リクエストを受け入れるために生成されたプロセスの量です。

例:processes = 5

プロトコル

デフォルトでは、uWSGIは独自のuwsgiプロトコルで実行されます。 このプロパティを使用すると、変更できます。

例:protocol = http

管理

主人

このオプションは、マスターuWSGIプロセスを有効または無効にするために使用されます。 これらのプロセスは、着信要求を受け入れて処理するワーカーを管理するために使用されます。 ソケットに触れることなくワーカーを正常に再起動するなど、多くの利点があり、ダウンタイムなしでアップグレードできます。

例:master = true

max-requests

メモリリークが心配で、それを処理するためのより確実な方法が考えられない場合、このオプションを使用すると、指定された設定量の要求を処理した後、プロセスを自動的に再起動できます。

例:max-requests = 1001

スレッド

再スレッドモードで指定されたスレッド数で各プロセスを実行するための設定。 このオプションをprocessesと組み合わせて、さまざまな程度で同時実行性を取得することができます。

例:threads = 2

ロギング

disable-logging

ロギング機能を無効にするために使用されます。

例:disable-logging = true

uWSGIプロセス

procname

プロセス名を任意の名前に設定できます。

例:procname = My Application

uid

uWSGIサーバーユーザーuidを指定されたものに設定します。

例:uid = 1001

gid

uWSGIサーバーgidを指定されたサーバーに設定します。

例:gid = 555

真空

終了時に、生成されたすべてのpidfile/ソケットを削除します。

デーモン化

この設定は、デーモン化 uWSGIを実行し、指定された引数(ログファイル)にメッセージを書き込みます。

例:daemonize = /tmp/uwsgi_daemonize.log

pidfile

オプションで指定されたファイルにプロセスPIDを書き込むようにuWSGIを設定します。 このオプションは、実行中のuWSGIプロセスの管理に非常に便利です(詳細については、 uWSGI のセクションを参照してください)。

例:pidfile = /tmp/proj_pid.pid

様々

切腹

この設定は、プロセスがメモリ/管理の目的で強制終了されてリサイクルされる前に、プロセスがタスクを完了することができる最大時間を設定するために使用されます

例:harakiri = 30

利用可能な数百の構成についてすべて学ぶには、公式の構成オプションのドキュメントにある完全なリストを確認する必要があります。

その他のヒントと提案


ファイアウォール:

SSHの保護:

アラートの作成:

サーバーアクセスログを毎日監視および監視します。

投稿者: https ://twitter.com/ostezer