mirror of
https://github.com/django/django.git
synced 2025-10-23 21:59:11 +00:00
Fixed #16360 -- Added WSGI entrypoint to startproject layout, and enabled internal servers (runserver and runfcgi) to use an externally-defined WSGI application. Thanks to Armin Ronacher, Jannis Leidel, Alex Gaynor, ptone, and Jacob Kaplan-Moss.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17022 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Carl Meyer
@@ -4,10 +4,9 @@ How to use Django with FastCGI, SCGI, or AJP
|
||||
|
||||
.. highlight:: bash
|
||||
|
||||
Although the current preferred setup for running Django is :doc:`Apache with
|
||||
mod_wsgi </howto/deployment/modwsgi>`, many people use shared hosting, on
|
||||
which protocols such as FastCGI, SCGI or AJP are the only viable options. In
|
||||
some setups, these protocols may provide better performance than mod_wsgi_.
|
||||
Although :doc:`WSGI</howto/deployment/wsgi/index>` is the preferred deployment
|
||||
platform for Django, many people use shared hosting, on which protocols such as
|
||||
FastCGI, SCGI or AJP are the only viable options.
|
||||
|
||||
.. admonition:: Note
|
||||
|
||||
@@ -20,13 +19,13 @@ serve pages to a Web server. The Web server delegates the incoming Web requests
|
||||
(via a socket) to FastCGI, which executes the code and passes the response back
|
||||
to the Web server, which, in turn, passes it back to the client's Web browser.
|
||||
|
||||
Like mod_wsgi, FastCGI allows code to stay in memory, allowing requests to be
|
||||
served with no startup time. While mod_wsgi can either be configured embedded
|
||||
in the Apache Web server process or as a separate daemon process, a FastCGI
|
||||
process never runs inside the Web server process, always in a separate,
|
||||
Like WSGI, FastCGI allows code to stay in memory, allowing requests to be
|
||||
served with no startup time. While
|
||||
e.g. :doc:`mod_wsgi</howto/deployment/wsgi/modwsgi>` can either be configured
|
||||
embedded in the Apache Web server process or as a separate daemon process, a
|
||||
FastCGI process never runs inside the Web server process, always in a separate,
|
||||
persistent process.
|
||||
|
||||
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
||||
.. _mod_perl: http://perl.apache.org/
|
||||
|
||||
.. admonition:: Why run code in a separate process?
|
||||
|
||||
@@ -9,13 +9,12 @@ ways to easily deploy Django:
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
modwsgi
|
||||
uwsgi
|
||||
wsgi/index
|
||||
fastcgi
|
||||
mod_python (deprecated) <modpython>
|
||||
|
||||
If you're new to deploying Django and/or Python, we'd recommend you try
|
||||
:doc:`mod_wsgi </howto/deployment/modwsgi>` first. In most cases it'll be
|
||||
:doc:`mod_wsgi </howto/deployment/wsgi/modwsgi>` first. In most cases it'll be
|
||||
the easiest, fastest, and most stable deployment choice.
|
||||
|
||||
.. seealso::
|
||||
|
||||
@@ -7,14 +7,14 @@ How to use Django with Apache and mod_python
|
||||
Support for mod_python has been deprecated, and will be removed in
|
||||
Django 1.5. If you are configuring a new deployment, you are
|
||||
strongly encouraged to consider using :doc:`mod_wsgi
|
||||
</howto/deployment/modwsgi>` or any of the other :doc:`supported
|
||||
backends </howto/deployment/index>`.
|
||||
</howto/deployment/wsgi/modwsgi>` or any of the other :doc:`supported
|
||||
servers </howto/deployment/index>`.
|
||||
|
||||
.. highlight:: apache
|
||||
|
||||
The `mod_python`_ module for Apache_ can be used to deploy Django to a
|
||||
production server, although it has been mostly superseded by the simpler
|
||||
:doc:`mod_wsgi deployment option </howto/deployment/modwsgi>`.
|
||||
:doc:`mod_wsgi deployment option </howto/deployment/wsgi/modwsgi>`.
|
||||
|
||||
mod_python is similar to (and inspired by) `mod_perl`_ : It embeds Python within
|
||||
Apache and loads Python code into memory when the server starts. Code stays in
|
||||
|
||||
@@ -1,147 +0,0 @@
|
||||
==========================================
|
||||
How to use Django with Apache and mod_wsgi
|
||||
==========================================
|
||||
|
||||
Deploying Django with Apache_ and `mod_wsgi`_ is the recommended way to get
|
||||
Django into production.
|
||||
|
||||
.. _Apache: http://httpd.apache.org/
|
||||
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
||||
|
||||
mod_wsgi is an Apache module which can be used to host any Python application
|
||||
which supports the Python WSGI interface described in :pep:`3333`, including
|
||||
Django. Django will work with any version of Apache which supports mod_wsgi.
|
||||
|
||||
The `official mod_wsgi documentation`_ is fantastic; it's your source for all
|
||||
the details about how to use mod_wsgi. You'll probably want to start with the
|
||||
`installation and configuration documentation`_.
|
||||
|
||||
.. _official mod_wsgi documentation: http://code.google.com/p/modwsgi/
|
||||
.. _installation and configuration documentation: http://code.google.com/p/modwsgi/wiki/InstallationInstructions
|
||||
|
||||
Basic configuration
|
||||
===================
|
||||
|
||||
Once you've got mod_wsgi installed and activated, edit your ``httpd.conf`` file
|
||||
and add::
|
||||
|
||||
WSGIScriptAlias / /path/to/mysite/apache/django.wsgi
|
||||
|
||||
The first bit above is the url you want to be serving your application at (``/``
|
||||
indicates the root url), and the second is the location of a "WSGI file" -- see
|
||||
below -- on your system, usually inside of your project. This tells Apache
|
||||
to serve any request below the given URL using the WSGI application defined by that file.
|
||||
|
||||
Next we'll need to actually create this WSGI application, so create the file
|
||||
mentioned in the second part of ``WSGIScriptAlias`` and add::
|
||||
|
||||
import os
|
||||
import sys
|
||||
|
||||
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
|
||||
|
||||
import django.core.handlers.wsgi
|
||||
application = django.core.handlers.wsgi.WSGIHandler()
|
||||
|
||||
If your project is not on your ``PYTHONPATH`` by default you can add::
|
||||
|
||||
path = '/path/to/mysite'
|
||||
if path not in sys.path:
|
||||
sys.path.append(path)
|
||||
|
||||
just below the ``import sys`` line to place your project on the path. Remember to
|
||||
replace 'mysite.settings' with your correct settings file, and '/path/to/mysite'
|
||||
with your own project's location.
|
||||
|
||||
.. _serving-files:
|
||||
|
||||
Serving files
|
||||
=============
|
||||
|
||||
Django doesn't serve files itself; it leaves that job to whichever Web
|
||||
server you choose.
|
||||
|
||||
We recommend using a separate Web server -- i.e., one that's not also running
|
||||
Django -- for serving media. Here are some good choices:
|
||||
|
||||
* lighttpd_
|
||||
* Nginx_
|
||||
* TUX_
|
||||
* A stripped-down version of Apache_
|
||||
* Cherokee_
|
||||
|
||||
If, however, you have no option but to serve media files on the same Apache
|
||||
``VirtualHost`` as Django, you can set up Apache to serve some URLs as
|
||||
static media, and others using the mod_wsgi interface to Django.
|
||||
|
||||
This example sets up Django at the site root, but explicitly serves
|
||||
``robots.txt``, ``favicon.ico``, any CSS file, and anything in the
|
||||
``/static/`` and ``/media/`` URL space as a static file. All other URLs
|
||||
will be served using mod_wsgi::
|
||||
|
||||
Alias /robots.txt /usr/local/wsgi/static/robots.txt
|
||||
Alias /favicon.ico /usr/local/wsgi/static/favicon.ico
|
||||
|
||||
AliasMatch ^/([^/]*\.css) /usr/local/wsgi/static/styles/$1
|
||||
|
||||
Alias /media/ /usr/local/wsgi/media/
|
||||
Alias /static/ /usr/local/wsgi/static/
|
||||
|
||||
<Directory /usr/local/wsgi/static>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
||||
<Directory /usr/local/wsgi/media>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
||||
WSGIScriptAlias / /usr/local/wsgi/scripts/django.wsgi
|
||||
|
||||
<Directory /usr/local/wsgi/scripts>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
||||
.. _lighttpd: http://www.lighttpd.net/
|
||||
.. _Nginx: http://wiki.nginx.org/Main
|
||||
.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
|
||||
.. _Apache: http://httpd.apache.org/
|
||||
.. _Cherokee: http://www.cherokee-project.com/
|
||||
|
||||
.. More details on configuring a mod_wsgi site to serve static files can be found
|
||||
.. in the mod_wsgi documentation on `hosting static files`_.
|
||||
|
||||
.. _hosting static files: http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Hosting_Of_Static_Files
|
||||
|
||||
.. _serving-the-admin-files:
|
||||
|
||||
Serving the admin files
|
||||
=======================
|
||||
|
||||
Note that the Django development server automagically serves the static files
|
||||
of the admin app, but this is not the case when you use any other server
|
||||
arrangement. You're responsible for setting up Apache, or whichever media
|
||||
server you're using, to serve the admin files.
|
||||
|
||||
The admin files live in (:file:`django/contrib/admin/static/admin`) of the
|
||||
Django distribution.
|
||||
|
||||
We **strongly** recommend using :mod:`django.contrib.staticfiles` to handle
|
||||
the admin files, but here are two other approaches:
|
||||
|
||||
1. Create a symbolic link to the admin static files from within your
|
||||
document root.
|
||||
|
||||
2. Or, copy the admin static files so that they live within your Apache
|
||||
document root.
|
||||
|
||||
Details
|
||||
=======
|
||||
|
||||
For more details, see the `mod_wsgi documentation on Django integration`_,
|
||||
which explains the above in more detail, and walks through all the various
|
||||
options you've got when deploying under mod_wsgi.
|
||||
|
||||
.. _mod_wsgi documentation on Django integration: http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango
|
||||
66
docs/howto/deployment/wsgi/gunicorn.txt
Normal file
66
docs/howto/deployment/wsgi/gunicorn.txt
Normal file
@@ -0,0 +1,66 @@
|
||||
===============================
|
||||
How to use Django with Gunicorn
|
||||
===============================
|
||||
|
||||
.. highlight:: bash
|
||||
|
||||
Gunicorn_ ('Green Unicorn') is a pure-Python WSGI server for UNIX. It has no
|
||||
dependencies and is easy to install and use.
|
||||
|
||||
.. _Gunicorn: http://gunicorn.org/
|
||||
|
||||
There are two ways to use Gunicorn with Django. One is to have Gunicorn treat
|
||||
Django as just another WSGI application. The second is to use Gunicorn's
|
||||
special `integration with Django`_.
|
||||
|
||||
.. _integration with Django: http://gunicorn.org/run.html#django-manage-py_
|
||||
|
||||
Installing Gunicorn
|
||||
===================
|
||||
|
||||
Installing gunicorn is as easy as ``pip install gunicorn``. For more details,
|
||||
see the `gunicorn documentation`_.
|
||||
|
||||
.. _gunicorn documentation: http://gunicorn.org/install.html
|
||||
|
||||
Running Django in Gunicorn as a generic WSGI application
|
||||
========================================================
|
||||
|
||||
When Gunicorn is installed, a ``gunicorn`` command is available which starts
|
||||
the Gunicorn server process. At its simplest, gunicorn just needs to be called
|
||||
with a the location of a WSGI application object.::
|
||||
|
||||
gunicorn [OPTIONS] APP_MODULE
|
||||
|
||||
Where ``APP_MODULE`` is of the pattern ``MODULE_NAME:VARIABLE_NAME``. The
|
||||
module name should be a full dotted path. The variable name refers to a WSGI
|
||||
callable that should be found in the specified module.
|
||||
|
||||
So for a typical Django project, invoking gunicorn would look like::
|
||||
|
||||
gunicorn myproject.wsgi:application
|
||||
|
||||
(This requires that your project be on the Python path; the simplest way to
|
||||
ensure that is to run this command from the same directory as your
|
||||
``manage.py`` file.)
|
||||
|
||||
|
||||
Using Gunicorn's Django integration
|
||||
===================================
|
||||
|
||||
To use Gunicorn's built-in Django integration, first add ``"gunicorn"`` to
|
||||
:setting:`INSTALLED_APPS`. Then run ``python manage.py run_gunicorn``.
|
||||
|
||||
This provides a few Django-specific niceties:
|
||||
|
||||
* sets the gunicorn process name to be that of the project
|
||||
|
||||
* validates installed models
|
||||
|
||||
* allows an ``--adminmedia`` option for passing in the location of the
|
||||
admin media files, mimicing the behavior of runserver.
|
||||
|
||||
See Gunicorn's `deployment documentation`_ for additional tips on starting and
|
||||
maintaining the Gunicorn server.
|
||||
|
||||
.. _deployment documentation: http://gunicorn.org/deploy.html
|
||||
72
docs/howto/deployment/wsgi/index.txt
Normal file
72
docs/howto/deployment/wsgi/index.txt
Normal file
@@ -0,0 +1,72 @@
|
||||
=======================
|
||||
How to deploy with WSGI
|
||||
=======================
|
||||
|
||||
Django's primary deployment platform is WSGI_, the Python standard for web
|
||||
servers and applications.
|
||||
|
||||
.. _WSGI: http://www.wsgi.org
|
||||
|
||||
Django's :djadmin:`startproject` management command sets up a simple default
|
||||
WSGI configuration for you, which you can tweak as needed for your project, and
|
||||
direct any WSGI-compliant webserver to use. Django includes getting-started
|
||||
documentation for the following WSGI servers:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
modwsgi
|
||||
gunicorn
|
||||
uwsgi
|
||||
|
||||
The ``application`` object
|
||||
--------------------------
|
||||
|
||||
One key concept of deploying with WSGI is to specify a central ``application``
|
||||
callable object which the webserver uses to communicate with your code. This is
|
||||
commonly specified as an object named ``application`` in a Python module
|
||||
accessible to the server.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
The :djadmin:`startproject` command creates a :file:`projectname/wsgi.py` that
|
||||
contains such an application callable.
|
||||
|
||||
.. note::
|
||||
|
||||
Upgrading from a previous release of Django and don't have a :file:`wsgi.py`
|
||||
file in your project? You can simply add one to your project's top-level
|
||||
Python package (probably next to :file:`settings.py` and :file:`urls.py`)
|
||||
with the contents below. If you want :djadmin:`runserver` to also make use
|
||||
of this WSGI file, you can also add ``WSGI_APPLICATION =
|
||||
"mysite.wsgi.application"`` in your settings (replacing ``mysite`` with the
|
||||
name of your project).
|
||||
|
||||
Initially this file contains::
|
||||
|
||||
import os
|
||||
|
||||
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
|
||||
|
||||
# This application object is used by the development server
|
||||
# as well as any WSGI server configured to use this file.
|
||||
from django.core.handlers.wsgi import get_wsgi_application
|
||||
application = get_wsgi_application()
|
||||
|
||||
The ``os.environ.setdefault`` line just sets the default settings module to
|
||||
use, if you haven't explicitly set the :envvar:`DJANGO_SETTINGS_MODULE`
|
||||
environment variable. You'll need to edit this line to replace ``mysite`` with
|
||||
the name of your project package, so the path to your settings module is
|
||||
correct.
|
||||
|
||||
To apply `WSGI middleware`_ you can simply wrap the application object
|
||||
in the same file::
|
||||
|
||||
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.
|
||||
|
||||
.. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides
|
||||
175
docs/howto/deployment/wsgi/modwsgi.txt
Normal file
175
docs/howto/deployment/wsgi/modwsgi.txt
Normal file
@@ -0,0 +1,175 @@
|
||||
==========================================
|
||||
How to use Django with Apache and mod_wsgi
|
||||
==========================================
|
||||
|
||||
Deploying Django with Apache_ and `mod_wsgi`_ is a tried and tested way to get
|
||||
Django into production.
|
||||
|
||||
.. _Apache: http://httpd.apache.org/
|
||||
.. _mod_wsgi: http://code.google.com/p/modwsgi/
|
||||
|
||||
mod_wsgi is an Apache module which can host any Python WSGI_ application,
|
||||
including Django. Django will work with any version of Apache which supports
|
||||
mod_wsgi.
|
||||
|
||||
.. _WSGI: http://www.wsgi.org
|
||||
|
||||
The `official mod_wsgi documentation`_ is fantastic; it's your source for all
|
||||
the details about how to use mod_wsgi. You'll probably want to start with the
|
||||
`installation and configuration documentation`_.
|
||||
|
||||
.. _official mod_wsgi documentation: http://www.modwsgi.org/
|
||||
.. _installation and configuration documentation: http://www.modwsgi.org/wiki/InstallationInstructions
|
||||
|
||||
Basic configuration
|
||||
===================
|
||||
|
||||
Once you've got mod_wsgi installed and activated, edit your Apache server's
|
||||
``httpd.conf`` file and add::
|
||||
|
||||
WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
|
||||
WSGIPythonPath /path/to/mysite.com
|
||||
|
||||
<Directory /path/to/mysite.com/mysite>
|
||||
<Files wsgi.py>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Files>
|
||||
</Directory>
|
||||
|
||||
The first bit in the ``WSGIScriptAlias`` line is the base URL path you want to
|
||||
serve your application at (``/`` indicates the root url), and the second is the
|
||||
location of a "WSGI file" -- see below -- on your system, usually inside of
|
||||
your project package (``mysite`` in this example). This tells Apache to serve
|
||||
any request below the given URL using the WSGI application defined in that
|
||||
file.
|
||||
|
||||
The ``WSGIPythonPath`` line ensures that your project package is available for
|
||||
import on the Python path; in other words, that ``import mysite`` works.
|
||||
|
||||
The ``<Directory>`` piece just ensures that Apache can access your
|
||||
:file:`wsgi.py` file.
|
||||
|
||||
Next we'll need to ensure this :file:`wsgi.py` with a WSGI application object
|
||||
exists. As of Django version 1.4, :djadmin:`startproject` will have created one
|
||||
for you; otherwise, you'll need to create it. See the :doc:`WSGI overview
|
||||
documentation</howto/deployment/wsgi/index>` for the default contents you
|
||||
should put in this file, and what else you can add to it.
|
||||
|
||||
Using a virtualenv
|
||||
==================
|
||||
|
||||
If you install your project's Python dependencies inside a `virtualenv`_,
|
||||
you'll need to add the path to this virtualenv's ``site-packages`` directory to
|
||||
your Python path as well. To do this, you can add another line to your
|
||||
Apache configuration::
|
||||
|
||||
WSGIPythonPath /path/to/your/venv/lib/python2.X/site-packages
|
||||
|
||||
Make sure you give the correct path to your virtualenv, and replace
|
||||
``python2.X`` with the correct Python version (e.g. ``python2.7``).
|
||||
|
||||
.. _virtualenv: http://www.virtualenv.org
|
||||
|
||||
Using mod_wsgi daemon mode
|
||||
==========================
|
||||
|
||||
"Daemon mode" is the recommended mode for running mod_wsgi (on non-Windows
|
||||
platforms). See the `official mod_wsgi documentation`_ for details on setting
|
||||
up daemon mode. The only change required to the above configuration if you use
|
||||
daemon mode is that you can't use ``WSGIPythonPath``; instead you should use
|
||||
the ``python-path`` option to ``WSGIDaemonProcess``, for example::
|
||||
|
||||
WSGIDaemonProcess example.com python-path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
|
||||
|
||||
.. _serving-files:
|
||||
|
||||
Serving files
|
||||
=============
|
||||
|
||||
Django doesn't serve files itself; it leaves that job to whichever Web
|
||||
server you choose.
|
||||
|
||||
We recommend using a separate Web server -- i.e., one that's not also running
|
||||
Django -- for serving media. Here are some good choices:
|
||||
|
||||
* lighttpd_
|
||||
* Nginx_
|
||||
* TUX_
|
||||
* A stripped-down version of Apache_
|
||||
* Cherokee_
|
||||
|
||||
If, however, you have no option but to serve media files on the same Apache
|
||||
``VirtualHost`` as Django, you can set up Apache to serve some URLs as
|
||||
static media, and others using the mod_wsgi interface to Django.
|
||||
|
||||
This example sets up Django at the site root, but explicitly serves
|
||||
``robots.txt``, ``favicon.ico``, any CSS file, and anything in the
|
||||
``/static/`` and ``/media/`` URL space as a static file. All other URLs
|
||||
will be served using mod_wsgi::
|
||||
|
||||
Alias /robots.txt /path/to/mysite.com/static/robots.txt
|
||||
Alias /favicon.ico /path/to/mysite.com/static/favicon.ico
|
||||
|
||||
AliasMatch ^/([^/]*\.css) /path/to/mysite.com/static/styles/$1
|
||||
|
||||
Alias /media/ /path/to/mysite.com/media/
|
||||
Alias /static/ /path/to/mysite.com/static/
|
||||
|
||||
<Directory /path/to/mysite.com/static>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
||||
<Directory /path/to/mysite.com/media>
|
||||
Order deny,allow
|
||||
Allow from all
|
||||
</Directory>
|
||||
|
||||
WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
|
||||
|
||||
<Directory /path/to/mysite.com/mysite>
|
||||
<Files wsgi.py>
|
||||
Order allow,deny
|
||||
Allow from all
|
||||
</Files>
|
||||
</Directory>
|
||||
|
||||
.. _lighttpd: http://www.lighttpd.net/
|
||||
.. _Nginx: http://wiki.nginx.org/Main
|
||||
.. _TUX: http://en.wikipedia.org/wiki/TUX_web_server
|
||||
.. _Apache: http://httpd.apache.org/
|
||||
.. _Cherokee: http://www.cherokee-project.com/
|
||||
|
||||
.. More details on configuring a mod_wsgi site to serve static files can be found
|
||||
.. in the mod_wsgi documentation on `hosting static files`_.
|
||||
|
||||
.. _hosting static files: http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Hosting_Of_Static_Files
|
||||
|
||||
.. _serving-the-admin-files:
|
||||
|
||||
Serving the admin files
|
||||
=======================
|
||||
|
||||
Note that the Django development server automatically serves the static files
|
||||
of the admin app (and any other installed apps), but this is not the case when
|
||||
you use any other server arrangement. You're responsible for setting up Apache,
|
||||
or whichever media server you're using, to serve the admin files.
|
||||
|
||||
The admin files live in (:file:`django/contrib/admin/static/admin`) of the
|
||||
Django distribution.
|
||||
|
||||
We **strongly** recommend using :mod:`django.contrib.staticfiles` (along with
|
||||
a Web server as outlined in the previous section) to handle the admin files, but
|
||||
here are three other approaches:
|
||||
|
||||
1. Create a symbolic link to the admin static files from within your
|
||||
document root (this may require ``+FollowSymLinks`` in your Apache
|
||||
configuration).
|
||||
|
||||
2. Use an ``Alias`` directive, as demonstrated above, to alias the appropriate
|
||||
URL (probably :setting:`STATIC_URL` + `admin/`) to the actual location of
|
||||
the admin files.
|
||||
|
||||
3. Copy the admin static files so that they live within your Apache
|
||||
document root.
|
||||
@@ -36,7 +36,7 @@ uWSGI model
|
||||
-----------
|
||||
|
||||
uWSGI operates on a client-server model. Your Web server (ie. nginx, Apache)
|
||||
communicates with a django-uwsgi "worker" process to serve dynamic contents.
|
||||
communicates with a django-uwsgi "worker" process to serve dynamic content.
|
||||
The Web server can communicate with the uWSGI process either:
|
||||
|
||||
* directly by the uWSGI protocol through a socket created by uWSGI,
|
||||
@@ -48,9 +48,9 @@ systems), or it can use a TCP socket. What you choose is a matterr of
|
||||
preference. Usually, a TCP socket is easier because connecting to a port
|
||||
doesn't require special permissions.
|
||||
|
||||
In the second case, the Web server doesn't need to do uWSGI protocol. It just
|
||||
needs to be able to proxy HTTP requests to the HTTP server built-in uWSGI.
|
||||
The procedure is the same than proxying any HTTP server. Note that the Web
|
||||
In the second case, the Web server doesn't need to speak the uWSGI protocol. It
|
||||
just needs to be able to proxy HTTP requests to the HTTP server built-in uWSGI.
|
||||
The procedure is the same as proxying to any HTTP server. Note that the Web
|
||||
server is a "reverse proxy" in this case.
|
||||
|
||||
Configuring the uWSGI server
|
||||
@@ -68,9 +68,9 @@ the uWSGI server.
|
||||
on that file.
|
||||
|
||||
uWSGI is highly configurable and thus there are many ways to start the
|
||||
process. For example, uwsgi version 0.9.6.8 provides a hundred switches.
|
||||
This guide demonstrates the most important of them, but does not intent to
|
||||
substitute the official manual and online documentation.
|
||||
process. For example, uwsgi version 0.9.6.8 provides a hundred switches. This
|
||||
guide demonstrates the most important of them, but is not a substitute the
|
||||
official manual and online documentation.
|
||||
|
||||
uWSGI supports configuration through:
|
||||
|
||||
@@ -98,8 +98,8 @@ uWSGI server. This means:
|
||||
|
||||
* the uWSGI server can be restarted or reloaded independently from the Web
|
||||
server,
|
||||
* (except with Cheerokee), it is the role of the system administrator to make
|
||||
uWSGI to start on boot or reboot: either through tools like supervisor or
|
||||
* (except with Cherokee), it is the role of the system administrator to make
|
||||
uWSGI start on boot or reboot: either through tools like supervisor or
|
||||
daemontools, either directly at init level in a file like /etc/rc.local or
|
||||
/etc/conf.d/local
|
||||
|
||||
@@ -109,11 +109,11 @@ Managing uWSGI
|
||||
Starting the server
|
||||
-------------------
|
||||
|
||||
Example command line for a Web server that understand the uWSGI protocol::
|
||||
Example command line for a Web server that understands the uWSGI protocol::
|
||||
|
||||
uwsgi --chdir=/path/to/your/project
|
||||
--module='django.core.handlers.wsgi:WSGIHandler()' \
|
||||
--env DJANGO_SETTINGS_MODULE=settings \
|
||||
--module='mysite.wsgi:application' \
|
||||
--env DJANGO_SETTINGS_MODULE=mysite.settings \
|
||||
--master --pidfile=/tmp/project-master.pid \
|
||||
--socket=127.0.0.1:49152 \ # can also be a file
|
||||
--processes=5 \ # number of worker processes
|
||||
@@ -125,17 +125,27 @@ Example command line for a Web server that understand the uWSGI protocol::
|
||||
--home=/path/to/virtual/env \ # optionnal path to a virtualenv
|
||||
--daemonize=/var/log/uwsgi/yourproject.log # background the process
|
||||
|
||||
Django specific options are:
|
||||
This assumes that you have a top-level project package named ``mysite``, and
|
||||
within it a module :file:`mysite/wsgi.py` that contains a WSGI ``application``
|
||||
object. This is the layout you will have if you ran ``django-admin.py
|
||||
startproject mysite`` (using your own project name in place of ``mysite``) with
|
||||
a recent version of Django. If this file does not exist, you'll need to create
|
||||
it. See the :doc:`/howto/deployment/wsgi/index` documentation for the default
|
||||
contents you should put in this file, and what else you can add to it.
|
||||
|
||||
* ``chdir``: should be the path to your project
|
||||
* ``module``: uwsgi module to use
|
||||
* ``pythonpath``: optional path to your project virtualenv
|
||||
* ``env``: should contain at least ``DJANGO_SETTINGS_MODULE``
|
||||
The Django-specific options here are:
|
||||
|
||||
* ``chdir``: the path to the directory that needs to be on Python's import path; i.e. the directory containing the ``mysite`` package.
|
||||
* ``module``: The WSGI module to use, probably the ``mysite.wsgi`` module which
|
||||
:djadmin:`startproject` creates.
|
||||
* ``env``: should probably contain at least ``DJANGO_SETTINGS_MODULE``
|
||||
* ``home``: optional path to your project virtualenv
|
||||
|
||||
Example ini configuration file::
|
||||
|
||||
[uwsgi]
|
||||
chdir=/path/to/your/project
|
||||
module='mysite.wsgi:application'
|
||||
master=True
|
||||
pidfile=/tmp/project-master.pid
|
||||
vacuum=True
|
||||
@@ -157,7 +167,7 @@ Read more `uWSGI configuration examples
|
||||
Reloading the daemon
|
||||
--------------------
|
||||
|
||||
As mentioned above, the uWSGI master process is one of the core component of
|
||||
As mentioned above, the uWSGI master process is one of the core components of
|
||||
the uWSGI stack. The signal to brutally reload all the workers and the master
|
||||
process is SIGTERM. Example command to brutally reload the uWSGI processes::
|
||||
|
||||
@@ -167,7 +177,7 @@ Patching the daemon
|
||||
-------------------
|
||||
|
||||
One of the great advantages of uWSGI is its ability to gradually restart each
|
||||
worker without loosing any request.
|
||||
worker without losing any requests.
|
||||
|
||||
For example, uWSGI can be signaled that worker should reload the code after
|
||||
handling their current request (if any) from bash::
|
||||
@@ -236,7 +246,7 @@ still experimental.
|
||||
Troubleshooting
|
||||
===============
|
||||
|
||||
As usual, the first things to do is to check the logs. This implies:
|
||||
As usual, the first thing to do is to check the logs. This implies:
|
||||
|
||||
* the web server log, which will indicate if it couldn't connect to the uWSGI
|
||||
process,
|
||||
@@ -251,5 +261,5 @@ Typical gotchas:
|
||||
killed with ``SIGKILL``, it won't remove the socket and pidfile when it is
|
||||
interrupted. It is safe to remove them manually and to start uWSGI again in
|
||||
that case.
|
||||
* uWSGI can start the process on the foreground, this will make errors easily
|
||||
* uWSGI can start the process in the foreground, this will make errors easily
|
||||
visible to the system administrator.
|
||||
Reference in New Issue
Block a user