Установка Django 1.5 + PostgreSQL + Nginx в Debian
Устанавливалось на Debian 6.0.6, в репозиториях был только Python 2.6.6. Не стал заморачиваться на Python 2.7. Хотя рекомендуется обновить до 2.7.3 или выше. Также Django 1.5 поддерживает Python 3, особенно 3.2 и выше. Предполагается, что работы ведем под учетной записью суперпользователя.
Предварительно требуется установить систему контроля версий git:
aptitude install git
Установка и настройка PostgreSQL:
aptitude install postgresql
Сразу после установки запускается. В данном случае установилась версия 8.4.
Проверка:
netstat -tanp | grep postgre
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 16394/postgres
Создаем пользователя:
su postgres createuser username
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
Задаем пароль пользователю:
psql template1
psql (8.4.13)
Type "help" for help.
template1=#
alter user username password 'user';
ALTER ROLE
Задаем пароль суперпользователю баз данных:
ALTER ROLE postgres WITH ENCRYPTED PASSWORD 'megapass';
ALTER ROLE
\q
Создаем базу данных для пользователя username:
createdb basename --owner=username -hlocalhost
Ловим ошибку:
createdb: could not connect to database postgres: FATAL: no pg_hba.conf entry for host "10.78.89.142", user "postgres", database "postgres", SSL on
FATAL: no pg_hba.conf entry for host "10.78.89.142", user "postgres", database "postgres", SSL off
Выходим на уровень пользователя root, правим конфиг и рестартим сервис:
exit echo "host all all 10.78.89.142/32 trust" >> /etc/postgresql/8.4/main/pg_hba.conf service postgresql restart
Здесь добавляем возможность доступа с айпишника системы. На другой системе нужно будет выставить другой айпишник.
Далее снова заходим под пользователя postgres и повторяем создание базы данных:
su postgres createdb basename --owner=username -hlocalhost
Если спросит пароль, то используется пароль для суперпользователя postgres.
Если вы установили более новую версию PostgreSQL, к примеру, 9.1, то описанной выше проблемы быть не должно.
Пробуем подключиться к базе:
psql -Uusername -W -hlocalhost basename
Password for user podvesnoy:
psql (8.4.13)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
podvesdb=>
Все, с базой данных разобрались.
Установка Django 1.5:
Создаем директорию под сайт, устанавливаем права:
mkdir /var/www/django chown www-data:www-data /var/www/django cd /var/www/
Скачиваем движок и устанавливаем его:
su www-data git clone https://github.com/django/django.git exit cd ./django python setup.py build python setup.py install
Для запуска Django как FastCGI-сервера понадобится flup:
aptitude install python-flup
Создаем новый проект:
django-admin.py startproject djangoproject chown -R www-data:www-data djangoproject/
Запускаем FastCGI сервер:
./djangoproject/manage.py runfcgi method=threaded host=127.0.0.1 port=3033
Проверяем:
netstat -tanp | grep python
tcp 0 0 127.0.0.1:3033 0.0.0.0:* LISTEN 15748/python
Установка и настройка nginx:
aptitude install nginx
Из стандартных репов установился 0.7.67-3 что не густо, конечно.
Создаем конфиг виртуального хоста:
nano /etc/nginx/sites-available/django
Содержимое следующее:
upstream djangoserv {
server 127.0.0.1:3033;
}
server {
listen 80;
server_name domain.com;
root /var/www/django/djangoproject;
access_log /var/www/django/logs/access.log;
error_log /var/www/django/logs/error.log;
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js|mov)
{
access_log off;
expires 30d;
}
location / {
fastcgi_pass djangoserv;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param SERVER_NAME $server_name;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
fastcgi_pass_header Authorization;
fastcgi_intercept_errors off;
}
}
После чего делаем symlink и включаем конфиг для нового виртуального хоста, создаем папку с логами и выставляем ей нужного владельца (www-data), после чего перезагружаем nginx:
ln -s /etc/nginx/sites-available/django /etc/nginx/sites-enabled/django mkdir /var/www/django/logs touch /var/www/django/logs/access.log touch /var/www/django/logs/error.log chown -R www-data:www-data /var/www/django/logs /etc/init.d/nginx reload
Проверяем чтобы nginx запустился, после чего открываем сайт в браузере по айпишнику или по доменному имени.
Видим:
“It worked! Congratulations on your first Django-powered page.”
Настраиваем подключение к базе данных:
nano /var/www/django/djangoproject/djangoproject/settings.py
Правим:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'basename',
'USER': 'username',
'PASSWORD': 'user',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
Затем создаем таблицы в базе:
cd /var/www/django/djangoproject python manage.py syncdb
По ходу предложит создать суперпользователя. Имя пользователя - admin, пароль - adminpass или любой другой.
Перезапускаем FastCGI-сервер:
ps ax | grep 3033 | grep -v grep | awk '{print $1}' | xargs kill -9
/var/www/django/djangoproject/manage.py runfcgi method=threaded host=127.0.0.1 port=3033
Пытаемся открыть админку в браузере по адресу http://ip.ad.re.ss/admin/ и видим, что статика не отображается. Кайфуем. Взыв мозга с этой статикой обеспечен.
Лечится так.
Необходимо в файле /var/www/django/djangoproject/djangoproject/settings.py прописать путь до диектории со статикой:
STATIC_ROOT = '/var/www/django/djangoproject/static/'
Собираем статику в эту директорию с помощью команды:
/var/www/podvesnoy/podvesproject/manage.py collectstatic
Однако проблема не совсем решена, так как в разработке удобнее использовать встроенный сервер в связи с тем, что для того чтобы увидеть изменения через nginx, требуется перезапустить FastCGI-сервер, а при использовании встроенного сервера, статика в админке так и не отображается. В общем, нужен опытный джангист для консультации.
Для облегчения разработки добавляем в cron команду на регулярное убивание FastCGI сервера и его запуск. На стадии продакшена нужно будет убрать.
Точнее, напишем скрипт из пары строк и добавим его в систему для удобства использования.
Итак, с помощью вашего любимого текстового редактора создаем файл в директории /usr/local/bin с удобным вам названием, к примеру, pdev, примерно следующего содержания:
#!/bin/bash
ps ax | grep 3033 | grep -v grep | awk '{print $1}' | xargs kill -1
python /var/www/django/djangoproject/djangoproject/manage.py runfcgi method=threaded host=127.0.0.1 port=3033
Здесь указываем путь до файла manage.py вашего проекта на джанго, а также нужный порт. Если у вас на одно машине запущена продакшн-версия сайта и версия для разработки, то можно запустить два FastCGI-сервера на разных портах и с помощью nginx направить их на разные домены или поддомены.
Задаем владельца:
chown root:staff /usr/local/bin/pdev
Устанавливаем права:
chmod 755 /usr/local/bin/pdev
Далее, делаем симлинк файла pdev из директории /usr/local/bin в /usr/bin:
ln -s /usr/local/bin/pdev /usr/bin/pdev
Таким образом перезапуск FastCGI-сервера Django можно будет осуществлять одной командой.
Добавляем в cron:
crontab -e * * * * * pdev
Теперь перезапуск сервера Django будет происходить раз в минуту, чего вполне достаточно для неспешной разработки, тем более, что перезапуск можно осуществить вручную. Стоит напомнить, что такой вариант подходит только на этапе разработки либо если запущено два отдельных проекта один из которых работает без регулярного перезапуска.
Кстати, так как Ubuntu основан на Debian, то всё описанное выше будет работать и под Ubuntu, только вы получите более современные версии PostgreSQL и Nginx.
Если будут вопросы или дополнения (например, про статику в сервере для разработки), то вы можете оставить их в комментариях ниже.
Опубликовано