WSGIアプリケーションの提供

WSGIアプリケーションを提供する方法はたくさんあります。開発中は、通常、Apacheのような本格的なWebサーバーを稼働させたくはありませんが、代わりに単純なスタンドアロンのWebサーバーを使用します。そのため、Werkzeugには開発サーバーが組み込まれています。

最も簡単な方法は、組み込みサーバーを使用してアプリケーションを実行する小さなstart-myproject.pyファイルを作成することです。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from werkzeug.serving import run_simple
from myproject import make_app

app = make_app(...)
run_simple('localhost', 8080, app, use_reloader=True)

extra_files キーワード引数を、監視する追加ファイル（構成ファイルなど）のリストとともに渡すこともできます。

情報

開発サーバーは、実稼働システムでの使用を目的としたものではありません。これは特に開発目的で設計されており、高負荷ではパフォーマンスが低下します。展開のセットアップについては、アプリケーションの展開ページをご覧ください。

リローダー

バージョン0.10で変更されました。

Werkzeugリローダーは、Webアプリケーションのモジュールとパスを常に監視し、監視対象のファイルのいずれかが変更された場合はサーバーを再起動します。

バージョン0.10以降、リローダーがサポートするバックエンドはstatとwatchdogの2つです。

デフォルトのstatバックエンドは、定期的にすべてのファイルのmtimeをチェックするだけです。ほとんどの場合、これで十分ですが、ラップトップのバッテリーを消耗することが知られています。
watchdogバックエンドはファイルシステムイベントを使用し、statよりもはるかに高速です。ウォッチドッグモジュールをインストールする必要があります。これを実現するための推奨される方法は、要件ファイルにWerkzeug[watchdog]を追加することです。

watchdogがインストールされて利用可能な場合、組み込みのstatリローダーの代わりに自動的に使用されます。

バックエンドを切り替えるには、run_simple()関数の reloader_type パラメーターを使用できます。 'stat'はそれをデフォルトの統計ベースのポーリングに設定し、'watchdog'はそれをウォッチドッグバックエンドに強制します。

ノート

正しくインポートできなかったモジュールなど、一部のエッジケースは、パフォーマンス上の理由から統計リローダーによって処理されません。ウォッチドッグリローダーはそのようなファイルも監視します。

カラーロギング

開発サーバーは、オプションで、ステータスコードに基づいてさまざまな色でリクエストログを強調表示できます。この機能を有効にするには、クリックをインストールします。

仮想ホスト

多くのWebアプリケーションは、複数のサブドメインを利用しています。これは、ローカルでシミュレートするのが少し難しい場合があります。幸い、ローカルコンピュータに複数の名前を割り当てるために使用できる hostsファイルがあります。

これにより、 localhost に加えて、ローカルコンピューター yourapplication.local および api.yourapplication.local （またはその他）を呼び出すことができます。

次の場所にhostsファイルがあります。

ウィンドウズ %SystemRoot%\system32\drivers\etc\hosts

Linux / OS X /etc/hosts

お気に入りのテキストエディタでファイルを開き、 localhost の後に新しい名前を追加できます。

127.0.0.1       localhost yourapplication.local api.yourapplication.local

変更を保存すると、しばらくすると、これらのホスト名の開発サーバーにもアクセスできるようになります。 URL Routing システムを使用して、異なるホスト間でディスパッチしたり、request.hostを自分で解析したりできます。

サーバーのシャットダウン

バージョン0.7の新機能。

Werkzeug 0.7以降、開発サーバーは、要求後にサーバーをシャットダウンする方法を提供します。これは現在、Python 2.6以降でのみ機能し、開発サーバーでのみ機能します。シャットダウンを開始するには、WSGI環境で'werkzeug.server.shutdown'という名前の関数を呼び出す必要があります。

def shutdown_server(environ):
    if not 'werkzeug.server.shutdown' in environ:
        raise RuntimeError('Not running the development server')
    environ['werkzeug.server.shutdown']()

トラブルシューティング

ipv6をサポートし、最新のLinuxシステム、OS X 10.4以降、およびWindows Vistaなどの構成済みのオペレーティングシステムでは、ローカルサーバーにアクセスすると、一部のブラウザーが非常に遅くなる可能性があります。これは、「localhost」がipv4ソケットとipv6ソケットの両方で使用できるように構成されている場合があり、一部のブラウザーは最初にipv6にアクセスし、次にipv4にアクセスしようとするためです。

現時点では、統合Webサーバーはipv6とipv4を同時にサポートしておらず、移植性を高めるためにipv4がデフォルトです。

Webブラウザがページをロードするのに時間がかかることに気付いた場合、この問題を回避する方法は2つあります。 ipv6のサポートが必要ない場合は、次の行を削除して、 hostsファイルのipv6エントリを無効にできます。

::1             localhost

または、ブラウザでipv6サポートを無効にすることもできます。たとえば、Firefoxがこの動作を示している場合は、about:configに移動し、 network.dns.disableIPv6 キーを無効にすることで無効にできます。ただし、これはWerkzeug0.6.1では推奨されていません。

Werkzeug 0.6.1以降、サーバーはオペレーティングシステムの構成に基づいてipv4とipv6を切り替えるようになりました。これは、ブラウザでipv6サポートを無効にしたが、オペレーティングシステムがipv6を優先している場合、サーバーに接続できないことを意味します。そのような状況では、::1のlocalhostエントリを削除するか、ホスト名をipv4アドレス（ 127.0.0.1 ）に明示的にバインドできます。

SSL

バージョン0.6の新機能。

組み込みサーバーは、テスト目的でSSLをサポートします。 SSLコンテキストが提供されている場合は、それが使用されます。つまり、サーバーはHTTPモードまたはHTTPSモードのいずれかで実行できますが、両方で実行することはできません。

クイックスタート

WerkzeugでSSLベースの開発を行う最も簡単な方法は、SSL証明書と秘密鍵を生成し、それをどこかに保存して、そこに置くことです。証明書の場合、生成時にサーバーの名前または CN を提供する必要があります。

SSLキーを生成し、次の場所に保存します。

>>> from werkzeug.serving import make_ssl_devcert
>>> make_ssl_devcert('/path/to/the/key', host='localhost')
('/path/to/the/key.crt', '/path/to/the/key.key')

これで、このタプルをssl_contextとしてrun_simple()メソッドに渡すことができます。

run_simple('localhost', 4000, application,
           ssl_context=('/path/to/the/key.crt',
                        '/path/to/the/key.key'))

その後、ブラウザで証明書を確認する必要があります。

手作業でコンテキストを読み込む

Python 2.7.9および3+では、単純なタプルの代わりにssl.SSLContextオブジェクトを使用するオプションもあります。このようにして、Werkzeugの組み込みサーバーのSSL動作をより適切に制御できます。

import ssl
ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23)
ctx.load_cert_chain('ssl.cert', 'ssl.key')
run_simple('localhost', 4000, application, ssl_context=ctx)

証明書の生成

キーと証明書は、make_ssl_devcert()の代わりにopensslツールを使用して事前に作成できます。これには、 openssl コマンドがシステムにインストールされている必要があります。

$ openssl genrsa 1024 > ssl.key
$ openssl req -new -x509 -nodes -sha1 -days 365 -key ssl.key > ssl.cert

アドホック証明書

SSLを有効にする最も簡単な方法は、サーバーをアドホックモードで起動することです。その場合、WerkzeugはSSL証明書を生成します。

run_simple('localhost', 4000, application,
           ssl_context='adhoc')

もちろん、これの欠点は、サーバーがリロードされるたびに証明書を確認する必要があることです。最新のブラウザはセキュリティ上の理由からそれらをサポートするのに悪い仕事をしているので、アドホック証明書は推奨されません。

この機能を使用するには、暗号化ライブラリをインストールする必要があります。

Unixソケット

開発サーバーは、TCPソケットの代わりにUnixソケットにバインドできます。 run_simple()は、hostnameパラメーターが'unix://'で始まる場合、Unixソケットにバインドします。

from werkzeug.serving import run_simple
run_simple('unix://example.sock', 0, app)

WSGIアプリケーションの提供—Werkzeugドキュメント

目次