機械翻訳について

更新2

このユースケースでは、「更新1」ユースケース・ドメインに類似したドメインを同じsample-domain1-nsネームスペースに同時にデプロイする方法を示しますが、ドメインUID、WebLogicドメイン名およびWebLogicドメイン暗号化キーは異なります。 これは、次の方法で行います:

  • 初期状態のユース・ケースおよび更新1ユースケースと同じイメージ、イメージ・モデルYAMLファイルおよびアプリケーション・アーカイブを使用します。
  • 同じモデルを使用して、更新1ユースケース(データ・ソース)と同じConfigMapソース・ファイルを更新します。
  • 新しいドメインに別の(一意の)ドメインUIDであるsample-domain2を使用します。
  • ドメインごとに異なる(一意の)ドメイン名domain2を使用します。
  • シークレットおよびモデルをデプロイすると、新しいドメインに対して一意のラベルが付けられ、名前が付けられたConfigMapが更新されます。

このユースケースでは、異なるWebLogicドメイン名およびドメイン暗号化キーを持つWebLogicドメインのコピーを迅速にデプロイするModel in Imageの一意の機能を示しています。 これは、Domain in Image ドメイン・ホーム・ソース・タイプでサポートされていない便利な機能です:

  • Domain in Imageではドメイン名のオーバーライドはサポートされていませんが、2つのドメインを相互運用する必要がある場合は異なるドメイン名が必要です。 このユースケースでは、モデル・マクロを利用して、2つの異なるドメインのドメイン名が異なることを確認します:

    • まず、@@ENV:CUSTOM_DOMAIN_NAME@@環境変数マクロを使用して、モデルYAMLファイルにドメイン名を定義します。
    • 次に、各ドメインのYAMLファイルのenvスタンザを使用して、CUSTOM_DOMAIN_NAME環境変数の値を異なる値に設定します。

  • Domain in Imageでは、イメージに対して変更できないWebLogic security/SerializedSystemIni.datドメイン暗号化キーをイメージに埋め込む必要があります(CI/CDに関する考慮事項の「レイヤー化が重要な理由」を参照)。 これは、同じイメージを共有する2つのDomain in Imageドメインが、相互に暗号化されたパスワードを復号化できることを意味します。 一方、Model in Imageのドメイン暗号化キーはイメージに埋め込まれず、ドメインが起動されるたびに動的かつ一意に作成されます。

Oracleは、相互運用するWebLogicドメインに異なるドメイン名が必要です。 これは、2つのドメインが通信する場合、またはWebLogic ServerまたはWebLogic Javaクライアントが同時に複数のドメインに接続する場合に必要です。

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

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

  2. データ・ソース定義を含むWDTモデルを使用してConfigMapを作成します。

    次のコマンドを実行します:

    $ kubectl -n sample-domain1-ns create configmap sample-domain2-wdt-config-map \
  --from-file=/tmp/sample/model-configmaps/datasource

    $ kubectl -n sample-domain1-ns label configmap sample-domain2-wdt-config-map \
  weblogic.domainUID=sample-domain2

    Update 1ユース・ケースで独自のデータ・ソース・ファイルを作成した場合は、--from-file=パラメータでファイル名を置換します(前述の/tmp/sample/mydatasource.yamlをお薦めします)。 -from-file=パラメータは、指定されたファイルをConfigMapに配置する単一のファイルを参照することも、指定されたディレクトリ内のすべてのファイルをConfigMapに移入するディレクトリを参照することもできます。

    観察結果:

    • sample-domain1と同じネームスペースにドメインsample-domain2をデプロイするため、ConfigMapのネームスペースsample-domain1-nsは変更しません。
    • 次の2つの理由で、関連付けられたドメインUIDを使用してConfigMapに名前を付け、ラベルを付けます:
      • どのConfigMapがどのドメインに属しているかを明らかにします。
      • ドメインのクリーンアップを容易にするため。 一般的なクリーンアップ・スクリプトでは、ドメインに関連付けられているすべてのリソースを簡単に検索できるように、weblogic.domainUIDラベルを使用します。
    • 次の2つの理由から、新しいドメインには別のConfigMapを使用します:
      • 2つのドメインのライフ・サイクルまたはCI/CDプロセス(あるいはその両方)を簡単かつ独立した状態に保つため。
      • 元のドメインまたは新しいドメインのConfigMapへの変更を独立させるために、新しいドメインを今後の証明に使用します。

  3. イメージおよびConfigMapのWDTモデル・ファイルによって参照されるシークレットを作成します。これらはドメインYAMLファイルによっても参照されます。

    次のコマンドを実行します:

    ノート: 選択したパスワードをMY_WEBLOGIC_ADMIN_PASSWORDに置換します。 このパスワードには、少なくとも7文字と1桁の数字を含める必要があります。

    ノート: 選択したパスワードをMY_RUNTIME_PASSWORDに置換します。 管理パスワードとは異なる一意である必要がありますが、これは必須ではありません。 

    # spec.webLogicCredentialsSecret

    $ kubectl -n sample-domain1-ns create secret generic \
  sample-domain2-weblogic-credentials \
   --from-literal=username=weblogic --from-literal=password=MY_WEBLOGIC_ADMIN_PASSWORD

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

    # spec.configuration.model.runtimeEncryptionSecret

    $ kubectl -n sample-domain1-ns create secret generic \
  sample-domain2-runtime-encryption-secret \
   --from-literal=password=MY_RUNTIME_PASSWORD

    $ kubectl -n sample-domain1-ns label  secret \
  sample-domain2-runtime-encryption-secret \
  weblogic.domainUID=sample-domain2

    # referenced by spec.configuration.secrets and by the data source model YAML in the ConfigMap

    $ kubectl -n sample-domain1-ns create secret generic \
   sample-domain2-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-domain2-datasource-secret \
   weblogic.domainUID=sample-domain2

    観察結果:

    • sample-domain1と同じネームスペースにドメインsample-domain2をデプロイするため、各シークレットのネームスペースsample-domain1-nsは変更されません。
    • シークレットには、次の2つの理由で、関連付けられたドメインUIDを使用して名前を付け、ラベルを付けます:
      • どのシークレットがどのドメインに属しているかを明らかにします。
      • ドメインのクリーンアップを容易にするため。 一般的なクリーンアップ・スクリプトでは、ドメインに関連付けられているすべてのリソースを簡単に検索できるように、weblogic.domainUIDラベルを使用します。
    • 新しいドメインには、次の2つの理由で異なるシークレットのセットを使用します:
      • 2つのドメインのライフ・サイクルまたはCI/CDプロセス(あるいはその両方)を簡単かつ独立した状態に保つため。
      • 元のドメインのシークレットまたは新しいドメインのシークレットへの変更を独立させ、今後も利用可能なものにするため。
    • 「更新4」ユースケースでsample-domain1のデータ・ソース属性を動的に修正するため、データ・ソース・シークレットで誤ったパスワードおよび最小プール容量を意図的に指定します。

  4. 更新1ユースケースのドメインYAMLファイルと同様のドメインYAMLファイルを構成しますが、異なるドメインUID、ドメイン名、モデル更新のためのConfigMap参照およびシークレット参照を使用します:

    • オプション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-update2.yamlに名前を変更することをお薦めします。

        • コピーの操作は厳密には必要ありませんが、このサンプルの様々なユースケースでの作業の追跡に役立ち、以前の作業のバックアップが提供されます。

      • /tmp/sample/mii-update2.yamlドメインYAMLファイル名およびweblogic.domainUIDラベルをsample-domain2に変更します。

        最終的な結果は次のようになります:

        apiVersion: "weblogic.oracle/v9"
kind: Domain
metadata:
  name: sample-domain2
  namespace: sample-domain1-ns
  labels:
    weblogic.domainUID: sample-domain2

        ノート: sample-domain1と同じネームスペースにドメインsample-domain2をデプロイするため、ネームスペースsample-domain1-nsは変更されません。

      • /tmp/sample/mii-update2.yamlドメインYAMLファイルのCUSTOM_DOMAIN_NAME環境変数をdomain1からdomain2に変更します。

        イメージ内のモデル・ファイルでは、ドメイン名の設定時にマクロ@@ENV:CUSTOM_DOMAIN_NAME@@を使用してこの環境変数を参照します。

        具体的には、対応するドメインspec.serverPod.env YAMLファイル・スタンザを次のように変更します:

        ...
spec:
  ...
  serverPod:
  ...
    env:
    - name: CUSTOM_DOMAIN_NAME
      value: "domain2"
  ...

      • /tmp/sample/mii-update2.yamlドメインYAMLファイルのspec.domainHome値を/u01/domains/sample-domain2に変更します。 対応するYAMLファイル・スタンザは次のようになります: 

        ...
spec:
  ...
  domainHome: /u01/domains/sample-domain2
  ...

        (この変更は厳密には必要ありませんが、WebLogicドメインのホーム・ディレクトリをそのドメイン名またはドメインUIDで修飾することは有用な規則です。)

      • spec.webLogicCredentialsSecretスタンザおよびspec.configuration.secretsスタンザの/tmp/sample/mii-update2.yamlシークレット参照を、このユースケースのシークレットを参照するように変更します。 具体的な変更箇所は次のとおりです。 

        spec:
  ...
  webLogicCredentialsSecret:
    name: sample-domain1-weblogic-credentials
  ...
  configuration:
  ...
    secrets:
    - sample-domain1-datasource-secret
    ...
    model:
      ...
      runtimeEncryptionSecret: sample-domain1-runtime-encryption-secret

        これを次のように変更します。

        spec:
  ...
  webLogicCredentialsSecret:
    name: sample-domain2-weblogic-credentials
  ...
  configuration:
    ...
    secrets:
    - sample-domain2-datasource-secret
    ...
    model:
      ...
      runtimeEncryptionSecret: sample-domain2-runtime-encryption-secret

      • ドメインYAMLファイルのspec.configuration.model.configMap値をsample-domain1-wdt-config-mapからsample-domain2-wdt-config-mapに変更します。 対応するYAMLファイル・スタンザは次のようになります: 

        spec:
  ...
  configuration:
    ...
    model:
    ...
      configMap: sample-domain2-wdt-config-map

      • 次に、元のドメインYAMLファイルと変更されたドメインYAMLファイルを比較して、変更を再確認します。

        $ diff /tmp/sample/mii-update1.yaml /tmp/sample/mii-update2.yaml

        9c9
<   name: sample-domain1
---
>   name: sample-domain2
13c13
<     weblogic.domainUID: sample-domain1
---
>     weblogic.domainUID: sample-domain2
21c21
<   domainHome: /u01/domains/sample-domain1
---
>   domainHome: /u01/domains/sample-domain2
36c36
<     name: sample-domain1-weblogic-credentials
---
>     name: sample-domain2-weblogic-credentials
46c46
<   #logHome: /shared/logs/sample-domain1
---
>   #logHome: /shared/logs/sample-domain2
61c61
<       value: "domain1"
---
>       value: "domain2"
71c71
<     #    claimName: sample-domain1-weblogic-sample-pvc
---
>     #    claimName: sample-domain2-weblogic-sample-pvc
110c110
<       configMap: sample-domain1-wdt-config-map
---
>       configMap: sample-domain2-wdt-config-map
113c113
<       runtimeEncryptionSecret: sample-domain1-runtime-encryption-secret
---
>       runtimeEncryptionSecret: sample-domain2-runtime-encryption-secret
118c118
<     - sample-domain1-datasource-secret
---
>     - sample-domain2-datasource-secret

        ノート: diffにネームスペースの変更を含めないでください。 ドメインsample-domain2をsample-domain1 (ネームスペースsample-domain1-ns)と同じネームスペースにデプロイしています。

      • 変更したドメインYAMLファイルを適用します:

        ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxiliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。

        $ kubectl apply -f /tmp/sample/mii-update2.yaml

    • オプション2: サンプルに付属している更新されたドメインYAMLファイルを使用します:

      ノート: ドメイン・カスタム・リソースをデプロイする前に、Kubernetesクラスタauxiliary-imageおよびその他のイメージにアクセスできます内のすべてのノードを確認します。

      $ kubectl apply -f /tmp/sample/domain-resources/WLS/mii-update2-d2-WLS-v1-ds.yaml

  5. sample-domain2が起動するまで待機します。

    kubectl get pods -n sample-domain1-ns --watchを実行すると、sample-domain2実行のイントロスペクタ・ジョブが表示され、WebLogic Serverポッドが起動します。 出力は次のようになります:

    「ここをクリックして展開します。」

    このアクティビティの詳細を表示するには、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-domain2 -p Completed

  6. sample-domain2ドメインの実行後、サンプルwebアプリケーションをコールして、完全にアクティブであることを確認できます。

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

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

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

    $ kubectl exec -n sample-domain1-ns sample-domain2-admin-server -- bash -c \
  "curl -s -S -m 10 http://sample-domain2-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-domain2'
  domain name = 'domain2'

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」のsample-domain1のデータ・ソース属性を動的に修正するため、TestPool Failureが必要です。

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

このサンプルでは、sample-domain2ドメインを再度使用しません。必要に応じて、kubectl -n sample-domain1-ns delete domain sample-domain2をコールして今すぐ停止できます。

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