분산 배포 OpenDevOps는 502 오류 문제 해결 프로세스를보고합니다.

분산 방식을 사용하여 OpenDevOps를 빌드 할 때 공식 웹 사이트의 지침 문서 https://docs.opendevops.cn/zh/guide/install/distribute/ 에 따라 빌드되었으며 결국 502 오류가보고되었습니다. 반나절 이상 문제를 발견 한 후 마침내 해결했고 이제 녹화합니다. 구체적인 솔루션 프로세스는 다음과 같습니다.

오류 신고

프런트 엔드 및 백 엔드를 설정 한 후 명령을 사용하여 게이트웨이를 배포하기 전에 서비스가 정상인지 확인하고 모두 200을 반환 한 후 다음 단계로 바로 이동합니다.
여기에 사진 설명 삽입
명령을 사용하여 게이트웨이 배포 후 테스트

[root@localhost api-gateway]# curl -I -X GET -m 10 -o /dev/null -s -w %{http_code} http://gw.opendevops.cn:8888/api/accounts/are_you_ok/

502 오류가 표시됩니다.
여기에 사진 설명 삽입
문서의 FAQ 섹션으로 이동하여 502 오류에 대한 해결책이 있음을 확인했습니다.
여기에 사진 설명 삽입
502는 게이트웨이 구성 오류이므로 게이트웨이 구성 및 DNS 구성을 확인해야합니다. 그런 다음이를 살펴 보겠습니다. 다시 두 가지 측면.

DNS 확인

DNS는 문서의 내용에 따라 엄격하게 배치되어 있으며, 이전에 각 서비스의 건전성을 확인했을 때도 200 개를 보였습니다. 모든 도메인 이름을 ping 할 때 ping을 할 수 있습니다. 도메인 이름. 그러나 경우에 따라 구성 파일을 확인하십시오.

/etc/resolv.conf 파일 확인

[root@localhost api-gateway]# vim /etc/resolv.conf

파일 내용은 다음과 같습니다.
여기에 사진 설명 삽입
여기서 192.168.134.156은 내부 DNS의 IP 주소이며 실제로 첫 번째 항목에 배치되며 문제가 없습니다.

/etc/resolv.dnsmasq 파일을 확인하십시오.

[root@localhost api-gateway]# vim /etc/resolv.dnsmasq

파일의 내용은 다음과 같습니다.
여기에 사진 설명 삽입
빌드 문서에이 파일이 업스트림 DNS를 설정하는 데 사용되었다고되어 있지만 이전에 테스트 한 후 프록시를 사용하여 인터넷을 검색했습니다.이 DNS가 구성된 경우 OpenDevOps 도메인 이름 핑할 수 없으므로 주석 처리했습니다.
여기에 문제 없습니다

/ etc / dnsmasqhosts 파일을 확인하십시오.

[root@localhost api-gateway]# vim /etc/dnsmasqhosts

파일의 내용은 다음과 같습니다.
여기에 사진 설명 삽입
모든 모듈을 단일 시스템에 배포하고 모든 도메인 이름이 동일한 IP를 가리키고 파싱 된 결과도 동일한 IP로 확인되므로 여기서 자세히 살펴 보았는데 문제.
나중에 DNS 수신 포트가 53 / udp 포트라고 생각했습니다 .DNS 구성을 통해 DNS 서버를 확인할 때 docker의 서비스가이 포트에 연결할 수 없는지, 그 결과 IP를 얻지 못해 502 오류보고가 발생했습니다. 다른 서버의 텔넷이 포트를 확인한 결과 실제로 차단 된 것으로 나타 났으므로 방화벽에서 포트 53을 열었습니다.

[root@localhost api-gateway]# firewall-cmd --zone=public --add-port=53/udp --permanent

방화벽 규칙 과부하

[root@localhost api-gateway]# firewall-cmd --reload

그런 다음 여전히 불가능하다는 것을 알았습니다. 502 오류가 여전히 존재합니다.

그러나 나중에 내 502 문제가 해결되고 포트 53을 닫으려고 시도하고 실제로 502 오류가 있음을 발견했기 때문에 포트 53이 실제로 열릴 것입니다.
여기에 사진 설명 삽입

이 시점에서 dns 확인이 완료되고 마침내 포기하지 않고 dns를 다시 시작했는데 결과가 여전히 작동하지 않고 모든 도메인 이름 dig를 확인할 수 있지만 게이트웨이는 여전히 502를보고합니다.
다음 단계로만 계속할 수 있습니다.

게이트웨이 확인

게이트웨이 검사는 실제로 이전에 게이트웨이를 구축하는 단계를 따르고 다시 읽는 것입니다.
nginx.conf 파일 확인

[root@localhost api-gateway]# vim /opt/codo/api-gateway/conf/nginx.conf

파일의 내용은 다음과 같습니다.
여기에 사진 설명 삽입nginx.conf에서 리졸버의 dns 주소 만 수정됩니다. 실제로 로컬 DNS의 주소입니다. 문제 없습니다.

gw.conf 파일 확인

[root@localhost api-gateway]# vim /opt/codo/api-gateway/conf/conf.d/gw.conf

파일의 내용은 다음과 같습니다.
여기에 사진 설명 삽입
꼼꼼히 읽어 본 후이 부분을 ​​기본으로 유지하는 것이 좋다고 생각 합니다만, 이전에 수정 한 적이없고 수정할 필요가 없습니다. 이 부분은 괜찮습니다.

configs.lua 파일 확인

[root@localhost api-gateway]# vim /opt/codo/api-gateway/lua/configs.lua

파일의 내용은 다음과 같습니다.
여기에 사진 설명 삽입
상단 부분은 주로 redis 구성 및 token_sercret, rewrite_cache_tocken 및 관리 백엔드 구성 파일 /opt/codo/codo-admin/settings.py가 token_secret 및 secret_key와 일치하는지 여부와 관련이 있습니다. 여기서주의 깊게 비교해도 문제가 없습니다.
여기에 사진 설명 삽입
하반기는 주로 rui와 도메인 이름 포트가 일치하는지 확인하는 것입니다. 여기에서는 수정이 없습니다. 기본값을 유지합니다. 신중하게 비교하면 문제가 없습니다.
Dockerfile 확인

[root@localhost api-gateway]# vim /opt/codo/api-gateway/docker-compose.yml

파일의 내용은 다음과 같습니다.
여기에 사진 설명 삽입
Dockerfile 파일은 실제로 문서에서 직접 복사하여 붙여 넣으며 전혀 수정하지 않고 문서와 일치하는지 확인합니다. 확인했는데 문제가 없습니다.
이 시점에서 게이트웨이 파일 검사가 완료되었습니다.
나는 항상 이것이 사실이 아니라고 생각하며 모든 단계는 문서에 따라 이루어지며 결국 오류가보고됩니다. 소스 코드를 다시 다운로드하고, 이미지를 가져오고, 구성을 수정하고, Docker를 컴파일하고 시작합니다. 마침내 나는 희망적으로 확인했다. 여전히 502로보고되었습니다.

열린 게이트웨이 로그 포트보기

공식 홈페이지의 트러블 슈팅 아이디어에 따라 문제를 찾지 못했는데, 이때 갑자기 게이트웨이 로그를 보겠다고 생각했습니다. (처음에는 게이트웨이 로그를 봤어야했는데, 그때는 공식 웹 사이트에 관심을 기울이지 않았습니다)

게이트웨이의 오류 로그는 /usr/local/openresty/nginx/logs/error.log입니다. 공식 문서에는 특별한 내용이 없지만 구성 파일에서 찾을 수 있습니다.

로그에서 오류를 보았습니다

로그는 당시에 명확하게 유지되지 않았습니다. 이것은 사후 시뮬레이션입니다.

호스트에 대한 경로가 표시되지 않고 적절한 포트가 열려 있지 않습니다. 따라서 방화벽에서 다음 포트가 열렸습니다.

[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8010/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8020/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8030/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8040/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8050/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8060/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8080/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=8888/tcp --permanent
[root@localhost supervisor]# firewall-cmd --zone=public --add-port=9900/tcp --permanent
[root@localhost supervisor]# firewall-cmd --reload

그런 다음 게이트웨이 로그를 확인하고 호스트에 대한 경로 없음 오류를보고하지 않고보고를 시작했습니다 (5 : 작업 거부 됨).
미소여기에 사진 설명 삽입

거부 됨은 백엔드 모듈의 도메인 이름이 연결되어 있지만 연결이 거부되었음을 나타냅니다. 일부 모듈이 정상적으로 시작되지 않을 수 있다고 의심되기 시작하여 백엔드 모듈을 다시 확인했습니다.

각 모듈 로그보기

프런트
엔드 프런트 엔드의 로그 경로는 / var / log / nginx 아래에 있으며 총 6 개의 로그 파일이 있으며이 중 error.log가 오류 로그입니다. 주로 error.log에 오류가 있는지 여부에 따라 다릅니다.

[root@localhost api-gateway]# vim /var/log/nginx/error.log

여기에 사진 설명 삽입
내 테스트 머신이 내부 네트워크에 있고 인터넷에 직접 액세스 할 수 없기 때문에 배포 초기에 도메인 이름에 연결할 수없는 경우에만 프록시를 사용하여 외부 네트워크에 연결합니다. 프록시가 설정되면 전면 end nginx는 도메인 이름을 찾을 수없는 경우 오류를보고 한 다음 프런트 엔드를 다시 시작합니다.

배경
모든 로그는 배경 / var / log / supervisor / 아래
여기에 사진 설명 삽입
에 있습니다.

  • cmdb_cron.log 및 cmdb.log는 자산 관리 모듈의 로그입니다.
  • codo_dns는 도메인 이름 관리 모듈의 로그입니다.
  • cron_jobs.log 및 cron.log는 타이밍 태스크 모듈의 로그입니다.
  • exec_task.log, task_cron_app.log, task_other.log 및 task_scheduler.log는 태스크 시스템 모듈의 로그입니다.
  • kerrigan.log는 구성 센터 모듈의 로그입니다.
  • tools.log는 운영 및 유지 보수 도구 모듈의 로그입니다.
  • mg.log는 관리 백엔드의 로그입니다.

연결할 수없는 mysql, redis, mq 등
여기에 사진 설명 삽입의 오류 메시지는 아래와 같이 로그에 나타날 수 있습니다. Port 5672는 RabbitMQ의 기본 포트입니다. 여기의 오류 메시지는 RabbitMQ를 연결할 수 없음을 나타냅니다. mq의 IP 구성 오류입니다. 이러한 로그에 오류가있는 경우 주로 관련 모듈의 구성을 확인하십시오. 구성에서 문제가없는 것으로 확인되거나 오류가보고되면 방화벽에서 포트가 열려 있지 않을 수 있습니다. 다음 명령을 사용하여 포트 5672를 엽니 다 (redis 및 mysql의 기본 포트도 바람직하게는 열려 있음).

[root@localhost supervisor]# firewall-cmd --zone=public --add-port=5672/tcp --permanent

방화벽 규칙 과부하

[root@localhost supervisor]# firewall-cmd  --reload

모듈을 다시 시작하고 로그를 보면 오류가 없습니다.
여기에 사진 설명 삽입위의 방법을 통해 모든 모듈을 확인한 후 게이트웨이를 다시 시작한 후 테스트에서 502 ... 502 오류가 실제로 백그라운드 서비스의 상태와 관련이 없음을 확인했습니다. 서비스가 정상적으로 시작되지 않으면 브라우저가 500을보고합니다. 틀렸지 만 확인하는 것이 좋습니다.
게이트웨이 로그보기로 이동

[root@localhost supervisor]# vim /usr/local/openresty/nginx/logs/error.log

여전히보고 된 발견 (5 : 작업 거부)
여기에 사진 설명 삽입

게이트웨이 로그 문제 해결보기

잘못 될 수있는 모든 곳을 읽었지만 문제는 여전히 해결되지 않았습니다. 마침내 로그로 시작하여 Baidu를 시작하기로 결정했습니다. Baidu는 "5 : operation rejectd nginx"를 검색했고이 링크를 하나씩 찾았습니다.

NGINX 해석기 구성의 "구덩이"


여기에 사진 설명 삽입그래서 nginx의 버전을 확인하기 위해 docker 컨테이너로 갔다 는 단락이 있습니다.

[root@localhost supervisor]# docker exec -it api-gateway_gateway_1 bash
[root@84229c61f571 sbin]# cd /usr/local/openresty/nginx/sbin/ && ./nginx -v

버전이 openresty / 1.15.8.1 인 것을 보면 실제로 1.11.5 버전보다 높습니다.
여기에 사진 설명 삽입
그래서 컨테이너의 nginx 구성 파일을 수정하고 ipv6 = off 매개 변수를 추가했습니다.

[root@84229c61f571 sbin]# vi /usr/local/openresty/nginx/conf/nginx.conf

여기에 사진 설명 삽입게이트웨이 컨테이너를 다시 시작하고 다시 확인한 후 정상 200으로 확인되었습니다.

[root@localhost api-gateway]# curl -I -X GET -m 10 -o /dev/null -s -w %{http_code} http://gw.opendevops.cn:8888/api/accounts/are_you_ok/

여기에 사진 설명 삽입
그런 다음 브라우저를 방문-> 계정 비밀번호 입력-> 성공적인 로그인
여기에 사진 설명 삽입
여기에 사진 설명 삽입

추천

출처blog.csdn.net/xiguashixiaoyu/article/details/106665793