> 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/self-hosted/enterprise/secure-gateway-podman.md). # Podman を使う RHEL 上の Secure Gateway Kubernetes を使わずに Red Hat Enterprise Linux ホスト上へ Secure Gateway をデプロイし、ゲートウェイとその暗号化キャッシュを Roboflow Deployment Manager が管理する Podman コンテナとして実行します。 [セキュアゲートウェイ](/deployment/ja/self-hosted/enterprise/secure-gateway.md) また、Docker も Kubernetes もない Red Hat Enterprise Linux ホストでも動作します。専用インストーラーが、Roboflow Deployment Manager（`rfdm`）によって管理される Podman コンテナとして、ゲートウェイとその暗号化キャッシュをデプロイします。Roboflow API をプロキシし、あなたのフリート向けにモデル重みとコンテナイメージをキャッシュする、制御された 1 つの送信ポイントという同じゲートウェイを、Docker デプロイと同じエアギャップ対応バンドルモデルで、RHEL に付属するコンテナランタイム上で利用できます。 {% hint style="info" %} 3つのデプロイモデルがあります。次を使用してください。 [Docker デプロイ](/deployment/ja/self-hosted/enterprise/secure-gateway.md) Docker がすでに動作しているホストではこのページを、Docker も Kubernetes もない RHEL ホストではこのページを、そして [MicroShift 上のセキュアゲートウェイ](/deployment/ja/self-hosted/enterprise/secure-gateway-microshift.md) Kubernetes フリートとして管理されている Red Hat Device Edge ホストではこれを使用してください。ゲートウェイの設定リファレンス（キャッシュ、TLS 変数、ログのエクスポート）は 3 つすべてで共通です。詳細は [セキュアゲートウェイ](/deployment/ja/self-hosted/enterprise/secure-gateway.md) および [セキュアゲートウェイ マニュアル](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` に保存され、ホストファイルシステム上でキャッシュコンテナにバインドマウントされます。LVM ボリュームグループやストレージプロビジョナーは不要です。 * SELinux は enforcing のままです。管理対象のコンテナ設定内のボリュームマウントには SELinux ラベル（`:Z`/`z`）が付くため、手動での再ラベル付けも permissive モードも不要です。 これは単一ホストのデプロイです。高可用性や複数ホストのクラスターはサポートされていません。 {% hint style="warning" %} ゲートウェイには専用ホストを使用してください。Podman と CRI-O（MicroShift が使用するランタイム）はホストのコンテナストレージを共有するため、一方でのイメージのクリーンアップ（例: `podman image prune`）が、もう一方のランタイムがキャッシュしたイメージを解放してしまうことがあります。ホストで MicroShift が動作している場合は、代わりに [MicroShift デプロイ](/deployment/ja/self-hosted/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 権限: ゲートウェイはシステム（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 ``` ゲートウェイとキャッシュの両方のコンテナが `Up`であり、ヘルスチェックは HTTP 200 を返すはずです。 `-k` フラグは、ゲートウェイの証明書を信頼するまで必要です。 [TLS と信頼](#tls-and-trust). ## エアギャップ環境にインストールする 同じバンドルを、インターネットにアクセスできないホストにもインストールできます。コンテナイメージは OCI アーカイブとしてその中に同梱され、ホストの Podman ストレージに直接読み込まれます。コンテナは正確なバージョンタグを参照するため、インストール時もその後も、レジストリから何も取得されません。 接続済みのマシンでバンドルをダウンロードして検証し、リムーバブルメディアまたは社内のファイル転送手順でホストに転送してから、展開して `install-podman.sh` を上記とまったく同じように実行します。検証方法も同じです。 ## TLS と信頼 インストーラーはゲートウェイ用の自己署名証明書を生成し、その証明書でポート上の HTTPS を提供します `443` およびポート上の HTTP を `80` HTTPS にリダイレクトします。 `repo.roboflow.com`、また以下もカバーします `*.roboflow.com`, `localhost`、および `127.0.0.1`10 年間有効です。インストーラーを再実行しても、その生成済みペアに有効期限が 1 年以上残っていれば維持されるため、すでにクライアントへ配布した信頼設定は引き続き機能します。これは生成された素材にのみ適用されます。インストーラーはそれを個別に追跡するため、--cert と --key なしで再実行すると `--cert` および `--key` を指定して提供した証明書が自己署名証明書で上書きされます。 ゲートウェイは証明書と鍵をホスト上の `/etc/secure-gateway/tls/tls.crt` および `/etc/secure-gateway/tls/tls.key` から読み込みます。 `--cert` および `--key` を `install-podman.sh` に渡して最初から独自の素材をインストールするか、これら 2 つのファイルを置き換えてゲートウェイコンテナを再起動してください。証明書は `repo.roboflow.com`：クライアントのインストールスクリプトは `repo.roboflow.com` のゲートウェイに向け直します `/etc/hosts`、コンテナランタイムはイメージを取得する前に TLS ホスト名を確認します。追加しないでください `*.roboflow.com`：クライアントのインストールスクリプトはこの証明書を各クライアントのシステム全体の信頼ストアにインストールするため、ワイルドカードにすると、その後に秘密鍵を入手した誰でも `api.roboflow.com` または他の roboflow\.com ホストになりすませるようになります。 ゲートウェイプロセスはコンテナ内で UID 1000、グループ 0 で実行されるため、ファイルは所有者権限で読み取られます。インストーラーは両方のファイルの所有者を `1000:0`、モード `0640` キーでは `0644` 証明書では、ディレクトリの所有者を `root:0` およびモード `0750`に設定します。ファイルを root で置き換えて root 所有のままにすることが、ゲートウェイがキーを読めなくなる最も一般的な原因です（ [トラブルシューティング](#troubleshooting)). ## Inference Server の接続 Roboflow Inference Server を実行する各マシンで、ゲートウェイのクライアントインストールスクリプトを実行してください。これにより、ゲートウェイの証明書がそのマシンの信頼ストアに追加され、Roboflow トラフィック（API 呼び出し、モデル重み、コンテナイメージの取得）がゲートウェイ経由になります。 まず、すでに信頼しているチャネルでゲートウェイの証明書をクライアントにコピーしてください（例: `scp` ゲートウェイホストから、組織のファイル転送手順、リムーバブルメディア）。証明書の検証を無効にして、ゲートウェイ自体から取得しないでください: ```bash sudo cat /etc/secure-gateway/tls/tls.crt > gateway-ca.crt && scp gateway-ca.crt :/tmp/gateway-ca.crt ``` クライアント側では、その証明書で検証された TLS 接続を使ってインストールスクリプトをダウンロードし、次にそれを実行します。 `--resolve` は `repo.roboflow.com` 証明書がカバーする名前をゲートウェイの IP に向けるため、検証を無効にしなくても成功します。スクリプトは `?server=` 付きで要求してください。そうすればゲートウェイはスクリプトをテンプレート化するすべての箇所に正しいアドレスを入れ、 `repo.roboflow.com` リクエストのホスト名ではなく、 ```bash curl -fsSL --cacert /tmp/gateway-ca.crt --resolve repo.roboflow.com:443: \ "https://repo.roboflow.com/install-client.sh?server=" -o install-client.sh sudo bash install-client.sh --server ``` スクリプトを別にダウンロードしてから実行すると、root として実行する前に内容を確認することもできます。 実行するのは、自分で管理するネットワーク経路上だけにしてください: `install-client.sh` は `/ca.crt` および `/trust-bundle.crt` を、接続を検証せずにゲートウェイ自体から取得します。そのため、その経路上のインターセプターは、上記のダウンロードが検証済みであっても、その手順で信頼済み CA を供給できてしまいます。 あるいは、 `SECURE_GATEWAY` 環境変数を使って、個別の Inference Server をゲートウェイに向けてください。詳細は [Inference Server の接続](/deployment/ja/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers)を参照してください。 `SECURE_GATEWAY=https://repo.roboflow.com`を使用してください。明示的な HTTPS スキームをバージョンをまたいで使用してください。保留中のランタイム強化ビルドでは、ベアアドレスと平文のゲートウェイの扱いが変わるためです。詳細は [セキュリティ設定の移行](/deployment/ja/self-hosted/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/ に書き込みます。修正後も既存コンテナは古いバックエンドのままなので、次で削除します sudo podman rm -f secure-gateway seaweedfs を実行し、Deployment Manager（sudo systemctl restart rfdm）を再起動して再作成します。
ゲートウェイが Permission denied を返して TLS 鍵の読み取りに失敗する証明書と鍵のファイルは所有されている必要があります 1000:0 （モード 0640 は鍵で、 0644 は証明書で）、所有されているディレクトリ内に root:0 モードで 0750置かれていなければなりません。これはインストーラーが設定します。通常の原因は、証明書を root として手動で置き換えたことです。手動で設定してから、ゲートウェイコンテナを再起動してください: 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コンテナから、Deployment Manager がマウントしているホストの CA バンドルが SELinux によりブロックされています。拒否は抑制されるため、audit 検索には何も出ません。 sudo setsebool -P container_read_certs onを実行してください。インストーラーはこの boolean を設定するので、再実行してもホスト側は修正されます。
ゲートウェイのログ 初期ハンドシェイクに失敗しました ... ローカルキャッシュのみモードで起動します起動時にゲートウェイが 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 は、追加のリポジトリやパッケージなしでサポートされます。