[5ym]

2026-10-17 に Talos へ移し終えたので、Ubuntu + k3s 期の残りを消し、建て直しの手順を Talos → Talos の形に書き直す。

消したもの

• backup/(k3s-backup と systemd unit・env.example・k3s-server-config.yaml)、recovery/restore.sh
• talos/drift.sh(Ubuntu のホストと比べる道具)、talos/after-migration/(中身は apps/k8up/ へ移した。下)
• docs/restore-drill.md(k3s ホストを QEMU で戻すドリル)、docs/migration-day.md(今も効くところは recovery/README.md へ)
• bootstrap/apiserver/authentication-config.yaml(k3s の /etc/rancher/k3s/ に置いていた写し。正本は talos/patches/apiserver.yaml で、理由のコメントはあちらへ移した。値は変えていない)
• talos/cilium-values.yaml / talos/cert-manager-values.yaml(bootstrap/ の values.yaml に畳んだ。重ねる相手の k3s が無い)
• bootstrap/apiserver/ca.crt の k3s の CA。残る 1 枚は talos/clusterconfig/kubeconfig の certificate-authority-data と同じ(SHA-256 A5:76:EF:…:39:D0 で突き合わせた)
• cilium-drift.yml の k3s の分岐、notify.yaml のホストのスクリプト用の判定(複数経路のスナップショット)
• apps/・talos/・bootstrap/ のコメントの「k3s 期は…」「Ubuntu 期は…」(今も効いている理由だけ残した)
• apps/adguardhome/pvc.yaml の adguardhome-ssl(どの Pod も使っていない。下)

書き直したもの

• recovery/README.md を建て直しの唯一の入口にした(1 鍵と render.sh → 2 ISO → 3 apply-config → 4 bootstrap/kubeconfig → 5 bootstrap apply → 6 Infisical の DB → 7 Kubernetes auth の CA → 8 PV → 9 確認 → 10 後始末)。今日踏んだものはそれぞれの手順の横に理由を書いた
• 道具: recovery/pv.sh(k8up の Restore を root で、SQLite は大きさを突き合わせて付け替え、tar 展開、pg_dump、Argo CD の一時停止)、recovery/infisical.sh + infisical-ca.mjs(restic から直接 DB を戻す・old_public の後始末・Kubernetes auth の CA の PATCH と operator の蹴り直し)。当日 .home/ で使ったスクリプトから決め打ちを外したもの
• bootstrap-apply.yml: Namespace を先に当てる(初回の namespaces "auth" not found 対策)
• talos-validate.yml: bootstrap/cilium/** と bootstrap/cert-manager/** でも走る(render.sh が読む)
• etcd の日次スナップショットを apps/k8up/etcd-snapshot.yaml に置いた(マージで有効になる)。時刻は 13:45 → 13:00 UTC(13:30 に matrix の Schedule が入っていて forget のロックとぶつかる)
• 文書の圧縮(行数 前 → 後): ROADMAP 127 → 63、docs/talos.md 408 → 192、docs/decisions.md 696 → 627、talos/README.md 154 → 109、bootstrap/README.md 208 → 172、bootstrap/cilium/README.md 86 → 38、apps/k8up/README.md 393 → 329、recovery/README.md 76 → 274(migration-day 271 と restore-drill 185 を吸収)。Markdown 全体で 4172 → 3294

確かめたこと

• CI と同じダミーの秘密で render.sh を前後で回し、鍵・証明書・毎回変わる値を除いて生成物が同じ(valid for metal mode)
• workflow と apps/bootstrap/talos の YAML が全部読める、Markdown の相対リンクが全部ある、sh -n が通る

迷ったところ・見てほしいところ

• pv.sh / infisical.sh は引数にした形ではまだ流していない(元のスクリプトは当日通った)。次の建て直しかリハーサルで確かめる必要がある
• adguardhome-ssl は残り物と判断して消した。 DoT の証明書は同名のボリューム(Secret adguard-dot-tls)で渡していて、PVC はどの Pod もマウントしていない(Traefik の acme-watcher の頃の残り)。Argo CD の prune で PVC と PV が消え、通知は restic の /data/adguardhome-ssl について 8 日鳴る。要らなければ最後のコミットだけ落とせる
• 前のホストのスナップショット(host=main)はもう誰も forget しない(保持を回していたのはホストのスクリプト自身)。消すかどうかを ROADMAP の Phase 3 に置いた。消すまで denpa の forget なども効かない
• bootstrap/argocd/helmchart.yaml(SOPS)のコメントが消した docs/restore-drill.md を指したまま。SOPS ファイルは触らない約束なので ROADMAP に残した
• apps/pt3/rebind.yaml の「移行当日」の 1 語は、触らない約束なので残した
• 途中で main に入った kubectl / talosctl の資格情報を tools/t.ps1 のコンテナで用意する #403・tools: クラスタへの行き先を 10.10.0.4 にする #405・tools: 管理者の kubeconfig もファイルで持たず、その場で作る #407(t.ps1 が kubeconfig / talosconfig をその場で作る)に合わせて、手順から --talosconfig・-n/-e・kubeconfig の取り直しを外した。talosctl upgrade-k8s は既定でクラスタの endpoint(10.0.0.2)に行くので --endpoint https://10.10.0.4:6443 を書いた(ここは未確認)
• レビューの指摘で、pv.sh / infisical.sh を流し直しに耐える形にした(控えの上書き・old_public の残り・空の DB で起こさない・port-forward を待つ)
• 復元のリハーサルは、ノードにシェルが無く前の形(本番の上の QEMU)では回せない。回す場所は未定のまま ROADMAP に

🤖 Generated with Claude Code

https://claude.ai/code/session_01JbmWyUB9jcBcYCnNyiGBSV

[claude]

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

---

レビュー結果

削除と文書の整理は、消したファイルへの参照が残っていないか grep で確認しました。残っているのは PR 本文に書いてある bootstrap/argocd/helmchart.yaml:45 だけです。adguardhome-ssl もボリューム名(Secret adguard-dot-tls)として deployment.yaml に残っているだけで、PVC への参照はありません。ここは問題ありません。指摘は recovery/ の新しいスクリプトに集中しています。なお、スクリプトは読んだだけで実行していません。

不具合(要確認を含む)

1. recovery/pv.sh の stop を 2 回流すと、控えが 0 で上書きされます。
   • : > "$REP" で控えを空にしてから、現在の replicas を書き直しています。
   • 途中で失敗して stop を流し直すと、すでに 0 になっているものを「元は 0」と記録します。
   • そのあと start を流しても何も起き上がりません。
   • 控えが既にあるときは上書きしない(または 0 を記録しない)ほうが安全です。
2. recovery/infisical.sh db は途中で落ちたあと、そのまま流し直せません。
   • ALTER SCHEMA public RENAME TO old_public は old_public が既にあると失敗します。ON_ERROR_STOP で止まり、Infisical は 0 のままです。
   • 流し直す前に drop-old するか、old_public があれば rename を飛ばす分岐が要ります。
   • README の 6 に一言あるとよいです。
3. infisical.sh db で、ダンプの流し込みが失敗しても || true で先へ進みます。
   • 件数と ERROR の上位は出ますが、users と projects が 0 件でも Infisical を replicas=1 に戻して起こします。
   • 空の DB で起動して新しい状態を作るのを避けるため、件数が 0 なら止めるほうがよいです(要確認。現状は人が出力を見て止める前提に見えます)。
4. infisical.sh ca は port-forward のあと sleep 3 で待っています。
   • 立ち上がりが遅いと fetch が接続拒否になります。
   • /tmp/pf.log を見るか、接続できるまでリトライするほうが堅いです。
   • 固定ポート 18080 が埋まっていると、別のプロセスに繋がる恐れもあります。
5. pv.sh pgload は psql ... || true で、失敗しても rm -f までそのまま進みます。
   • ダンプは PVC から消えますが、snapshot から戻せるので致命的ではありません。
   • 書き込み先の /var/lib/postgresql/data は、イメージや PGDATA の設定によって実際のマウント先と違う場合があります(要確認)。

セキュリティ

• infisical-ca.mjs の identity ID は秘密ではありません。トークンは env 経由で、表示もしていません。問題ありません。
• pv.sh は引数を sh -c にそのまま埋め込んでいます。運用者が自分で打つ引数なので実害はありませんが、信頼できない値は渡さない前提です。

設計・その他

• etcd-snapshot を 13:00 UTC に動かすのは、13:30 の matrix の Schedule とぶつからないので妥当です。ただし 13:00 開始のジョブが 30 分以内に終わる前提です。スナップショットが大きくなったら重なります。
• host=main のスナップショットを誰も forget しない件を ROADMAP に置いたのは適切です。保持が無制限になるので、R2 の容量に注意してください。
• bootstrap-apply.yml と cilium-drift.yml は差分が小さく、動作に影響する問題は見当たりませんでした。

テスト

• 新しい pv.sh と infisical.sh は、PR 本文にあるとおり引数化した形では未実行です。リハーサルの場所が未定なので、せめて shellcheck と sh -n を CI に足すと、引用符まわりの崩れを早く拾えます。
• 上の 1 と 2 は実機がなくても読めば分かる穴なので、マージ前に直すのがおすすめです。
  | branch: talos-only-cleanup

[claude]

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

---

レビュー結果

先のレビューで挙げた 5 点は、最新コミット(46123a8 流し直しに耐えるようにする)で対処済みでした。現在の recovery/pv.sh と recovery/infisical.sh を読み直して確かめました。スクリプトは読んだだけで、実行はしていません。

前回の指摘の確認

1. pv.sh stop を流し直すと控えが 0 で上書きされる件は直っています。控えがあれば書き直さず(keep_rep)、start が控えを消す流れとも矛盾しません。
2. infisical.sh db を流し直すと old_public で落ちる件は直っています。rename の前に old_public の有無を見て、あれば drop-old を促して止まります。
3. ダンプの流し込みが失敗したまま Infisical を起こす件は直っています。users が 0 なら止めたままにします。|| true は残っていますが、その後の判定があるので問題ありません。
4. port-forward の sleep 3 は、/api/status が通るまで最大 30 秒リトライする形に直っています。
5. pgload で psql が失敗すると、終了コードを返してダンプを残す形に直っています。/var/lib/postgresql/data がマウント先と一致する点は、コメントのとおり apps/{forgejo,rybbit}/postgres.yaml が根拠です。

新たに見つけた問題

不具合、セキュリティ、設計のいずれも、ブロックするものは見つかりませんでした。

• 削除したファイルへの参照は、PR 本文にある bootstrap/argocd/helmchart.yaml のコメントだけが残っています。これは意図どおりで、ROADMAP にも記録されています。
• adguardhome-ssl の PVC は、削除でよいと判断します。
• pv.sh は引数を sh -c に埋め込みますが、運用者が自分で打つ引数なので実害はありません。

テスト(要確認)

pv.sh と infisical.sh は、引数にした形では未実行です(PR 本文にも書かれています)。実機で試せるまでは、次の 2 点を勧めます。

• shellcheck を CI に足す。
• リハーサルの前にマージするなら、次の建て直しで最初に通す対象として README に一言置く。
  | branch: talos-only-cleanup

[claude]

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

---

レビュー結果

先の 2 回のレビューの指摘(pv.sh stop の控え上書き、old_public の残り、空 DB で起こす件、port-forward の待ち、pgload の失敗時)は 46123a8 で直っています。今回は recovery/ の 3 本と bootstrap-apply.yml、etcd-snapshot.yaml を読み直しました。スクリプトは読んだだけで実行していません。

ブロックする問題は見つかりませんでした。

確認したこと

• infisical.sh ca: bun・curl・restic・infisical はどれも tools/Dockerfile に入っています。18080 は実行ごとに新しいコンテナ内のポートなので、ほかと取り合いません。
• infisical.sh drop-old: pg "...$PSQL..." の二重展開はそのまま sh -c で通る形です。
• pv.sh sqlite: restic ls -l の $4 はサイズなので、突き合わせは合っています。
• etcd-snapshot.yaml: 13:00 UTC は 13:30 の matrix の Schedule の手前で、--host etcd の forget も他とロックが衝突しません。
• adguardhome-ssl の削除: 前回までと同じく妥当と見ています。
• 削除したファイルへの参照: PR 本文に書かれた bootstrap/argocd/helmchart.yaml のコメントだけが残っています。

軽微な点(要確認・任意)

1. bootstrap-apply.yml の Namespace 抽出が失敗を握りつぶします。
   • mapfile ... < <(printf ... | xargs -0 grep -lZ '^kind: Namespace$') は、プロセス置換の失敗が set -e に届きません。
   • 該当ファイルが 0 件だと ns= が -f だけになり、次の k apply -f が分かりにくく落ちます。
   • 今は Namespace のファイルがあるので問題になりません。[ ${#NS[@]} -gt 0 ] の確認を足すか、空なら apply を飛ばすと堅くなります。
2. infisical.sh db は kubectl wait --for=delete pod -l ... が失敗すると sleep 20 で済ませます。
   • Pod が既にいない場合は正しい動きです。
   • label 名 app.kubernetes.io/name=infisical-standalone が chart の実際のものと違えば、常に 20 秒待つだけで気づけません。次の建て直しで一度 kubectl get pod --show-labels で見てください(要確認)。
3. pv.sh sqlite で want(restic のサイズ)が空のときは、size mismatch N != で止まるので安全側です。ただ「パスが見つからない」が原因だと分かるメッセージがあると、当日に迷いません。

テスト

pv.sh と infisical.sh は引数化した形では未実行です(PR 本文にも明記あり)。CI に shellcheck を足すのと、README の 8 に「引数化した形はまだ通していない」と一言置くのを、引き続きお勧めします。
| branch: talos-only-cleanup

[claude]

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

---

レビュー結果

前回までの指摘(pv.sh stop の控え上書き、old_public の残り、空 DB で起こす件、port-forward の待ち、pgload の失敗時、Namespace 0 件、sqlite のパス不明メッセージ)は、最新の 9fcc268 までで直っているのを読んで確かめました。スクリプトは読んだだけで、実行はしていません。ブロックする問題はありません。

軽微(任意)

1. recovery/infisical.sh db は restic dump の前に ALTER SCHEMA public RENAME TO old_public を実行します。

   • snapshot ID の誤りや restic の資格情報の不備で dump が失敗すると、set -e で落ちます。そのとき public は空で old_public が残り、Infisical は 0 のままです。
   • 流し直すと old_public の検査で止まり、drop-old を促されます。drop-old は退けた元のデータを消すので、ダンプが取れていないうちに消す手順になります。
   • 先に restic dump を済ませてから rename するほうが安全です。ダンプのサイズが 0 でないことも確認すると、さらに堅くなります。

2. pv.sh sqlite / untar の sh -euc "…$f…$2…" は、ファイル名やパスに空白があると崩れます。 運用者が自分で打つ引数で、今のパスには空白が無いので実害はありません。気になる場合は README に「空白を含まない名前」と一言あれば足ります。

確認したこと

• bootstrap-apply.yml の Namespace 先当ては、0 件なら ::error:: で止まります。
• 削除したファイルへの参照は、PR 本文にある bootstrap/argocd/helmchart.yaml のコメントだけが残っています(ROADMAP に記録あり)。
• adguardhome-ssl の削除は妥当です。ボリューム名として deployment.yaml に残るのは Secret adguard-dot-tls で、PVC への参照はありません。
• セキュリティ面では、トークンは env 経由で表示もしていないため問題ありません。シークレットの混入も見当たりません。

要確認

• infisical.sh db の kubectl wait -l app.kubernetes.io/name=infisical-standalone は、ラベルが chart の実際のものと違うと常に sleep 20 に落ちて気づけません。次の建て直しで kubectl get pod --show-labels で確かめてください。
• talosctl upgrade-k8s --endpoint https://10.10.0.4:6443 は PR 本文のとおり未確認です。

テスト

pv.sh と infisical.sh は引数化した形では未実行です。README の入口にその旨が書かれているので、運用上は十分と考えます。shellcheck を CI に足すと、引用符まわりの崩れを早く拾えます。
| branch: talos-only-cleanup

[claude]

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

---

レビュー結果

最新の fb8a486(ダンプを取れてから public を退ける)を含めて recovery/infisical.sh を読み直しました。スクリプトは読んだだけで、実行していません。

ブロックする問題はありません。前回までの指摘は直っています。

• ダンプを先に取り、空なら止めます(recovery/infisical.sh:21-22)。
• old_public が残っていれば drop-old を促して止まります(:30-31)。
• users が 0 なら Infisical は 0 のままです(:41)。

軽微(任意)

1. ダンプが $HOME/infisical.sql に平文で残ることがあります。
   • 中身は Infisical の DB 全体です。
   • rm -f は :35 で、その前の :31(old_public が残っていた場合)や :32(rename の失敗)で落ちると消えません。
   • 次の db で上書きされるので害は小さいです。
   • 気になるなら trap 'rm -f "$HOME/infisical.sql"' EXIT を足すと、どこで落ちても消えます。
2. kubectl wait -l app.kubernetes.io/name=infisical-standalone のラベルは要確認です。
   • chart の実際のラベルと違うと、常に sleep 20 に落ちて気づけません。
   • 次の建て直しで kubectl get pod --show-labels と突き合わせてください。

残る注意

• pv.sh と infisical.sh は、引数にした形では未実行です。README の入口にその旨があるので、運用上は足りています。
• talosctl upgrade-k8s --endpoint https://10.10.0.4:6443 は未確認です。PR 本文のとおり、次の機会に確かめてください。
• shellcheck を CI に足すと、引用符まわりの崩れを早く拾えます(任意)。
  | branch: talos-only-cleanup

[claude]

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

---

レビュー結果

最新の 6874614(手元のダンプはどこで落ちても消す)を含めて recovery/infisical.sh を読み直しました。スクリプトは読んだだけで、実行していません。

ブロックする問題はありません。前回までの指摘は直っています。

• trap 'rm -f "$HOME/infisical.sql"' EXIT が :22 にあり、:31 や :32 で落ちてもダンプは消えます。
• ダンプが空なら止まり、old_public が残っていれば drop-old を促して止まります(:24, :33)。
• users が 0 なら Infisical は 0 のままです(:43)。

軽微(任意)

1. db の trap が ca の trap と別の分岐にあるだけで、衝突はありません。 case の枝ごとに 1 回しか張らないので問題なしです。
2. kubectl wait -l app.kubernetes.io/name=infisical-standalone のラベルは要確認です。
   • chart の実際のラベルと違うと、常に sleep 20 に落ちて気づけません。
   • 次の建て直しで kubectl get pod --show-labels と突き合わせてください。

残る注意

• pv.sh と infisical.sh は引数にした形では未実行です。README の入口にその旨があるので、運用上は足りています。
• talosctl upgrade-k8s --endpoint https://10.10.0.4:6443 は未確認です。次の機会に確かめてください。
• shellcheck を CI に足すと、引用符まわりの崩れを早く拾えます(任意)。

セキュリティ面(トークンは env 経由で非表示、シークレットの混入なし)と、adguardhome-ssl の削除、消したファイルへの参照(bootstrap/argocd/helmchart.yaml のコメントのみ、ROADMAP に記録済み)は、これまでの確認から変わりありません。
| branch: talos-only-cleanup