Tout d'abord, cet article peut ne pas être utile pour les grands, c'est juste un compte rendu du processus de recherche de problèmes.
La chose est comme ça: j'ai vécu une chose très déprimante lors de la transformation de la demande de ressort en demande de travail élastique.
La partie travail élastique de la configuration est comme ceci, très simple, la partie travail élastique de la configuration
<reg:zookeeper id="regCenter" server-lists="${GAC_JOB_URL}"
namespace="${namespace}" base-sleep-time-milliseconds="1000"
max-sleep-time-milliseconds="3000" max-retries="3" />
Ensuite, dans les propriétés, nous l'appelons xxx.properties pour ajouter HAC_JOB_URL = 10.x.xx.xxx:2181 et
spécifier -Dspring.profiles.active = uat, logiquement il devrait être facile de remplacer $ {HAC_JOB_URL} par ce qui précède. string, mais la chose étrange s'est produite et une erreur a été signalée:
java.net.UnknownHostException: ${HAC_JOB_URL}: unknown error
En fait, dites-moi d'imprimer l'erreur directement sans analyse? Il n'y a pas d'autre moyen que de plonger pour trouver la cause et la rechercher. . . .
Au début, je pensais que c'était un problème de configuration d'élastic-job, mais je ne le connaissais pas. . Ensuite, j'ai changé la configuration de différentes manières. Le plus déprimant est qu'un autre projet a également été transformé de spring-task en élastique-job, mais il peut réellement fonctionner, et il tourne très haut ...
eh bien, peut-être que je me trompe, alors je l'ai juste changé en fonction, mais ça ne marche toujours pas, c'est toujours la même erreur. Il est trop tard pour le moment. Je voulais rentrer du travail à 18 heures pour dîner avec ma femme, mais ça J'ai essayé de modifier diverses configurations, mais les résultats étaient tous De même, l'heure est venue à 21h40 du soir, oublions ça, rentrons à la maison, ou soyons grondés par ma femme.
Sur le chemin du retour, j'ai soudain pensé, pourquoi ne pas l'exécuter localement, car avant, le code était modifié et soumis immédiatement, et jenkins était responsable de la construction.
Je suis arrivé au bureau tôt le lendemain matin, j'ai mis l'ordinateur sous tension et je l'ai exécuté localement, mais cela pouvait démarrer normalement. Le problème dans l'environnement avant de revenir à l'environnement ne s'est pas reproduit. J'ai commencé à me demander s'il y avait un problème avec le build script, mais il n'y avait aucune preuve. Impossible de faire glisser les camarades de classe de maintenance dans l'eau, donc je dois continuer à localiser la raison.
J'ai commencé à comparer les journaux des deux environnements et j'ai soudainement constaté que je produisais évidemment une clé et une valeur de propriétés localement, et que le supplément est le nouveau HAC_JOB_URL dans xxx.properties, j'ai donc configuré cette clé dans un autre fichier de propriétés Inside (nous avoir plusieurs fichiers de ce genre, donc il est facile de distinguer -_-), la soumission a relancé la compilation jenkins, xxx, cette fois ça a réussi, et j'ai couru, j'ai fondu en larmes. Évidemment, l'ajout d'une nouvelle clé à ce fichier n'a aucun effet, mais pourquoi est-ce inutile?
J'ai ouvert le paquet construit par Jenkins et j'ai trouvé un problème, c'est-à-dire que peu importe la façon dont vous modifiez le fichier xxx.properties, tant qu'il est construit, il générera un fichier fixe à la fin, et le contenu à l'intérieur ne changera jamais . D'accord, la vérité est révélée, non? J'ai donc posé cette question aux camarades de classe d'opération et d'entretien, et l'opération et l'entretien ont dit qu'il n'y avait pas de fichier xxx.properties. Eh bien, je continue à trouver la raison.
Je pensais qu'il s'était avéré que le xxx.properties dans le projet était écrasé après chaque build, donc je peux commencer avec le script de build, donc j'ai ouvert le journal de build jenkins, et j'ai vu un enregistrement comme celui-ci:
scp -r /root/.jenkins/profile/jds-efg/xxx.properties [email protected]:/usr/local/software/abc-efg-app-tomcat/webapps/abdandaj/WEB-INF/classes/properties/uat
Une autre sortie de projet qui peut être démarrée avec succès est la suivante:
scp -r /root/.jenkins/profile/jds-efg-app/xxx.properties [email protected]:/usr/local/software/abc-efg-app-tomcat/webapps/abdandaj/WEB-INF/classes/properties/uat
La seule différence entre les deux est qu'il y a une autre -app ci-dessous, c'est-à-dire que la première n'est pas la dernière du projet, mais celle sous /root/.jenkins/profile/jds-efg/ Répertoire xxx.properties Il y a longtemps, c'est pourquoi il sera écrasé à chaque fois qu'il sera construit.
Enfin, laissez l'opération et la maintenance modifier le script de construction pour qu'il démarre normalement.
Cette fois, cela a été causé par les camarades de classe d'exploitation et de maintenance qui ont écrit le mauvais script avec négligence. Cela n'a peut-être pas une valeur pratique pour tout le monde. J'ai juste pensé au processus de positionnement du problème, alors j'ai fait un enregistrement. Après tout, j'ai même eu une soupe avec ma femme pour le dîner, mais à quoi ça sert? Peut-être que quelqu'un de naïf fait la même erreur, hehe ( ▽ )