Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: нужен совет по if-констру кциям
On 02.08.2011 19:43, Илья Шипицин wrote:
нужен критический взгляд на наш подход к написанию конфигов.
задача такая, скажем, nginx балансирует группу сайтов.
соотвественно на профилактику можно закрыть, как отдельный сайт, так
всю группу.
группу сайтов на сервере можно закрывать скриптом, так что эта задача
легко сводится к задаче закрытия отдельного сайта на профилактику.
людям, которые выполняют профилактику, нужен backdoor, чтобы смотреть,
как всё получилось, до того, как открыть сайты обратно.
server { server_name example.com; ... } - видимый для клиентов
server { server_name example.com; ... } - видимый для персонала
второй сервер - запускать на отдельном порту, с запросом клиентского
сертификата, чтобы никто кроме персонала не мог зайти на этот сайт.
сайты https, строго по паролю, в поисковых системах мы не
присутствуем, поэтому на время профилактики нам неважно,
с 503-м кодом мы ее отдаем или с 200-м.
http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#try_files
try_files /system/maintenance.html
$uri $uri/
=404;
если в location с try_files есть proxy_pass,
то для обработки запроса он будет проксироваться
на backend, если proxy_pass нет - файл $uri будет
отдаваться как статика.
если есть /system/maintenance.html
то всегда будет показываться содержимое
этого файла на любой запрос.
в самом этом файле можно сгенерировать html текст
сообщения о том, что на сервере проводятся какие-то
работы и сколько времени займет восстановление работы.
если такого файла нет - тогда будет
происходить нормальная обработка,
и не будет показываться заглушка.
конфиг написан на if-ах и include-ах, хочется понять, является ли он
оптимальным (голова заточена на if-ы, сложно переключаться на
location/map подход). есть подозрение, что можно переписать более
оптиаально, чем на куче if-ов.
можно сделать разные конфиги для одного сайта,
для нормальной работы и для режима профилактики,
и просто менять конфигурационные файлы, после чего
делать service nginx reload - самое надежное и эффективное
решение (не будет оверхеда в нормальном режиме работы),
если нет "долгоиграющих" сессий с клиентами -
отдачи больших файлов и т.п.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
