Deploy Python's Django project to Apache server under Linux

It took some time these days to deploy the Django-developed Web project to Apache, referencing some official documents and documents on the Internet, or spending more time on the configuration process.
Convenient to have the need of friends, can refer to, less detours!
1. Django Project Deployment Environment description
Operating system: Red Hat Enterprise Linux Server Release 5.3 (Tikanga) x86_64
Apache Version: Httpd-2.2.3-22.el5
Mod_wsgi version: Mod_wsgi-3.2-1.el5 Fedora Epel can be downloaded
Django Version: 1.2.3
Python version: 2.5
This assumes that Django and Apache are already installed, and that the Django project is already well developed.
The above packages are installed through the Yum package, which is the system standard directory structure!
The Django-developed project directory is/var/www/html/server, and the project directory structure is as follows (standard Django project directory structure)

#tree-D server/server/|--__init__.py |--manage.py |--settings.py |--backend |--static |  | --Images |  | --Locale |  | --Plugins |  '--themes |    | --default |    |  '--Images |    | --Gray |    |  '--Images |    '--Icons |--template '--view

2. Apache and MOD_WSGI Configuration
Modifying the WSGI configuration (/etc/httpd/conf.d/wsgi.conf)

#cat/etc/httpd/conf.d/wsgi.conf  LoadModule wsgi_module modules/mod_wsgi.so wsgiscriptalias/"/var/www/html/ Server/django.wsgi "  
 
  
   
    Order deny,allow 
 
   allow from all

Django.wsgi in the project directory this file needs to be created, and later on how to create a new file.
The standard configuration used by Apache, Apache DocumentRoot points to the/var/www/html directory
3. Create a new Django.wsgi file
Create a new Django.wsgi under project directory/var/www/html/server, with the following file contents:

#cat/var/www/html/server/django.wsgi #-*-coding:utf-8-*-import os import sys os.environ[' django_settings_module '] = ' Settings ' os.environ[' python_egg_cache '] = '/tmp/.python-eggs ' Current_dir = Os.path.dirname (__file__) if Current_dir Not in Sys.path:sys.path.append (current_dir)  import DJANGO.CORE.HANDLERS.WSGI application = Django.core.handlers.wsgi.WSGIHandler ()

　
The third line os.environ[' django_settings_module ' = ' SETTINGS ', this SETTINGS refers to the setting.py file under the project directory.
Line four os.environ[' python_egg_cache ' = '/tmp/.python-eggs ', specify the CACHE directory to extract the EGG file, and ensure that the user running Apache can have read and write access to this directory.
Five, six will automatically add the current directory to the Python search path, if the project has its own written module, easy to use and publish
Finally, this DJANGO.WSGI file name can be arbitrarily taken, such as Test.wsgi, App.wsgi, and so on, but be sure to align with the configuration in the/etc/httpd/conf.d/wsgi.conf configuration file.
If the file name you created here is not Django.wsgi but Test.wsgi, then the configuration in/etc/httpd/conf.d/wsgi.conf should be modified to

Wsgiscriptalias/"/var/www/html/server/test.wsgi"

4. Modify the setting.py file in the Django project
Find the setting.py under the project directory, for this is/var/www/html/server/setting.py. Locate the Template_dirs, and modify it to:

Template_dirs = ("/var/www/html/server/template",)

Note: The template directory here must use absolute road strength, but not with the relative path, of course, there are methods to dynamically set the template road strength

PS: About MOD_WSGI
Currently MOD_WSGI has two modes of operation:

The first is the embed mode, similar to Mod_python, run directly in the Apache process, the benefit is not need to add additional process, but the disadvantage is also obvious, all memory and Apache share, if the same as mod_python caused by memory vulnerabilities, Will endanger the entire Apache. And if Apache is forced into threading mode with worker Mpm,mod_wsgi, it's not going to work for non-thread-safe programs.

This mode requires the following settings in Apache's vhost:

Wsgiscriptalias/path/path-to-wsgi

can take effect, for small scripts, you can use this mode directly.

The second is the background mode, similar to the background of fastcgi, MOD_WSGI will borrow Apache Shell, another start one or more processes, and then through the socket communication and Apache process contact.

This can be done using the following configuration:

#启动WSGI后台, Site1 is the background name wsgidaemonprocess site1 processes=1 threads=15 Display-name=%{group} #分配当前上下文应该使用哪个WSGI后台, Can be placed inside the location specify Wsgiprocessgroup site1# is assigned to the corresponding background wsgiscriptalias/path/path-to-wsgi based on the processgroup of the current context.

In this mode, we can set the three MPM modes by adjusting the values of processes and threads: prefork ', ' worker ', ' Winnt '.

Winnt mode

wsgidaemonprocess Example Threads=25wsgi.multithread truewsgi.multiprocess False

Processes=1 at this time, but Multiprocess is false

If you explicitly indicate that processes is 1 then:

wsgidaemonprocess example Processes=1 threads=25wsgi.multithread truewsgi.multiprocess True

Worker mode

wsgidaemonprocess example processes=2 threads=25wsgi.multithread truewsgi.multiprocess True

Preforker mode

wsgidaemonprocess example processes=5 threads=1wsgi.multithread falsewsgi.multiprocess True

Background mode because it is separated from the Apache process, memory independent, and can be restarted independently, will not affect the Apache process, if you have more than one project (Django), you can choose to set up multiple background or common use of a background.

For example, in the same virtualhost, different paths correspond to different Django projects, and you can use a daemon at the same time:

wsgidaemonprocess default Processes=1 Threads=1 display-name=%{group} wsgiprocessgroup default Wsgiscriptalias/ Project1 "/home/website/project1.wsgi" Wsgiscriptalias/project2 "/home/website/project2.wsgi"

This way two Django uses the same WSGI background.

You can also separate the different items, separate the use of different backgrounds, so the cost is relatively large, but will not be coupled together.

Display-name is the name of the background process, so it's easy to restart the corresponding process without having to kill it all.

Wsgidaemonprocess site1 processes=1 Threads=1 display-name=%{group} wsgidaemonprocess site2 Processes=1 Threads=1 Display-name=%{group} 
  
   
    
   wsgiprocessgroup site1
  
   wsgiscriptalias/project1 "/home/website/ Project1.wsgi " 
  
   
    
   wsgiprocessgroup site2
  
   wsgiscriptalias/project2"/home/website/ Project2.wsgi "

For versions under Django 1.0, it is recommended to use multi-process single-threaded mode because the official identification is not thread-safe

Processes=n Threads=1

For Django 1.0, you can use multi-process multithreaded mode with confidence:

processes=2 threads=64

The performance will be better in this way.

