Re: Не понятное поведение при использовании proxy_pass в локейшене

[Maxim Dounin]

Hello!

On Thu, Dec 07, 2017 at 03:01:56PM +0200, Alex Domoradov wrote:

> Понятно, просто изначально проблема была немного другой.
> 
> В location /test/ не было указано никаких резолверов, и он проксировал на
> тестовый инстанс elk, который со временем удалили, при этом перестало
> работать проксирование и на основной elk, который находится в корневом
> локейшене. Пользователи стали получать - "504 Gateway Time-out". В
> error.log при этом было
> 
> 2017/12/07 03:21:01 [emerg] 16478#0: host not found in upstream "
> search-testing.us-west-1.es.amazonaws.com" in /etc/nginx/conf.d/elk.conf:46
> 
> Это тоже нормальное поведение, что если в любом из локейшенов в пределах
> одного сервера, перестает резолвиться апстрим, то перестает работать весь
> сервер? Я пробовал воспроизвести проблему, но не получилось. Единственное
> отличие это то, что в первом случае, когда стал не доступен корневой
> апстрим, с момента запуска nginx до момента возникновения проблемы прошел
> месяц. Такое ощущение, что сбросились какие то кеши.

Если какое-либо из имён, указанных в конфигурации, не резолвится - 
то это повод отклонить такую конфигурацию.  Приведённая ошибка - 
это как раз ошибка парсинга конфигурации.

Соответственно, если такое происходит при попытке перезагрузить 
конфигурацию - то nginx просто продолжит работать со старой 
конфигурацией.

Если же вы зачем-то сначала остановили nginx, а потом пытаетесь 
запустить его с конфигурацией, в которой указано несуществующее 
имя - то сначала придётся конфигурацию исправить, и только после 
этого nginx запустится.

(Отмечу в скобках, что некоторые по привычке используют restart 
вместо reload при изменениях конфигурации.  Так делать не надо - 
это, во-первых, приводит к потере запросов в момент перезапуска, а 
во-вторых - может привести к полной недоступности сервиса, если 
старый nginx завершится, а новый не сможет стартовать из-за 
каких-то проблем.  Лучше всегда использовать reload, а при 
необходимости обновления исполняемого файла - upgrade.  Такой 
подход позволяет гарантировать, что nginx продолжит работать в 
любых условиях.  Подробнее про всё это написано на странице 
http://nginx.org/ru/docs/control.html.)

-- 
Maxim Dounin
http://mdounin.ru/