5 марта 2013 г.

NGINX. Редирект статики для серверов разработки

Дошли, наконец-то руки описать один прелестный прием в сервере nginx. И себе - чтобы не забыть, и Вам, чтобы пользовали.
Итак: имеем production сервер с веб порталом и несколько development серверов, используем git для создания распределенных сред разработки (с последующим мержингом веток разных разработчиков и деплоем на production сервер). Рассмотрим подробнее один из серверов разработчиков (любой, в данном случае), а именно как сделать некоторые полезности при разработке веб портала. Так вот: есть клон git репозитория с файлами скриптов (и прочего стаффа веб приложения) с которым все ясно - программист пишет, комитит, апдейтит и пр. Но вот вопрос как быть с тестами написанного? Самым простым и действенным решением есть развернуть на сервере разработчика весь сайт, который тот разрабатывает и тестируй себе на здоровье! Но вот вопрос со статикой сайта (картинки, css, js, и т.д.) остается открытым - делать 5-20 копий статики накладно, ведь может занимать много места на диске. Потому, используя nginx можно брать статику прямо с production сервера. Нагрузки на него много мы не сделаем, а вот хлама на development серверах будет порядком поменьше, да и проблемы с синхронизацие будут отброшены за ненадобностью.
Собственно вот рецепт: (приведу часть рабочего конфига nginx с пояснениями)
Вообще-то - никакой магии - просто средствами nginx проверяется наличие локально запрошенного файла и, в случае его отсутствия, - редирект на основной сайт.
Вот так вот.

4 комментария:

  1. Мне кажется подобные манипуляции гораздо проще реализовать через try_files (http://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files).

    ОтветитьУдалить
  2. В целом, концептуально, использование подобной модели отдачи будет затруднено на контентных сайтах, где большую роль играет загрузка какиой-либо статики через веб-интерфейс (в частности, становится невозможной отладка аплоада) и на ресурсах с динамической генерацией статики (как правило, ряд ключей для генерации статики на production и dev серверах не совпадает, поэтому dev-сервер будет получать 404 за счет их разности).

    ОтветитьУдалить
  3. Читайте wiki.nginx.org/IfIsEvil и wiki.nginx.org/Pitfalls, и больше не пишите таких ужасных конфигов.

    ОтветитьУдалить
  4. Согласен с замечаниями. Хотя судя по давности страницы IfIsEvil (This page was last modified on 4 August 2011) можно предположить, что в данный момент кое-что могли уже и поправить.

    ОтветитьУдалить