Самостоятельные контейнеры WSGI

Существуют популярные серверы, написанные на Python, которые содержат приложения WSGI и обслуживают HTTP. Эти серверы работают автономно; вы можете обращаться к ним через прокси-сервер из своего веб-сервера. Обратите внимание на раздел Настройки прокси, если у вас возникнут проблемы.

Gunicorn

Gunicorn («Зелёный единорог») — WSGI HTTP-сервер для UNIX. Это модель предварительного разветвления, перенесённая из проекта Unicorn для Ruby. Он поддерживает как eventlet, так и greenlet. Запуск приложения Flask на этом сервере довольно прост:

gunicorn myproject:app

Gunicorn предоставляет множество опций командной строки — см. gunicorn -h. Например, чтобы запустить приложение Flask с 4 рабочими процессами (-w 4) и привязкой к локальному хосту на порту 4000 (-b 127.0.0.1:4000):

gunicorn -w 4 -b 127.0.0.1:4000 myproject:app

Gevent

Gevent — основанная на сопроцедурах Python-библиотека для сетевого программирования, использующая greenlet для предоставления высокоуровневого синхронного API поверх цикла событий libev:

from gevent.wsgi import WSGIServer
from yourapplication import app

http_server = WSGIServer(('', 5000), app)
http_server.serve_forever()

Twisted Web

Twisted Web — веб-сервер, поставляемый с Twisted, зрелой, неблокирующей, управляемой событиями библиотекой сетевого программирования. Twisted Web поставляется со стандартным контейнером WSGI, который можно управлять из командной строки с помощью утилиты twistd:

twistd web --wsgi myproject.app

Этот пример запустит приложение Flask под названием app из модуля под названием myproject.

Twisted Web поддерживает множество флагов и опций, и утилита twistd тоже; см. twistd -h и twistd web -h для получения дополнительной информации. Например, чтобы запустить сервер Twisted Web в фоновом режиме на порту 8080 с приложением из myproject:

twistd -n web --port 8080 --wsgi myproject.app

Настройки прокси

Если вы развертываете своё приложение с помощью одного из этих серверов за HTTP-прокси, вам потребуется переписать несколько заголовков, чтобы приложение работало. Две проблемные значения в окружении WSGI обычно это REMOTE_ADDR и HTTP_HOST. Вы можете настроить httpd так, чтобы он передавал эти заголовки, или можете исправить их в middleware. Werkzeug поставляется с исправлением, которое решит некоторые распространённые настройки, но, возможно, вам захочется написать свой собственный WSGI-middleware для определённых настроек.

Вот простая конфигурация nginx, которая проксирует к приложению, обслуживаемому на localhost на порту 8000, задавая соответствующие заголовки:

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 не предоставляет эти заголовки, наиболее распространённая настройка подразумевает установку хоста из X-Forwarded-Host и удалённого адреса из X-Forwarded-For:

from werkzeug.contrib.fixers import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app)

Если вы хотите переписать заголовки из другого заголовка, возможно, вы захотите использовать исправленное подобно этому:

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)