En primer lugar, es posible que este artículo no sea útil para los grandes, es solo un registro del proceso de búsqueda de problemas.
La cosa es así: experimenté algo muy deprimente durante la transformación de la tarea de primavera a la demanda de trabajo elástico.
La parte de trabajo elástico de la configuración es así, muy simple, la parte de trabajo elástico de la configuración
<reg:zookeeper id="regCenter" server-lists="${GAC_JOB_URL}"
namespace="${namespace}" base-sleep-time-milliseconds="1000"
max-sleep-time-milliseconds="3000" max-retries="3" />
Luego, en las propiedades, lo llamamos xxx.properties para agregar HAC_JOB_URL = 10.x.xx.xxx:2181 y
especificar -Dspring.profiles.active = uat, lógicamente debería ser sencillo reemplazar $ {HAC_JOB_URL} con lo anterior. string, pero sucedió algo extraño y se informó un error:
java.net.UnknownHostException: ${HAC_JOB_URL}: unknown error
¿De verdad me dice que imprima el error directamente sin analizar? No hay otra forma que zambullirse para encontrar la causa y buscarla. . . .
Al principio pensé que era un problema de configuración de elastic-job, pero no estaba familiarizado con él. . Luego cambié la configuración de varias maneras. Lo más deprimente es que otro proyecto también se transformó de spring-task a elastic-job, pero en realidad puede ejecutarse, y funciona muy alto ...
bueno, tal vez me equivoque, así que lo cambié de acuerdo con él, pero sigue sin funcionar, sigue siendo el mismo error. Es demasiado tarde a esta hora. Quería ir a casa del trabajo a las 18 en punto para cenar con mi esposa, pero Todo fracasó Intenté modificar varias configuraciones, pero los resultados fueron todos Del mismo modo, llegó la hora de las 21:40 de la noche, olvídalo, vámonos a casa, o que mi esposa me regañe.
De camino a casa, de repente pensé, ¿por qué no ejecutarlo localmente? Porque antes, el código se modificaba y enviaba de inmediato, y Jenkins era responsable de la construcción.
Llegué a la oficina temprano a la mañana siguiente, encendí la computadora y ejecuté localmente, pero podía comenzar normalmente. El problema en el ambiente antes de regresar al ambiente no se reproducía. Comencé a preguntarme si había un problema con el construir el script, pero no había pruebas. No puedo arrastrar a los compañeros de clase de mantenimiento al agua, así que tengo que seguir buscando el motivo.
Comencé a comparar los registros de los dos entornos y, de repente, descubrí que obviamente generaba una clave y un valor de las propiedades localmente, y el extra es el nuevo HAC_JOB_URL en xxx.properties, así que configuré esta clave en otro archivo de propiedades dentro (nosotros tengo varios archivos de este tipo, por lo que es fácil de distinguir -_-), la presentación volvió a activar la compilación jenkins, xxx, esta vez fue exitosa, y corrí, me eché a llorar. Obviamente, agregar una nueva clave a ese archivo no tiene ningún efecto, pero ¿por qué es inútil?
Abrí el paquete creado por Jenkins y encontré un problema, es decir, no importa cómo cambie el archivo xxx.properties, siempre que esté construido, generará un archivo fijo al final y el contenido del interior nunca cambiará . Está bien, la verdad está fuera, ¿verdad? Entonces lancé esta pregunta a los compañeros de clase de operación y mantenimiento, y la operación y mantenimiento dijeron que no hay un archivo xxx.properties. Bueno, sigo buscando la razón.
Pensé que resultó que las xxx.properties en el proyecto se sobrescribieron después de cada compilación, por lo que puedo comenzar con el script de compilación, así que abrí el registro de compilación de jenkins y vi un registro como este:
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
Otro resultado del proyecto que se puede iniciar con éxito es el siguiente:
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 única diferencia entre los dos es que hay una aplicación más debajo, es decir, la primera no es la última del proyecto, sino la que está debajo de /root/.jenkins/profile/jds-efg/ directorio xxx.properties Hace mucho tiempo, es por eso que se sobrescribe cada vez que se construye.
Finalmente, deje que la operación y el mantenimiento cambien el script de compilación para que se inicie normalmente.
Esta vez fue causado por los compañeros de operación y mantenimiento que escribieron el guión incorrecto descuidadamente. Puede que no sea de valor práctico para todos. Solo pensé en el proceso de posicionamiento del problema, así que hice un registro. Después de todo, incluso cené una sopa con mi mujer, pero ¿de qué sirve ?, quizás alguien que es ingenuo comete el mismo error, jeje ( ▽ )