nginx и alias-ы сайтов

Собственно, уже ощущаю по-немногу, что зря связался с этим nginx. CentOS + ISPConfig. Прикрутил изолентой кеширующий nginx. Просто потому что на прошлом сервере девелоперы просили, что бы было так. Настроил, запустил, через [censored] даже управляется. Но тут оказалась беда: сервисы типа /mysqladmin, которые прописаны как алиасы в apache не хотят грузить картинки через http (почему https показывает их нормально я так и не понял). Но в http с ними беда.

Пришлось залезть в nginx.conf и руками дописать там правило

location ~ (/mywebmail|/mysqladmin) {
proxy_pass http://127.0.0.1:82;
}

Но вы не находите, что это как-то некрасивенько и при создании очередного сервиса с алиасом мне надо будет снова уродоваться?

Научился размещать проигрыватель flv на сайте

Собственно, ничего экстраординарного. Есть статья, достаточно подробно освещающая какие они бывают. В первом же плеере зашел в описание, увидел онлайн-демо с комментарием о том, что надо просто открыть его и посмотреть исходники.  Там несколько разнообразных файлов, которые она обычно тягает с другого сайта, но их wget-ом выкачал в отдельный каталог на сайте, а потом скопировал исходный код в index.html в этот каталог и вуаля!

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

Запуск apache и nginx под одним именем

Собственно, прикручиваю nginx к хостингу под управлением ISPConfig. Штатным образом они пока (в режиме каскада, так что бы nginx только картинки и архивы показывал, а остальное апач). Так вот, вроде как запустилось (в одном месте только пришлось грязными лапами в конфиги ISPConfig влезть), а но оказалось, что картинки отображать не хочет. То есть, то, что идёт на обработку apache — вопросов нет. В конфигаю nginx путь в куда-надо формируется правильно. А не показывает. Смекнул я (потому что я исключительно умный), что nginx показывал бы всё, но ему не хватает в организме прав. Я и перезапустил его под именем apache. И картинки сразу появились. Что бы nginx получал те же права для тех же пользователей, как назначает их ISPConfig, надо лезть в скрипты ISPConfig. А если просто и то, и другое запускать от имени apache, то вроде как и проблемы нет. Внимание, вопрос: чем я рискую, если допускаю себе такую вольность?

Не сервер хостинга, а красота в чистом виде!

Хочу обозначить в качестве резюме по своим занятиям последние пару дней. Поставил на сервер IBM Cenos 6 x86_64, поставил на него ISPConfig3, только вместо убогого SquirrelMail поставил RoundCube версии 0.4.2 для того, что бы заработали плагины ISPConfig3.

Нанастраивался, аж из ушей торчит. Вроде всё заработало и всё безумно красиво. Купил себе мануал на это дело. Читать долгими зимними вечерами. И даже вопрос задал на форуме, потому что не совсем понятно было как nginx прикрутить фронтендом к apache.

Сегодня замечательный день. Я познакомился с nginx!

Так получилось, что на моём сервере крутится один суровый известный ресурс. И крутят его не лыком шитые дизайнеры. Когда я начал откровенно тупить, то они попросили sudo-шный доступ и поставили мне nginx. Единственное, что я понял, так это то, что он как-то оптимизирует запросы. Я немного почитал что про это думает интернет, ужаснулся от слога википедии, почитал простое, но наполненное терминами на страничке автора описание. Кстати, я так и не понял зачем оно ещё и почту проксирует. Далее я понял, что у меня ngnix является фронтендом к apache. А вот потом я попал на замечательную статью (а это часть 2), которая описывает не только саму суть, но и раскладывает всё по полочкам даже такому человеку, который потоки от процессов отличает очень слабо:

Итак, представим следующую ситуацию: на HTTP-сервер с каналом в 1 Гбит/с подключается 200 клиентов с каналом по 256 Кбит/с:

Что происходит в случае Apache? Создается 200 потоков/процессов, которые относительно быстро генерируют контент (это могут быть как динамические страницы, так и статические файлы, читаемые с диска), но медленно отдают его клиентам. Операционная система вынуждена справляться с кучей потоков и блокировок ввода/вывода.
Nginx в такой ситуации затрачивает на каждый коннект на порядок меньше ресурсов ОС и памяти. Однако тут выявляется ограничение сетевой модели nginx: он не может генерировать динамический контент внутри себя, т.к. это приведет к блокировкам внутри nginx. Естественно, решение есть: nginx умеет проксировать такие запросы (на генерирование контента) на любой другой веб-сервер (например, все тот же Apache) или на FastCGI-сервер.

В довершение понимания ещё можно почитать интервью с разработчиком. И ещё я всё никак про это название понять не мог. Всё мне казалось, что это искаженное слово «unix», а сейчас я знаю, что это «engine x«.

Ну и в завершение: я разобрался на что настроили nginx суровые дизайнеры и настроил профиль для своего сайта. Теперь картинки отдаются стабильнее и быстрее. Особенно банер в заголовке сайта. Я доволен собой.