Skip to content

リバースプロキシ（URL パスプレフィックス）

https://host/app1/ のように、リバースプロキシの背後でサブパスのもとに Potato を配信します。デプロイ用の URL プレフィックスを設定し、静的アセット・アノテーション操作・ライブストリームがマウントパスのもとで正しく解決されるようにします。

Potato は https://host/app1/ のような URL サブパスのもとで、リバースプロキシの背後で動作できます。 これは複数の内部サーバーが 1 つの公開 HTTPS エンドポイントを共有する場合によく見られます。

text
https://host/app1/  ->  http://127.0.0.1:8000/
https://host/app2/  ->  http://127.0.0.1:8001/

アノテーション UI は、ルート相対 URL（/static/...、/updateinstance、/annotate、/media/...）を介して静的アセットを読み込み、操作を実行します。Potato が /app1 のもとにマウントされると、それらの URL は本来であれば公開ルートに対して解決されてしまい、CSS や JS の 404、インターフェイスの非表示、または「annotations not saved」となる自動保存の失敗として現れます。デプロイプレフィックスは、サイトごとの nginx の小細工なしにこれを解決します。

仕組み

以下の両方のオプションは WSGI の SCRIPT_NAME を設定します。Potato はこれを、サーバーレンダリングされる url_for(...) の出力、およびブラウザに window.config.url_prefix として公開されるクライアント側プレフィックスのための唯一の信頼できる情報源として読み取ります。このプレフィックスは fetch()、sendBeacon()、EventSource、およびルート相対の href/action/src 属性をラップします。プレフィックスが設定されていない場合、SCRIPT_NAME は空で何も変わらないため、通常の potato start の実行ではこれは何の動作も行いません。

オプション A — POTATO_PROXY_FIX（プロキシが転送ヘッダーを送信する）

プロキシを自分で制御していて、転送ヘッダーを送信できる場合にこれを使用します。Potato は Werkzeug の ProxyFix を有効にし、これがリクエストごとに X-Forwarded-Prefix（および -Proto/-Host/-For）を読み取ります。

bash
export POTATO_PROXY_FIX=1
potato start config.yaml -p 8000

nginx、プレフィックスを取り除いてヘッダーとして転送します。

nginx
location /app1/ {
    proxy_pass         http://127.0.0.1:8000/;   # trailing slash strips /app1/
    proxy_set_header   Host              $host;
    proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   X-Forwarded-Prefix /app1;
}

ProxyFix は転送ヘッダーを信頼します。POTATO_PROXY_FIX は、アプリが信頼されたプロキシ経由でのみ到達可能な場合にのみ有効にしてください。内部ポートにも直接到達できる場合、クライアントが X-Forwarded-Prefix や -Host を偽装し、生成される URL を汚染するおそれがあります。

オプション B — POTATO_URL_PREFIX（プロキシ設定を変更できない）

転送ヘッダーを追加できないが、公開マウントパスが分かっている場合にこれを使用します。Potato はプレフィックスを自ら SCRIPT_NAME に注入します。

bash
export POTATO_URL_PREFIX=/app1
potato start config.yaml -p 8000

それでもプロキシは転送前にプレフィックスを取り除く必要があり、Flask が /static/styles.css のようなプレフィックスのないパスを受け取れるようにします。

nginx
location /app1/ {
    proxy_pass       http://127.0.0.1:8000/;     # trailing slash strips /app1/
    proxy_set_header Host $host;
}

両方の変数が設定されている場合、リクエストごとの転送プレフィックスが優先され、POTATO_URL_PREFIX はフォールバックとなります。

ライブストリーミング（Server-Sent Events）

ライブエージェントおよびライブコーディングのビューアは SSE を使用します。URL プレフィックスは自動的に適用されますが、SSE ではさらに、プロキシがストリームのロケーションでバッファリングを無効にする必要があります。さもないとイベントが保留されます。

nginx
location /app1/api/ {
    proxy_pass            http://127.0.0.1:8000/api/;
    proxy_set_header      Host $host;
    proxy_buffering       off;
    proxy_read_timeout    3600s;
}

検証

  1. https://host/app1/ を読み込み、CSS と JS が 404 なしで読み込まれることを確認します。
  2. アノテーションを行い、自動保存されることを確認します。
  3. 「次へ／前へ」を操作し、メディアとデータがレンダリングされることを確認します。
  4. ライブエージェント評価を使用している場合は、ストリームが接続され更新されることを確認します。

注意事項と制限

  • 表示されるアノテーションコンテンツ内のルート相対リンクにもプレフィックスが付きます。公開ルートを指し示すつもりのコンテンツ作成者は、絶対 URL を使用すべきです。
  • pip でインストールしたデプロイは、パッケージ化された静的アセットに依存します。ビルドにネストされた static/ ディレクトリが含まれていることを確認してください。

関連項目

実装の詳細については、ソースドキュメントを参照してください。