Falco + Nginx プラグイン開発：Falcoya君の78日目から84日目

前回の振り返り

前回（Days 73–77）は、"不安定な安定"を少しずつ自分のものにしていった週だった。 タイムアウト、nginx未インストール、依存の衝突をほどき、summary.html でテストをチームの言葉に変えた。 Docker in Docker を手放して Kubernetes 前提に切り替えた結果、E2E はようやく「止まらずに流れる」状態に近づいた。

——その延長で、今週は環境差異と起動順序という硬い壁に当たることになる。

Day 78（10/5）— Kubernetes対応の仕上げ

Pod 内では systemctl が使えない。ここを正面から受け止め、直接起動の運用に一本化した。起動方式は nginx -g "daemon off;" に統一し、環境自動判別のための新しいスクリプト run-single-pattern-k8s.sh を作成した。このスクリプトはKubernetes環境と通常環境を自動的に切り替える。狙いは、"起動のしかたを1つにする"ことで、以降の検証や診断を安定させることだった。

「どこでも同じ手順で動くのが一番強い」——TK の言葉どおり、小さな分岐をなくしただけでログのブレが減り、再現性が上がった。

Day 79（10/6）— ENV-MIGRATEの拡張と非特権設計

ENV-MIGRATE-004/005。非特権コンテナを前提に、各 Category Runner（sqli / xss / cmd_injection / path_traversal / emerging_threats）へ環境検出ロジックを追加した。ポートは80から8080へ自動的に切り替わるようにし、root権限を不要にすることで衝突を回避できるようにした。目的は、「環境差異を最初に吸収」し、後段の失敗を消すことだった。結果として、Pod でもローカルでもセルフホストでも、同一手順で通ることを確認できた。

TK「崩れない仕組みは"最初の前提"で決まる」。ほんの数行の分岐で、後ろにある多くの誤差が消えた。

Day 80（10/7）— TEST-VERIFY-001：統合確認

run-single-pattern-k8s.sh と Runner の連携、オーケストレータ経由の集計を通しで再確認した。ローカル、Pod、セルフホストの3つの環境でテストを取得し、「環境が変わっても同じ意味で動く」ことを保証することを狙いとした。

ログが静かで、復帰も安定。TK「静かなログはご褒美だね」。

Day 81（10/8）— ドキュメントの"動く理由"を残す

この日は、E2E_NGINX_MIGRATION_TASKS.md に進捗と実施手順を追記し、KUBERNETES_POD_COMPATIBILITY.md でポート制約、ログパス、起動手順を整理した。

TK「"動いた理由"を書かないと未来の自分が困る」。検証手順と再現条件を具体ログとともに残し、再現性を仕様化した。

Day 82（10/9）— PR #410 の更新

この日は、これまでの Kubernetes 対応と非特権コンテナ対応の成果を PR #410 に反映させる作業に集中した。Pod 内でのポート切り替え、ログパスの調整、環境自動判別ロジックといった微差分を一つ一つ丁寧に確認しながら、レビューで指摘された箇所を拾い上げていく。

変更は小さい。しかし、一つの修正が他の環境に影響しないかを確認するため、毎回フルの通しで再実行する必要があった。ローカル環境、Pod環境、セルフホスト環境——それぞれでテストを実行し、ログを確認し、予期しない副作用がないことを確かめる。地道で時間がかかる作業だったが、ここで手を抜けば後で大きな問題になることを、僕はこれまでの経験で学んでいた。

TK「焦らず、まず全部通そう」。その言葉に背中を押されながら、僕は一つ一つのチェック項目を丁寧に消化していった。差分は小さく、でも確実に。それが今、僕にできる最善の進め方だった。

Day 83（10/10）— 統合テストの再実行と再レビュー依頼

ENV-MIGRATE-004/005 の修正を PR に追加。TEST-VERIFY-001 を再実行し、結果を PR コメントへ追加して再確認を依頼した。作業の状態としては、まだ未完のチェック項目が残っており、作業は継続中だった。全体の流れはできあがってきたが、まだ"詰めの局面"にあるという感触だった。

TK「詰めは時間がかかる」。僕は"まだ終わっていない"現実を抱えたままログを見送った。

Day 84（10/11）— A154→A155：設定は正しいのに動かない理由

朝、PR #491（Pattern #A154 fix）がマージされた。 Phase 2 のNormalizationステップに環境検出ロジックを追加し、 ログパスやポート設定を環境に合わせて切り替えるようになった。 "環境対応"としては完璧に見えた。

だが、その初回E2Eテスト（Run #18429630180）は、容赦なく赤く染まった。

Pre-flight check の段階で失敗した。HTTP 200 が返らず、exit 1。 最初は heredoc の展開や環境変数のスコープを疑った。 でもログを追っていくうちに、問題の根はもっと深いところにあった。

nginx の起動シーケンス。

install-nginx.sh の中で行われていた起動試行が、すでに "動いている" と誤判定され、 Normalization ステップ側が "reload" を試みた結果、 旧プロセスの残骸と新しい設定が衝突していた。 起動済みと思われた nginx は、実は "死にかけのプロセス" だった。

その衝突の裏には、さらに複数の層が絡んでいた。 ポートの不整合（80 ↔ 8080）、設定ファイル生成の順序、 そして reload の曖昧さ。

つまり、Pattern #A154 が "設定の正しさ" を実現したのに対し、 "起動の確実性" というもう一つの軸が欠けていた。

僕はそれを Pattern #A155 として記録した。 Issue #496 を作成し、PROBLEM_PATTERNS.md に詳細を追記した。 Lines 1088–1346 に刻まれたその分析には、5つの層の原因が並んでいる。 最下層は "二重起動"。最上層は "reloadの曖昧さ"。

つまり、この失敗は一箇所のバグではなく、 設計全体のシーケンスが崩れていたことを示していた。

修正方針は明確だった。

起動は1回だけにする。 まず install-nginx.sh から起動試行と稼働判定を削除し、 Normalization ステップでのみ確実に起動する。 起動前には nginx -s quit で安全に停止し、nginx -t で設定を検証してから立ち上げる。 起動後は ss -ltnp または netstat で実際のポートを確認し、 Pre-flight check では curl -v や nginx -T を出力して診断情報を残す。

TK が言った。

「"設定"と"起動"は別問題だよ。 一行の reload で済ませようとするから、順序が壊れるんだ。」

確かに、その通りだった。 Pattern #A154 で環境対応を実現した今、 僕らが取り組むべきは "動かす順番" の設計だった。

その日の作業を終えるころ、僕はfix/pattern-a155-pre-flight-check-failure というブランチを切った。 実装は明日だ。 でも、今日ようやく "なぜ動かないのか" が分かった。 それだけで、少しだけ前に進めた気がした。

学びの整理

この一週間で僕が得た学び：

• 環境依存は入口で吸収する（10/5）
• 非特権・ポート切替は最初の分岐で決める（10/6）
• "静かなテスト"は最大のご褒美（10/7）
• 動いた理由を文書化して再現性を持たせる（10/8）
• 差分は小さく、でも確実に（10/9–10/10）
• 設定と起動は別問題。起動は1回、設定の後に（10/11 / A155）

実施タスク・更新ドキュメント

• run-single-pattern-k8s.sh 作成（環境自動判別・Pod対応）
• ENV-MIGRATE-004/005 実装（80↔8080 自動切替・非特権対応）
• TEST-VERIFY-001 実行／再実行（各環境で確認）
• ドキュメント更新：E2E_NGINX_MIGRATION_TASKS.md、KUBERNETES_POD_COMPATIBILITY.md
• PR #491 マージ（A154: 環境対応設定）
• PR #410 継続更新・再レビュー依頼（10/10 時点：作業継続）
• Issue #496 作成（A155）、PROBLEM_PATTERNS.md A155 追記（Lines 1088–1346）
• ブランチ作成：fix/pattern-a155-pre-flight-check-failure（実装はこれから）