オンプレミス・コンテナに関するよくある質問（FAQ

IBM® Sterling Intelligent Promising コンテナ、 IBM OMS Gateway Operator、 IBM Sterling Intelligent Promising オペレーター、トラストストア、外部サービスなどに関連するよくある質問に対する回答をご覧ください。

演算子

Kubernetes クラスター（ Red Hat® OpenShift® Container Platform 例：vanilla Kubernetes ）や、EKS、 GKE、 AKSIBM Sterling Intelligent Promising などのクラウド管理クラスターにインストールできますか？: そう、 IBM Sterling Intelligent Promising はプラットフォームにとらわれないように設計されており、どんなCloud Native Computing Foundation (CNCF) Kubernetes クラスタにもインストールできる。

インターネットアクセスが利用できない制限された環境で、 KubernetesRed Hat OpenShift Container Platform またはクラスターを運用しています。この環境では Operator Lifecycle Manager （ OLM ）を使用できません。エアギャップ・セットアップのサポートはありますか？もしそうなら、 IBM Sterling Intelligent Promising: はい、エアギャップの設定は IBM Sterling Intelligent Promising でサポートされています。詳細については、オペレータユーティリティの概要を参照してください。

Sterling Intelligent Promising オンプレミス・コンテナ・デプロイメントには、 IBM Sterling Intelligent Promising Operator と IBM OMS Gateway Operator の 2 つの Operator が含まれる。 2つの異なるネームスペースにインストールすることは可能ですか？: いいえオペレーターを2つの異なるネームスペースにインストールすることはお勧めしません。詳細については、コマンドライン・インタフェース（CLI）を使用したオペレータのインストールを参照してください。

IBM Sterling Intelligent Promising Operator と IBM OMS Gateway Operator のバージョンを v1 から v2 にアップグレードしようとしているのですが、バージョン v2 の対応するサブスクリプションにインストールプランが作成されていないことに気づきました。通常の状況では、更新されたOperatorバージョンが利用可能になると、新しいインストール計画が自動的に生成されます。このシナリオで設置計画が作成されない理由は何でしょうか？

この問題は、監視ツール、セキュリティツール、またはサービスメッシュツールが、次のような場合に発生する可能性があります

init コンテナまたは
は、 Operator Lifecycle Manager ( OLM ) によって管理されるものを含むクラスタ内のポッドの動作を変更します。たとえば、カタログソースポッドなどです。

このようなインジェクションが発生した場合、Operatorイメージの更新を検出するカタログOperatorの機能を妨害する可能性があります。したがって、新しいバージョンが利用可能になったときに、インストールプランが自動的に作成されるのを防ぐことができます。

これを解決するためだ、

サードパーティツールがカタログソースポッドに init コンテナを変更したり注入したりしていないことを確認する。
init コンテナが削除されるか、インジェクションが無効になると、 OLM、更新されたOperatorバージョンが検出され、インストールプランが生成されます。

クラ Red Hat OpenShift Container Platform スターにオペレーターをインストールする際、オペレーターハブには最新リリース版と古いバージョンを含む複数のバージョンがリストされていることに気づきました。このシナリオでは、最新バージョンではなく、特定の古いバージョンのオペレーターをインストールすることは可能ですか？もしそうなら、正しいバージョンがインストールされ、適切に管理されるようにするには、どのような方法が推奨されますか？また、オペレーターをアップグレードする方法は？: はい、必要に応じて、オペレータの特定のバージョンをインストールすることを選択できます。しかし、ベストプラクティスは、最新の機能、改善、改良を利用するために、利用可能な最新バージョンを使用することです。常に最新の状態を保つことで、最高の互換性とサポート体験をお約束します。最新版の詳細については、新機能の「最新リリースにおけるオンプレミスコンテナの機能強化」セクションを参照してください。

オペレーターのアップグレードポリシーを「自動」に設定したので、新しいリリースが利用可能になるたびに、オペレーターは最新バージョンに更新されます。しかし、Operatorのバージョンは自動的にアップグレードされるが、Inventory、Promising、Utility、Optimizationなどのアプリケーションはまだ古いイメージバージョンを使用していることに気づいた。このシナリオでは、これは潜在的な問題なのでしょうか？どうすればこの問題を効果的に解決できるのか？: いいえいくつかのリリースとの後方互換性がサポートされている。ただし、Operatorと互換性のある画像を使用することをお勧めします。詳細については、オペレータのバージョン一覧とアプリケーションイメージタグを参照してください。

トラストストアとセキュリティ

Cassandra、 Kafka、 Elasticsearch などのミドルウェア・サービス用に複数のトラストストアがある。さて、この場合、各サービスが正しいトラスト・コンフィギュレーションを使用するように、複数のトラストストアをサポートするために SIPEnvironmentをどのように設定すればよいのでしょうか？複数のトラスト・ソース、例えば証明書やトラストストアを安全に管理するためのベスト・プラクティスにはどのようなものがありますか？

はい、 SIPEnvironmentは統一されたトラスト設定の使用をサポートしています。複数のトラストストアを扱うには、個々のトラストストアを、 Cassandra、 Kafka、 Elasticsearch、すべての必要なミドルウェア・サービスの証明書を含む単一のトラストストアに統合する必要がある。このマージされたトラストストアは、 Sterling Intelligent Promising に提供されなければならない。詳細については、セキュリティパラメータを参照してください。

トラストストアをマージする際には、以下の操作を完了させてください。

統合されたトラストストアに単一のパスワードを使用する。
このパスワードは、環境変数やシークレットなど、適切なコンフィギュレーションを通して、 Sterling Intelligent Promising 。
必要なすべての証明書が正しくインポートされ、信頼されていることを検証する。

信頼証明書を Sterling Intelligent Promising に提供するには、シークレット、 ConfigMaps,、マウントされたストレージを使用する3つの方法があると理解しています。ベストプラクティスとセキュリティの観点から、信頼証明書を Sterling Intelligent Promising に提供する最も適切な方法はどれですか？: セキュリティと運用のベストプラクティスの観点から、 Kubernetes シークレットを使用することが、 Sterling Intelligent Promising に信頼証明書を提供するための推奨される方法である。とはいえ、あなたの運用設定や制約に最も適した方法を選ぶのは自由だ。詳細については、 additionalMounts パラメータを参照してください。

いったんトラストストアが構築され、 Sterling Intelligent Promising のデプロイメントにマウントされると、 Sterling Intelligent Promising のアップグレードまたは再デプロイメントのたびにトラストストアを再作成または再生成する必要がありますか？トラストストアの再構築が必要な場合、どのような状況ですか？: いいえ。信頼構成が変更されない限り、 Sterling Intelligent Promising アップグレードまたは再デプロイメントのたびにトラストストアを再作成または再生成する必要はありません。トラストストアを再構築する条件の詳細については、トラストストアを再構築する条件を参照してください。

私の外部ミドルウェアサービスの1つ、例えば Cassandra、 Kafka、 Elasticsearch、信頼証明書の1つが期限切れになりました。 Sterling Intelligent Promising セットアップで期限切れの証明書を更新された証明書に安全に置き換えるには、どのような手順を踏めばよいですか？すべての依存コンポーネントまたはポッドが新しい証明書を正しくピックアップするようにするにはどうすればよいですか？: Secrets、 ConfigMaps,、またはマウントされたストレージなど、最初に使用したのと同じ方法で、更新した信頼証明書をマウントする。更新された証明書をマウントした後、トラストストアを再構築し、更新された証明書を含める。トラストストアを再構築するアノテーションの詳細については、 apps.sip.ibm.com/import-certificate-to-truststore アノテーションを参照のこと。

最終的なトラストストアは /sip-external-certs/client.truststore.jks で作成され、ストアタイプは常にJKSであることを知った。このトラストストアのタイプはJKSに固定されているのか、それとも PKCS12 のような別のタイプを使用するように柔軟に設定できるのか？: はい。利用可能なトラストストア・タイプのオプションは、 PKCS12 と JKSである。詳細については、セキュリティパラメータを参照してください。

Sterling Intelligent Promising デプロイメントの文脈で、 trustJavaCACerts フラグが用意されていることに気づいた。 trueまたはfalseに設定することの意味は？: サーバにデフォルトのJava TrustStore の証明書を信頼させたいかどうかに基づいて、 ssl.trust.trustJavaCACerts プロパティを true または false に設定する。詳細については、セキュリティパラメータを参照してください。

ミドルウェアまたは外部サービス

私は、 Cassandra、 Kafka、 Elasticsearch などのミドルウェア・サービスをセットアップするオペレーターを頼りにしている。ミドルウェアのデータを確実に保存し、再起動後も持続させるには？

ミドルウェア・サービスのセットアップをオペレータに依存している場合は、各ミドルウェア・サービスに永続ストレージを設定することが不可欠です。永続ストレージを設定することで、ポッドの再起動やノードの故障があってもデータが保持される。これは通常、各ミドルウェアコンポーネントの SIPEnvironment 内で storage プロパティを定義することで実現される。

例:

  storage:
    name: persist_PVC
     accessMode: ReadWriteMany
     capacity: 40Gi
     storageClassName: default

詳細については、外部サービスでのストレージとストレージのプロパティを参照してください。

Cassandra、 Kafka、 Elasticsearch などのミドルウェア・コンポーネントは、 Sterling Intelligent Promising オンプレミス・コンテナで公式にサポートされているバージョンは？

以下のミドルウェアのバージョンが公式にサポートされている。

Cassandra 4.1.0
Kafka 3.9.1
Elasticsearch 8.19.8

詳細については、「本番環境でのミドルウェアサービスのインストール」を参照してください。

SIPEnvironmentをインストールした後、 Cassandra、 Kafka、 Elasticsearch などのミドルウェア・サービスのエンドポイントを変更する必要があります。 Sterling Intelligent Promising のインストール後、ミドルウェアのコンフィギュレーションをアップデートする推奨の方法は？: Sterling Intelligent Promising 、インストール後にミドルウェア・サービスのエンドポイントを変更することはサポートされておらず、推奨されていません。 Sterling Intelligent Promising がインストールされると、各ミドルウェア・サービスには、プラットフォームでの役割に応じた運用データが入力される。これらのコンポーネントは協調して働き、そのデータはしばしば相互に依存した状態を保持する。どれか1つのミドルウェア・サービスのエンドポイントを変更すると、データの不整合、重要な状態情報の喪失、システムの不安定化につながる可能性がある。新しく構成されたミドルウェアは、他のコンポーネントが必要とする同期データや期待されるデータを持たない。

Sterling Intelligent Promising データ・ストレージを処理するためのミドルウェアの依存関係の1つとして、を公式にサポートしている。 Apache Cassandra 私は、 DataStage, が提供するクラウドネイティブの Cassandra -as-a-Service である Astra DB を、セルフホスティングの Cassandra デプロイメントに取って代わる可能性のあるものとして利用することを検討している。 Sterling Intelligent Promising は Astra DB と互換性がありますか？: いいえ、サポートされていません。

開発モードでは、 Sterling Intelligent Promising 、 Kafka トピックを自動作成することができますが、本番モードでは自動作成されないことを確認しました。この行動の背景には何があるのか？: 開発モードでは、 Sterling Intelligent Promising がオンデマンドで自動的に Kafka トピックを作成するように設定されているため、セットアップが簡素化され、テスト中の手作業が軽減される。これは、 Kafka のコンフィギュレーションと内部ロジックの緩和によって実現され、開発中の迅速な反復と使いやすさを促進するように設計されている。しかし、本番モードでは、 Kafka トピックの自動作成は、より厳格な制御、一貫性、および信頼性を強制するために、意図的に無効化される。運用時にトピックの自動作成を許可すると、トピックが誤って構成されたり、一貫性のないデータフローが発生したり、メッセージ処理で意図しない副作用が発生したりする可能性があります。したがって、本番環境では、 Kafka トピックは、デプロイのベストプラクティスに従って、事前に、またはプロビジョニングのメカニズムを通じて、明示的に作成および管理されることが期待される。

Sterling Intelligent Promising デプロイメント中に、 Kafka などのミドルウェアサービスへの接続に失敗すると、デプロイメント自体が失敗する。実際の配備が始まる前に問題を検出して対処できるように、初期段階で必要なすべてのミドルウェア・サービスへの接続性を検証する推奨方法はありますか？: はい。 apps.sip.ibm.com/validate-external-services-connections アノテーションを使用して、ミドルウェア・サービスの接続性を検証します。詳細については、「 Sterling Intelligent Promising 演算子で使用されるアノテーション」を参照してください。

SSL または TLS を無効化し、外部ミドルウェアサービスとの通信が非セキュアまたはプレーンテキストのチャネルで行われるように Sterling Intelligent Promising 設定することは可能ですか？: はい、設定パラメータを使用して、 SSL または TLS を無効にできます。詳細はコンフィギュレーション・パラメーターを参照。

自分の環境に Sterling Intelligent Promising 。その動作中、 Sterling Intelligent Promising は、 Kafka、 PostgreSQL,、 ActiveMQ, などのさまざまなミドルウェア・サービスと相互作用する。これらのサービスには、コンフィギュレーション・データやランタイム・データが入力される。その後、 Sterling Intelligent Promising はアンインストールされるが、ミドルウェア・サービスとそのデータはそのまま環境に残る。既存のミドルウェアのデータやコンフィギュレーションに関して、どのような点に留意すべきでしょうか？: Sterling Intelligent Promising は、アンインストール中にミドルウェア・サービスのデータのクリーンアップや削除を行いません。 Cassandra、 Kafka、 Elasticsearch などのサービスに保存されているすべてのコンフィギュレーションとランタイム・データは、 Sterling Intelligent Promising が環境から削除された後もそのまま残る。これらのミドルウェア・サービスを新規インストールや他のアプリケーションに再利用または再目的化する場合は、既存のデータを手動で確認し、クリーンアップすることが重要です。そのため、コンフリクトやコンフィギュレーションの陳腐化、予期せぬ動作を防ぐことができる。

Cassandra、 Kafka、 Elasticsearch などの外部ミドルウェア・サービスの1つについて、認証情報、ユーザー名、またはパスワードが変更される。これらの更新された認証情報を安全に使用するために、 Sterling Intelligent Promising コンテナのセットアップでどのような手順を踏むべきですか？すべての依存コンポーネントまたはポッドが新しい資格情報を正しくピックアップするようにするにはどうすればよいですか？

SIPEnvironmentで使用されるシークレットを新しい認証情報で更新する必要がある。詳細については、「シークレットの作成」を参照してください。次に、以下のアノテーションを追加して、すべてのポッドが再起動して更新されたクレデンシャルを拾うようにします。

apps.sip.ibm.com/restart

ストレージ

Sterling Intelligent Promising をインストールする前に、事前に必要なPVCを手動で作成する必要がありますか？必要なPVCを作成せずに Sterling Intelligent Promising: はい。詳細については、パーシステント・ボリューム・クレームを手動で作成するオプションを参照してください。

私の環境では、 Sterling Intelligent Promising のデプロイメントに動的なPersistent Volumes（PV）を使用する予定だ。デプロイメントの開始前に信頼証明書を使用できるようにする必要がある場合、デプロイメントの開始前に証明書が動的プロビジョニングボリュームに配置されていることを確認するにはどうすればよいですか? このシナリオを処理するために推奨されるアプローチはありますか？: Sterling Intelligent Promising 。アプリケーションはこの処理を自動的には行わないため、デプロイを開始する前に、信頼証明書が動的にプロビジョニングされたボリュームに配置されていることを手動で確認する必要があります。詳細については、 Kubernetes 永続ボリュームを手動で作成するを参照してください。

Sterling Intelligent Promising 、パーシステント・ボリューム（PV）には一体何が保存されているのでしょうか？永続的なストレージが必要なコンポーネントやデータは？: Sterling Intelligent Promising デプロイメントの永続ボリュームは、 Cassandra、 Kafka、 Elasticsearch などのミドルウェア・サービスのトラストストアとデータを格納するために使用されます。特に開発モードでは、ストレージが構成されている場合に使用されます。詳細については、 SIPEnvironmentカスタムリソースマニフェストを参照してください。

ロギング

私は Kubernetes クラスタセットアップで Sterling Intelligent Promising を使用しています。デフォルトでは、 Sterling Intelligent Promising ポッドからのログは標準出力で利用可能です。ログを収集する他の方法は？: Sterling Intelligent Promising は、を介したデフォルトのコンソールと、集中ログ収集のためのを含む2つのログモードをサポートしています。 stdout Kafka 詳細については、ログパラメータを参照してください。

アップグレード

Inventory Visibility、プロミシング、オプティマイザー、ユーティリティー・サービスなどのアプリケーション・サービスをデプロイするセットアップにおいて、特定のコンポーネントのデフォルト・イメージ・バージョンをオーバーライドまたは変更するにはどうすればよいですか？

画像タグとダイジェストを使用して、以下の3つのレベルでサービスの画像バージョンをオーバーライドできます。

SIP環境またはグローバルレベル
サービス・グループ・レベル
アプリケーションサーバーまたはバックエンドサーバーレベル

詳しくは、画像設定の優先順位を参照してください。

オペレーターのバージョンとアプリケーション・イメージのバージョンが同期していない場合、互換性の問題や予期せぬ動作につながる可能性はありますか？また、スタック全体の安定性と互換性を確保するために、アップグレードをどのように管理すべきですか?: はい。各新リリースには、Operatorとアプリケーション・イメージの両方にわたって調整された変更が含まれる可能性があるからです。ベストプラクティスは、安定性と互換性を確保するために、Operatorとアプリケーションイメージを最新のサポートバージョンに保つことです。詳細については、オペレータのバージョン一覧とアプリケーションイメージタグを参照してください。

最近のアップグレードの際、 Sterling Intelligent Promising オペレーターを最新バージョンに更新しようとした。しかし、アップグレードは予期せぬ問題で失敗し、環境は不安定になった。ビジネスの継続性を確保するため、アップグレードの問題を調査している間、システムが期待通りに機能し続けられるように、以前の作業オペレーターのバージョンにロールバックしたい。どうすればいいですか？: アプリケーションイメージが更新されない限り、 Sterling Intelligent Promising Operator の以前のバージョンにロールバックできます。ロールバックする前に、互換性の問題につながる可能性があるため、新しい Operator に依存するバージョンにアップグレードされたアプリケーションコンポーネントがないことを確認してください。このようなシナリオを避けるために、アップグレードはまず低環境で徹底的にテストすることをお勧めします。本番環境へのアップグレードは、すべてが検証されてから行ってください。低環境であっても、何らかの問題が発生した場合は、速やかに報告し、サポートに連絡して指導を受けるのが最善である。

最近のアップグレードの際、アプリケーション・イメージを最新バージョンに更新しようとした。しかし、アップグレードは予期せぬ問題で失敗し、環境は不安定になった。ビジネスの継続性を確保するため、アップグレードの問題を調査している間、システムが期待通りに機能し続けられるように、以前の動作するアプリケーション・イメージにロールバックしたい。どうすればいいですか？: アプリケーションのアップグレードは、データベースやその他の内部コンポーネントに不可逆的な変更を伴う可能性があるため、アプリケーション・イメージが新しいバージョンにアップグレードされた後は、アプリケーション・イメージを古いバージョンにロールバックすることはサポートされていません。このような事態を避けるため、アップグレードはまず低環境で十分にテストすることをお勧めします。本番環境へのアップグレードは、安定性と互換性を確認してから行ってください。テスト環境であっても、問題が発生した場合は直ちに報告し、それ以上先に進む前にサポートに連絡して指導を受けてください。

証明書管理

OMSゲートウェイ層において、デフォルトの証明書を置き換える形で、任意の TLS カスタム証明書を使用するようSIPEnvironment環境を設定する必要があります。どうすればそれを実現できるのか？: はい、OMSゲートウェイ層でカスタム TLS 証明書を設定できます。詳細については、 OMS Gateway のカスタム TLS 証明書構成を参照してください。

共有証明書またはデフォルト証明書に依存する代わりに、特定のサービスにカスタム証明書を使用するように SIPEnvironmentを設定できますか?: いいえ。 SIPEnvironmentは、個々のサービスレベルでのカスタム証明書の構成をサポートしていません。カスタム証明書は、ゲートウェイまたはイングレスレベルでのみ適用できますが、配備内の特定のサービスには適用できません。

SIPEnvironmentは、証明書の有効期限切れ、ローテーション、および更新の自動処理をサポートしていますか?: はい。 CertificateManager は、証明書再生の自動化、所有権管理の改善、有効期限追跡などに重点を置き、スムーズで中断のない運用を保証する。証明書の自動更新、ダウンタイムゼロを保証する証明書の再生成、一元化されたCAシークレット、タイムリーなステータス追跡などの機能を備えている。詳細については、 CertificateManager の主な機能と利点をご覧ください。

Sterling Intelligent Promising コンテナ・サービスをカスタム・ドメイン（ sip.example.com ）を通して公開し、統合や外部アクセスを行う必要がある場合。これをサポートするように SIPEnvironmentを設定するにはどうすればよいですか?: カスタム・ドメインを構成するには、 common 構成の ingress セクション内に customDomains プロパティを定義します。詳細については、 SIPEnvironment における customDomains の設定を参照してください。

回復力と拡張性

現在、開発環境またはステージング環境に Sterling Intelligent Promising をシングルクラスターデプロイしている。本番環境に移行する準備として、高可用性、フォールト・トレランス、およびリージョンやデータ・カンター間でのディザスタ・リカバリを確保するために、マルチクラスター設定に移行したいと考えています。どうすればいいのでしょうか？: Sterling Intelligent Promising コンテナのマルチクラスタ・サポートを使用して、単一クラスタからマルチクラスタ・セットアップに移行する。詳細については、「単一クラスターから複数クラスターへの移行」を参照してください。

一般

製品が提供するデフォルトのゲートウェイ認証ではなく、別の認証システムを使用したい。それは可能ですか？はい」の場合、内蔵認証を無効にして独自のシステムを使用するにはどうすればよいですか？: はい、組み込みのゲートウェイ認証を無効にして、独自の認証システムを統合することができます。詳細については、 omsGateway パラメータを参照してください。

製品のインストール中、オンボーディングジョブは Kubernetes ジョブとして実行されます。これらのジョブが失敗した場合、インストールは続行されません。問題を解決した後、これらのジョブを再開するにはどうすればよいですか？ Kubernetes、失敗したジョブは自動的に再開されません: 失敗したジョブは、 apps.sip.ibm.com/restart アノテーションを使用して再開できます。詳細については、「 Sterling Intelligent Promising 演算子で使用されるアノテーション」を参照してください。

シークレット、 configMaps,、ストレージボリュームといったリソースの一部が、クラスタ全体や意図しないワークロードに公開されることなく、意図したポッドやコンテナだけにマウントされるようにしなければならない。セキュリティ、リソースの分離、クリーンな構成管理を維持するために、どのようなベストプラクティスに従うべきか？: additionalMounts 、ラベルに基づいてリソースを動的にマウントすることができます。詳細については、 additionalMounts パラメータを参照してください。

開発モードで SIPEnvironmentをデプロイし、現在問題に直面しています。デバッグモードを有効にして、より詳細なログを収集したい。効果的なトラブルシューティングのために、どのような方法が推奨されますか？: はい、デバッグモードでロギングを有効にすることができます。詳細については、ログパラメータを参照してください。

SIPジョブのステータス Error に「pods」と表示されています。心配したほうがいいでしょうか？

そうではない場合もあります。ジョブの初回実行中に、ポッドの起動に失敗することがありますが、これは想定内の動作です。ポッドに障害が発生した場合、 Kubernetes ジョブは設定された回数（ jobBackoffLimit デフォルト：4回）に基づき、自動的に再試行を行います。ジョブは、ポッドが正常に完了するか、再試行回数の上限に達するまで、再試行を続けます。

少なくとも1つのポッドが「表示中」の状態である限り Completed、ジョブ全体は成功したとみなされ、SIPオペレーターは通常通り処理を続行します。先ほどの「Error」ポッドは再試行の試みであるため、無視しても問題ありません。どのポッドもに到達せず、すべてのポッドがを示している場合 CompletedError 、そのジョブは再試行回数の上限に達したため、としてマークされます Failed。以下のアノテーションを使用すると、失敗したジョブを再実行できます：

apps.sip.ibm.com/restart: 'true'

詳細については、「 Sterling Intelligent Promising 演算子で使用される注釈」を参照してください。