---
title: Red Hat OpenShift
description: Red Hat OpenShift に OpenLM Platform をインストールします。チャートの OpenShift モードを有効にし、ルートでプラットフォームを公開して、restricted のセキュリティーコンテキスト制約に適合させます。
product: OpenLM Platform
---
Red Hat OpenShift クラスターに OpenLM Platform をインストールするには、OpenLM Platform チャートの OpenShift モードを有効にします。このモードでは、チャートは Ingress オブジェクトではなく OpenShift のルートを通じて OpenLM Platform を公開し、Pod を実行するユーザー ID の割り当てを OpenShift に任せます。共通の手順は [プラットフォームのインストール](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation) に従い、そのページで API ゲートウェイと OpenLM Platform をインストールする箇所で、このページの設定を追加してください。
:::info[プレビュー: openlm-platform チャート]
このページは現在の `openlm_mono` チャートを対象としています。リリース候補として公開されている新しい `openlm-platform` 1.0 チャートについては、プレビューガイドの [OpenShift 上の OpenLM Platform](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/platforms/openshift) に従ってください。
:::
## 始める前に
次の前提条件を確認します。
- **OpenShift バージョン**: OpenLM は、OpenLM Platform チャートを OpenShift 4.18 と 4.20 でテストしています。
- **プロジェクト**: API ゲートウェイと OpenLM Platform は、`openlm` という名前のプロジェクトにインストールします。どちらのチャートも `openlm` namespace にルートを作成し、OpenLM Platform のコンポーネントの既定の namespace も `openlm` です。別のプロジェクトにインストールする場合は、有効にするすべてのコンポーネントでこの namespace を上書きする必要があります。
- **ホスト名**: OpenShift ルーターに解決される、OpenLM Platform 用の完全修飾ドメイン名（FQDN）を 1 つ用意します。例: `openlm.example.com`。ホスト名は短くしてください。[長いホスト名で Web コンポーネントがクラッシュループするのはなぜですか？](#長いホスト名で-web-コンポーネントがクラッシュループするのはなぜですか) を参照してください。
- **証明書**: そのホスト名に対してルーターが提供する証明書です。[OpenShift での証明書](#openshift-での証明書) を参照してください。
- **イメージ**: `public.ecr.aws/r3q3q2f4`（OpenLM のイメージ）、`docker.tyk.io`（API ゲートウェイ）、`docker.io`（ゲートウェイの `busybox` init コンテナと、クラスター内で実行する場合の Bitnami インフラストラクチャイメージ）からのプルアクセス。クラスターがミラー経由でイメージを取得する場合は、これらのレジストリをミラーしてください。
- **インフラストラクチャ**: SQL Server、MongoDB、Kafka、Redis（クラスター外またはクラスター内）。[OpenShift 上のインフラストラクチャサービス](#openshift-上のインフラストラクチャサービス) を参照してください。
## OpenShift モードの仕組み
ルートを通じて OpenLM Platform を公開するには、OpenLM Platform の values ファイルで `global.useOpenShift: true` を設定します。これにより、チャートは次の 3 点を変更します。
- Web コンポーネントごとに、Ingress オブジェクトではなく OpenShift のルートを作成します。オンプレミスの全コンポーネントセットでは 32 個のルートになります。各ルートはルーターで TLS を終端し（エッジ終端）、HTTP を HTTPS にリダイレクトします。
- すべてのルートに、HTTP Strict Transport Security (HSTS) ヘッダーと次のセキュリティ応答ヘッダーを追加します: `X-Frame-Options`、`X-Content-Type-Options`、`Referrer-Policy`、`Content-Security-Policy: frame-ancestors 'self'`。これらを付けない場合は、`global.routeSecurity.enabled: false` を設定します。
- すべての Pod から `runAsUser`、`runAsGroup`、`fsGroup` を除外します。OpenShift は、既定の `restricted-v2` セキュリティーコンテキスト制約（SCC）に基づき、これらをプロジェクトの範囲から割り当てます。
各 Pod のセキュリティーコンテキストのその他の部分は、チャートの定義どおりです。オンプレミスのセットに含まれるすべてのコンポーネントは、非 root として、`RuntimeDefault` seccomp プロファイルを使用し、権限昇格なし、すべての Linux ケーパビリティを削除した状態で実行されます。チャート内のどのコンポーネントも、特権モードでの実行、ホストネットワークの使用、ホストパスのマウント、ユーザー ID 0 での実行は行いません。
## OpenLM Platform の values を設定する
[プラットフォームのインストール](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation#values-ファイルを作成する) で作成する values ファイルに、次の設定を追加します。
### OpenShift モードを有効にする
OpenShift のスイッチを設定します。`global.masterIngress.enabled` は既定値の `false` のままにしてください。ルートがその役割を担います。
```yaml
global:
useOpenShift: true
```
### すべての Web コンポーネントにホスト名を設定する
各ルートは、それぞれのコンポーネントの `ingress.hostname` からホストを取得します。チャートにはグローバルなホスト名がなく、既定値は OpenLM の開発用ホスト `dev-k8s-us-cloud.openlm.com` です。有効にする Web コンポーネントそれぞれに FQDN を設定してください。
```yaml
homepageui:
enabled: true
ingress:
hostname: openlm.example.com
identity:
enabled: true
ingress:
hostname: openlm.example.com
```
次のコンポーネントにはルートがあります。有効にするコンポーネントそれぞれに `ingress.hostname` を設定してください。
ルートを持つコンポーネント（32）
`agentactivitymanagerui`, `agentshubui`, `alertsserviceui`, `auditserviceui`, `brokerhubui`, `cloudbrokerui`, `complianceserviceui`, `denialsui`, `donglemonitoringui`, `dssui`, `homepageui`, `identity`, `identityui`, `integrationui`, `licenseaccesscontrolui`, `licenseallocationsui`, `licensefilesui`, `licensemanagerui`, `licenseserversui`, `licensesui`, `navigationui`, `notificationui`, `personaldashboard`, `processmanagerui`, `productsserviceui`, `projectsserviceui`, `samcatalogui`, `softwareassetmanagementui`, `uiconfigurationserviceui`, `usageui`, `usersandgroupsserviceui`, `vlmui`
インストール前にホストを確認するには、チャートをレンダリングしてホストを数えます。出力のすべての行に FQDN が表示されている必要があります。
```bash
helm template monohelm openlm_mono-.tgz -f mono-values.yaml -n openlm \
| grep -E '^[[:space:]]+host:' | sort | uniq -c
```
### ノードラベルなしで実行する
既定では、チャートは `openlm.com/role=main` または `openlm.com/role=spark` ラベルの付いたノードにのみワークロードをスケジュールします。クラスターのノードにこれらのラベルがない場合は、ノードアフィニティと対応する toleration を無効にしてください。無効にしないと、Pod はノードに割り当てられません。
```yaml
global:
affinity:
enabled: false
taints:
enabled: false
```
専用のノードロールを維持する場合は、[ノードアフィニティ](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation#ノードアフィニティ) の説明に従ってノードにラベルを付けてください。
## OpenShift での証明書
ルートはルーターで TLS を終端し、独自の証明書を持たないため、ルーターはこれらのルートに対して Ingress Controller のデフォルト証明書を提供します（[Red Hat: Certificate types and descriptions](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/security_and_compliance/certificate-types-and-descriptions)）。[プラットフォームのインストール](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation) で作成する `openlm-lb-cert` secret は、ルートが提供する証明書を変更しません。次のいずれかの構成を使用してください。
- **クラスターの apps ドメイン配下のホスト名**: 例: `openlm.apps.`。ルーターのワイルドカード証明書が対象に含まれます。
- **その他のホスト名**: クラスター管理者が、そのホスト名に対して Ingress Controller が提供する証明書を設定します（[Red Hat: Replacing the default ingress certificate](https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/security_and_compliance/configuring-certificates#replacing-default-ingress)）。
エージェント、ブラウザー、OpenLM Platform のコンポーネントのすべてが、その証明書を信頼している必要があります。コンポーネントは、クラスター内から OpenLM Platform の公開 URL（`https:///identity`）を呼び出すためです。証明書がプライベート CA から発行されている場合は、[クラスター内でプライベート CA を信頼させる](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/tls-certificates#クラスター内でプライベート-ca-を信頼させる) の説明に従って、CA チェーンをコンポーネントにマウントしてください。
## API ゲートウェイをインストールする
ゲートウェイチャートは、`/api` ルートを自ら作成します。[API ゲートウェイのインストール](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation#api-ゲートウェイのインストール) の説明に従って `openlm` にインストールし、ゲートウェイの values に次の設定を加えてください。
```yaml
openShiftRoute:
enabled: true
host: openlm.example.com
tyk-oss:
tyk-gateway:
gateway:
hostName: openlm.example.com
ingress:
enabled: false
securityContext:
runAsUser: null
fsGroup: null
containerSecurityContext:
runAsUser: null
```
各設定の役割は次のとおりです。
- `openShiftRoute` は、エッジ TLS 終端を使用する `/api` ルートを `openlm` namespace に作成します。ゲートウェイチャート `0.2.11` 以降では、このルートにも OpenLM Platform のルートと同じ HSTS ヘッダーとセキュリティヘッダーが付きます。
- `ingress.enabled: false` は、ルートで置き換えるゲートウェイ自身の Ingress オブジェクトを無効にします。
- `null` の値は、Tyk ゲートウェイ Pod の固定 ID である `runAsUser: 1000` と `fsGroup: 2000` を削除します。`restricted-v2` SCC はプロジェクトの範囲外の ID を拒否するため、固定 ID のままではゲートウェイ Pod が起動せず、すべての `/api` 呼び出しが失敗します。
Helm 4 は、`null` に設定したサブチャートの値を削除します。Helm 3 はチャートの値を保持します。Helm 3 では、各 `null` を、次のコマンドが出力するプロジェクトの範囲の先頭 ID に置き換えてください。
```bash
oc get namespace openlm -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}'
```
出力は `/` の形式です。例: `1005910000/10000`
## OpenShift 上のインフラストラクチャサービス
OpenLM Platform に必要なのは、SQL Server、MongoDB、Kafka、Redis のエンドポイントと資格情報だけなので、これらはクラスター外で実行できます。クラスター内で実行する場合は、各チャートのセキュリティーコンテキストを `restricted-v2` SCC と照らし合わせて確認してください。次の表は、OpenLM が使用する Bitnami チャートの動作を示しています。
| チャート | OpenShift での動作 |
| --- | --- |
| MariaDB `22.0.0`、MongoDB `15.6.19`、PostgreSQL `16.7.21`、Redis `20.1.7` | セキュリティーコンテキストを OpenShift に合わせて自動で調整します（`global.compatibility.openshift.adaptSecurityContext: auto`）。 |
| Kafka `26.6.2` | controller と broker の Pod に `runAsUser: 1001` と `fsGroup: 1001` を設定し、OpenShift 向けの調整は行いません。Kafka の Pod にこれらの ID を許可するか、Kafka の values で上書きするか、Kafka をクラスター外で実行してください。 |
## OpenLM Platform をインストールする
[プラットフォームのインストール](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation#openlm-platform-のインストール) のコマンドで、OpenShift の設定を加えた values ファイルを指定して、OpenLM Platform を `openlm` にインストールします。
## インストールの確認
インストール後に、次の確認を行います。
1. ルートの一覧を表示します。
```bash
oc get routes -n openlm
```
すべてのルートのホストが FQDN になっており、ゲートウェイの `/api` ルートが一覧に含まれていることを確認します。
2. 実行中でない Pod の一覧を表示します。
```bash
oc get pods -n openlm | grep -vE 'Running|Completed'
```
すべての Pod が起動していれば、出力はヘッダー行だけになります。
3. [デプロイの確認](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation#デプロイの確認) のリクエストを実行します。
## トラブルシューティング
OpenShift に OpenLM Platform をインストールするときの、よくある問題を次に示します。
### Pod がセキュリティーコンテキスト制約によって拒否されるのはなぜですか？
Pod に、プロジェクトの範囲外のユーザー ID またはグループ ID が設定されています。この場合も Helm はリリースを `deployed` と報告するため、イベントで拒否を確認します。
```bash
oc get events -n openlm --field-selector reason=FailedCreate
```
OpenLM Platform のコンポーネントでは、`global.useOpenShift: true` を設定します。API ゲートウェイと Kafka では、[API ゲートウェイをインストールする](#api-ゲートウェイをインストールする) と [OpenShift 上のインフラストラクチャサービス](#openshift-上のインフラストラクチャサービス) の説明に従って、固定 ID を削除または置き換えます。
### Pod がノードに割り当てられないのはなぜですか？
ノードアフィニティまたは toleration が有効なのに、対応する `openlm.com/role` ラベルを持つノードがないため、Pod が `Pending` 状態のままになっています。`global.affinity.enabled: false` と `global.taints.enabled: false` を設定するか、[ノードアフィニティ](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/platform-installation#ノードアフィニティ) の説明に従ってノードにラベルを付けてください。
### ルートに誤ったホストが表示されるのはなぜですか？
`dev-k8s-us-cloud.openlm.com` が表示されるルートは、values ファイルに `ingress.hostname` がないコンポーネントのものです。そのコンポーネントに FQDN を追加し、インストールコマンドを再実行してください。
### /api の呼び出しがすべて 503 で失敗するのはなぜですか？
API ゲートウェイの Pod が実行されていません。ゲートウェイのイベントで SCC による拒否を確認し、[API ゲートウェイをインストールする](#api-ゲートウェイをインストールする) の説明に従って ID を設定してください。
### 長いホスト名で Web コンポーネントがクラッシュループするのはなぜですか？
Web コンポーネントは FQDN を nginx の設定に書き込みますが、nginx の既定のサーバー名ハッシュには長い名前が収まりません。ログには `could not build server_names_hash, you should increase server_names_hash_bucket_size` と表示されます。OpenLM では、57 文字のホスト名でこの現象を確認しています。より短い FQDN を使用するか、OpenLM サポートにお問い合わせください。
### Web コンポーネントが nginx ファイルで「Permission denied」になるのはなぜですか？
そのコンポーネントのイメージが、`/run/nginx.pid` などの nginx ファイルを root のみが書き込めるディレクトリに書き込んでいます。OpenShift が割り当てるユーザー ID では、そのコンポーネントはクラッシュします。修正済みのイメージについては、OpenLM サポートにお問い合わせください。
### サインインが IdentityUnavailable で失敗するのはなぜですか？
コンポーネントが `https:///identity` を解決できないか、到達できません。FQDN がクラスター内で解決されることと、ルーターが提供する証明書をコンポーネントが信頼していることを確認してください（[OpenShift での証明書](#openshift-での証明書) を参照）。