独立したWSGIコンテナ（Standalone WSGI Containers） Standalone WSGI Containers¶
Pythonで書かれた人気のあるサーバで、WSGアプリケーションを含みHTTPへ対応するものがいくつかあります。これらのサーバは実行すると独立して稼働します;自分のwebサーバからそれらのサーバへプロキシさせることが可能です（訳注: 例えば、このドキュメントの最後の方にある、NginxからlocalhostのWSGIコンテナへ転送するようなケースを意図していると思います）。もし問題に出くわしたときはプロキシの設定（Proxy Setups）セクションに注目してください。 There are popular servers written in Python that contain WSGI applications and serve HTTP. These servers stand alone when they run; you can proxy to them from your web server. Note the section on :ref:`deploying-proxy-setups` if you run into issues.
Gunicorn¶
Gunicorn「Green Unicorn」はUNIX用のWSGI HTTPサーバです。GunicornはRubyのUnicornプロジェクトから移植されたpre-fork workerモデル（訳注: HTTPリクエストを受信したとき、サーバのプロセスをOSレベルで複製（fork）し、作成した子プロセスでリクエストの具体的な処理を行うもので、そのときプロセスのforkは負荷が大きい処理なので、性能向上のために事前にいくつかの子プロセスを作成（pre-fork）して用意しておくモデル）のものです。Gunicornはeventletとgreenlet（訳注: ネットワーク処理と並行処理のための具体的なライブラリ）を両方サポートします。このサーバでFlaskアプリケーションを実行するのはとても単純です: `Gunicorn`_ 'Green Unicorn' is a WSGI HTTP Server for UNIX. It's a pre-fork worker model ported from Ruby's Unicorn project. It supports both `eventlet`_ and `greenlet`_. Running a Flask application on this server is quite simple::
$ gunicorn myproject:app
Gunicornは多くのコマンドラインのオプションを提供します-- gunicorn -hを見てください。例えば、Flaskアプリケーションをlocalhostの4000番ポートに結び付けて（-b 127.0.0.1:4000)、4つのworkerプロセスを使って（-w 4）（訳注: 4つのpre-forkしたプロセスという意味合いだと思います）実行するには以下のようにします:
`Gunicorn`_ provides many command-line options -- see ``gunicorn -h``. For example, to run a Flask application with 4 worker processes (``-w 4``) binding to localhost port 4000 (``-b 127.0.0.1:4000``)::
$ gunicorn -w 4 -b 127.0.0.1:4000 myproject:app
gunicornコマンドは、アプリケーションのmoduleまたはpackageの名前と、module内のアプリケーションのインスタンスの名前とを期待します。もしapplication factoryパターンを使っているときは、以下のようにしてgunicornへインスタンスを渡せます:
The ``gunicorn`` command expects the names of your application module or package and the application instance within the module. If you use the application factory pattern, you can pass a call to that::
$ gunicorn "myproject:create_app()"
uWSGI¶
uWSGIはCで書かれた高速なアプリケーションサーバです。uWSGIはとても柔軟に設定できることから、gunicornよりも複雑な設定（setup）が必要になります。 `uWSGI`_ is a fast application server written in C. It is very configurable which makes it more complicated to setup than gunicorn.
uWSGI HTTP Routerの実行: Running `uWSGI HTTP Router`_::
$ uwsgi --http 127.0.0.1:5000 --module myproject:app
より最適化された設定（setup）については、uWSGIとNGINXの設定を確認ください。 For a more optimized setup, see :doc:`configuring uWSGI and NGINX <uwsgi>`.
Gevent¶
Geventはコルーチン（訳注: プログラミングで、呼び出された関数などで、途中で中断して制御を一旦呼び出し元に戻し、後から処理を再開できるような概念・機能）をベースにしたPythonのネットワーク処理のライブラリで、libevのevent loop上に高階層の（抽象度の高い）同期APIを提供するためにgreenletを使用しています: `Gevent`_ is a coroutine-based Python networking library that uses `greenlet`_ to provide a high-level synchronous API on top of `libev`_ event loop::
from gevent.pywsgi import WSGIServer
from yourapplication import app
http_server = WSGIServer(('', 5000), app)
http_server.serve_forever()
Twisted Web¶
Twisted Webは、成熟した（実績の多い）、non-blockingでevent-drivenなネットワーク処理のライブラリであるTwistedと一緒に配付されているwebサーバです。Twisted Webでは、twistdユーティリティを利用してコマンドラインから制御可能な、独立したWSGIコンテナが一緒に提供されています:
`Twisted Web`_ is the web server shipped with `Twisted`_, a mature, non-blocking event-driven networking library. Twisted Web comes with a standard WSGI container which can be controlled from the command line using the ``twistd`` utility::
$ twistd web --wsgi myproject.app
この例は、myprojectという名前のmoduleからappと呼ばれるFlaskアプリケーションを走らせます。
This example will run a Flask application called ``app`` from a module named ``myproject``.
Twisted Webは多くのフラグとオプションをサポートし、twistdユーティリティも同様に多くをサポートします;さらなる情報については、twistd -hとtwistd web -hを確認してください。以下は、Twistd Webをフォアグラウンドで、8080番ポート上で、myprojectのアプリケーションを使って走らせる例です:
Twisted Web supports many flags and options, and the ``twistd`` utility does as well; see ``twistd -h`` and ``twistd web -h`` for more information. For example, to run a Twisted Web server in the foreground, on port 8080, with an application from ``myproject``::
$ twistd -n web --port tcp:8080 --wsgi myproject.app
プロキシの設定（Proxy Setups） Proxy Setups¶
もしHTTPプロキシの背後に、ここで取り上げたサーバのひとつを使って自分のアプリケーションをデプロイする場合、アプリケーションが機能するためにはいくつかのヘッダを書き換える必要があります。WSGI環境の中で問題になりやすい2つの値はREMOTE_ADDRとHTTP_HOSTです。これらのヘッダを渡すようにhttpd（訳注: webサーバのような意味合い、広く使われているWebサーバのApacheでは、webサーバの具体的なプログラム名（実行ファイル名）がhttpdなので、そこからwebサーバ一般のような意味合いで使われていると思います）を設定することも、ミドルウェアの中でそれらのヘッダを修正することも可能です。Werkzeugはいくつかのよくある設定（setups）でこの問題を解決する機能（fixer）を配付していますが、固有の設定（setups）用に自分で独自のWSGIミドルウェアを書きたくなるかもしれません。
If you deploy your application using one of these servers behind an HTTP proxy you will need to rewrite a few headers in order for the application to work. The two problematic values in the WSGI environment usually are ``REMOTE_ADDR`` and ``HTTP_HOST``. You can configure your httpd to pass these headers, or you can fix them in middleware. Werkzeug ships a fixer that will solve some common setups, but you might want to write your own WSGI middleware for specific setups.
以下は、適切なヘッダを設定し、localhostの8000番ポートで稼働しているアプリケーションへプロキシする、シンプルなnginxの構成です: Here's a simple nginx configuration which proxies to an application served on localhost at port 8000, setting appropriate headers:
server {
listen 80;
server_name _;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location / {
proxy_pass http://127.0.0.1:8000/;
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-Proto $scheme;
}
}
もし自分のhttpdがこれらのヘッダを提供しない場合、最もありがちな設定ではhostをX-Forwarded-Hostから、remote addressをX-Forwarded-Forから設定します:
If your httpd is not providing these headers, the most common setup invokes the host being set from ``X-Forwarded-Host`` and the remote address from ``X-Forwarded-For``::
from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1, x_host=1)
ヘッダの信用 Trusting Headers
このようなミドルウェアをプロキシを使わない設定で使用することは、悪意のあるクライアントによって偽造されているかもしれない受信ヘッダを盲目的に信用するため、セキュリティ上の問題になることを覚えておいてください。 Please keep in mind that it is a security issue to use such a middleware in a non-proxy setup because it will blindly trust the incoming headers which might be forged by malicious clients.
もしその他のヘッダを書き換えたい場合、以下のような修正機能（fixer）を使いたくなるかもしれません: If you want to rewrite the headers from another header, you might want to use a fixer like this::
class CustomProxyFix(object):
def __init__(self, app):
self.app = app
def __call__(self, environ, start_response):
host = environ.get('HTTP_X_FHOST', '')
if host:
environ['HTTP_HOST'] = host
return self.app(environ, start_response)
app.wsgi_app = CustomProxyFix(app.wsgi_app)
