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

Alex Domoradov alex.hha на gmail.com
Пт Дек 8 14:44:12 UTC 2017


Кстати хорошая идея. Ведь они сами предупреждают, что стоит использовать
только CNAME при ссылке на ELB так как адреса могут поменяться.

Because the set of IP addresses associated with a LoadBalancer can change
over time, you should never create an "A" record with any specific IP
address. If you want to use a friendly DNS name for your load balancer
instead of the name generated by the Elastic Load Balancing service, you
should create a CNAME record for the LoadBalancer DNS name

В случае с ELK стеком, думаю там тоже стоят балансировщики, судя по выводу

$ host search-production.us-west-1.es.amazonaws.com
search-production.us-west-1.es.amazonaws.com has address 52.8.xxx.xxx
search-production.us-west-1.es.amazonaws.com has address 13.57.xxx.xxx

$ host 52.8.xxx.xxx
xxx.xxx.8.52.in-addr.arpa domain name pointer
ec2-52-8-xxx-xxx.us-west-1.compute.amazonaws.com.

$ host 13.57.xxx.xxx
xxx.xxx.57.13.in-addr.arpa domain name pointer
ec2-13-57-xxx-xxx.us-west-1.compute.amazonaws.com.

В моем случае получается, что nginx при старте отрезолвил имя
search-production.us-west-1.es.amazonaws.com в одну пару ip адресов, а со
временем они поменялись. И скорее всего я и получил эту ошибку. Отслеживать
в ручную и делать reload это конечно не вариант. А как вообще стоит тогда
настраивать nginx, если он стоит перед амазоновским elb, чтобы избежать
подобных проблем в будущем?

2017-12-08 16:23 GMT+02:00 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Fri, Dec 08, 2017 at 04:11:19PM +0200, Alex Domoradov wrote:
>
> > Да, это я знаю. Тогда у меня возникает вопрос
> >
> > Скорее всего ошибка  host not found in upstream "
> > search-testing.us-west-1.es.amazonaws.com" in
> /etc/nginx/conf.d/elk.conf:46
> > действительно была вызвана попыткой сделать reload/restart. Но раз nginx
> > работал, значит restart не производился. Возможно действительно был
> reload.
> > Но он бы не применился по причине ошибки резолвинга. Сам домен был удален
> > примерно за 10 дней, до обнаружения самой ошибки, т.е. момент когда
> > перестал открываться ELK(кибана)
> >
> > Больше никаких ошибок в error.log не было. Тогда не понятно, почему
> > перестало работать проксирование из корневого локейшена, а возвращалась
> 504
> > ошибка? У меня к сожалению не удалось воспроизвести это поведение
>
> Если 504 возвращал именно nginx, а не какой-нибудь ELB перед ним,
> то a) очевидно, что nginx был запущен и работал, и б) проблема
> была в том, что он не мог добраться до конкретного бэкенда.
> Почему не мог - отдельный вопрос.
>
> Например, такое могло случиться из-за того, что IP-адреса бэкендов
> поменялись, а reload nginx'у, чтобы он подобрал эти изменившиеся
> IP-адреса, никто не сказал.  В результате nginx продолжал ходить
> на старые адреса, где ему не отвечали.  В логах будут подробности
> на уровне error, включая IP-адреса, куда nginx пытался ходить.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20171208/0a8f2401/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru