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

更新1

このユースケースでは、モデルを更新してドメインをローリングすることで、実行中のドメインにデータ・ソースを動的に追加する方法を示します。 WDTおよびModel in Imageのいくつかの機能を示します:

モデルの更新に使用する構文は、元のモデルの作成に使用する構文と同じです。
ドメインのモデルは、Kubernetes ConfigMapのファイルにモデル更新を指定することで動的に更新できます。
モデルの更新は、単一の属性の値を変更するだけでなく、JMSサーバーの追加など、より複雑な場合もあります。

モデル更新の詳細は、「ランタイム更新」を参照してください。

オペレータでは、可能なすべての動的モデル更新がサポートされているわけではありません。モデル更新の制限については、Model in Imageユーザー・ドキュメントの「ランタイム更新」を参照し、本番環境で動的更新を試行する前にモデル更新を慎重にテストしてください。

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

実行中のドメインがあることを確認します。

初期状態のユースケースからドメインがデプロイされていることを確認します。

データソース・モデルYAMLファイルを作成します。

データ・ソースのWDTモデル・スニペットを作成します(または提供されている例を使用します)。ターゲットがcluster-1に設定され、初期容量が0に設定されていることを確認します。

後者の理由は、データベースが見つからない場合、データ・ソースがWebLogic Server起動の失敗を発生させないようにすることです。これは、デプロイしていないために発生する可能性があります。

次に、これらの基準を満たすデータ・ソース・モデル構成の例を示します:

resources:
  JDBCSystemResource:
    mynewdatasource:
      Target: 'cluster-1'
      JdbcResource:
        JDBCDataSourceParams:
          JNDIName: [
            jdbc/mydatasource1,
            jdbc/mydatasource2
          ]
          GlobalTransactionsProtocol: TwoPhaseCommit
        JDBCDriverParams:
          DriverName: oracle.jdbc.xa.client.OracleXADataSource
          URL: '@@SECRET:@@ENV:DOMAIN_UID@@-datasource-secret:url@@'
          PasswordEncrypted: '@@SECRET:@@ENV:DOMAIN_UID@@-datasource-secret:password@@'
          Properties:
            user:
              Value: '@@SECRET:@@ENV:DOMAIN_UID@@-datasource-secret:user@@'
            oracle.net.CONNECT_TIMEOUT:
              Value: 5000
            oracle.jdbc.ReadTimeout:
              Value: 30000
        JDBCConnectionPoolParams:
            InitialCapacity: 0
            MaxCapacity: '@@SECRET:@@ENV:DOMAIN_UID@@-datasource-secret:max-capacity@@'
            TestTableName: SQL ISVALID
            TestConnectionsOnReserve: true

前のモデル・スニペットを/tmp/sample/mydatasource.yamlという名前のファイルに配置し、後のステップでモデルConfigMapをデプロイするか、または/tmp/sample/model-configmaps/datasource/model.20.datasource.yamlで提供されるものと同じデータ・ソースを使用します。

データ・ソース・シークレットを作成します。

データ・ソースは、作成する必要がある新しいシークレットを参照します。次のコマンドを実行してシークレットを作成します:
```
$ kubectl -n sample-domain1-ns create secret generic \
   sample-domain1-datasource-secret \
   --from-literal='user=sys as sysdba' \
   --from-literal='password=incorrect_password' \
   --from-literal='max-capacity=1' \
   --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
```
ドメインのローリングを必要とせずに「更新4」ユース・ケースでデータ・ソース属性を動的に修正するため、誤ったパスワードおよび最小プール容量を意図的に指定します。

シークレットの命名とラベル付けには、次の2つの理由で、関連付けられたドメインUIDを使用します:
- どのシークレットがどのドメインに属しているかを明らかにします。
- ドメインのクリーンアップを容易にするため。一般的なクリーンアップ・スクリプトでは、ドメインに関連付けられているすべてのリソースを簡単に検索できるように、weblogic.domainUIDラベルを使用します。
データ・ソース定義を含むWDTモデルを使用してConfigMapを作成します。

次のコマンドを実行します:
```
$ kubectl -n sample-domain1-ns create configmap sample-domain1-wdt-config-map \
  --from-file=/tmp/sample/model-configmaps/datasource
```
```
$ kubectl -n sample-domain1-ns label configmap sample-domain1-wdt-config-map \
  weblogic.domainUID=sample-domain1
```
- 独自のデータ・ソース・ファイルを作成した場合は、--from-file=パラメータでファイル名を置き換えます(前述の/tmp/sample/mydatasource.yamlをお薦めします)。
- -from-file=パラメータは、指定されたファイルをConfigMapに配置する単一のファイルを参照することも、指定されたディレクトリ内のすべてのファイルをConfigMapに移入するディレクトリを参照することもできます。
次の2つの理由で、関連付けられたドメインUIDを使用してConfigMapに名前を付け、ラベルを付けます:
- どのConfigMapがどのドメインに属しているかを明らかにします。
- ドメインのクリーンアップを容易にするため。一般的なクリーンアップ・スクリプトでは、ドメインに関連付けられているすべてのリソースを簡単に検索できるように、weblogic.domainUIDラベルを使用します。
ConfigMapおよびSecretを参照するようにドメインYAMLファイルを更新します。
- オプション1: 初期状態のユース・ケースからドメインYAMLファイルのコピーを更新します。
  - 「初期状態の」ユースケースでは、/tmp/sample/mii-initial-domain.yamlという名前のドメインYAMLファイルを作成するか、サンプルに付属する「ドメイン・リソース」ファイルを使用することをお薦めします。
    - 変更を行う前に、元のドメインYAMLファイルをコピーし、コピー/tmp/sample/mii-update1.yamlに名前を変更することをお薦めします。
    - コピーの操作は厳密には必要ありませんが、このサンプルの様々なユースケースでの作業の追跡に役立ち、以前の作業のバックアップが提供されます。
  - シークレットをspec.configuration.secretsスタンザに追加します:
```
spec:
  ...
  configuration:
  ...
    secrets:
    - sample-domain1-datasource-secret
```
    (既存のシークレットはそのままにします。)
  - そのspec.configuration.model.configMapを次のように変更します:
```
spec:
  ...
  configuration:
    ...
    model:
      ...
      configMap: sample-domain1-wdt-config-map
```
  - 変更したドメインYAMLファイルを適用します:
    
    ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。
```
$ kubectl apply -f /tmp/sample/mii-update1.yaml
```
- オプション2: サンプルに付属している更新されたドメインYAMLファイルを使用します:
  
  ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。
```
$ kubectl apply -f /tmp/sample/domain-resources/WLS/mii-update1-d1-WLS-v1-ds.yaml
```
ドメインを再起動(ロール)します。

これで、データ・ソースがConfigMapにデプロイされ、そのシークレットもデプロイされ、ConfigMapおよびシークレットを参照するspec.configuration.model.configMapおよびspec.configuration.secretsで更新されたドメインYAMLファイルを適用したので、オペレータにドメインをロールするように指示します。

モデル・ドメインが再起動すると、そのイントロスペクタ・ジョブを再実行して構成を再生成し、イントロスペクタで見つかった構成の変更も再起動された各サーバーに渡されます。実行中のドメインを再起動するには、ドメインのspec.restartVersionを変更する方法があります。これを行うには:
- オプション1: ドメイン・カスタム・リソースを編集します。
  - kubectl -n sample-domain1-ns edit domain sample-domain1を呼び出します。
  - spec.restartVersionフィールドの値を編集して保存します。
    - このフィールドは文字列です。通常は、このフィールドに数値を入力し、再起動のたびに増加します。
- オプション2: kubectl patchを使用してドメインを動的に変更します。
  - 現在のrestartVersionコールを取得するには:
```
$ kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}'
```
  - 現在の再起動バージョンとは異なる新しい再起動バージョンを選択してください。
    - このフィールドは文字列です。通常は、このフィールドに数値を入力し、再起動のたびに増加します。
  - kubectl patchを使用して新しい値を設定します。たとえば、新しい再起動バージョンが2であるとします:
```
$ kubectl -n sample-domain1-ns patch domain sample-domain1 --type=json '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "2" }]'
```
- オプション3: サンプル・ヘルパー・スクリプトを使用します。
  - /tmp/sample/utils/patch-restart-version.sh -n sample-domain1-ns -d sample-domain1を呼び出します。
  - これにより、オプション2と同じkubectl getおよびkubectl patchコマンドが実行されます。
ロールが完了するまで待ちます。

ドメイン・ロールが開始されたので、データ・ソースがデプロイされたことを確認する場合は、ドメイン・ロールが完了するまで待機する必要があります。
- これを行うには、kubectl get pods -n sample-domain1-ns --watchを呼び出してポッドがready状態に戻るまで待機する方法があります。
- このアクティビティの詳細を表示するには、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 'v1' of the sample JSP web-app.

Welcome to WebLogic Server 'managed-server1'!

  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: 1

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

Found 1 local data source:
  Datasource 'mynewdatasource':  State='Running', testPool='Failed'
    ---TestPool Failure Reason---
    NOTE: Ignore 'mynewdatasource' failures until the sample's Update 4 use case.
    ---
    ...
    ... invalid host/username/password
    ...
    -----------------------------

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

「更新4」のデータ・ソース属性を動的に修正するため、TestPool Failureが必要です。

予想されるTestPool Failure以外のエラーが表示された場合は、「デバッグ」を参照してください。

「更新3」または「更新4」ユースケースを実行する場合は、ドメインを実行したままにします。

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