> サンプル > Tanzu Kubernetes Service

Tanzu Kubernetes Service

このサンプルは、WebLogic Kubernetes Operator (以降「オペレータ」)を使用して、Tanzu Kubernetes Grid (TKG)にWebLogic Server (WLS)クラスタを設定する方法を示しています。サンプル・ステップを実行すると、Model in Imageドメイン・ソース・タイプのWLSドメインがTKG Kubernetesクラスタ・インスタンスで実行されます。ドメインがプロビジョニングされたら、WebLogic Server管理コンソールを使用して監視できます。

TKGは、Kubernetesクラスタを迅速にデプロイおよび管理できる管理対象Kubernetesサービスです。詳細は、Tanzu Kubernetes Grid (TKG)の概要ページを参照してください。

前提条件

このサンプルでは、次の前提条件の環境設定を想定しています:

WebLogic Kubernetes Operator: このドキュメントは、バージョンv3.1.0でテストされました。
オペレーティング・システム: GNU/Linux.
Git; git --versionを使用して、gitが動作するかどうかをテストします。このドキュメントは、バージョン2.17.1でテストされました。
TKG CLI; tkg versionを使用して、TKGが機能するかどうかをテストします。このドキュメントは、バージョンv1.1.3でテストされました。
kubectl: kubectl versionを使用して、kubectlが動作するかどうかをテストします。このドキュメントは、バージョンv1.18.6でテストされました。
Helmバージョン3.1以上。helm versionを使用してhelmバージョンを確認します。このドキュメントは、バージョンv3.2.1でテストされました。

Tanzuに固有の一般的なオペレータの前提条件およびオペレータ・サポートの制限については、「サポートされている環境」を参照してください。

Tanzu Kubernetesクラスタの作成

TKG CLIを使用してKubernetesクラスタを作成します。「Tanzuドキュメント」を参照して、Kubernetesクラスタを設定します。 Kubernetesクラスタが稼働したら、次のコマンドを実行して、kubectlがKubernetesクラスタにアクセスできることを確認します:

$ kubectl get nodes -o wide

NAME                                    STATUS     ROLES    AGE     VERSION            INTERNAL-IP       EXTERNAL-IP       OS-IMAGE                 KERNEL-VERSION   CONTAINER-RUNTIME
k8s-cluster-101-control-plane-8nj7t     NotReady   master   2d20h   v1.18.6+vmware.1   192.168.100.147   192.168.100.147   VMware Photon OS/Linux   4.19.132-1.ph3   containerd://1.3.4
k8s-cluster-101-md-0-577b7dc766-552hn   Ready      <none>   2d20h   v1.18.6+vmware.1   192.168.100.148   192.168.100.148   VMware Photon OS/Linux   4.19.132-1.ph3   containerd://1.3.4
k8s-cluster-101-md-0-577b7dc766-m8wrc   Ready      <none>   2d20h   v1.18.6+vmware.1   192.168.100.149   192.168.100.149   VMware Photon OS/Linux   4.19.132-1.ph3   containerd://1.3.4
k8s-cluster-101-md-0-577b7dc766-p2gkz   Ready      <none>   2d20h   v1.18.6+vmware.1   192.168.100.150   192.168.100.150   VMware Photon OS/Linux   4.19.132-1.ph3   containerd://1.3.4

Oracle Container Registry

Oracle Container Registryアカウントが必要です。次のステップでは、WebLogic ServerイメージをプルするためにOracleの標準条件および制限を受け入れるように指示します。 Oracle Accountのパスワードと電子メールをノートにとります。このサンプルは12.2.1.4に関連していますが、他のバージョンも動作する場合があります。

WebLogic Kubernetes Operatorのインストール

WebLogic Kubernetes Operatorは、WebLogic ServerおよびKubernetesを統合するアダプタで、KubernetesはWLSインスタンスをホストするコンテナ・インフラストラクチャとして機能できます。オペレータはKubernetesポッドとして実行され、KubernetesでのWLSの実行に関連するアクションを実行する準備ができています。

WebLogic Kubernetes Operatorリポジトリをマシンにクローニングします。このリポジトリ内のいくつかのスクリプトを使用して、WebLogicドメインを作成します。 Kubernetes Operatorsは、Helmを使用してKubernetesアプリケーションを管理します。オペレータのHelmチャートは、kubernetes/charts/weblogic-operatorディレクトリにあります。次のコマンドを実行して、オペレータをインストールします。

リポジトリをクローニングします。

$ git clone --branch v4.2.8
 https://github.com/oracle/weblogic-kubernetes-operator.git

$ cd weblogic-kubernetes-operator

Helmサービス・アカウントにcluster-adminロールを付与します。

$ cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: helm-user-cluster-admin-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system
EOF

オペレータのネームスペースおよびサービス・アカウントを作成します。

$ kubectl create namespace sample-weblogic-operator-ns

namespace/sample-weblogic-operator-ns created

$ kubectl create serviceaccount -n sample-weblogic-operator-ns sample-weblogic-operator-sa

serviceaccount/sample-weblogic-operator-sa created

オペレータをインストールします。

$ helm install weblogic-operator kubernetes/charts/weblogic-operator \
  --namespace sample-weblogic-operator-ns \
  --set serviceAccount=sample-weblogic-operator-sa \
  --wait

NAME: weblogic-operator
LAST DEPLOYED: Tue Nov 17 09:33:58 2020
NAMESPACE: sample-weblogic-operator-ns
STATUS: deployed
REVISION: 1
TEST SUITE: None

次のコマンドを使用してオペレータを確認します。ステータスはrunningになります。

$ helm list -A

NAME                        NAMESPACE                     REVISION   UPDATED                                 STATUS       CHART                   APP VERSION
sample-weblogic-operator    sample-weblogic-operator-ns   1          2020-11-17 09:33:58.584239273 -0700 PDT deployed     weblogic-operator-3.1

$ kubectl get pods -n sample-weblogic-operator-ns

NAME                                 READY   STATUS    RESTARTS   AGE
weblogic-operator-775b668c8f-nwwnn   1/1     Running   0          32s

イメージの作成

イメージ作成の前提条件

JAVA_HOME環境変数を設定し、有効なJDK 8または11インストールを参照する必要があります。
サンプルを新しいディレクトリにコピーします。たとえば、ディレクトリ/tmp/mii-sampleを使用します。

$ mkdir /tmp/mii-sample

$ cp -r /root/weblogic-kubernetes-operator/kubernetes/samples/scripts/create-weblogic-domain/model-in-image/* /tmp/mii-sample

ノート: サンプルのこの作業用コピーを/tmp/mii-sampleと呼びますが、別のロケーションを使用できます。

最新のWebLogic Deploying Tooling (WDT)およびWebLogic Image Tool (WIT)インストーラZIPファイルを/tmp/mii-sample/model-imagesディレクトリにダウンロードします。 Model in Imageコンテナ・イメージを作成するには、WDTとWITの両方が必要です。

$ cd /tmp/mii-sample/model-images

$ curl -m 120 -fL https://github.com/oracle/weblogic-deploy-tooling/releases/latest/download/weblogic-deploy.zip \
  -o /tmp/mii-sample/model-images/weblogic-deploy.zip

$ curl -m 120 -fL https://github.com/oracle/weblogic-image-tool/releases/latest/download/imagetool.zip \
  -o /tmp/mii-sample/model-images/imagetool.zip

WebLogic Image Toolを設定するには、次のコマンドを実行します:

$ cd /tmp/mii-sample/model-images

$ unzip imagetool.zip

$ ./imagetool/bin/imagetool.sh cache addInstaller \
  --type wdt \
  --version latest \
  --path /tmp/mii-sample/model-images/weblogic-deploy.zip

これらのステップでは、WITを/tmp/mii-sample/model-images/imagetoolディレクトリにインストールし、さらにWDT ZIPファイル・インストーラを指すwdt_latestエントリをツールのキャッシュに配置します。 WITは、サンプルの後半でモデル・イメージの作成に使用します。

イメージの作成 - 導入

イメージ作成の目的は、WebLogic Image Toolを使用して、/tmp/mii-sample/model-images/model-in-image:WLS-v1/にステージングするファイルからmodel-in-image:WLS-v1という名前のイメージを作成する方法を示すことです。ステージングされたファイルには、WDTアーカイブ内のwebアプリケーションと、admin-serverというWebLogic管理サーバーおよびcluster-1というWebLogicクラスタのWDTモデル構成が含まれます。

全体として、Model in Imageイメージの/u01/wdt/weblogic-deployディレクトリには、WebLogic ServerインストールとWebLogic Deploy Toolingインストールが含まれている必要があります。また、WDTモデルのアーカイブ・ファイルがある場合、イメージの/u01/wdt/modelsディレクトリにもこれらのファイルが含まれている必要があります。最後に、イメージにWDTモデルYAMLファイルとプロパティ・ファイルを同じ/u01/wdt/modelsディレクトリに含めることもできます。 WDTモデルYAMLファイルを/u01/wdt/modelsディレクトリに指定しない場合は、ドメインspec.model.configMapフィールドで参照されるKubernetes ConfigMapを使用して、モデルYAMLファイルを動的に指定する必要があります。このサンプルの後半で、モデルConfigMapの使用例を示します。

次の各項では、イメージmodel-in-image:WLS-v1を作成するステップについて説明します。

最初のアーカイブの理解

このサンプルには、イメージのアーカイブZIPファイルの作成に使用する事前定義済アーカイブ・ディレクトリが/tmp/mii-sample/archives/archive-v1に含まれています。

wlsdeployという名前のアーカイブ・トップ・ディレクトリには、applicationsという名前のディレクトリが含まれています。このディレクトリには、myapp-v1というディレクトリに展開されたサンプルJSP webアプリケーションが含まれています。 WDTアーカイブについて覚えておく必要がある3つの重要な点は次のとおりです:

モデル・イメージには、複数のWDTアーカイブを含めることができます。
WDTアーカイブには、複数のアプリケーション、ライブラリおよびその他のコンポーネントを含めることができます。
WDTアーカイブには「適切に定義されたディレクトリ構造」があり、最上位ディレクトリは常にwlsdeployです。

実行中のWebLogic Serverインスタンスに関する重要な詳細が表示されます: つまり、そのドメイン名、クラスタ名、サーバー名、およびサーバーにターゲット指定されているデータ・ソースの名前です。

アーカイブのZIPファイルのステージング

イメージを作成するときは、ステージング・ディレクトリ/tmp/mii-sample/model-in-image__WLS-v1内のファイルを使用します。準備として、WDTアプリケーション・アーカイブのZIPファイルを含める必要があります。

次のコマンドを実行して、アプリケーション・アーカイブZIPファイルを作成し、必要なディレクトリに配置します:

# Delete existing archive.zip in case we have an old leftover version

$ rm -f /tmp/mii-sample/model-images/model-in-image__WLS-v1/archive.zip

# Move to the directory which contains the source files for our archive

$ cd /tmp/mii-sample/archives/archive-v1

# Zip the archive to the location will later use when we run the WebLogic Image Tool

$ zip -r /tmp/mii-sample/model-images/model-in-image__WLS-v1/archive.zip wlsdeploy

モデル・ファイルのステージング

このステップでは、ステージング済WDTモデルYAMLファイルおよび/tmp/mii-sample/model-in-image__WLS-v1ディレクトリのプロパティを確認します。このディレクトリのモデルは、アーカイブ内のwebアプリケーションを参照し、WebLogic Server管理サーバーを構成し、WebLogicクラスタを構成します。これは、単一のプロパティを持つファイルであるmodel.10.propertiesと、WebLogic構成model.10.yamlを含むYAMLファイルでのみ構成されます。

CLUSTER_SIZE=5

WLS model.10.yamlを次に示します:

domainInfo:
    AdminUserName: '@@SECRET:__weblogic-credentials__:username@@'
    AdminPassword: '@@SECRET:__weblogic-credentials__:password@@'
    ServerStartMode: 'prod'

topology:
    Name: '@@ENV:CUSTOM_DOMAIN_NAME@@'
    AdminServerName: 'admin-server'
    Cluster:
        'cluster-1':
            DynamicServers:
                ServerTemplate:  'cluster-1-template'
                ServerNamePrefix: 'managed-server'
                DynamicClusterSize: '@@PROP:CLUSTER_SIZE@@'
                MaxDynamicClusterSize: '@@PROP:CLUSTER_SIZE@@'
                MinDynamicClusterSize: '0'
                CalculatedListenPorts: false
    Server:
        'admin-server':
            ListenPort: 7001
    ServerTemplate:
        'cluster-1-template':
            Cluster: 'cluster-1'
            ListenPort: 8001

appDeployments:
    Application:
        myapp:
            SourcePath: 'wlsdeploy/applications/myapp-v1'
            ModuleType: ear
            Target: 'cluster-1'

モデル・ファイルの特徴は次のとおりです:

次を使用してWebLogicドメインを定義します:
- クラスタcluster-1
- 管理サーバーadmin-server
- wlsdeploy/applications/myapp-v1のWDTアーカイブZIPファイルにあるcluster-1ターゲットEARアプリケーション
マクロを利用して外部値をインジェクトします:
- プロパティ・ファイルのCLUSTER_SIZEプロパティは、PROPマクロを使用してモデルYAMLファイルのDynamicClusterSizeおよびMaxDynamicClusterSizeフィールドで参照されます。
- モデル・ファイル・ドメイン名は、ENVマクロを使用してCUSTOM_DOMAIN_NAMEという名前のカスタム環境変数を使用してインジェクトされます。
  - この環境変数は、このサンプルの後半で、そのドメインのenvフィールドを使用して設定します。
  - 「これにより、同じモデル・イメージを使用して複数の異なる名前のドメインを簡単にデプロイできます」。
- モデル・ファイル管理者のユーザー名とパスワードは、WebLogic資格証明シークレットへのweblogic-credentialsシークレット・マクロ参照を使用して設定されます。
  - このシークレットは、ドメインのwebLogicCredentialsSecretフィールドを使用して参照されます。
  - weblogic-credentialsは、所有ドメインの実際のWebLogic資格証明のシークレット名を常に間接参照する予約名です。

Model in Imageイメージには、複数のプロパティ・ファイル、アーカイブZIPファイルおよびYAMLファイルを含めることができますが、このサンプルでは、それぞれのいずれかを使用します。 Model in Imagesモデル・ファイルのネーミング規則、ファイル・ロード順序およびマクロ構文の詳細は、Model in Imageユーザー・ドキュメントの「モデル・ファイル」ファイルを参照してください。

WITを使用したイメージの作成

この時点で、イメージmodel-in-image:WLS-v1に必要なすべてのファイルをステージングしました。これには次のものが含まれます:

/tmp/mii-sample/model-images/weblogic-deploy.zip
/tmp/mii-sample/model-images/model-in-image__WLS-v1/model.10.yaml
/tmp/mii-sample/model-images/model-in-image__WLS-v1/model.10.properties
/tmp/mii-sample/model-images/model-in-image__WLS-v1/archive.zip

weblogic-deploy.zipファイルが表示されない場合は、「前提条件」でステップが欠落しています。

ここで、イメージ・ツールを使用して、ベースWebLogicイメージにレイヤー化されたmodel-in-image:WLS-v1という名前のイメージを作成します。このツールは、前提条件ステップですでに設定されています。

次のコマンドを実行してモデル・イメージを作成し、機能していることを確認します:

$ cd /tmp/mii-sample/model-images

$ ./imagetool/bin/imagetool.sh update \
  --tag model-in-image:WLS-v1 \
  --fromImage container-registry.oracle.com/middleware/weblogic:12.2.1.4 \
  --wdtModel      ./model-in-image__WLS-v1/model.10.yaml \
  --wdtVariables  ./model-in-image__WLS-v1/model.10.properties \
  --wdtArchive    ./model-in-image__WLS-v1/archive.zip \
  --wdtModelOnly \
  --wdtDomainType WLS \
  --chown oracle:root

imagetoolディレクトリが表示されない場合は、前提条件のステップが欠落しています。

このコマンドは、WebLogic Image ToolをModel in Imageモードで実行し、次の操作を実行します:

最終イメージをcontainer-registry.oracle.com/middleware/weblogic:12.2.1.4ベース・イメージのレイヤーとしてビルドします。
WITキャッシュで参照されるWDT ZIPファイルをイメージにコピーします。
- サンプルの前提条件ステップでキャッシュを設定するときに、キーワードlatestを使用してWITにWDTをキャッシュしたことに注意してください。
- これにより、WITはそれが目的のWDTバージョンであると暗黙的に想定し、-wdtVersionフラグを渡す必要がなくなります。
指定されたWDTモデル、プロパティおよびアプリケーション・アーカイブをイメージのロケーション/u01/wdt/modelsにコピーします。

コマンドが成功すると、次のような出力で終了します:

[INFO   ] Build successful. Build time=36s. Image tag=model-in-image:WLS-v1

また、docker imagesコマンドを実行すると、model-in-image:WLS-v1という名前のイメージが表示されます。

ノート: ローカル・マシンにリモートのKubernetesクラスタ・ワーカー・ノードがある場合は、これらのノードがアクセスできるロケーションにイメージを配置する必要があります。「Kubernetesクラスタがイメージにアクセスできることの確認」を参照してください。

このサンプルでは、一般提供 (GA)イメージを使用しています。 GAイメージは、パブリック・インターネットから環境を使用できないデモンストレーションおよび開発目的「のみ」に適しています。「本番での使用はできません」。本番では、常にOCRのCPU (パッチ適用済)イメージを使用するか、WebLogic Image Tool (WIT)と--recommendedPatchesオプションを使用してイメージを作成する必要があります。詳細は、「Oracle WebLogic Serverの本番環境の保護」の「最新のパッチと更新の適用」を参照してください。

WebLogicドメインの作成

この項では、次のステップを含む新しいイメージをネームスペースsample-domain1-nsにデプロイします:

WebLogicドメインのネームスペースを作成します。
オペレータをアップグレードして、WebLogicドメイン・ネームスペースを管理します。
WebLogic管理者のユーザー名とパスワードを含むシークレットを作成します。
Model in Imageランタイム暗号化パスワードを含むシークレットを作成します:
- すべてのModel in Imageドメインは、ランタイム暗号化シークレットにpassword値を指定する必要があります。
- オペレータによって内部的に渡される構成を暗号化するために使用されます。
- 値はプライベートにしておく必要がありますが、任意に指定できます。オプションで、ドメインを再起動するたびに別のシークレット値を指定できます。
新しいイメージを参照するドメインYAMLファイルをデプロイします。
ドメインのポッドが起動して準備完了状態になるまで待機します。

ネームスペース

1つ以上のドメインをホストできるネームスペースを作成します:

$ kubectl create namespace sample-domain1-ns

## label the domain namespace so that the operator can autodetect and create WebLogic Server pods.

$ kubectl label namespace sample-domain1-ns weblogic-operator=enabled

シークレット

最初に、WLSタイプ・モデル・ドメインで必要なシークレットを作成します。この場合、2つのシークレットがあります。

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

$ kubectl -n sample-domain1-ns create secret generic \
  sample-domain1-weblogic-credentials \
   --from-literal=username=<wl admin username> \
   --from-literal=password=<wl admin password>

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

$ kubectl -n sample-domain1-ns create secret generic \
  sample-domain1-runtime-encryption-secret \
   --from-literal=password=<mii runtime encryption pass>

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

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

パスワードおよびユーザー名の選択:
- <wl admin username>および<wl admin password>は、選択したユーザー名とパスワードに置き換えます。パスワードは8文字以上で、数字を1文字以上使用する必要があります。指定した内容を記憶します。これらの資格証明は後で再度必要になる場合があります。
- <mii runtime encryption pass>を任意のパスワードに置き換えます。
WebLogic資格証明シークレット:
- これは必須で、usernameおよびpasswordフィールドが含まれている必要があります。
- ドメインのspec.webLogicCredentialsSecretフィールドによって参照される必要があります。
- また、モデルYAMLファイルのdomainInfo.AdminUserNameおよびdomainInfo.AdminPassWordフィールドのマクロで参照する必要があります。
モデルWDTランタイム・シークレット:
- これは、Model in Imageで必要とされる特殊なシークレットです。
- passwordフィールドが含まれている必要があります。
- ドメインのspec.model.runtimeEncryptionSecretフィールドを使用して参照する必要があります。
- ドメインがKubernetesにデプロイされているかぎり同じである必要がありますが、デプロイメント間で変更できます。
- ドメインのイントロスペクタ・ジョブおよびそのWebLogic Serverポッドからログ・ファイルを使用して内部的に渡されるデータの暗号化に使用されます。
シークレットの削除および再作成:
- シークレットを作成する前に削除すると、シークレットがすでに存在する場合はcreateコマンドが失敗します。
- これにより、kubectl create secretコマンドの使用時にシークレットを変更できます。
シークレットの命名とラベル付けには、次の2つの理由で、関連付けられたドメインUIDを使用します:
- どのシークレットがどのドメインに属しているかを明らかにします。
- ドメインのクリーンアップを容易にするため。一般的なクリーンアップ・スクリプトでは、ドメインに関連付けられているすべてのリソースを簡単に検索できるように、weblogic.domainUIDラベルを使用します。

ドメイン・リソース

ここで、ドメインYAMLファイルを作成します。ドメインは、オペレータにWebLogicドメインのデプロイ方法を伝える主要なリソースです。

/tmp/mii-sample/mii-initial.yamlなどのファイルに次をコピーするか、サンプル・ソースに含まれているファイル/tmp/mii-sample/domain-resources/WLS/mii-initial-d1-WLS-v1.yamlを使用します。

「WLSドメインYAMLファイルを表示するには、ここをクリックします。」

  #
  # This is an example of how to define a Domain resource.
  #
  apiVersion: "weblogic.oracle/v9"
  kind: Domain
  metadata:
    name: sample-domain1
    namespace: sample-domain1-ns
    labels:
      weblogic.domainUID: sample-domain1

  spec:
    # Set to 'FromModel' to indicate 'Model in Image'.
    domainHomeSourceType: FromModel

    # The WebLogic Domain Home, this must be a location within
    # the image for 'Model in Image' domains.
    domainHome: /u01/domains/sample-domain1

    # The WebLogic Server image that the Operator uses to start the domain
    image: "model-in-image:WLS-v1"

    # Defaults to "Always" if image tag (version) is ':latest'
    imagePullPolicy: "IfNotPresent"

    # Identify which Secret contains the credentials for pulling an image
    #imagePullSecrets:
    #- name: regsecret

    # Identify which Secret contains the WebLogic Admin credentials,
    # the secret must contain 'username' and 'password' fields.
    webLogicCredentialsSecret:
      name: sample-domain1-weblogic-credentials

    # Whether to include the WebLogic Server stdout in the pod's stdout, default is true
    includeServerOutInPodLog: true

    # Whether to enable overriding your log file location, see also 'logHome'
    #logHomeEnabled: false

    # The location for domain log, server logs, server out, introspector out, and Node Manager log files
    # see also 'logHomeEnabled', 'volumes', and 'volumeMounts'.
    #logHome: /shared/logs/sample-domain1

    # Set which WebLogic Servers the Operator will start
    # - "Never" will not start any server in the domain
    # - "AdminOnly" will start up only the administration server (no managed servers will be started)
    # - "IfNeeded" will start all non-clustered servers, including the administration server, and clustered servers up to their replica count.
    serverStartPolicy: IfNeeded

    # Settings for all server pods in the domain including the introspector job pod
    serverPod:
      # Optional new or overridden environment variables for the domain's pods
      # - This sample uses CUSTOM_DOMAIN_NAME in its image model file
      #   to set the WebLogic domain name
      env:
      - name: CUSTOM_DOMAIN_NAME
        value: "domain1"
      - name: JAVA_OPTIONS
        value: "-Dweblogic.StdoutDebugEnabled=false"
      - name: USER_MEM_ARGS
        value: "-XX:+UseContainerSupport -Djava.security.egd=file:/dev/./urandom "

      # Optional volumes and mounts for the domain's pods. See also 'logHome'.
      #volumes:
      #- name: weblogic-domain-storage-volume
      #  persistentVolumeClaim:
      #    claimName: sample-domain1-weblogic-sample-pvc
      #volumeMounts:
      #- mountPath: /shared
      #  name: weblogic-domain-storage-volume

    # The desired behavior for starting the domain's administration server.
    # adminServer:
      # Setup a Kubernetes node port for the administration server default channel
      #adminService:
      #  channels:
      #  - channelName: default
      #    nodePort: 30701

    # The number of managed servers to start for unlisted clusters
    replicas: 1

    # The desired behavior for starting a specific cluster's member servers
    clusters:
    - clusterName: cluster-1
      replicas: 2

    # Change the `restartVersion` to force the introspector job to rerun
    # and apply any new model configuration, to also force a subsequent
    # roll of your domain's WebLogic Server pods.
    restartVersion: '1'

    configuration:

      # Settings for domainHomeSourceType 'FromModel'
      model:
        # Valid model domain types are 'WLS', 'JRF', and 'RestrictedJRF', default is 'WLS'
        domainType: "WLS"

        # Optional configmap for additional models and variable files
        #configMap: sample-domain1-wdt-config-map

        # All 'FromModel' domains require a runtimeEncryptionSecret with a 'password' field
        runtimeEncryptionSecret: sample-domain1-runtime-encryption-secret

      # Secrets that are referenced by model yaml macros
      # (the model yaml in the optional configMap or in the image)
      #secrets:
      #- sample-domain1-datasource-secret

ノート: ドメイン・カスタム・リソースをデプロイする前に、ローカル・マシンにリモートのKubernetesクラスタ・ワーカー・ノードがあるかどうかを確認します。その場合、これらのノードがアクセスできるロケーションにドメインのイメージを配置する必要があり、新しいロケーションを参照するようにドメインYAMLファイルを変更することも必要になる場合があります。「Kubernetesクラスタがイメージにアクセスできることの確認」を参照してください。

次のコマンドを実行して、ドメイン・カスタム・リソースを作成します:

$ kubectl apply -f /tmp/mii-sample/domain-resources/WLS/mii-initial-d1-WLS-v1.yaml

ノート: 事前定義済のドメインYAMLファイルを使用せずに、以前に独自のドメインYAMLファイルを作成した場合、前述のコマンドでカスタム・ファイル名を置き換えます。以前は、/tmp/mii-sample/mii-initial.yamlという名前を付けることをお薦めしました。

WebLogic Serverポッドがすべて実行されていることを確認します:

$ kubectl get all -n sample-domain1-ns

NAME                                 READY   STATUS    RESTARTS   AGE
pod/sample-domain1-admin-server      1/1     Running   0          41m
pod/sample-domain1-managed-server1   1/1     Running   0          40m
pod/sample-domain1-managed-server2   1/1     Running   0          40m

NAME                                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/sample-domain1-admin-server        ClusterIP   None           <none>        7001/TCP   41m
service/sample-domain1-cluster-cluster-1   ClusterIP   100.66.99.27   <none>        8001/TCP   40m
service/sample-domain1-managed-server1     ClusterIP   None           <none>        8001/TCP   40m
service/sample-domain1-managed-server2     ClusterIP   None           <none>        8001/TCP   40m

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

ロード・バランサを作成して、クラスタにデプロイされたWebLogic Server管理コンソールおよびアプリケーションにアクセスします。 Tanzuは、ルーティングのためにMetalLBロード・バランサおよびNGINXイングレスをサポートしています。

次のコマンドを実行して、MetalLBロード・バランサをインストールします:

## create namespace metallb-system

$ kubectl create ns metallb-system

## deploy MetalLB load balancer

$ kubectl apply -f https://raw.githubusercontent.com/google/metallb/v0.9.2/manifests/metallb.yaml -n metallb-system

## create secret

$ kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

$ cat metallb-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.100.50-192.168.100.65

$ kubectl apply -f metallb-configmap.yaml

configmap/config created

$ kubectl get all -n metallb-system

NAME                              READY   STATUS    RESTARTS   AGE
pod/controller-684f5d9b49-jkzfk   1/1     Running   0          2m14s
pod/speaker-b457r                 1/1     Running   0          2m14s
pod/speaker-bzmmj                 1/1     Running   0          2m14s
pod/speaker-gphh5                 1/1     Running   0          2m14s
pod/speaker-lktgc                 1/1     Running   0          2m14s

NAME                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
daemonset.apps/speaker   4         4         4       4            4           beta.kubernetes.io/os=linux   2m14s

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/controller   1/1     1            1           2m14s

NAME                                    DESIRED   CURRENT   READY   AGE
replicaset.apps/controller-684f5d9b49   1         1         1       2m14s

NGINXのインストール。

$ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx --force-update

$ helm install ingress-nginx ingress-nginx/ingress-nginx

クラスタにデプロイされたアプリケーションにアクセスし、管理コンソールにアクセスするためのイングレスを作成します。

$ cat ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sample-nginx-ingress-pathrouting
  namespace: sample-domain1-ns
spec:
  ingressClassName: nginx
  rules:
  - host:
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: sample-domain1-cluster-cluster-1
            port:
              number: 8001
      - path: /console
        pathType: Prefix
        backend:
          service:
            name: sample-domain1-admin-server
            port:
              number: 7001

$ kubectl apply -f ingress.yaml

イングレスが実行中であることを確認してください。

$ kubectl get ingresses -n sample-domain1-ns

NAME                               CLASS    HOSTS   ADDRESS          PORTS   AGE
sample-nginx-ingress-pathrouting   <none>   *       192.168.100.50   80      7m18s

ロード・バランサのIPアドレスhttp://192.168.100.50/consoleを使用して、管理コンソールにアクセスします。コンソール・ログイン画面には、「シークレット」で指定したWebLogic管理資格証明が必要です。

サンプル・アプリケーションにアクセスします。

# Access the sample application using the load balancer IP (192.168.100.50)

$ curl http://192.168.100.50/myapp_war/index.jsp

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

Hello World! This is version 'v1' of the mii-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 0 local data sources:

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

$ curl http://192.168.100.50/myapp_war/index.jsp

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

Hello World! This is version 'v1' of the mii-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 0 local data sources:

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