このドキュメントは、KubernetesでのWebLogicドメインおよびクラスタの管理の概要です。
ドメイン・リソースは、WebLogicドメイン構成、WebLogicインストール、「イメージ」、およびドメインの実行に必要なその他のすべてのものを参照します。 WebLogicドメイン構成内のWebLogicクラスタは、オペレータ4.0から、ドメイン・リソースに加えてクラスタ・リソースにオプションで関連付けることができます。 詳細については、「ドメインおよびクラスタ・リソース」を参照してください。
WebLogicドメインは、永続ボリューム(Domain on PV)、コンテナ内のみ(Model in Image)またはイメージ(Domain in Image)に配置できます。 それぞれの説明については、「ドメイン・ホーム・ソース・タイプの選択」を参照してください。 それぞれの例については、「WebLogic Kubernetes Operatorサンプル」を参照してください。
Domain in Image 「ドメイン・ホーム・ソース・タイプ」は、WebLogic Kubernetes Operatorバージョン4.0では非推奨です。 Oracleでは、必要に応じてDomain on PVまたはModel in Imageを選択することをお薦めします。
特定のパッチ・セットを選択したり、特定の構成またはアプリケーションがデプロイされたドメインを作成するなど、独自のコンテナ・イメージを作成する場合は、ドメイン・カスタム・リソースを手動で作成してドメインをデプロイできます。 このプロセスは、「このサンプル」に記載されています。
ノート: 基本を理解した後、重要な考慮事項およびリソース名の制限を確認することをお薦めします。
ドメインYAMLファイルをデプロイする前に、Domain on PV、Domain in ImageおよびModel in ImageのWebLogicドメイン構成を変更できます:
ドメインが永続ボリューム上にある場合は、WLSTまたはWDTを使用して構成を変更できます。
Domain in ImageおよびDomain on PVの場合は、「構成のオーバーライド」を使用できます。
構成オーバーライドを使用すると、元のconfig.xmlまたはシステム・リソースのXMLファイルを変更せずに構成を変更でき、Kubernetesシークレットから値をインジェクトできるようにオーバーライドのパラメータ化がサポートされます。 たとえば、シークレットに格納されているデータベース・ユーザー名、パスワードおよびURLをインジェクトできます。 ただし、構成が「サポートされていません」をオーバーライドするシナリオに注意してください。
Model in Imageには、「ランタイム更新」を使用します。
ライフサイクル操作は、WebLogic Servers、クラスタまたはドメインで実行できます。 これには、ドメイン、クラスタまたは個々のサーバーの起動、停止、ローリングに加え、失敗の検出と再試行動作のチューニングが含まれます。 「ドメインのライフサイクル」を参照してください。
オペレータを使用すると、様々な方法でクラスタのスケーリングを開始できます:
kubectlを使用したクラスタ・リソースの編集scaleコマンドの使用「ドメインのライフサイクル・スケーリング」を参照してください。
オペレータは、ドメイン処理中にキー・ポイントでKubernetesイベントを生成します。 詳細は、「ドメイン・イベント」を参照してください。
WLST、コンソール、T3またはロード・バランサを使用してドメインにアクセスしたり、Prometheus-compatibleメトリクスをエクスポートするには、「ドメインへのアクセスと監視」を参照してください。
ログ・ファイルのロケーションとローテーションを調整するには、「ログ・ファイル」を参照してください。
オペレータまたはドメイン・ログ・ファイルをエクスポートするには、「エラスティック・スタック」の例を参照してください。
Kubernetesでは、一部のリソース・タイプの名前が、「DNSラベル名」およびRFC 1123で定義されているDNSラベル標準に準拠している必要があります。 この要件により、これらのリソースの名前に使用できる文字が制限され、これらの名前の長さも63文字以下に制限されます。
次に、ドメイン・リソースのデプロイ時にオペレータが生成するそのようなKubernetesリソースのリストを、それらの名前の構築方法も含めて示します。
<domainUID>-<introspectorJobNameSuffix>という名前のドメイン・イントロスペクタ・ジョブ。 デフォルトのサフィクスは-introspectorで、オペレータのHelm構成introspectorJobNameSuffixを使用してオーバーライドできます(「WebLogicドメイン管理」を参照)。 <domainUID>-<serverName>という名前の各WebLogic ServerのClusterIPタイプ・サービスおよびポッド。<domainUID>-cluster-<clusterName>という名前の各WebLogicクラスタのClusterIPタイプ・サービス。<domainUID>-<adminServerName>-<externalServiceNameSuffix>という名前のWebLogic管理サーバー用のオプションのNodePortタイプ・サービス(外部サービスとも呼ばれます)。 デフォルトのサフィクスは-extで、オペレータのHelm構成externalServiceNameSuffixを使用してオーバーライドできます(「WebLogicドメイン管理」を参照)。 オペレータは、これらのリソースがKubernetesの制限に違反しないように、特定の検証チェックおよび変換を行います。
A-Z, a-z, 0-9, -または_の文字のみを含めることができ、英数字で開始および終了する必要があります。 ポッド名とサービス名を生成する場合、オペレータは構成した名前を小文字に変換し、アンダースコア(_)ごとにハイフン(-)に置き換えることに注意してください。 domainUIDは45文字以下である必要があります。ドメイン・リソースまたはWebLogicドメイン構成が制限に違反すると、ドメインの起動に失敗し、実際の検証エラーがドメイン・リソースのステータスで報告されます。
Kubernetesで実行するWebLogicドメインについては、次の重要な考慮事項に注意してください:
ドメイン・ホームのロケーション: WebLogicドメイン・ホームのロケーションは、ドメインYAMLファイルdomainHome(指定されている場合)によって決定されます。指定されていない場合、デフォルトのロケーションはdomainHomeSourceType設定によって決定されます。
domainHomeフィールドが指定されておらず、domainHomeSourceTypeがImage (デフォルト)の場合、オペレータはドメイン・ホームが/u01/oracle/user_projects/domains/の下のディレクトリであるとみなし、ドメインが見つからないか複数のドメインが見つかった場合はエラーを報告します。domainHomeフィールドが指定されておらず、domainHomeSourceTypeがPersistentVolumeの場合、オペレータはドメイン・ホームが/shared/domains/DOMAIN_UIDであるとみなします。domainHomeフィールドが指定されておらず、domainHomeSourceTypeがFromModelの場合、オペレータはドメイン・ホームが/u01/domains/DOMAIN_UIDであると想定します。Oracleは、WebLogicドメイン・ホーム(domainHomeSourceTypeはImage)を含むイメージをプライベートとしてレジストリ(Oracle Cloud Infrastructure Registry、GitHub Container Registryなど)に格納することを強くお薦めします。 WebLogicドメインを含むコンテナ・イメージには、外部リソース(データ・ソース・パスワードなど)へのアクセスに使用されるキーや資格証明などの機密情報が含まれます。 詳細は、「コンテナ・イメージ保護されたWebLogicドメイン」を参照してください。
ログ・ファイルのロケーション: オペレータは、WebLogic Server、ドメインおよびイントロスペクタ・ログのロケーションを自動的にオーバーライドできます。 これは、Domain logHomeEnabledフィールドが明示的にtrueに設定されている場合、またはlogHomeEnabledが設定されておらず、domainHomeSourceTypeがPersistentVolumeに設定されている場合に発生します。 オーバーライドする場合、ログのロケーションはlogHome設定で指定されたロケーションになります。 ログ・ファイルのチューニングの詳細は、「ログ・ファイル」を参照してください。
リスニング・アドレスのオーバーライド: オペレータは、すべてのWebLogicドメイン・デフォルト、SSL、管理者またはカスタム・チャネルのリスニング・アドレスを自動的にオーバーライドします(構成のオーバーライドを使用)。 これらは、domainUIDの後にハイフンが続き、サーバー名、すべて小文字およびアンダースコアがハイフンに変換されます。 たとえば、domainUID=domain1でWebLogic Server名がAdmin_Serverの場合、そのリスニング・アドレスはdomain1-admin-serverになります。
ドメイン、クラスタ、サーバーおよびネットワーク・アクセス・ポイント名: WebLogicドメイン、クラスタ、サーバーおよびネットワーク・アクセス・ポイント(チャネル)名には、A-Z, a-z, 0-9, -または_の文字のみを含める必要があり、適切な長さに保つ必要があります。 これにより、KubernetesリソースおよびDNS1123のネーミング要件を満たすリソース名を安全に作成できます。 詳細は、「Kubernetesリソース名の制限を満たす」を参照してください。
ノード・ポート: WLSTアクセスを許可するために、管理ポートやT3チャネルなどのNodePortを使用してKubernetesクラスタの外部にWebLogicチャネルを公開する場合は、各チャネルにKubernetesクラスタ全体で一意のポート番号を割り当てる必要があります。 Kubernetesクラスタ内の各WebLogicドメインで管理ポートを公開する場合は、それぞれのポート番号が異なる必要があります。 これは、NodePortsを使用してKubernetesクラスタ外でチャネルを公開するために必要です。
Kubernetes NodePortを使用して管理チャネル、RMIチャネルまたはT3対応チャネルを公開すると、セキュアでない構成を作成できます。 一般に、HTTPプロトコルのみを外部で使用可能にする必要があり、この公開は通常、内部(NodePort以外の)サービスにアクセスできる外部ロード・バランサを設定することで実現されます。 詳細は、「WebLogic T3および管理チャネル」を参照してください。
ホスト・パス永続ボリューム: hostPath永続ボリュームを使用する場合は、クラスタ内のすべてのワーカー・ノードで使用可能であり、WebLogic Serverデプロイメント内のすべてのコンテナ/ポッドに対するread/write/many権限を持っている必要があります。 多くのクラウド・プロバイダのボリューム・プロバイダは、可用性ゾーン全体のボリュームをサポートしていない可能性があることに注意してください。 この制限を回避するには、NFSまたはクラスタ化されたファイルシステムを使用できます。
セキュリティ上のノート: USER_MEM_ARGS環境変数は、すべてのWebLogic ServerポッドおよびWebLogicイントロスペクション・ジョブで-Djava.security.egd=file:/dev/./urandomにデフォルト設定されます。 serverPod構成の下にあるenv属性を使用して、ドメインまたはクラスタのYAMLファイルの別の値に明示的に設定できます。
JVMメモリーおよびJavaオプションの引数: 次の環境変数を使用して、WebLogic Server管理対象サーバーとノード・マネージャ・インスタンスの両方のJVMメモリーおよびJavaオプションをカスタマイズできます:
JAVA_OPTIONS - WebLogic Serverを起動するためのJavaオプションUSER_MEM_ARGS - WebLogic Serverを起動するためのJVMメモリー引数NODEMGR_JAVA_OPTIONS - ノード・マネージャ・インスタンスを起動するためのJavaオプションNODEMGR_MEM_ARGS - ノード・マネージャ・インスタンスを起動するためのJVMメモリー引数詳細は、「JVMメモリーおよびJavaオプション環境変数」を参照してください。
次の機能は、このリリースでは動作保証またはサポートされていません:
Kubernetes環境でサポートされているWebLogic Serverの機能の最新情報は、My Oracle Support Doc ID 23492 28.1を参照してください。