> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ja/serufuhosuto/enterprise/secure-gateway-podman.md). # Podman を使った RHEL 上の Secure Gateway Kubernetes を使わずに Red Hat Enterprise Linux ホスト上へ Secure Gateway をデプロイし、ゲートウェイとその暗号化キャッシュを Roboflow Deployment Manager が管理する Podman コンテナとして実行します。 [セキュアゲートウェイ](/deployment/ja/serufuhosuto/enterprise/secure-gateway.md) Docker も Kubernetes もない Red Hat Enterprise Linux ホストでも動作します。専用インストーラーがゲートウェイとその暗号化キャッシュを Podman コンテナとして配置し、Roboflow Deployment Manager（`rfdm`）が Podman を Docker 互換 API で制御します。Docker デプロイと同じゲートウェイ（Roboflow API をプロキシし、フリート向けにモデル重みとコンテナイメージをキャッシュする、制御された単一の送信出口）を、RHEL に付属するコンテナランタイム上で、同じエアギャップ対応バンドルモデルで利用できます。 {% hint style="info" %} 3つのデプロイモデルがあります。次を使用してください [Docker デプロイ](/deployment/ja/serufuhosuto/enterprise/secure-gateway.md) すでに Docker が動作しているホストではこのデプロイを、Docker または Kubernetes がない RHEL ホストではこのページを、そして [MicroShift 上の Secure Gateway](/deployment/ja/serufuhosuto/enterprise/secure-gateway-microshift.md) Kubernetes フリートとして管理されている Red Hat Device Edge ホストではこれを使用してください。ゲートウェイの構成リファレンス（キャッシュ、TLS 変数、ログのエクスポート）は 3 つすべてで共通です。以下を参照してください [セキュアゲートウェイ](/deployment/ja/serufuhosuto/enterprise/secure-gateway.md) および [Secure Gateway マニュアル](https://secure-gateway.roboflow.com/manual/). {% endhint %} ## アーキテクチャ * Roboflow Deployment Manager はホスト上で systemd サービスとして動作し、Podman の Docker 互換 API（`podman.socket`）を通じてコンテナを管理します。構成を維持し、更新し、稼働させ続けます。 * ゲートウェイとそのキャッシュバックエンド（SeaweedFS、保存時暗号化対応の S3 互換ストア）は、システム（root）Podman インスタンスの下でコンテナとして実行されます。 * ゲートウェイはポートを公開します `80` および `443` ホスト上に直接公開します: HTTPS は `443`、HTTP は `80` HTTPS にリダイレクトされます。 * キャッシュは `/data/seaweedfs` にホストのファイルシステム上で保存され、キャッシュコンテナに bind マウントされます。LVM ボリュームグループやストレージプロビジョナーは不要です。 * SELinux は enforcing のままです。管理されたコンテナ設定のボリュームマウントには SELinux ラベル（`:Z`/`z`）が付くため、手動での再ラベル付けも permissive モードも不要です。 これは単一ホストのデプロイです。高可用性やマルチホストクラスターはサポートされません。 {% hint style="warning" %} ゲートウェイには専用ホストを使用してください。Podman と CRI-O（MicroShift が使用するランタイム）はホストのコンテナストレージを共有するため、一方でのイメージクリーンアップ（例: `podman image prune`）では、もう一方のランタイムがキャッシュしたイメージが削除されることがあります。ホストで MicroShift が動作している場合は、代わりに [MicroShift デプロイ](/deployment/ja/serufuhosuto/enterprise/secure-gateway-microshift.md) を使用してください。 {% endhint %} ## 前提条件 * x86\_64 上の Red Hat Enterprise Linux 9.x ホストで、Podman 4.x 以降が必要です。インストーラーバンドルは `linux-amd64` 専用です。Podman は追加サブスクリプションなしで RHEL リポジトリから提供されますが、最小インストールには含まれていない場合があります。次を実行してください: `sudo dnf install podman` をまず `podman --version` が失敗する場合は。以下を参照してください。 [サポートマトリクス](#support-matrix). * ルート権限: ゲートウェイはシステム（root）Podman インスタンスの下にインストールされます * ディスク: 約 3 GB を `/` コンテナイメージ用に、さらにキャッシュ用の空き領域が `/data`に必要で、最大 50 GB まで増加します * ポート `80` および `443` ホスト上でゲートウェイに使用可能 * 接続されたインストールでは、外向き HTTPS は `api.roboflow.com` および `repo.roboflow.com` {% hint style="info" %} MicroShift デプロイとは異なり、インストールする Kubernetes ディストリビューションはありません。OpenShift pull secret も LVM ボリュームグループも不要です。Red Hat サブスクリプションは RHEL 自体をカバーしていれば十分です。 {% endhint %} ## 接続済みホストにインストールする Podman インストーラーバンドルをダウンロードし、整合性を検証します: ```bash curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz.sha256 echo "$(cat secure-gateway-podman-installer-linux-amd64.tar.gz.sha256) secure-gateway-podman-installer-linux-amd64.tar.gz" \\ | sha256sum -c - ``` 展開して、root でインストーラーを実行します: ```bash tar xzf secure-gateway-podman-installer-linux-amd64.tar.gz cd secure-gateway-podman-installer sudo ./install-podman.sh \\ --api-key \\ --device-id \\ --workspace ``` インストーラーは次を行います: 1. Podman API ソケット（`podman.socket`）を有効にします。Deployment Manager がその Docker 互換 API を通じてコンテナを管理します。 2. バンドルされた Secure Gateway と SeaweedFS のイメージをホストの root Podman ストレージに読み込みます。レジストリからは何も取得しません。 3. ホスト上に旧 CNI の残骸があるとコンテナ間 DNS が壊れる場合、Podman のネットワークバックエンドを netavark に切り替えます。 4. ゲートウェイの TLS 証明書と秘密鍵を生成します。 5. Roboflow Deployment Manager を Podman モードの systemd サービスとしてインストールし、デバイス設定を書き込みます。 6. を有効にします `podman-restart.service` ホスト再起動後にコンテナが戻るようにします。 7. Deployment Manager を起動し、ゲートウェイとキャッシュのコンテナを作成・起動します。 デプロイを検証します: ```bash sudo systemctl is-active rfdm sudo podman ps curl -fk https:///health ``` ゲートウェイとキャッシュのコンテナはどちらも `稼働中`であるべきで、ヘルスチェックは HTTP 200 を返すはずです。 `-k` フラグは、ゲートウェイの証明書を信頼するまで必要です。以下を参照してください。 [TLS と信頼](#tls-and-trust). ## エアギャップ環境にインストールする 同じバンドルはインターネットに接続していないホストにもインストールできます。コンテナイメージは 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 所有のままにすることが、ゲートウェイが秘密鍵を読めなくなる最も一般的な原因です（以下参照 [トラブルシューティング](#troubleshooting)). ## 推論サーバーの接続 Roboflow Inference Server を実行する各マシンで、ゲートウェイのクライアントインストールスクリプトを実行します。これはゲートウェイの証明書をマシンの信頼ストアに追加し、Roboflow のトラフィック（API 呼び出し、モデル重み、コンテナイメージの pull）をゲートウェイ経由にルーティングします: ```bash curl -fsSLk https:///install-client.sh | sudo bash -s -- --server ``` この `-k` フラグがここでは必要です。マシンはまだゲートウェイの証明書を信頼しておらず、その証明書をこのスクリプトがインストールします。この操作は自分で制御できるネットワーク経路上でのみ行うか、あるいはスクリプトを自分でコピーして先に確認してください。 別の方法として、個々の Inference Server をゲートウェイに向けるには `SECURE_GATEWAY` 環境変数を使用します。以下を参照してください。 [推論サーバーの接続](/deployment/ja/serufuhosuto/enterprise/secure-gateway.md#connecting-inference-servers)。使用 `SECURE_GATEWAY=https://repo.roboflow.com`。各バージョンで明示的な HTTPS スキームを使用してください。保留中の runtime-hardening ビルドでは、素のアドレスや平文のゲートウェイの扱いが変わるためです。詳細は [セキュリティ構成の移行](/deployment/ja/serufuhosuto/inference-server/configuration/security-migration.md#gateway-transport)。ホスト名も重要です。生成された証明書は `repo.roboflow.com` をカバーし、ホストの IP アドレスはカバーしないため `https://` では、マシンが証明書を信頼していても証明書検証に失敗します。まずクライアントインストールスクリプトを実行して `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.crtSELinux が、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.
## サポートマトリクス
RHELPodman注記
9.x4.xPodman 4 は RHEL 9 に付属しています
9.x5.xRHEL 9.6 と Podman 5.4.0 で検証済み
Podman 4.x がサポートされる最小バージョンです。現在の RHEL 9.x リリースに付属する Podman は、追加のリポジトリやパッケージなしでサポートされます。