構成のオーバーライドは、Domain in ImageおよびDomain on PVドメインと組み合せてのみ使用できます。 Model in Imageドメインの場合は、かわりに「Model in Imageランタイムの更新」を使用します。
構成オーバーライド(「状況構成」とも呼ばれる)を使用して、ドメインの実際のconfig.xmlまたはシステム・リソース・ファイルを変更せずに、Domain in ImageまたはDomain on PVドメインのWebLogicドメイン構成をカスタマイズします。 たとえば、JDBCデータ・ソースのXMLモジュールのユーザー名、パスワードおよびURLを、ローカル・データベースを参照するようにオーバーライドできます。
ノート: Domain in Image ドメイン・ホーム・ソース・タイプは、WebLogic Kubernetes Operatorバージョン4.0では非推奨です。 Oracleでは、必要に応じてDomain on PVまたはModel in Imageを選択することをお薦めします。
オーバーライドを使用して、QAから本番に移行するとき、異なるサイトにデプロイされるとき、または同じサイトに複数回デプロイされるときに、ドメインをカスタマイズできます。 オペレータ・バージョンの3.0.0から、実行中のWebLogic Serverインスタンスの構成オーバーライドを変更して、これらの新しいオーバーライドを動的に有効にできるようになりました。 オーバーライドによって変更できるWebLogic構成属性に対する「制限事項」があり、サーバーの実行中に変更できるのは動的構成のMBean属性に対する変更のみです。 その他の変更、特に動的でないMBeansに対するオーバーライドは、サーバーの起動時または再起動時に適用する必要があります。
2.0を含むversion.txtという名前のファイル。configuration.overridesConfigMapフィールドをこのConfigMapの名前に構成します。configuration.secretsを設定します。これらのステップの詳細は、「段階的なガイド」を参照してください。
introspectVersionフィールドの値を変更して、「イントロスペクションの開始」を実行できます。optconfigディレクトリに配置します。optconfigディレクトリから自動的にロードします。config.xmlまたはシステム・リソースのXMLファイルで指定された値のかわりに、オーバーライド・ファイルのオーバーライド値を使用します。optconfigディレクトリ内のファイルを監視します。 これは、動的構成MBean属性に関連する構成オーバーライドの変更に対してのみ機能します。 ランタイム・フローの詳細は、「内部設計フロー」を参照してください。
構成のオーバーライドは、Domain in ImageおよびDomain on PVドメインと組み合せて使用できます。 Model in Imageドメイン(3.0.0で導入)の場合は、かわりに「Model in Imageランタイムの更新」を使用します。
WebLogicドメイン・ホームのoptconfigディレクトリに、オペレータによって配置されていない構成オーバーライドXMLファイルを含めることはできません。 このディレクトリ内の既存の構成オーバーライドXMLファイルはすべて削除され、オペレータ・オーバーライド・テンプレート(存在する場合)に置き換えられます。
JDBC、JMSまたはWLDF (診断)モジュールをオーバーライドする場合は、元のモジュールをそれぞれドメイン・ホームのconfig/jdbc、config/jmsおよびconfig/diagnosticsディレクトリに配置する必要があります。 これらは、これらのタイプのモジュールのデフォルトのロケーションです。
オーバーライドの一般的な属性は次のとおりです:
MaxMessageSizeなど)すでに実行中のWebLogic Serverインスタンスに新規または変更された構成のオーバーライドを配布する方法については、「構成のオーバーライド」を参照してください。
重要: オペレータは、次の領域での顧客指定のオーバーライドをサポートしていません。
listen address、portおよびenabledフィールドdomain.spec.dataHomeが設定されている場合、デフォルトまたはカスタムのファイル・ストア・ディレクトリ具体的には、次の場合にカスタム・オーバーライドを使用しないでください:
Enabled、リスニング・アドレスおよびポートdomain.spec.logHome設定を使用し、domain.spec.logHomeEnabledがtrueに設定されていることを確認してくださいdomain.spec.dataHomeが設定されている場合、デフォルトまたはカスタムのファイル・ストア・ディレクトリネットワーク・アクセス・ポイントのpublicまたはexternalのアドレスとポートをオーバーライドすることもできます。 また、JMX (MBean)またはオンラインWLSTへの外部アクセスでは、ネットワーク・アクセス・ポイントの内部ポートと外部ポートが一致している必要があります(JMS、RMIまたはEJBへの外部T3またはHTTPトンネリング・アクセスでは、ポートの一致は必要ありません)。
サポートされていないオーバーライドを使用した場合の動作は未定義です。
オペレータは、オペレータのイントロスペクション・フェーズで、顧客が指定した構成オーバーライドとオペレータが生成したオーバーライドを組み合せて、最終構成オーバーライドを生成します。 これらのオーバーライドは、WebLogic Serverインスタンスの起動時または再起動時に使用されます。 オペレータ・バージョン3.0.0以降、これらのオーバーライドも配布でき、すでに実行中のWebLogic Serverインスタンスに適用されます。
Domain on PVでは、管理コンソールまたはWLSTを含む従来の管理トランザクションを使用してWebLogicドメイン構成を変更する機能を組み合せて、繰返しイントロスペクションを開始し、更新された構成オーバーライドを配布できます。 この組合せでは、新しいWebLogicクラスタの定義や、管理対象サーバー・クラスタ・メンバーの即時起動などのユースケースがサポートされます。
オーバーライドは、「構成のオーバーライド」と呼ばれる組込みのWebLogic機能を利用します。この機能は、非公式には「状況構成」と呼ばれます。 構成オーバーライドは、WebLogic config.xmlの構造によく似たXML形式のファイルと、システム・リソース・モジュールのXMLファイルで構成されます。 また、これらのファイルの属性フィールドには、add、replaceおよびdelete動詞を埋め込んで、フィールドに必要なオーバーライド・アクションを指定できます。
このオペレータには、WebLogicの組込み構成オーバーライド機能とは異なるオーバーライド・テンプレートのファイル名形式が必要です。 テンプレートをドメイン・ホームのoptconfigディレクトリに移動するときに、名前が構成オーバーライド機能で必要な形式に変換されます。 次の表では、形式について説明します:
| 元の構成 | 必須オーバーライド名 |
|---|---|
config.xml |
config.xml |
| JMSモジュール | jms-MODULENAME.xml |
| JDBCモジュール | jdbc-MODULENAME.xml |
| 診断モジュール | diagnostics-MODULENAME.xml |
MODULENAMEは、元のconfig.xmlファイルで定義されているシステム・リソースのMBean名に対応している必要があります。 オーバーライドを使用して新しいモジュールを追加することはできません。 新しいモジュールを設定するためにオーバーライドが必要な場合は、元の構成でオーバーライド可能なスケルトン・モジュールを指定します。
オーバーライド・テンプレートでは、構成オーバーライド機能に必要な正確なスキーマを定義する必要があります。 スキーマは、オーバーライドするファイル・タイプによって異なります。
config.xml
<?xml version='1.0' encoding='UTF-8'?>
<d:domain xmlns:d="http://xmlns.oracle.com/weblogic/domain"
xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
xmlns:s="http://xmlns.oracle.com/weblogic/situational-config">
...
</d:domain>
jdbc-MODULENAME.xml
<?xml version='1.0' encoding='UTF-8'?>
<jdbc:jdbc-data-source xmlns:jdbc="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:f="http://xmlns.oracle.com/weblogic/jdbc-data-source-fragment"
xmlns:s="http://xmlns.oracle.com/weblogic/situational-config">
...
</jdbc:jdbc-data-source>
jms-MODULENAME.xml
<?xml version='1.0' encoding='UTF-8'?>
<jms:weblogic-jms xmlns:jms="http://xmlns.oracle.com/weblogic/weblogic-jms"
xmlns:f="http://xmlns.oracle.com/weblogic/weblogic-jms-fragment"
xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
...
</jms:weblogic-jms>
diagnostics-MODULENAME.xml
<?xml version='1.0' encoding='UTF-8'?>
<wldf:wldf-resource xmlns:wldf="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:f="http://xmlns.oracle.com/weblogic/weblogic-diagnostics-fragment"
xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
...
</wldf:wldf-resource>
オペレータは、オーバーライド・テンプレートへのマクロの埋込みをサポートしています。 これにより、テンプレートでは、異なるデプロイメントに対して異なるURL、ユーザー名およびパスワードを指定するなど、複数のユースケースを柔軟に処理できます。
環境変数マクロとシークレット・マクロの2タイプのマクロがサポートされています:
環境変数マクロの構文は${env:ENV-VAR-NAME}で、サポートされている環境変数はDOMAIN_UID, DOMAIN_NAME, DOMAIN_HOMEおよびLOG_HOMEです。
シークレット・マクロの構文は、${secret:SECRETNAME.SECRETKEY}および${secret:SECRETNAME.SECRETKEY:encrypt}です。
シークレット・マクロのSECRETNAMEフィールドはKubernetesシークレットの名前を参照する必要があり、SECRETKEYフィールドはそのシークレット内のキーを参照する必要があります。 たとえば、値scottを含むusernameという名前のキーを使用してdbuserという名前のシークレットを作成した場合、テンプレートがWebLogic Serverインスタンス・ポッドにコピーされる前に、マクロ${secret:dbuser.username}がscottに置き換えられます。
セキュリティ上のノート: シークレット・マクロで:encryptサフィクスを使用して、(プレーン・テキスト値のままにするのではなく) WebLogic WLST encryptコマンドで置換値を暗号化します。 これは、データ・ソースのpassword-encryptedフィールドなど、暗号化された値を必要とするMBean属性をオーバーライドする場合に役立ちます。また、オペレータがドメイン・ホームに配置した構成ファイルをカスタム・オーバーライドしてもプレーン・テキストでパスワードが公開されないようにする場合にも役立ちます。
次の各アイテムでベスト・プラクティスを確認し、カスタムのオーバーライド構成が有効であることを確認します:
combine-mode動詞(addおよびreplace)を省略する必要があります。
replaceおよびadd動詞を次のように使用します:
config.xmlにまだ存在しない新規Beanを追加する場合は、MBean自体およびBean内の各属性でaddを指定します。
server-debugスタンザを参照してください。config.xml内の既存のBeanに新しい属性を追加する場合、その属性にはadd動詞が必要です。
max-message-sizeスタンザを参照してください。config.xml内の既存の属性の値を変更する場合、属性にはreplace動詞が必要です。
public-addressスタンザを参照してください。config.xmlをオーバーライドする場合:
xmlns:)は、テンプレート・スキーマのオーバーライドで指定されているとおりにする必要があります。
d:を使用してconfig.xml beanおよび属性を参照し、addのf:およびreplace domain-fragment動詞、およびs:を使用して構成オーバーライド・スキーマを参照します。jms:、jdbc:およびwldf:を使用することをお薦めします。次に、テンプレートのオーバーライド・ファイルの例を示します。
config.xmlのオーバーライド次のconfig.xmlオーバーライド・ファイルは、次のことを示しています:
admin-serverという名前のWebLogic Serverでのmax-message-sizeフィールドの設定。 元のconfig.xmlではこの値が定義されていないため、replaceのかわりにaddが使用されることを前提としています。 public-addressおよびpublic-portフィールドに、hostnameおよびportというキーを持つtest-hostという名前のシークレットから取得した値を設定します。 ここでは、元のconfig.xmlでこれらのフィールドがすでに設定されていることを前提としているため、addのかわりにreplaceを使用します。 server-debugスタンザがないため、スタンザ全体でaddを使用します。 <?xml version='1.0' encoding='UTF-8'?>
<d:domain xmlns:d="http://xmlns.oracle.com/weblogic/domain"
xmlns:f="http://xmlns.oracle.com/weblogic/domain-fragment"
xmlns:s="http://xmlns.oracle.com/weblogic/situational-config" >
<d:server>
<d:name>admin-server</d:name>
<d:max-message-size f:combine-mode="add">78787878</d:max-message-size>
<d:server-debug f:combine-mode="add">
<d:debug-server-life-cycle f:combine-mode="add">true</d:debug-server-life-cycle>
<d:debug-jmx-core f:combine-mode="add">true</d:debug-jmx-core>
</d:server-debug>
<d:network-access-point>
<d:name>T3Channel</d:name>
<d:public-address f:combine-mode="replace">${secret:test-host.hostname}</d:public-address>
<d:public-port f:combine-mode="replace">${secret:test-host.port}</d:public-port>
</d:network-access-point>
</d:server>
</d:domain>
次のjdbc-testDS.xmlオーバーライド・テンプレートは、secret macrosを使用したtestDSという名前のJDBCモジュールのURL、ユーザー名およびパスワード暗号化フィールドの設定を示しています。 マクロをシークレット値に置き換える生成済の構成オーバーライドは、DOMAIN_HOME/optconfig/jdbcディレクトリにあります。 password-encryptedフィールドには、:encryptサフィクスの付いたシークレット・マクロが使用されるため、暗号化された値が移入されます。 Secretはdbsecretという名前で、3つのキーが含まれています: url、usernameおよびpassword。
データ・ソース・モジュールとそのオーバーライドのベスト・プラクティス:
JDBCConnectionPoolParams MinCapacityおよびInitialCapacityを0に設定し、元のDriverNameを既存のJDBCドライバを参照するように設定します。 これにより、無効なURL/username/password値を構成した場合、データベースが稼働していない場合、またはまだオーバーライドを指定していない場合でも、サーバーを正常に起動できます。 <?xml version='1.0' encoding='UTF-8'?>
<jdbc:jdbc-data-source xmlns:jdbc="http://xmlns.oracle.com/weblogic/jdbc-data-source"
xmlns:f="http://xmlns.oracle.com/weblogic/jdbc-data-source-fragment"
xmlns:s="http://xmlns.oracle.com/weblogic/situational-config">
<jdbc:name>testDS</jdbc:name>
<jdbc:jdbc-driver-params>
<jdbc:url f:combine-mode="replace">${secret:dbsecret.url}</jdbc:url>
<jdbc:properties>
<jdbc:property>
<jdbc:name>user</jdbc:name>
<jdbc:value f:combine-mode="replace">${secret:dbsecret.username}</jdbc:value>
</jdbc:property>
</jdbc:properties>
<jdbc:password-encrypted f:combine-mode="replace">${secret:dbsecret.password:encrypt}</jdbc:password-encrypted>
</jdbc:jdbc-driver-params>
</jdbc:jdbc-data-source>
version.txtファイル、を含むディレクトリを作成します。
version.txtファイルには、文字列2.0を正確に含める必要があります。
2.0のままである必要があります。ConfigMapは、ドメインと同じKubernetesネームスペースに存在する必要があります。
ConfigMapを単一のDOMAIN_UIDで使用する場合は、リソースの追跡に役立つweblogic.domainUID=<mydomainuid>ラベルを追加することをお薦めします。
たとえば、./mydirにversion.txtおよび状況構成テンプレート・ファイルが含まれているとします:
$ kubectl -n MYNAMESPACE create cm MYCMNAME --from-file ./mydir
$ kubectl -n MYNAMESPACE label cm MYCMNAME weblogic.domainUID=DOMAIN_UID
シークレットには、クリア・テキストまたはbase64値を保持できる複数のキー(ファイル)を含めることができます。 Opaqueタイプのシークレットをdataフィールドで使用してパスワードにbase64値を使用することをお薦めします。これにより、それらのシークレットを簡単に読めなくなります。 詳細は、https://kubernetes.io/docs/concepts/configuration/secret/を参照してください。
シークレットは、ドメインと同じKubernetesネームスペースに存在する必要があります。
シークレットを単一のDOMAIN_UIDで使用する場合は、リソースの追跡に役立つようにweblogic.domainUID=<mydomainuid>ラベルを追加することをお薦めします。
例えば:
$ kubectl -n MYNAMESPACE create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret
$ kubectl -n MYNAMESPACE label secret my-secret weblogic.domainUID=DOMAIN_UID
configuration.overridesConfigMapフィールドでConfigMapの名前を構成します。usernameおよびpasswordキーが含まれている場合は、ドメインYAMLファイルのwebLogicCredentialsSecretフィールドを設定します。configuration.secretsフィールドに追加します。 ノート: 1つのシークレットのみを追加する場合でも、これは配列形式である必要があります(次のドメインYAMLファイルのサンプルを参照)。 ドメインYAMLの例:
apiVersion: "weblogic.oracle/v9"
kind: Domain
metadata:
name: domain1
namespace: default
labels:
weblogic.domainUID: domain1
spec:
[ ... ]
webLogicCredentialsSecret:
name: domain1-wl-credentials-secret
configuration:
overridesConfigMap: domain1-overrides-config-map
secrets: [my-secret, my-other-secret]
[ ... ]
この情報を使用して、オーバーライドが有効であるか、エラーがあるかどうかを確認します。
バックグラウンド・ノート:
WebLogic Server管理コンソールには、オーバーライドの変更は反映され「ません」。
wlst.shスクリプトを参照してください。不正なオーバーライド・ファイルは警告やエラーなしで暗黙的に受け入れられる可能性があります。
weblogic.SituationalConfig.failBootOnErrorシステム・プロパティをサポートするWebLogic Serverバージョンで、正しくないオーバーライドが検出される場合があります。
FAIL_BOOT_ON_SITUATIONAL_CONFIG_ERROR環境変数をfalseに設定して、このチェックを無効にします。デバッグ・ステップ:
「段階的なガイド」の各ステップに従っていることを確認してください。
WebLogic Serverインスタンスのポッドがまったく起動しない場合は、次のようにします:
ドメイン・リソース・ステータスの確認: kubectl -n MYDOMAINNAMESPACE describe domain MYDOMAIN
ドメインのイベントのチェック: kubectl -n MY_NAMESPACE get events --sort-by='.lastTimestamp'。 詳細は、「ドメイン・イベント」を参照してください。
イントロスペクタ・ジョブとそのログを確認します。
DOMAIN_UID-introspectorという名前のジョブと、DOMAIN_UID-introspector-xxxxのような名前の対応するポッドがあるかどうかを確認します。 その場合は、次の点を確認してください:
kubectl -n MYDOMAINNAMESPACE describe job INTROSPECTJOBNAMEkubectl -n MYDOMAINNAMESPACE logs INTROSPECTPODNAMEspec.logHomeが構成され、spec.logHomeEnabledがtrueの場合、ドメイン・リソースのspec.logHomeディレクトリにミラー化されます。オペレータ・ログでWarning/Error/Severeメッセージを確認します。
kubectl -n MYOPERATORNAMESPACE logs OPERATORPODNAMEWebLogic Serverインスタンスのポッドが起動する場合は、次のようにします:
kubectl logでキーワードsituationalを検索します(例: kubectl logs MYADMINPOD | grep -i situational)。
<Dec 14, 2018 12:20:47 PM UTC> <Info> <Management> <BEA-141330> <Loading situational configuration file: /shared/domains/domain1/optconfig/custom-situational-config.xml>Warning行またはError行が返される場合、カスタム構成オーバーライド・テンプレートの形式が正しくなく、WarningまたはErrorテキストで問題を記述する必要があります。java.lang.NullPointerException
at weblogic.management.provider.internal.situationalconfig.SituationalConfigManagerImpl.registerListener(SituationalConfigManagerImpl.java:227)
at weblogic.management.provider.internal.situationalconfig.SituationalConfigManagerImpl.start(SituationalConfigManagerImpl.java:319)
...
at weblogic.management.configuration.DomainMBeanImpl.setJDBCSystemResources(DomainMBeanImpl.java:11444)
...
DOMAIN_HOME/optconfigディレクトリを確認します。
configuration.overridesConfigMapがカスタム・オーバーライドConfigMap名と一致するように構成されていないか、カスタム・オーバーライドConfigMapにオーバーライド・ファイルが含まれていない可能性があります。管理サーバーのポッドが起動しても準備完了状態にならない場合、または再起動を試行する場合:
kubectl logでこのメッセージ WebLogic Server failed to start due to missing or invalid situational configuration filesを確認してください
situationalを含む行は、より多くのヒントを提供するために管理サーバーのポッド・ログに記録される場合があります。 <Jun 20, 2019 3:48:45 AM GMT> <Warning> <Management> <BEA-141323>
<The situational config file has an invalid format, it is being ignored: XMLSituationalConfigFile[/shared/domains/domain1/optconfig/jdbc/testDS-0527-jdbc-situational-config.xml] because org.xml.sax.SAXParseException; lineNumber: 8; columnNumber: 3; The element type "jdbc:jdbc-driver-params" must be terminated by the matching end-tag "</jdbc:jdbc-driver-params>".
testDS JDBCデータ・ソースに指定された構成オーバーライド・ファイルに構文エラーがあることを示します。kubectl -n MY_NAMESPACE get events --sort-by='.lastTimestamp'。WebLogic MBeanツリーで構成のオーバーライドが有効になっていることを確認するには、server configとdomain configのMBeanツリー値を比較します。
domain config値は、ドメイン・ホーム構成の元の値を反映する必要があります。server config値は、オーバーライドされた値を反映する必要があります。DOMAIN_UIDがdomain1で、ドメインにadmin-serverという名前のWebLogic Serverが含まれているとします:$ kubectl exec -it domain1-admin-server /bin/bash
$ wlst.sh
> connect(MYADMINUSERNAME, MYADMINPASSWORD, 't3://domain1-admin-server:7001')
> domainConfig()
> get('/Servers/admin-server/MaxMessageSize')
> serverConfig()
> get('/Servers/admin-server/MaxMessageSize')
> exit()
WebLogic構成オーバーライド機能によってWebLogic Serverログに追加のデバッグ情報が生成されるようにするには、ドメインYAMLファイルでJAVA_OPTIONS環境変数を次のように構成します:
-Dweblogic.debug.DebugSituationalConfig=true
-Dweblogic.debug.DebugSituationalConfigDumpXml=true
DOMAIN_UID-introspectorという名前のイントロスペクション用のKubernetesジョブを作成します。configuration.overridesConfigMap、webLogicCredentialsSecretおよびconfiguration.secretsフィールドを使用して指定されたKubernetes ConfigMapおよびシークレットをマウントします。${env:DOMAIN_UID}など)が拡張されます。${secret:mysecret.mykey}など)から値を読み取ることで、参照されるシークレットを拡張します。${secret:mysecret.mykey:encrypt}など)に便利です。DOMAIN_UID-weblogic-domain-introspect-cmで始まる1つ以上のConfigMaps内のファイルをオーバーライドします。startServer.shスクリプト:
config.xmlオーバーライドは、そのドメイン・ホームのoptconfigディレクトリにコピーされます。optconfig/jdbc、optconfig/jmsまたはoptconfig/diagnosticsディレクトリにコピーされます。optconfigディレクトリ内の構成オーバーライド・ファイルを削除します。optconfigディレクトリからオーバーライドを読み取ります。kubeletによるConfigMapデータのこの定期的な同期率は構成可能ですが、デフォルトは10秒です。overridesDistributionStrategyがDynamicの場合、Kubernetesによってすでに定期的に起動されているlivenessProbe.shスクリプトは、startServer.shと同じアクションを実行してoptconfigのファイルを更新します。optconfig内のファイルを監視し、構成オーバーライド・ファイルの現在の内容に基づいてアクティブな構成を動的に更新します。overridesDistributionStrategyがOnRestartの場合、ConfigMapのマウント・ポイントで更新されたファイルは、WebLogic Serverインスタンスの実行中にoptconfigにコピーされないため、アクティブな構成には影響しません。実行中のWebLogic Serverインスタンスに配布された構成オーバーライドへの変更は、対応するWebLogic構成のMBean属性が「動的」である場合にのみ有効になります。 たとえば、データソースpasswordEncrypted属性は動的ですが、Url属性は動的ではありません。