mod_wsgi(Apache)
Apache Webサーバーを使用している場合は、 mod_wsgi の使用を検討してください。
気を付けて
アプリケーションファイルで発生する可能性のあるapp.run()
呼び出しが、if __name__ == '__main__':
ブロック内にあるか、別のファイルに移動されていることを事前に確認してください。 そのアプリケーションをmod_wsgiにデプロイした場合、不要なローカルWSGIサーバーが常に起動するため、呼び出されていないことを確認してください。
mod_wsgi をインストールしています
mod_wsgi がまだインストールされていない場合は、パッケージマネージャーを使用してインストールするか、自分でコンパイルする必要があります。 mod_wsgi インストール手順は、UNIXシステムでのソースインストールを対象としています。
Ubuntu / Debianを使用している場合は、次のようにapt-getしてアクティブ化できます。
# apt-get install libapache2-mod-wsgi
yumベースのディストリビューション(Fedora、OpenSUSEなど)を使用している場合は、次のようにインストールできます。
# yum install mod_wsgi
FreeBSDでは、 www / mod_wsgi ポートをコンパイルするか、pkg_addを使用して、 mod_wsgi をインストールします。
# pkg install ap22-mod_wsgi2
pkgsrcを使用している場合は、 www / ap2-wsgi パッケージをコンパイルして mod_wsgi をインストールできます。
最初のapacheのリロード後に、segfaultingの子プロセスに遭遇した場合は、それらを無視しても問題ありません。 サーバーを再起動するだけです。
.wsgi ファイルの作成
アプリケーションを実行するには、yourapplication.wsgi
ファイルが必要です。 このファイルには、アプリケーションオブジェクトを取得するために起動時に実行されているコード mod_wsgi が含まれています。 そのファイル内の application というオブジェクトがアプリケーションとして使用されます。
ほとんどのアプリケーションでは、次のファイルで十分です。
from yourapplication import app as application
アプリケーション作成用のファクトリ関数がなく、シングルトンインスタンスがある場合は、そのインスタンスを application として直接インポートできます。
そのファイルを再び見つかる場所(例:/var/www/yourapplication
)に保存し、 yourapplication と使用中のすべてのライブラリがPythonのロードパス上にあることを確認します。 システム全体にインストールしたくない場合は、仮想Python インスタンスの使用を検討してください。 実際にアプリケーションをvirtualenvにもインストールする必要があることに注意してください。 または、インポートする前に.wsgi
ファイルのパスにパッチを適用するオプションがあります。
import sys
sys.path.insert(0, '/path/to/the/application')
Apacheの構成
最後に行う必要があるのは、アプリケーション用のApache構成ファイルを作成することです。 この例では、セキュリティ上の理由から、 mod_wsgi に別のユーザーでアプリケーションを実行するように指示しています。
<VirtualHost *>
ServerName example.com
WSGIDaemonProcess yourapplication user=user1 group=group1 threads=5
WSGIScriptAlias / /var/www/yourapplication/yourapplication.wsgi
<Directory /var/www/yourapplication>
WSGIProcessGroup yourapplication
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
注:WSGIDaemonProcessはWindowsに実装されておらず、Apacheは上記の構成での実行を拒否します。 Windowsシステムでは、次の行を削除します。
<VirtualHost *>
ServerName example.com
WSGIScriptAlias / C:\yourdir\yourapp.wsgi
<Directory C:\yourdir>
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
注: Apache 2.4 のアクセス制御構成にいくつかの変更があります。
最も注目すべきは、ディレクトリ権限の構文がhttpd2.2から変更されたことです。
Order allow,deny
Allow from all
httpd2.4構文へ
Require all granted
詳細については、 mod_wsgiのドキュメントを参照してください。
トラブルシューティング
アプリケーションが実行されない場合は、次のガイドに従ってトラブルシューティングを行ってください。
- 問題:アプリケーションが実行されず、エラーログにSystemExitが無視されたことが示されます
if __name__ == '__main__':
条件で保護されていないapp.run()
呼び出しがアプリケーションファイルにあります。 そのrun()
呼び出しをファイルから削除して、別のrun.py
ファイルに移動するか、そのようなifブロックに配置します。- 問題:アプリケーションで権限エラーが発生する
おそらく、アプリケーションが間違ったユーザーとして実行されていることが原因です。 アプリケーションが適切な特権を設定するためにアクセスする必要のあるフォルダーを確認し、アプリケーションが正しいユーザーとして実行されるようにします( WSGIDaemonProcess ディレクティブの
user
およびgroup
パラメーター)- 問題:アプリケーションが印刷時にエラーで停止する
mod_wsgiは、
sys.stdout
およびsys.stderr
での操作を禁止していることに注意してください。 WSGIRestrictStdout をoff
に設定することにより、構成からこの保護を無効にできます。WSGIRestrictStdout Off
または、.wsgiファイルの標準出力を別のストリームに置き換えることもできます。
import sys sys.stdout = sys.stderr
- 問題:リソースにアクセスするとIOエラーが発生する
アプリケーションは、おそらく、site-packagesフォルダーにシンボリックリンクされた単一の.pyファイルです。 これは機能しないことに注意してください。代わりに、ファイルが保存されているpythonpathにフォルダーを配置するか、アプリケーションをパッケージに変換する必要があります。
これは、インストールされていないパッケージの場合、モジュールファイル名がリソースの検索に使用され、シンボリックリンクの場合、間違ったファイル名が取得されるためです。
自動リロードのサポート
デプロイメントツールを支援するために、自動リロードのサポートをアクティブ化できます。 .wsgi
ファイルが変更されるたびに、 mod_wsgi はすべてのデーモンプロセスをリロードします。
そのためには、 Directory セクションに次のディレクティブを追加するだけです。
WSGIScriptReloading On
仮想環境での作業
仮想環境には、必要な依存関係をシステム全体にインストールしないという利点があるため、どこで何を使用するかをより適切に制御できます。 mod_wsgiで仮想環境を使用する場合は、.wsgi
ファイルを少し変更する必要があります。
.wsgi
ファイルの先頭に次の行を追加します。
activate_this = '/path/to/env/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))
Python 3の場合、.wsgi
ファイルの先頭に次の行を追加します。
activate_this = '/path/to/env/bin/activate_this.py'
with open(activate_this) as file_:
exec(file_.read(), dict(__file__=activate_this))
これにより、仮想環境の設定に従ってロードパスが設定されます。 パスは絶対的なものでなければならないことに注意してください。