Renovate を k8s の CronJob で回す

[5ym]

GitHub Actions (5ym/repo-config の renovate.yml) と Forgejo Actions (doa/renovate) で毎時回していた Renovate を、apps/renovate/ の CronJob にまとめる。GitHub の schedule は 15〜40 分遅れ、丸ごと飛ばされることもあった。

中身

• CronJob 3 本: renovate-danything / renovate-5ym (GitHub) / renovate-forgejo (fj.doany.io の doa)。15 分おき、5 分ずつずらす。concurrencyPolicy: Forbid
• 環境変数は今の 2 つの workflow と同じ (onboarding・RENOVATE_ALLOWED_COMMANDS など)
• GitHub App のトークンは、Renovate のイメージに入っている node で毎回作る (github-app-token.mjs。JWT → インストールを探す → トークン)
• 秘密は Infisical の /renovate/renovate-secrets (github-app-private-key / forgejo-token / github-com-token)。無いあいだは何もせずに exit 0
• Job はいつも成功で終える。失敗で CronJob が Degraded になると ArgoCD が gitops の同期を止めるため (apps/k8up/notify.yaml と同じ判断)。失敗はログで見る
• PSA は restricted。イメージの既定の非 root (12021) のまま
• postUpgradeTasks のスクリプトと renovate.json の説明にある「repo-config の renovate.yml」を apps/renovate/renovate.yaml に直した

確かめたこと

• github-app-token.mjs が作る JWT を openssl で検証した (RS256、iss = client ID)。本物の鍵での実行はまだ (鍵は Infisical に入れてから)
• 3 ファイルとも YAML として読め、RENOVATE_ALLOWED_COMMANDS が今と同じ値になる

マージ後

1. Infisical に /renovate/renovate-secrets を作って鍵を入れる (apps/renovate/README.md の表)
2. 動いたのを確かめてから、5ym/repo-config と doa/renovate の workflow の schedule を外す (workflow_dispatch は残す)

🤖 Generated with Claude Code

https://claude.ai/code/session_01JbmWyUB9jcBcYCnNyiGBSV

[claude]

Claude finished @5ym's task in 52s —— View job

---

レビュー: Renovate を k8s の CronJob で回す (#388)

• 差分と周辺 (apps/k8up、bootstrap/argocd、postUpgradeTasks の 2 スクリプト) を確認
• 不具合 / セキュリティ / 設計 / テストの観点で評価

結論: マージを止めるほどの問題は見つかりませんでした。 以下は要確認と軽い指摘です。

不具合

• 要確認: 実行頻度が 4 倍になる (毎時 → 15 分おき)。 emptyDir で毎回空から clone し、キャッシュもありません。GitHub App のインストールトークンの上限は 5000 req/h で、autodiscover の全リポジトリ分の API 呼び出しが 1 時間に 4 回分かかります。danything と 5ym でそれぞれ上限に収まるかを、初回のログ (rate limit の行) で確認してください。収まらなければ周期を延ばすか、RENOVATE_REPOSITORY_CACHE を検討してください。Forgejo 側の負荷も同様です。
• 要確認: Forgejo の Job は Pod から fj.doany.io へ IPv6 で届く前提です (renovate.yaml 238 行目)。apps/forgejo/runner.yaml と同じ経路で届くか、kubectl create job --from=cronjob/renovate-forgejo で一度確かめてください。
• 要確認: postUpgradeTasks の 2 スクリプトは、Actions のランナーから Renovate のコンテナ (非 root の 12021、readOnlyRootFilesystem なし) に動く場所が変わります。install-tool bun が書く先 (/opt/containerbase など) に 12021 で書けるか、本番の PR で最初に動かして確かめてください。ローカルで試した範囲では、ここは未検証のはずです。

セキュリティ

• 問題なし。run.sh は node でトークンを作った後に unset APP_PRIVATE_KEY していて、子プロセスの renovate や postUpgradeTasks に鍵が渡りません。automountServiceAccountToken: false、restricted の PSA、drop: [ALL]、allowPrivilegeEscalation: false も適切です。
• github-app-token.mjs のエラーメッセージには、API の応答本文とインストール先の一覧だけが出ます。鍵やトークンは出ません。
• client ID (Iv23li…) は秘密ではないという注記どおりです。
• RENOVATE_ALLOWED_COMMANDS は完全一致の正規表現で、2 スクリプトに絞れています。

設計

• exit 0 に統一する判断は、apps/k8up/notify.yaml と同じ理由なので一貫しています。ただし鍵の失効や権限の欠落が続いても、Job は成功のままで誰にも気づかれません。ログを見に行く運用に頼ることになります。
  • 当面は許容できます。ただ、気づく仕組みは別途ほしいです (例: 数時間ごとの PR 数の確認や、failedJobs に頼らない通知)。
• 3 本の CronJob で securityContext・resources・volumes がほぼ同一のコピーです (約 60 行ずつ)。GitOps の素の YAML で、kustomize も使っていないリポジトリなので、今の形で一貫性は保てています。増えたら共通化を考えれば十分です。
• resources に ephemeral-storage の request がありません。emptyDir は sizeLimit: 10Gi ですが、ノードのディスク逼迫時に退避されやすくなります。任意です。
• successfulJobsHistoryLimit: 1 だと、成功のログは次の実行までしか残りません。Job は常に成功なので、失敗の調査用ログが 1 回分しか残らない点は意識しておいてください。failedJobsHistoryLimit は実質使われません。ここは 3 程度に上げてもよいと思います。
• activeDeadlineSeconds: 2700 (45 分) はトークンの寿命 (1 時間) より短く、concurrencyPolicy: Forbid と合わせて整合しています。

テスト

• マニフェストのため自動テストは無く、JWT を openssl で検証したという本文の確認で足りています。
• 本物の鍵での実行は未了なので、マージ後の手順 1 → create job --from=cronjob/... で各 CronJob を手動で 1 回走らせてから、workflow の schedule を外す順序が重要です。README にも書かれていて適切です。
• ドキュメント更新 (README の表、renovate.json の説明、pulumi/README.md) は漏れなく揃っています。

[github-actions]

🍹 preview on doany-cloudflare/prod

Pulumi report

Previewing update (prod):

@ previewing update.....
pulumi:pulumi:Stack doany-cloudflare-prod  
Resources:
54 unchanged

[claude]

Claude finished @5ym's task in 22s —— View job

---

レビュー (更新): Renovate を k8s の CronJob で回す (#388)

新しいコミット 3267a41 (successfulJobsHistoryLimit: 3) を反映して再確認しました。前回の指摘のうち「成功のログが 1 回分しか残らない」は解消しています。3 本とも 3 になっていて、冒頭コメントの説明とも合っています。

結論: マージを止める問題はありません。 前回から増えた指摘は 1 件で、要確認です。

不具合

• 要確認: 「Job はいつも成功」にならない経路が残っています。 run.sh の exit 0 は、シェルが最後まで走った場合にしか効きません。次のケースでは Job が Failed になり、冒頭コメントで避けたい CronJob の Degraded、つまり ArgoCD の同期停止になりえます (apps/k8up/notify.yaml の判断と同じ話です)。
  • メモリ上限 4Gi を超えて OOMKill された場合 (renovate.yaml の resources.limits.memory)。大きなリポジトリや monorepo で起きやすいです。
  • activeDeadlineSeconds: 2700 に達して Job が打ち切られた場合 (clone やネットワークのハング)。
  • 今回は failedJobsHistoryLimit: 1 なので、失敗した Job は 1 つ残ります。ただ、これは Degraded を防ぎません。
  • 1 回 3〜7 分という実績なら当面は起きにくいです。初回のログでメモリ使用量を見て、余裕が薄ければ上限を上げてください。k8up の件と同じ対処 (Degraded にしない設定) が ArgoCD 側にあるか、一度確認してください。
• 要確認 (前回から継続):
  • 実行頻度が毎時から 15 分おきになり、API のレート制限が足りるか。
  • Forgejo への IPv6 経路。kubectl create job --from=cronjob/renovate-forgejo で確認できます。
  • postUpgradeTasks の 2 スクリプトが、非 root (12021) のコンテナで動くか。

セキュリティ

問題なし。鍵は unset APP_PRIVATE_KEY で子プロセスに渡さず、PSA restricted や drop: [ALL] も適切です。RENOVATE_ALLOWED_COMMANDS も 2 スクリプトに絞れています。

設計

• 3 本の CronJob でほぼ同じ記述が繰り返されています。ただ、このリポジトリの流儀 (素の YAML) に沿っていて、今は許容範囲です。
• 失敗に気づく仕組みが無い点は前回のとおりです。当面はログ運用で許容できます。

テスト

マニフェストのため自動テストはありません。本文の確認手順で足ります。マージ後は、手順 1 (Infisical に鍵を入れる) → 各 CronJob を手動で 1 回走らせる → workflow の schedule を外す、の順序を守ってください。