All articles, tagged with “nginx”

Запуск django сайта через nginx + superfcgi

Я вчера перевёл все свои сайты на связку nginx + fastcgi-демон. Раньше они работали на связке nginx + apache/mod_wsgi. Даже не знаю, зачем я это сделал. Да и какая разница :o) Я сейчас просто опишу как соединять nginx с fastcgi-django-демонами через библиотеку superfcgi и надеюсь, кому-нибудь это будет полезно.

Так вот, для начала нада поставить superfcgi библиотеку. Кстати, её автор barbuza. Ставится банально: pip install superfcgi. Только не забудьте зависимости поставить предварительно. В debian надо ставить такие пакеты: gcc, python2.5-dev (если у вас 2.5 python), libfcgi-dev. Ещё надо multiprocessing либу поставить в случае python2.5, правда, Виктор говорит, что она уже автоматически ставиться. Но, если что, имейте в виду.

После установки superfcgi надо прописать ‘superfcgi’ в settings.INSTALLED_APPS. Это сделает доступной команду manage.py runserupfcgi, с помощью которой можно запустить процесс, который позволит общаться с nginx через fastcgi-интерфейс.

Проблема в том, что надо как-то контролировать этот процесс: уметь его останавливать, например. Команда manage.py runsuperfcgi этого не умеет, поэтому я использую дополнительный bash скрипт. Пощупать его можно тут: http://bitbucket.org/lorien/spawn/src/tip/spawn.sh

У меня для каждого сайта есть свой маленький spawn.sh, в котором я задаю одну переменную $SITE и затем делаю include главного spawn.sh. Например, для запуска веб-мозгов у меня такой скрипт:

#!/bin/bash
SITE="web_brains"
source /home/web/bin/spawn.sh

На всякий случай, если вдруг сайт упадёт или будет сделан rebot сервера у меня в кроне каждую минуту стартуются все сайты. Тупо, да, зато работает :D Конечно, если сайт уже запущен, то копия не запускается, в spawn.sh учтёт этот момент. Каждую минуту я пытаюсь запустить все сайты таким скриптом:

#!/bin/sh

dirs=$(find /home/web/web -maxdepth 1 -type d)
for dir in $dirs; do
    echo "Checking directory $dir"
    cd $dir;
    if [ -e spawn.sh ]; then
        echo "Found spawn.sh"
        ./spawn.sh $1
    fi
done

Кроме django-сайтов я запустил через superfcgi также один trac-проект. Для этого я сделал следующее, создал в директории проекта файл trac_wsgi.py

import os

os.environ['TRAC_ENV'] = '/web/pybb.org'
os.environ['PYTHON_EGG_CACHE'] = '/web/cache/trac/pybb.org'

import trac.web.main
app = trac.web.main.dispatch_request

Это просто создание WSGI приложения, обслуживающего trac-проект. Теперь его можно подцепить к superfcgi библиотеке. Библиотека superfcgi предоставляет команду superfcgi, которая в параметре —app принимает название модуля, где находится wsgi-приложение. Описываю я всё довольно сумбурно, но писать подробнее не могу — шибко лень :) Я просто это всё напишу здесь, потом кто-то будет искать через google, наткнётся, прочитает, что-то поймёт. Я сам иногда на свои старые посты натыкаюсь и иногда даже нахожу то, что успел забыть :D

В общем, spawn.sh файл для запуска trac такой:

#!/bin/sh
SITE="pybb"
SOCKET_FILE="/var/run/www/pybb.sock"
NOHUP="1"
COMMAND="superfcgi --workers 1 --threads 1 --app trac_wsgi.app --socket $SOCKET_FILE --path /web/pybb.org"
source /home/web/bin/spawn.sh

Ускоряем работу debug-сервера

Django debug сервер, который запускается через ./manage.py runserver, работает достаточно неторопливо. Это особо ощущается, когда он обслуживает запросы к статике. Конечно, такой подход удобен тем, что при разработке не нужно поднимать каких-то дополнительных серверов, но иногда эта канитель начинает раздражать. Дабы не тратить попусту нервы и время, можно возложуть груз ответственности за статику на плечи _____ (вписать имя вашего любимого веб-сервера).

Для начала создадим в /etc/hosts строку: 127.0.0.1 foobar.local

Далее, в settings_local.py пропишем:

MEDIA_URL = 'http://foobar.local/media/'
STATIC_URL = 'http://foobar.local/static/'

Потом идём в конфиг nginx и создаём новый сервер:

server {
    server_name .foobar.local;
    root /web/foobar; # это корень проекте, вернее каталога где лежит static каталог

    location /static {}
    location /favicon.ico {}

    location / {
        proxy_pass http://localhost:8000;
    }
}

Теперь запускаем debug сервер и радуемся — все запросы на статику обрабатываются боевым сервером :-)

Доступ к mercurial репозиторию через http

Ща я расскажу как раздавать mercurial репозиторий через тырнет.
Итак, мы имеем:
- nginx в роли веб-сервера, через который и будем раздавать репозиторий
- mercurial в роли mercurial
- flup в роли клея, с помощью которого мы замутим связь nginx и mercurial
- желание сделать всё с участием минимума скриптов и красиво, так чтобы веб-репозитории располагались на поддомене hg домена проекта.
 

Настройка awstats, nginx и logrotate

Я уже четыре раза раза устанавливал связку awstas & nginx & logrotate и у меня сложилось более-менее внятное понимание работы этой троицы, о чём бы я и хотел рассказать. В первую очередь статья предназначена тем людям, которые решат использовать awstats & nginx на своих VDS и dedicated серверах.
 

Разворачивание 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/.
 

Скрипт управления django fastcgi процессами

У меня на хостинге сейчас запущено несколько сайтов на Django. Директория каждого django-проекта называется web_site и лежит в одноимённой домену директории. Например, этот блог находится в /web/web-brains.com/web_site.

Такое расположение проектов позволяет мне легко управлять демонами этих сайтов.