Déploiement distribué OpenDevOps signale un processus de résolution de problèmes d'erreur 502

Lors de l'utilisation d'une méthode distribuée pour construire OpenDevOps, il a été construit selon le document d'orientation du site officiel https://docs.opendevops.cn/zh/guide/install/distribute/ . En fin de compte, une erreur 502 a été signalée. plus d'une demi-journée Après avoir trouvé le problème, je l'ai finalement résolu, maintenant enregistrez-le. Le processus de solution spécifique est le suivant

Signaler une erreur

Après avoir configuré le front-end et le back-end, utilisez des commandes pour vérifier si les services sont sains avant de déployer la passerelle, et constatez que tout renvoie 200, puis passez directement à l'étape suivante.

Utilisez la commande pour tester après le déploiement de la passerelle

[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/

Une erreur 502 s'affiche.

Accédez à la section FAQ du document et constatez qu'il existe des solutions à l'erreur

502. Étant donné que 502 est une erreur de configuration de la passerelle, nous devons vérifier la configuration de la passerelle et la configuration DNS. Ensuite, je les examinerai encore deux aspects.

Vérification DNS

DNS est déployé en stricte conformité avec le contenu du document, et lors de la vérification de la santé de chaque service auparavant, il a également montré 200. Lors de la commande ping de tous les noms de domaine, il peut être ping. nom de domaine. Mais juste au cas où, vérifiez le fichier de configuration.

Vérifiez le fichier /etc/resolv.conf

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

Le contenu du fichier est le suivant:

où 192.168.134.156 est l'adresse IP du DNS interne, il est bien placé dans le premier élément, et il n'y a pas de problème.

Vérifiez le fichier /etc/resolv.dnsmasq

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

Le contenu du fichier est le suivant: Le

document de construction indique que ce fichier est utilisé pour configurer le DNS en amont, mais je l'ai testé avant et j'ai utilisé un proxy pour surfer sur Internet. Si ce DNS est configuré, le nom de domaine OpenDevOps ne peut pas être ping, donc je l'ai commenté.
Aucun problème ici

Vérifiez le fichier / etc / dnsmasqhosts

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

Le contenu du fichier est le suivant:

je déploie tous les modules sur une seule machine, tous les noms de domaine pointent vers la même adresse IP, et le résultat analysé est également résolu sur la même adresse IP, j'ai donc examiné de plus près ici et il n'y a pas problème.
Plus tard, j'ai pensé que le port d'écoute DNS est le port 53 / udp. Le service de docker est-il incapable de se connecter à ce port lors de la vérification du serveur dns via la configuration dns, ce qui entraîne le rapport d'erreur 502 causé par le fait de ne pas obtenir l'IP, je telnet sur d'autres serveurs, j'ai vérifié ce port et j'ai trouvé qu'il était vraiment bloqué, j'ai donc ouvert le port 53 sur le pare-feu:

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

Surcharger les règles de pare-feu

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

Puis découvert, toujours pas possible. L'erreur 502 existe toujours.

Mais le port 53 doit en effet être ouvert, car plus tard, mon problème 502 a été résolu et j'ai essayé de fermer le port 53 et j'ai trouvé qu'il y avait effectivement une erreur 502, et le journal a montré

À ce stade, la vérification DNS est terminée, et finalement j'ai redémarré le DNS sans abandonner, et j'ai constaté que le résultat ne fonctionnait toujours pas, tous les noms de domaine creusés peuvent être résolus, mais la passerelle signale toujours 502.
Peut seulement passer à l'étape suivante

Vérification de la passerelle

La vérification de la passerelle consiste en fait à suivre les étapes de construction de la passerelle avant et à la relire.
Vérifiez le fichier nginx.conf

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

Le contenu du fichier est le suivant:
Seule l'adresse DNS du résolveur est modifiée dans nginx.conf, qui est bien l'adresse du DNS local, pas de problème.

Vérifiez le fichier gw.conf

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

Le contenu du fichier est le suivant: après l'avoir lu

attentivement, je pense qu'il est bon de conserver cette partie par défaut. Je ne l'ai pas modifié auparavant et il n'est pas nécessaire de le modifier. Cette partie est bien.

Vérifiez le fichier configs.lua

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

Le contenu du fichier est le suivant: La

partie supérieure se préoccupe principalement de savoir si la configuration redis et token_sercret, rewrite_cache_tocken et le fichier de configuration du backend de gestion /opt/codo/codo-admin/settings.py sont cohérents avec token_secret et secret_key. Il n'y a pas de problème après une comparaison minutieuse ici. La

seconde moitié consiste principalement à vérifier si les ports de rui et de nom de domaine correspondent. Il n'y a pas de modification ici. Conservez la valeur par défaut. Après une comparaison minutieuse, il n'y a pas de problème.
Vérifiez le Dockerfile

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

Le contenu du fichier est le suivant: Le

fichier Dockerfile est en fait copié et collé directement à partir du document, sans aucune modification, il suffit de vérifier s'il est cohérent avec le document. J'ai vérifié et il n'y a pas de problème.
À ce stade, la vérification du fichier de passerelle est terminée.
J'ai toujours le sentiment que cela ne devrait pas être le cas, chaque étape est conforme au document et une erreur sera signalée à la fin. Je retélécharge le code source, j'importe l'image, je modifie la configuration et je compile et démarre le docker. Enfin, j'ai vérifié avec espoir. Toujours signalé 502.

Afficher le port de journalisation de la passerelle ouvert

Suite aux idées de dépannage du site officiel, je n'ai pas trouvé le problème. A ce moment, j'ai soudainement pensé à regarder le journal de la passerelle (j'aurais dû regarder le journal de la passerelle au début, mais à l'époque j'ai pensé à suivre le site officiel et n'a pas fait attention)

Le journal des erreurs de la passerelle est: /usr/local/openresty/nginx/logs/error.log. Il n'y a pas de note spéciale dans la documentation officielle, mais elle peut être trouvée dans le fichier de configuration.

J'ai vu une erreur dans le journal

Le journal n'était pas tenu clair à l'époque, il s'agit d'une post-simulation

Aucune route vers l'hôte n'est affichée et le port approprié n'est pas ouvert. Ainsi, les ports suivants ont été ouverts sur le pare-feu

[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

Ensuite, vérifiez le journal de la passerelle, il n'a pas signalé l'erreur aucune route vers l'hôte et a commencé à générer des rapports (5: opération refusée)

Ce rejet indique que les noms de domaine des modules backend sont connectés, mais la connexion est refusée.J'ai commencé à soupçonner que certains modules pourraient ne pas être démarrés normalement, j'ai donc vérifié à nouveau les modules backend.

Afficher chaque journal de module

Frontend
Le chemin du journal du frontal se trouve sous / var / log / nginx. Il existe au total 6 fichiers journaux, dont error.log est le journal des erreurs. Cela dépend principalement de la présence ou non d'une erreur dans error.log.

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

Uniquement lorsque le nom de domaine est inaccessible au début du déploiement, car ma machine de test est sur le réseau interne et ne peut pas accéder directement à Internet, elle utilise un proxy pour se connecter au réseau externe. Une fois le proxy défini, le front- end nginx signalera une erreur s'il ne trouve pas le nom de domaine, puis redémarrez le frontal.

Arrière-plan
Tous les journaux sont en arrière-plan / var / log / supervisor / Under

où:

• cmdb_cron.log et cmdb.log sont les journaux du module de gestion des actifs
• codo_dns est le journal du module de gestion des noms de domaine
• cron_jobs.log et cron.log sont des journaux du module de tâche de chronométrage
• exec_task.log, task_cron_app.log, task_other.log et task_scheduler.log sont des journaux des modules du système de tâches
• kerrigan.log est le journal du module du centre de configuration
• tools.log est le journal du module de l'outil d'exploitation et de maintenance
• mg.log est le journal du backend de gestion.

Des messages d'erreur tels que mysql, redis, mq, etc. qui ne peuvent pas être connectés peuvent apparaître dans le journal, comme indiqué ci-dessous: Le
port 5672 est le port par défaut de RabbitMQ. Le message d'erreur ici indique que RabbitMQ ne peut pas être connecté. Vérifiez qu'il est une erreur de configuration IP de mq. S'il y a des erreurs dans ces journaux, vérifiez principalement la configuration des modules concernés. Si la configuration confirme qu'il n'y a pas de problème ou qu'une erreur est signalée, il se peut que le port ne soit pas ouvert sur le pare-feu. Utilisez la commande suivante pour ouvrir le port 5672 (les ports par défaut de redis et mysql sont de préférence ouverts aussi)

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

Surcharger les règles de pare-feu

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

Après avoir redémarré le module et consulté le journal, il n'y a pas d'erreur.
Après avoir vérifié tous les modules via la méthode ci-dessus, puis redémarré la passerelle, le test a révélé que l'erreur 502 ... 502 n'est en fait pas liée à la santé du service d'arrière-plan, car si le service ne démarre pas normalement, le navigateur rapportera 500. Faux, mais il vaut mieux vérifier.
Allez voir le journal de la passerelle

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

Trouvé toujours signalé (5: Opération refusée)

Afficher les journaux de la passerelle - résolution des problèmes

J'ai lu tous les endroits qui peuvent mal tourner, mais le problème n'est toujours pas résolu. Enfin décidé de commencer par le journal et de démarrer Baidu. Baidu a recherché "5: opération refusée nginx", et j'ai trouvé ce lien un par un:

"Pit" dans la configuration du résolveur NGINX

Il y a un paragraphe disant que
je suis donc allé dans le conteneur du docker pour vérifier la version de mon nginx

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

Voyant que la version est openresty / 1.15.8.1, elle est en effet supérieure à la version 1.11.5.

J'ai donc modifié le fichier de configuration nginx dans le conteneur et ajouté le paramètre ipv6 = off.

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

Après avoir redémarré le conteneur de passerelle et vérifié à nouveau, il s'est avéré normal 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/

Ensuite, visitez le navigateur -> entrez le mot de passe du compte -> connexion réussie