Nginxの背後にあるGunicornHTTPサーバーを使用してPythonWSGIアプリをデプロイする方法
序章
おそらく、 Python Webサーバーの比較に関する記事で、切り替えたくなるか、現在のアプリケーションデプロイメントスタックを単純に超えてしまったという事実でした。 あなたはGunicornWebサーバーについてもっと知りたいと思っており、Pythonアプリケーションを最初から徹底的にデプロイする方法を学びたいと思っています。
このDigitalOceanの記事では、私たちの目的は、上記のすべて、そしていくつかを支援することです。 まず、優れたGunicorn WSGI HTTPサーバーに関する知識を広げ、さまざまな人気のあるフレームワーク上に構築されたPythonWSGIWebアプリケーションのデプロイを続けます。
用語集
1. GunicornとNginxについて
- Gunicorn
- Nginxを使用したWebアプリケーションのデプロイ
2. 生産のための液滴の準備
- デフォルトのオペレーティングシステムを更新する
- Python、pip、virtualenvのセットアップ
- 仮想(Python)環境の作成
- Gunicornのダウンロードとインストール
- Nginxのダウンロードとインストール
3. GunicornでPythonWebアプリケーションを提供する
- WSGI
- WSGIアプリケーションオブジェクト(呼び出し可能): wsgi.py
- サーバーの実行
- Gunicornの設定と最適化
- Nginxの構成
- その他のヒントと提案
GunicornとNginxについて
Gunicorn
Gunicorn は、多くの機能を提供するスタンドアロンのWSGIWebアプリケーションサーバーです。 アダプターを使用してさまざまなフレームワークをネイティブにサポートしているため、開発中に使用される多くの開発サーバーのドロップイン置換を非常に簡単に使用できます。
技術的には、Gunicornの動作方法は、Rubyアプリケーション用の成功したUnicornWebサーバーと非常によく似ています。 どちらも、プレフォークモデルと呼ばれるものを使用しています。 これは、本質的に、中央の[Gunicorn]マスタープロセスに、ワーカーの管理、ソケットとバインディングの作成などを処理するタスクを実行します。
Gunicornサーバーのハイライト
-
WSGI Python Webアプリケーション(およびフレームワーク)を実行します
-
Paster(Pyramid)、Djangoの開発サーバー、web2pyなどのドロップイン代替品として使用できます。
-
さまざまなワーカータイプと構成が付属しています
-
ワーカープロセスを自動的に管理します
-
同期および非同期ワーカーによるHTTP/1.0およびHTTP/1.1(Keep-Alive)のサポート
-
SSLをサポート
-
フックで拡張可能
-
Python2.6以降および3.xのサポート
Nginxを使用したWebアプリケーションのデプロイ
Nginxは、非常に高性能なWebサーバー/(リバース)プロキシです。 軽量で、操作が比較的簡単で、拡張が簡単なため(アドオン/プラグインを使用)、現在人気があります。 そのアーキテクチャのおかげで、多くのリクエスト(実質的に無制限)を処理できます。これは、アプリケーションやWebサイトの負荷によっては、他の古い代替手段を使用して対処するのが非常に難しい場合があります。
覚えておいてください:接続を「処理する」とは、技術的には、接続を削除せず、何かでサービスを提供できることを意味します。 Nginxがエラーメッセージではないクライアント*応答を提供するためには、アプリケーションとデータベースが正常に機能している必要があります。
アプリケーションサーバーの前でリバースプロキシとしてNginxを使用するのはなぜですか?
多くのフレームワークとアプリケーションサーバー(Gunicornを含む)は静的ファイルを提供できます(例: 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
注:使用するサーバー/ワーカーの数については、Gunicornの構成と最適化のセクションを参照してください。
生産のための液滴の準備
このセクションでは、仮想を本番用に準備します(つまり、 アプリケーションをデプロイするため)。
まず始めます:
-
デフォルトのオペレーティングシステムを更新する
-
一般的なPythonツールのダウンロードとインストール(つまり pip、virtualenv)
-
アプリケーションを含む仮想環境の作成(Gunicornなどの依存関係が存在する環境)
注:ここに記載されている手順は簡潔にしています。 詳細については、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
|..
|.
Gunicornのダウンロードとインストール
これは、アプリケーションに関連するすべての要素を可能な限り仮想環境内にまとめて含めるための推奨される方法です。 そのため、Gunicornをダウンロードしてインストールします。
環境内で作業していない場合、Gunicornはグローバルにインストールされます(つまり、 システム全体で利用可能)。 これは推奨されていません。 常にvirtualenvの使用を選択してください。
pipを使用してGunicornをインストールするには、次のコマンドを実行します。
pip install gunicorn
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をインストールする方法を参照してください。
GunicornでPythonWebアプリケーションを提供する
このセクションでは、WSGIアプリケーションがGunicornでどのように機能するかを確認します。 このプロセスは、サーバーに呼び出し可能なWSGIアプリケーションを提供することで構成されます(例: application = (..)
)をエントリポイントとして使用します。
WSGI
一言で言えば、WSGIは、Webサーバーとアプリケーション自体の間のインターフェイスです。 これは、さまざまなサーバーとアプリケーション(フレームワーク)間の標準化された方法が相互に連携し、必要に応じて互換性を確保できるようにするために存在します(例: 開発環境から本番環境への切り替え)、これは今日の必須のニーズです。
注: WSGIおよびPythonWebサーバーの詳細については、記事PythonベースのWebサーバーの比較をご覧ください。 Webアプリケーション。
WSGIアプリケーションオブジェクト(呼び出し可能): wsgi.py
上記のように、WSGIで実行されているWebサーバーにはアプリケーションオブジェクトが必要です(つまり、 アプリケーションの)。
ほとんどのフレームワークとアプリケーションでは、これは次のもので構成されます。
- wsgi.py は、サーバーで使用されるアプリケーションオブジェクト(または呼び出し可能)を含み、提供します。
まず、Gunicornで使用する模範的なwsgi.pyを作成します。
「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の解析時(例: 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
|..
|.
サーバーの実行
アプリケーションの提供を開始するには、以下を実行する必要があります。
gunicorn [option] [option] .. [wsgi file]
次のコマンドを実行してサーバーを起動します。
gunicorn -b 0.0.0.0:8080 wsgi
これにより、サーバーがフォアグラウンドで実行されます。 停止したい場合は、CTRL+Cを押してください。
サーバーをバックグラウンドで実行するには、次を実行します。
gunicorn -b 0.0.0.0:8080 wsgi &
アプリケーションをバックグラウンドで実行する場合は、プロセスマネージャーを使用する必要があります(例: htop)それを殺す(または止める)。
Gunicornの設定と最適化
注:以下は、最も一般的に使用される構成および最適化設定の一部です。 利用可能なすべてのオプションについては、Gunicornの構成の概要の公式ドキュメントをご覧ください。
前述のように、Gunicornは高度に構成可能であり、必要なすべてのパラメーターを変更して自分のやり方に合わせるのは非常に簡単です。
[!]重要:以下にリストされているすべての設定と構成オプションは、gunicornを起動し、アプリケーションをサーバー化するためにチェーン(次々に配置)する必要があります。 サーバーの起動後にオプションを変更することはできません。 どちらのオプションを使用する場合でも、その後にアプリケーションへのエントリポイントを含むwsgiファイルを続ける必要があります。
例:
# Simply running the server (as shown above):
gunicorn -b 0.0.0.0:8080 wsgi
# Running the server with five workers:
gunicorn -b 0.0.0.0:8080 --workers=5 wsgi
労働者数
一般に、アプリケーションはCPUバウンドではなくI / Oバウンドであると見なされます(受け入れられます)。 これが意味するのは、ボトルネックは仮想サーバーの処理能力ではなく、ディスクが原因であるということです。 アイデアは、ワーカーがディスク操作で忙しいときでも、別のワーカーが要求を処理するCPUを利用するということです。
したがって、推奨される労働者の数は、通常、次の簡単な式で設定されます。
# (2 Workers * CPU Cores) + 1
# ---------------------------
# For 1 core -> (2*1)+1 = 3
# For 2 cores -> (2*2)+1 = 5
# For 4 cores -> (2*4)+1 = 9
引数--workers=[n]
を渡すことにより、ワーカーの数を指定できます。
使用法:
# Example: gunicorn --workers=[number of workers]
gunicorn --workers=5
注:上記のシナリオは、非ブロッキングワーカーには厳密には適用されません。
ソケット設定
ソケットバインディングの仕組みは次のとおりです。
# Example: gunicorn -b [address:port]
gunicorn -b 127.0.0.1:8080
注:アプリケーションが
127.0.0.1
で着信接続をリッスンするように設定されている場合、ローカルでのみアクセスできます。 ただし、0.0.0.0
を使用すると、外部からの接続も受け入れられます。
ワーカータイプの選択
私たちが議論したように、Gunicornはさまざまなタイプの労働者と協力する可能性を提供しました。
ほとんどのデプロイメントでは、標準のワーカータイプ(sync)で十分であり、デフォルトで提供されるため、明示的な設定は必要ありません。
他のワーカーについては、依存関係としてインストールする必要があることに注意してください。
使用法:
# Example: gunicorn -k [worker]
gunicorn -k sync # or;
gunicorn -k gevent # ..
利用可能なタイプ:
- 同期
- イベントレット
- gevent
- 竜巻
イベントレット/イベントの同時接続数
EventletおよびGeventワーカーの同時接続数を変更するには:
# Example: gunicorn -k [worker] --worker-connections [number]
gunicorn -k gevent --worker-connections 1001
アクセスログ
アクセスログを書き込むためにファイルを明示的に設定する場合:
# Example: gunicorn --access-logfile [file]
gunicorn --access-logfile acclogs
デフォルトでは、このオプションはNoneに設定されています。
エラーログ
エラーログを書き込むファイルを指定するには、この設定を使用します。
# Example: gunicorn --log-file [file]
gunicorn --log-file error_logs.log
ログレベル
これは、エラーログ出力の粒度を設定するために使用されます。 可能なオプションは次のとおりです。
- デバッグ
- 情報
- 警告
- エラー
- 致命的
使用法:
# Example: gunicorn --log-level [level]
gunicorn --log-level error
プロセスの命名
top などのユーティリティを使用してプロセスを監視している場合は、この設定を使用して、タスクに役立つより意味のある名前を付けることができます。
# Example: gunicorn --name [name]
gunicorn --name my_application
Nginxの構成
Gunicornの構成と実行について学習した後、アプリケーションを実行しているGunicornサーバーと通信するために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 app_servers {
server 127.0.0.1:8080;
# server 127.0.0.1:8081;
# ..
# .
}
# Configuration for Nginx
server {
# Running port
listen 80;
# Settings to serve static files
location ^~ /static/ {
# Example:
# root /full/path/to/application/static/file/dir;
root /app/static/;
}
# Serve a static file (ex. favico)
# outside /static directory
location = /favico.ico {
root /app/favico.ico;
}
# Proxy connections to the application servers
# app_servers
location / {
proxy_pass http://app_servers;
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サーバーを構成する方法を参照してください。
その他のヒントと提案
ファイアウォール:
SSHの保護:
アラートの作成:
サーバーアクセスログを毎日監視および監視します。