機械翻訳について

サンプル

目次

始める前に: 前提条件のステップを実行し、ドメイン作成イメージのビルドのステップを実行してDomain on PV domain creation imageをビルドします。 サンプル内でJRFパスを使用している場合は、イメージ名およびディレクトリ・パス内のWLSをJRFに置き換えます。 また、JRF-v1モデルYAMLファイルは、WLS-v1 YAMLファイルとは異なります(追加のdomainInfo -> RCUDbInfoスタンザが含まれています)。

概要

このサンプルは、Kubernetes PersistentVolume (PV) (Domain on PV)にドメイン・ホームを持つWebLogicドメインを設定する方法を示しています。 内容は次のとおりです。

  • 以前に作成した「ドメイン作成イメージ」を使用します。
  • ドメインのシークレットの作成。
  • 次を行うドメインのドメイン・リソースYAMLファイルの作成:
    • シークレットおよびWebLogicイメージを参照します。
    • WDTモデルYAMLを使用して定義された初期Domain on PV構成のspec.configuration.initializeDomainOnPVセクションのdomain creation imageを参照します。
    • PVおよびPVCを作成するためのPVおよびPVCメタデータと仕様をspec.configuration.initializeDomainOnPVセクションで定義します(オプション)。

PVおよびPVCのノート:

  • ドメイン・リソースYAMLファイルのspec.configuration.initializeDomainOnPVセクションで定義されたPersistentVolumeおよびPersistentVolumeClaimの指定は環境固有であり、多くの場合、Kubernetesクラスタ管理者からの情報を使用して情報を提供する必要があります。 詳細は、ユーザー・ドキュメントの「永続ボリュームと永続ボリューム要求」を参照してください。
  • ReadWriteManyオプションをサポートするストレージ・プロバイダを使用する必要があります。
  • このサンプルでは、永続ボリュームのドメイン・ホーム内のすべてのファイルの所有者がuid 1000に自動的に設定されます。 別のユーザーを使用する場合は、ドメインYAMLファイルのspec.serverPod.podSecurityContextセクションにあるセキュリティ・コンテキストで、必要なrunAsUserおよびrunAsGroupを構成します。 オペレータは、ドメイン・ホーム・ディレクトリ内のファイルの所有者を設定するときにこれらの値を使用します。

ドメインのデプロイ後、オペレータはPVおよびPVCを作成し(構成されていて、まだ存在しない場合)、domain creation imageおよびconfig mapに含まれるモデルをWebLogic構成に変換してDomain on PVを初期化するイントロスペクタ・ジョブを開始します。

ドメイン作成イメージ

このサンプルでは、「ドメイン作成イメージのビルド」ステップで作成したwdt-domain-image:WLS-v1という名前のdomain creation imageを使用しています。 このイメージのWDTモデル・ファイルは、初期WebLogic Domain on PV構成を定義します。 イメージには次のものが含まれます:

  • WebLogic Deploy Toolingソフトウェアがインストールされるディレクトリ(WDTホームとも呼ばれる)。デフォルトでは、イメージの/auxiliary/weblogic-deployディレクトリで想定されます。
  • WDTモデルYAML、プロパティおよびアーカイブ・ファイル。デフォルトでは、ディレクトリ/auxiliary/modelsに必要です。

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

この項では、PVおよびPVC構成を定義し、ドメイン・リソースYAMLファイルで以前に作成したdomain creation imageを参照します。 次に、次のステップを含む、ドメイン・リソースYAMLファイルをネームスペースsample-domain1-nsにデプロイします:

  • WebLogic管理者のユーザー名とパスワードを含むシークレットを作成します。
  • ドメイン・タイプがJRFの場合は、RCUアクセスURL、資格証明およびプレフィクスを含むシークレットを作成します。
  • PV/PVC構成を参照するドメインYAMLファイル、およびspec.configuration.initializeDomainOnPVセクションのdomain creation imageをデプロイします。
  • PVおよびPVCがまだ存在しない場合は、作成を待機します。
  • ドメインのポッドが起動し、準備完了状態になるまで待ちます。

シークレット

まず、WLSおよびJRFタイプの両方のモデル・ドメインに必要なシークレットを作成します。 WDTモデル・ファイルのマクロから参照されるWebLogic資格証明シークレットおよびその他のシークレットを作成する必要があります。 WDTモデル・ファイルでのマクロの使用の詳細は、「WDTモデル・ファイルの操作」を参照してください。

次のkubectlコマンドを実行して、必要なシークレットをデプロイします:

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

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

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

これらのシークレットに関する重要な詳細:

  • WebLogic資格証明シークレットは必須で、usernameおよびpasswordフィールドが含まれている必要があります。 これをドメインYAMLファイルのspec.webLogicCredentialsSecretフィールドで参照し、モデルYAMLファイルのdomainInfo.AdminUserNameおよびdomainInfo.AdminPassWordフィールドでマクロを参照します。
  • 作成する前にシークレットを削除してください。そうしないと、シークレットがすでに存在する場合に作成コマンドが失敗します。
  • 関連付けられたドメインUIDを使用してシークレットに名前を付け、ラベルを付けて、どのシークレットがどのドメインに属しているかを明確にし、ドメインのクリーンアップを容易にします。

サンプルを介してJRFパスに従っている場合は、JRFモデルのRCUDbInfo句でマクロによって参照される追加のシークレットと、OPSSウォレット・パスワード・シークレットもデプロイする必要があります。 これらのシークレットの使用方法の詳細は、Domain on PVのユーザー・ドキュメントを参照してください。

「JRFの追加シークレットをデプロイするためのコマンドは、ここをクリックしてください。」

ドメイン・リソース

ここで、両方のリソースを定義する単一のYAMLリソース・ファイルを使用して、sample-domain1ドメイン・リソースおよび関連するsample-domain1-cluster-1クラスタ・リソースをデプロイします。 ドメイン・リソースおよびクラスタ・リソースは、WebLogicドメインのデプロイ方法をオペレータに指示します。 従来のWebLogic構成ファイルは置換されませんが、かわりに、これらのファイルと連携して、対応するドメインのKubernetesアーティファクトを記述します。

サンプル・ソースに含まれている「WLSドメイン・リソースYAMLファイル」ファイルの内容を、/tmp/sample/domain-resource.yamlなどのファイルにコピーします。

「こちら」をクリックして、WLSドメインのYAMLファイルを表示します。

「こちら」をクリックして、JRFドメインのYAMLファイルを表示します。

環境に基づいて、ドメイン・リソースYAMLファイルのspec.configuration.initializeDomainOnPVセクションで定義されたPVおよびPVC仕様を変更します。 これらの指定では、多くの場合、Kubernetesクラスタ管理者に情報を提供する必要があります。 詳細は、ユーザー・ドキュメントの「永続ボリュームと永続ボリューム要求」を参照してください。

デフォルトでは、このサンプルはタイプhostPathの永続ボリューム(PV)を作成します。 これは、1つのノードKubernetesクラスタに対してのみ、テストまたは概念実証アクティビティで機能します。 マルチ・ノードKubernetesクラスタでは、Kubernetes StorageClass、またはnfs型のPVを使用することを検討してください。 Oracle Container Engine for Kubernetes (OKE)を使用し、PVにOracle Cloud Infrastructure File Storage (FSS)を使用する予定の場合、Oracleでは、initializeDomainOnPVセクションのPersistentVolumeClaim (PVC)構成にStorageClassを作成し、StorageClassの名前を指定することをお薦めします。 詳細は、OCIドキュメントの「ファイル・ストレージ・サービス(FSS)でのPVCのプロビジョニング」を参照してください。

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

次のコマンドを実行して、2つのサンプル・リソースを適用します。

$ kubectl apply -f /tmp/sample/domain-resource.yaml

ドメイン・リソースは、クラスタ・リソース、WebLogic Serverインストール・イメージ、定義したシークレット、PVおよびPVC構成の詳細、および従来のWebLogic構成とWebLogicアプリケーションを含むサンプルのdomain creation imageを参照します。 詳細については、「ドメインおよびクラスタ・リソース」を参照してください。

PV、PVCおよびドメインの確認

PV、PVC、およびドメインが作成されたことを確認するには、次の手順を使用します。

永続ボリュームの検証

オペレータがPVを作成するようにspec.configuration.initializeDomainOnPV.persistentVolumeが構成されている場合は、指定された名前のPVが作成され、ステータスがBoundであることを確認します。 PVがすでに存在する場合は、既存のPVがBoundステータスであることを確認します。 

$ kubectl get pv

このコマンドの出力例を次に示します:

NAME                                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                  STORAGECLASS   REASON   AGE
sample-domain1-weblogic-sample-pv   5Gi        RWX            Retain           Bound    sample-domain1-ns/sample-domain1-weblogic-sample-pvc   manual                  14m

永続ボリューム要求の検証

オペレータがPVCを作成するようにspec.configuration.initializeDomainOnPV.persistentVolumeClaimが構成されている場合は、指定された名前のPVCが作成され、ステータスがBoundであることを確認します。 PVCがすでに存在する場合は、既存のPVCがBoundステータスであることを確認します。 

$ kubectl get pvc -n sample-domain1-ns

このコマンドの出力例を次に示します:

NAME                                 STATUS   VOLUME                              CAPACITY   ACCESS MODES   STORAGECLASS   AGE
sample-domain1-weblogic-sample-pvc   Bound    sample-domain1-weblogic-sample-pv   5Gi        RWX            manual         11m

ドメインの検証

次のkubectl describe domainコマンドを実行して、作成されたドメインのステータスおよびイベントを確認します。

$ kubectl describe domain sample-domain1 -n sample-domain1-ns
「ここをクリックすると、このコマンドの出力例が表示されます。」

出力のStatusセクションに、使用可能なサーバーおよびクラスタがリストされます。 このコマンドがドメイン・リソースの適用後すぐに発行された場合、まだ使用可能なサーバーがないか、おそらく管理サーバーのみで管理対象サーバーがない可能性があります。 オペレータは最初に管理サーバーを起動し、準備ができるまで待機してから管理対象サーバーを起動します。

ポッドを確認

kubectl get pods -n sample-domain1-ns --watchを実行すると、イントロスペクタ・ジョブの実行および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-domain1 -p Completed

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

サービスの検証

次のコマンドを使用して、ドメインのサービスを表示します:

$ kubectl get services -n sample-domain1-ns

このコマンドの出力例を次に示します:

NAME                               TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
sample-domain1-admin-server        ClusterIP   None             <none>        7001/TCP   10m
sample-domain1-cluster-cluster-1   ClusterIP   10.107.178.255   <none>        8001/TCP   9m49s
sample-domain1-managed-server1     ClusterIP   None             <none>        8001/TCP   9m49s
sample-domain1-managed-server2     ClusterIP   None             <none>        8001/TCP   9m43s

webアプリケーションの起動

すべてのサンプル・リソースがデプロイされたので、Traefikイングレス・コントローラのNodePortを使用してサンプルwebアプリケーションを起動できます。

  • 次の例に示すように、アプリケーションのロード・バランサURLにwebアプリケーション・リクエストを送信します。

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

        $ K8S_CLUSTER_ADDRESS=$(kubectl cluster-info | grep DNS | sed 's/^.*https:\/\///g' | sed 's/:.*$//g')

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

  • 出力は次のようになります:

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

   Hello World! This is version 'v1' 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: 1

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

   Found 0 local data sources:

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

リソースをクリーン・アップし、生成されたドメイン・ホームを削除

クリーンアップ手順「こちら」に従って、ドメイン、クラスタおよびその他の関連リソースを削除します。

本番環境ではありますが、ほとんどの場合はテスト環境で、このサンプルを使用して生成されたDomain on PVコンテンツを削除することもできます。 このために、ドメイン・ライフサイクル・ディレクトリでpv-pvc-helper.shヘルパー・スクリプトを使用できます。 このスクリプトは、指定された永続ボリューム要求名とマウント・パスを使用して、pvhelperという名前のKubernetesポッドを起動します。 kubectl execを実行して、実行中のポッド・コンテナにシェルを取得し、コマンドを実行して永続ボリューム上の共有ディレクトリの内容を確認またはクリーン・アップできます。 例えば: 

$ cd /tmp/weblogic-kubernetes-operator/kubernetes/samples/scripts/domain-lifecycle
$ ./pv-pvc-helper.sh -n sample-domain1-ns -r -c sample-domain1-weblogic-sample-pvc -m /shared
「ここをクリックして出力を表示します。」

実行中のポッド・コンテナにシェルが表示された後、rm -rf /shared/domains/sample-domain1およびrm -rf /shared/applications/sample-domain1コマンドを使用して、ドメイン・ホームおよびアプリケーション・ディレクトリの内容を再帰的に削除できます。 これらのコマンドは、永続ストレージ上のファイルを実際に削除するため、これらのコマンドを慎重に理解して実行することをお薦めします。

PVCおよびPVの削除

PVCおよびPVがオペレータによって作成され、保持しない場合は、次のコマンドを実行してPVCおよびPVを削除します。

$ kubectl delete pvc sample-domain1-weblogic-sample-pvc -n sample-domain1-ns
$ kubectl delete pv sample-domain1-weblogic-sample-pv

ドメイン・ネームスペースを削除します。

$ kubectl delete namespace sample-domain1-ns