使用apache和mod_wsgi的多个django站点

Question

我想在使用Debian 5的同一台服务器下托管几个站点，比如我有site1 ， site2和site3 ，并假设我的ip是155.55.55.1 ：

site1: 155.55.55.1:80  , script at /opt/django/site1/
site2: 155.55.55.1:8080, script at /opt/django/site2/
site3: 155.55.55.1:8090, script at /opt/django/site3/

这是我的apache默认值：

<VirtualHost *:80>
    ServerName /
    ServerAlias  */
    DocumentRoot /opt/django/site1/
    LogLevel warn
    WSGIScriptAlias / /opt/django/site1/apache/django.wsgi
    Alias /media /opt/django/site1/media/statics
    Alias /admin_media  /home/myuser/Django-1.1/django/contrib/admin/media 
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot "/usr/share/phpmyadmin"
    ServerName /phpmyadmin
    Alias /phpmyadmin /usr/share/phpmyadmin
    <Directory /usr/share/phpmyadmin>
        Options Indexes FollowSymLinks
        AllowOverride None
        Order Deny,Allow
        Allow from all
    </Directory>
</VirtualHost>

这是我的wsgi配置为site1 ，位于/opt/django/site1/apache/django.wsgi ：

import os, sys
import django.core.handlers.wsgi

sys.path.append('/opt/django')
sys.path.append('/opt/django/site1')

os.environ['DJANGO_SETTINGS_MODULE'] = 'site1.settings'
application = django.core.handlers.wsgi.WSGIHandler()

如何添加site2和site3 ，它们是基于Django的站点，将像site1一样提供？

Answer 1

您的ServerName / ServerAlias指令是错误的。 ServerName应该是主机名。 您可能应该删除ServerAlias。

然后只需更改明显和重复的VirtualHost / Listen指令，只需更改文件系统中脚本的端口号和位置即可。

最后，不要将DocumentRoot设置为Django代码的位置，因为如果填充Apache配置，它会更容易意外地将源代码暴露给下载。 因此，只需从VirtualHost中删除Django站点的DocumentRoot指令即可。

Listen 80

<VirtualHost *:80>
ServerName www.example.com
WSGIScriptAlias / /opt/django/site1/apache/django.wsgi
Alias /media /opt/django/site1/media/statics
Alias /admin_media  /home/myuser/Django-1.1/django/contrib/admin/media

<Directory opt/django/site1/apache>
Order allow,deny
Allow from all
</Directory>

<Directory /home/myuser/Django-1.1/django/contrib/admin/media>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Listen 8080

<VirtualHost *:8080>
ServerName www.example.com
WSGIScriptAlias / /opt/django/site2/apache/django.wsgi
Alias /media /opt/django/site2/media/statics
Alias /admin_media  /home/myuser/Django-1.1/django/contrib/admin/media

<Directory opt/django/site2/apache>
Order allow,deny
Allow from all
</Directory>

<Directory /home/myuser/Django-1.1/django/contrib/admin/media>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Listen 8090

<VirtualHost *:8090>
ServerName www.example.com
WSGIScriptAlias / /opt/django/site3/apache/django.wsgi
Alias /media /opt/django/site3/media/statics
Alias /admin_media  /home/myuser/Django-1.1/django/contrib/admin/media

<Directory opt/django/site3/apache>
Order allow,deny
Allow from all
</Directory>

<Directory /home/myuser/Django-1.1/django/contrib/admin/media>
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

我还添加了缺少Directory指令以允许访问静态文件。 但是，您应该查看路径。

请务必阅读：

http://code.google.com/p/modwsgi/wiki/IntegrationWithDjango http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Hosting_Of_Static_Files

了解更多信息。

---

更新1

顺便说一句，既然你在同一个Apache中使用PHP，那么使用mod_wsgi守护进程模式并将每个Django实例推送到它自己的独立进程中会更好。 这允许这些进程是多线程的，即使主要的Apache进程因PHP而被强制为单线程。 与使用prefork MPM在嵌入式模式下在每个进程中运行多个Django实例相比，最终结果将使用更少的内存。 你的Django代码只需要线程安全。 除上述之外的配置是将WSGIDaemonProcess / WSGIProcessGroup添加到每个Django VirtualHost，其中守护进程组的名称对于每个VirtualHost是不同的。

<VirtualHost *:80>
WSGIDaemonProcess site1 display-name=%{GROUP}
WSGIProcessGroup site1
... existing stuff
</VirtualHost>

<VirtualHost *:8080>
WSGIDaemonProcess site2 display-name=%{GROUP}
WSGIProcessGroup site2
... existing stuff
</VirtualHost>

<VirtualHost *:8090>
WSGIDaemonProcess site3 display-name=%{GROUP}
WSGIProcessGroup site3
... existing stuff
</VirtualHost>

这也允许您更轻松地重新启动每个Django实例，而无需重新启动整个Apache。 读：

http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide#Delegation_To_Daemon_Process http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

Answer 2

将所有virtualHost配置放在一个地方工作正常，但Debian有自己的概念，将它们分别放在/ etc / apache2 / sites-available中每个站点的文件中，这些文件通过在../sites-enabled中进行符号链接来激活。 通过这种方式，服务器管理员还可以为每个站点管理员unix用户分配配置文件的单独访问权限，脚本可以检查站点是否处于活动状态等。

基本上，为Django-Admin安装提供一个中心方法是很好的，目前大量独立的文档，链接和博客文章对Django的扩散并没有多大帮助。