Nginx *

LESS — это популярный препроцессор для языка CSS, добавляющий возможности использовать константы, наследование, вложенные стили и много другое, чего так не хватает в CSS. Как только я познакомился с LESS я понял что это то, что мне нужно. Единственное, что омрачило мою радость — разработчики предлагают всего два варианта его использования: встраивать JavaScript файл, который занимается препроцессингом прямо в браузере или использовать специальный скрипт (который должен исполняться на node.js) который процессирует LESS файлы.

Вариант c процессингом LESS файлов на клиенте мне не понравился тем, что для больших LESS файлов это вызывает ощутимые паузы при загрузке страницы. Если использовать LESS версию твиттерного bootstrap-a — загрузка увеличивается на несколько секунд, что абсолютно недопустимо.
Вариант с предварительной компиляцией меня не устраивал тем, что приходится «вручуную» запускать препроцессор. Я видел программу, которая автоматически перегенерирует LESS файлы при их изменении, но она оказалась платной и только под МакОСь.

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

Есть в моем ведении несколько VPSов, на которых крутится… вообщем не моя зона ответственности, и потому крутится там то что крутится, в меру тормозит, в меру работает. И оказалось, что крутится на одном из них некий форум, и начал форум притормаживать. И захотелось разобраться…

Доступны три пакета услуг:

• Essential ($1100/мес)
• Advanced ($4400/мес, $50K/год)
• Premium ($6600+/мес, $70K+/год)

Самый дорогой вариант включает в себя неограниченное количество серверов, круглосуточную телефонную поддержку 24х7 и допускает работу по найму. На самом дешёвом тарифе рассматриваются максимум 2 инцидента в месяц, 2-10 серверов, контакты только по почте/вебу, никакой приоритетной разработки для клиента или помощи в дизайне/внедрении.

Контракты заключаются на 3-12 месяцев, платежи помесячно или поквартально, предоплата.

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

Недавно, по работе, пришлось столкнуться с сайтом fbi.gov. Пароль, который выдали почему-то не прошел, и каково-же было мое удивление, когда после 3-ей попытки я увидел это

Как известно, при разработке высоконагруженных серверов часто применяется событийная модель работы с сокетами. Ключевым компонентом системы при этом является epoll (во FreeBSD и Windows есть свои решения, но остановимся на Линуксе). Функция epoll_wait, будучи единственным блокирующим вызовом, возвращает нам информацию обо всех сетевых событиях, которые нас интересуют. Подобным образом, конечно, работает и всем известный сервер NGINX.

Событийная модель программирования делает код весьма своеобразным, как будто выворачивает его наизнанку. Но эта проблема не так страшна. Есть другая проблема — использование в событийно-ориентированном коде существующих библиотек, изначально не предназначенных для него. Если подобная библиотека делает блокирующие вызовы (например, connect, recv и т.д.), вся событийная модель может потерять смысл т.к. окончания одного такого вызова будут ждать все остальные клиенты, что совершенно неприемлемо, если вы пишете серьезный продукт.

Приветствую Вас, хабрачитатели!

Расскажу об одной задачке, которая встала передо мной, и как я ее решил.

Сразу оговорюсь — часовой поиск в G и в Я удовлетворяющего результата не принес, но за следующий час было реализовано собственное решение.

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


Суть задачи сводилась к тому, что мне требовалось уникально идентифицировать посетителя в независимости от природы и вероисповедания компонентов системы (Web-проект). Причем сделать это максимально просто, быстро и без большого оверхеда по быстродействию.
Важно заметить, что авторизация пользователя по логину/паролю или еще как не производится.

В качестве веб-сервера и первичного балансировщика нагрузки у меня имеется Nginx.

В моей системе для php используетcя php-fpm через fastcgi, так же через fastcgi работает c++ сервер бизнес логики.

В свежей статистике Netcraft за январь 2012 произошло замечательное событие: веб-сервер nginx наконец-то обогнал Microsoft IIS и вышел на второе место в интернете среди активных сайтов (то есть сайтах с уникальным контентом, сделанных не по шаблонам).

Разработчик	Декабрь 2011	Доля	Январь 2012	Доля	Изменение
Apache	102 005 032	58,21%	105 684 049	57,93%	-0,28
nginx	20 342 324	11,61%	22 221 514	12,18%	0,57
Microsoft	21 572 870	12,31%	22 142 114	12,14%	-0,17
Google	14 240 979	8,13%	14 412 926	7,90%	-0,23

Примечательно, что в этой статистике все основные конкуренты потеряли позиции, и только nginx прибавил по сравнению с декабрём 2011 года.

С этим загадочным глюком вы столкнётесь только при сочетании сразу нескольких условий.

Ваш сайт обслуживается Apache Server. (Это условие выполнить нетрудно: сейчас Apache — один из наиболее популярных вебосерверов.)

Ваш сайт также снабжён кэширующим сервером nginx. (Закупая shared-хостинг для небольшого сайта, вы можете до последней минуты ничего и не знать о том, что хостинговый провайдер, заботясь об экономии ресурсов, навесил nginx. Если, конечно, не полезете читать заголовки HTTP-отклика.)

Вы ставите какой-нибудь движок, работающий на PHP. (Например, CMS Drupal. Или, например, вики MediaWiki.)

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

И тогда приходят они. Четыре шестнадцатеричные цифры. Они появляются в коде страницы с описанием ошибки 404 (а также и 403), они стоят в этом коде перед «<!DOCTYPE», и поэтому многие браузеры (например, Firefox) стремятся отобразить их выше всего остального текста страницы — а значит, заметно разламывают дизайн, задуманный создателями CMS или вики:

3340
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
    <head>
          <title> … … …

В чём же дело?

Получаем скриншоты из видео через NGINX средствами ImageMagick и ffmpeg

Совсем недавно появился новый модуль nginx-video-thumbextractor-module
Хотел опубликовать как ссылку но как видно топиков-ссылок больше нет. да и как перевод уже не подходит ибо добавил отсебятины.
В любом случае считаю что стоит поделиться этим замечательным модулем с Хабровчанами.
В статусе указано что он готов для продакшена, что очень радует.

На Хабре уже есть несколько описаний Nginx, но, думаю, моя конфигурация тоже будет интересна.
Ситуация выглядит следующим образом: есть размещённый на нескольких серверах IIS сайт (интернет-магазин), перед ним расположен балансировщик. Между ними решено установить nginx для уменьшения нагрузки на IIS.

Основная масса динамического контента отображается Ajax-ом, так что кеширование страниц каталога товаров вполне безопасно. Однако на них могут быть отзывы о товаре, за которые можно проголосовать — совсем как на Хабре, что тоже надо учесть.

Плюс к этому хочется поддерживать валидность популярных страниц в кеше автоматически.

Я уже писал о том, как с помощью Nginx трансформировать контент на лету. С момента публикации статьи на базе описанного метода запущен и развивается реальный проект ecommerce. Помимо перевода и трансформации также реализован и SEO рерайт по заветам руководства для начинающих от Google.

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

В чем суть проблемы

Проблема заключается в том, что любой нормальный сервер приложений всегда выставляет Cookie, например для того, чтобы сохранять сессию клиента или корзину с его товаром. Если этот сервер (точнее его администратор) озабочен поддержанием определенного уровня безопасности, то он выставляет в теле Cookie домен и путь, например domain= backend.org; path=/path1. Наш Nginx запущенный в режиме Reverse Proxy замечательно меняет все ссылки в теле документов с backend.org на frontend.org, но не делает этого для кук! Это означает что браузер клиента отвергнет такие куки.

Этот вопрос с давних пор волнует умы администраторов nginx, в рассылках он всплывает по 1-2 раза в год. Большинство вопрошавших, по-видимому, решили свои проблемы подкручивая логику backendа, но не я! После очередного апдейта оригинального сайта стало понятно, что костыль с PHP + Curl тянуть больше невозможно и надо непременно найти решение с помощью Nginx!

Я вернул тему в рассылку, попутно перебирая варианты из ngx_http_perl_module и переменной $upstream_http_set_cookie, даже заглянул в дебри сорсов с призрачной надеждой написать модуль самому. Но все было неудачно пока в один прекрасный момент я не получил письмо от Mikhail Mazursky, который дал ценный совет. Благодаря этому совету я не только с легкостью решил задачу проксирования Cookie, но и получил новый инструмент, с помощью которого можно создать версию 2.0 своего проекта.

Решение

Название этого инструмента lua-nginx-module, который написан еще одним китайским самородком с корнями из Taobao. Из названия легко понять, что речь об языке скриптов Lua встроенном в Nginx — но это больше чем просто интерпретатор! Эти ребята создали полностью неблокируемую реализацию с производительностью десятки тысяч операций в секунду, которая имеет хуки ко всем событиям внутри Nginx. То что раньше можно было реализовать только написав свой модуль на C, теперь можно сделать несколькими строчками на Lua. Заинтересовались?

Компания Nginx Inc. сообщила о получении первого транша венчурных инвестиций в размере $3 млн. Венчурные фонды Runa Capital, BV Capital и MSD Capital вложили деньги под создание нового коммерческого продукта, который должен выйти до конца октября.

Три миллиона долларов пойдут на американскую экспансию Nginx Inc., открытие офиса в Сан-Франциско в октябре-декабре 2011 года, наём персонала.

Игорь Сысоев разработал первую версию веб-сервера Engine X (Nginx) в 2002-2004 гг, будучи штатным сотрудником компании «Рамблер». В июле 2011 года он основал собственную фирму Nginx, а в октябре 2011 года — акционерное общество Nginx Inc. На сегодняшний день веб-сервер Nginx установлен на более чем 40 млн доменах в интернете (8,5% от общего количества) и владеет долей более 20% среди тысячи самых крупных веб-сайтов, включая Facebook, Dropbox и WordPress.

Можно посчитать, что если хотя бы 1% сайтов перейдёт с бесплатной на коммерческую версию Nginx, то инвестиции венчурных фондов окупятся с лихвой. Кажется, беспроигрышная сделка. По некоторым оценкам, за $3 млн инвесторы получили до 40% акций, а также два места в совете директоров.

UPD. По поводу инвестиционной сделки опубликовано сообщение в официальном блоге Runa Capital на Хабрахабре.

Модуль полностью нативный и написан Игорем Сысоевым, анонс был вчера:

Изменения в nginx 1.1.3 14.09.2011
*) Добавление: модуль ngx_http_mp4_module.

Только что я его поставил и он работает.
Основная директива mp4 совместима с модулем h264.code-shop.com/trac/wiki/Mod-H264-Streaming-Nginx-Version2
Описание директив модуля:
nginx.org/en/docs/http/ngx_http_mp4_module.html

Ссылка на исходник, спасибо powder96
nginx.org/download/nginx-1.1.3.tar.gz
Ссылка на rpm для Centos 5
centos.alt.ru/?p=579

По моему это просто чудо какое то.
Добейте если не жалко 22 плюса к новости до инвайта.

Приветствую вас, господа.

Не так давно в одном из своих проектов мне понадобилось иметь возможность передачи файлов посредством метода PUT, без скрипта-обработчика на принимающей стороне, принять и обработать файл должен был сам сервер. Так же была задача реализовать это не на Apache, а на его собрате — Nginx.

В итоге своих изысканий у меня получилась такая схема — скрипт на PHP получает адрес файла и делает запрос к серверу, а он в свою очередь получает файл и складывает в требуемую папочку.

Приводить дальнейшие примеры по установке, настройке и отработке взаимодействий я буду отталкиваясь от debian-based ОС.

Здравствуйте.
Побудила меня написать эту заметку статься Недокументированные возможности secure_link.
Где по большому счету была теория но мало прикладных примеров.
Поэтому я и решил немножко исправить ситуацию и поделится своими небольшими наработками.

На прошлой неделе Максим Дунин разместил в англоязычном списке рассылки разработчиков Nginx сообщение с просьбой потестировать патч, добавляющий полноценную (включая chunked-ответы) поддержку Keep-Alive соединений (при использовании upstream keepalive модуля) с http, fastcgi и memcached бэк-энд серверами.

Во избежание кривотолков, напомню, что Nginx обладает прекрасной поддержкой протокола HTTP 1.1 и Keep-Alive соединений с клиентами. Однако, постоянные соединения с http бэк-эндами не поддерживаются. На то были свои причины.

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

С версии 0.8.46 в nginx появились опции, позволяющие легко и просто настроить прозрачное кэширование для анонимных пользователей.

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

Если вы используете Socket.IO или Faye с WebSockets, и хотите при этом использовать реверс-прокси с Nginx, то вы встретитесь с проблемой поддержки WebSocket в Nginx. Ее просто нет — WebSocket использует HTTP 1.1, в то же время как Nginx умеет правильно проксировать только HTTP 1.0.

Что делать?

Вы можете попытаться пойти в обход — использовать HAProxy для проксирования tcp соединений, или же скатиться к использованию Long-polling.
Но есть способ реализовать реверсированное проксирование и с NGINX, используя неофициальный патч, реализующий модуль tcp_proxy в nginx, который даст возможность пробрасывать произвольные tcp-соединения (по сути тоже самое, что дает HAProxy).

В этой статье я покажу, как настроить простую связку nginx + Asp.Net. Под простой надо понимать, что какие-то специфические особенности проектов, разграничение прав пользователей, высокие нагрузки и т.п. нужно настраивать отдельно (особенно это касается Asp.Net). Статья написана по просьбе хабраюзера mace.

В свое время озадачившись проблемой хостинга маленьких Asp.Net-проектов я осознал одну простую вещь: покупать лицензию на Windows Server, а потом и арендовывать достаточно мощный выделенный/виртуальный сервер для каких-то домашних поделок/экспериментов — крайне неразумно. Решение как-то сразу всплыло в моей лысой голове: есть же Mono! Непродолжительный поиск по mono-project.com вывел на FAQ об Asp.Net. Фактически, документация показала мне три возможных варианта:

  Начиная с версии 0.8.50 в модуле Nginx secure_link появилось значительное улучшение по защите ссылок от подделывания. Как ни странно, новые возможности до сих пор не отражены в официальной документации [1]. Описание на английском можно найти на сайте Nginx Community [2], а также пояснения Сысоева по данным изменениям [3]. Код на PHP для генерации защищённых ссылок можно найти в форуме по nginx [4].
 В общем, новшество выглядит так: