talos: 当てたあとのズレを見る drift.sh

[5ym]

Talos では CNI も storage も machine config の inlineManifests に載るので、ズレは git とノードの間で起きる(apply を打ち忘れる / 実機で patch して git に戻し忘れる)。

git から作ったものとノードが持っているものを並べて diff を出すだけの道具を足す。当てはしない(適用は再起動を伴うことがあり、Talos API は mTLS だけなので CI には渡さない — talos-validate と同じ線)。鍵と証明書は両方から落としてから比べる。

移行後にホストから手で回す、または cron に置く想定。一致 0 / ズレ 1。

🤖 Generated with Claude Code

https://claude.ai/code/session_01JgGYf5qbjDXYhtzcpLsGvv

[claude]

Claude finished @5ym's task in 2m 45s —— View job

---

レビュー結果

• コンテキスト収集 (CLAUDE.md / README / 差分)
• drift.sh のロジックレビュー
• README 更新内容の確認
• レビューコメント投稿

全体的な所感

設計方針(検出は自動・適用は手動、鍵/証明書は両側から落として比較、単一ノード構成なので controlplane.yaml のみ比較)は render.sh や talos-validate.yml の既存方針と一貫しており、コメントも丁寧です。set -eu + trap での一時ディレクトリ後始末、command -v によるツール存在チェックなど、リポジトリの他スクリプトの作法にも沿っています。

1点だけ 要確認 としてインラインコメントを付けました:

• talos/drift.sh (27〜35行目付近) — render.sh は「サーバに入っている yq が v3 で構文が違う」という理由でわざわざ yq を避けて awk を使っています。一方 drift.sh は yq -e '.spec' や yq -P '... | del(...) | sort_keys(..)' という yq v4 系限定の構文に依存しています。README の想定では同じホストから手動 / cron で回すことになっており、そのホストの yq が本当に v4 になっているか確認が必要です(v3 のままだと command -v yq のチェックは通っても実行時に構文エラーで落ちます)。

それ以外の不具合・セキュリティ上の懸念は見当たりませんでした。テストについては、drift.sh は方針上 CI に組み込まない(mTLS のみで CI に鍵を渡さないため)ので、自動テストが無いこと自体は他のスクリプトとの一貫性から妥当と判断しました。

[claude]

要確認: render.sh は ver()/hc() で yq をあえて使わず awk で読んでいます。理由として明記されているのは「サーバに入っているのが v3 で構文が違う」( talos/render.sh:65, talos/render.sh:119 )。

一方この drift.sh は yq -e '.spec'・yq -P '... | del(...) | sort_keys(..)' という mikefarah yq v4 系限定の構文に依存しています(v3 は yq r file.yaml spec のようなサブコマンド形式で、これらのパイプ式は通りません)。

drift.sh は README により「ホストから手で回す、または cron に置く」想定 ── つまり render.sh を手で回すのと同じホストで動かされる可能性が高いです。もし本当にそのホストの yq が v3 のままなら、command -v yq のチェックは通っても実行時に構文エラーで落ちます。

• 実際にこのスクリプトを回すホストの yq バージョンを確認しているか
• 確認済みなら、render.sh 側のコメントとの食い違いに見えるので一言補足があると親切

Fix this →

[5ym]

レビューありがとうございます。指摘のとおりでした — ホスト(main)の yq は 3.4.3(jq 構文)で、書いていた v4 の式は動きません。

render.sh が awk で組んでいるのと同じ理由なので、yq をやめて python3 + PyYAML(どちらもホストにあります: python3 3.14 / PyYAML 6.0.3)で読むようにしました。

• 器(talosctl get machineconfig の .spec)と素の machine config の両方を受ける。版によって .spec が YAML 文字列で返ることがあるのでそれも処理
• 落とす鍵は DROP に並べ、machine.registries.config.*.auth のようなワイルドカードも 1 つの仕組みで扱う
• 手元で、器あり / 素の両方を食わせて同じ正規化結果になることを確認済み

[claude]

Claude finished @5ym's task in 2m 28s —— View job

---

レビュー結果

• コンテキスト収集 (README / render.sh / 差分)
• 前回指摘 (yq v3/v4) への対応確認
• drift.sh のロジックレビュー (python3+PyYAML 版)
• レビューコメント投稿

前回指摘の解消

前回の「drift.sh が yq v4 限定構文に依存しており、render.sh が『サーバの yq は v3』という理由で awk を使っているのと矛盾する」という指摘は、今回のコミット(yq をやめて python3 + PyYAML で読む)で解消されています。

• yq への依存を完全に排し、python3 -c 'import yaml' で PyYAML の有無まで実行前にチェックしている(talos/drift.sh:20-22)のは、単に command -v だけ見ていた旧実装より堅い作りです。
• スクリプト冒頭のコメント(talos/drift.sh:17-19)で「python3 + PyYAML はどちらもサーバにある」と明記されており、render.sh が awk を使う理由と地続きの説明になっています。

1点だけ要確認(ブロッカーではありません): このコメントの「サーバにある」は実機で確認済みという理解でよいでしょうか。もし未確認なら、command -v python3 のチェックは通っても import yaml の方が実行時に無くて exit 2 で気づける作りにはなっているので、実害は小さいです。

ロジックレビュー (talos/drift.sh 本体)

• norm.py の drop() はワイルドカード ("*") を含むパスも正しく再帰的に辿れており、machine.registries.config.*.auth のような可変キー配下の削除も問題なく動作します。
• machine_config() は「素の machine config」と「talosctl get machineconfig -o yaml の資源の器 (spec が文字列/オブジェクトどちらもありうる)」の両方に対応していて、git 側・ノード側で同じ正規化関数を通せる設計になっています。
• sort_keys=True での yaml.safe_dump により diff が決定的になっており、意図(鍵/証明書と資源メタデータだけを落として設定差分だけを見る)通りです。
• 鍵・証明書・トークン類 (machine.token/ca/certSANs、cluster.secret/token/ca/aggregatorCA/serviceAccount/secretboxEncryptionSecret/etcd.ca など) を両側から落としてから比較しており、diff 出力に秘密が残らない設計は妥当です。
• 一時ファイルは mktemp -d + trap ... EXIT INT TERM で後始末されており、render.sh の作法と一貫しています。

その他、不具合・セキュリティ上の懸念は見当たりませんでした。テストについては、方針上 CI に組み込めない(Talos API が mTLS のみで CI に鍵を渡さない)理由が README・スクリプトのコメント双方に明記されており、自動テストが無いこと自体は妥当と判断します。

[5ym]

「サーバにある」は実機で確認済みです(2026-09-16、ホスト main):

/usr/bin/yq  → yq 3.4.3   ← これが理由で使わない
/usr/bin/python3, /usr/bin/jq
python3 -c 'import yaml' → pyyaml 6.0.3