Em primeiro lugar, este artigo pode não ser útil para os grandes caras, é apenas um registro do processo de localização de problemas.
A coisa é assim: eu experimentei uma coisa muito deprimente durante a transformação de tarefa de mola para demanda de trabalho elástico.
A parte elástica da configuração é assim, muito simples, a parte elástica da configuração
<reg:zookeeper id="regCenter" server-lists="${GAC_JOB_URL}"
namespace="${namespace}" base-sleep-time-milliseconds="1000"
max-sleep-time-milliseconds="3000" max-retries="3" />
Em seguida, nas propriedades, chamamos de xxx.properties para adicionar HAC_JOB_URL = 10.x.xx.xxx:2181 e
especificar -Dspring.profiles.active = uat, logicamente deve ser suave substituir $ {HAC_JOB_URL} pelo acima string, mas uma coisa estranha aconteceu e um erro foi relatado:
java.net.UnknownHostException: ${HAC_JOB_URL}: unknown error
Na verdade, diga-me para imprimir o erro diretamente sem analisar? Não há outra maneira a não ser mergulhar para encontrar a causa e procurá-la. . . .
A princípio pensei que fosse um problema de configuração do elástico-job, mas não estava familiarizado com ele. . Então eu mudei a configuração de várias maneiras. O mais deprimente é que outro projeto também foi transformado de tarefa elástica para tarefa elástica, mas pode realmente rodar e rodar muito alto ...
bem, talvez eu esteja errado, então eu só mudei de acordo com ele, mas ainda não funciona, ainda é o mesmo erro. É muito tarde nessa hora. Eu queria ir para casa do trabalho às 18 horas para jantar com minha esposa, mas Tentei modificar várias configurações, mas os resultados foram todos Da mesma forma, chegou a hora das 21:40 da noite, esquece, vamos para casa ou seremos repreendidos pela minha mulher.
No caminho para casa, de repente pensei, por que não executá-lo localmente, porque antes, o código foi modificado e enviado imediatamente, e Jenkins era o responsável pela construção.
Cheguei ao escritório na manhã seguinte, liguei o computador e rodei localmente, mas podia iniciar normalmente. O problema no ambiente antes de retornar ao ambiente não se reproduzia. Comecei a me perguntar se havia algum problema com o construir o script, mas não havia evidências. Não é possível arrastar os colegas de manutenção para a água, então tenho que continuar a localizar o motivo.
Comecei a comparar os logs dos dois ambientes e de repente descobri que obviamente produzo alguma chave e valor de propriedades localmente, e o extra é o novo HAC_JOB_URL em xxx.properties, então configurei essa chave para outro arquivo de propriedades interno (nós tenho vários arquivos desse tipo, então é fácil distinguir -_-), o envio disparou novamente o build jenkins, xxx, desta vez foi bem-sucedido e eu corri, comecei a chorar. Obviamente, adicionar uma nova chave a esse arquivo não tem efeito, mas por que é inútil?
Abri o pacote construído pelo Jenkins e encontrei um problema, ou seja, não importa como você altere o arquivo xxx.properties, desde que esteja compilado, ele irá gerar um arquivo fixo no final, e o conteúdo dentro nunca mudará . Ok, a verdade foi revelada, certo? Então eu joguei essa questão para os colegas de operação e manutenção, e a operação e manutenção disse que não existe o arquivo xxx.properties. Bem, continuo a descobrir o motivo.
Achei que xxx.properties no projeto foi sobrescrito após cada compilação, então posso começar com o script de compilação, então abri o log de compilação jenkins e vi um 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
Outra saída do projeto que pode ser iniciada com sucesso é a seguinte:
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
A única diferença entre os dois é que há mais um -app abaixo, ou seja, o primeiro não é o mais recente do projeto, mas o que está sob o /root/.jenkins/profile/jds-efg/ Diretório xxx.properties. Há muito tempo atrás, é por isso que ele será sobrescrito toda vez que for compilado.
Por fim, deixe a operação e a manutenção alterar o script de construção para iniciar normalmente.
Desta vez foi causado pelos colegas de operação e manutenção que escreveram o roteiro errado de forma descuidada. Pode não ter valor prático para todos. Só pensei no processo de posicionamento do problema, então fiz um registro. Afinal, até tomei uma sopa com minha mulher no jantar, mas qual é o ponto? Talvez alguém ingênuo cometa o mesmo erro, hehe ( ▽ )