Niektóre konfiguracje odwrotnego proxy nginx przestają działać raz dziennie

12

Mam odwrotny serwer proxy nginx, który pośredniczy w żądaniach od zewnętrznego ELB amazona do wewnętrznych ELB.

Mam 6 instancji zaplecza, które obsługują żądania. Konfiguracje z obsługą witryny wyglądają tak, ale istnieją różne numery portów i proxy_pass. Wszystko inne jest identyczne:

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

}

Raz na około 24 godziny jedna z konfiguracji przestaje działać. Wszystkie pozostałe proxy działają poprawnie. Jeśli zrestartuję nginx, wszystkie konfiguracje znów będą działać. Nie ma nic w error.log, nic dziwnego w dzienniku dostępu, syslog lub dmesg.

Czy to coś wiadomo? Czy zrobiłem coś złego z konfiguracjami proxy? Czy są jeszcze jakieś dzienniki, w których mogę zajrzeć?

nginx reverse-proxy user202172
źródło
patrz: serverfault.com/questions/240476/…
nick lis
Możliwy duplikat Jak zmusić nginx do rozpoznawania DNS (dynamicznej nazwy hosta) za każdym razem podczas wykonywania proxy_pass?
Anon

Odpowiedzi:

22

Odpowiedź na to pytanie jest taka, że ​​ELB czasami zmieniają adresy IP, a nginx rozpoznaje nazwy podczas startu.

Aby to naprawić, zawsze jest serwer DNS w twoim VPC na 0.2. Jeśli więc lokalny CIDR IP to 10.0.0.0/16, serwer DNS ma 10.0.0.2.

Dodaj to do konfiguracji nginx.

resolver 10.0.0.2 valid=10s;

Parametr proxy_pass należy również zdefiniować jako zmienną, w przeciwnym razie nginx rozwiąże go tylko raz. Tak więc w oparciu o powyższą konfigurację jest to poprawna konfiguracja:

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
źródło
czy ktoś wie, która wersja nginx obsługuje zmienne w ustawieniu proxy_pass? Próbuję na elastycznej łodydze fasoli (wersja Nginx 1.6.2) i nie chce zaakceptować zmiennej, mimo że ją
Stephen C
Dziękuję za to, dosłownie doprowadza nas do szału już od około miesiąca!
Jim.R
Ten artykuł na temat bloku nginx powtarza także tę konfigurację. nginx.com/blog/dns-service-discovery-nginx-plus
Morgan Christiansson
1

Jeśli Twój proxy_pass nie przeszedł bezpośrednio do jednego adresu URL, jak pokazuje twój przykład ( http://amazonaws.com ), ale zamiast tego do farmy pośredniej proxy, jak poniżej:

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

Wtedy będziesz mniej zaniepokojony chwilowym upadkiem jednego z potoków. Ponieważ wszyscy będą wykonywać tę samą pracę. Jeśli ktoś nie udzieli odpowiedzi, następny będzie proxy dla tej odpowiedzi. Święty spokój.

Nginx automatycznie pominie uszkodzoną maszynę przez x sekund. Dopóki go nie naprawisz lub dopóki nie powróci sam. ( http://wiki.nginx.org/HttpUpstreamModule )

Niezależnie od przyczyny zakłóceń, poprzez dystrybucję ich na farmie wydobywczej, przekształca się to w łatwiejszą konfigurację.

użytkownik18099
źródło
Dzięki za odpowiedź! Dziwne jest to, że mogę wykonać żądanie bezpośrednio do instancji backendu, ale nie przez nginx. Jeśli po prostu zrestartuję nginx, żądanie zostanie ponownie przesłane do serwera proxy. Ponieważ jest to już w środowisku produkcyjnym, naprawdę chcę dowiedzieć się, dlaczego jedna z konfiguracji wydaje się być „rozładowana” lub jak mogę dowiedzieć się, co naprawdę robi Nginx za kulisami.
user202172,
Możesz wtedy polować na więcej informacji o logowaniu nginx. Jest to problem, w którym ktoś próbował, tak jak ty, dowiedzieć się więcej o „sporadycznych problemach [...] Jestem proxy” stackoverflow.com/questions/9914792/... Opisuje sposób pobierania bardziej odpowiednich dzienników. Mam nadzieję, że to pomoże.
user18099