Red Hat OpenShift

Red Hat OpenShift に OpenLM Platform をインストールするには、ステップ 1 の前にこのページをお読みください。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 の設定 を参照）。
ルート と独自のルーターでトラフィックを受け入れます	コントローラー固有のアノテーションを持つ 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.<cluster-domain>、最も簡単）、または証明書を用意した独自の名前。証明書 を参照してください。

ワークシートで ON_OPENSHIFT="true" を設定します。INGRESS_CLASS は任意の値のままでかまいません。OpenShift では使用しません。

プロジェクトを作成する

プロジェクトを作成し、そのユーザー ID の範囲を読み取ります。

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 の設定

ステップ 4 の後に、OpenShift 用の 2 つ目の values ファイルを生成します。コマンドは、インストールワークシート から作成したファイル openlm-install.env から変数を読み込みます。両方のファイルを Helm に渡します。Helm がこれらをマージするため、1 つ目のファイルを変更する必要はありません。

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 <<EOF
# OpenShift additions for $DOMAIN (project UID range starts at $UID_START)
global:
  useOpenShift: true             # Routes instead of Ingress; OpenShift assigns user IDs
  masterIngress: { enabled: false }
EOF
# Every Route carries the host name
for c in agentactivitymanagerui agentshubui alertsserviceui auditserviceui brokerhubui cloudbrokerui \
         complianceserviceui dbconfigurationtoolui 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; do
  printf '%s:\n  ingress: { hostname: %s }\n' "$c" "$DOMAIN" >> $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 のコマンドに代わるものです。

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 のゲートウェイのリリースが作成します。）

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

アップグレード時の手動作成のルート

手動で作成したルートが、チャートが新たに作成するルートと同じ名前の場合、アップグレードは何も変更せずに停止します。手順 1 のコマンドで手動作成のルートを削除するか、Helm に引き継がせます。引き継がせるには、そのルートにラベル app.kubernetes.io/managed-by=Helm とアノテーション meta.helm.sh/release-name=openlm-platform、meta.helm.sh/release-namespace=openlm を追加し、アップグレードを再実行します。

2. サインインのパスを維持します。 サインイン用のルートは、/identity をそのまま渡す必要があります。これを行わないと、サインインが 409 で失敗します。

oc -n "$NS" annotate route identity-ingress haproxy.router.openshift.io/rewrite-target-

3. ルートを確認します。

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.<cluster>）で、ルーターの証明書が公的 CA の発行（ROSA での一般的なケース）	信頼される	不要
apps ドメイン配下で、ルーターの証明書がクラスター独自の CA の発行（新規の自己管理クラスターでの既定）	Pod から信頼されない	クラスター管理者に、信頼される既定の証明書をルーターにインストールするよう依頼するか、独自の証明書を持つ名前を使用します
独自の名前（openlm.example.com）	対象外	クラスター管理者に、その名前の証明書をルーターで提供するよう依頼する（既定の証明書またはルーターシャード）か、各ルートに証明書を追加します（spec.tls.certificate / key）。後者には routes/custom-host 権限が必要です

Pod から見える証明書を確認するには、次のコマンドを実行します。

echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null | openssl x509 -noout -subject -issuer -enddate

サブジェクトまたはサブジェクト代替名が DOMAIN をカバーし、発行者が Pod から信頼される CA である必要があります。これがサインインにとって重要な理由は、TLS 証明書 で説明しています。

ステップ 3 では、引き続き openlm-lb-cert を作成します。OpenShift では使用しませんが、作成しておくと、シークレットのセットがすべてのプラットフォームで同じになります。

イメージ

クラスターが public.ecr.aws からプルできない場合は、public.ecr.aws/r3q3q2f4 を自社のレジストリにミラーして ImageTagMirrorSet を追加する（クラスター管理者）か、プルスルーのリモートリポジトリ（Quay、Artifactory、Nexus）を設定します。イメージのタグは変わりません。

プルスルーのレジストリは、多くの場合、新しいイメージを最初にプルしたときにスキャンし、スキャンが終わるまでそのイメージを保留します。また、パブリックレジストリは匿名のプルを制限しています。リリースのイメージは、インストールまたはアップグレードの作業時間帯の 1 日以上前に 自社のレジストリ経由でプルしておいてください。イメージの一覧は、そのリリースの リリースノート ページにあります。リモートリポジトリには、パブリックレジストリの認証情報を設定してください。

アップグレードでは、数十個の新しいイメージを一度にプルします。アップグレードの前に、ワーカーのイメージストレージに空きがあることを確認してください。ディスクの空きが少なくなったワーカーは、Pod を退避させます（DiskPressure）。

リソースとクォータ

次の数値を基に、プロジェクトのクォータを計画します。

• 標準セットの リクエスト は約 10 vCPU / 22 GiB で、メモリの リミット は合計で約 55 GiB です。プロジェクトのクォータは、多くの場合、リクエストではなく リミット に対して設定されています。このクォータは、リミットに API ゲートウェイの分と、新旧の Pod が並行して実行されるアップグレード時の余裕を加えた量を許可する必要があります。limits.cpu: 64、limits.memory: 128Gi を申請してください。詳しくは サイジング ページを参照してください。
• 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）を設定してください。ボリュームのサイズは、サイジング の説明に従って決めます。

バックアップ

プラットフォームのボリュームには、CSI ボリュームスナップショットを使用できます。プロジェクト内の各 PVC の VolumeSnapshot を作成します。SQL Server、MongoDB、Kafka は、それぞれのツールでバックアップしてください。

OpenShift 固有の確認

次のコマンドを実行します。正常なインストールでは、どのコマンドも何も出力しません。

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 の対応 で説明しているとおり想定どおりです。出力にそれ以外の Pod がある場合は対処が必要です。

セキュリティコンテキスト制約に言及する FailedCreate イベントには、まだ固定のユーザー ID を設定しているコンポーネントの名前が示されます。そのコンポーネントを values の設定 の 2 つ目のループに追加し、インストールを再実行してください。