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

提供：Dev Guides
Werkzeug/docs/2.0.x/serving
移動先:案内、検索

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

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

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

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'はそれをウォッチドッグバックエンドに強制します。

ノート

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


カラーロギング

開発サーバーは、ステータスコードに基づいて、リクエストログをさまざまな色で強調表示します。 Windowsでは、これを有効にするために Colorama もインストールする必要があります。


仮想ホスト

多くの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を自分で解析したりできます。


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

場合によっては、リクエストを処理した後にサーバーをシャットダウンすると便利なことがあります。 たとえば、OAuth認証を必要とするローカルコマンドラインツールは、サーバーを一時的に起動して応答をリッスンし、ユーザーのトークンを記録してから、サーバーを停止することができます。

これを行う1つの方法は、multiprocessingプロセスでサーバーを起動し、値が親に戻された後にプロセスを終了することです。 

import multiprocessing
from werkzeug import Request, Response, run_simple

def get_token(q: multiprocessing.Queue) -> None:
    @Request.application
    def app(request: Request) -> Response:
        q.put(request.args["token"])
        return Response("", 204)

    run_simple("localhost", 5000, app)

if __name__ == "__main__":
    q = multiprocessing.Queue()
    p = multiprocessing.Process(target=get_token, args=(q,))
    p.start()
    print("waiting")
    token = q.get(block=True)
    p.terminate()
    print(token)

この例ではWerkzeugの開発サーバーを使用していますが、Pythonプロセスとして起動できる本番サーバーはすべて同じ手法を使用できるため、セキュリティのために優先する必要があります。 別の方法は、subprocessプロセスを開始し、stdoutを介して値を送り返すことです。

バージョン2.0以降の非推奨： environ["werkzeug.server.shutdown"]によるサーバーのシャットダウンは非推奨であり、Werkzeug2.1で削除されます。


開発サーバーは、要求からサーバーをシャットダウンする方法を提供します。 これは、開発サーバーでのみ機能します。 開発サーバーは、"werkzeug.server.shutdown"キーを使用してWSGI環境に関数を挿入します。 

def shutdown_server(environ):
    shutdown = environ.get("werkzeug.server.shutdown")

    if shutdown is None:
        raise RuntimeError("Not running the development 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 を提供する必要があります。

  1. 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')

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

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

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


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

タプルの代わりにssl.SSLContextオブジェクトを使用して、TLS構成を完全に制御できます。 

import ssl
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
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)


「https://www.finddevguides.com/index.php?title=Werkzeug/docs/2.0.x/serving&oldid=99900」から取得
Powered by MediaWiki