Deploy the Python Django project to the Apache server in Linux

This article mainly introduces the key points of deploying the Python Django project to the Apache server. This article focuses on the wsgi connection method. If you need it, you can refer to the time spent in the next few days, I will deploy the web project developed by django on Apache. It took a lot of time to refer to some official documents and documents on the Internet. Here I will talk about the configuration process.
It is convenient for friends who need it. You can refer to it to avoid detours!
1. Deploy the django Project Environment
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: 2.5
It is assumed that Django and Apache have been installed, and Django projects have been developed.
The above software packages are all installed through the yum package, and the software packages are the standard system directory structure!
The project directory developed by django is/var/www/html/server. 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
Modify 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 
 

The django. wsgi file in the project directory needs to be created. We will discuss how to create this file later.
Standard configuration used by apache. Apache DocumentRoot points to the/var/www/html directory.
3. Create a django. wsgi File
Create a new django. wsgi under the project directory/var/www/html/server. The file content is as follows:

 #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()

　
Row 3: OS. environ ['django _ SETTINGS_MODULE '] = 'setting'. This setting refers to the setting. py file in the project directory.
Row 4 OS. environ ['python _ EGG_CACHE '] ='/tmp /. python-eggs ': Specifies the cache directory for extracting the egg file to ensure that the user running apache can read and write the directory.
Fifth, the six lines automatically add the current directory to the search path of python. If the project has a self-written module, it is easy to use and release.
Finally, this django. wsgi file names can be retrieved as needed, such as test. wsgi, app. wsgi and so on, but it must be consistent with/etc/httpd/conf. d/wsgi. the configuration in the conf configuration file must be consistent.
If the new file name is not django. wsgi but test. wsgi, the configuration in/etc/httpd/conf. d/wsgi. conf should be changed

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

4. Modify the setting. py file in the django Project
Find setting. py in the project directory. For this example,/var/www/html/server/setting. py. Find the TEMPLATE_DIRS and modify it:

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

Note: The template directory must use absolute paths instead of relative paths. Of course, there are also ways to dynamically set template paths.

PS: About mod_wsgi
Currently, mod_wsgi has two working modes:

The first is the embedded mode, which is similar to mod_python and runs directly in the apache process. The advantage is that the process does not need to be added, but the disadvantage is obvious. All the memory is shared with apache, if the same memory vulnerability as mod_python causes, the entire apache may be compromised. In addition, if apache uses worker mpm, mod_wsgi will be forced to enter the thread mode, which is useless for non-thread-safe programs.

In this mode, the following settings must be set in the apache vhost:

WSGIScriptAlias /path /path-to-wsgi

It takes effect. For small scripts, use this mode directly.

The second is the background mode. Similar to the FastCGI background, mod_wsgi will use the apache shell to start one or more processes and then communicate with apache processes through socket.

In this way, you only need to use the following Configuration:

# Start the WSGI background. site1 is the background name WSGIDaemonProcess site1 processes = 1 threads = 15 display-name =%{ GROUP} # specify which WSGI background should be used by the current context, you can put the WSGIProcessGroup site1 in the Location field # assign the WSGIScriptAlias/path-to-wsgi to the corresponding background based on the ProcessGroup of the current context

In this mode, we can adjust the values of processes and threads to set three MPM modes: prefork ', 'worker', and 'winnt '.

Winnt Mode

WSGIDaemonProcess example threads=25wsgi.multithread Truewsgi.multiprocess False

In this case, processes = 1, but multiprocess is false.

If it explicitly indicates 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

The backend mode is separated from the apache process, and the memory is independent. It can be restarted independently without affecting the apache process. If you have multiple projects (django ), you can create multiple backgrounds or use one background together.

For example, in the same VirtualHost, different paths correspond to different django projects, 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”

In this way, both django uses the same WSGI background.

You can also separate different projects and use different backend services separately. This means that the overhead is relatively large, but it will not be coupled together.

Display-name is the name of the background process, so that the corresponding process can be restarted without killing all processes.

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 earlier than django 1.0, since it is officially determined that it is not thread-safe, we recommend that you use the multi-process single-thread mode.

processes=n threads=1

After django 1.0, you can safely use the multi-process and multi-thread mode:

processes=2 threads=64

This will provide better performance.