Рубрика «nginx» - 40

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

  1. ресайз изображений под любые размеры (добавление новых размеров не должно вызывать головную боль)
  2. модификация изображений: добавление водяного знака, применение эффектов оттенки серого, сепия и вообще добавление новых эффектов не должно быть трудной задачей
  3. обработка изображения не должна влиять на основной поток (скорость загрузки страницы)
  4. для ускорения загрузки изображений на странице решение должно позволять обойти лимит одновременных соединений в браузерах, детальнее о лимите (рус)
  5. избежать возможность засорения сервера явной передачей параметров ресайза в url
  6. кешировать результаты работы

Читать полностью »

За год работы в сфере Web технологий, мне не раз приходилось настраивать своё рабочее окружение. Для новичков не так то просто найти хороший гайд по настройке рабочего окружения.

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

Всё это я поднимать на Ubuntu 13.04. Предполагается что вы уже скачали её с официального сайт, и установили.
Читать полностью »

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

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

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

Задача: развернуть несколько django-проектов, использующих разные версии django и разные версии питона на одном сервере.

Инструкция приводится для ОС Ubuntu 12.04.
Читать полностью »

«Битва балансеров» — это нагрузочный тест балансеров / прокси, которые поддерживают WebSockets. Данные технологии незаменимы при масштабировании инфраструктуры.

Тестировались следующие технологии:

http-proxy, версия: 0.10.0
HAProxy, версия: 1.5-dev18 (девелопмент релиз)
— элементарный “echo сервер”, для контрольного теста.

Были сомнения относительно hipache. Причина по которой он был исключен проста — он построен на базе http-proxy. В данный момент они используют форк проекта, в котором попросту отсутствуют патчи, связанные с производительностью.
Читать полностью »

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

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

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

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

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

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

Введение

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

Измерить качество обслуживания напрямую мы, конечно, не можем, однако даже такую эфемерную величину в принципе можно свести к набору количественных характеристик, так или иначе косвенно отражающихся на качестве. Прибыль, число клиентов, процент конвертированных лидов (leads – зарегистрировавшиеся или заинтересованные пользователи) и т.д. – все это вполне объективные показатели. Кроме того, эти величины могут быть включены в систему контроля эффективности работы в качестве KPI – ключевых показателей эффективности.

С нашей, инженерной точки зрения подобными характеристиками являются время ответа и HTTP-код ответа апстрима. Действительно, дизайн, функциональность продукта, маркетинговые усилия и прозвон клиентов находятся вне зоны нашей компетенции. Следовательно, нужно сфокусироваться на том, что находится в нашей власти – ускорение работы инфраструктуры приложения и обработки клиентских запросов.

Анализ отклика и HTTP-кодов удобно проводить на основе некоторой собранной статистической базы, и здесь мы плавно подходим к теме статьи.
Читать полностью »

Давеча был свидетелем одного интересного спора о том как же действительно нужно определять IP адрес конечного пользователя из скриптов PHP.
Собственно, каждое слово сабжа отображает действительную ситуацию. Это был религиозный спор обострённый весенней замечательной погодой, в котором, я считаю, не оказалось правых и не правых, но который побудил меня к мини-исследованию и к моему счастью поставил точку в понимании этого конфессионального но по факту очень простого вопроса.
Для тех, кто как и я сомневался был уверен, что во всём разобрался, но боялся спросить лень было разбираться в мелочах — под кат.
Читать полностью »

Продолжаем публикацию полезных статей о непростых вещах.
Сегодня речь пойдёт о публикации различных сервисов через несколько провайдеров связи одновременно.

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

  • HTTP сервисы(около 60 сайтов)
  • XMPP сервис
  • HTTPS Сервер корпоративной почты(Exchange)
  • VPN сервис
  • SSH
  • IMAP, IMAPS, POP, POP3S, SMTP, SMTPS
  • OwnCloud

Читать полностью »

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — 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-скрипт
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js