使用

このドキュメントでは、通常のドメイン・ホームを永続ボリューム(Domain on PV)に作成およびデプロイする方法について説明します。

WebLogic Kubernetes Operator

演算子をデプロイし、Domain on PVドメインの目的のネームスペースをモニタリングしていることを確認します。「オペレータの管理」および「クイック・スタート」を参照してください。

構成

オペレータ・バージョン4.1.0から、セクションdomain.spec.configuraiton.initializeDomainOnPVを指定して、永続ボリュームが最初にデプロイされたときに、永続ボリュームのWebLogicドメインを初期化できます。これは「1回のみ」の初期化です。ドメインの作成後、ドメイン・リソースYAMLファイルのこのセクションに対する後続の更新では、WebLogicドメインの再作成または更新は行われません。

この機能を使用するには、次の情報を指定します:

「WebLogicベース・イメージ」 - これは、WebLogic ServerやFusion Middleware Infrastructureなど、使用するFusion Middlewareソフトウェアです。
「ボリュームおよびVolumeMounts情報」 - これは、永続ボリュームをマウントするための標準のKubernetesポッド要件に従います。
「PersistentVolumeおよびPersistentVolumeClaim」 - これは環境固有であり、通常は、storageClassや任意の権限などの基礎となる詳細を提供するための管理者からの支援が必要です。
「ドメイン情報」 - ここでは、ドメイン・タイプと、オペレータがRCUスキーマを作成する必要があるかどうかについて説明します。
「ドメインのWDTモデル」 - WDTホーム、WDTモデル、WDTアーカイブ、およびWDT変数ファイルが存在する場所です。
「オプションのWDTモデルConfigMap」 - オプションのWDTモデル、WDT変数ファイル。
「ドメイン・リソースYAMLファイル」 - これは、WebLogic Kubernetes Operatorにドメインをデプロイするためのものです。

各フィールドの詳細は、ドメイン・リソースschemaのinitializeDomainOnPVセクションを参照するか、コマンドkubectl explain domain.spec.configuration.initializeDomainOnPVを使用します。

基本的な構成の例は、「基本構成」を参照してください。

WebLogicベース・イメージ

ドメインは永続ボリュームに作成されるため、ベース・イメージにはFMW製品バイナリとJDKのみを含める必要があります。

spec:
  image: "container-registry.oracle.com/middleware/fmw-infrastructure_cpu:12.2.1.4-jdk8-ol8-221014"

独自のイメージを指定したり、container-registry.oracle.comからパッチを適用したイメージを使用したり、WebLogic Image Tool (WIT)を使用してイメージを作成してパッチ適用できます。

ドメイン作成のWDTモデル

ドメイン・リソースYAMLファイル内のドメイン・トポロジ、リソースおよびアプリケーションを記述するイメージを指定します。

     domain:
          domainCreationImages:
            - image: 'myrepo/domain-images:v1'

フィールド	ノート	値	必須
`domainCreationImages`	WDTドメイン・イメージ。	イメージの配列。	Y

このイメージでは、必要なWDT 「インストーラ」、およびWDTモデル・ファイル、WDT変数ファイル、およびWDTアーカイブ・ファイルを指定する必要があります。オペレータはこれらを使用して初期ドメインを作成します。

domainCreationImages内の追加オプションについては、次のコマンドを使用して詳細を取得します。

$ kubectl explain domain.spec.configuration.initializeDomainOnPV.domain.domainCreationImages

イメージ・レイアウトは、次のディレクトリ構造に従います:

/auxiliary/weblogic-deploy - The directory where the WebLogic Deploy Tooling software is installed.
/auxiliary/models -  WDT model, WDT archive, and WDT variables files.

使い慣れたメソッドを使用して独自のイメージを作成することも、WebLogic Image Tool(WIT)を使用することもできます。

たとえば、ファイル構造はModel in Imageドメイン・ホームのソース・タイプで使用される「補助イメージ」と同じであるため、同じWITコマンドcreateAuxImageを使用できます。

$ imagetool.sh createAuxImage --wdtArchive /home/acme/myapp/wdt/myapp.zip \
   --wdtVersion latest \
   --wdtModel /home/acme/myapp/wdt/model1.yaml \
   --wdtVariables /home/acme/myapp/wdt/model1.properties \
   --tag myrepo/domain-images:v1

オプションのWDTモデルConfigMap

オプションで、Kubernetes ConfigMapに、追加のWDTモデルおよびWDT変数ファイルを補足として提供したり、domainCreationImagesのものにオーバーライドすることができます。

     domain:
          ...
          domainCreationImages:
              ...
          domainCreationConfigMap: mymodel-domain-configmap

フィールド	ノート	値	必須
`domainCreationConfigMap`	ConfigMap内のオプションのWDTモデルおよびWDT変数ファイル。	ConfigMap名。	N

このConfigMap内のファイルには、ファイル拡張子.yaml、.propertiesまたは.zipが必要です。

ボリュームおよびVolumeMounts情報

domain.spec.serverPodにvolumesおよびvolumeMounts情報を指定する必要があります。これにより、ポッドは実行時に永続ストレージをマウントできます。 mountPathは、ドメイン・ホームおよびログ・ホームの一部である必要があります。persistentVolumeClaim.claimNameは、既存のPVCであるか、オペレータが作成するPVCであるかに関係なく、有効なPVC名である必要があります。「オペレータによるPVCの作成」を参照してください。

spec:
  domainHome: /share/domains/domain1
  logHome: /share/logs/domain1
  serverPod:
    volumes:
      - name: weblogic-domain-storage-volume
        persistentVolumeClaim:
          claimName: sample-domain1-pvc-rwm1
    volumeMounts:
      - mountPath: /share
        name: weblogic-domain-storage-volume

永続ボリュームおよび永続ボリューム要求

Kubernetes PersistentVolume (PV)およびPersistentVolumeClaim (PVC)は、Kubernetes環境内の永続ストレージにアクセスするためにKubernetesで使用されます。既存のPV/PVCを使用するか、オペレータがそれらを作成するようにリクエストできます。

PersistentVolumeおよびPersistentVolumeClaimの指定は環境固有であり、多くの場合、Kubernetesクラスタ管理者からの情報が必要です。様々な環境での「永続ストレージ」を参照してください。

PVおよびPVCの要件

Domain on PVでは、PVおよびPVCがFilesystemボリューム・モードで作成されている必要があります。Blockボリューム・モードはサポートされていません。
- オペレータがPVおよびPVCを作成するようにリクエストした場合は、デフォルトのFilesystemボリューム・モードが使用されます。
- 既存のPVおよびPVCを使用する予定の場合は、Filesystemボリューム・モードで作成されたことを確認します。
ReadWriteManyオプションをサポートするストレージ・プロバイダを使用する必要があります。
オペレータは、永続ボリュームのドメイン・ホーム内のすべてのファイルの所有者を、gid 0を使用してuid 1000に自動的に設定します。別のユーザーおよびグループを使用する場合は、ドメインYAMLファイルのspec.serverPod.podSecurityContextセクションにあるセキュリティ・コンテキストで、必要なrunAsUserおよびrunAsGroupを構成します。オペレータは、ドメイン・ホーム・ディレクトリ内のファイルの所有者を設定するときにこれらの値を使用します。

たとえば、ドメイン・リソースYAMLファイルでPersistent VolumeおよびPersistent Volume Claimを指定した場合、
次に、オペレータはPVおよびPVCを作成し、永続ボリュームを/shareディレクトリにマウントします。

spec:
  domainHome: /share/domains/domain1
  serverPod:
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
         claimName: sample-domain1-pvc-rwm1
    volumeMounts:
    - mountPath: /share
      name: weblogic-domain-storage-volume

  configuration:
    initializeDomainOnPV:
      waitForPvcToBind: true
      persistentVolume:
        metadata:
            name: sample-domain1-pv-rwm1
        spec:
            storageClassName: my-storage-class
            capacity:
                storage: 20Gi
            persistentVolumeReclaimPolicy: Retain
            hostPath:
                path: "/share"
      persistentVolumeClaim:
        metadata:
            name: sample-domain1-pvc-rwm1
        spec:
            storageClassName: my-storage-class
            resources:
                requests:
                    storage: 10Gi

フィールド	ノート	値	必須
`waitForPvcToBind`	オペレータがPVCの作成時にPVCが`bound`状態になるまで待機するかどうかを指定します。一部のクラウド環境では、PVCが実行中のポッドで実際に使用されるまで、PVCは`pending`状態になります。必要に応じて`false`に設定します。	Boolean	N (デフォルト`true`)
`persistentVolume`	オペレータが作成している場合の永続ボリュームの指定。	オペレータで永続ボリュームを作成する場合の永続ボリュームの指定。	N (オペレータは永続ボリュームを作成しません)
`persistentVolumeClaim`	オペレータが作成している場合の永続ボリューム要求の指定。	オペレータで永続ボリューム要求を作成する場合は、その指定。	N (オペレータは永続ボリューム要求を作成しません)

標準のKubernetes PVおよびPVCのすべてのフィールドがサポートされているわけではありません。 persistentVolumeおよびpersistentVolumeClaimでサポートされているフィールドのリストについては、ドメイン・リソースschemaのinitializeDomainOnPV.peristentVolumeおよびinitializeDomainOnPV.peristentVolumeClaimの項を参照するか、次のコマンドを使用します:

 $ kubectl explain domain.spec.configuration.initializeDomainOnPV.persistentVolume
 $ kubectl explain domain.spec.configuration.initializeDomainOnPV.persistentVolumeClaim

PVおよびPVCが環境内にすでに存在する場合は、intializedDomainOnPVセクションの下にpersistentVolumeまたはpersistentVolumeClaimを指定する必要はありません。

リファレンス

ドメイン情報

JRFベースのドメインの場合は、先に進む前に、必ずこのドキュメントをお読みください、「JRFドメイン」。

これは、WebLogicドメインについて説明する項です。例えば:

spec:
  domainHome: /share/domains/sample-domain1
  domainHomeSourceType: PersistentVolume

  configuration:
    secrets: [ sample-domain1-rcu-access ]
    initializeDomainOnPV:
      ...
      domain:
          # Domain | DomainAndRCU
          createIfNotExists: DomainAndRCU
          domainCreationImages:
            - image: 'myrepo/domain-images:v1'
          domainType: JRF
          domainCreationConfigMap: sample-domain1-wdt-config-map
          opss:
           walletPasswordSecret: sample-domain1-opss-wallet-password-secret

フィールド	ノート	値	必須
`domainType`	作成されたドメインのタイプ。	`JRF` または`WLS`	N (デフォルト`WLS`)
`createIfNotExists`	オペレータがドメインを作成する前に、最初にRCUスキーマを作成する必要があるかどうかを指定します。	`Domain`または`DomainAndRCU` (既存のRCUスキーマの削除および新しいRCUスキーマの作成)	N (デフォルト`Domain`)
`domainCreationImages`	WDTドメイン・イメージ。	イメージの配列。	Y
`domainCreationConfigMap`	追加のWDTモデルを含むオプションのConfigMap。	Kubernetes ConfigMap名。	N
`osss.walletPasswordSecret`	JRFドメインのOPSSウォレットを抽出するためのパスワード。	Kubernetesキー`walletPassword`のシークレット名。	Y
`osss.walletFileSecret`	OPSSウォレット・ファイルを抽出しました。	Kubernetesキー`walletFile`のシークレット名。	N (障害リカバリ中にドメインを再作成する場合にのみ必要)

JRFドメインが正常にデプロイされた後: 次の項ベスト・プラクティスに従って、OPSSウォレットをダウンロードしてバックアップします。

ベスト・プラクティス

Oracleでは、最初のJRFドメインの作成後に、OPSSウォレット・ファイルを安全なバックアップ・ロケーション「すぐに」に保存することをお薦めします。また、必ず同じネームスペースのKubernetesシークレットにウォレットを格納してください。これにより、ディザスタ・シナリオでドメインをリカバリする必要がある場合、またはドメイン・ディレクトリが破損した場合に、シークレットを使用できるようになります。この特定のウォレット・キーなしで元のRCUスキーマを再利用する方法はありません。したがって、障害時リカバリの場合は、「このOPSSウォレットをバックアップする必要があります」です。

JRFドメイン・ホーム・ディレクトリおよびデータベースのバックアップ

Oracleでは、初期JRFドメインの作成後にドメイン・ホーム・ディレクトリおよびデータベースをバックアップしてから、定期的にすべての最新の変更がバックアップされるようにすることをお薦めします。

JRFドメインは、RCUスキーマと1対1の関係を持ちます。特定のRCUスキーマを使用してドメインを作成した後、そのスキーマを別のドメインで再利用することはできず、同じスキーマを異なるドメイン間で共有することもできません。既存のRCUスキーマを使用して新しいドメインを作成しようとすると、エラーが発生します。

ドメイン・ホームが正しくバックアップされていない場合、ドメイン・ホームが破損または削除されると、既存のデータが失われる可能性があります。これは、ドメインを再作成するには、既存のRCUスキーマを削除し、新しいRCUスキーマを作成する必要があるためです。したがって、既存のドメイン・ホームのバックアップは、Kubernetes環境で最も高い優先度である必要があります。

Domain on PVドメイン構成は、初期デプロイメント後に更新される場合があります。たとえば、WLSTまたはコンソールを使用して、新しいアプリケーションのデプロイ、カスタムOPSSキーストアの追加、OWSMポリシーの追加などを行ったとします。この場合、初期ドメインの作成に使用される元のWDTモデル・ファイルは、ドメインの現在の状態とは一致しません(WDTモデル・ファイルは正しいソースではありません)。したがって、元のWDTモデル・ファイルを使用してドメインを再作成すると、その後の更新がすべて失われます。ドメインの更新を保持するには、ドメイン・ホーム・ディレクトリのバックアップ・コピーからドメインをリストアし、データベース・バックアップから既存のRCUスキーマに接続する必要があります。

OPSSウォレットをKubernetesシークレットに格納し、ドメイン・リソースの`opss.walletFileSecret`を更新

ドメインの作成後、オペレータはOPSSウォレットを自動的にエクスポートし、イントロスペクタConfigMapに格納します。ConfigMapの名前は、パターン<domain uid>-weblogic-domain-introspect-cmの後にキーewallet.p12が付きます。 Oracleでは、最初のJRFドメインの作成後に、OPSSウォレット・ファイルを安全なバックアップ・ロケーション「すぐに」に保存することをお薦めします。また、必ず同じネームスペースのKubernetesシークレットにウォレットを格納してください。これにより、ディザスタ・シナリオでドメインをリカバリする必要がある場合、またはドメイン・ディレクトリが破損した場合に、シークレットを使用できるようになります。

KubernetesシークレットにOPSSウォレットを格納するステップの概要を次に示します。

オペレータには、ウォレット・ファイルを抽出してKubernetes walletFileSecretに格納するためのユーティリティ・スクリプト「OPSSウォレット・ユーティリティ」が用意されています。また、Kubernetesの外部で安全にバックアップされたロケーションにウォレット・ファイルを保存する必要もあります。たとえば、次のコマンドは、sample-nsネームスペースのsample-domain1ドメインのOPSSウォレットを/tmpディレクトリのewallet.p12という名前のファイルに保存し、jrf-wallet-file-secretという名前のウォレット・シークレットにも格納します。
```
$ opss-wallet.sh -n sample-ns -d sample-domain1 -s -r -wf /tmp/ewallet.p12 -ws jrf-wallet-file-secret
```
前のコマンドの/tmp/ewallet.p12を安全なロケーションに格納するファイルの名前に置き換え、jrf-wallet-file-secretを任意のシークレット名に置き換えます。詳細は、READMEファイルのOPSS wallet utilityセクションを参照してください。
抽出したウォレット・ファイル(この例では/tmp/ewallet.p12)を、Kubernetesの外部の安全なロケーションに保存します。

configuration.initializeDomainOnPV.domainの下のドメイン・リソースYAMLファイルにopss.walletFileSecretを追加します。

  ...
  configuration:
    initializeDomainOnPV:
    ...
      domain:
        ...
        opss:
          walletFileSecret: jrf-wallet-file-secret
          ...

次のpatchコマンドを使用して、ドメイン・リソースに追加できます。

$ kubectl -n sample-ns patch domain sample-domain1 --type='JSON' -p='[ { "op" : "add", "path" : "/spec/configuration/initializeDomainOnPV/domain/opss/walletFileSecret", "value" : "jrf-wallet-file-secret" }]'

ドメインが破損した場合または他の障害シナリオでリカバリする場合

ドメイン・ホーム・ディレクトリが破損しており、ドメイン・ホーム・ディレクトリの最近のバックアップがある場合は、次のステップを実行してドメインをリカバリします。

バックアップ・コピーからドメイン・ホーム・ディレクトリをリストアします。

ドメインを再起動するには、ドメイン・リソースのrestartVersionを更新します。たとえば、

$ kubectl -n sample-ns patch domain sample-domain1 --type='JSON' -p='[ { "op" : "replace", "path" : "/spec/restartVersion", "value" : "15" }]'

ドメインの再起動後、WebLogicドメイン構成を確認し、最新の変更があることを確認します。 ノート: 前回のバックアップ後にドメイン・ホーム・ディレクトリに保持されている変更を行った場合は、それらの変更をドメイン・ホーム・ディレクトリに再適用する必要があります。ただし、オペレータが同じRCUスキーマに再接続されるため、OPSS表、MDS表またはOWSM表に格納されているデータが最新になります。
最後のバックアップの後、ドメイン・ホーム・ディレクトリ(データ・ソース接続、JMS宛先、新しいアプリケーションEARデプロイメントなど)に保持されているドメイン構成の変更をすべて再適用します。これらの変更を行うには、WLST、WebLogic Server管理コンソールまたはEnterprise Managerを使用します。

ドメイン・ホーム・ディレクトリが破損し、ドメイン・ホーム・ディレクトリの最新のバックアップがない場合、またはバックアップ・コピーも破損している場合は、RCUスキーマ・データを失うことなく、WDTモデル・ファイルからドメインを再作成できます。

永続ボリュームからドメイン・ホーム・ディレクトリを削除します。
ドメイン・リソースのdomain.spec.introspectVersionを新しい値で追加または置換します。次に、サンプル・ドメインのintrospectVersionを更新するためのサンプルpatchコマンドを示します。
```
$ kubectl -n sample-ns patch domain sample-domain1 --type='JSON' -p='[ { "op" : "replace", "path" : "/spec/intropsectVersion", "value" : "15" }]'
```
オペレータは、既存のWDTモデルから新しいドメインを作成し、元のRCUスキーマを再利用します。

ノート: 最初のデプロイメント後にドメインに加えられたすべての更新は、回復されたドメインでは使用できません。ただし、これにより、すべてのデータを失うことなく、元のRCUスキーマ・データベースにアクセスできます。
ドメイン・ホーム・ファイル・システムに保持されているすべてのドメイン構成変更(データ・ソース接続、JMS宛先、新しいアプリケーションEARデプロイメントなど)を適用します。この変更は、WDTモデル・ファイルには含まれません。これらは、初期ドメイン・デプロイメント後に行った変更です。

ドメインを再起動するには、ドメイン・リソースのrestartVersionを更新します。

$ kubectl -n sample-ns patch domain sample-domain1 --type='JSON' -p='[ { "op" : "replace", "path" : "/spec/restartVersion", "value" : "15" }]'

詳細については、「障害時リカバリ」を参照してください。

トラブルシューティング

問題: イントロスペクタ・ジョブでエラーが発生しました。

ドメインのドメイン・ステータスを確認します。
```
$ kubectl -n <domain namespace> get domain <domain uid>
```
logHomeのドメイン・ログ・ファイルを確認します。

デフォルトでは、オペレータはイントロスペクタ・ジョブ、RCUログおよびWebLogicサーバー・ログのログ・ファイルをdomain.spec.logHomeに保持します(デフォルト): /share/logs/<domain uid> ).

エラーがある場合は、関連する出力ファイルがlogHomeディレクトリにあります。例えば:
```
admin-server.log                  
introspector_script.out
createDomain.log
wdt_output.log             
admin-server.out
...                 
rculogdir/**
```
オペレータ・ログを確認してください。オペレータ・ログで追加のエラー・メッセージが使用できる場合があります。
```
$ kubectl -n <operator namespace> logs <operator pod name>
```

Kubernetesイベントを確認します。

$ kubectl -n <domain namespace> get events

問題: WDTモデルを更新しましたが、変更はドメインに反映されません。

これは予想された動作です。ドメイン・イメージまたはConfigMapで指定されたWDTドメイン・モデルは、「1回のみ」操作です。これらは初期ドメインの作成にのみ使用されます。ドメインの作成後は、ライフサイクル操作に参加しません。 WebLogicコンソール、WLSTまたはその他の方法を使用して、ドメインを更新する必要があります。更新されたモデルを使用してドメインを再作成するには、ドメインを再作成する前に、ドメイン・ホーム・ディレクトリおよびJRFドメイン(ドメイン・ホーム・ディレクトリの親の下にあるapplications/<domain uid>)のアプリケーション・ディレクトリも削除する必要があります。

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

クリーンアップ

JRFドメインのドメイン・ホームおよびアプリケーション・ディレクトリを削除する必要がある場合、エラーからリカバリする場合、またはドメイン・ホームを再作成する必要がある場合、ドメイン・ホームはdomain.spec.domainHomeで指定されたディレクトリにあり、JRFドメインのアプリケーション・ディレクトリ(WDTモデルで指定されていない場合)は<parent directory of domain home>/applications/<domain uid>にあります。次の操作を実行できます:

基礎となるストレージ・ボリュームが動的に割り当てられる場合は、ReclaimPolcy: deleteを使用してPVCを削除し、PVCを再作成します。
共有ボリュームにポッドをアタッチし、ポッドにアクセスしてコンテンツを削除します。サンプル・スクリプト「PVおよびPVCヘルパー・スクリプト」を参照してください。

ドメイン・リソースを削除します。

$ kubectl -n <namespace> delete -f <domain resource YAML>

構成例

次の構成例は、基本構成を示しています。

基本構成

spec:
  domainHome: /share/domains/sample-domain1
  domainHomeSourceType: PersistentVolume
  image: "container-registry.oracle.com/middleware/fmw-infrastructure_cpu:12.2.1.4-jdk8-ol8-221014"
  imagePullPolicy: "IfNotPresent"
  imagePullSecrets:
  - name: ocir-credentials
  webLogicCredentialsSecret:
    name: sample-domain1-weblogic-credentials
  logHomeEnabled: true
  logHome: /share/logs/sample-domain1
  serverPod:
    env:
    - name: JAVA_OPTIONS
      value: "-Dweblogic.StdoutDebugEnabled=false -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=DemoTrust -Dweblogic.debug.DebugManagementServicesResource=true"
    - name: USER_MEM_ARGS
      value: "-XX:+UseContainerSupport -Djava.security.egd=file:/dev/./urandom "
    # set up pod to use persistent storage using pvc
    # domain home must be under the mountPath  
    volumes:
    - name: weblogic-domain-storage-volume
      persistentVolumeClaim:
         claimName: sample-domain1-pvc-rwm1
    volumeMounts:
    - mountPath: /share
      name: weblogic-domain-storage-volume
  clusters:
  - name: sample-domain1-cluster-1
  replicas: 2

  configuration:
    secrets: [ sample-domain1-rcu-access ]
    initializeDomainOnPV:
      persistentVolume:
        metadata:
            name: sample-domain1-pv-rwm1
        spec:
            storageClassName: my-storage-class
            capacity:
                storage: 20Gi
            persistentVolumeReclaimPolicy: Retain
            hostPath:
                path: "/share"
      persistentVolumeClaim:
        metadata:
            name: sample-domain1-pvc-rwm1
        spec:
            storageClassName: my-storage-class
            resources:
                requests:
                    storage: 10Gi
      domain:
          # Domain | DomainAndRCU
          createIfNotExists: DomainAndRCU
          domainCreationImages:
            - image: 'myrepo/domain-images:v1'
          domainType: JRF
          domainCreationConfigMap: sample-domain1-wdt-config-map
          opss:
           walletPasswordSecret: sample-domain1-opss-wallet-password-secret

使用

目次