Nginx и правила реврайтов

[zerkms]

Господа, думаю, что никто не будет спорить, что правила реврайтов - являются частью приложения (хотя бы потому, что в момент времени X код может работать адекватно только с одним набором правил перезаписи урлов, а в следующий момент Y схема полностью поменялась и пара реврайты-код - совершенно другая)

Посему - вопрос: как хранить реврайты в случае nginx'а и отсутствия в нём подобия .htaccess?

 

[MiksIr]

В приложении хранить и обрабатывать. Т.е. сервер - разделение статики и запросов в приложение + быстрые костыли при переконфигурации приложения. А остальное уже само приложение решает без всяких htaccess.
.htaccess тут как бы совсем непричем - это все-равно веб-сервер, а то, что приложение научили с этим работать - это другая песня. Если уж очень нужно из приложения управлять правилами nginx - пихать в базу и по крону перегенерить конфиг nginx, к примеру.

 

[zerkms]

В приложении хранить и обрабатывать - вообще как бы не вариант. Перекладывать с вебсервера, который это сделает быстро на приложение, которое это будет делать сильно медленнее.

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

пихать в базу и по крону перегенерить конфиг nginx, к примеру

Чудесный шанс получить неконсистентное состояние приложения

 

[MiksIr]

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

А какое отношение к конкрентному приложению имеют правила управляющие раздачей запросов на разные приложения?

Чудесный шанс получить неконсистентное состояние приложения

С чего бы.

 

[zerkms]

А какое отношение к конкрентному приложению имеют правила управляющие раздачей запросов на разные приложения?

Есть легаси-код, и хороший код. Они лежат в одном репозитории. Соответственно "проект" в данном случае это симбиоз из: Проект1 (лапша), Проект2 (не лапша) и некоторые служебные штуки, которые этому всему позволяют взлететь (правила перезаписи - как раз одни из них)

С чего бы.

Ну ты сам сказал "по крону". Значит очевидно, что этот процесс происходит без нашего участия по расписанию. Есть шанс обновить код и до следующего обновления иметь состояние, которое не соответствует ожидаемому.

 

[MiksIr]

Есть легаси-код, и хороший код. Они лежат в одном репозитории. Соответственно "проект" в данном случае это симбиоз из: Проект1 (лапша), Проект2 (не лапша) и некоторые служебные штуки, которые этому всему позволяют взлететь (правила перезаписи - как раз одни из них)

Достаточно начать считать nginx частью системы приложений. Я, лично, его так и воспринимаю - как управляющий элемент. Так что реврайты не смущают.

Ну ты сам сказал "по крону". Значит очевидно, что этот процесс происходит без нашего участия по расписанию. Есть шанс обновить код и до следующего обновления иметь состояние, которое не соответствует ожидаемому.

Ну это самое первое, что в голову пришло. Я же конкрентно задачи не знаю. Наворотить можно много, что бы сигнал на реконфиг посылать из приложения (опять же, есть несколько способов решения проблемы прав) или через посредник. Но вообще звучит все это странно... сама задача не выглядит реальной.

 

[zerkms]

Достаточно начать считать nginx частью системы приложений. Я, лично, его так и воспринимаю - как управляющий элемент. Так что реврайты не смущают.

Ну а как хранить его конфиг-то? Тоже as-is в системе контроля версий?

 

[AmdY]

Ну а как хранить его конфиг-то? Тоже as-is в системе контроля версий?

яндекс так и делает

 

[zerkms]

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

 

[atv]

zerkms, а ты что из svn апдейты на продакшене делаешь?

 

[zerkms]

zerkms, а ты что из svn апдейты на продакшене делаешь?

Из меркуриала. А какие-то проблемы с этим?

 

[MiksIr]

Include из основного конфига - и пусть лежит далеко, если это удобно.

Из меркуриала. А какие-то проблемы с этим?

Ну обычно проблема - то самое неконсистентное состояние на время апдейта. В принципе оп-код кешер может решить частично, но только для скриптов.

 

[zerkms]

Это меньшее зло (которое при желании решается выкатыванием через вторую директорию и сменой симлинка на докрут)

А инклюд, да, мерси

 

[confguru]

Заведите отдельный репозиторий для конфигов вебсервера или храните в папке которая подлинкована.
Nginx перечитает конфиги только по команде ;-)

 

[fixxxer]

Если у тебя в конфиге nginx именно реврайты, то с вероятностью 99% ты неправильно пишешь конфиг nginx.

По сути - я делаю просто, конфиг генерирую при деплое прямо в каталоге с приложением (точнее чуть выше), на него стоит инклюд.

 

[grigori]

веб-сервер является частью приложения, конфиги хранятся так же, как и любые другие конфиги приложения
да, они не на php написаны, ну и что?

 

[fixxxer]

Я щас признаюсь в страшном. У меня конфиг nginx-а написан на php.

 

[grigori]

 

[zerkms]

Если у тебя в конфиге nginx именно реврайты, то с вероятностью 99% ты неправильно пишешь конфиг nginx.

По сути - я делаю просто, конфиг генерирую при деплое прямо в каталоге с приложением (точнее чуть выше), на него стоит инклюд.

Т.е. ты реврайты не используешь в принципе? Т.е. реврайты в принципе зло?

 

[zerkms]

Я щас признаюсь в страшном. У меня конфиг nginx-а написан на php.

Это как? :-S