---
title: "WSGI とともにデプロイするには"
version: 1.10
locale: ja
source: https://docs.djangoproject.com/ja/1.10/howto/deployment/wsgi/
canonical: https://djangodocs.dev/ja/1.10/howto/deployment/wsgi/
---
# WSGI とともにデプロイするには

Django の主要なデプロイプラットフォームは、 Web サーバと Web アプリケーション に関して Python の標準である [WSGI](http://www.wsgi.org) です。

Django の [`startproject`](/ja/1.10/ref/django-admin/#django-admin-startproject) 管理用コマンドはシンプルなデフォルトの WSGI 設定をセットアップします。必要に応じて、あなたのプロジェクトと WSGI 準拠の Web サーバに合わせて微調整することができます。

Django には以下の WSGI サーバのために、手引きとなるドキュメントが用意されています:

- [Django を Apache と `mod_wsgi` とともに使うには？](/ja/1.10/howto/deployment/wsgi/modwsgi/)
- [Django のユーザーデータベースに対する Apache からの認証](/ja/1.10/howto/deployment/wsgi/apache-auth/)
- [How to use Django with Gunicorn](/ja/1.10/howto/deployment/wsgi/gunicorn/)
- [How to use Django with uWSGI](/ja/1.10/howto/deployment/wsgi/uwsgi/)

## `application` オブジェクト

WSGI デプロイでキーとなる概念は、Web サーバがあなたのコードと通信するために使う `application` という呼び出し可能オブジェクトです。これは一般的に、サーバにアクセスできる Python モジュールの中で `application` という名前のオブジェクトとして提供されています。

[`startproject`](/ja/1.10/ref/django-admin/#django-admin-startproject) コマンドは、この `application` 呼び出し可能オブジェクトを含む `<project_name>/wsgi.py` ファイルを生成します。

これは、Django のデプロイサーバーによって、また WSGI デプロイプロダクションにおいて、これら両方で使われます。

WSGI サーバーは `application` 呼び出し可能オブジェクトへのパスを、その設定から取得します。Django のビルトインサーバー (要するに [`runserver`](/ja/1.10/ref/django-admin/#django-admin-runserver) コマンド) は、[`WSGI_APPLICATION`](/ja/1.10/ref/settings/#std-setting-WSGI_APPLICATION) の設定からこれを読み出します。デフォルトでは、 `<project_name>/wsgi.py` 内の `application` 呼び出し可能オブジェクトを指す \<project\_name\>.wsgi.application\` がセットされています。

## 設定モジュールを設定する

WSGI サーバがあなたのアプリケーションを読み込むとき、Django は設定モジュールをインポートする必要があります。そのモジュールは、あなたのあなたのアプリケーション全体が定義されている場所です。

Django uses the [`DJANGO_SETTINGS_MODULE`](/ja/1.10/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) environment variable to
locate the appropriate settings module. It must contain the dotted path to the
settings module. You can use a different value for development and production;
it all depends on how you organize your settings.

If this variable isn't set, the default `wsgi.py` sets it to
`mysite.settings`, where `mysite` is the name of your project. That's how
[`runserver`](/ja/1.10/ref/django-admin/#django-admin-runserver) discovers the default settings file by default.

> **Note**
>
> Since environment variables are process-wide, this doesn't work when you
> run multiple Django sites in the same process. This happens with mod\_wsgi.
>
> To avoid this problem, use mod\_wsgi's daemon mode with each site in its
> own daemon process, or override the value from the environment by
> enforcing `os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"` in
> your `wsgi.py`.

## Applying WSGI middleware

To apply [WSGI middleware](https://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides) you can simply wrap the application object. For
instance you could add these lines at the bottom of `wsgi.py`:

```
from helloworld.wsgi import HelloWorldApplication
application = HelloWorldApplication(application)
```

You could also replace the Django WSGI application with a custom WSGI
application that later delegates to the Django WSGI application, if you want
to combine a Django application with a WSGI application of another framework.

> **Note**
>
> Some third-party WSGI middleware do not call `close` on the response
> object after handling a request. In those cases the
> [`request_finished`](/ja/1.10/ref/signals/#django.core.signals.request_finished) signal isn't sent. This can
> result in idle connections to database and memcache servers.