механизм запуска django-приложения сервером на виртуальном хостинге

2

3

задавал этот вопрос на тематическом форуме, но ответа не получил, поэтому спрашиваю здесь. судя по соседним темам мой вопрос подходит к этому разделу

помогите пожалуйста разобраться в некоторых общих моментах при размещении на виртуальном(shared) хостинге. у меня сложилось некоторое представление и я его сейчас изложу. если в чём-то буду не прав, то пожалуйста укажите на ошибку. здесь элементарные вещи, но для меня они важны. ещё в конце будет небольшой вопрос

например есть хостинг под 1 сайт. обычно на таком хостинге есть каталог с вирт.окружением(.virtualenvs) и каталог для файлов django-проекта. в .bash_profile или другом подобном файле прописана переменная среды $WORKON_HOME, благодаря кооторой сервер знает какое вирт.окружение используется

сервер(apache, nginx или любой другой) имеет в конфиге секции типа <Virtualhost>. в каждой из них прописано правило, которое при запросе пользователем через браузер адреса определённого вида(например http://project.ru) отдаёт странички определённого django-проекта

то есть порядок такой:

1. пользователь ввёл адрес в адресную строку браузера
2. браузер выслал заголовки с запросом
3. сервер получил заголовки
4. сервер на основе конфига <Virtualhost> смотрит файл wsgi.py определённого проекта и берёт из этого файла значение переменной DJANGO_SETTINGS_MODULE
5. переменная DJANGO_SETTINGS_MODULE указывает на точку входа django-проекта(то есть на файл settings.py)
6. далее django-проект отдаёт сгенерированный html
7. сервер отдаёт браузеру html
8. браузер отрисовывает страницу в manage.py тоже есть DJANGO_SETTINGS_MODULE, указывающая на settings.py , но на работу сайта это не влияет. это нужно только программисту, если он задумает выполнять различные команды типа python manage.py collectstatic

таким образом при переносе проекта на другой хостинг кроме настройки среды возможно нужно будет менять значения только в трёх файлах:

settings.py,
wsgi.py,
manage.py

если я в общем описал процесс верно, то у меня вопрос такой: если используется виртуальный хостинг, которые рассчитан не на одно приложение, а на несколько, то каким образом организованы виртуальные окружения? например в этом случае в каталоге .virtualenvs будет несколько каталогов, соответствующих определённм виртуальным окружениям. для определённости пусть одно окружение настроено на использование python2.7, а другое - на python3.4. соответственно в каталогах файлов проекта существуют тоже 2 проекта(один работает под python2.7, другой работает под python3.4)

после того как сервер получит запрос от браузера пользователя как он узнает какое именно виртуальное окружение использовать для запуска django-приложения?

Ссылка

Да проще пареной репы ) Вот примерный конфиг для uWSGI:

[uwsgi]
vhost = true
plugins = python
socket = /tmp/mysite.su.sock
master = true
enable-threads = true
processes = 2
wsgi-file = /home/webapp/mysite/mysite/mysite/wsgi.py
virtualenv = /home/webapp/venv/mysite
chdir = /home/webapp/mysite/mysite
touch-reload = /home/webapp/mysite

Т.е. сервер uWSGI уже знает, какая virtualenv нужена для этого проекта. Так же при создании virtualenv можно указать отличный python от того, что стоит по умолчанию. И в созданной virtualenv python будем именно тот, который мы указали.

abc ★
(07.11.14 10:40:39 MSK)

И да, менять manage.py обычно никогда не было необходимости, да и wsgi.py тоже. А вот при создании проекта, лучше изменить settings.py чтобы он искал к примеру файлы вида production_settings.py и брал из них значения.

abc ★
(07.11.14 10:42:14 MSK)

сервер(apache

например есть хостинг под 1 сайт. обычно на таком хостинге

.htaccess

Options +ExecCGI
AddHandler wsgi-script .wsgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /index.wsgi/$1 [QSA,PT,L]

index.wsgi

import os 
import sys
sys.path.append('/path/to/app/') 
sys.path.append('/path/to/env/site-packages/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'app.settings'
from django.core.handlers import wsgi
application = wsgi.WSGIHandler()

ggrn ★★★★★
(07.11.14 11:23:01 MSK)
Последнее исправление: ggrn 07.11.14 11:23:33 MSK (всего исправлений: 1)

В WSGIDaemonProcess добавляю python-path с необходимым путем.

gruy ★★★★★
(07.11.14 15:16:14 MSK)

Похожие темы