Re: нужен совет по if-конструкциям

[Gena Makhomed]

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