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

更新3

更新3ユースケースでは、更新されたイメージを使用して、実行中の「更新1」ユースケース・ドメインに更新されたWebLogicアプリケーションをデプロイする方法を示します。

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

現在アクティブなmodel-in-image:WLS-v1イメージに類似したイメージmodel-in-image:WLS-v2を作成しますが、次の更新を行います:
- myapp-v1ではなくWDTアプリケーション・アーカイブ内のmyapp-v2ディレクトリ・パスにある更新されたwebアプリケーションv2。
- 新しいwebアプリケーション・パスを指す、イメージ内の更新されたモデルYAMLファイル。
元の「更新1」ユースケースのシークレットを参照しながら、新しいイメージを参照する更新済ドメインYAMLファイルを適用し、ConfigMapをモデル化します。

更新されたドメインYAMLファイルが適用されると、オペレータは次のことを行います:

イントロスペクタ・ジョブを再実行し、新しいモデルに基づいて新しいドメイン・ホームを生成します。
ドメインの管理サーバーポッドを再起動して、新しいイメージと新しいドメイン・ホームをロードします。
ドメインのクラスタ・サーバーを一度に1つずつロールして、それぞれが新しいイメージ、新しいドメイン・ホームおよび改訂したアプリケーションをロードするようにします。

最後に、アプリケーションを呼び出して、そのリビジョンがアクティブであることを確認します。

古いバージョンのアプリケーションv1は新しいイメージのアーカイブに残りますが、使用されません。元に戻す場合に備えて古いバージョンを残しておくことができることを示すために、ここに残しておきます。新しいイメージが適用された後、モデルのconfiguration.model.configMapを変更してイメージ・モデルの関連アプリケーション・パスをオーバーライドすることで元に戻すことができます。

このユースケースのステップは、次のとおりです:

「更新1」ユースケースからドメインがデプロイされていることを確認します。
更新された補助イメージを作成します。

「初期状態の」ユースケースの目的は、WebLogic Image Toolを使用して、/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v1/にステージングされたファイルからwdt-domain-image:WLS-v1という補助イメージを作成することでした。ステージングされたファイルには、WDT ZIPアーカイブにwebアプリケーションが含まれ、admin-serverというWebLogic Server管理サーバーおよびcluster-1というWebLogicクラスタ用のWDTモデル構成が含まれていました。最後のイメージは、wdt-domain-image:WLS-v1と呼ばれ、/auxiliary/modelsディレクトリにステージングされたファイルのコピーを持つことに加えて、WebLogic Deploy Toolingソフトウェアがインストールされているディレクトリ/auxiliary/weblogic-deployも含まれていました。

このユースケースでは、「初期状態の」ユースケースと同様のステップに従って、更新されたアプリケーションおよびモデルで新しいイメージを作成し、更新されたモデルおよびアプリケーションを実行中の「更新1」ユースケース・ドメインにデプロイします。
- 更新したWDTアーカイブを理解します。
  
  このユースケースで更新されたアーカイブは、ディレクトリ/tmp/sample/wdt-artifacts/archives/archive-v2にあります。これを使用して、イメージのアーカイブZIPファイルを作成します。このアーカイブは、「初期状態の」ユースケースの/tmp/sample/wdt-artifacts/archives/archive-v1と似ていますが、次の点が異なります:
  - これには、./wlsdeploy/applications/myapp-v2のアプリケーションの更新バージョンが含まれます(元のアプリケーションはディレクトリ./wlsdeploy/applications/myapp-v1に保持されます)。
  - ./wlsdeploy/applications/myapp-v2/myapp_war/index.jspのアプリケーションには、元のアプリケーションとの単一の違いが含まれます: これにより、行out.println("Hello World! This is version 'v1' of the sample JSP web-app.");がout.println("Hello World! This is version 'v2' of the sample JSP web-app.");に変更されます。
  アーカイブの詳細は、「最初のアーカイブの理解」を参照してください。
- WDTアーカイブのZIPファイルをステージングします。
  
  更新したイメージを作成する場合は、ステージング・ディレクトリ/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2のファイルを使用します。準備として、新しいWDTアプリケーション・アーカイブのZIPファイルを含める必要があります。
  
  次のコマンドを実行して、アプリケーション・アーカイブZIPファイルを作成し、必要なディレクトリに配置します:
```
# Delete existing archive.zip in case we have an old leftover version
```
```
$ rm -f /tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2/archive.zip
```
```
# Move to the directory which contains the source files for our new archive
```
```
$ cd /tmp/sample/wdt-artifacts/archives/archive-v2
```
  「WDTアーカイブ・ヘルパー・ツール」を使用して、後でWebLogic Image Toolを実行するときに使用するロケーションにアーカイブを作成
```
$ /tmp/sample/wdt-artifacts/weblogic-deploy/bin/archiveHelper.sh add application -archive_file=/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2/archive.zip -source=wlsdeploy/applications/myapp-v2
```
- ステージング済モデル・ファイルの理解。
  
  WDTモデルYAMLファイルおよびこのユースケースのプロパティは、ディレクトリ/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2にすでにステージングされています。
  
  このディレクトリのmodel.10.yamlファイルには、アーカイブ内の更新されたwebアプリケーションを参照する更新されたパスwlsdeploy/applications/myapp-v2がありますが、それ以外の場合は元のイメージにステージングされたモデルと同じです。最終的な関連YAMLファイル・スタンザは次のようになります:
```
appDeployments:
    Application:
        myapp:
            SourcePath: 'wlsdeploy/applications/myapp-v2'
            ModuleType: ear
            Target: 'cluster-1'
```
  この変更の前に元のモデル全体を確認する場合は、初期状態のユース・ケースの「モデル・ファイルのステージング」を参照してください。
- WITを使用して、ステージングされたモデル・ファイルから新しい補助イメージを作成します。
  
  この時点で、イメージwdt-domain-image:WLS-v2に必要なすべてのファイルをステージングしました。これには次のものが含まれます:
  - /tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2/model.10.yaml
  - /tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2/model.10.properties
  - /tmp/sample/model-images/wdt-artifacts/wdt-model-files/WLS-v2/archive.zip
  ここで、イメージ・ツールを使用して、wdt-domain-image:WLS-v2という名前の補助イメージを作成します。このツールは、前提条件ステップですでに設定されています。
  
  次のコマンドを実行して補助イメージを作成し、動作していることを確認します:
```
$ cd /tmp/sample/wdt-artifacts/wdt-model-files/WLS-v2
```
```
$ /tmp/sample/wdt-artifacts/imagetool/bin/imagetool.sh createAuxImage \
  --tag wdt-domain-image:WLS-v2 \
  --wdtModel ./model.10.yaml \
  --wdtVariables ./model.10.properties \
  --wdtArchive ./archive.zip
```
  imagetoolディレクトリが表示されない場合は、「前提条件」でステップが欠落しています。
  
  このコマンドは、WebLogic Image ToolをModel in Imageモードで実行し、次の操作を実行します:
  - 最後の補助イメージを小さいbusyboxベース・イメージのレイヤーとしてビルドします。
  - WITキャッシュで参照されるWDT ZIPファイルをイメージにコピーします。
    - サンプルの前提条件ステップでキャッシュを設定するときに、キーワードlatestを使用してWITにWDTをキャッシュしたことに注意してください。
    - これにより、WITはそれが目的のWDTバージョンであると暗黙的に想定し、-wdtVersionフラグを渡す必要がなくなります。
  - 指定されたWDTモデル、プロパティおよびアプリケーション・アーカイブをイメージのロケーション/auxiliary/modelsにコピーします。
  コマンドが成功すると、次のような出力で終了します:
```
[INFO   ] Build successful. Build time=36s. Image tag=wdt-domain-image:WLS-v2
```
  また、docker imagesコマンドを実行すると、wdt-domain-image:WLS-v2という名前のイメージが表示されます。
  
  ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxiliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。

リソースのデプロイ - 導入

ドメインYAMLファイルを設定して適用します。これは、更新1のユースケースのドメインYAMLファイルと似ていますが、イメージが異なります:
- オプション1: ドメインYAMLファイルのコピーを更新1ユースケースから更新します。
  - 「更新1」ユースケースでは、/tmp/sample/mii-update1.yamlという名前のファイルを作成するか、サンプルに付属の/tmp/sample/domain-resources/WLS/mii-update1-d1-WLS-v1-ds.yamlファイルを使用することをお薦めします。
    - 変更を行う前に、このドメインYAMLファイルをコピーし、コピー/tmp/sample/mii-update3.yamlに名前を変更することをお薦めします。
    - コピーの操作は厳密には必要ありませんが、このサンプルの様々なユースケースでの作業の追跡に役立ち、以前の作業のバックアップが提供されます。
  - wdt-domain-image:WLS-v1ではなくwdt-domain-image:WLS-v2を参照するように、/tmp/sample/mii-update3.yamlドメインYAMLファイルのimageフィールドを変更します。
    
    最終的な結果は次のようになります:
```
...
spec:
  ...
  image: "wdt-domain-image:WLS-v2"
```
  - 変更したドメインYAMLファイルを適用します:
    
    ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxiliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。
```
$ kubectl apply -f /tmp/sample/mii-update3.yaml
```
- オプション2: サンプルに付属している更新されたドメインYAMLファイルを使用します:
  
  ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxiliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。
```
$ kubectl apply -f /tmp/sample/domain-resources/WLS/mii-update3-d1-WLS-v2-ds.yaml
```
ロールが完了するまで待ちます。

更新されたイメージでドメインYAMLファイルを適用したので、オペレータは自動的にドメインのイントロスペクタ・ジョブを再実行して新しいドメイン・ホームを生成し、新しいドメイン・ホームおよび新しいイメージを使用するようにドメインのポッドをそれぞれ再起動('roll')します。新しいイメージとそれに関連付けられた新しいアプリケーションがデプロイされたことを確認するには、このロールが完了するまで待機する必要があります。
- これを行うには、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アプリケーションをコールして、更新されたアプリケーションがデプロイされたかどうかを確認できます。

アプリケーションが起動されると、Hello World! This is version 'v2' of the sample JSP web-app.などの出力文字列が含まれます。

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-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以外のエラーが表示された場合は、「デバッグ」を参照してください。

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

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