Django_-_podrobnoe_rukovodstvo

Если команде runfcgi передать единственный параметр help, она выведет список всех допустимых параметров.

Команде требуется передать либо один параметр socket, либо два параметра – host и port. А при настройке веб-сервера нужно будет указать на необходимость использовать соответствующий сокет или пару хост/ порт при запуске сервера FastCGI.

Поясним на примерах.

•• Запуск многопоточного сервера на TCP-порте:

./manage.py runfcgi method=threaded host=127.0.0.1 port=3033

•• Запуск сервера с несколькими процессами на UNIX-сокете:

./manage.py runfcgi method=prefork socket=/home/user/mysite.sock pidfile=django.pid

•• Запуск без перевода процесса в фоновый режим (удобно для отладки):

./manage.py runfcgi daemonize=false socket=/tmp/mysite.sock

Остановка процесса FastCGI

Чтобы остановить процесс, работающий в приоритетном режиме, достаточно нажать комбинацию клавиш Ctrl+C. А для завершения фонового процесса придется прибегнуть к команде UNIX kill.

Если при выполнении manage.py runfcgi был указан параметр pidfile, то для завершения процесса FastCGI можно набрать команду:

kill `cat $PIDFILE`1

где $PIDFILE – заданное вами значение параметра pidfile.

Чтобы упростить перезапуск демона FastCGI в UNIX, можно воспользоваться следующим сценарием оболочки:

#!/bin/bash

# Определите для следующих трех переменных свои значения. PROJDIR=”/home/user/myproject” PIDFILE=”$PROJDIR/mysite.pid” SOCKET=”$PROJDIR/mysite.sock”

cd $PROJDIR

if [ -f $PIDFILE ]; then kill `cat—$PIDFILE` rm –f $PIDFILE

fi

1Обратите внимание: здесь используются обратные апострофы! – Прим. науч. ред.

exec /usr/bin/env - \ PYTHONPATH=”../python:..” \

./manage.py runfcgi socket=$SOCKET pidfile=$PIDFILE

Использование Django совместно с Apache и FastCGI

Чтобы развернуть Django на платформе Apache + FastCGI, нужно установить и настроить Apache с модулем mod_fastcgi. Как это делается, можно узнать в документации на странице http://www.djangoproject. com/r/mod_fastcgi/.

Закончив базовую настройку, сообщите Apache, где находится экземпляр Django FastCGI, отредактировав конфигурационный файл httpd. conf. Нужно сделать две вещи:

•• С помощью директивы FastCGIExternalServer указать местоположение FastCGI-сервера.

•• С помощью модуля mod_rewrite перенаправить URL на FastCGI.

Определение местоположения FastCGI-сервера

Директива FastCGIExternalServer сообщает серверу Apache, где найти FastCGI­-сервер. Как поясняется в документации (http://www.django­ project.com/r/mod_fastcgi/FastCGIExternalServer/), допускается указывать один из двух параметров: socket или host. Приведем оба варианта:

# Соединиться с FastCGI через UNIX-сокет/именованный канал: FastCGIExternalServer /home/user/public_html/mysite.fcgi -socket /home/user/mysite.sock

#Соединиться с FastCGI через TCP-сокет, определяемый

#парой хост/порт:

FastCGIExternalServer /home/user/public_html/mysite.fcgi -host 127.0.0.1:3033

В любом случае должен существовать каталог /home/user/public_html/, хотя сам файл /home/user/public_html/mysite.fcgi может отсутствовать. Это просто URL, используемый веб-сервером для внутренних целей, – маркер, показывающий, какие URL должны обрабатываться FastCGIсервером (см. следующий раздел).

Использование mod_rewrite

для перенаправления URL на FastCGI

Далее нужно сообщить Apache, какие URL должны обрабатываться FastCGI-сервером. Для этого мы воспользуемся модулем mod_rewrite и перенаправим URL, соответствующие заданному регулярному выражению, на mysite.fcgi (или тот URL, который был указан в директиве FastCGIExternalServer, приведенной в предыдущем разделе).

В примере ниже мы говорим, что Apache должен передавать FastCGIсерверу запросы к любому URL, кроме статических файлов и адресов, начинающихся с /media/. Это, пожалуй, самый распространенный случай, если вы пользуетесь административным интерфейсом Django:

<VirtualHost 12.34.56.78> ServerName example.com

DocumentRoot /home/user/public_html

Alias /media /home/user/python/django/contrib/admin/media RewriteEngine On

RewriteRule ^/(media.*)$ /$1 [QSA,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^/(.*)$ /mysite.fcgi/$1 [QSA,L]

</VirtualHost>

FastCGI и lighttpd

lighttpd (http://www.djangoproject.com/r/lighttpd/) – это облегченный веб-сервер, который часто применяют для обслуживания статических файлов. Поскольку в него встроена поддержка FastCGI, то он является идеальным вариантом для обслуживания как статических, так и динамических страниц, если только вашему сайту не нужны возможности, доступные только в Apache.

Убедитесь, что mod_fastcgi находится в вашем списке модулей после mod_ rewrite и mod_access, но перед mod_accesslog. Для обслуживания мультимедийных файлов, используемых в административном интерфейсе, еще имеет смысл включить модуль mod_alias.

Добавьте в конфигурационный файл lighttpd такие строки:

server.document-root = “/home/user/public_html” fastcgi.server = (

“/mysite.fcgi” => ( “main” => (

#Для TCP fastcgi задавать host / port вместо socket

#“host” => “127.0.0.1”,

#“port” => 3033,

“socket” => “/home/user/mysite.sock”, “check-local” => “disable”,

)

),

)

alias.url = (

“/media/” => “/home/user/django/contrib/admin/media/”,

)

url.rewrite-once = ( “^(/media.*)$” => “$1”,

“^/favicon\.ico$” => “/media/favicon.ico”, “^(/.*)$” => “/mysite.fcgi$1”,

)

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ mysite.fcgi/$1 [QSA,L]

Затем создайте коротенький сценарий, который сообщит серверу Apache, как запускать вашу FastCGI-программу. Для этого создайте файл mysite.fcgi, поместите его в каталог своего сайта и не забудьте сделать его исполняемым:

#!/usr/bin/python import sys, os

#Настроить свой путь Python. sys.path.insert(0, “/home/user/python”)

#Перейти в каталог своего проекта. (Необязательно.)

#os.chdir(“/home/user/myproject”)

#Установить переменную окружения DJANGO_SETTINGS_MODULE. os.environ[‘DJANGO_SETTINGS_MODULE’] = “myproject.settings”

from django.core.servers.fastcgi import runfastcgi runfastcgi(method=”threaded”, daemonize=”false”)

Перезапуск порожденного процесса

После любого изменения Python-кода своего сайта необходимо сообщить об этом FastCGI-серверу. Но перезапускать Apache необязательно. Достаточно еще раз скопировать на сервер файл mysite.fcgi (или отредактировать его), чтобы изменилась его временная метка. Увидев, что файл изменился, Apache сам перезапустит приложение Django.

Если у вас имеется доступ к командной оболочке в UNIX, то можно просто воспользоваться командой touch:

touch mysite.fcgi

Масштабирование

Разобравшись с запуском Django на одном сервере, посмотрим, как можно масштабировать Django по горизонтали. Мы обсудим переход от одного сервера к крупномасштабному кластеру, способному обслуживать миллионы посещений в час.

Однако важно понимать, что у каждого крупного сайта есть свои особенности, поэтому не существует единой методики масштабирования на все случаи жизни. Мы старались познакомить вас с общими принципами, но всюду, где возможно, указываем, какие возможны варианты.

Сразу скажем, что речь пойдет исключительно о масштабировании на платформе Apache + mod_python. Хотя нам известно о ряде успешных опытов развертывания сайтов среднего и крупного масштаба с применением технологии FastCGI, сами мы все же лучше знакомы с Apache.

Запуск на одном сервере

Обычно новый сайт сначала запускается на одном сервере, и архитектура выглядит, как показано на рис. 12.1.

Django

База данных

Мультимедийные файлы Сервер

Рис. 12.1. Конфигурация Django на одном сервере

Такая конфигурация прекрасно подходит для небольших и средних сайтов и обходится сравнительно дешево – одиночный сервер для Djangoсайта можно приобрести менее чем за 3000 долларов.

Однако по мере увеличения трафика быстро наступает конкуренция за ресурсы между различными программными компонентами. Серверы базы данных и веб-серверы обожают захватывать все имеющиеся аппаратные ресурсы, поэтому при работе на одном компьютере они начинают конкурировать за оперативную память, процессор и т. д., которыми предпочли бы распоряжаться монопольно.

Эта проблема решается переносом сервера базы данных на другую машину, как объясняется в следующем разделе.

Выделение сервера базы данных

С точки зрения Django процедура выделения сервера базы данных чрезвычайно проста: достаточно лишь изменить его IP-адрес или доменное имя в параметре DATABASE_HOST. По возможности старайтесь идентифицировать сервер базы данных по IP-адресу, так как при идентификации по доменному имени приходится полагаться на безупречную работу DNS, а это не рекомендуется.

Архитектура с выделенным сервером базы данных выглядит, как показано на рис. 12.2.

Django

Мультимедийные файлы Веб сервер

База данных Сервер баз данных

Рис. 12.2. Перенос базы данных на отдельный сервер

Здесь начинается переход к так называемой n-уровневой архитектуре. Этот термин просто означает, что различные уровни прикладного стека физически располагаются на разных компьютерах.

Если вы понимаете, что один сервер базы данных скоро перестанет справляться с нагрузкой, то самое время задуматься об организации пула соединений и (или) репликации базы данных. К сожалению, нам не хватит места даже для поверхностного освещения этих вопросов, поэтому обратитесь к документации по своей СУБД или к сообществу.

Выделение сервера мультимедийного содержимого

У односерверной конфигурации есть еще одна проблема: обслуживание мультимедийных файлов тем же компьютером, который обслуживает динамическое содержимое.

Для оптимальной работы этих механизмов требуются разные условия, а при размещении на одной машине «тормозить» будут оба. Поэтому следующим шагом является организация отдельного компьютера для мультимедийного содержимого, то есть всего, что не генерируется Django (рис. 12.3).

В идеале на этом компьютере должен работать облегченный веб-сервер, оптимизированный для доставки статического мультимедийного содержимого. Отличными кандидатами являются lighttpd и tux (http:// www.djangoproject.com/r/tux/), но Apache в минимальной конфигурации тоже подойдет.

База данных Сервер баз данных

Рис. 12.3. Выделение сервера мультимедийного содержимого

Для сайтов с большим объемом статического содержимого (фотографии, видео и т. д.) выделение для него специального сервера вдвойне важно; это должно быть самым первым шагом масштабирования по вертикали.

Однако эта операция не вполне тривиальна. Если приложение поддерживает загрузку файлов на сервер, то Django должен иметь возможность записывать полученные файлы на сервер мультимедийного содержимого. Если же мультимедийные файлы хранятся на другом сервере, то необходимо настроить систему­ так, чтобы она могла передавать файлы через сеть.

Реализация балансирования нагрузки и резервирования

Сейчас мы разнесли все, что было можно. Такая конфигурация с тремя серверами способна справляться с весьма серьезными нагрузками, нам удавалось обрабатывать примерно 10 миллионов посещений в день. Если вы планируете дальнейший рост, то пора подумать о резервном оборудовании.

Это на самом деле полезно. Взгляните на рис. 12.3 – если любой из трех серверов выйдет из строя, перестанет работать весь сайт. Поэтому добавление избыточных серверов повышает не только пропускную способность, но и надежность.

Предположим, к примеру, что предела пропускной способности первым достигает веб-сервер. Относительно несложно разместить несколько копий Django-сайта – достаточно скопировать весь код на несколько компьютеров и на каждом запустить Apache.