Nginx *

Существует мнение, что nginx — отличный инструмент для отдачи статики.
Есть статьи, где описываются настройки sendfile или aio для «улучшения» отдачи.
На Хабре есть чего почитать о настройке proxy_store с proxy_cache для минимизации проблем со стороны мозгов сайта.
Еще в QA иногда возникают вопросы про кеширование картинок, например.

Зачем заниматься этой ерундой! — говорят опытные пользователи — OS лучше вас знает как кешировать файлы! С кешем и префетчем в современных OS, точнее FS, проблем нет! Зачем плодить свои кеши и списки популярных материалов и все такое?...

Есть только одно вредное «но» — в среде исполнения nginx (в общем случае Linux) понятие "файл" и вообще «файловая система» — просто понятие.
И однажды, когда я, подмонтировав сервер по sshfs, обновил один скриптик, случилось волшебное:
1. На каждой страничке стало на 4 картинки больше.
2. Сервера сдохли.
Что поделать — картинки хранились на glusterFS. Наступил полный FUSE.

Доброго времени суток уважаемые пользователи Хабра! Хотелось бы с вами поделиться своими переживаниями по поводу одного проекта и передать его в добрые руки.

Об этом сегодня написали на nginx.com. Платные плюшки:

• Мониторинг работоспособности бакэнда
• Мониторинг активности в реальном времени с экспортом в JSON
• Продвинутые правила балансировки загрузки
• Реконфигурация на лету с поддержкой HTTP API
• Расширенные возможности логирования
• Настройки для обеспечения высокой доступности
• Потоковое вещание MP4, FLV, Adobe HDS и Apple HLS с поддержкой адаптивного битрейта

Обойдётся это счастье в 1350 долларов в год за установку. В придачу к новым возможностям предоставляется техническая поддержка.

Всем добрый день.
Команда Русоникса решила проблемы с электричеством и написала прекрасный пост с красивыми картинками про «Распределенную брутфорс-атаку на CMS с точки зрения хостера».
Впрочем, там не хватает одного — собственно реализации.

Итак, цели этого поста:

• Эскизная реализация описанной в статье схемы на Nginx + немного бэкэнда в виде php;
• Поиск решения «покрасивее»

Если интересно, прошу под хабракат.

Хочу поделиться своими наработками по настройке nginx, которые, возможно, помогут кому-то при старте нового проекта или избавят от необходимости копипастить очередной vhost.

Я отметил две проблемы подавляющего числа конфигов nginx'а, попадавших мне на глаза:

• «Всё в одном файле»
• Дублирование настроек

С помощью моего подхода, надеюсь, эти и многие другие проблемы будут устранены.

В последнее время всё чаще стали появляться новости о планах по завоеванию серверного рынка системами построенными на ARM-архитектуре. Более того, воплотились в кремнии настоящие серверные ARM-процессоры от Calxeda, а также системы на их основе от Boston Viridis и в скором времени от HP — Moonshot.

Сервера на базе Intel® Atom™ я использую уже 4 года, а вот ARM-ы мне знакомы только с мобильной телефонно-планшетной стороны. На что же он способен, современный ARM-процессор? Сможет ли он конкурировать с Atom-ами? Прямого сравнения на серверном фронте я не нашел, только синтетику на Phoronix. Интересное тестирование было на AnandTech, но там Xeon-ы. Calxeda в своём бенчмарке также сравнивает с Xeon-ами. Мне же было интересно сравнить именно с Atom-ами в связке Linux+NGINX для отдачи статики.

Настраивал кеширование на связке nginx+apache на сервере под управлением Ubuntu. Хотел бы поделиться с некоторыми нюансами с которорими я столкнулся в процесе работы. А имеено с проблемой отображения ssi интсрукций для nginx и разделением кеша с учетом языковой куки.

Проблемы с отображением SSI при использовании прокси на nginx

Для отображения динамических блоков решил использовать ssi. На локальной машине все работало отлично, но после выкладки на сервер ssi блоки не обрабатывались.
В качастве проксирующего веб-сервера используеться апач. После ряда экспериментов установил, что при использовании fastcgi блоки ssi обрабатывались отлично. То есть проблема в прокси-серевере apache.

Обожаю задачи “на стыке технологий”, это одна из таких.
Задача:

• реализовать geoDNS*
• c возможностью wildcard (*.some.tst. A 1.2.3.4)
• с возможностью менять содержимое зон на ходу, добавлять новые зоны пачками
• без необходимости запускать громоздкие скрипты на каждый запрос “мимо кеша”
• научиться тестить этот реактор (с локалхоста, а не кучи proxy/VDS)

*) под geoDNS я подразумеваю возможность для клиентов из разных регионов отдавать разные, например, адреса сервера/А-записи (для США отдаётся IP сервера в США, для СНГ — в москве, для ЕС — в Европе ...)

Статья описывает

• метод реализации geoDNS
• метод тестирования
• эскизное решение на “чистом nginx”

Если интересно, причём же здесь nginx, прошу под кат.

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной.

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

Плагин позволяет пользователю переключать Cpanel веб-сервер на Nginx и PHP-FPM, полностью выключая Apache.



Не только proxy-pass на Apache, a реализует полный стек Nginx + PHP-FPM без Apache!

Для чего эта заметка, ведь похожих уже полно? Если кратко, то когда я взялся настроить связку пришлось перечитать огромное количество документации и разных статей, все сразу и в одном месте найти не получилось. Данная статья попытка систематизировать накопленные знания, а также максимально подробная помощь тем, кто только начинает осваивать nginx.

В качестве теста решил перевести все свои сайты на nginx, до этого все работало на Apache из состава ZendServerCE. Интересно было пробовать насколько сложно будет полностью переехать на новый для себя веб-сервер, ведь используется несколько CMS (DLE, Wordpress, самописныеCMS).

Задачи:

• базовая работа web сервера — обработка html;
• запуск php скриптов;
• корректная работа phpmyadmin для всех сайтов на сервере;
• запуск cgi и pl скриптов;
• использование кеширования и подбор оптимальных параметров для увеличения производительности.

Имеем свежеустановленный сервер Debian 6 в минимальной установке из netinstall. И так поехали.

Введение

Как известно, nginx умеет кешировать ответ сервера, и выдавать его по запросу вместо обращения к бэкенду, экономя тем самым ресурсы сервера. Скорость отдачи таких закешированных страниц иногда поражает, ради таких скоростей иногда не жалко переносить на javascript многие функции сайта только для того, чтобы иметь возможность закешировать ещё 1 страницу целиком (Например, вынести отрисовку плашки с авторизацией юзера на js, чтобы иметь возможность кешировать страницу, которая идентична для всех пользователей, за исключением этой самой плашки).

Я много раз использовал возможность кэширование nginxом страниц, и натыкался на пару неудобных для себя вещей:

• Можно легко закешировать вообще все страницы, но для динамических сайтов или для сайтов с авторизацией нужно ли это?
• Можно закешировать отдельно несколько url, вида /album/*, но не переписывать же конфиг nginx каждый раз при появлении новых разделов сайта?

Добрый день.

Так уж сложилось, что последнее время пришлось достаточно часто менять VDS провайдеров, и каждый раз приходится заново настраивать систему, поэтому решил написать краткий конспект по настройке. Все нижеописанное корректно работает на ОС Linux Ubuntu server 12.04 LTS. В этой статье я опишу как установить и произвести первичную настройку nginx+apache2, eaccelerator, memcached, fure-ftpd, php, mysql, phpmyadmin а также панели управления игровыми серверами — open game panel.

Здравствуйте. Недавно я задавал вопрос по поводу создания цикла статей. Вот первая статья.

В этом цикле статей вы узнаете как грамотно настроить LAMP сервер, аля «хостинг только мощней».
Мы будем использовать следующий стек: nginx — apache-mpm-itk — mod_php — mysql — linux/debian.

Буду освещать следующие темы:

• Настройка frontend — backend
• Расчет возможностей сервера, настройка mysql и backend
• Рассказ об опыте на базе intel s3420gp

Совершенно уверенно могу сказать, что настройка LAMP сервера не ограничивается 6-10 командами установки и раскомментирования определенных строчек в файлах настройки.
Пример: по умолчанию nginx не дает возможности закачать на сервер тело запроса больше чем 1M. Если не настроить данный параметр, будет возникать ошибка 414 (Request-URI Too Large), при попытке добавления небольшой серии фотографий.
У apache совершенно противоположное: у него тело запроса по умолчанию не ограничено. Это делает возможным совершать пакости.

В этой статье мы познакомимся со всей настройкой досконально. В статье вы сможете найти конфигурационные файлы, подготовленные мной. Будучи педантом, мои конфигурационные файлы всегда сгруппированы по типу, например: «производительность», «генерация контента», «страницы ошибок», «сжатие», «другие настройки», «общие настройки». Мне кажется, что читаемость данных файлов становится намного лучше, если они сгруппированы.

Мы узнаем о том какие бывают простые атаки и как от них защищаться. Сразу скажу, что при базовой конфигурации frontend в лице nginx — backend apache все равно остается уязвим.

Я практически уверен, что я не смогу уместить все в одну статью. Добро пожаловать под кат.

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

В данном пособии мы узнаем как быстро и просто сделать рабочее зеркало любого сайта, что позволяет сменить IP и назначить любое доменное имя. Мы даже попробуем спрятать домен в url, после чего можно сохранить локально полную копию сайта. Все упражнения можно сделать на любом виртуальном сервере — лично я использую хостинг Хетцнер и OS Debian. И конечно мы будем использовать лучший веб-сервер всех времен и народов — NGINX!

К этому абзацу пытливый читатель уже приобрел и настроил какой нибудь выделенный сервер или просто запустил Linux на старом компьютере под столом, а так же запустил Nginx последней версии со страничкой «Save me now».

В своих продуктах мы используем AMQP. Это удобно, это позволяет лучше масштабироваться и позволяет добавлять в сложную систему новые модули и расширения практически без проблем. В качестве брокера используется RabbitMQ. В качестве фронтендов используется Nginx. До недавнего времени мы везде использовали связку php-amqp и librabbitmq-0.0.1 для работы с брокером. Но в некоторых частях системы это нам показалось избыточным.

Разработчики nginx анонсировали бета-версию модуля, реализующего поддержку протокола SPDY draft 2. Модуль сейчас распространяется в виде патча для девелоперской версии nginx 1.3.x (патч: http://nginx.org/patches/spdy/patch.spdy.txt).

Пока что у модуля имеется ряд ограничений (отсутствие поддержки push с сервера, директивы post_action, ограничения пропускной способности, отключён SSL-буфер), но в течение ближайших месяцев планируется его доработать, снять все ограничения и полностью интегрировать в основной код nginx.

Протокол SPDY поддерживается браузерами Firefox и Chrome.

Если вам приходилось настраивать Nginx под нужды веб-студии, сеошников или киберсквоттеров ;), то уже наверняка знаете про символ подчёркивания в качестве server_name. Тем не менее несколько других небесполезных приёмчиков из моего примера почерпнуть можно.

Чтоб создать новый сайт на сервере с такой конфигурацией, достаточно создать директорию с именем сайта и залить в неё содержимое. А конфигурационный файл остаётся единственным и неизменным.

Конфиг делает следующее:
1. Отрезает «www» от адреса, дабы сервер нашел директорию с сайтом невзирая на эти буквы в URL.
2. Выдаёт отдельную страничку при запросе несуществующего сайта.
3. Делает стандартный редирект на index.php в корне сайта при запросе несуществующего пути.
4. Перенаправляет запрос на php-fpm при вызове .php файлов.
5. Добавляет возможность обработки .htm(l) файлов как PHP.

Интернет пришел в Россию в 1995-96гг. Среднестатистическим компьютером тогда был AMD 486DX150 или Intel Pentium100 с RAM 4-8 Mb и HDD 100-400 Mb. Как раз тогда появился Windows 95, и именно новая ОС и потребовала апгрейдов железа до указанных величин, т.к. на типичных для 94го года компьютерах 486 SX25 или DX66 с 2-4 Mb Win95 еле ворочался. Интернет-серверами и роутерами у провайдеров в те годы были точно такие же машины, или даже более слабые, т.к. Linux тогда еще вполне комфортно себя чувствовал на 2 Мб (без GUI), сайты были в основном статическими, и почтового спама еще не было. Доступ к интернету имел в лучшем случае один на тысячу человек — по нескольку сотен человек в среднем российском областном центре, и все они работали через единичные провайдерские почтовые и веб-серверы. То есть один сервер указанной ничтожной по современным меркам конфигурации обслуживал примерно столько человек, сколько сейчас интернет-пользователей в довольно крупном предприятии. И справлялся…

Есть ли сейчас компьютеры сопоставимой мощности (если слово мощность еще применимо к такому железу), и как они используются? Есть. Нет, это не роутеры и тем более не смартфоны — те и другие заметно производительнее, даже если рассматривать только домашние роутеры и самые простые телефоны. Роутеры легко прокачивают 100Мбит, а телефоны легко крутят видео, да и память у телефонов на сотни мегабайт — ничего такого и близко не было в 96м году. Надо искать более слабые процессоры сопоставимые с Pentium100, то есть около 100МГц или до 200 DMIPS…

Представим, что у нас есть приложение/сайт с достаточно высокой нагрузкой.

Многие разработчики приложений для «ВК» или «Одноклассников» сталкивались с ситуацией, когда приложение выходит в топ новых приложений и на вас сваливается огромнейшая нагрузка.
Допустим, в процессе обращения клиента к серверу, генерируется картинка. Серверов у нас много. Каким образом клиенту отдать эту картинку, если у вас нет единой файловой системы и файлы не синхронизируются между серверами?

Как поступить, когда на сервер ежесекундно приходит большое количество народу? Ответ прост — nginx.