Secure Gateway

Secure Gateway は Roboflow Deployment サーバーに必要なルートを会社の DMZ にプロキシし、モデル重みとコンテナイメージをローカルにキャッシュします。

Secure Gateway は、Roboflow Inference Server をインターネットからファイアウォールで遮断する際に、Roboflow API とモデルの重みへのプロキシです。これは〜の後継ですライセンスサーバーさらに、モデルの重みとコンテナイメージのローカルキャッシュを追加し、推論サーバーの群が 1 つの管理された送信経路を共有できるようにします。

このページでは基本事項を扱います。完全な設定と運用のリファレンスについては、 Secure Gateway マニュアル.

前提条件

Docker Engine 20.10 以上、または Kubernetes v1.24 以上
api.roboflow.com と repo.roboflow.com にアクセスできるホスト
ポート 80 が利用可能で、TLS はゲートウェイの前にあるロードバランサーまたはコンテナ内で終端されます
4GB 以上のメモリ
キャッシュ用の S3 バケット、または 50GB 以上のローカルディスク

Red Hat Enterprise Linux にデプロイしますか？ Podman を使用した RHEL 上の Secure Gateway Docker や Kubernetes のない RHEL ホストを対象としており、 MicroShift 上の Secure Gateway MicroShift を実行している Red Hat Device Edge ホストを対象としています。どちらも同じエアギャップ対応バンドルモデルを使用する専用インストーラーを使います。

Secure Gateway の使用

〜にアクセスできるマシン上で https://api.roboflow.com と https://repo.roboflow.com、Secure Gateway コンテナを pull します:

docker pull repo.roboflow.com/roboflow-edge/secure-gateway:latest

この latest タグは最新リリースを追跡します。本番環境、特にエアギャップ環境では、代わりに特定のバージョンを固定して、アップグレードが意図的かつ再現可能になるようにしてください。たとえば repo.roboflow.com/roboflow-edge/secure-gateway:0.2.0.

ローカルテスト用のローカルディスクキャッシュとループバック専用の HTTP リスナー、または同じホスト上の TLS プロキシで実行します:

docker run -d --name secure-gateway -p 127.0.0.1:80:80 --restart unless-stopped \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest

実行されていることを確認します:

curl http://localhost/health

ローカルディスクの代わりに S3 にキャッシュするには、 CACHE_S3_BUCKET と CACHE_S3_REGION 環境変数を設定します。インスタンスまたは IAM ロールを使用する場合は、認証情報を未設定のままにしてください。

TLS 証明書

デフォルトでは、ゲートウェイは通常の HTTP で待ち受けし、その前段のロードバランサーで TLS を終端します。ゲートウェイ自体から HTTPS を提供するには、証明書と秘密鍵をコンテナにマウントし、両方を TLS_CERT_FILE と TLS_KEY_FILE。するとゲートウェイは設定されたポートで HTTPS を提供します:

docker run -d --name secure-gateway -p 443:443 --restart unless-stopped \
    -e PORT=443 \
    -e TLS_CERT_FILE=/etc/ssl/certs/gateway.crt \
    -e TLS_KEY_FILE=/etc/ssl/private/gateway.key \
    -v /path/to/certs:/etc/ssl:ro \
    -v gateway-cache:/var/cache/secure-gateway \
    repo.roboflow.com/roboflow-edge/secure-gateway:latest

両方 TLS_CERT_FILE と TLS_KEY_FILE は受信 HTTPS を有効にするために必要で、それぞれ PEM エンコードされたファイルを指します。

ゲートウェイの送信トラフィックが Zscaler などの社内 TLS 検査プロキシを通過する場合は、 TLS_CA_BUNDLE をそのプロキシの CA バンドルに設定して、ゲートウェイが api.roboflow.com と repo.roboflow.com への接続を信頼するようにします:

-e TLS_CA_BUNDLE=/etc/ssl/certs/corporate-ca.pem

推論サーバーの接続

各 Inference Server を、ゲートウェイの HTTPS リスナーまたは TLS プロキシへ、明示的な SECURE_GATEWAY URL で向けてください。サーバーは Roboflow API 呼び出しとモデルのダウンロードをそのアドレス経由でルーティングします。

sudo docker run --rm -p 127.0.0.1:9001:9001 \
    --env SECURE_GATEWAY=https://gateway.example.com \
    roboflow/roboflow-inference-server-cpu:latest

443 と異なる場合はポートを含めます。たとえば https://gateway.example.com:8443。証明書は URL 内のホスト名または IP をカバーしている必要があり、Inference Server コンテナは発行 CA を信頼していなければなりません。ゲートウェイの送信 TLS_CA_BUNDLE を設定しても、クライアントに信頼はインストールされません。

次を使用してください Podman を使う RHEL または MicroShift それらのデプロイメントを使用する場合のクライアントのインストール手順。

従来のアドレスとローカルトンネル

バージョンをまたいで明示的な HTTPS スキームを使用してください。予定されているランタイム強化ビルドでは、素のアドレスは HTTP から HTTPS に切り替わり、平文のリモートまたは LAN ゲートウェイは拒否されます。移行範囲.

そのビルドは、明示的な HTTP をループバック IP または localhostのような SECURE_GATEWAY=http://127.0.0.1:8080。トンネルは Inference Server 自身のネットワーク名前空間から到達可能でなければなりません。ブリッジコンテナのループバックは、そのホストのループバックではありません。

api.roboflow.com と repo.roboflow.com への送信アクセスが必要なのはゲートウェイのみです。Inference Server を起動した後、モデルを実行して、要求がゲートウェイのアクセスログに表示されることを確認してください。

従来の LICENSE_SERVER 変数は、 SECURE_GATEWAYのエイリアスとして引き続き受け入れられます。 SECURE_GATEWAY 新しい設定では

キャッシュ

Secure Gateway は、コンテンツの更新頻度に応じて階層化し、最初のダウンロード時に各レスポンスをキャッシュします。コンテンツアドレス指定のコンテナ blob とモデルの重みは最も長く保持され、変更可能な API レスポンスはより短い期間保持されます。後続のリクエストはどの Inference Server からでもキャッシュから提供されるため、帯域幅の使用量とフリート全体でのコールドスタートが削減されます。

前へPodman を使う RHEL 上の Secure Gateway

次へストリーム管理 API

最終更新 28 日前

役に立ちましたか？