Хочу рассказать вам, друзья, о том как сделать связку nginx+apache для друпала. Это будет не просто связка. Это будет очень универсальный, работающий в условиях мультисайтинга, доменов третьего уровня и нестандартных портов (например у меня 6969 и на нем висит виртуальный сервер) конфиг. Еще эта связка будет иметь мегакэширование страниц для анонимов - без всяких дополнительных модулей drupal firebug выдает время загрузки страници порядка 80ms (разумеется на виртуальном сервере в локальной сети).
Рабочая лошадка: ubuntu server 9.04
Условия: apache, php, mysql, php-apc, drupal уже имеются и все работает. Drupal лежит в /var/www/d6. На drupal'е через мультисайтинг висят сайты site.ru, site2.ru (из локальной сети у меня они имеют адрес следующего вида: http://localhost.site.ru:6969/, http://localhost.subsite.site.ru:6969/, я это к тому, что и в таких нестандартых условиях все будет работать как надо).
Установка: в репозиторях ubuntu nginx несвеж, а нам нужен первачек. Делаем так:
echo "deb http://ppa.launchpad.net/jdub/ppa/ubuntu hardy main" >> /etc/apt/sources.list
aptitude update
aptitude install nginx
Конфингурация apache2:
В /etc/apache2/ports.conf правим порты на 8080.
Listen 8080
Создаем /etc/apache2/sites-enabled/d6:
ServerName site.ru
DocumentRoot /var/www/d6
ServerAlias *.site.ru
</VirtualHost>
<VirtualHost *:8080>
ServerName site2.ru
DocumentRoot /var/www/d6
ServerAlias *.site2.ru
</VirtualHost>
Думаю здесь все ясно и в комментариях не нуждается.
Конфингурация nginx:(больше не актуальна, смотрим здесь )
Создаем /etc/nginx/sites-enabled/d6:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=one:20m;
proxy_temp_path /var/cache/nginx/temp;
proxy_cache_valid any 10m;
server {
server_name .site.ru .site2.ru;
set $cached 0;
listen *:80;
#нужно чтобы отдавать красивую 500 ошибку с себя
error_page 502 503 504 509 /500.html;
#если где-то что-то забыли, то будет работать схема прозрачного проксирования
error_page 404 = [user=nocached]nocached[/user];
expires epoch;
root /var/www/d6;
rewrite ^(/manager/.*)$ https://$http_host$1 permanent;
#статику будем брать с frontend и если отсутствует, то скачивать
location ~* ^.+\.(jpg|jpeg|gif|gz|zip|flv|rar|wmv|avi|css|swf|png|htc|ico|mpeg|mpg|txt|mp3|mov|js|ttf)$ {
expires 1y;
error_page 404 = [user=cached]cached[/user];
}
#кэшируем статику на себя
location [user=fetch]fetch[/user] {
proxy_pass http://127.0.0.1:8080;
proxy_store on;
proxy_temp_path /var/cache/nginx/temp;
proxy_set_header Host mydomain;
proxy_set_header If-Modified-Since "";
}
#для зарегистрированных проксируем прозрачно
location [user=nocached]nocached[/user] {
proxy_pass http://127.0.0.1:8080;
proxy_redirect default;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
#гостям проксируем и кэшируем
location [user=cached]cached[/user] {
proxy_pass http://127.0.0.1:8080;
proxy_redirect default;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache one;
proxy_cache_valid 200 301 302 304 5m;
proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
proxy_hide_header "Set-Cookie";
proxy_ignore_headers "Cache-Control" "Expires";
}
#иначе морда домена не будет работать
location = / {
return 404;
}
location / {
#если нет нашей куки
if ($http_cookie !~ "DRUPAL_UID" ) {
set $cached 1;
}
if ($request_method = POST) {
set $cached 0;
}
if ($request_method != GET) {
set $cached 0;
}
if ($cached = 1) {
error_page 404 405 502 504 = [user=cached]cached[/user];
break;
}
if ($cached = 0) {
error_page 404 405 502 504 = [user=nocached]nocached[/user];
break;
}
}
}
Все, товарищи. Перезапускаем apache и nginx, радуемся.
Источник вдохновения: http://habrahabr.ru/blogs/nginx/76315/
Послесловие: Все это хорошо только если большинство ваших пользователей анонимны. Меня в данном случаи радует в первую очередь то, что не важно как у вас сконфигурирован сам drupal, все будет кэшироваться и хорошо кэшировать. Конфиг универсален: в данном случаи мои сайты вертятся на установленой системе которая лежит в /var/www/d6, ни каких проблем не составит создать еще один конфиг скажем для /var/www/d7 - нужно будет только поменять адреса и доменные имена. Конфиг сделан "на глаз" хоть и протестирован, а что может из него вылезти я не знаю - прошу участия в его модернизации. Спасибо за внимание.
Комментарии
спасибо
надеюсь не пригодится
А на репозиторий для hardy не ругается? Вроде 9.04 это же jaunty...
Нет, не ругается. Там варианты lucid и hardy. Lucid не катит т.к. не все зависимости будут удовлетворены. Обновлять на свежую версию ОС не рекомендую, т.к. она за собой притянет php5.3 что есть беда да большинства модулей drupal.
Там есть для jaunty раздел....
Говорят есть дебпаки даже для lucid:
http://habrahabr.ru/blogs/linux/95677/
Нужно вариант для 10.04 просматривать (решать вопрос с пхп 5.3).
Потому что это LTS, а не тестовый выпуск.
Кто сказал, что Jaunty 9.04 и другие - тестовый выпуск? У них просто поддержка обновлений меньше по времени, чем у LTS...
Я кстати тоже на нетбуке 9.04 пользуюсь и не собираюсь пока обновляться - все что надо есть.
Совсем недавно уже решал этот вопрос:
http://2bits.com/drupal-planet/various-ways-running-php-52-ubuntu-1004-l...
Approach 3 - то что нужно
Ну видишь, сам ведь все понимаешь почти.
Дело в том, что в опенсорсе без тестовых релизов никак нельзя обойтись, поэтому у дебиана ветка зовется тест, у новела есть опенсусь, у редхата федора, у мандривы мандрива фри и тд в этом роде.
Так как каноникл не делает различий между комьюнити и коммерческими релизами, все дистры у них зовутся убунту. Но! Те что с приставкой LTS-это и есть стабл дебиана, след от новела и тд. А всякие 810, 904, 910 - это промежуточные варианты, на которых обкатываются новая логика и технологии. Поэтому они как раз таки "тестовые", и для бизнеса(для продакшн серверов) лучше использовать лтс релизы, на данный момент 10.04. Просто это правильней.
Я с нее обновился на 910 когда нужен был гимп поновее(там с зависимостями трахаться пришлось бы), на ней и сижу))
Логики нет - я что-то не заметил обкатки Центра приложений до 10.04, я также не заметил PHP5.3 до 10.04... Т.е. это все как раз новинки и выпущены они именно в LTS релизе (PHP5.3 уже давно доступен, как минимум в 9.10 его можно было как раз и затестить)...
И уже устаю повторять - Ubuntu и Debian на данный момент похожи лишь форматом пакетов... Идеалогически это разные вещи и Stable/Unstable у Debian ни в коей мере не применимо к выпускам Ubuntu. Stable у Debian - это пакеты, проверенные и стабильные, Unstable - пакеты в разработке. Все.
В Ubuntu выпуск идет для каждой !!!! версии дистрибутива Main - основная ветка (плюс multiverse и unverse, resctricted) и backports+proposed - тестовые пакеты в разработке.... Ни в коем случае стабильность выпуска Ubuntu никогда не привязывалась к версии дистрибутива. Каждый дистрибутив Ubuntu стабилен и отличается набором ПО (более новое ядро, более новая версия прикладных программ и утилит). То, что поддержка у LTS дольше - означает лишь то, что поддержка у LTS дольше по времени, только и всего. Т.е. теоретически (обращаю внимание - именно теоретически) к концу ее поддержки они могут ее вылизать более качественно, чем обычный выпуск... Но это не будет значить, что другие выпуски тестовые.
Тоже самое касается openSUSE и SLES/SLED от Novell - openSUSE идет как тестовая площадка для переноса разработок в SLED/SLES, но это не значит, что openSUSE нестабилен и тестовый дистрибутив все время. Его вполне можно и даже используют в продакшене.
Надеюсь я объяснил нормально и вы поняли.
Немного не понял ты меня. И каноникл похоже тоже.
Я не говорю, что с неЛТС убунтами нельзя работать, или что они до непригодны. Для опенсусе тож самое-работай на здоровье. Но производитель сам предлагает использовать для предприятий именно ЛТС-версии, т.к. над ними работают гораздо тщательнее. И то, как правило, закрытие еще многих дырок приходит к обновлениям после релиза (8.04.х, 10.04.х и тд).
А вот и соль: отказаться от новшеств не могут, но обязательно к первым обновлениям ЛТСа допилят, и пользуйся остальные 3-5 лет этими фичами.
А разница убунты и дебиана достаточна проста, на мой взгляд: убунту - это дебиан для бизнеса(регулярные обновления, распланированные выпуски, поддержка, и тп).
--
И именно уверенность разработчиков в релизе на ближайшие несколько лет (а что это если не гарантия?)и показывает приставка ЛТС. Вспомни, к примеру, почему Кубунте 804 не дали ЛТС.
Вот так и выходит, что для "поиграться пол-годика" вполне идут неЛТСы, а для продакшина лучше все же использовать ЛТС. Это рекомендации, а не правила, им можно следовать или нет.
---
UPD
Цитата (http://www.ubuntu.com/project/about-ubuntu )
It was decided that every fourth release, issued on a two-year basis, would receive long-term support (LTS). LTS releases are typically used for large-scale deployments.
А вот и слова самого Марка в интервью журналу Linux-Magazine Italia:
Вопрос - 3) Ok, let’s talk about the latest Ubuntu 8.04. In an interview you said that “Hardy Heron is your most significant release ever”. Well, can you talk about the main improvements of this release?
Из ответа выдержка- ...We very much hope that other distributions will follow our lead on the LTS cycle with their enterprise releases ....
------
И если вот тут еще не понятно кому-то, что такое ЛТС, то я уже не знаю как объяснять.
Ох уж эти линуксойды
И не говори....
Мегафлуд старт!Винда лучше линукса, на винде мастер установки сети есть
Хм imagecache в таком конфиге работает? Сaptcha для всех анонимов одну картинку выдает?
imagecache - не вопрос, Сaptcha - не проверял, думаю нет. Хотя не знаю как Сaptcha ввобще работает, думаю что если через iframe, то можно настроить. Также можно запретить кэширование картинок по урлу вида .../captcha/oijdqwoid.jpg . Если сслылка на каждую картинку Сaptcha уникальна, то работать будет (например при кэшированиии css и js методами drupal ссылки на сжатые файлы уникальны, работает на ура).
конфиг несколько уныл. костыли с proxy_store уже можно смело выкидывать
Опишите, как лучше...
Автору стоит обратить внимание на http://groups.drupal.org/nginx и как минимум http://groups.drupal.org/node/46404
+1
что-то не совсем понятно, то есть даже совершенно не понятно, что тут делает локейшн fetch с proxy_store и как вообще туда попасть... по всей видимости автор в локейшне со статикой что-то не то написал, там должно быть например root /кэш try_files $uri fetch; ..... хотя при единственном физическом сервере оно вообще не нужно....
но идея хороша, только нужно ее под fastcgi переписать и погонять, потому что boost лагает люто и тупо лочит базу (~9K страниц, когда кэш переваливает за 4К приходит кирдык)...
Может тема ооочень старая, но ничего подходящего и простого я больше не нагуглил. Почти все что, что на д.орг работает с boost и прочими модулями или конфиги под fastcgi.
Два дня как столкнулся с nginx, ничего больше как всунуть в локейшне со статикой try_files $uri @cached; не смог, т.к. единственное до чего додумался. После этого хоть индексная страница по-человечьи стала загружаться и ответ сервера стал естественно нормальным (3-50мс).
location @fetch - удалил вообще.