このサンプルは、domain on PVアプローチを使用して、WebLogic Kubernetes Operator (以降「オペレータ」)を使用してAzure Kubernetesサービス(AKS)にWebLogic Server (WLS)クラスタを設定する方法を示します。 ステップを実行した後、WLSドメインはAKSクラスタ・インスタンスで実行され、WebLogic Server管理コンソールにアクセスしてWLSドメインを管理できます。
このサンプルでは、次の前提条件環境を想定しています。
git --versionを使用して、gitが動作するかどうかをテストします。 このドキュメントは、バージョン2.25.1でテストされました。 az --versionを使用して、azが動作するかどうかをテストします。 このドキュメントは、バージョン2.58.0でテストされました。 Docker version 20.10.7でテストされました kubectl versionを使用して、kubectlが動作するかどうかをテストします。 このドキュメントは、バージョンv1.21.2でテストされました。 helm versionを使用してhelmバージョンを確認します。 このドキュメントは、バージョンv3.6.2でテストされました。 JAVA_HOME環境変数が正しく設定されていることを確認します。 zip/unzip -vを使用して、zip/unzipが動作するかどうかをテストします。# Change these parameters as needed for your own environment
export ORACLE_SSO_EMAIL=<replace with your oracle account email>
export ORACLE_SSO_PASSWORD="<replace with your oracle password>"
# Specify a prefix to name resources, only allow lowercase letters and numbers, between 1 and 7 characters
export BASE_DIR=~
export NAME_PREFIX=wls
export WEBLOGIC_USERNAME=weblogic
export WEBLOGIC_PASSWORD=Secret123456
export domainUID=domain1
# Used to generate resource names.
export TIMESTAMP=`date +%s`
export AKS_CLUSTER_NAME="${NAME_PREFIX}aks${TIMESTAMP}"
export AKS_PERS_RESOURCE_GROUP="${NAME_PREFIX}resourcegroup${TIMESTAMP}"
export AKS_PERS_LOCATION=eastus
export AKS_PERS_STORAGE_ACCOUNT_NAME="${NAME_PREFIX}storage${TIMESTAMP}"
export AKS_PERS_SHARE_NAME="${NAME_PREFIX}-weblogic-${TIMESTAMP}"
export SECRET_NAME_DOCKER="${NAME_PREFIX}regcred"
export ACR_NAME="${NAME_PREFIX}acr${TIMESTAMP}"
Oracleアカウントが必要です。 次のステップでは、WebLogic Serverのライセンス契約に同意します。 Oracle Accountのパスワードと電子メールをノートにとります。 このサンプルは12.2.1.4に関連していますが、他のバージョンも動作する場合があります。
--recommendedPatchesオプションを指定したWebLogic Image Tool (WIT)を使用してイメージを作成する必要があります。 詳細は、「Oracle WebLogic Serverの本番環境の保護」の「最新のパッチと更新の適用」を参照してください。 $ docker login container-registry.oracle.com -u ${ORACLE_SSO_EMAIL} -p ${ORACLE_SSO_PASSWORD}
$ docker pull container-registry.oracle.com/middleware/weblogic:12.2.1.4
Oracle Container Registryへのアクセスに問題がある場合は、「Oracle GitHubリポジトリ」から独自のイメージを作成できます。
この項のステップでは、Azure CLIにサインインする方法を示します。
Bashシェルを開きます。
サインアウトし、一部の認証ファイルを削除して、ライセンス資格証明を削除します。
$ az logout
$ rm ~/.azure/accessTokens.json
$ rm ~/.azure/azureProfile.json
Azure CLIにサインインします。
$ az login
サブスクリプションIDを設定します。 プレースホルダーを適切な値に置換してください。
$ export SUBSCRIPTION_ID="<your-sub-id>"
$ az account set -s $SUBSCRIPTION_ID
サンプル・ステップの次の項では、AKSでWebLogicクラスタを設定するプロセスを順を追って説明します - これらは、限りなくKubernetesネイティブに近い形で実施できます。 これにより、各ステップを理解してカスタマイズできます。 より低いレベルの詳細を抽象化する、より自動化されたエクスペリエンスが必要な場合は、「自動化」セクションにスキップできます。
WebLogic Kubernetes OperatorサンプルZIPファイルをダウンロードします。 このzipファイル内の複数のスクリプトを使用して、WebLogicドメインを作成します。 このサンプルはv4.2.5でテストされましたが、最新リリースで動作するはずです。
$ cd $BASE_DIR
$ mkdir sample-scripts
$ curl -m 120 -fL https://github.com/oracle/weblogic-kubernetes-operator/releases/download/v4.2.5/sample-scripts.zip \
-o ${BASE_DIR}/sample-scripts/sample-scripts.zip
$ unzip ${BASE_DIR}/sample-scripts/sample-scripts.zip -d ${BASE_DIR}/sample-scripts
$ az extension add --name resource-graph
$ az group create --name $AKS_PERS_RESOURCE_GROUP --location $AKS_PERS_LOCATION
このサンプルはアプリケーション・ルーティングを有効にしません。 アプリケーション・ルーティングを有効にする場合は、「AKSのアプリケーション・ルーティング・アドオンでnginx Ingressを管理」に従います。
次のコマンドを実行して、AKSクラスタ・インスタンスを作成します。
$ az aks create \
--resource-group $AKS_PERS_RESOURCE_GROUP \
--name $AKS_CLUSTER_NAME \
--node-count 2 \
--generate-ssh-keys \
--nodepool-name nodepool1 \
--node-vm-size Standard_DS2_v2 \
--location $AKS_PERS_LOCATION \
--enable-managed-identity
正常に出力されるのは、エントリ"type": "Microsoft.ContainerService/ManagedClusters"を含むJSONオブジェクトです。
デプロイメントが終了したら、次のコマンドを実行してAKSクラスタに接続します。 このコマンドは、後続のkubectlコマンドが指定されたAKSクラスタと相互作用するようにローカル~/.kube/configを更新します。
$ az aks get-credentials --resource-group $AKS_PERS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME
正常な出力は次のようになります:
Merged "wlsaks1596087429" as current context in /home/username/.kube/config
Kubernetesクラスタが稼働したら、次のコマンドを実行して、kubectlがKubernetesクラスタにアクセスできることを確認します:
$ kubectl get nodes -o wide
成功した出力は、次のようになります。
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
aks-nodepool1-15679926-vmss000000 Ready agent 118s v1.25.6 10.224.0.4 <none> Ubuntu 22.04.2 LTS 5.15.0-1041-azure containerd://1.7.1+azure-1
aks-nodepool1-15679926-vmss000001 Ready agent 2m8s v1.25.6 10.224.0.5 <none> Ubuntu 22.04.2 LTS 5.15.0-1041-azure containerd://1.7.1+azure-1
ノート: VMサイズの障害に遭遇した場合は、トラブルシューティング - 仮想マシン・サイズはサポートされていませんを参照してください。
オペレータの使用パターンには、WebLogic ServerがWebLogic Serverワークロードを実行するKubernetesポッドとは別に構成およびデータを保持できるように、Kubernetesの永続ボリュームを作成することが含まれます。
データにアクセスして永続化する外部データ・ボリュームを作成します。 「Azure Kubernetes Service (AKS)のアプリケーションのストレージ・オプション」で説明されているように、データ共有にはいくつかのオプションがあります。
Azure Files NFS共有で永続ボリュームを動的に作成して使用します。 このフル機能のクラウド・ストレージ・ソリューションの詳細は、「Azure Filesのドキュメント」を参照してください。
Azureストレージ・アカウントを作成します。
Azure CLIを使用してストレージ・アカウントを作成します。 次の値が指定されていることを確認します:
| オプション名 | 値 | ノート |
|---|---|---|
name |
$AKS_PERS_STORAGE_ACCOUNT_NAME |
ストレージ・アカウント名に使用できるのは小文字と数字のみで、3文字から24文字の長さである必要があります。 |
sku |
Premium_LRS |
NFS共有で動作するのはPremium_LRSおよびPremium_ZRSのみです。「Azure Files NFS共有ドキュメント」を参照してください。 |
https-only |
false |
セキュア転送を無効にしないかぎり、NFSファイル共有をマウントすることはできません。 |
default-action |
Deny |
セキュリティのために、デフォルトではアクセスを拒否し、AKSクラスタ・ネットワークからのアクセスを許可するように選択することをお薦めします。 |
$ az storage account create \
--resource-group $AKS_PERS_RESOURCE_GROUP \
--name $AKS_PERS_STORAGE_ACCOUNT_NAME \
--location $AKS_PERS_LOCATION \
--sku Premium_LRS \
--kind FileStorage \
--https-only false \
--default-action Deny
正常に出力されるのは、エントリ"type": "Microsoft.Storage/storageAccounts"を含むJSONオブジェクトです。
NFS共有を作成します。
SMBではなくNFSを推奨します。 NFSは、UNIXオペレーティング・システム、およびGNU/Linuxなどの他のバリアントから進化しました。 このため、Dockerなどのコンテナ・テクノロジでNFSを使用する場合、同時読取りおよびファイル・ロックに問題がある可能性は低くなります。
NFS v4.1を有効にしてください。 v4.1より低いバージョンでは問題が発生します。
ファイル共有を作成するには、NoRootSquashを使用して、オペレータがNFS共有内のディレクトリの所有権を変更できるようにする必要があります。
そうしないと、chown: changing ownership of '/shared': Operation not permittedのようなエラーが表示されます。
次のコマンドは、100GiBでNFS共有を作成します:
# Create NFS file share
$ az storage share-rm create \
--resource-group $AKS_PERS_RESOURCE_GROUP \
--storage-account $AKS_PERS_STORAGE_ACCOUNT_NAME \
--name ${AKS_PERS_SHARE_NAME} \
--enabled-protocol NFS \
--root-squash NoRootSquash \
--quota 100
このコマンドは、NFS 4.1以上でNFSファイル共有をプロビジョニングします。
AKSクラスタ「コントリビュータ」ロールを割り当てて、ストレージ・アカウントにアクセスします。
AKSクラスタからストレージ・アカウントへのアクセスを許可するロール割当てを構成する必要があります。
次のコマンドを使用して、AKSクラスタのobjectIdを取得し、変数AKS_OBJECT_IDで保存します:
$ AKS_OBJECT_ID=$(az aks show --name ${AKS_CLUSTER_NAME} --resource-group ${AKS_PERS_RESOURCE_GROUP} --query "identity.principalId" -o tsv)
次のコマンドを使用して、ストレージ・アカウントのIDを取得します:
$ STORAGE_ACCOUNT_ID=$(az storage account show --name ${AKS_PERS_STORAGE_ACCOUNT_NAME} --resource-group ${AKS_PERS_RESOURCE_GROUP} --query "id" -o tsv)
これで、ストレージ・アカウントのスコープでAKSクラスタ「コントリビュータ」を付与するロール割当てを作成できます。 その後、AKSクラスタはファイル共有にアクセスできます。
$ az role assignment create \
--assignee-object-id "${AKS_OBJECT_ID}" \
--assignee-principal-type "ServicePrincipal" \
--role "Contributor" \
--scope "${STORAGE_ACCOUNT_ID}"
出力に成功すると、次のような文字列を含むJSONオブジェクトになります:
{
"condition": null,
"conditionVersion": null,
"createdBy": "d6fe7d09-3330-45b6-ae32-4dd5e3310835",
"createdOn": "2023-05-11T04:13:04.922943+00:00",
"delegatedManagedIdentityResourceId": null,
"description": null,
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/wlsresourcegroup1683777168/providers/Microsoft.Storage/storageAccounts/wlsstorage1683777168/providers/Microsoft.Authorization/roleAssignments/93dae12d-21c8-4844-99cd-e8b088356af6",
"name": "93dae12d-21c8-4844-99cd-e8b088356af6",
"principalId": "95202c6f-2073-403c-b9a7-7d2f1cbb4541",
"principalName": "3640cbf2-4db7-43b8-bcf6-1e51d3e90478",
"principalType": "ServicePrincipal",
"resourceGroup": "wlsresourcegroup1683777168",
"roleDefinitionId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/wlsresourcegroup1683777168/providers/Microsoft.Storage/storageAccounts/wlsstorage1683777168",
"type": "Microsoft.Authorization/roleAssignments",
"updatedBy": "d6fe7d09-3330-45b6-ae32-4dd5e3310835",
"updatedOn": "2023-05-11T04:13:04.922943+00:00"
}
ネットワーク・セキュリティを構成します。
AKSクラスタからファイル共有へのアクセスを許可するネットワーク・セキュリティを構成する必要があります。
まず、仮想ネットワーク名とAKSクラスタのサブネット名を取得する必要があります。
次のコマンドを実行してネットワーク情報を取得します:
# get the resource group name of the AKS managed resources
$ aksMCRGName=$(az aks show --name $AKS_CLUSTER_NAME --resource-group $AKS_PERS_RESOURCE_GROUP -o tsv --query "nodeResourceGroup")
$ echo ${aksMCRGName}
# get network name of AKS cluster
$ aksNetworkName=$(az graph query -q "Resources \
| where type =~ 'Microsoft.Network/virtualNetworks' \
| where resourceGroup =~ '${aksMCRGName}' \
| project name = name" --query "data[0].name" -o tsv)
$ echo ${aksNetworkName}
# get subnet name of AKS agent pool
$ aksSubnetName=$(az network vnet subnet list --resource-group ${aksMCRGName} --vnet-name ${aksNetworkName} -o tsv --query "[*].name")
$ echo ${aksSubnetName}
# get subnet id of the AKS agent pool
$ aksSubnetId=$(az network vnet subnet list --resource-group ${aksMCRGName} --vnet-name ${aksNetworkName} -o tsv --query "[*].id")
$ echo ${aksSubnetId}
次のコマンドを使用して、サブネットのサービス・エンドポイントMicrosoft.Storageを有効にする必要があります:
$ az network vnet subnet update \
--resource-group $aksMCRGName \
--name ${aksSubnetName} \
--vnet-name ${aksNetworkName} \
--service-endpoints Microsoft.Storage
サービス・エンドポイントを有効にするには数分かかります。正常な出力は、次のような文字列を持つJSONオブジェクトになります:
"serviceEndpoints": [
{
"locations": [
"eastus",
"westus"
],
"provisioningState": "Succeeded",
"service": "Microsoft.Storage"
}
AKSクラスタからのアクセスを許可するネットワーク・ルールを作成する必要があります。 次のコマンドは、AKSサブネットからストレージ・アカウントへのアクセスを有効にします:
$ az storage account network-rule add \
--resource-group $AKS_PERS_RESOURCE_GROUP \
--account-name $AKS_PERS_STORAGE_ACCOUNT_NAME \
--subnet ${aksSubnetId}
成功した出力は、次のような仮想ネットワーク・ルールを持つJSONオブジェクトになります:
"virtualNetworkRules": [
{
"action": "Allow",
"state": "Succeeded",
"virtualNetworkResourceId": "${aksSubnetId}"
}
]
次のコマンドを使用して、構成ファイルを生成します。
cat >azure-csi-nfs-${TIMESTAMP}.yaml <<EOF
# Copyright (c) 2018, 2023, Oracle and/or its affiliates.
# Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-nfs
provisioner: file.csi.azure.com
parameters:
protocol: nfs
resourceGroup: ${AKS_PERS_RESOURCE_GROUP}
storageAccount: ${AKS_PERS_STORAGE_ACCOUNT_NAME}
shareName: ${AKS_PERS_SHARE_NAME}
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
EOF
cat >pvc-${TIMESTAMP}.yaml <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wls-azurefile-${TIMESTAMP}
spec:
accessModes:
- ReadWriteMany
storageClassName: azurefile-csi-nfs
resources:
requests:
storage: 5Gi
EOF
kubectlコマンドを使用して、defaultネームスペースに対するストレージ・クラスおよび永続ボリューム要求を作成します。
$ kubectl apply -f azure-csi-nfs-${TIMESTAMP}.yaml
$ kubectl apply -f pvc-${TIMESTAMP}.yaml
次のコマンドを使用して確認します:
$ kubectl get sc
kubectl get sc出力の例:
$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
azurefile file.csi.azure.com Delete Immediate true 30m
azurefile-csi file.csi.azure.com Delete Immediate true 30m
azurefile-csi-nfs file.csi.azure.com Delete Immediate true 24m
azurefile-csi-premium file.csi.azure.com Delete Immediate true 30m
azurefile-premium file.csi.azure.com Delete Immediate true 30m
...
$ kubectl get pvc
kubectl get pvc出力の例:
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
wls-azurefile-1693900684 Bound pvc-1f615766-0f21-4c88-80e1-93c9bdabb3eb 5Gi RWX azurefile-csi-nfs 46s
このサンプルには、「ドメイン作成イメージ」が必要です。 詳細については、「永続ボリューム上のドメイン」を参照してください。
JAVA_HOME環境変数を設定し、有効なJDK 8または11インストールを参照する必要があります。
サンプルを新しいディレクトリにコピーします。たとえば、ディレクトリ/tmp/dpv-sampleを使用します。 ディレクトリ名では、dpvは"domain on pv"の略です。 Domain on PVは、オペレータでサポートされている3つのドメイン・ホーム・ソース・タイプのいずれかです。 詳細は、「ドメイン・ホーム・ソース・タイプの選択」を参照してください。
$ rm /tmp/dpv-sample -f -r
$ mkdir /tmp/dpv-sample
$ cp -r $BASE_DIR/sample-scripts/create-weblogic-domain/domain-on-pv/* /tmp/dpv-sample
ノート: サンプルのこの作業用コピーを/tmp/dpv-sampleと呼びますが、別のロケーションを使用できます。
サンプルのwdt-artifactsディレクトリを新しいディレクトリにコピーします。たとえば、ディレクトリ/tmp/dpv-sample/wdt-artifactsを使用
$ cp -r $BASE_DIR/sample-scripts/create-weblogic-domain/wdt-artifacts/* /tmp/dpv-sample
$ export WDT_MODEL_FILES_PATH=/tmp/dpv-sample/wdt-model-files
最新のWebLogic Deploying Tooling (WDT)およびWebLogic Image Tool (WIT)インストーラZIPファイルを${WDT_MODEL_FILES_PATH}ディレクトリにダウンロードします。 Model in Imageイメージを作成するには、WDTとWITの両方が必要です。
$ curl -m 120 -fL https://github.com/oracle/weblogic-deploy-tooling/releases/latest/download/weblogic-deploy.zip \
-o ${WDT_MODEL_FILES_PATH}/weblogic-deploy.zip
$ curl -m 120 -fL https://github.com/oracle/weblogic-image-tool/releases/latest/download/imagetool.zip \
-o ${WDT_MODEL_FILES_PATH}/imagetool.zip
WebLogic Image Toolを設定し、次のコマンドを実行します:
$ unzip ${WDT_MODEL_FILES_PATH}/imagetool.zip -d ${WDT_MODEL_FILES_PATH}
$ ${WDT_MODEL_FILES_PATH}/imagetool/bin/imagetool.sh cache deleteEntry --key wdt_latest
$ ${WDT_MODEL_FILES_PATH}/imagetool/bin/imagetool.sh cache addInstaller \
--type wdt \
--version latest \
--path ${WDT_MODEL_FILES_PATH}/weblogic-deploy.zip
これらのステップでは、WITを${WDT_MODEL_FILES_PATH}/imagetoolディレクトリにインストールし、さらにWDT ZIPファイル・インストーラを指すwdt_latestエントリをツールのキャッシュに配置します。 WITは、サンプルの後半でモデル・イメージの作成に使用します。
イメージ作成の目的は、WebLogic Image Toolを使用して、${WDT_MODEL_FILES_PATH}/WLS-v1/にステージングするファイルからwdt-domain-image:WLS-v1とタグ付けされたイメージを作成することを示すことです。
/auxiliary/weblogic-deployディレクトリに必要です。/auxiliary/modelsに必要です。「最初のアーカイブの理解」を参照してください。
既存のarchive.zipは、古い残存バージョンがある場合に削除します。
$ rm -f ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip
WebLogic Image Toolの実行時に使用するロケーションに、アーカイブのZIPファイルを作成します。
$ cd /tmp/dpv-sample/archives/archive-v1
$ zip -r ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip wlsdeploy
このステップでは、ステージング済WDTモデルYAMLファイルおよび${WDT_MODEL_FILES_PATH}/WLS-v1ディレクトリのプロパティを確認します。 このディレクトリのモデルは、アーカイブ内のwebアプリケーションを参照し、WebLogic Server管理サーバーを構成し、WebLogicクラスタを構成します。 これは、model.10.propertiesという2つのファイル、単一のプロパティを持つファイル、およびmodel.10.yamlというWebLogic構成のYAMLファイルのみで構成されています。
WLS model.10.propertiesを次に示します:
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-1admin-servercluster-1をターゲットとするEARアプリケーション。wlsdeploy/applications/myapp-v1のWDTアーカイブZIPファイルにありますマクロを利用して外部値をインジェクトします:
CLUSTER_SIZEプロパティは、PROPマクロを使用してモデルYAMLファイルのDynamicClusterSizeおよびMaxDynamicClusterSizeフィールドで参照されます。CUSTOM_DOMAIN_NAMEという名前のカスタム環境変数を使用してインジェクトされます。
envフィールドを使用して設定します。weblogic-credentialsシークレット・マクロ参照を使用して設定されます。
webLogicCredentialsSecretフィールドを使用して参照されます。weblogic-credentialsは、所有ドメインの実際のWebLogic資格証明のシークレット名を常に間接参照する予約名です。イメージには、複数のプロパティ・ファイル、アーカイブZIPファイルおよびモデルYAMLファイルを含めることができますが、この例ではそれぞれ1つのみを使用します。 WDTモデル・ファイルの命名規則、ファイル・ロード順序およびマクロ構文の詳細は、ユーザー・ドキュメントの「モデル・ファイル」を参照してください。
この時点で、ステージングされたimage wdt-domain-image:WLS-v1に必要なすべてのファイルがあります。次のファイルが含まれます:
/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v1/model.10.yaml/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v1/model.10.properties/tmp/sample/wdt-artifacts/wdt-model-files/WLS-v1/archive.zipここで、イメージ・ツールを使用して、wdt-domain-image:WLS-v1という名前のイメージを作成します。 このツールは、前提条件ステップですでに設定されています。
次のコマンドを実行してイメージを作成し、それが機能することを確認します。
$ ${WDT_MODEL_FILES_PATH}/imagetool/bin/imagetool.sh createAuxImage \
--tag wdt-domain-image:WLS-v1 \
--wdtModel ${WDT_MODEL_FILES_PATH}/WLS-v1/model.10.yaml \
--wdtVariables ${WDT_MODEL_FILES_PATH}/WLS-v1/model.10.properties \
--wdtArchive ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip
このコマンドは、WebLogic Image Toolを実行してドメイン作成イメージを作成し、次のことを実行します:
busyboxベース・イメージのレイヤーとしてビルドします。latestを使用してWITにWDTをキャッシュしたことに注意してください。-wdtVersionフラグを渡す必要がなくなります。/auxiliary/modelsにコピーします。コマンドが成功すると、次のような出力で終了します:
[INFO ] Build successful. Build time=70s. Image tag=wdt-domain-image:WLS-v1
次のコマンドを使用して、イメージがローカルDockerサーバーで使用可能であることを確認します。
$ docker images | grep WLS-v1
wdt-domain-image WLS-v1 012d3bfa3536 5 days ago 1.13GB
imagetool.shは、Apple SiliconのmacOSではサポートされていません。 「トラブルシューティング - execフォーマット・エラー」を参照してください。
Dockerビルド・キットが有効になっている場合は、Dockerfile解析エラーになることがあります。「トラブルシューティング - WebLogic Image Toolの失敗」を参照してください。
AKSは任意のコンテナ・レジストリからイメージをプルできますが、最も簡単な統合はAzure Container Registry (ACR)を使用することです。 シンプルさに加えて、ACRを使用すると、地理レプリケーションなどの機能により、高可用性とディザスタ・リカバリが簡素化されます。 詳細については、「Azure Container Registryのレプリケーション」を参照してください。 この項では、新しいAzure Container Registryを作成し、既存のAKSクラスタに接続し、前の項で作成したイメージをプッシュします。 詳細は、「Azure Container Registryのドキュメント」を参照してください。
AKSに使用したリソース・グループと同じリソース・グループにACRのインスタンスを作成します。 前述のステップで使用した環境変数を使用します。 簡単にするために、ACRインスタンスの名前としてリソース・グループ名を使用します。
$ az acr create --resource-group $AKS_PERS_RESOURCE_GROUP --name $ACR_NAME --sku Basic --admin-enabled true
このコマンドからのJSON出力を詳細に調べます。 loginServerプロパティの値を保存します。 次のようになります。
"loginServer": "contosoresourcegroup1610068510.azurecr.io",
この値を使用してACRインスタンスにサインインします。 az cliでサインインしているため、az loginを以前に実行してアイデンティティがすでに伝達されているため、パスワードは必要ありません。
$ export LOGIN_SERVER=$(az acr show -n $ACR_NAME --resource-group $AKS_PERS_RESOURCE_GROUP --query "loginServer" -o tsv)
$ az acr login --name $LOGIN_SERVER
正常な出力には、Login Succeededが含まれます。
このレジストリの前提条件を満たしながら作成されたwdt-domain-image:WLS-v1イメージをプッシュします。
$ docker tag wdt-domain-image:WLS-v1 $LOGIN_SERVER/wdt-domain-image:WLS-v1
$ docker push ${LOGIN_SERVER}/wdt-domain-image:WLS-v1
最後に、AKSをACRに接続します。 ACRを既存のAKSに接続する方法の詳細については、「既存のAKSクラスタのACR統合の構成」を参照してください。
$ export ACR_ID=$(az acr show -n $ACR_NAME --resource-group $AKS_PERS_RESOURCE_GROUP --query "id" -o tsv)
$ az aks update --name $AKS_CLUSTER_NAME --resource-group $AKS_PERS_RESOURCE_GROUP --attach-acr $ACR_ID
正常に出力されるのは、エントリ"type": "Microsoft.ContainerService/ManagedClusters"を含むJSONオブジェクトです。
「このサブスクリプションの所有者」ではないと思われるエラーが表示される場合は、「サブスクリプションの所有者ではないため、ACRをアタッチできません」のトラブルシューティングの項を参照してください。
WebLogic Kubernetes Operatorは、WebLogic ServerおよびKubernetesを統合するアダプタで、KubernetesはWLSインスタンスをホストするコンテナ・インフラストラクチャとして機能できます。 オペレータはKubernetesポッドとして実行され、KubernetesでのWLSの実行に関連するアクションを実行する準備ができています。
Kubernetes Operatorsは、Helmを使用してKubernetesアプリケーションを管理します。 オペレータのHelmチャートは、kubernetes/charts/weblogic-operatorディレクトリにあります。 対応するコマンドを実行してオペレータをインストールしてください。
$ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update
$ helm repo update
$ helm install weblogic-operator weblogic-operator/weblogic-operator
出力には、次のように表示されます:
$ helm install weblogic-operator weblogic-operator/weblogic-operator
NAME: weblogic-operator
LAST DEPLOYED: Tue Jan 18 17:07:56 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
次のコマンドを使用してオペレータを確認します。STATUSはRunningである必要があります。 READYは1/1である必要があります。
$ kubectl get pods -w
NAME READY STATUS RESTARTS AGE
weblogic-operator-69794f8df7-bmvj9 1/1 Running 0 86s
weblogic-operator-webhook-868db5875b-55v7r 1/1 Running 0 86s
-wフラグのため、このコマンドを終了するにはCtrl-Cキーを押す必要があります。
AKSクラスタを作成し、オペレータをインストールし、オペレータの準備ができていることを確認したので、オペレータにWLSドメインを作成するように依頼できます。
$BASE_DIR/sample-scripts/create-weblogic-domain-credentials/create-weblogic-credentials.shスクリプトを使用して、KubernetesシークレットとしてドメインのWebLogic管理者資格証明を作成します。 実行してください:
cd $BASE_DIR/sample-scripts/create-weblogic-domain-credentials
$ ./create-weblogic-credentials.sh -u ${WEBLOGIC_USERNAME} -p ${WEBLOGIC_PASSWORD} -d domain1
secret/domain1-weblogic-credentials created
secret/domain1-weblogic-credentials labeled
The secret domain1-weblogic-credentials has been successfully created in the default namespace.
kubernetes/samples/scripts/create-kubernetes-secrets/create-docker-credentials-secret.shスクリプトを使用して、Docker資格証明をKubernetesシークレットとして作成します。 実行してください:
$ cd $BASE_DIR/sample-scripts/create-kubernetes-secrets
$ ./create-docker-credentials-secret.sh -s ${SECRET_NAME_DOCKER} -e ${ORACLE_SSO_EMAIL} -p ${ORACLE_SSO_PASSWORD} -u ${ORACLE_SSO_EMAIL}
secret/wlsregcred created
The secret wlsregcred has been successfully created in the default namespace.
次のコマンドを使用して、シークレットを確認します:
$ kubectl get secret
NAME TYPE DATA AGE
domain1-weblogic-credentials Opaque 2 2m32s
sh.helm.release.v1.weblogic-operator.v1 helm.sh/release.v1 1 5m32s
weblogic-operator-secrets Opaque 1 5m31s
weblogic-webhook-secrets Opaque 2 5m31s
wlsregcred kubernetes.io/dockerconfigjson 1 38s
ノート: 出力のNAME列に、前述の値のいずれかが欠落している場合は、このサンプルの前述のステップの実行を確認して、それらすべてに正しく従っていることを確認してください。
次のコマンドを実行して、オペレータがネームスペースをモニターできるようにします。
kubectl label namespace default weblogic-operator=enabled
ここで、両方のリソースを定義する単一のYAMLリソース・ファイルを使用して、sample-domain1ドメイン・リソースおよび関連するsample-domain1-cluster-1クラスタ・リソースをデプロイします。 ドメイン・リソースおよびクラスタ・リソースは、WebLogicドメインのデプロイ方法をオペレータに指示します。 従来のWebLogic構成ファイルは置換されませんが、かわりに、これらのファイルと連携して、対応するドメインのKubernetesアーティファクトを記述します。
次のコマンドを実行してリソース・ファイルを生成します。
create-domain-on-aks-generate-yaml.shで参照されるDomain_Creation_Image_tagをエクスポートします。
export Domain_Creation_Image_tag=${LOGIN_SERVER}/wdt-domain-image:WLS-v1
cd $BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service
bash create-domain-on-aks-generate-yaml.sh
前述のコマンドを実行すると、3つのファイルが表示されます: domain-resource.yaml, admin-lb.yaml, cluster-lb.yaml。
ドメイン・リソースは、クラスタ・リソース、WebLogic Serverインストール・イメージ、定義したシークレット、PVおよびPVC構成の詳細、および従来のWebLogic構成とWebLogicアプリケーションを含むサンプルのdomain creation imageを参照します。 詳細については、「ドメインおよびクラスタ・リソース」を参照してください。
次のコマンドを実行して、2つのサンプル・リソースを適用します。
$ kubectl apply -f domain-resource.yaml
次のコマンドを使用してロード・バランサ・サービスを作成します:
$ kubectl apply -f admin-lb.yaml
service/domain1-admin-server-external-lb created
$ kubectl apply -f cluster-lb.yaml
service/domain1-cluster-1-external-lb created
しばらくすると、管理サーバーと管理対象サーバーが実行されていることがわかります。
サーバーポッドのステータスを確認するには、次のコマンドを使用します:
$ kubectl get pods --watch
すべてのポッドのデプロイには最大20分かかる場合があります。お待ちください。準備ができていることを確認してください。
次のコマンドを使用して、管理サーバーのログを末尾に表示できます:
kubectl logs -f domain1-admin-server
ポッド出力の最後の例は次のとおりです:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
domain1-admin-server 1/1 Running 0 12m
domain1-managed-server1 1/1 Running 0 10m
domain1-managed-server2 1/1 Running 0 10m
weblogic-operator-7796bc7b8-qmhzw 1/1 Running 0 48m
weblogic-operator-webhook-b5b586bc5-ksfg9 1/1 Running 0 48m
KubernetesがWebLogicポッドをRunningとして通知する場合、WebLogic Serverが実際に実行されていることを確認できます。これは、オペレータがKubernetesヘルス・チェックが実際にWebLogicヘルス・チェック・メカニズムをポーリングしていることを確認するためです。
管理サーバーおよび管理対象サーバーのアドレスを取得します(外部IPアドレスが割り当てられるまでお待ちください):
$ kubectl get svc --watch
サービス出力の最後の例は次のとおりです:
$ kubectl get svc --watch
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
domain1-admin-server ClusterIP None <none> 7001/TCP 13m
domain1-admin-server-external-lb LoadBalancer 10.0.30.252 4.157.147.131 7001:31878/TCP 37m
domain1-cluster-1-lb LoadBalancer 10.0.26.96 4.157.147.212 8001:32318/TCP 37m
domain1-cluster-cluster-1 ClusterIP 10.0.157.174 <none> 8001/TCP 10m
domain1-managed-server1 ClusterIP None <none> 8001/TCP 10m
domain1-managed-server2 ClusterIP None <none> 8001/TCP 10m
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 60m
weblogic-operator-webhook-svc ClusterIP 10.0.41.121 <none> 8083/TCP,8084/TCP 49m
この例では、管理サーバーにアクセスするためのURLは次のとおりです: http://4.157.147.131/console。 管理コンソールに入力するユーザー名とパスワードは、「シークレットの作成」ステップでdomain1-weblogic-credentialsシークレットに指定したものと一致する必要があります。
WLS管理コンソールがまだ使用できない場合は、kubectl get events --sort-by='.metadata.creationTimestamp' を使用してトラブルシューティングを行います。
$ kubectl get events --sort-by='.metadata.creationTimestamp'
WLS上のサンプル・アプリケーションにアクセスするには、「サンプル・アプリケーションへのアクセス」セクションにスキップできます。 次の項には、前述のすべてのステップを自動化するスクリプトが含まれます。
AKSクラスタおよびWLSドメインを作成する前述のステップを自動化する場合は、スクリプト${BASE_DIR}/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/create-domain-on-aks.shを使用できます。
サンプル・スクリプトは、次のようなWLSドメイン・ホームをAKSクラスタに作成します:
入力値の場合、${BASE_DIR}/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/create-domain-on-aks-inputs.shを直接編集できます。 次の値を指定する必要があります:
| YAMLファイル内の名前 | 値の例 | ノート |
|---|---|---|
dockerEmail |
yourDockerEmail |
WebLogic Server Dockerイメージのプルに使用されるOracle Single Sign-On (SSO)アカウントの電子メール。 |
dockerPassword |
yourDockerPassword |
WebLogic Server Dockerイメージをクリア・テキストでプルするために使用されるOracle SSOアカウントのパスワード。 |
weblogicUserName |
weblogic |
WebLogicユーザー・アカウントのユーザー名。 |
weblogicAccountPassword |
Secret123456 |
WebLogicユーザー・アカウントのパスワード。 |
$ cd ${BASE_DIR}/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service
$ ./create-domain-on-aks.sh
デプロイメントが成功すると、スクリプトによって管理サーバーのアドレスが出力されます。 kubectlを使用してクラスタと対話するには、スクリプト出力に示すようにaz aks get-credentialsを使用します。
これで、Azure Files NFS共有のAKSクラスタが作成され、WLSドメイン構成ファイルが含まれます。 これらのアーティファクトを使用して、オペレータを使用してWLSドメインを作成しました。
管理ロード・バランサのIPアドレスを使用して管理コンソールにアクセスします。
$ ADMIN_SERVER_IP=$(kubectl get svc domain1-admin-server-external-lb -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ echo "Administration Console Address: http://${ADMIN_SERVER_IP}:7001/console/"
クラスタ・ロード・バランサのIPアドレスを使用してサンプル・アプリケーションにアクセスします。
$ CLUSTER_IP=$(kubectl get svc domain1-cluster-1-lb -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ curl http://${CLUSTER_IP}:8001/myapp_war/index.jsp
テスト・アプリケーションは、次のようなサーバー・ホストとサーバーIPを出力に一覧表示します:
<html><body><pre>
*****************************************************************
Hello World! This is version 'v1' of the sample JSP web-app.
Welcome to WebLogic Server 'managed-server1'!
domain UID = '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>
NFSボリュームをバリデートするには、いくつかの方法があります:
kubectl execを使用して管理サーバー・ポッドを入力し、ファイル・システムのステータスを確認します:
kubectl exec -it domain1-admin-server -- df -h
ファイルシステム${AKS_PERS_STORAGE_ACCOUNT_NAME}.file.core.windows.net:/${AKS_PERS_STORAGE_ACCOUNT_NAME}/${AKS_PERS_SHARE_NAME}、サイズ100G、および/sharedにマウントされた次のような出力があります :
Filesystem Size Used Avail Use% Mounted on
...
wlsstorage1612795811.file.core.windows.net:/wlsstorage1612795811/wls-weblogic-1612795811 100G 76M 100G 1% /shared
...
create-domain-on-aks.shスクリプトからの出力には、スクリプトによって作成されたAzureリソースに関する文が含まれます。 クラスタを削除し、関連するすべてのリソースを解放するには、単にリソース・グループを削除します。 出力には、などのリソース・グループが一覧表示されます。
The following Azure Resouces have been created:
Resource groups: wlsresourcegroup6091605169, MC_wlsresourcegroup6091605169_wlsakscluster6091605169_eastus
上記の出力では、次のAzure CLIコマンドによってリソース・グループが削除されます。
$ az group delete --yes --no-wait --name wlsresourcegroup6091605169
AKSクラスタをステップごとに作成した場合は、次のコマンドを実行してリソースをクリーンアップします。
$ az group delete --yes --no-wait --name $AKS_PERS_RESOURCE_GROUP
トラブルシューティングのアドバイスについては、「トラブルシューティング」を参照してください。