Kilka witryn django z apache i mod_wsgi

Chcę umieścić kilka witryn z tym samym serwerem, który używa Debian 5 , Mówić , mam
site1

,
site2

i
site3

, i załóżmy, że mój ip - adres
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/


Tutaj jest mój apache domyślna:


<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 phpmyadmin="" share="" usr="">
Options Indexes FollowSymLinks
AllowOverride None
Order Deny,Allow
Allow from all
</directory>
</virtualhost>


Ale moja konfiguracja WSGI
site1

, na
/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//


Jak mogę dodać
site2

i
site3

, które są witrynami Django i będzie obsługiwany jako
site1

?
Zaproszony:

Władysław

Potwierdzenie od:

Twoje dyrektywy ServerName/ServerAlias Nieproduktywny. ServerName Musi istnieć nazwa hosta. Prawdopodobnie powinieneś po prostu usunąć ServerAlias.

Następnie po prostu daj oczywiste i duplikaty dyrektyw. VirtualHost/Listen, Wystarczy zmienić numer portu i lokalizację skryptów w systemie plików.

Wreszcie nie instaluj DocumentRoot gdzie jest twój kod Django, Ponieważ ułatwia losowe ujawnienie kodu źródłowego do pobrania, jeśli karmisz konfigurację Apache. Wystarczy usunąć dyrektywę DocumentRoot z VirtualHost dla Django witryny.


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 apache="" django="" opt="" site1="">
Order allow,deny
Allow from all
</directory>
<directory admin="" contrib="" django="" django-1.1="" home="" media="" myuser="">
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 apache="" django="" opt="" site2="">
Order allow,deny
Allow from all
</directory>
<directory admin="" contrib="" django="" django-1.1="" home="" media="" myuser="">
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 apache="" django="" opt="" site3="">
Order allow,deny
Allow from all
</directory>
<directory admin="" contrib="" django="" django-1.1="" home="" media="" myuser="">
Order allow,deny
Allow from all
</directory>
</virtualhost>


Dodałem również brakującą dyrektywę katalogów, aby umożliwić dostęp do plików statycznych. Należy jednak przejrzeć ścieżki.

Upewnij się, że czytasz:

http://code.google.com/p/modws ... jango
http://code.google.com/p/modws ... Files
Po więcej informacji.

UPDATE 1

BTW, Jak używasz PHP w tym samym Apache, Byłoby znacznie lepiej używać trybu demona mod_wsgi i popchnij każdą kopię Django W swoim oddzielnym procesie. Pozwala to na wielowątkowość tych procesów, nawet jeśli główne procesy Apache muszą być pojedyncze z powodu PHP. Efekt końcowy będzie znacznie mniej używany pamięci niż w przypadku rozpoczęcia wielu instancji. Django W każdym procesie w trybie wbudowanym z prefork MPM. Twój kod Django Powinien być po prostu bezpieczny w gwintach. Konfiguracja oprócz powyższego zostanie dodana WSGIDaemonProcess/WSGIProcessGroup Wszystkim Django VirtualHost, gdzie nazwa grupy procesu demonów różni się dla każdego 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>


Pozwala również łatwiej restartować każdą instancję. Django Bez ponownego uruchomienia całej instancji Apache. Czytać:

http://code.google.com/p/modws ... ocess
http://code.google.com/p/modws ... eCode

Lech

Potwierdzenie od:

Umieszczenie wszystkich konfiguracji virtualHost w jednym miejscu działa dobrze, ale Debian ma swoją własną koncepcję, dzieląc je w pliku dla każdej witryny /etc/apache2/sites-available, które są aktywowane przez symboliczne linki do nich ../sites-enabled.
W ten sposób administrator serwera może również przypisać oddzielne prawa dostępu do pliku konfiguracyjnego dla każdego z użytkowników. site-admin unix, Skrypty mogą sprawdzić, czy witryna jest aktywna itp.

Zasadniczo byłoby miło mieć jeden centralny howto Do instalacji Django-Admin, Obecny zestaw oddzielnych dokumentów, linków i artykułów w blogach nie jest bardzo przydatny do dystrybucji. Django.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się