> 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-microshift.md). # MicroShift 上の Secure Gateway Secure Gateway を Red Hat Device Edge にデプロイし、ゲートウェイとその暗号化キャッシュを Roboflow Deployment Manager が管理する MicroShift ワークロードとして実行します。 [Secure Gateway](/deployment/ja/self-hosted/enterprise/secure-gateway.md) また、エッジデバイス向けの Red Hat Kubernetes ディストリビューションである MicroShift を使用して Red Hat Device Edge 上でも実行されます。専用のインストーラーが、Roboflow Deployment Manager（`rfdm`）が監視する Kubernetes ワークロードとして、ゲートウェイとその暗号化キャッシュをデプロイします。これは RHEL ホスト上で実行されます。Docker デプロイメントと同じゲートウェイ（Roboflow API をプロキシし、フリート向けにモデルの重みとコンテナーイメージをキャッシュする、制御された単一の出口ポイント）が、Red Hat Device Edge 向けに標準化されたホスト用にパッケージ化されます。 {% hint style="info" %} このページでは MicroShift デプロイメントについて説明します。MicroShift または Docker を使用しない RHEL ホストについては、 [Podman を使用した RHEL 上の Secure Gateway](/deployment/ja/self-hosted/enterprise/secure-gateway-podman.md)を参照してください。Docker ホストおよびゲートウェイの構成リファレンス（キャッシュ、TLS 変数、ログのエクスポート）については、 [Secure Gateway](/deployment/ja/self-hosted/enterprise/secure-gateway.md) および [Secure Gateway マニュアル](https://secure-gateway.roboflow.com/manual/). {% endhint %} ## アーキテクチャ * Roboflow Deployment Manager は RHEL ホスト上で systemd サービスとして実行され、MicroShift の Kubernetes API を通じてワークロードを管理します。ゲートウェイの構成、更新、実行を維持します。 * ゲートウェイとそのキャッシュバックエンド（保存時暗号化を備えた S3 互換ストアである SeaweedFS）は、 `roboflow-edge` 名前空間内で Deployment として実行されます。 * 1 つの `LoadBalancer` Service により、デバイス IP 上でゲートウェイが公開されます。HTTPS はポート `443` 、HTTP から HTTPS へのリダイレクトはポート `80`. * キャッシュは、MicroShift の LVMS ストレージプロビジョナーによってプロビジョニングされる永続ボリュームに保存されます。ボリューム要求は 60 GB で、ゲートウェイの 50 GB キャッシュに余裕を加えたサイズです。 * すべてのワークロードは、MicroShift のデフォルトの restricted セキュリティプロファイルの下で非特権として実行されます。特権コンテナー、root ユーザー、カスタムセキュリティコンテキストの付与はありません。 これは単一ノードのデプロイメントです。高可用性および複数ノードのクラスターはサポートされません。 ## 前提条件 * 有効な Red Hat サブスクリプションを持つ、x86\_64 上の Red Hat Enterprise Linux 9.6 ホスト。インストーラーバンドルは `linux-amd64` 専用にビルドされています。 * OpenShift pull secret を構成済みで、インストールおよび実行されている Red Hat build of MicroShift 4.16 以降。4.20（EUS）を推奨します。 [サポートマトリックス](#support-matrix). * 少なくとも 60 GB の空きがある LVM ボリュームグループ。MicroShift の LVMS プロビジョナーはここからゲートウェイのキャッシュボリュームを作成します。ボリュームグループがない場合、または空き容量が不足している場合、ストレージ要求は `Pending` のままとなり、キャッシュは起動しません。 * `skopeo` がホストにインストールされていること（`sudo dnf install skopeo`）。インストーラーはこれを使用してバンドルされたイメージを CRI-O のストレージへコピーし、存在しない場合は停止します。 * OpenShift CLI（`oc`）がホストにインストールされており、そのバージョンが使用する MicroShift リリースと一致していること。MicroShift はこれをインストールしません。このページの検証コマンドとトラブルシューティングコマンドではこれを使用します。sudo の `secure_path` (`/usr/bin` 内の場所にインストールしてください（以下で動作します）。 `sudo` は `/usr/local/bin` を `PATH`から除外するため、そこに `oc` 展開されたものがあると、次のようになります。 `sudo: oc: command not found`. * ポート `80` および `443` がデバイス IP 上のゲートウェイで使用可能であること * 接続された環境へのインストールでは、以下へのアウトバウンド HTTPS が必要です。 `api.roboflow.com` および `repo.roboflow.com` 標準の RHEL インストールでは firewalld が実行されているため、実行中の場合はインストール前にゲートウェイのポートを開き、MicroShift の Pod ネットワークを trusted ゾーンに追加してください。これを行わないと、Pod ネットワークとクライアントアクセスの両方が失敗します。 ```bash sudo firewall-cmd --permanent --zone=trusted --add-source=10.42.0.0/16 sudo firewall-cmd --permanent --zone=trusted --add-source=169.254.169.1 sudo firewall-cmd --permanent --add-service=http --add-service=https sudo firewall-cmd --reload ``` firewalld の再読み込み後は、OVN Pod が再起動するまで MicroShift Pod ネットワークが壊れた状態になります。そのため、再読み込み後に [トラブルシューティング](#troubleshooting). {% hint style="warning" %} の復旧手順に従ってください。インストーラーは、ゲートウェイがデバイス上のポート 80 および 443 を使用できるよう、MicroShift のデフォルト ingress ルーターを無効化します。このホストですでにルーターを通じて他のワークロードを提供している場合、このデプロイメントモデルはそれらと競合します。ゲートウェイには専用デバイスを使用してください。 {% endhint %} ## 接続されたホストへのインストール MicroShift インストーラーバンドルをダウンロードし、その整合性を検証します。 ```bash curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/microshift/latest/secure-gateway-microshift-installer-linux-amd64.tar.gz curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/microshift/latest/secure-gateway-microshift-installer-linux-amd64.tar.gz.sha256 echo "$(cat secure-gateway-microshift-installer-linux-amd64.tar.gz.sha256) secure-gateway-microshift-installer-linux-amd64.tar.gz" \ | sha256sum -c - ``` 展開して、root としてインストーラーを実行します。 ```bash tar xzf secure-gateway-microshift-installer-linux-amd64.tar.gz cd secure-gateway-microshift-installer sudo ./install-microshift.sh \ --api-key \ --device-id \ --workspace ``` インストーラーは次を実行します。 1. MicroShift が実行中でサポート対象バージョンであること、およびストレージ用の LVM ボリュームグループが利用可能であることを確認します。 2. バンドルされた Secure Gateway および SeaweedFS イメージをホストのコンテナーストレージに読み込みます。レジストリーからは何もプルされません。 3. Kubernetes のディスク圧迫時のガベージコレクションによって削除されないよう、CRI-O の構成でイメージを固定します。 4. MicroShift のデフォルト ingress ルーターを無効化して MicroShift を再起動し、ゲートウェイ用にポート 80 と 443 を解放します。 5. Roboflow Deployment Manager を systemd サービスとしてインストールし、そのデバイス構成を書き込みます。 6. Deployment Manager を起動します。これにより、 `roboflow-edge` 名前空間が作成され、ゲートウェイとキャッシュがデプロイされます。 デプロイメントを検証します。 ```bash sudo systemctl is-active rfdm sudo oc get pods -n roboflow-edge \ --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig curl -fk https:///health ``` 両方の Pod が `Running`であり、ヘルスチェックが HTTP 200 を返す必要があります。 `-k` フラグは、ゲートウェイの証明書を信頼するまで必要です。 [TLS と信頼](#tls-and-trust). ## エアギャップ環境へのインストール 同じバンドルを、インターネットアクセスのないホストにもインストールできます。コンテナーイメージは OCI アーカイブとして内部に含まれており、ホストのコンテナーストレージへ直接読み込まれます。ワークロードは正確なバージョンタグを参照するため、インストール時もその後も、レジストリーから何かがプルされることはありません。 接続されたマシンでバンドルをダウンロードして検証し、リムーバブルメディアまたは社内のファイル転送手順でデバイスへ転送してから、展開して `install-microshift.sh` を上記とまったく同じように実行します。検証も同じです。 ## TLS と信頼 デフォルトでは、Roboflow Deployment Manager はゲートウェイ用の自己署名証明書を生成し、 `secure-gateway-tls` Secret（タイプ `kubernetes.io/tls`）に保存します。 `roboflow-edge` 名前空間内にあります。ゲートウェイ Pod はこの Secret をマウントし、ポート 443 で HTTPS を提供します。証明書は Deployment Manager の再インストール後も維持されます。Deployment Manager は、証明書がない場合、有効期限まで 30 日以内になった場合、証明書と秘密鍵が一致しなくなった場合、または新しい証明書に含まれるすべての名前をカバーしなくなった場合に、証明書を置き換えます。 独自の証明書はこれらすべての名前をカバーする必要があります。そうでない場合、Deployment Manager は次の reconcile 時に自己署名証明書へ置き換えます。 * `repo.roboflow.com`, `*.roboflow.com`、および `localhost`。クライアントは以下でゲートウェイに接続します。 `repo.roboflow.com`のため、証明書がこれをカバーしていない場合、コンテナーイメージのプルは失敗します。 * `secure-gateway`, `secure-gateway.roboflow-edge.svc`、および `secure-gateway.roboflow-edge.svc.cluster.local` * デバイスのホスト名 * IP アドレス `127.0.0.1` およびデバイス IP 独自の証明書を使用するには、Secret の内容を置き換え、ゲートウェイを再起動します。 ```bash export KUBECONFIG=/var/lib/microshift/resources/kubeadmin/kubeconfig sudo -E oc create secret tls secure-gateway-tls -n roboflow-edge \ --cert=/path/to/gateway.crt --key=/path/to/gateway.key \ --dry-run=client -o yaml | sudo -E oc apply -f - sudo -E oc rollout restart deployment/secure-gateway -n roboflow-edge ``` 証明書の有効期限が切れる 30 日以上前に更新してください。Secret 内の証明書が最後の 30 日間に入ると、Deployment Manager は新たに生成した自己署名証明書に置き換えます。デバイスの IP アドレスまたはホスト名を変更した場合も同じことが起きるため、いずれかを変更する前に証明書を再発行してください。 Deployment Manager は、このデバイス自身の TLS サービス証明書から信頼バンドルも構築し、これを `roboflow-trust-bundle` ConfigMap として公開します。これはゲートウェイにマウントされ、以下で提供されます。 `/trust-bundle.crt`。クライアントインストールスクリプトは、実行された各マシンにそのバンドルをインストールします。これにより、証明書を手動で配布しなくても、これらのクライアントはこのデバイス上のすべての TLS サービスを信頼できます。 ## Inference Server の接続 Roboflow Inference Server を実行する各マシンで、ゲートウェイのクライアントインストールスクリプトを実行します。これにより、ゲートウェイの証明書がマシンの信頼ストアに追加され、その Roboflow トラフィック（API 呼び出し、モデルの重み、コンテナーイメージのプル）がゲートウェイ経由になります。 Secret からゲートウェイの証明書をエクスポートし、すでに信頼しているチャネル（例: `scp`、組織のファイル転送手順、リムーバブルメディア）経由でクライアントにコピーしてください。証明書検証を無効にして、ゲートウェイ自体から取得しないでください。 ```bash export KUBECONFIG=/var/lib/microshift/resources/kubeadmin/kubeconfig sudo -E oc get secret secure-gateway-tls -n roboflow-edge \ -o jsonpath='{.data.tls\.crt}' | base64 -d > gateway-ca.crt scp gateway-ca.crt :/tmp/gateway-ca.crt ``` クライアント上で、その証明書に対して検証された TLS 接続経由でインストールスクリプトをダウンロードしてから実行します。 ```bash curl -fsSL --cacert /tmp/gateway-ca.crt \ https:///install-client.sh -o install-client.sh sudo bash install-client.sh --server ``` スクリプトを実行とは別にダウンロードすることで、root として実行する前に内容を読むこともできます。 自分で制御しているネットワーク経路でのみ実行してください。 `install-client.sh` は `/ca.crt` および `/trust-bundle.crt` を接続を検証せずにゲートウェイ自体から取得するため、その経路上の中間者は、上記のダウンロードが検証済みであっても、この手順で信頼される CA を提供できる可能性があります。 または、個別の Inference Server に対して、 `SECURE_GATEWAY` 環境変数でゲートウェイを指定できます。 [Inference Server の接続](/deployment/ja/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers)を参照してください。明示的なスキーム（`SECURE_GATEWAY=https://`）をバージョンをまたいで使用してください。証明書はこの IP をカバーする必要があります。保留中のランタイム強化ビルドでは、 [セキュリティ構成の移行](/deployment/ja/self-hosted/inference-server/configuration/security-migration.md#gateway-transport)で説明するように、スキームなしのアドレスおよび平文の動作が変更されます。Inference Server もゲートウェイの証明書を信頼する必要がありますが、クライアントインストールスクリプトがこれを処理します。アウトバウンドアクセスが必要なのはゲートウェイだけです。 `api.roboflow.com` および `repo.roboflow.com`. ## トラブルシューティング
症状対処方法
キャッシュボリュームが停止したまま PendingLVM ボリュームグループがないか、60 GB の空きがあるものがありません。空き容量は次のコマンドで確認します。 sudo vgs。十分な容量を持つボリュームグループが用意されると、ボリュームは自動的にバインドされます。より小さいボリュームで実行するには、 storage_size および CACHE_MAX_SIZE_GB を次のファイル内でまとめて下げます。 /opt/rfdm/config/rfconfig.json.
ゲートウェイ LoadBalancer Service が停止したまま <pending>デバイス上のポート 80/443 が依然として使用中です。通常はデフォルトルーターがまだ有効であることが原因です。インストーラーはこれを次の場所のスニペットで設定します。 /etc/microshift/config.d/10-roboflow-ingress.yamlであり、次のファイル内ではありません。 /etc/microshift/config.yaml。次のコマンドで確認してください。 sudo microshift show-config --mode effective が次を報告することを確認します。 ingress.status: Removed。スニペットがなくなっている場合は復元し、MicroShift を再起動してください。また、他のホストプロセスが 80 または 443 にバインドしていないことも確認してください。
firewalld の再読み込み後に接続が失敗するfirewalld を再読み込みすると、OVN ネットワーキング Pod が再起動するまで MicroShift Pod ネットワークが壊れます。 openshift-ovn-kubernetes 名前空間の Pod を削除して再作成させるか、MicroShift を再起動してください。
ノードが NotReady; ovnkube-master Pod が次のエラーでクラッシュループする MTU (...) of network interface ... is too small for specified overlay MTU (1500)ネットワークインターフェースの MTU が 1500 未満です（クラウド VPC や VPN リンクでは一般的で、GCP では 1460 を使用します）。次のファイルで Pod MTU をインターフェース MTU から 100 を引いた値に設定してください。 /etc/microshift/ovn.yaml。1460 のインターフェースの場合、ファイルには次の 1 行を含めます。 mtu: 1360。その後、次を実行します。 sudo systemctl stop microshift, echo 1 | sudo microshift-cleanup-data --ovn、および sudo systemctl start microshift。以前の MTU は OVN データベースに保存されているため、クリーンアップ手順が必要です。
ゲートウェイ Pod が停止したまま ImagePullBackOff ホストイメージのクリーンアップ後イメージの固定は正確なバンドル済み参照を保護しますが、 podman rmi または podman image prune をホストで実行すると、CRI-O が使用する同じストレージから兄弟イメージおよび共有レイヤーが削除される可能性があります。デバイス上のコンテナーストレージを prune しないでください。イメージがなくなった場合は、インストーラーを再実行して再読み込みしてください。
ゲートウェイログ Init handshake failed ... starting in local-cache-only modeゲートウェイは起動時に Roboflow API に到達できませんでした（API キーが誤っている、アウトバウンド接続がない、またはキャッシュがまだ起動中だった）。トラフィックの提供とローカルキャッシュは継続しますが、S3 バックエンドのキャッシュなしで実行され、次回の再起動までバックエンドにテレメトリーまたはイベントを報告できません。原因を修正してから、次を実行します。 sudo oc rollout restart deployment/secure-gateway -n roboflow-edge --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
ログの場所Deployment Manager: sudo journalctl -u rfdm。ゲートウェイおよびキャッシュ: sudo oc logs deployment/secure-gateway -n roboflow-edge （および deployment/seaweedfs）。使用するもの: --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig.
## サポートマトリックス
MicroShiftRHEL注記
4.199.6
4.20（EUS）9.6推奨
4.219.6RHEL 10 上の MicroShift 4.21 は Red Hat Technology Preview であり、Secure Gateway ではサポートされません。
MicroShift 4.16 がサポートされる最小バージョンです。偶数番号の MicroShift リリースには Extended Update Support（EUS）が提供されるため、長期間運用するエッジデプロイメントには 4.20 が最適な選択です。