Некоторые конфиги обратного прокси nginx перестают работать раз в день

12

У меня есть обратный прокси-сервер nginx, который передает запросы от внешнего Amazon ELB к внутренним ELB.

У меня есть 6 серверных экземпляров, которые обрабатывают запросы. Конфиги с включенным сайтом выглядят так, но существуют разные номера портов и proxy_pass. Все остальное идентично:

server {
    listen 3000;
    location / {
            proxy_pass http://internal-prod732r8-PrivateE-1GJ070M0745TT-348518554.eu-west-1.elb.amazonaws.com:3000;
            include /etc/nginx/proxy.conf;
    }

}

Примерно каждые 24 часа одна из конфигураций перестает работать. Все остальные прокси работают нормально. Если я перезапущу nginx, все конфигурации снова будут работать. В файле error.log нет ничего странного, в журнале доступа, syslog или dmesg нет ничего странного.

Это что-то известно? Что-то не так с моими конфигами прокси? Есть ли другие журналы, в которые я могу заглянуть?

nginx reverse-proxy user202172
источник
см .: serverfault.com/questions/240476/…
Ник Фокс
Возможный дубликат Как заставить nginx разрешать DNS (динамическое имя хоста) каждый раз при выполнении proxy_pass?
Anon

Ответы:

22

Ответ на этот вопрос заключается в том, что ELB иногда меняют IP-адреса, а nginx разрешает имена во время запуска.

Чтобы это исправить, в вашем VPC всегда есть DNS-сервер на 0.2. Таким образом, если локальный ip CIDR равен 10.0.0.0/16, DNS-сервер находится на 10.0.0.2.

Добавьте это в конфигурацию nginx.

resolver 10.0.0.2 valid=10s;

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

server {
    listen 3000;
    location / {
            resolver 10.0.0.2 valid=10s;
            set $backend "http://internal-prod732r8-PrivateE-1GJ070M0745TT-348518554.eu-west-1.elb.amazonaws.com:3000"
            proxy_pass $backend;
            include /etc/nginx/proxy.conf;
    }
}
user202172
источник
Кто-нибудь знает, какая версия nginx поддерживает переменные в настройке proxy_pass? я примеряю эластичный бобовый стебель (nginx версия 1.6.2), и он все равно не хочет принимать переменную, в которую я его ввел.
Стивен С.
Спасибо за это, буквально сводим нас с ума уже около месяца!
Jim.R
Эта статья о блоке nginx повторяет эту конфигурацию. nginx.com/blog/dns-service-discovery-nginx-plus
Морган Кристиансон
1

Если ваш proxy_pass не передавался напрямую на один URL-адрес, как показано в примере ( http://amazonaws.com ), а вместо этого на прокси-ферму восходящего потока, например, так:

upstream my_upstream {
 server1 127.0.0.1:1337;
 server2 127.0.0.1:1338; 
}
location / {
 proxy_pass         http://my_upstream;
}

Тогда вы будете менее обеспокоены тем, что один из восходящих потоков временно потерпит неудачу. Потому что они все будут делать одну и ту же работу. Если один не отвечает, то следующий будет прокси для этого ответа. Спокойствие духа.

Nginx автоматически пропустит неисправный компьютер на x секунд. Пока вы не почините его, или пока он не вернется сам. ( http://wiki.nginx.org/HttpUpstreamModule )

Таким образом, какой бы ни была причина ваших прерываний, распределяя их в восходящей ферме, это упрощает настройку.

user18099
источник
Спасибо за ответ! Странно то, что я могу сделать запрос к экземпляру бэкэнда напрямую, но не через nginx. Если я просто перезапустить nginx, запрос снова будет проксирован. Так как это уже в рабочей среде, я действительно хочу выяснить, почему один из конфигов кажется «выгруженным» или как я могу узнать, что на самом деле делает nginx за кулисами.
user202172
Возможно, вы захотите узнать больше информации о регистрации в nginx. Это проблема, когда кто-то, как и вы, пытался узнать больше о «периодически возникающих проблемах [...], я работаю с прокси» stackoverflow.com/questions/9914792/… Он описывает способ получения более релевантных журналов. Надеюсь, поможет.
user18099