--- title: Red Hat OpenShift description: ROSA と ARO を含む Red Hat OpenShift に OpenLM Platform をインストールします。セキュリティコンテキスト制約、ルート、証明書、ストレージ、チャートの変更について説明します。 product: OpenLM Platform --- Red Hat OpenShift に OpenLM Platform をインストールするには、[ステップ 1](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-1-prepare-cluster) の前にこのページをお読みください。OpenShift はより厳しい既定値を持つ Kubernetes であり、OpenLM Platform は特別な権限なしでその上で動作します。標準のコンポーネントセットでは、`anyuid` も特権コンテナーも cluster-admin も不要です。このページでは、何が異なるか、チャートがそれにどう対応するか、追加で行う少数の手順を説明します。 ## OpenShift で異なる点と OpenLM Platform の対応 次の表は、OpenShift で異なる点と、OpenLM チャートの対応を示しています。 | OpenShift の動作 | 一般的なチャートへの影響 | OpenLM チャートの対応 | |---|---|---| | すべての Pod を **`restricted-v2` SCC** で実行します。プロジェクトの範囲からランダムなユーザー ID が割り当てられ、root なし、権限昇格なし、すべてのケーパビリティが削除されます | 固定のユーザー ID（例: `1000`）を持つ Pod は拒否されます | `global.useOpenShift: true` の場合、チャートは **ユーザー ID とグループ ID を除外** し、OpenShift に割り当てを任せます。すべての Pod は引き続き `runAsNonRoot`、`seccompProfile: RuntimeDefault`、`allowPrivilegeEscalation: false` を宣言し、すべてのケーパビリティを削除します。これは `restricted-v2` が求める内容です。このリリースでは、一部のコンポーネントで ID を明示的に設定する必要があります（[values の設定](#values-の設定) を参照）。 | | **ルート** と独自のルーターでトラフィックを受け入れます | コントローラー固有のアノテーションを持つ Ingress オブジェクトは、意図どおりに動作しません | `useOpenShift: true` の場合、チャートは **ルート** を作成します。ルーターでのエッジ TLS、HTTP から HTTPS へのリダイレクト、HSTS、セキュリティヘッダーを備えます。 | | 多くの場合、**クラスターではなくプロジェクト** が与えられます | ノードへのラベル付け、CRD のインストール、クラスターロールの作成ができません | チャートはそのいずれも必要としません。ノード配置は無効のままにしてください。 | | 多くの場合、イメージを **ミラー経由で** プルします | イメージ名を書き換えるか、ミラーする必要があります | OpenLM のイメージは 1 つのレジストリパス `public.ecr.aws/r3q3q2f4` を使用し、API ゲートウェイは `docker.tyk.io` からもプルします。両方をミラーしてください（[イメージ](#イメージ) を参照）。 | | プロジェクトごとに **LimitRange と ResourceQuota** を適用します | プロジェクトの最小値より小さいリクエストの Pod は拒否され、大規模なインストールはクォータに達します | クォータを計画し、最小値の削除を依頼してください。[リソースとクォータ](#リソースとクォータ) を参照してください。 | OpenLM Platform のイメージは、OpenShift の慣例に従い、グループ `0` を持つ任意のユーザー ID で実行されます。ただし、このリリースには例外が 1 つあります。拒否レポートを準備するスケジュールジョブ `denialsaggregation` です。任意のユーザー ID の下では、このジョブの実行は毎回 `Error` で終了します。OpenLM Platform のほかの部分には影響しませんが、拒否レポートは更新されません。 ## 始める前に 次の要件を確認します。 | 項目 | 要件 | |---|---| | OpenShift | 4.18 以降。Red Hat OpenShift Service on AWS (ROSA) と Azure Red Hat OpenShift (ARO) を含みます | | 必要な権限 | 1 つのプロジェクトに対する `admin`。標準セットでは cluster-admin は不要です。 | | 検証済みの環境 | 本番環境での OpenShift 4.18（ROSA）と OpenShift 4.20 系（Kubernetes 1.33） | | クラスターレベルのオブジェクト | 標準セットでは不要です。オプションのアドミッション Webhook コンポーネントはクラスターレベルのオブジェクトを作成するため、クラスター管理者が必要です。このコンポーネントは標準セットに含まれません。 | | ストレージ | **ブロック** ストレージクラス。ROSA では `gp3-csi`、ARO では `managed-csi`、それ以外では利用している CSI のブロッククラス（例: `thin-csi`、`ocs-storagecluster-ceph-rbd`）。多くのクラスターでは、ファイルベースのクラス（NFS または SMB）が既定です。プラットフォームのボリューム、データベース、Kafka にはこのクラスを使用せず、`STORAGE_CLASS` にブロッククラスを明示的に設定してください。 | | DNS 名 | クラスターの apps ドメイン配下の名前（`openlm.apps.`、最も簡単）、または証明書を用意した独自の名前。[証明書](#証明書) を参照してください。 | ワークシートで `ON_OPENSHIFT="true"` を設定します。`INGRESS_CLASS` は任意の値のままでかまいません。OpenShift では使用しません。 ## プロジェクトを作成する プロジェクトを作成し、そのユーザー ID の範囲を読み取ります。 ```bash oc new-project openlm oc get project openlm -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}{"\n"}' ``` 2 つ目のコマンドは、プロジェクトのユーザー ID の範囲（例: `1002360000/10000`）を出力します。[values の設定](#values-の設定) のスクリプトがこれを使用します。 ## values の設定 [ステップ 4](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-4-values) の後に、OpenShift 用の **2 つ目の** values ファイルを生成します。コマンドは、[インストールワークシート](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/worksheet) から作成したファイル `openlm-install.env` から変数を読み込みます。両方のファイルを Helm に渡します。Helm がこれらをマージするため、1 つ目のファイルを変更する必要はありません。 ```bash source ./openlm-install.env UID_START="$(oc get project "$NS" -o jsonpath='{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}' | cut -d/ -f1)" F=openlm-values-openshift.yaml cat > $F <> $F done # Components that set their own user IDs: give them IDs from the project's range for c in licensefilesmanagement platformhealth; do printf '%s:\n securityContext:\n pod: { runAsUser: %s, runAsGroup: 0, fsGroup: %s, runAsNonRoot: true, seccompProfile: { type: RuntimeDefault } }\n' \ "$c" "$UID_START" "$UID_START" >> $F done echo "written: $F" ``` 次に、**両方の** ファイルを指定してインストールします。これは [ステップ 6](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-6-install) のコマンドに代わるものです。 ```bash helm upgrade --install openlm-platform openlm/openlm-platform --version "$OPENLM_VERSION" -n "$NS" \ -f openlm-values.yaml -f openlm-values-openshift.yaml --timeout 60m ``` ## ルート チャートは、各 Web UI とサインイン用にルートを作成します。アップグレード時にルートのホストを変更しないでください。ホストは常に `DOMAIN` のままです。このリリースでは、**インストールとアップグレードのたびに**、追加の手順を 3 つ行います。 **1. データの匿名化をオンにした場合は**、そのルートを作成します。チャートはこのルートをまだ作成しません。ルートがないと、そのパスにはホームページが表示されます。`oc delete route` の行は、すべてのインストールで実行します。（`/api` のルートは、[ステップ 5](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-5-gateway) のゲートウェイのリリースが作成します。） ```bash oc -n "$NS" create route edge openlm-anonymization --service=openlm-anonymizationui --hostname="$DOMAIN" \ --path=/anonymization --insecure-policy=Redirect --dry-run=client -o yaml | oc -n "$NS" apply -f - oc -n "$NS" annotate route openlm-anonymization --overwrite haproxy.router.openshift.io/rewrite-target=/ # Only if an earlier installation created these by hand: remove them oc -n "$NS" delete route openlm-api openlm-dbconfigurationtool openlm-identity-alignment \ openlm-process-sessions openlm-touch-point-events --ignore-not-found ``` :::note[アップグレード時の手動作成のルート] 手動で作成したルートが、チャートが新たに作成するルートと同じ名前の場合、アップグレードは何も変更せずに停止します。手順 1 のコマンドで手動作成のルートを削除するか、Helm に引き継がせます。引き継がせるには、そのルートにラベル `app.kubernetes.io/managed-by=Helm` とアノテーション `meta.helm.sh/release-name=openlm-platform`、`meta.helm.sh/release-namespace=openlm` を追加し、アップグレードを再実行します。 ::: **2. サインインのパスを維持します。** サインイン用のルートは、`/identity` をそのまま渡す必要があります。これを行わないと、サインインが `409` で失敗します。 ```bash oc -n "$NS" annotate route identity-ingress haproxy.router.openshift.io/rewrite-target- ``` **3. ルートを確認します。** ```bash oc -n "$NS" get routes -o custom-columns=NAME:.metadata.name,HOST:.spec.host,PATH:.spec.path | sort -k3 ``` すべてのルートに `DOMAIN` が表示され、パスに `/`、`/api`、`/identity` が含まれていることを確認します。 ## 証明書 ルートは OpenShift ルーターで TLS を終端します。チャートのルートは独自の証明書を持たないため、**ルーターは既定の証明書を提供します**。次の表は 3 つのケースを示しています。 | `DOMAIN` | ルーターの証明書 | 対応 | |---|---|---| | apps ドメイン配下（`openlm.apps.`）で、ルーターの証明書が公的 CA の発行（ROSA での一般的なケース） | 信頼される | 不要 | | apps ドメイン配下で、ルーターの証明書がクラスター独自の CA の発行（新規の自己管理クラスターでの既定） | **Pod から信頼されない** | クラスター管理者に、信頼される既定の証明書をルーターにインストールするよう依頼するか、独自の証明書を持つ名前を使用します | | 独自の名前（`openlm.example.com`） | 対象外 | クラスター管理者に、その名前の証明書をルーターで提供するよう依頼する（既定の証明書またはルーターシャード）か、各ルートに証明書を追加します（`spec.tls.certificate` / `key`）。後者には `routes/custom-host` 権限が必要です | Pod から見える証明書を確認するには、次のコマンドを実行します。 ```bash echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null | openssl x509 -noout -subject -issuer -enddate ``` サブジェクトまたはサブジェクト代替名が `DOMAIN` をカバーし、発行者が Pod から信頼される CA である必要があります。これがサインインにとって重要な理由は、[TLS 証明書](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/concepts/tls-certificates) で説明しています。 [ステップ 3](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/install/step-3-secrets) では、引き続き `openlm-lb-cert` を作成します。OpenShift では使用しませんが、作成しておくと、シークレットのセットがすべてのプラットフォームで同じになります。 ## イメージ クラスターが `public.ecr.aws` からプルできない場合は、`public.ecr.aws/r3q3q2f4` を自社のレジストリにミラーして `ImageTagMirrorSet` を追加する（クラスター管理者）か、プルスルーのリモートリポジトリ（Quay、Artifactory、Nexus）を設定します。イメージのタグは変わりません。 プルスルーのレジストリは、多くの場合、新しいイメージを最初にプルしたときにスキャンし、スキャンが終わるまでそのイメージを保留します。また、パブリックレジストリは匿名のプルを制限しています。リリースのイメージは、インストールまたはアップグレードの作業時間帯の **1 日以上前に** 自社のレジストリ経由でプルしておいてください。イメージの一覧は、そのリリースの [リリースノート](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/release-notes/index) ページにあります。リモートリポジトリには、パブリックレジストリの認証情報を設定してください。 アップグレードでは、数十個の新しいイメージを一度にプルします。アップグレードの前に、ワーカーのイメージストレージに空きがあることを確認してください。ディスクの空きが少なくなったワーカーは、Pod を退避させます（`DiskPressure`）。 ## リソースとクォータ 次の数値を基に、プロジェクトのクォータを計画します。 - 標準セットの **リクエスト** は約 10 vCPU / 22 GiB で、メモリの **リミット** は合計で約 55 GiB です。プロジェクトのクォータは、多くの場合、リクエストではなく **リミット** に対して設定されています。このクォータは、リミットに API ゲートウェイの分と、新旧の Pod が並行して実行されるアップグレード時の余裕を加えた量を許可する必要があります。`limits.cpu: 64`、`limits.memory: 128Gi` を申請してください。詳しくは [サイジング](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/sizing) ページを参照してください。 - **LimitRange の最小値** は、プラットフォームの大部分をブロックします。ほとんどのコンポーネントのリクエストは小さく（最小で CPU 5m、メモリ 10 MiB）、OpenShift はリクエストが最小値を下回る Pod を **拒否** し、`minimum cpu usage per Pod is 100m` のようなイベントを出力します。クラスター管理者に、プロジェクトの最小値を削除するか、CPU 5m とメモリ 10 MiB 以下に設定するよう依頼してください。既定値と最大値は問題ありません。 - OpenLM Platform は **4 つの PersistentVolumeClaim** を使用し、API ゲートウェイはさらに **3 つ** 使用します。PVC のクォータがあるプロジェクトでは、少なくとも 7 つに加えて、プロジェクト内で実行するデータサービスのボリュームの分の余裕が必要です。 ## OpenShift 上のデータサービス MongoDB、Kafka、Redis は、プロジェクトの **外部**（マネージドサービスまたはプラットフォームチームが運用するもの）で実行するか、OpenShift 向けに作られたオペレーター（例: Kafka 用の Strimzi または AMQ Streams）で実行します。汎用のチャートの多くはユーザー ID をハードコードしているため、`restricted-v2` に拒否されます。 Kafka をプロジェクト内で実行する場合は、保持期間中のデータがボリュームを使い切らないように、すべてのトピックにサイズの上限（`retention.bytes`）を設定してください。ボリュームのサイズは、[サイジング](https://www.openlm.com/documentation/ja/cloud/deployment-operations/on-premise/deployment-guide/kubernetes/before-you-start/sizing) の説明に従って決めます。 ## バックアップ プラットフォームのボリュームには、CSI ボリュームスナップショットを使用できます。プロジェクト内の各 PVC の `VolumeSnapshot` を作成します。SQL Server、MongoDB、Kafka は、それぞれのツールでバックアップしてください。 ## OpenShift 固有の確認 次のコマンドを実行します。正常なインストールでは、どのコマンドも何も出力しません。 ```bash oc -n openlm get pods --no-headers | grep -vE "Running|Completed" # nothing oc -n openlm get events --field-selector reason=FailedCreate | grep -i "unable to validate against any security context constraint" # nothing ``` このリリースでは、1 つ目のコマンドで失敗した `openlm-denialsaggregation-…` ジョブの Pod も表示されます。これは [OpenShift で異なる点と OpenLM Platform の対応](#openshift-で異なる点と-openlm-platform-の対応) で説明しているとおり想定どおりです。出力にそれ以外の Pod がある場合は対処が必要です。 セキュリティコンテキスト制約に言及する `FailedCreate` イベントには、まだ固定のユーザー ID を設定しているコンポーネントの名前が示されます。そのコンポーネントを [values の設定](#values-の設定) の 2 つ目のループに追加し、インストールを再実行してください。