Linux: Nginx proxy_pass 도 메 인 이름 분석 으로 인 한 고장

배경
업무 구조:
배치 세부 사항: 두 용 기 는 모두 같은 기계 에 배치 되 어 docker-compose 편성 을 통 해 link 방식 으로 연결된다.
고장 설명
코드 를 업데이트 할 때 전단 이 열 릴 수 있 음 을 발 견 했 지만 모든 인터페이스 요청 은 502(Bad GateWay)고장 검사
전단 용기 compose_ui_1 의 로 그 를 보고 큰 파 도 를 쳤 습 니 다 502(Bad GateWay)UI 가 문제 가 없 으 면 첫 번 째 반응 은 compose_api_1 무릎 을 꿇 었 다 는 것 입 니 다. 그래서 직접 용기 에 가서 로 그 를 보 세 요.
용기 로 그 는 매우 정상 적 이 고 무 너 지지 않 았 으 며, 이 로 그 는 마치 요청 을 받 은 적 이 없 는 것 처럼 보 였 으 나, 분명히 내 전단 에 접근 이 있 을 것 이 고, 느낌 이 매우 이상 하 다.인 터 페 이 스 를 꺼 내 서 따로 방문 해 보 세 요:
인터페이스 단독 접근 결 과 는 잔인 합 니 다 502(Bad GateWay). 믿 을 수 없 는 것 같 습 니 다. 포트 나 호스트 에 접근 하 는 것 이 잘못 되 었 습 니까?이 컴퓨터 는 wireshark 스냅 백 을 켜 서 요청 한 호스트 와 포트 를 확인 합 니 다:
이렇게 하면 전단 compose_ui_1 이 방문 한 호스트 와 포트 가 정확 하고 정확 한 결 과 는 502(Bad GateWay) 이 므 로 compose_api_1 부터 조사 할 수 밖 에 없다.
이전에 도 비슷 한 문제 가 있 었 다. compose_api_1 는 uwsgi 배 치 를 통 과 했 기 때문에 python flask 항상 용법 에 문제 가 있다 고 생각 하고 uwsgi 배 치 를 바 꾼 후에 잠시 멈 추 었 다.지금 또 권토중래 했다.
먼저 compose_api_1 무릎 꿇 었 는 지 아 닌 지 판단 해 봐...그 건 희망 이 없 지만...
백 엔 드 api 인터페이스 직접 접근
어?어색 하 다좋 은 사람 을 잘못 잡 은 것 같다.이 건 아니 죠? 가방 을 잡 아 보 세 요. 다시 확인 해 보 세 요. 먼저:
마치 정말...see 용기 로그:
어?좋아요.잘 못 했 습 니 다. compose_api_1 무릎 을 꿇 지 않 았 습 니 다.
그래서 문제 가 생 겼 어 요.백 엔 드 인터페이스 괜 찮 습 니 다. 전단 방문 이 잘못 되 었 습 니 다. 귀신 이 곡 할 노 릇 입 니까?
용기 의 특성 에 의 한 문제 라 는 예감 이 든다.원 하지 않 는 다.
먼저 들 어가 compose_ui_1 용기 클러치 분석 을 통 해 전체 요청 체인 에 문제 가 있 는 지 살 펴 보 자.
약간의 고양 이 를 발견 한 것 같 습 니 다. Flags[R.] tcp 링크 가 reset 리 셋 되 었 습 니 다. 그런데 왜 괜 히 리 셋 되 었 습 니까?172.17.0.5.8080 돌아 오 는 것 을 보고 먼저 telnet 물 어보 세 요.
What???이게 미 치 겠 네. 우선 이거 172.17.0.5.8080 어디서 났 지?그 다음은 모 포트 가 통 하지 않 습 니까?
갑자기 중요 한 문제 가 생각 났 다.

容器之间是怎么知道它要把请求发给谁呢 ？

앞에서 말씀 드 렸 듯 이 이 두 용 기 는 link 방식 으로 연결 되 었 습 니 다. 아래 와 같이:
구 글 은 link 작업 원 리 를 찾 아 보 았 다.

link机制通过环境变量的方式提供了这些信息，除此之外像db的密码这些信息也会通过环境变量提供，docker将source container中定义的环境变量全部导入到received container中，在received container中可以通过环境变量来获取连接信息。

使用了link机制后，可以通过指定的名字来和目标容器通信，这其实是通过给/etc/hosts中加入名称和IP的解析关系来实现的

그 러 니까 compose_ui_1 에서 지 정 된 이름 에 따라 /etc/hosts 에서 구체 적 인 ip 을 번역 하고 통신 을 하 는 거 죠?용기 이름 이 뭔 지 볼 까요?compose_ui_1 의 /etc/hosts

root@e23430ed1ed7:/# cat /etc/hosts
127.0.0.1    localhost
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet
ff00::0    ip6-mcastprefix
ff02::1    ip6-allnodes
ff02::2    ip6-allrouters
172.17.0.4    detectapi fc1537d83fdf compose_api_1
172.17.0.3    authapi ff83f8e3adf2 compose_authapi_1
172.17.0.3    authapi_1 ff83f8e3adf2 compose_authapi_1
172.17.0.3    compose_authapi_1 ff83f8e3adf2
172.17.0.4    api_1 fc1537d83fdf compose_api_1
172.17.0.4    compose_api_1 fc1537d83fdf
172.17.0.6    e23430ed1ed7

정말 자료 에 따 르 면 172.17.0.4:8080 이 야 말로 compose_api_1 의 주소 가 암시 되 어야 하 는 거 죠?시험 해 보 세 요.
다시 보기 auth product is None 용기 의 로그:
그래서 거의 도망 가지 않 았 습 니 다. 왜 전단 방문 이 바로 502 입 니까? 그 이 유 는 ui 용기 가 잘못된 주소 로 요청 을 보 냈 기 때 문 입 니 다.
그럼 왜 이러 지?괜 히 바람 이 났 어?
방금 host 의 기록 에 따라 실험 을 했 습 니 다. 영상 주소 에 따라 인터페이스 요청 을 하 는 것 은 문제 가 없습니다.
로그 보기 compose_api_1 로그 보기
어색 하 다compose_ui_1 로그 가 표준 출력 과 표준 오류 에 직접 연결 되 다 니...그럼 간단하게 docker logs 로 직접 보 세 요.
보아하니 nginx 의 퍼 가기 가 잘못된 것 같 습 니 다. 왜 172.17.0.5 로 퍼 가기 되 었 는 지 nginx 퍼 가기 에 대한 설정 을 보십시오.
이거 nginx 랑 위 에 붙 어 있 는 nginx 시계 가 정확 한 주소 detectapi 를 찾 을 수 있 을까요?왜 리 트 윗 했 는 지 모 르 겠 어 요 hosts시스템 도 메 인 이름 해석 이 잘못 되 었 습 니까?
니 마, 이거 정말 신기해.
남자 의 직감 은 나 에 게 172.17.0.4 고양이 가 느끼 하 다 는 것 을 알려 준다!
용 기 를 재 부팅 한 172.17.0.5 용기 도 재 부팅 되 었 습 니 다.
페이지 를 다시 방문 하면 된다 니...
용기 의 nginx 로 그 를 다시 보 니 퍼 가기 에 성 공 했 습 니 다.
이렇게 되면 사실은 nginx 에서 문제 가 생 겼 다 는 것 을 알 수 있 을 것 이다.
고장 위치
다만 왜 nginx 이런 잘못 이 있 을 까?그 럴 리 가 없 는데.내부 도 메 인 이름 해석 캐 시 문제 인 것 같 습 니 다.
그리고 자 료 를 찾 아 봤 더 니 하하, 있 네.https://www.zhihu.com/questio...
그게 너무 어색해 요.이 문제 에 대해 약간의 의심 을 가지 고 베테랑 에 게 문의 한 후에 큰 남자 의 대답 은 바로:

如果 proxy_pass 后面跟的域名的话，在 nginx 启动的时候就会初始化好，以后就只会复用这个值；参考：ngx_http_upstream_init_round_robin 函数
如果 proxy_pass 后面跟的是upstream，配置才会走解析和缓存的逻辑；

개선 조치

실제 도 메 인 이름 이 아 닌 nginx 설정 으로 직접 전송 합 니 다.

아까 알 고 있 던 링크 처리 방안 도 참고 할 수 있다.https://www.zhihu.com/questio...;

확장 문제

왜 nginx 지 정 된 nginx 에 오류 가 발생 합 니까?

proxy_pass 뒤에 실제 도 메 인 이름과 함께 있 으 면 정말 재 활용 입 니까? 아니면 시간 캐 시 가 있 습 니까?

이 문 제 를 테스트 하려 고 했 는데 하루 가 걸 려 서 털 이 하나 도 없 었 다.하지만 작은 수확 도 있 습 니 다. 그것 은 어떻게 설정 upstream 하여 지원 하 는 지 compose_ui_1 입 니 다.
1. 컴 파일 프로필 수정: compose_api_1

ngx_compile_opt="-c"  改成 ngx_compile_opt="-c -g"

2. proxy_pass 시 컴 파일 파 라 메 터 를 추가 합 니 다. gdb 컴 파일 러 의 최적화 를 피 합 니 다.예 를 들 어 nginx 그렇지 않 으 면 컴 파일 러 는 코드 를 최적화 시 켜 디 버 깅 과정 에서 순환 하 는 일부 변수 값 을 인쇄 할 수 없고 아래 의 오 류 를 보고 할 것 이다.

value optimized out

디 버 깅 효 과 를 볼 수 있 습 니 다: nginx worker process 처리 입구: gdb여러분 의 큰 신의 조언 교 류 를 환영 합 니 다. QQ 토론 군: 258498217 전재 출처 를 밝 혀 주 십시오.https://segmentfault.com/a/11...