Разворачивание django-приложения под сервером nginx
В этой статье я расскажу о том, как перенести ваш django-проект на боевой сервер под управлением nginx. Допустим, наш сайт называется foo.ru, а проект мы будем хранить в каталоге /web/foo.ru/web_site. Скопируем все файлы на сервер в этот каталог и сделаем syncdb. Теперь надо проверить, чтобы переменная TEMPLATE_DIRS в settings.py содержала абсолютные пути. Хотя отладочный сервер Django позволяет использовать относительные имена в этой переменной, под nginx это вызовет ошибку при загрузке шаблонов. Настройка MEDIA_ROOT тоже должна содержать абсолютный путь. Допустим, она равна /web/foo.ru/web_site/pub/.
Осталось настроить nginx. Я не буду вдаваться в подробности установки и конфигурации nginx, как такового. Если у вас возникнут какие-то проблемы или вопросы, то рекомендую почитать следующие источники информации:
- Официальная документация на nginx
- Серия статей о nginx на блоге Алексея Ковырина
- Архив списка рассылки nginx-ru
Итак, создадим в конфиге nginx описание нашего сайта. У себя на VDS я храню описания сайтов в отдельных файлах в каталоге /etc/nginx/vhost. Напишем в /etc/nginx/vhost/foo.ru следующее:
Содержимое файла /etc/nginx/fastcgi.conf. В основном это команды, устанавливающие переменные окружения. Если будете настраивать Django на чужом сервере с уже установленным ngix, обязательно проверьте, есть ли в конфиге переменная PATH_INFO. Без неё ничего не будет работать, а в типичной конфигурации для php fastcgi процессов эта переменная может запросто отсутствовать.
Пара слов о сокет файле, который слушает fastcgi-демон сайта. Nginx не умеет сам запускать fastcgi-процессы (как lighttpd), поэтому мы должны сами позаботиться об этом. Команда manage.py runfcgi запускает fastcgi-демон django-сайта. Весьма удобно автоматизировать этот процесс, поставив вызов по крону скрипта, который будет проверять существование демона и загружать его в случае надобности. Здесь я уже показывал скрипт, которым пользуюсь на своём сервере.
Усё. Конец статьи.
Осталось настроить nginx. Я не буду вдаваться в подробности установки и конфигурации nginx, как такового. Если у вас возникнут какие-то проблемы или вопросы, то рекомендую почитать следующие источники информации:
- Официальная документация на nginx
- Серия статей о nginx на блоге Алексея Ковырина
- Архив списка рассылки nginx-ru
Итак, создадим в конфиге nginx описание нашего сайта. У себя на VDS я храню описания сайтов в отдельных файлах в каталоге /etc/nginx/vhost. Напишем в /etc/nginx/vhost/foo.ru следующее:
server {
# первая точка означает, что надо обрабатывать домен и все его поддомены
server_name .foo.ru;
# каталог с файлами нашего проекта, эта директива нужна для того, чтобы отдавать nginx'ом статические файлы из каталога MEDIA_ROOT
root /web/foo.ru/web_site;
# Логи доступа и ошибок
access_log /var/log/www/foo.ru-access.log;
error_log /var/log/www/foo.ru-error.log;
# Типовая конфигурация виртуального хоста на вашем сервере
# В простейшем случае в этом файле будет одна строка: listen 80
include /etc/nginx/vhost-default.conf;
# Настройки FASTCGI, об этом читайте ниже
include /etc/nginx/fastcgi.conf;
# location должно быть равно переменной ADMIN_MEDIA_PREFIX в settings.py
location /media {
# каталог в котором содержатся статические файлы админ-панели
# скорее всего у вас будет другой путь
root /web/django_src/django/contrib/admin;
}
# location должно быть равно переменной MEDIA_URL в settings.py
# мы специально указываем этот location отдельным блоком, чтобы nginx не передавал запросы в fastcgi-демону, а обрабатывал сам
location /pub/ {}
# а здесь мы говорим о том, что все запросы следует перенаправлять в сокет, который слушает fastcgi-процесс сайта foo.ru
location / {
fastcgi_pass unix:/var/run/www/foo.ru.sock;
}
}
Содержимое файла /etc/nginx/fastcgi.conf. В основном это команды, устанавливающие переменные окружения. Если будете настраивать Django на чужом сервере с уже установленным ngix, обязательно проверьте, есть ли в конфиге переменная PATH_INFO. Без неё ничего не будет работать, а в типичной конфигурации для php fastcgi процессов эта переменная может запросто отсутствовать.
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Пара слов о сокет файле, который слушает fastcgi-демон сайта. Nginx не умеет сам запускать fastcgi-процессы (как lighttpd), поэтому мы должны сами позаботиться об этом. Команда manage.py runfcgi запускает fastcgi-демон django-сайта. Весьма удобно автоматизировать этот процесс, поставив вызов по крону скрипта, который будет проверять существование демона и загружать его в случае надобности. Здесь я уже показывал скрипт, которым пользуюсь на своём сервере.
Усё. Конец статьи.



















Comments
Спасибо за статью! Сейчас буду пробовать :-)
Только комментарии в файле конфигурации сложно читать. Надо бы разбить их на несколько строк.
Сложно читать где? В текстовом редакторе или на блоге?
На блоге. В Мозилле длинные строчки комментариев наезжают на блок ссылок справа. Да и в Эксплорере смотрится не супер.
Разбить не получится это же код… Бог его знает, будет ли это просто текст или строка кода, которая после разбиения станет мусором. В принципе, я виже только такое решение назначить блоку кода стиль scroll: auto; который будет скрывать выступающую за гринцы блока информацию, позволяя получить к ней доступ с помощью элемента прокрутки в нижней части блока.