Red Hat OpenShift

Red Hat OpenShift クラスターに OpenLM Platform をインストールするには、OpenLM Platform チャートの OpenShift モードを有効にします。このモードでは、チャートは Ingress オブジェクトではなく OpenShift のルートを通じて OpenLM Platform を公開し、Pod を実行するユーザー ID の割り当てを OpenShift に任せます。共通の手順はプラットフォームのインストールに従い、そのページで API ゲートウェイと OpenLM Platform をインストールする箇所で、このページの設定を追加してください。

プレビュー: openlm-platform チャート

このページは現在の openlm_mono チャートを対象としています。リリース候補として公開されている新しい openlm-platform 1.0 チャートについては、プレビューガイドの OpenShift 上の OpenLM Platform に従ってください。

始める前に

次の前提条件を確認します。

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 コンポーネントがクラッシュループするのはなぜですか？を参照してください。
証明書: そのホスト名に対してルーターが提供する証明書です。OpenShift での証明書を参照してください。
イメージ: public.ecr.aws/r3q3q2f4（OpenLM のイメージ）、docker.tyk.io（API ゲートウェイ）、docker.io（ゲートウェイの busybox init コンテナと、クラスター内で実行する場合の Bitnami インフラストラクチャイメージ）からのプルアクセス。クラスターがミラー経由でイメージを取得する場合は、これらのレジストリをミラーしてください。
インフラストラクチャ: SQL Server、MongoDB、Kafka、Redis（クラスター外またはクラスター内）。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 を設定する

プラットフォームのインストールで作成する values ファイルに、次の設定を追加します。

OpenShift モードを有効にする

OpenShift のスイッチを設定します。global.masterIngress.enabled は既定値の false のままにしてください。ルートがその役割を担います。

global:
  useOpenShift: true

すべての Web コンポーネントにホスト名を設定する

各ルートは、それぞれのコンポーネントの ingress.hostname からホストを取得します。チャートにはグローバルなホスト名がなく、既定値は OpenLM の開発用ホスト dev-k8s-us-cloud.openlm.com です。有効にする Web コンポーネントそれぞれに FQDN を設定してください。

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 が表示されている必要があります。

helm template monohelm openlm_mono-<version>.tgz -f mono-values.yaml -n openlm \
  | grep -E '^[[:space:]]+host:' | sort | uniq -c

ノードラベルなしで実行する

既定では、チャートは openlm.com/role=main または openlm.com/role=spark ラベルの付いたノードにのみワークロードをスケジュールします。クラスターのノードにこれらのラベルがない場合は、ノードアフィニティと対応する toleration を無効にしてください。無効にしないと、Pod はノードに割り当てられません。

global:
  affinity:
    enabled: false
  taints:
    enabled: false

専用のノードロールを維持する場合は、ノードアフィニティの説明に従ってノードにラベルを付けてください。

OpenShift での証明書

ルートはルーターで TLS を終端し、独自の証明書を持たないため、ルーターはこれらのルートに対して Ingress Controller のデフォルト証明書を提供します（Red Hat: Certificate types and descriptions）。プラットフォームのインストールで作成する openlm-lb-cert secret は、ルートが提供する証明書を変更しません。次のいずれかの構成を使用してください。

クラスターの apps ドメイン配下のホスト名: 例: openlm.apps.<cluster-domain>。ルーターのワイルドカード証明書が対象に含まれます。
その他のホスト名: クラスター管理者が、そのホスト名に対して Ingress Controller が提供する証明書を設定します（Red Hat: Replacing the default ingress certificate）。

エージェント、ブラウザー、OpenLM Platform のコンポーネントのすべてが、その証明書を信頼している必要があります。コンポーネントは、クラスター内から OpenLM Platform の公開 URL（https://<FQDN>/identity）を呼び出すためです。証明書がプライベート CA から発行されている場合は、クラスター内でプライベート CA を信頼させるの説明に従って、CA チェーンをコンポーネントにマウントしてください。

API ゲートウェイをインストールする

ゲートウェイチャートは、/api ルートを自ら作成します。API ゲートウェイのインストールの説明に従って openlm にインストールし、ゲートウェイの values に次の設定を加えてください。

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 に置き換えてください。

oc get namespace openlm -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}'

出力は <first-id>/<size> の形式です。例: 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 をインストールする

プラットフォームのインストールのコマンドで、OpenShift の設定を加えた values ファイルを指定して、OpenLM Platform を openlm にインストールします。

インストールの確認

インストール後に、次の確認を行います。

ルートの一覧を表示します。
```
oc get routes -n openlm
```
すべてのルートのホストが FQDN になっており、ゲートウェイの /api ルートが一覧に含まれていることを確認します。
実行中でない Pod の一覧を表示します。
```
oc get pods -n openlm | grep -vE 'Running|Completed'
```
すべての Pod が起動していれば、出力はヘッダー行だけになります。
デプロイの確認のリクエストを実行します。

トラブルシューティング

OpenShift に OpenLM Platform をインストールするときの、よくある問題を次に示します。

Pod がセキュリティーコンテキスト制約によって拒否されるのはなぜですか？

Pod に、プロジェクトの範囲外のユーザー ID またはグループ ID が設定されています。この場合も Helm はリリースを deployed と報告するため、イベントで拒否を確認します。

oc get events -n openlm --field-selector reason=FailedCreate

OpenLM Platform のコンポーネントでは、global.useOpenShift: true を設定します。API ゲートウェイと Kafka では、API ゲートウェイをインストールすると OpenShift 上のインフラストラクチャサービスの説明に従って、固定 ID を削除または置き換えます。

Pod がノードに割り当てられないのはなぜですか？

ノードアフィニティまたは toleration が有効なのに、対応する openlm.com/role ラベルを持つノードがないため、Pod が Pending 状態のままになっています。global.affinity.enabled: false と global.taints.enabled: false を設定するか、ノードアフィニティの説明に従ってノードにラベルを付けてください。

ルートに誤ったホストが表示されるのはなぜですか？

dev-k8s-us-cloud.openlm.com が表示されるルートは、values ファイルに ingress.hostname がないコンポーネントのものです。そのコンポーネントに FQDN を追加し、インストールコマンドを再実行してください。

/api の呼び出しがすべて 503 で失敗するのはなぜですか？

API ゲートウェイの Pod が実行されていません。ゲートウェイのイベントで SCC による拒否を確認し、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://<FQDN>/identity を解決できないか、到達できません。FQDN がクラスター内で解決されることと、ルーターが提供する証明書をコンポーネントが信頼していることを確認してください（OpenShift での証明書を参照）。

ドキュメントチームは、大規模言語モデルを使ってこのページを下書きすることがあります。公開前に、テクニカルライターがすべてのページをレビューし、製品と照らし合わせて検証します。最終的な判断は人間が行います。

始める前に​

OpenShift モードの仕組み​

OpenLM Platform の values を設定する​

OpenShift モードを有効にする​

すべての Web コンポーネントにホスト名を設定する​

ノードラベルなしで実行する​

OpenShift での証明書​

API ゲートウェイをインストールする​

OpenShift 上のインフラストラクチャサービス​

OpenLM Platform をインストールする​

インストールの確認​

トラブルシューティング​

Pod がセキュリティーコンテキスト制約によって拒否されるのはなぜですか？​

Pod がノードに割り当てられないのはなぜですか？​

ルートに誤ったホストが表示されるのはなぜですか？​

/api の呼び出しがすべて 503 で失敗するのはなぜですか？​

長いホスト名で Web コンポーネントがクラッシュループするのはなぜですか？​

Web コンポーネントが nginx ファイルで「Permission denied」になるのはなぜですか？​

サインインが IdentityUnavailable で失敗するのはなぜですか？​