Jenkinsを再起動したら、起動しなくなった。

これは想定内でした。正確に言うと、「いつか壊れるとわかっていて、そのときに直せばいい」と自分の中で判断していた。結果的にリカバリーはできたのですが、この判断の経緯を残しておきたいと思います。

こういう判断の話って、表に出てこないことが多いと思っていて。「壊れました、直しました」の記録は残っても、「なぜ放置していたのか」という部分は語られない。自分なりの考えを整理する意味でも、書いておきます。

どういう状況だったか

うちのJenkinsはJCasCで設定管理していて、JENKINS_HOME に置いた jenkins.yaml を起動時に読み込んで設定を復元する構成です。EC2 Spot Fleetをエージェントとして使っていて、そのFleetリクエストIDもYAMLに書いてある。

jenkins.yaml はGUIで設定を変更しても自動更新されません。再起動すれば常に jenkins.yaml の値が「正」として復元されます。Spot FleetはAWSのリソースなので、再作成されればIDが変わる。つまり、Fleetを再作成するたびに jenkins.yaml を更新しないと、再起動のタイミングで壊れる構造になっていました。

この構造は把握していました。

jenkins.yaml を更新するパイプラインジョブが存在していて、それを実行すれば済む話でした。ただそのジョブが、別の不具合で一時的に動かない状態になっていた。

その不具合の詳細はこちらのIssueにまとめています。

🔗 https://github.com/tielec/infrastructure-as-code/issues/560

簡単に言うと、amazon-ecs プラグイン側の設計不整合で、JCasCの check-configuration（ドライラン検証）が失敗するという問題です。実際の起動やUI経由の設定適用では問題ないのに、CLIのドライランだけ弾かれる。このプラグインバグの対処を後回しにしていた間、jenkins.yaml の更新ジョブも止まったままになっていました。

なぜ放置していたか

正直に書くと、「壊れてから直せばいい」と判断していたからです。

その根拠になっていたのは、Jenkinsのトラブルシューティングをこれまで何度も経験してきたこと。プラグインの初期化失敗、JCasCの設定エラー、共有ストレージのマウント問題——一通り経験する中で、ログのどこを見るか、原因の当たりをどうつけるか、というのが自分なりに蓄積されていました。

「Spot Fleet IDの問題なら、短時間でリカバリーできるだろう」という読みがあった。

これは正しい/正しくないという話というよりは、そのときの状況をどう読むか、という判断だったと思っています。ただ、「自分が直せる」という自信が、裏を返せば「自分にしか直せない状態」でもあったことは自覚しておかないといけない。

実際にどう直したか

再起動後にJenkinsが上がらない。ログを確認するとJCasCの適用段階でec2-fleetプラグインの初期化が失敗していました。YAMLの構文は正しく、値も埋まっている。となると参照先のAWSリソースが怪しいという読み。

# Spot FleetリクエストIDの状態確認
aws ec2 describe-spot-fleet-requests \
  --spot-fleet-request-ids sfr-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
  --query "SpotFleetRequestConfigs[].{ID:SpotFleetRequestId,State:SpotFleetRequestState}" \
  --output table

期限切れでした。jenkins.yaml のIDを現在有効なものに置換して再起動。リカバリーできました。

この判断、どう考えるか

「壊れることを知りながら動かし続ける」という選択については、賛否があると思っています。「それは怠慢だ」「known issueは即対処すべき」という立場も、原則論としては正しい。自分もそれが理想だとは思っています。

ただ現実として、すべての問題を事前に潰してから運用するのが難しい場面もあって、今回は「壊れてから直す」を選んだ。これは正しい/正しくないという話というよりは、そのときの状況をどう読むか、という判断の話だと思っています。

ただ今回を振り返ると、この判断が成り立っていたのは自分にJenkinsの経験が積み重なっていたからで、同じ構造の問題でも経験が少ない状態でやると、リカバリーに時間がかかったり、そもそも原因に辿り着けなかったりする可能性はあります。「壊れてから直す」は、直せる根拠があってはじめて成立する話で、そこは自覚しておかないといけないと思っています。

それと、自分が直せるとしても、その知見が自分の中にしかなければ、いつか限界が来る。だからこうして残しておく、というのが今回の記録の動機でもあります。

参考リソース

運用における判断やJenkinsのトラブルシューティングについて、以下の書籍が参考になります。

[📦 商品リンク: moshimo-book-sre-google]

[📦 商品リンク: moshimo-book-jenkins-jissen]