> サンプル > ドメイン > Model in image > 更新4

更新4

このユースケースでは、WebLogic Serversを実行している再起動(ローリング)せずに、実行中のドメイン内のワーク・マネージャ・スレッド制約およびデータ・ソース構成を動的に変更する方法を示します。このユースケースでは、更新1ユースケースが実行され、sample-domain1ドメインがデプロイされて実行されていることが想定されています。

このユースケースでは、次のことを行います:

「更新1」ユースケースで作成されたWDTモデルを含むConfigMapを、ワーク・マネージャ・スレッド制約構成に変更して更新します。
「更新1」ユースケースで作成したデータ・ソース・シークレットを更新して、正しいパスワードと最大プール容量を増やします。
ドメインYAMLファイルを更新して、Model in Imageオンライン更新機能を有効にします。
ドメインYAMLファイルを更新してドメイン・イントロスペクションをトリガーします。これにより、サーバーを再起動せずに新しい構成値が適用されます。
オプションで、データベースを起動します(更新されたデータソース属性が有効になったことを示します)。

ステップは、次のとおりです。

「更新1」ユースケースからドメインをデプロイしているか、「更新3」ユースケースからこの同じドメインの更新済バージョンをデプロイしていることを確認してください。

sample-domain1-nsネームスペースで実行されているsample-domain1で始まる名前を持つ3つのWebLogic Serverポッド、sample-domain1という名前のドメイン、sample-domain1-wdt-config-mapという名前のConfigMap、およびsample-domain1-datasource-secretという名前のシークレットがあります。
ワーク・マネージャ・スレッド制約構成WDTモデルの更新を、Model in ImageモデルConfigMapの既存のデータ・ソース・モデルの更新に追加します。

このステップでは、「更新1」ユースケースからモデルConfigMapを更新し、最小スレッド数および最大スレッド数の制約に必要な変更を行います。

SampleMinThreads最小スレッド制約およびSampleMaxThreads最大スレッド制約の構成済カウント値を更新するモデル構成の例を次に示します:
```
resources:
  SelfTuning:
    MinThreadsConstraint:
      SampleMinThreads:
        Count: 2
    MaxThreadsConstraint:
      SampleMaxThreads:
        Count: 20
```
オプションで、前述のモデル・スニペットを/tmp/sample/myworkmanager.yamlという名前のファイルに配置し、更新されたモデルConfigMapをデプロイするときに使用するか、または/tmp/sample/model-configmaps/workmanager/model.20.workmanager.yamlで提供されているものと同じモデル・スニペットを使用します。

次のコマンドを実行します:
```
$ kubectl -n sample-domain1-ns delete configmap sample-domain1-wdt-config-map
```
```
$ kubectl -n sample-domain1-ns create configmap sample-domain1-wdt-config-map \
  --from-file=/tmp/sample/model-configmaps/workmanager \
  --from-file=/tmp/sample/model-configmaps/datasource
```
```
$ kubectl -n sample-domain1-ns label configmap sample-domain1-wdt-config-map \
  weblogic.domainUID=sample-domain1
```
ノート:
- 独自のモデルYAMLファイルを作成した場合は、--from-file=パラメータでファイル名を置き換えます(前述の/tmp/sample/myworkmanager.yamlおよび/tmp/sample/mydatasource.xmlをお薦めします)。
- -from-file=パラメータは単一のファイルを参照できます。この場合、指定されたファイルをConfigMapに格納するか、ディレクトリを参照できます。この場合、ConfigMapには指定されたディレクトリ内のすべてのファイルが移入されます。同じコマンドラインで複数回指定して、コンテンツを複数のロケーションからConfigMapにロードできます。
- 次の2つの理由で、関連付けられたドメインUIDを使用してConfigMapに名前を付け、ラベルを付けます:
  - どのConfigMapがどのドメインに属しているかを明らかにします。
  - ドメインのクリーンアップを容易にするため。一般的なクリーンアップ・スクリプトでは、ドメインに関連付けられているすべてのリソースを簡単に検索できるように、weblogic.domainUIDラベルを使用します。

更新1ユースケースで作成したデータ・ソース・シークレットを、正しいパスワードおよび最大プール容量の増加とともに更新します:

ノート: MY_ORACLE_SYS_PASSWORDを、データベースのデプロイ時に選択したものと同じデータベースsysアカウント・パスワード(または選択する予定)に置き換えます。

$ kubectl -n sample-domain1-ns delete secret sample-domain1-datasource-secret

$ kubectl -n sample-domain1-ns create secret generic \
   sample-domain1-datasource-secret \
   --from-literal='user=sys as sysdba' \
   --from-literal='password=MY_ORACLE_SYS_PASSWORD' \
   --from-literal='max-capacity=10' \
   --from-literal='url=jdbc:oracle:thin:@oracle-db.default.svc.cluster.local:1521/devpdb.k8s'

$ kubectl -n sample-domain1-ns label  secret \
   sample-domain1-datasource-secret \
   weblogic.domainUID=sample-domain1

ドメインのYAMLファイルを更新して、onlineUpdateを有効にします。

ドメインに対してonlineUpdateが有効で、モデル変更がWebLogicドメインの動的属性にのみある場合、ドメインのintrospectVersionを更新するときに、オペレータはサーバーを再起動せずに実行中のドメインをオンラインで更新しようとします。
- オプション1: ドメイン・カスタム・リソースを編集します。
  - kubectl -n sample-domain1-ns edit domain sample-domain1を呼び出します。
  - spec.configuration.model.onlineUpdateスタンザの値を追加または編集して、enabled: trueが含まれるようにし、保存します。
  - 更新されたドメインは次のようになります:
```
...
spec:
  ...
  configuration:
    ...
    model:
      ...
      onlineUpdate:
        enabled: true
```
- オプション2: kubectl patchを使用してドメインを動的に変更します。例えば:
```
$ kubectl -n sample-domain1-ns patch domain sample-domain1 --type=json '-p=[{"op": "replace", "path": "/spec/configuration/model/onlineUpdate", "value": {"enabled" : 'true'} }]'
```
- オプション3: サンプル・ヘルパー・スクリプトを使用します。
  - /tmp/sample/utils/patch-enable-online-update.sh -n sample-domain1-ns -d sample-domain1を呼び出します。
  - これにより、オプション2と同じkubectl patchコマンドが実行されます。
更新されたWebLogicドメイン構成をイントロスペクトするようオペレータに指示します。

更新されたワーク・マネージャ構成が更新されたモデルConfigMapにデプロイされ、更新されたデータ・ソース構成が更新されたデータ・ソース・シークレットに反映されるようになったため、オペレータがその構成を再生成するためにイントロスペクタ・ジョブを再実行する必要があります。

ドメインのspec.introspectVersionを変更して、ドメイン・イントロスペクションをトリガーします。これを行うには:
- オプション1: ドメイン・カスタム・リソースを編集します。
  - kubectl -n sample-domain1-ns edit domain sample-domain1を呼び出します。
  - spec.introspectVersionフィールドの値を変更して保存します。
  - このフィールドは文字列です。通常は、このフィールドで数値を使用して増分します。
- オプション2: kubectl patchを使用してドメインを動的に変更します。
  - 現在のintrospectVersionを取得します:
```
$ kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.introspectVersion}'
```
  - 現在のイントロスペクト・バージョンとは異なる新しいイントロスペクト・バージョンを選択してください。
    - このフィールドは文字列です。通常は、このフィールドで数値を使用して増分します。
  - kubectl patchを使用して新しい値を設定します。たとえば、新しいイントロスペクト・バージョンが2の場合:
```
$ kubectl -n sample-domain1-ns patch domain sample-domain1 --type=json '-p=[{"op": "replace", "path": "/spec/introspectVersion", "value": "2" }]'
```
- オプション3: サンプル・ヘルパー・スクリプトを使用します。
  - /tmp/sample/utils/patch-introspect-version.sh -n sample-domain1-ns -d sample-domain1を呼び出します。
  - これにより、オプション2と同じkubectl patchコマンドが実行されます。
spec.configuration.model.onlineUpdateのenabled値をtrueに設定し、指定したモデル変更はすべてWebLogic動的構成属性用であるため、ドメイン・イントロスペクタ・ジョブはポッドを再起動(ローリング)せずにWebLogic Serversに変更を適用すると想定しています。
イントロスペクタ・ジョブが完了するまで待ちます。次のことが可能です。
- kubectl get pods -n sample-domain1-ns --watchをコールし、イントロスペクタ・ポッドがTerminating状態になるまで待機して終了します。
```
sample-domain1-introspector-vgxxl   0/1     Terminating         0          78s
```
- このアクティビティの詳細を表示するには、waitForDomain.shサンプル・ライフサイクル・スクリプトを使用できます。このスクリプトは、ドメインのポッドに関する有用な情報を提供し、オプションで、Completedステータス条件がTrueになるまで待機します。 Completedドメインは、予想されるすべてのポッドがready状態に加え、ターゲットのrestartVersion、introspectVersionおよびimageに達したことを示します。例えば:
```
$ cd /tmp/weblogic-kubernetes-operator/kubernetes/samples/scripts/domain-lifecycle
$ ./waitForDomain.sh -n sample-domain1-ns -d sample-domain1 -p Completed
```
- イントロスペクタ・ジョブが失敗した場合は、「デバッグ」を参照してください。

サンプルwebアプリケーションをコールして、次のことを行います:

最小および最大スレッド数の制約の構成が新しい値に更新されたかどうかを確認します。
データ・ソースがデータベースに接続できるかどうかを確認します(データベースをデプロイした場合)。

webアプリケーション・リクエストをイングレス・コントローラに送信します:

$ curl -s -S -m 10 -H 'host: sample-domain1-cluster-cluster-1.sample.org' \
   http://localhost:30305/myapp_war/index.jsp

または、Traefikが使用できず、管理サーバーポッドが実行されている場合は、kubectl execを実行できます:

$ kubectl exec -n sample-domain1-ns sample-domain1-admin-server -- bash -c \
  "curl -s -S -m 10 http://sample-domain1-cluster-cluster-1:8001/myapp_war/index.jsp"

次のように表示されます。

<html><body><pre>
*****************************************************************

Hello World! This is version 'v2' of the sample JSP web-app.

Welcome to WebLogic server 'managed-server2'!

  domain UID  = 'sample-domain1'
  domain name = 'domain1'

Found 1 local cluster runtime:
  Cluster 'cluster-1'

Found min threads constraint runtime named 'SampleMinThreads' with configured count: 2

Found max threads constraint runtime named 'SampleMaxThreads' with configured count: 20

Found 1 local data source:
  Datasource 'mynewdatasource':  State='Running', testPool='Passed'

*****************************************************************
</pre></body></html>

mynewdatasourceのtestPool='Passed'は、パスワードを修正するためにデータ・ソース・シークレットへの更新が成功したことを確認します。

testPool='Failed'エラーが表示された場合は、データベースをデプロイしなかったか、データベースが正しくデプロイされていない可能性があります。

その他のエラーが表示された場合は、「デバッグ」を参照してください。

これでサンプル・シナリオは完了です。

サンプルで作成したリソースを削除するには、「クリーンアップ」を参照してください。