このドキュメントでは、ドメインをデプロイするためのドメイン・ホームのソース・タイプと、各タイプに適したイメージの作成について説明します。
オペレータを使用してドメインからWebLogic Serverインスタンスを起動する場合、次のWebLogicドメイン・ホーム・ソース・タイプを選択できます:
Domain in Imageドメイン・ホームのソース・タイプは、WebLogic Kubernetes Operatorバージョン4.0では非推奨です。 Oracleでは、必要に応じてDomain on PVまたはModel in Imageを選択することをお薦めします。
domain.spec.domainHomeSourceType属性をFromModelに設定します。Domain in Image: ノート: Domain in Imageドメイン・ホームのソース・タイプは、WebLogic Kubernetes Operatorバージョン4.0では非推奨です。 Oracleでは、必要に応じてDomain on PVまたはModel in Imageを選択することをお薦めします。
domain.spec.domainHomeSourceType属性をImageに設定します。domain.spec.domainHomeSourceType属性をPersistentVolumeに設定します。domain.spec.configuration.initialDomainOnPVセクションを指定して、オペレータが初期ドメイン・ホームを作成するための情報を指定します。ドメインごとに異なるドメイン・ホーム・タイプを使用できます。同じKubernetesクラスタまたはネームスペースに異なるドメイン・ホーム・タイプを持つドメインを使用することに制限はありません。
Model in Imageが最も一般的な選択肢であるドメイン・ホーム・ソース・タイプごとに利点がありますが、1つのタイプをお客様のニーズに合う可能性がある様々なクラウド・プロバイダの技術的な制限もあります。 次の表に、タイプを比較します:
| Domain on PV | Domain in Image | Model in Image |
|---|---|---|
| すべてのドメインのすべてのサーバーに同じ標準WebLogic Serverイメージを使用できます。 | ドメインごとに異なるイメージが必要ですが、そのドメイン内のすべてのサーバーで同じイメージが使用されます。 | ドメインごとに同じイメージを使用できますが、必要なdomainUIDは異なり、構成も異なる場合があります。 |
| イメージには状態が保持されないため、これらのイメージから作成されたコンテナは完全に破棄されます(ペットではありません)。 | ランタイム状態はイメージに保持しないでくださいが、アプリケーションと構成は保持されます。 | ランタイム状態をイメージに保持しないでください。 アプリケーションおよび構成は可能です。 |
| 新しいアプリケーションは、管理コンソールまたはWLSTを使用してデプロイできます。 | アプリケーション更新をデプロイする場合は、新しいイメージを作成する必要があります。 | アプリケーション更新をデプロイする場合は、新しいイメージを作成する必要があります。オプションで、WebLogicインストールを含まない「補助イメージ」にできます。 |
| 構成のオーバーライドを使用して、ドメイン構成をデプロイする前に変更できますが、「制限事項」があります。 | Domain on PVと同じです。 | モデル・ファイルをConfigMapにデプロイして、ドメインをデプロイする前にミュートできます。 モデル・ファイルの構文は、構成オーバーライド構文よりもはるかに単純でエラーが発生しにくく、構成オーバーライドとは異なり、データ・ソースおよびJMSモジュールを直接追加できます。 |
| 管理コンソールまたはWLSTを使用して、実行時にWebLogicドメイン構成を変更できます。 構成のオーバーライドおよび「新しいオーバーライドを配布」を実行中のサーバーに変更することもできますが、動的でない構成属性は、サーバーの起動時にのみ変更でき、変更によっては完全なドメインの再起動が必要になる場合があります。 | 構成のオーバーライドおよび「新しいオーバーライドを配布」を実行中のサーバーに変更することもできますが、動的でない構成属性は、サーバーの起動時にのみ変更でき、変更によっては完全なドメインの再起動が必要になる場合があります。 変更は一時的であり、サーバーの再起動時に失われるため、これらのドメインには管理コンソールまたはWLSTを使用しないでください。 | 「ランタイム更新」で提供されているモデルYAMLファイル・スニペットを使用して、実行時に構成を変更できます(構成オーバーライドよりも指定が非常に簡単です)。ただし、動的でない構成属性は、サーバーが再起動(ロール)された場合にのみ変更され、一部の変更で完全なドメイン再起動が必要になる場合があります。 変更は一時的であり、サーバーの再起動時に失われるため、これらのドメインには管理コンソールまたはWLSTを使用しないでください。 |
| ログは自動的に永続ストレージに配置され、ポッドのstdoutに送信されます。 | ログはコンテナに保持され、デフォルトでポッドのログ(stdout)に送信されます。 ログのロケーションを変更するには、ドメインlogHomeEnabledをtrueに設定し、logHomeを使用して目的のディレクトリを構成します。 |
Domain in Imageと同じです。 |
| パッチは、イメージを変更してドメインをローリングするだけで適用できます。 | パッチを適用するには、ドメイン固有のイメージを更新し、パッチの性質に応じてドメインを再起動またはロールする必要があります。 | 専用「補助イメージ」を使用してモデル・アーティファクトを提供する場合はDomain on PVと同じで、それ以外の場合はDomain in Imageと同じです。 |
| 多くのクラウド・プロバイダでは、可用性ゾーン間で共有される永続ボリュームが提供されないため、単一の永続ボリュームを使用できない場合があります。 一部の種類のボリューム・レプリケーション・テクノロジまたはクラスタ・ファイル・システムを使用する必要がある場合があります。 | コンテナに格納して状態を維持しない場合は、各ポッドにドメインの独自のコピーがあるため、可用性ゾーン間のボリューム・レプリケーションについて心配する必要はありません。 WebLogicレプリケーションは、オンライン構成変更の伝播を処理します。 | Domain in Imageと同じです。 |
| CI/CDパイプラインは、変更を有効にするためにライブ・ドメイン・ディレクトリに対してWLSTを実行する必要があるため、より複雑な場合があります。 | CI/CDパイプラインは、イメージ内にドメイン全体を作成でき、ドメインの永続的なコピーについて心配する必要がないため、より簡単です。 | CI/CDパイプラインは、ドメイン・ホームを生成する必要がないため、さらに単純です。 オペレータは、指定されたモデルに基づいてドメイン・ホームを作成します。 |
| 管理および格納するイメージが少なくなるため、ストレージおよびネットワークが大幅に節約される可能性があります。 | このアプローチでは、より多くのイメージを管理および格納する必要があります。 | 「補助イメージ」アプローチを使用する場合を除き、Domain in Imageと同じです。 補助イメージでは、単一のイメージを使用して、WebLogicインストール(Domain on PVと同様)と、WebLogic構成およびアプリケーションを含む1つ以上の特定の専用イメージを分散できます。 |
| 標準のOracle提供のイメージ、または少なくとも少数の自己作成イメージ(パッチがインストールされている場合など)を使用できます。 | イメージをビルドおよび保守するプロセスを設定するために、さらに作業が必要になる場合があります。 | Domain in Imageと同じです。 |
選択したドメイン・ホームのソース・タイプの詳細は、次の「ドキュメント」を参照してください。