Администрирование веб сервера nginx

Собственно зачем вообще запрещать доступ к сайту по географическому признаку ? Да просто 80% IP адресов участвующих в ddos атаке, как правило принадлежат странам, жители которых никогда не зайдут на данный сайт, естественно это сугубо индивидуально для каждого ресурса и если вы знаете что часть ваших посетителей приходит из Эфиопии или Чили, блокировать их, вы вряд-ли захотите. У большинства-же моих клиентов, географическое расположение посетителей, как правило ограничивается Европой и бывшим СССР, остальных можно смело игнорировать.

Думаю многие играли или играют или хотя-бы слышали о такой популярной игрухе как Counter Strike. Серверов с этой игрой в сети как грязи нынче.
В общем случилось поднимать игровой сервак + веб морду для модуля статистики Server Stat System.

По работе, периодически приходиться заниматься переносом уже работающих ресурсов с веб сервера Apache на связку nginx - fastcgi, или со старого сервера на новый с уже установленным веб сервером nginx. Ни в коем разе не допускаю мысли, что Apache плохой веб сервер, учитывая количество модулей, он очень универсален, можно решать практически любые задачи, но его монстрообразность предъявляет определенные требования к ресурсам системы.

Итак, имеем веб сервер Nginx в качестве фронтэнда, на бакэндах Apache и какой-нибудь fastcgi (spawn-fcgi или php-fpm). Функциональные возможности серверов, nginx и apache, несколько различаются, и одно из различий как раз в том, что nginx не поддерживает обработку файлов htaccess, которые в apache используются практически повсеместно. Большинство сайтовых движков (CMS), поддерживают возможность генерировать так называемые ЧПУ(человекопонятный урл, в оригинале, SEF - search engines friendly url), но для этого, веб сервер, должен обрабатывать строку запроса определенным образом, что apache и делает с помощью mod_rewrite и правил в файле .htaccess. Задача: заменить правила .htaccess, соответствующими директивами в конфигурационном файле nginx.conf.

301 Moved Permanently, редирект, говорящий что ресурс перемещен на постоянной основе. В интернетах пишут что мол типа архинеобходимо для SEO, мол поисковики это дюже уважают), спорить не буду, не вникал. В веб сервере Nginx 301 редирект настраивается в конфигурационном файле ( в apache можно через файл .htaccess ), таким образом:

Контролируемое скачивание, реализуемое в веб сервере Nginx с использованием заголовка X-Accel-Redirect, подразумевает следующий алгоритм при отдаче контента:

• Клиент нажимает на ссылку "скачать файл"
• Запрос передается веб серверу Nginx
• Nginx в свою очередь передает запрос некоему скрипту на проверку
• Скрипт, после проверки, например валидности запроса на скачивание, возвращает запрос в Nginx, устанавливая заголовок X-Accel-Redirect
• Запрос с заголовком X-Accel-Redirect попадает в специальный внутренний location, сервера Nginx, откуда и отдается клиенту

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

В предыдущей статье "Установка и настройка веб сервера Nginx в качестве проксирующего фронтэнда к Apache", был рассмотрен простой вариант установки и использования Nginx, с настройками по-умолчанию, в качестве проксирующего сервера, с сервером Apache в качестве проксиркемого бакэнда.

В данном материале хотелось-бы рассказать о более сложном варианте установки и настройки Nginx, для построения связки Nginx Apache FastCGI. Для организации FastCGI сервера, будет использована утилиты, spawn-fcgi, ранее входившая в состав веб сервера lighttpd, а теперь выделенная в отдельный порт.

В предыдущей статье, "Веб сервер Nginx, обзор функциональных возможностей", речь шла об основных функциональных возможностях сервера Nginx, а так-же затронут вопрос его использования в качестве проксирующего фронтенд-сервера в связке с веб сервером Apache. Здесь хотелось-бы рассказать о практической стороне вопроса, то есть перейти непосредственно к установке и настройке вышеупомянутой связки, Nginx - Apache. Так как всем остальным *nix системам, я предпочитаю FreeBSD, на ней и будем все это поднимать.

Nginx - небольшой по размерам, очень быстрый, достаточно функциональный веб сервер и почтовый прокси-сервер, разработчик ]]>Игорь Сысоев]]> ( rambler.ru ). Из-за очень маленького потребления ресурсов системы и скорости работы, а так-же гибкости конфигурирования, веб сервер Nginx часто используется в качестве фронтэнда к более тяжеловесным серверам, такими как Apache, в проектах с высокой нагрузкой. Классическим вариантом является связка, Nginx - Apache - FastCGI. Работая в такой схеме, сервер Nginx, принимает все запросы приходящие по HTTP, и в зависимости от конфигурации и собственно самого запроса, решает, обработать-ли запрос самому и отдать клиенту готовый ответ или отправить запрос на обработку, одному из бакэндов ( Apache или FastCGI ).