bridge の運用

bridge とその背後のリングを運用するためのオペレーターノート：プランをロードし、再起動を生き延び、貢献を流し続け、そしてエンジンをインターネットから遠ざける。

ゲートウェイ（公開エントリポイント）と bridge（エンジンの顔）は、オペレーターが健全に保つ 2 つの長寿命サービスであり、その背後に p4 エージェントとステージサーバーが並びます。エンジンは認証をまったく話しません — 互いに到達できるマシンどうしは、そうあるべくして到達できるのだと前提しています — だからこそ公開されるものはすべてゲートウェイに集約され、bridge は公開せずトンネル越しに到達します。

• 配置は依頼するものではなく、書くプランです：提供を依頼してきた相手に bridge は 409 を返します。プランを生成し、ドライランし、それから --confirm でロードします。
• load generation は最初のコマンドを送る前にディスクへ書き出します。これはロードする者が選ぶ番号で、セッションごとにもアンロード時にも完全一致で検査され、マシン上のどこにも記録されません — 失えばロード済みモデルは撤去することすらできません。
• ノードの generation も同じ番号です。異なる 2 つの番号でリングをロードすると、ちょうど 1 リクエストを提供したところで先頭が止まり、次のセッションは半ロードのままハングします。ロードごとに新しい値を使ってください。さもないと失敗した試行が残した登録と衝突します。
• エージェントは運用ジャーナルなしではロードを拒否します。これはリプレイ安全なロードに必要な受理記録であって、デバッグフラグではありません。

• エージェントの再起動はそのノードを落とします。ステージサーバーはランタイム限りなので、モデルはプランからロードし直す必要があります。それは障害ではなく復旧手順です。
• ゲートウェイが代わりにリロードしてくれることはありません。リングウォッチドッグは提供の止まったモデルに気づき、bridge の 409 から配置が外部にあることを学び、一度そう言ってから問い合わせをやめます。
• 貢献カウンタは bridge のメモリ上にあります。ゲートウェイは 30 秒ごとにポーリングしてデルタ記帳するため、再起動で失われるのはまだポーリングされていない分だけであり、カウンタが巻き戻ったときゲートウェイは二重払いせず再ベースライン化します。

• bridge はループバックにバインドし、サービストークンを与えてください。トークンがなければ誰も認証されず、そこに到達できるものは何でもリングを無償で動かせます — bridge は起動時にそう言います。あとから気づくことにはなりません。
• エージェントは他のエージェントがダイヤルするアドレスを広告します。ホストが共有する最速のネットワークを使い、ホスト間でループバックを使わず、そのネットワークを公開インターネットから隔離してください。
• どうしても公開 IP に置くものがある場合、Docker の公開ポートは INPUT チェーンの前に DNAT されるため、dport のルールはマッチしないことを思い出してください。DOCKER-USER チェーンで conntrack の元の宛先ポート（--ctorigdstport）を使ってフィルタし、After=docker.service を指定した systemd oneshot で永続化します。

• オペレーターウォレット未設定は、稼ぎゼロに見えます。ゲートウェイは所有者のない貢献行をスキップし、何もログに残しません。ノードは提供しているのに遊んでいるように見えます。
• `pkill` は自分自身のコマンドラインにマッチします。 ssh host 'pkill -f server.js; ...' はそれを走らせているシェルを殺します。パターンはリモートコマンドではなくスクリプトファイルに置き、文字クラス（server[.]js）を使ってください。また、素の node server.js として起動したプロセスにはマッチすべきパスがないため、その場合は待ち受けポートから見つけます。