まず第一に、この記事は大物には役に立たないかもしれません、それは問題発見プロセスの単なる記録です。
こういうことで、春の仕事から弾力的な仕事への転換の過程で、とても憂鬱なことを経験しました。
構成の弾性ジョブ部分は、このような非常に単純な構成の弾性ジョブ部分です。
<reg:zookeeper id="regCenter" server-lists="${GAC_JOB_URL}"
namespace="${namespace}" base-sleep-time-milliseconds="1000"
max-sleep-time-milliseconds="3000" max-retries="3" />
次に、プロパティでxxx.propertiesと呼び、HAC_JOB_URL = 10.x.xx.xxx：2181を追加し、-Dspring.profiles.active = uatを
指定します。論理的には、$ {HAC_JOB_URL}を上記のものに置き換えるのはスムーズです。文字列ですが、奇妙なことが起こり、エラーが報告されました：
java.net.UnknownHostException: ${HAC_JOB_URL}: unknown error
実際に、解析せずにエラーを直接出力するように教えてください。原因を見つけて探す以外に方法はありません。。。。
最初はエラスティックジョブの構成の問題だと思っていましたが、なじみがありませんでした。。次に、さまざまな方法で構成を変更しました。最も気のめいるのは、別のプロジェクトもスプリングタスクからエラスティックジョブに変換されたということですが、実際には実行でき、非常に高く実行されます...
まあ、私は間違っているかもしれません、それに合わせて変更したのですが、それでも動かない、同じエラーです。今は手遅れです。18時に仕事から帰って妻と食事をしたかったのですが、いろいろな設定を変えてみましたが、結果はすべて同じように夕方21時40分になりました。忘れて、家に帰りましょう。妻に叱られてしまいました。
家に帰る途中、突然、ローカルで実行してみませんか。以前はコードが変更されてすぐに送信され、jenkinsが構築を担当していたからです。
翌朝早くオフィスに到着し、パソコンの電源を入れて現地で走りましたが、正常に起動できました。環境に戻る前の環境の問題は再現されていませんでした。スクリプトを作成しましたが、証拠はありませんでした。メンテナンスクラスメートを水中にドラッグできないため、理由を突き止め続ける必要があります。
2つの環境のログを比較し始めたところ、プロパティのキーと値がローカルに出力されていることが突然わかりました。余分なものはxxx.propertiesの新しいHAC_JOB_URLであるため、このキーを内部の別のプロパティファイルに構成しました（この種のファイルがいくつかあるので、区別するのは簡単です-_-）、送信によってjenkinsビルドxxxが再トリガーされました。今回は成功し、実行すると、突然涙が出ました。明らかに、そのファイルに新しいキーを追加しても効果はありませんが、なぜそれが役に立たないのですか？
Jenkinsによってビルドされたパッケージを開いたところ、問題が見つかりました。つまり、xxx.propertiesファイルをどのように変更しても、ビルドされている限り、最後に固定ファイルが生成され、内部のコンテンツは変更されません。 。さて、真実は出ていますよね？そこで、この質問を運用・保守のクラスメートに投げたところ、運用・保守はxxx.propertiesファイルがないと言っていました。さて、私は理由を見つけ続けます。
プロジェクトのxxx.propertiesはビルドのたびに上書きされることがわかったので、ビルドスクリプトから始めることができるので、jenkinsビルドログを開くと、次のようなレコードが表示されました。
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
正常に開始できる別のプロジェクト出力は次のとおりです。
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
2つの違いは、下にもう1つ-appがあることです。つまり、最初のアプリはプロジェクトの最新のものではなく、/ root / .jenkins / profile / jds-efg /の下にあります。 xxx.propertiesディレクトリ。昔は、これがビルドされるたびに上書きされる理由です。
最後に、操作とメンテナンスでビルドスクリプトを変更して、正常に開始できるようにします。
今回は、不用意に間違ったスクリプトを書いた運用・保守の同級生が原因でした。誰にとっても実用的ではないかもしれません。問題の位置付けのプロセスを考えただけで、記録を残しました。結局、私も妻と夕食にスープを食べたのですが、どういう意味ですか？素朴な人も同じ過ちを犯しているのかもしれませんねへへ（▽）