Rybbit(rb.doany.io): アクセス解析を apps/rybbit に足す

[5ym]

トドロクの LP から購入までのどこで離脱するかを、ファネル・ユーザージャーニー・セッションリプレイで見るために Rybbit を置く。クッキー無しなので同意バナーは要らない。AGPL-3.0。Talos 移行の前に入れる(店主の判断)。

• 上流の docker-compose.yml をそのまま k8s に写した: backend / client v2.9.0(GitHub の最新リリース。ghcr のタグは v 付き)、ClickHouse 26.3(上流の設定 4 本を ConfigMap に。メモリの上限だけこの箱向けに limit 3 Gi・1 クエリ 2 GB・4 スレッド)、PostgreSQL 17(forgejo と同じ形、pg_dump を k8up に)、Redis(セッションのカウンタだけなので emptyDir)
• 秘密は Infisical /rybbit/rybbit の 4 キー(clickhouse-password / postgres-password / redis-password / better-auth-secret)。mattermost と同じ InfisicalSecret。値は店主が UI で入れる(入るまで Pod は CreateContainerConfigError で待つ)
• HTTPRoute rb.doany.io: 上流の Caddyfile と同じ振り分け(/api と /.well-known/oauth-* / openid-configuration は backend、ほかは client)。DNS はワイルドカードで既に引ける
• k8up の Schedule rybbit(14:30 UTC、prune 日曜 23:45)。ClickHouse の PVC はファイルとして、PostgreSQL は pg_dump
• PSA は baseline(hostPort も特権も無い。Talos でもそのまま)
• 使い始め(Infisical の値 → 最初のアカウント → DISABLE_SIGNUP を true にする PR → サイト ID をトドロクへ)は apps/rybbit/README.md

確認: kubectl apply --dry-run=client --validate=strict が通る。ノードは 48 GB でメモリの割当は 10% なので余裕あり。

🤖 Generated with Claude Code

https://claude.ai/code/session_01JgGYf5qbjDXYhtzcpLsGvv

[claude]

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

---

レビュー完了

タスクリスト

• コンテキスト収集（README / 既存アプリ(mattermost・forgejo・netbird)との比較）
• 変更ファイルの確認 (rybbit.yaml, clickhouse.yaml, postgres.yaml, redis.yaml, httproute.yaml, rybbit-secrets.yaml, namespace.yaml, README.md, k8up/schedules.yaml)
• 不具合・境界値の確認
• セキュリティ・シークレット取り扱いの確認
• 設計一貫性（既存 apps との比較）
• テスト・検証観点の確認
• レビュー結果をまとめて投稿

所感

全体として上流の docker-compose.yml を丁寧に写し取っており、既存アプリ（mattermost / forgejo）の慣習（Infisical の形、postgres の pg_dump、PSA baseline 等）にもよく揃っています。1 点、実際の挙動に影響しそうな指摘をインラインで付けました。

要確認・修正候補

• apps/rybbit/httproute.yaml (20–22行目): PathPrefix は Gateway API 仕様上「パス要素単位」のマッチで、単純な文字列前方一致ではありません(/abc は /abc/def にマッチするが /abcd にはマッチしないのと同じ理屈)。value: /.well-known/oauth- は末尾がパス区切りで終わっていないため、実際のパス /.well-known/oauth-authorization-server にはマッチせず、意図せず client 側(Next.js)にルーティングされてしまう可能性があります。上流の Caddyfile の path マッチャー(前方一致 glob)をそのまま Gateway API の PathPrefix に置き換えたことで意味が変わってしまったと見えます。type: Exact でフルパスを列挙する形に直すのが安全です。詳細と根拠はインラインコメント参照。better-auth が実際に生成する .well-known パスの種類（oauth-authorization-server 以外にもあるか)は要確認です。

その他、問題は見当たりませんでした

• Redis の --requirepass "$REDIS_PASSWORD" はコマンドライン引数に渡るため ps//proc から見える点は気になりますが、PSA baseline・単一運用者のクラスタという前提では許容範囲と判断し、ブロッキングな指摘にはしていません（要確認程度）。
• Secret の取り扱い(Infisical 経由、secretKeyRef のみ、平文の値はコミットされていない)、k8up の Schedule 時刻の重複回避、ClickHouse のメモリ比率設定、PostgreSQL の pg_dump 設定などは既存アプリと一貫しており妥当です。
• README・トップレベル README・k8up README の更新内容も実際のファイル構成と整合しています。
  / ブランチ: rybbit

[claude]

Gateway API の PathPrefix は文字列の前方一致ではなく、/ で区切ったパス要素単位でのマッチです(spec より: Matches based on a URL path prefix split by /... For example, the paths /abc, /abc/, and /abc/def would all match the prefix /abc, but the path /abcd would not.)。

value: /.well-known/oauth- は要素が ["", ".well-known", "oauth-"] となるため、実際のパス /.well-known/oauth-authorization-server (要素 ["", ".well-known", "oauth-authorization-server"]) は /abc vs /abcd と同じ理由でマッチしません。この rule は意図した OAuth discovery エンドポイントに一致せず、backend ではなく次の matches(/ → client)に流れてしまいます。

type: Exact で実際のフルパス(/.well-known/oauth-authorization-server など、better-auth が実際に生成するパス)を列挙するか、末尾が / で終わる境界に合わせる必要があります。上流の Caddyfile の path マッチャーは glob 的な前方一致なので、そのまま Gateway API の PathPrefix に置き換えると意味が変わってしまう点に注意。

要確認: better-auth の OIDC プラグインが実際にどの .well-known パスを生成しているか(oauth-authorization-server だけか、oauth-protected-resource なども)によって、必要な Exact ルールの数が変わります。

[claude]

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

---

レビュー完了

タスクリスト

• コンテキスト収集(前回レビュー・既存 apps との比較)
• 変更ファイルの再確認(前回指摘の httproute.yaml PathPrefix の扱いを含む)
• 不具合・境界値の確認
• セキュリティ・シークレット取り扱いの確認
• 設計一貫性の確認
• レビュー結果をまとめて投稿

所感

追加コミット 034f260(レビュー対応)を確認しました。前回指摘した「Gateway API の PathPrefix はパス要素単位のマッチであり、/.well-known/oauth- のような途中までの前方一致は書けない」という問題は、Exact で個別パスを列挙するのではなく、そもそも MCP を使わないので該当ルールごと削除するという形で解決されています(apps/rybbit/httproute.yaml 20–25行目)。

• 対応方針は妥当です。MCP クライアント向けの OAuth discovery エンドポイント(/.well-known/oauth-*, /.well-known/openid-configuration)は Rybbit の MCP 機能を使わない限り不要なので、無理に Exact でフルパスを列挙するより「置かない」方がシンプルで、将来 better-auth 側のパス構成が変わってもここが壊れる心配がありません。
• コメント(2–5行目)に、なぜ置かないか・Gateway API の PathPrefix の挙動の注記まで残っており、今後同種の変更をする人への説明として十分です。
• README.md(16行目)の説明も新しい振り分けと整合しています。
• 他に .well-known への参照が残っていないことも確認済みです。

その他、新規の問題は見当たりませんでした。 前回レビュー時に指摘済みだったその他の点(Redis の --requirepass がコマンドライン引数に出る点など)は今回のコミットでは変更されておらず、ブロッキングではないという前回の評価のままです。
/ ブランチ: rybbit