Podman を使う RHEL 上の Secure Gateway
Kubernetes を使わずに Red Hat Enterprise Linux ホスト上へ Secure Gateway をデプロイし、ゲートウェイとその暗号化キャッシュを Roboflow Deployment Manager が管理する Podman コンテナとして実行します。
セキュアゲートウェイ Docker も Kubernetes もない Red Hat Enterprise Linux ホストでも動作します。専用インストーラーがゲートウェイとその暗号化キャッシュを Podman コンテナとして配置し、Roboflow Deployment Manager（rfdm）が Podman を Docker 互換 API で制御します。Docker デプロイと同じゲートウェイ（Roboflow API をプロキシし、フリート向けにモデル重みとコンテナイメージをキャッシュする、制御された単一の送信出口）を、RHEL に付属するコンテナランタイム上で、同じエアギャップ対応バンドルモデルで利用できます。
アーキテクチャ
Roboflow Deployment Manager はホスト上で systemd サービスとして動作し、Podman の Docker 互換 API（
podman.socket）を通じてコンテナを管理します。構成を維持し、更新し、稼働させ続けます。ゲートウェイとそのキャッシュバックエンド（SeaweedFS、保存時暗号化対応の S3 互換ストア）は、システム（root）Podman インスタンスの下でコンテナとして実行されます。
ゲートウェイはポートを公開します
80および443ホスト上に直接公開します: HTTPS は443、HTTP は80HTTPS にリダイレクトされます。キャッシュは
/data/seaweedfsにホストのファイルシステム上で保存され、キャッシュコンテナに bind マウントされます。LVM ボリュームグループやストレージプロビジョナーは不要です。SELinux は enforcing のままです。管理されたコンテナ設定のボリュームマウントには SELinux ラベル（
:Z/z）が付くため、手動での再ラベル付けも permissive モードも不要です。
これは単一ホストのデプロイです。高可用性やマルチホストクラスターはサポートされません。
ゲートウェイには専用ホストを使用してください。Podman と CRI-O（MicroShift が使用するランタイム）はホストのコンテナストレージを共有するため、一方でのイメージクリーンアップ（例: podman image prune）では、もう一方のランタイムがキャッシュしたイメージが削除されることがあります。ホストで MicroShift が動作している場合は、代わりに MicroShift デプロイ を使用してください。
前提条件
x86_64 上の Red Hat Enterprise Linux 9.x ホストで、Podman 4.x 以降が必要です。インストーラーバンドルは
linux-amd64専用です。Podman は追加サブスクリプションなしで RHEL リポジトリから提供されますが、最小インストールには含まれていない場合があります。次を実行してください:sudo dnf install podmanをまずpodman --versionが失敗する場合は。以下を参照してください。 サポートマトリクス.ルート権限: ゲートウェイはシステム（root）Podman インスタンスの下にインストールされます
ディスク: 約 3 GB を
/コンテナイメージ用に、さらにキャッシュ用の空き領域が/dataに必要で、最大 50 GB まで増加しますポート
80および443ホスト上でゲートウェイに使用可能接続されたインストールでは、外向き HTTPS は
api.roboflow.comおよびrepo.roboflow.com
接続済みホストにインストールする
Podman インストーラーバンドルをダウンロードし、整合性を検証します:
展開して、root でインストーラーを実行します:
インストーラーは次を行います:
Podman API ソケット（
podman.socket）を有効にします。Deployment Manager がその Docker 互換 API を通じてコンテナを管理します。バンドルされた Secure Gateway と SeaweedFS のイメージをホストの root Podman ストレージに読み込みます。レジストリからは何も取得しません。
ホスト上に旧 CNI の残骸があるとコンテナ間 DNS が壊れる場合、Podman のネットワークバックエンドを netavark に切り替えます。
ゲートウェイの TLS 証明書と秘密鍵を生成します。
Roboflow Deployment Manager を Podman モードの systemd サービスとしてインストールし、デバイス設定を書き込みます。
を有効にします
podman-restart.serviceホスト再起動後にコンテナが戻るようにします。Deployment Manager を起動し、ゲートウェイとキャッシュのコンテナを作成・起動します。
デプロイを検証します:
ゲートウェイとキャッシュのコンテナはどちらも 稼働中であるべきで、ヘルスチェックは HTTP 200 を返すはずです。 -k フラグは、ゲートウェイの証明書を信頼するまで必要です。以下を参照してください。 TLS と信頼.
エアギャップ環境にインストールする
同じバンドルはインターネットに接続していないホストにもインストールできます。コンテナイメージは OCI アーカイブとしてその中に含まれ、ホストの Podman ストレージへ直接読み込まれます。コンテナは厳密なバージョンタグを参照するため、インストール時もその後もレジストリから何も取得しません。
接続されたマシンでバンドルをダウンロードして検証し、リムーバブルメディアまたは社内のファイル転送プロセスでホストに転送してから、展開し install-podman.sh を上記とまったく同じように実行します。検証も同じです。
TLS と信頼
インストーラーはゲートウェイ用の自己署名証明書を生成します。ゲートウェイはそれを使ってポート 443 で HTTPS を提供し、ポート 80 の HTTP を HTTPS にリダイレクトします。生成された証明書は共通名 repo.roboflow.comを使用し、 *.roboflow.com, localhost、および 127.0.0.1、有効期間は10年です。インストーラーを再実行すると、その生成済みのペアは残り1年以上ある間は維持されるため、すでにクライアントへ配布した信頼設定は引き続き機能します。これは生成物にのみ適用されます。インストーラーはそれを別個に追跡するため、 --cert および --key 上書きした証明書は、自己署名のものに置き換えられます。
ゲートウェイは証明書とキーを /etc/secure-gateway/tls/tls.crt および /etc/secure-gateway/tls/tls.key のホスト上から読み取ります。 --cert および --key へ install-podman.sh 自分の材料を最初からインストールするには、またはその 2 つのファイルを置き換えてゲートウェイコンテナを再起動してください。証明書は repo.roboflow.com: クライアントインストールスクリプトがそのホスト名を /etc/hostsのゲートウェイに再向けし、コンテナランタイムはイメージを pull する前に TLS ホスト名を確認します。
ゲートウェイプロセスはコンテナ内で UID 1000、グループ 0 で実行されるため、ファイルは所有者権限で読み取ります。インストーラーは両方のファイルの所有者を 1000:0、モード 0640 秘密鍵は 0644 証明書は root:0 、モード 0750に設定します。root としてファイルを置き換えたまま root 所有のままにすることが、ゲートウェイが秘密鍵を読めなくなる最も一般的な原因です（以下参照 トラブルシューティング).
推論サーバーの接続
Roboflow Inference Server を実行する各マシンで、ゲートウェイのクライアントインストールスクリプトを実行します。これはゲートウェイの証明書をマシンの信頼ストアに追加し、Roboflow のトラフィック（API 呼び出し、モデル重み、コンテナイメージの pull）をゲートウェイ経由にルーティングします:
この -k フラグがここでは必要です。マシンはまだゲートウェイの証明書を信頼しておらず、その証明書をこのスクリプトがインストールします。この操作は自分で制御できるネットワーク経路上でのみ行うか、あるいはスクリプトを自分でコピーして先に確認してください。
別の方法として、個々の Inference Server をゲートウェイに向けるには SECURE_GATEWAY 環境変数を使用します。以下を参照してください。 推論サーバーの接続。使用 SECURE_GATEWAY=https://repo.roboflow.com。各バージョンで明示的な HTTPS スキームを使用してください。保留中の runtime-hardening ビルドでは、素のアドレスや平文のゲートウェイの扱いが変わるためです。詳細は セキュリティ構成の移行。ホスト名も重要です。生成された証明書は repo.roboflow.com をカバーし、ホストの IP アドレスはカバーしないため https://<host-ip> では、マシンが証明書を信頼していても証明書検証に失敗します。まずクライアントインストールスクリプトを実行して repo.roboflow.com でゲートウェイを指すようにし /etc/hosts 証明書をインストールします。IP アドレスを使う場合は、それをカバーする独自の証明書を発行し、 --cert および --keyにインストールしてください。外向きアクセスが必要なのはゲートウェイだけです api.roboflow.com および repo.roboflow.com.
トラブルシューティング
コンテナ同士が名前解決できず、ゲートウェイのログにキャッシュへの到達時の名前解決エラーが出る
Podman が旧 CNI ネットワークバックエンドを使っており、コンテナ DNS がありません。通常は以前のコンテナランタイムの CNI の残骸が原因です。次で確認してください sudo podman info --format '{{.Host.NetworkBackend}}'；返る値は netavarkです。インストーラーは必要に応じて netavark を選択するため、 /etc/containers/containers.conf.d/ 以下に drop-in を書き込みます。修正後も既存のコンテナは古いバックエンドのままなので、 sudo podman rm -f secure-gateway seaweedfs および Deployment Manager を再起動してsudo systemctl restart rfdmそれらを再作成します。
ゲートウェイが Permission denied で失敗し、TLS キーの読み取りに
証明書ファイルとキー ファイルは所有者が設定されている必要があります 1000:0 （モード 0640 秘密鍵は 0644 証明書は root:0 の所有者であるディレクトリ内に 0750、モード sudo chown 1000:0 /etc/secure-gateway/tls/tls.crt /etc/secure-gateway/tls/tls.key, sudo chmod 0640 /etc/secure-gateway/tls/tls.key, sudo chmod 0644 /etc/secure-gateway/tls/tls.crt。再実行でも install-podman.sh 修正できますが、 --cert および --key 独自の証明書を持ち込んだ場合は再度
Permission denied マウントされたディレクトリへの書き込み
ボリュームマウントに SELinux ラベルがありません。管理された構成のすべてのボリュームには :Z （または共有 :z）オプションが付いています。手動でマウントを追加した場合は、SELinux を permissive モードにするのではなく、ラベルを追加してください。
ゲートウェイがクラッシュループしています: PermissionError を読み取り中 /etc/ssl/certs/ca-certificates.crt
SELinux が、Deployment Manager がマウントするホストの CA バンドルへのコンテナアクセスをブロックしています。拒否は抑制されているため、audit 検索では何も見つかりません。次を実行してください sudo setsebool -P container_read_certs on。インストーラーはこの boolean を設定するので、再実行でもホスト側も修正されます。
ゲートウェイログ Init ハンドシェイクに失敗 ... local-cache-only モードで起動中
ゲートウェイは起動時に Roboflow API に到達できませんでした（API キーが誤っている、外向き接続がない、またはキャッシュがまだ起動中だった）。引き続きトラフィックを処理し、ローカルにはキャッシュしますが、S3 バックのキャッシュなしで動作し、次の再起動まではテレメトリやイベントをバックエンドへ報告できません。原因を修正してから、ゲートウェイコンテナを再起動してください: sudo podman restart <gateway-container>、コンテナ名は sudo podman ps.
ログの場所
Deployment Manager: sudo journalctl -u rfdm。ゲートウェイとキャッシュ: sudo podman logs <container>、コンテナ名は sudo podman ps.
サポートマトリクス
9.x
4.x
Podman 4 は RHEL 9 に付属しています
9.x
5.x
RHEL 9.6 と Podman 5.4.0 で検証済み
Podman 4.x がサポートされる最小バージョンです。現在の RHEL 9.x リリースに付属する Podman は、追加のリポジトリやパッケージなしでサポートされます。
最終更新
役に立ちましたか？