Python Web フレームワーク、WSGI、CGI がどのように連携するか
質問
私は持っています ブルーホスト Python スクリプトを CGI として実行できるアカウント。実行するには以下を定義する必要があるため、これが最も単純な CGI だと思います。 .htaccess
:
Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py
現在、Python を使用した Web プログラミングについて調べるたびに、WSGI とほとんどのフレームワークがそれをどのように使用しているかについてよく耳にします。しかし、特に Web サーバーが与えられ (ホストのマシンで Apache が実行されている)、実際に操作できるものではない場合 (定義を除く)、すべてがどのように組み合わされるのか理解できません。 .htaccess
コマンド)。
調子はどうですか WSGI, 、CGI、およびフレームワークはすべて接続されていますか?Web フレームワーク (たとえば、 web.py または チェリーパイ) 私の基本的な CGI 設定ではどうですか?WSGI サポートをインストールするにはどうすればよいですか?
解決
WSGI、CGI、およびフレームワークのすべての接続方法
Apacheはポート80でリッスンします。HTTP要求を取得します。要求を解析して、応答する方法を見つけます。 Apacheには、応答するための選択肢がたくさんあります。応答する1つの方法は、CGIを使用してスクリプトを実行することです。応答する別の方法は、単にファイルを提供することです。
CGIの場合、Apacheは環境を準備し、CGIプロトコルを介してスクリプトを呼び出します。これは標準のUnix Fork / Execの状況です。CGIサブプロセスは、ソケットとstdoutを含むOS環境を継承します。 CGIサブプロセスは、Apacheに戻る応答を書き込みます。 Apacheはこの応答をブラウザに送信します。
CGIは原始的で迷惑です。主に、すべてのリクエストに対してサブプロセスをフォークし、サブプロセスは、stdoutおよびstderrを終了または閉じて、応答の終了を示す必要があるためです。
WSGIは、CGI設計パターンに基づいたインターフェースです。必ずしもCGIである必要はありません。リクエストごとにサブプロセスをフォークする必要はありません。 CGIでも構いませんが、そうである必要はありません。
WSGIは、いくつかの重要な方法でCGIデザインパターンに追加されます。 HTTPリクエストヘッダーが解析され、環境に追加されます。環境内のファイルのようなオブジェクトとして、POST指向の入力を提供します。また、応答を定式化する関数を提供し、多くの書式設定の詳細を省きます。
基本的なCGI構成でWebフレームワーク(web.pyやcherrypyなど)を実行する場合、何を知って/インストール/実行する必要がありますか?
サブプロセスのフォークはコストがかかることを思い出してください。これを回避するには2つの方法があります。
-
埋め込み
mod_wsgi
またはmod_python
は、Apache内にPythonを埋め込みます。プロセスはフォークされません。 ApacheはDjangoアプリケーションを直接実行します。 -
デーモン
mod_wsgi
またはmod_fastcgi
を使用すると、Apacheは別のデーモン(または「長時間実行プロセス」)と対話できます。 WSGIプロトコルを使用します。長時間実行されるDjangoプロセスを開始してから、Apacheのmod_fastcgiを設定してこのプロセスと通信します。
mod_wsgi
は、埋め込みまたはデーモンのいずれかのモードで動作することに注意してください。
mod_fastcgiを読むと、Djangoが flup を使用して作成していることがわかります。 mod_fastcgiによって提供される情報からのWSGI互換インターフェイス。パイプラインは次のように機能します。
Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)
Djangoには、いくつかの「django.core.handlers」があります。さまざまなインターフェース用。
mod_fastcgiの場合、DjangoはFLUPとハンドラーを統合する manage.py runfcgi
を提供します。
mod_wsgiには、このためのコアハンドラがあります。
WSGIサポートのインストール方法
これらの指示に従ってください。
https://code.google.com/archive/p/ modwsgi / wikis / IntegrationWithDjango.wiki
背景についてはこちらをご覧ください
http://docs.djangoproject.com/en / dev / howto / deployment /#howto-deployment-index
他のヒント
私は思う フロリアンの答え 特に次の記事を読んだ場合、「WSGI とは何ですか」という質問の部分に答えます。 PEP.
最後の方であなたが提起した質問については、次のとおりです。
WSGI、CGI、FastCGIなどWeb サーバーが実行するためのすべてのプロトコルです。 コードを実行する, 、作成された動的なコンテンツを配信します。これを静的 Web サービスと比較してください。静的 Web サービスでは、基本的にプレーン HTML ファイルがそのままクライアントに配信されます。
CGI、FastCGI、および SCGI は言語に依存しません。 CGI スクリプトは、Perl、Python、C、bash など何でも記述できます。CGI の定義 どれの URL に基づいて実行可能ファイルが呼び出され、 どうやって それは次のように呼ばれます:引数と環境。また、実行可能ファイルの終了後に戻り値を Web サーバーに戻す方法も定義します。バリエーションは基本的に、より多くのリクエストを処理したり、待ち時間を短縮したりできるようにするための最適化です。基本的なコンセプトは同じです。
WSGI は Python のみです。 言語に依存しないプロトコルではなく、標準の関数シグネチャが定義されています。
def simple_app(environ, start_response):
"""Simplest possible application object"""
status = '200 OK'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['Hello world!\n']
これは、完全な (制限がある場合) WSGI アプリケーションです。WSGI サポートを備えた Web サーバー (mod_wsgi を備えた Apache など) は、リクエストが到着するたびにこの関数を呼び出すことができます。
これが非常に優れている理由は、HTTP GET/POST から CGI、Python に変換し、途中で再度元に戻すという面倒な手順を回避できるためです。これは、より直接的でクリーンかつ効率的なリンクです。
また、リクエストに対して実行する必要があるのが関数呼び出しだけであれば、Web サーバーの背後で長時間実行されるフレームワークを実行することも非常に簡単になります。普通の CGI では、次のようにする必要があります。 フレームワーク全体を起動します 個々のリクエストごとに。
WSGI をサポートするには、WSGI モジュール (次のような) をインストールする必要があります。 mod_wsgi)、または WSGI が組み込まれた Web サーバーを使用します (例: チェリーパイ)。どちらも不可能な場合は、 できた PEP で指定された CGI-WSGI ブリッジを使用します。
Pep333が示すように、 CGIでWSGIを実行できます。例として。ただし、リクエストがあるたびに新しいPythonインタープリターが開始され、コンテキスト全体(データベース接続など)を構築する必要があり、すべて時間がかかります。
WSGIを実行する場合に最適なのは、ホストが mod_wsgi をインストールし、制御をアプリケーションに委ねるために適切な設定を行いました。
Flup は、 FCGI 、 SCGI またはAJP。私の経験では、FCGIのみが実際に機能し、 mod_fastcgi または mod_proxy_fcgi を使用して別のPythonデーモンを実行できる場合。
WSGI はCGIによく似たプロトコルであり、ウェブサーバーとPythonコードがどのように相互作用するかについての一連のルールを定義します。 Pep333 として定義されています。多くの異なるWebサーバーが、同じアプリケーションプロトコルを使用して、多くの異なるフレームワークとアプリケーションを使用できるようになります。これは非常に有益で非常に便利です。
この分野のすべての用語が不明確で、頭字語が混同されている場合は、CGI vs. FastCGI vs.を説明する公式のpython HOWTOの形式の良い背景読者がいます。 WSGIなど: http://docs.python.org/howto/webservers.html
これはPythonの単純な抽象化レイヤーであり、Javaのサーブレット仕様と似ています。 CGIは本当に低レベルであり、プロセス環境と標準の入出力に内容をダンプするだけですが、上記の2つの仕様はhttpリクエストとレスポンスを言語の構造としてモデル化します。しかし、私の印象では、Pythonの人々は事実上の実装にそれほど落ち着いていないので、参照実装と、WSGIサポートとともに他のものを提供する他のユーティリティタイプのライブラリ(ペーストなど)が混在しています。もちろん、私は間違っているかもしれません。私はPythonの初心者です。 「ウェブスクリプティング」コミュニティは、Javaの人々が(静的にコンパイルおよびデプロイされたコードに対して専用環境で単一のエンタープライズコンテナーを実行する)贅沢とは異なる方向(共有ホスティング、CGIレガシー、特権分離の懸念)から問題に直面しています。