実行中のModel in ImageドメインにWebLogicドメイン・ホーム構成を更新し、更新をWebLogic Serverポッドの再起動のままにする場合は、既存のモデルを変更し、WebLogic Kubernetes Operatorに変更を伝播するように指示する必要があります。
かわりに、WebLogic Server管理コンソールまたはWLSTスクリプトを使用してModel in Imageドメインの直接実行時のWebLogic構成更新を行うと、更新は一時的になります。 これは、ポッド再起動のたびにモデルからModel in Imageドメイン・ホームが再生成されるためです。
最初にドメインを停止せずに、実行中のModel in Imageドメインにモデル更新を伝播するには、次の2つの方法があります:
オフライン更新: オフライン更新は、モデルを更新してからドメイン・ロールを開始することでWebLogicポッドに伝播され、新しいドメイン構成が生成され、更新された構成でドメインのWebLogic Server管理サーバーを再起動してから、実行中の他のサーバーを再起動します。
オンライン更新: モデル変更が完全に動的構成MBean属性になるように構成されている場合は、オプションで、オンライン更新を使用してロールなしでWebLogicポッドに変更を伝播できます。 オンライン更新リクエストに、オフライン更新のみを使用して達成できる非動的モデル更新が含まれている場合、結果の動作はドメイン・リソースのYAML domain.spec.configuration.model.onlineUpdate.onNonDynamicChanges属性によって制御されます。この属性の詳細は、「非動的WebLogic構成変更のオンライン更新処理」を参照してください。
オペレータは、ドメインがまだ実行されている間、すべてのタイプのWebLogic構成変更をサポートしません。 オンラインまたはオフラインの更新で変更がサポートされていない場合、変更を伝播するには、ドメインを完全にシャットダウンし、変更を適用して、最後にドメインを再起動する必要があります。 ドメインの完全再起動については、「ドメイン全体の再起動」を参照してください。
ノート: サポートされている変更とサポートされていない変更については、これらのセクションで説明: サポートされる更新およびサポートされない更新。 更新の正しいアプローチを開始するために、ドメイン・リソースに必要な変更を行うことは管理者責任です。
「構成のオーバーライド」で説明されているように、ドメイン・リソースYAMLファイルconfiguration.overridesConfigMapを使用して指定されたWebLogic構成のオーバーライドであるカスタム構成のオーバーライドは、Model in Imageと組み合せてサポートされ「ません」。 カスタム・オーバーライドが指定されている場合、Model in Imageはエラーを生成します。 モデル・ファイル、シークレットまたはモデル・イメージの更新は、カスタム構成のオーバーライドの更新よりも単純で柔軟性が高いため、これは考慮しないでください。 構成のオーバーライドとは異なり、モデル・ファイルの更新の構文は、モデル・ファイルを最初に指定するための構文と完全に一致します。
実行中のModel in Imageドメインに対して提案されたモデルの更新が、「サポートされる更新」および「サポートされない更新」を参照することでサポートされている場合は、次の方法を使用できます。
オンラインまたはオフライン更新の場合:
モデル・ファイルを含む新しいまたは変更されたWDT ConfigMapを指定し、ドメイン・リソースYAMLファイルconfiguration.model.configMapフィールドを使用してマップを参照します。 ConfigMapのモデル・ファイルは、イメージ内のモデル・ファイルとマージされます。 ConfigMapがドメインと同じネームスペースにデプロイされていることを確認します。
モデル・ファイルのマクロによって参照されるシークレットを変更、追加または削除し、ドメイン・リソースYAMLファイルconfiguration.secretsフィールドを使用してシークレットを参照します。 シークレットがドメインと同じネームスペースにデプロイされていることを確認します。
オフライン更新の場合のみ、次の2つの追加オプションがあります:
新規または変更されたモデル・ファイルで新しいイメージを指定します。
spec.imageで指定されたイメージにファイルが配置されている場合は、このフィールドを変更してイメージを参照します。serverPod.auxiliaryImages.imageフィールド値を変更して新しいイメージを参照するか、新しいイメージ用の新しいserverPod.auxiliaryImagesマウントを追加します。モデル・ファイルのマクロによって参照される環境変数を変更、追加または削除します。 環境変数は、ドメイン・リソースYAMLファイルspec.serverPod.envまたはspec.serverPod.adminServer.env属性で指定されます。
最後の2つの変更オプション、または同様のドメイン・リソースYAMLファイルが「サーバーの再起動の原因となるフィールド」に変更され、他のすべての変更の準備が完了するまで遅延することをお薦めします。 これは、そのような変更が自動的かつ即時にイントロスペクタ・ジョブの再実行となり、ジョブが成功した場合、ドメインのロールとオフライン更新(モデルに伴う変更がある場合)が発生するためです。
モデル更新には、追加、変更および削除を含めることができます。 モデル変更の生成に役立ちます:
モデル・ファイルの構文の詳細は、WebLogic Deploy ToolingドキュメントおよびModel in Image 「モデル・ファイル」ドキュメントを参照してください。
モデル変更YAMLの生成に使用できるヘルパー・ツールの説明については、「WDT検出および比較モデル・ツールの使用」を参照してください。
イメージ、ボリューム(「補助イメージ」機能からのイメージに基づくものを含む)またはWDT ConfigMapに複数のモデル・ファイルを指定した場合、ロードおよびマージされる順序は、「モデル・ファイルの命名およびロード順序」で説明するように決定されます。
オンライン更新を実行していて、更新に削除が含まれている場合は、「オンライン更新削除処理」を参照してください。
モデル更新の準備が完了したら、「オフライン更新」または「オンライン更新」のステップに従って、変更したモデルを実行中のドメインに伝播するようにオペレータに指示できます。
次のステップを使用して、モデルに対するオフライン構成の更新を開始します:
spec.imageで指定されたイメージにファイルが配置されている場合は、このフィールドを変更してイメージを参照します。serverPod.auxiliaryImages.imageフィールド値を変更して新しいイメージを参照するか、新しいイメージ用の新しいserverPod.auxiliaryImagesマウントを追加します。domain.spec.serverPod.envまたはdomain.spec.adminServer.serverPod.envを変更します。domain.spec.configuration.model.configMapをConfigMapの名前に設定します。domain.spec.configuration.secrets配列に現在のすべてのシークレットが反映されていることを確認します。spec.restartVersionの変更」を参照するか、他のドメイン・リソースYAML 「サーバーの再起動の原因となるフィールド」を変更します。 オペレータは、後でドメインのイントロスペクタ・ジョブを再実行します。 このジョブは、すべてのシークレットおよび環境変数をリロードし、すべてのモデル・ファイルをマージして、新しいドメイン・ホームを生成します。
ジョブが成功すると、オペレータはDOMAIN_UID-weblogic-domain-introspect-cmという名前のConfigMapを使用して、更新されたドメイン・ホームをポッドで使用できるようにし、その後、オペレータはドメイン内でWebLogic Serverポッドを実行しているそれぞれをロール(再起動)して、新しい構成をロードできるようにします。 ドメイン・ロールは、ドメインの管理サーバーの再起動から始まり、ドメイン内の各管理対象サーバーの再起動に進みます。
ジョブで失敗が報告された場合は、「デバッグ」を参照してください。
データ・ソースを追加するオフライン更新サンプルについては、Model in Imageサンプルの「1つのユース・ケースを更新」を参照してください。
次のステップを使用して、モデルに対するオンライン構成の更新を開始します:
domain.spec.image、domain.spec.serverPod.env、またはその他のドメイン・リソースYAML 「サーバーの再起動の原因となるフィールド」を変更「しないでください」。これにより、自動的にすぐにイントロスペクタ・ジョブの再実行、ジョブが成功した場合のロール、および付随するモデル変更がある場合のオフライン更新が行われます。
WDT ConfigMapを指定する場合は、domain.spec.configuration.model.configMapをConfigMapの名前に設定します。
変更の一部としてシークレットを追加または削除する場合は、domain.spec.configuration.secrets配列に現在のすべてのシークレットが反映されていることを確認します。
domain.spec.configuration.model.onlineUpdate.enabledをtrueに設定します(デフォルトはfalseです)。
domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesをCommitUpdateOnly (デフォルト)およびCommitUpdateAndRollのいずれかに設定します。 詳細は、「非動的WebLogic構成変更のオンライン更新処理」を参照してください。
オプションで、domain.spec.configuration.model.onlineUpdate.wdtTimeoutsのWDTタイムアウトを調整します。
kubectl explain domain.spec.configuration.model.onlineUpdate.wdtTimeoutsを呼び出すことができます。domain.spec.introspectVersionを別の値に変更します。 例については、「ドメインspec.introspectVersionの変更」を参照してください。
これらのステップを完了した後、オペレータは、新しいマージ済モデルを生成するイントロスペクタ・ジョブを実行し、新しいマージ済モデルを以前にデプロイしたマージ済モデルと比較し、WebLogic Deploy Toolingを実行して差異を処理します:
イントロスペクタ・ジョブWDTで差異が完全に動的なWebLogic構成MBean変更に限定されていると判断された場合、オペレータは、実行中のWebLogicポッドにデルタ・オンライン更新を送信します。
WDTで非動的WebLogic構成MBeanの変更が検出された場合、domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesをCommitUpdateOnly (デフォルト)に構成したか、またはCommitUpdateAndRollに構成したかに応じて、オペレータは更新を無視するか、オンライン更新のみを許可するか、オフライン更新(ロール)を開始できます。 詳細は、「非動的WebLogic構成変更のオンライン更新処理」を参照してください。
イントロスペクタ・ジョブで失敗またはその他の失敗が発生したことが報告された場合、アドバイスについては「デバッグ」を参照してください。 失敗から回復する場合は、次の点に注意してください:
オペレータは、ユーザー制御下にあるリソースの変更を自動的に元に戻すことはできません(オフライン更新の場合と同様)。 たとえば、問題の変更をイメージ、configMap、シークレットおよびドメイン・リソースのYAMLファイルに戻すことは、管理者の責任です。
オンライン更新中に失敗が発生した場合、実行中のドメインに対するWebLogic構成変更は行われず、イントロスペクタ・ジョブは、domain.spec.failureRetryLimitMinutesで指定された失敗再試行時間制限まで再試行します。 問題を修正するには、モデル・リソース(ConfigMapまたはシークレット(あるいはその両方)を変更および再適用し、さらにイントロスペクタ・ジョブが再試行を停止した場合は、ドメイン・リソースdomain.spec.introspectVersionも再度変更する必要があります。 詳細は、「ドメイン失敗再試行処理」を参照してください。
オンライン更新用のサンプル・ドメイン・リソースYAMLファイル:
...
kind: Domain
metadata:
name: sample-domain1
namespace: sample-domain1-ns
...
spec:
...
introspectVersion: 5
configuration:
...
model:
domainType: "WLS"
configMap: sample-domain1-wdt-config-map
runtimeEncryptionSecret: sample-domain1-runtime-encryption-secret
onlineUpdate:
enabled: true
onNonDynamicChanges: "CommitUpdateAndRoll"
secrets:
- sample-domain1-datasource-secret
- sample-domain1-another-secret
動的なWebLogic MBean変更のみを含むオンライン更新に成功しました。
Completed条件ステータスがTrueに設定されます。 詳細は、「ドメイン条件」を参照してください。 weblogic.introspectVersionラベルは、domain.spec.introspectVersionと一致するように設定されます。domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesがCommitUpdateOnly (デフォルト)のときに、動的でないWebLogic MBean属性を含むオンライン更新に成功しました。
usernameなど)。Available条件は、StatusがTrueになります。ConfigChangesPendingRestart条件は、管理者がすでに実行されているすべてのWebLogic Serverポッドをロールするまで、TrueのStatusになります。weblogic.introspectVersionラベルは、domain.spec.introspectVersionと一致します。weblogic.configChangesPendingRestart=trueラベルが付けられます。weblogic.configChangesPendingRestart=trueラベルを使用してポッドを再起動します(ドメイン・ロールの開始など)。domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesがCommitUpdateAndRollの場合、動的でないWebLogic MBean属性を含むオンライン更新に成功しました。
weblogic.introspectVersionラベルは、ロールされた後、domain.spec.introspectVersionと一致します。Available条件のStatusはTrueになります。domain.spec.introspectVersion, spec.configuration.secrets, spec.configuration.model.onlineUpdateまたはspec.configuration.model.configMapに加えて、ドメイン・リソース「サーバーの再起動の原因となるフィールド」を変更します。
「サポート対象外」のモデル属性を変更します。
モデルのエラー(構文エラーなど)。
Failed条件は、StatusがTrueになります。spec.introspectVersionを変更します。ドメインの更新中に他のエラーが発生しました。
Failed条件は、StatusがTrueになります。spec.introspectVersionを変更します。オンライン更新時に、オペレータはイントロスペクタ・ジョブを再実行します。このジョブは、実行中のドメインに対するWebLogic構成のオンライン変更を試行します。 ドメイン・リソースのステータス条件およびそのWebLogic Serverポッド・ラベルを使用して、更新のステータスをモニターできます。
たとえば、ドメイン・ステータスの場合は、kubectl -n MY_NAMESPACE get domain MY_DOMAINUID -o yamlを使用してドメイン・リソースdomain.statusスタンザをチェックし、WebLogicポッド・ラベルの場合は、kubectl -n MY_NAMESPACE get pods --show-labelsに加えてオプションで--watchを追加して、時間の経過とともにポッドが変化したときにポッドを監視できます。
domain.statusのConfigChangesPendingRestart条件には、オンライン更新の進行状況に関する情報が含まれます。 詳細は、「ConfigChangesPendingRestart条件」を参照してください。
オンライン更新成功後の予想されるWebLogicポッド・ラベルの一部を次に示します:
各WebLogic Serverポッドのweblogic.introspectVersionラベル値は、最終的に定義したdomain.spec.introspectVersion値と一致します。
domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesがCommitUpdateOnly (デフォルト)の場合、イントロスペクション・ジョブが正常に完了すると、すべてのポッドのイントロスペクト・バージョン・ラベルが即時に更新されます。domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesがCommitUpdateAndRollで、モデルに対する非動的構成の変更がない場合、イントロスペクション・ジョブが正常に完了すると、すべてのポッドのイントロスペクト・バージョン・ラベルが即時に更新されます。domain.spec.configuration.model.onlineUpdate.onNonDynamicChangesがCommitUpdateAndRollで、モデルに対する動的でないク・ラベル構成変更がある場合、ポッドのロール後に各ポッドのイントロスペクト・バージョン・ラベルが更新されます。次のすべてに該当する場合、管理者によってポッドが再起動(ロール)されるまで、各WebLogic Serverポッドにweblogic.configChangesPendingRestart=trueラベルが表示されます:
domain.spec.configuration.model.onlineUpdate.onNonDynamicChanges属性はCommitUpdateOnly (デフォルト)です。ドメイン・リソースYAML domain.spec.configuration.model.onlineUpdate.onNonDynamicChanges属性は、オンライン更新イントロスペクタ・ジョブ中に非動的WebLogic構成の変更が検出された場合の動作を制御します。 非動的変更とは、ドメインの再起動を有効にする必要がある変更です。 有効な値は、CommitUpdateOnly (デフォルト)またはCommitUpdateAndRollです:
CommitUpdateOnly (デフォルト)に設定され、非動的変更が検出されると、すべての変更がコミットされ、動的変更が即時に有効になり、ドメインは自動的に再起動(ロール)されず、ポッドが後で再起動された場合にのみ、非動的変更がポッドで有効になります。
CommitUpdateAndRollに設定し、非動的変更が検出されると、すべての変更がコミットされ、動的変更が即時に有効になり、ドメインは自動的に再起動(ロール)、非動的変更がポッドの再起動後に各ポッドに対して有効になります。
When updating a domain with non-dynamic MBean changes with
`domain.spec.configuration.model.onlineUpdate.onNonDynamicChanges=CommitUpdateOnly` (the default),
the non-dynamic changes are not effective on a WebLogic pod until the pod is restarted.
However, if you scale up a cluster or otherwise start any new servers in the domain,
then the new servers will start with the new non-dynamic changes
and the domain will then be running in an inconsistent state until its older servers are restarted.
オンライン更新の主なユース・ケースは、小さな追加、単一リソースの削除、依存関係のないMBeans、または非動的MBean属性の変更を行うことです。
次の2つのケースで、オンライン更新で削除が問題になる場合があります:
通常、これらの問題を回避するには、複雑な削除をオフライン更新で処理する必要があります。
ノート: モデルの親タイプのセクションを暗黙的に削除すると、そのセクションのタイプに応じて動作することがあります。 たとえば、model.configMapのappDeployments:の下のモデルにアプリケーションがあり、その後、オンライン更新を使用してConfigMapを更新し、appDeploymentセクションを含まないようにすると、オンライン更新によってドメインからアプリケーションが削除されます。
MBeanの削除の例として、次で始まるWDT ConfigMapを考えてみます:
resources:
SelfTuning:
WorkManager:
wm1:
Target: 'cluster-1'
wm2:
Target: 'cluster-1'
JDBCSystemResource:
...
work-managersを使用せずに新しいモデルにオンライン更新する場合は、ConfigMapを次のように変更します:
resources:
SelfTuning:
WorkManager:
JDBCSystemResource:
...
または、追加のConfigMapを指定します:
resources:
SelfTuning:
WorkManager:
'!wm1':
'!wm2':
ConfigMapを省略したSelfTuningセクションに置換しようとすると、オンライン更新は失敗します:
resources:
JDBCSystemResource:
...
これは、MBean型SelfTuningおよびWorkManagerを暗黙的に削除するため失敗します。
クロス・リファレンスを持つMBeansのサポートされていないオンライン更新削除の例は、ワーク・マネージャ全体を削除する制約を使用して構成されたワーク・マネージャの場合を考えてみます:
resources:
SelfTuning:
WorkManager:
newWM:
Target: 'cluster-1'
MinThreadsConstraint: 'SampleMinThreads'
MaxThreadsConstraint: 'SampleMaxThreads'
MinThreadsConstraint:
SampleMinThreads:
Count: 1
MaxThreadsConstraint:
SampleMaxThreads:
Count: 10
ConfigMapで更新したモデルを次のように指定しようとした場合:
resources:
SelfTuning:
WorkManager:
MinThreadsConstraint:
MaxThreadsConstraint:
次に、オペレータはこのデルタを使用してドメインのオンライン更新を試みます:
resources:
SelfTuning:
MaxThreadsConstraint:
'!SampleMaxThreads':
WorkManager:
'!newWM':
MinThreadsConstraint:
'!SampleMinThreads':
オンライン更新では、WorkManagerを削除する前に参照されているすべてのConstraintsを削除しない可能性があるため、これは失敗します。
クロス依存関係を持つオブジェクトに対するオンライン更新に関する問題を回避するには、一連のオンライン更新を使用して段階的に変更できます。 たとえば、前のワーク・マネージャの例を続け、最初にオンライン更新を実行してワーク・マネージャを省略し、制約は省略します:
resources:
SelfTuning:
WorkManager:
MinThreadsConstraint:
SampleMinThreads:
Count: 1
MaxThreadsConstraint:
SampleMaxThreads:
Count: 10
更新が完了したら、別のオンライン更新を実行します:
resources:
SelfTuning:
WorkManager:
MinThreadsConstraint:
MaxThreadsConstraint:
データ・ソースおよびワーク・マネージャを変更するオンライン更新サンプルについては、Model in Imageサンプルの「4つのユース・ケースを更新」を参照してください。
追加の重要な情報については、次の付録を確認してください。
次の更新は、オフライン更新またはオンライン更新のsupportedです。ただし、サポート対象外として特にドキュメント化されている領域を参照する場合を除きます:
新しいWebLogicクラスタまたはスタンドアロン・サーバーを追加できます。
動的WebLogicクラスタのサイズを増やすことができます。
対応するモデルYAMLファイル・スニペットを親Bean階層とともに指定することで、新しいMBeansまたはリソースを追加できます。 たとえば、データ・ソースを追加できます。
YAMLファイル・スニペットと、既存のMBeanおよび属性を参照する親Bean階層を指定することで、MBean属性を変更または追加できます。 たとえば、mynewdatasourceという名前のデータ・ソースの最大容量を追加または変更するには:
resources:
JDBCSystemResource:
mynewdatasource:
JdbcResource:
JDBCConnectionPoolParams:
MaxCapacity: 5
詳細は、WebLogic Deploy Toolingドキュメントの「複数のモデルの使用」に関する項を参照してください。
モデル・マクロが参照するシークレット(@@SECRET:secretname:secretkey@@構文を使用するマクロ)を変更または追加できます。 たとえば、データベースのパスワード・シークレットを変更できます。
オフライン更新の場合のみ、モデル・マクロが参照する環境変数を変更または追加できます(@@ENV:myenvvar@@構文を使用するマクロ)。
イメージ・モデル・ファイルおよびWDT構成マップでMBean、アプリケーション・デプロイメントまたはリソースへの参照を省略することで、MBean、アプリケーション・デプロイメントまたはリソースを削除できます。 名前付きのMBean、アプリケーション・デプロイメントまたはリソースを削除することもできます。削除するには、名前の直前に感嘆符(!)を追加して、元の名前付き構成を含む元のモデル・ファイルの後に新しいモデル・ファイルがロードされるようにします。 たとえば、モデルにmynewdatasourceという名前のデータ・ソースが定義されている場合、データ・ソースを定義するモデル・ファイルの後にロードする小さいモデル・ファイルを指定することで削除できます。この場合、小さいモデル・ファイルは次のようになります:
resources:
JDBCSystemResource:
!mynewdatasource:
「オンライン更新の例外」があります。
詳細は、WebLogic Deploying Toolingのドキュメントの「削除する名前付きMBeansの宣言」に関する項を参照してください。
サポートされていないモデル更新を実行中のドメインに適用しないようにすることが重要です。 サポートされていない更新を使用しようとすると、常にクリア・エラー・メッセージになるとは限りません。予期される動作は未定義である可能性があります。 サポートされていない更新を行う必要があり、回避策がドキュメント化されていない場合は、変更を行う前にドメインを完全に停止します。 「ドメイン全体の再起動」を参照してください。
次に、回避方法または代替方法が記載されていないかぎり、Model in Imageでサポートされていない実行時更新構成のタイプをまとめます:
replicas属性を減らすことができます。 replicas属性を減らすことができます。 Enabled、リスニング・アドレスまたはポート。Enabled、リスニング・アドレス、プロトコルまたはポート。publicまたはexternalのアドレスとポートをオーバーライドできます。 JMX (MBean)またはオンラインWLSTへの外部アクセスでは、ネットワーク・アクセス・ポイントの内部ポートと外部ポートが一致している必要があります(JMS、RMIまたはEJBへの外部T3またはHTTPトンネリング・アクセスでは、ポートの一致は必要ありません)。 セキュリティ上の考慮事項により、T3またはRMIプロトコルをクラスタの外部に公開しないことを強くお薦めします。
spec.logHome、spec.logHomeEnabledまたはspec.httpAccessLogInLogHome属性を使用して同じMBeansをオーバーライドするようにドメイン・リソースが構成されている場合に、実行時にMBeanのサーバーおよびドメイン・ログ関連の設定を変更、追加または削除するために適用されます。 !構文を使用して、削除する属性の親である名前付きbean/リソースを削除するモデル・ファイルを追加します。!構文を使用して名前付きMBeanを削除できます。topology:スタンザの変更:
ConsoleEnabled, RootDirectory, AdminServerNameなどです。/u01/wdt/weblogic-deploy/bin/modelHelp.sh -oracle_home $ORACLE_HOME topologyを実行します(これは、/u01/wdt/weblogic-deployディレクトリにWDTをインストールしていることを前提としています)。!SelfTuningを使用して追加のモデルを指定することによって、SelfTuning型のスタンザ全体を削除することはできません。SelfTuningの親をそのままにするか、!構文を使用して特定のMBean名と組み合せて追加のモデルを指定することで、特定のMBeanを削除できます。domainInfo.Admin*, domainInfo.RCUDbinfo.*, topology.Security.*およびtopology.SecurityConfiguration.*でのセキュリティ変更が含まれます。オプションで、WDT Discoverドメインおよび比較ドメイン・ツールを使用して、モデル・ファイルの更新を生成できます。 WebLogic Deploy Tooling 「ドメインの検出ツール」は既存のドメイン・ホームからモデル・ファイルを生成し、その「モデルの比較ツール」は2つのドメイン・モデルを比較して、最初のドメインを2つ目のドメインに更新するためのYAMLファイルを生成します。
たとえば、WDTを/u01/wdt/weblogic-deployにインストールし、ドメイン・タイプがWLSであるとします:
既存のドメイン・ホームの検出を実行します。
$ /u01/wdt/weblogic-deploy/bin/discoverDomain.sh \
-oracle_home $ORACLE_HOME \
-domain_home $DOMAIN_HOME \
-domain_type WLS \
-archive_file old.zip \
-model_file old.yaml \
-variable_file old.properties
次に、コンソールまたはWLSTを使用して、WebLogic構成の変更を行います。
変更したドメイン・ホームに対してdiscoverを実行します。
$ /u01/wdt/weblogic-deploy/bin/discoverDomain.sh \
-oracle_home $ORACLE_HOME \
-domain_home $DOMAIN_HOME \
-domain_type WLS \
-archive_file new.zip \
-model_file new.yaml \
-variable_file new.properties
diffを使用して、古いYAMLと新しいYAMLを比較します。
$ diff new.yaml old.yaml
compareDomainを使用して古いYAMLと新しいYAMLを比較し、古いYAMLから新しいYAMLへの変換に使用できるYAML更新ファイルを生成します。
$ /u01/wdt/weblogic-deploy/bin/compareModel.sh \
-oracle_home $ORACLE_HOME \
-output_dir /tmp \
-variable_file old.properties \
old.yaml \
new.yaml
compareModelは、次のファイルを生成します:
# /tmp/diffed_model.json
# /tmp/diffed_model.yaml, and
# /tmp/compare_model_stdout
restartVersionまたはintrospectVersionの変更「オフライン更新」で説明したように、オフライン構成の変更を実行中のドメインに適用するようにオペレータに指示する1つの方法は、ドメインspec.restartVersionを変更することです。 同様に、「オンライン更新」は、ドメインspec.introspectVersionを変更して開始します。 次のいずれかのフィールドを変更する一般的な方法があります:
kubectl edit -n MY_NAMESPACE domain MY_DOMAINUIDを使用して、restartVersionまたはintrospectVersionを対話的に変更できます。
ドメインのリソース・ファイルがある場合は、このファイルを変更して、ファイルに対してkubectl apply -fをコールできます。
Kubernetesのgetおよびpatchコマンドを使用できます。
restartVersionのサンプル自動化スクリプトで、1番目のパラメータ(デフォルトのsample-domain1-ns)としてネームスペースを取得し、2番目のパラメータ(デフォルトのsample-domain1)としてdomainUIDを取得します:
#!/bin/bash
NAMESPACE=${1:-sample-domain1-ns}
DOMAINUID=${2:-sample-domain1}
currentRV=$(kubectl -n ${NAMESPACE} get domain ${DOMAINUID} -o=jsonpath='{.spec.restartVersion}')
if [ $? = 0 ]; then
# we enter here only if the previous command succeeded
nextRV=$((currentRV + 1))
echo "@@ Info: Rolling domain '${DOMAINUID}' in namespace '${NAMESPACE}' from restartVersion='${currentRV}' to restartVersion='${nextRV}'."
kubectl -n ${NAMESPACE} patch domain ${DOMAINUID} --type='json' \
-p='[{"op": "replace", "path": "/spec/restartVersion", "value": "'${nextRV}'" }]'
fi
introspectVersionの同様のサンプル・スクリプトを次に示します:
#!/bin/bash
NAMESPACE=${1:-sample-domain1-ns}
DOMAINUID=${2:-sample-domain1}
currentIV=$(kubectl -n ${NAMESPACE} get domain ${DOMAINUID} -o=jsonpath='{.spec.introspectVersion}')
if [ $? = 0 ]; then
# we enter here only if the previous command succeeded
nextIV=$((currentIV + 1))
echo "@@ Info: Rolling domain '${DOMAINUID}' in namespace '${NAMESPACE}' from introspectVersion='${currentIV}' to introspectVersion='${nextIV}'."
kubectl -n ${NAMESPACE} patch domain ${DOMAINUID} --type='json' \
-p='[{"op": "replace", "path": "/spec/introspectVersion", "value": "'${nextIV}'" }]'
fi
前の箇条書きアイテムで説明した同じコマンドを呼び出すWebLogic Kubernetes Operatorサンプル・スクリプトを使用できます。
kubernetes/samples/scripts/create-weblogic-domain/model-in-image/utils/ディレクトリのpatch-restart-version.shおよびpatch-introspect-version.shを参照してください。introspectDomain.shおよびrollDomain.shを参照してください。