> サンプル > Azure Kubernetes Service > Model in Image

Model in Image

このサンプルは、WebLogic Kubernetes Operator (以降はオペレータ)を使用して、model in imageドメイン・ホーム・ソース・タイプを使用してAzure Kubernetesサービス(AKS)にWebLogic Server (WLS)クラスタを設定する方法を示します。ステップを実行した後、WLSドメインはAKSクラスタ・インスタンスで実行され、オペレータと対話することでWLSドメインを管理できます。

前提条件

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

「Azureサブスクリプション」がない場合は、開始する前に「無料アカウント」を作成します。
- サインインしてこの記事を完了するために使用するAzureアイデンティティには、現在のサブスクリプションの「所有者」ロール、または現在のサブスクリプションの「協力者」ロールと「ユーザー・アクセス管理者」ロールのいずれかを使用することをお薦めします。
- アイデンティティのロール割当てが非常に制限されている場合は、AKSクラスタを実行するリソース・グループに「協力者」ロールと「ユーザー・アクセス管理者」ロールがあることを確認してください。これには、リソース・グループにリソースを作成する前に、特権ユーザーにロールの割当てを依頼する必要があります。
オペレーティング・システム: GNU/Linux、macOS (Intelのみ、Apple Siliconはサポートされていません) WSL2 for Windows 10。
Git; git --versionを使用して、gitが動作するかどうかをテストします。このドキュメントは、バージョン2.25.1でテストされました。
Azure CLI ; az --versionを使用して、azが動作するかどうかをテストします。このドキュメントは、バージョン2.58.0でテストされました。
Docker for Desktop。このドキュメントはDocker version 20.10.7でテストされました
kubectl: kubectl versionを使用して、kubectlが動作するかどうかをテストします。このドキュメントは、バージョンv1.21.2でテストされました。
Helm、バージョン3.1以降、helm versionを使用してhelmバージョンを確認します。このドキュメントは、バージョンv3.6.2でテストされました。
Java JDK、バージョン8または11。 Azureでは、「Microsoft OpenJDKのビルド」をお薦めします。コマンドを実行するシェルで、JAVA_HOME環境変数が正しく設定されていることを確認します。
zip/unzipユーティリティがインストールされていることを確認します。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.>"

export BASE_DIR=~
export NAME_PREFIX=wls

# Used to generate resource names.
export TIMESTAMP=`date +%s`
export ACR_NAME="acr${TIMESTAMP}"
export AKS_CLUSTER_NAME="aks${TIMESTAMP}"
export AKS_PERS_RESOURCE_GROUP="resourcegroup${TIMESTAMP}"
export AKS_PERS_LOCATION=eastus

export SECRET_NAME_DOCKER="${NAME_PREFIX}regcred"
export WEBLOGIC_USERNAME=weblogic
export WEBLOGIC_PASSWORD=Secret123456
export WEBLOGIC_WDT_PASSWORD=Secret123456

Oracle Container Registry

Oracleアカウントが必要です。次のステップでは、WebLogic Serverのライセンス契約に同意します。 Oracle Accountのパスワードと電子メールをノートにとります。このサンプルは12.2.1.4に関連していますが、他のバージョンも動作する場合があります。

webブラウザで、https://container-registry.oracle.comに移動し、Oracle Single Sign-On認証サービスを使用してログインします。 SSO資格証明がまだない場合は、ページの上部にあるSign Inリンクをクリックして作成します。
Oracle Container Registryには、このサンプルで使用されるWebLogic 12.2.1.4一般提供 (GA)インストール・イメージが用意されています。
ノート: 一般提供(GA)イメージは、パブリック・インターネットから環境を使用できないデモおよび開発目的onlyに適しています。これらは「本番で使用できません」。本番では、常にOCRのCPU (パッチ適用済)イメージを使用するか、--recommendedPatchesオプションを指定したWebLogic Image Tool (WIT)を使用してイメージを作成する必要があります。詳細は、「Oracle WebLogic Serverの本番環境の保護」の「最新のパッチと更新の適用」を参照してください。

Dockerが実行されていることを確認します。 WebLogic 12.2.1.4インストール・イメージを検索してプルします:

$ 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
```

WebLogic Kubernetes Operatorサンプルをダウンロードします。

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クラスタの作成

このサンプルはアプリケーション・ルーティングを有効にしません。アプリケーション・ルーティングを有効にする場合は、「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 Kubernetes Operatorのインストール

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

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

$ 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

このコマンドを使用して、サービス・アカウントが作成されたことを確認します。

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

NAME                          SECRETS   AGE
default                       1         9m24s
sample-weblogic-operator-sa   1         9m5s

オペレータをインストールします。オペレータのHelmチャートは、kubernetes/charts/weblogic-operatorディレクトリにあります。このサンプルでは、GithubからHelmチャートを使用してオペレータをインストールします。オペレータのインストールには数分かかる場合があります。

$ helm repo add weblogic-operator https://oracle.github.io/weblogic-kubernetes-operator/charts --force-update

リポジトリを更新して、最新のHelmチャートを取得します。これは、新しいオペレータ・バージョンをインストールする前に毎回行うことをお勧めします。この例では、固定バージョンを使用していますが、最新バージョンを使用すると成功する場合があります。この場合、--version引数は省略できます。これらの指示は、表示されている正確なバージョンでのみテストされていることに注意してください。

$ helm repo update
$ helm install weblogic-operator weblogic-operator/weblogic-operator \
  --namespace sample-weblogic-operator-ns \
  --version 4.2.5 \
  --set serviceAccount=sample-weblogic-operator-sa \
  --wait

出力には、次のように表示されます:

NAME: weblogic-operator
LAST DEPLOYED: Fri Aug 12 14:28:47 2022
NAMESPACE: sample-weblogic-operator-ns
STATUS: deployed
REVISION: 1
TEST SUITE: None

より新しいバージョンのオペレータを使用する場合は、前述のコマンドの4.2.5を他のバージョン番号に置き換えます。バージョンのリストを表示するには、「GitHubリリース・ページ」を参照してください。

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

$ helm list -A

NAME                    NAMESPACE                       REVISION        UPDATED                                 STATUS CHART                    APP VERSION
weblogic-operator       sample-weblogic-operator-ns     1               2023-05-15 10:31:05.1890341 +0800 CST   deployeweblogic-operator-4.2.5  4.2.5

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

NAME                                         READY   STATUS    RESTARTS   AGE
weblogic-operator-54b5c8df46-g4rcm           1/1     Running   0          86s
weblogic-operator-webhook-6c5885f69f-pd8qw   1/1     Running   0          86s

--set imageの値を変更して、オペレータ・イメージを指定できます。失敗が発生した場合は、「トラブルシューティング - WebLogic Kubernetes Operatorのインストール失敗」を参照してください。

Model in Imageに続くドメイン・モデルでイメージが構築されている場合は、「WebLogicドメインの作成」に直接移動できます。

Dockerイメージの作成

イメージ作成の前提条件

JAVA_HOME環境変数を設定し、有効なJDK 8または11インストールを参照する必要があります。
サンプルを新しいディレクトリにコピーします。たとえば、ディレクトリ/tmp/mii-sampleを使用します。ディレクトリ名では、miiは"model in image"の短縮形です。 Model in imageは、オペレータでサポートされている3つのドメイン・ホーム・ソース・タイプのいずれかです。詳細は、「ドメイン・ホーム・ソース・タイプの選択」を参照してください。
```
$ rm /tmp/mii-sample -f -r
$ mkdir /tmp/mii-sample
```
```
$ cp -r $BASE_DIR/sample-scripts/create-weblogic-domain/wdt-artifacts/* /tmp/mii-sample
```
モデル・ファイルのディレクトリを保存します。
```
$ export WDT_MODEL_FILES_PATH=/tmp/mii-sample/wdt-model-files
```
ノート: サンプルのこの作業用コピーを/tmp/mii-sampleと呼びますが、別のロケーションを使用できます。

最新の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とタグ付けされたイメージを作成することを示しています。

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

最初のアーカイブの理解

「最初のアーカイブの理解」を参照してください。

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

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

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

# Delete existing archive.zip in case we have an old leftover version
$ rm -f ${WDT_MODEL_FILES_PATH}/WLS-v1/archive.zip

WebLogic Image Toolの実行時に使用するロケーションに、アーカイブのZIPファイルを作成します。

$ cd /tmp/mii-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-1
- 管理サーバーadmin-server
- cluster-1をターゲットとするEARアプリケーション。wlsdeploy/applications/myapp-v1のWDTアーカイブZIPファイルにあります
マクロを利用して外部値をインジェクトします:
- プロパティ・ファイルの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を使用したイメージの作成

この時点で、ステージングされた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ベース・イメージのレイヤーとしてビルドします。
WITキャッシュで参照されるWDT ZIPファイルをイメージにコピーします。
- サンプルの前提条件ステップでキャッシュを設定するときに、キーワードlatestを使用してWITにWDTをキャッシュしたことに注意してください。
- これにより、WITはそれが目的のWDTバージョンであると暗黙的に想定し、-wdtVersionフラグを渡す必要がなくなります。
指定されたWDTモデル、プロパティおよびアプリケーション・アーカイブをイメージのロケーション/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の失敗」を参照してください。

Azure Container Registryへのイメージのプッシュ

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が含まれます。

Dockerがローカル・マシンで実行されていることを確認します。次のコマンドを実行して、イメージにタグ付けし、ACRにプッシュします。

$ docker tag wdt-domain-image:WLS-v1 $LOGIN_SERVER/mii-aks-auxiliary-image:1.0

$ docker push $LOGIN_SERVER/mii-aks-auxiliary-image:1.0

The push refers to repository [contosorgresourcegroup1610068510.azurecr.io/mii-aks-auxiliary-image]
1.0: digest: sha256:208217afe336053e4c524caeea1a415ccc9cc73b206ee58175d0acc5a3eeddd9 size: 2415

最後に、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ドメインの作成

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

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

ネームスペース

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

$ kubectl create namespace sample-domain1-ns

オペレータがWebLogic Serverポッドを自動検出および作成できるように、ドメイン・ネームスペースにラベルを付けます。このステップがない場合、オペレータはネームスペースを表示できません。

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

WebLogicイメージのKubernetesシークレット

kubernetes/samples/scripts/create-kubernetes-secrets/create-docker-credentials-secret.shスクリプトを使用して、Docker資格証明をKubernetesシークレットとして作成し、OCRからイメージをプルします。実行してください:

$ $BASE_DIR/sample-scripts/create-kubernetes-secrets/create-docker-credentials-secret.sh \
  -n sample-domain1-ns \
  -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 sample-domain1-ns namespace.

WebLogicのKubernetesシークレット

最初に、WLSタイプ・モデル・ドメインで必要なシークレットを作成します。実行中のドメインのコンテキストでのシークレットの詳細は、「ドメインを実行する準備」を参照してください。この場合、2つのシークレットがあります。

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

$ kubectl -n sample-domain1-ns create secret generic \
  sample-domain1-weblogic-credentials \
   --from-literal=username="${WEBLOGIC_USERNAME}" \
   --from-literal=password="${WEBLOGIC_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="${WEBLOGIC_WDT_PASSWORD}"

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

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

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

これで、次のコマンドを使用してシークレットを確認できます:

kubectl get secrets -n sample-domain1-ns

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

NAME                                       TYPE                             DATA   AGE
sample-domain1-runtime-encryption-secret   Opaque                           1      19s
sample-domain1-weblogic-credentials        Opaque                           2      28s
wlsregcred                                 kubernetes.io/dockerconfigjson   1      47s

ドメイン・リソース

次に、ドメインYAMLファイルを作成します。ドメインYAMLファイルは、Kubernetesを使用してWebLogicドメインの一部の側面を構成する方法と考えてください。オペレータは、Kubernetesのカスタム・リソース機能を使用して、Domainと呼ばれるKubernetesリソース・タイプを定義します。 Domain Kubernetesリソースの詳細は、「ドメイン・リソース」を参照してください。カスタム・リソースの詳細は、「Kubernetesのドキュメント」を参照してください。

ドメイン・リソースの説明を生成するためのスクリプトを$BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/create-domain-on-aks-mii-generate-yaml.shで提供します。

次のコマンドを実行してリソース・ファイルを生成します。

export Domain_Creation_Image_tag="$LOGIN_SERVER/mii-aks-auxiliary-image:1.0"

$ cd $BASE_DIR
$ bash $BASE_DIR/sample-scripts/create-weblogic-domain-on-azure-kubernetes-service/create-domain-on-aks-mii-generate-yaml.sh

前述のコマンドを実行すると、3つのファイルが表示されます: mii-initial.yaml、admin-lb.yamlおよびcluster-lb.yaml。

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

$ kubectl apply -f mii-initial.yaml

成功した出力は次のようになります:

domain.weblogic.oracle/sample-domain1 created
cluster.weblogic.oracle/sample-domain1-cluster-1 created

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

$ kubectl get pods -n sample-domain1-ns --watch

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

NAME                                READY   STATUS              RESTARTS   AGE
sample-domain1-introspector-xwpbn   0/1     ContainerCreating   0          0s
sample-domain1-introspector-xwpbn   1/1     Running             0          1s
sample-domain1-introspector-xwpbn   0/1     Completed           0          66s
sample-domain1-introspector-xwpbn   0/1     Terminating         0          67s
sample-domain1-introspector-xwpbn   0/1     Terminating         0          67s
sample-domain1-admin-server         0/1     Pending             0          0s
sample-domain1-admin-server         0/1     Pending             0          0s
sample-domain1-admin-server         0/1     ContainerCreating   0          0s
sample-domain1-admin-server         0/1     Running             0          2s
sample-domain1-admin-server         1/1     Running             0          42s
sample-domain1-managed-server1      0/1     Pending             0          0s
sample-domain1-managed-server1      0/1     Pending             0          0s
sample-domain1-managed-server1      0/1     ContainerCreating   0          0s
sample-domain1-managed-server2      0/1     Pending             0          0s
sample-domain1-managed-server2      0/1     Pending             0          0s
sample-domain1-managed-server2      0/1     ContainerCreating   0          0s
sample-domain1-managed-server2      0/1     Running             0          3s
sample-domain1-managed-server2      1/1     Running             0          40s
sample-domain1-managed-server1      0/1     Running             0          53s
sample-domain1-managed-server1      1/1     Running             0          93s

システムが次の状態で安定すると、続行しても安全です。

NAME                             READY   STATUS    RESTARTS   AGE
sample-domain1-admin-server      1/1     Running   0          2m
sample-domain1-managed-server1   1/1     Running   0          83s
sample-domain1-managed-server2   1/1     Running   0          83s

すべてのポッドのデプロイには最大10分かかる場合があります。お待ちください。準備ができていることを確認してください。

システムがこの状態に達しない場合は、続行する前に問題をトラブルシューティングして解決してください。ヒントについては、「トラブルシューティング」を参照してください。

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

Azureロード・バランサの作成

WebLogic Server管理コンソールおよびクラスタにデプロイされたアプリケーションにアクセスするためのAzureパブリック標準ロード・バランサを作成します。

admin-lb.yamlの構成ファイルを使用して、管理サーバーのロード・バランサ・サービスを作成します。事前定義済YAMLファイルを使用せず、かわりにカスタマイズされた値で新しいYAMLファイルを作成する場合は、次のコンテンツをドメイン値に置き換えます。

「YAMLコンテンツを表示するには、ここをクリックしてください。」

cluster-lb.yamlの構成ファイルを使用して、管理対象サーバーのロード・バランサ・サービスを作成します。事前定義済YAMLファイルを使用せず、かわりにカスタマイズされた値を使用して新しいYAMLファイルを作成する場合は、次のコンテンツをドメイン値に置き換えます。

「YAMLコンテンツを表示するには、ここをクリックしてください。」

次のコマンドを使用してロード・バランサ・サービスを作成します:

$ kubectl apply -f admin-lb.yaml

service/sample-domain1-admin-server-external-lb created

$ kubectl  apply -f cluster-lb.yaml

service/sample-domain1-cluster-1-external-lb created

管理サーバーおよびクラスタ・ロード・バランサの外部IPアドレスを取得します(外部IPアドレスが割り当てられるまでお待ちください):

$ kubectl get svc -n sample-domain1-ns --watch

NAME                                      TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)          AGE
sample-domain1-admin-server               ClusterIP      None           <none>           7001/TCP         8m33s
sample-domain1-admin-server-external-lb   LoadBalancer   10.0.184.118   52.191.234.149   7001:30655/TCP   2m30s
sample-domain1-cluster-1-lb               LoadBalancer   10.0.76.7      52.191.235.71    8001:30439/TCP   2m25s
sample-domain1-cluster-cluster-1          ClusterIP      10.0.118.225   <none>           8001/TCP         7m53s
sample-domain1-managed-server1            ClusterIP      None           <none>           8001/TCP         7m53s
sample-domain1-managed-server2            ClusterIP      None           <none>           8001/TCP         7m52s

この例では、管理サーバーにアクセスするためのURLは次のとおりです: http://52.191.234.149:7001/console。必要なユーザー名とパスワードは、「WebLogicのKubernetesシークレット」ステップで選択した値と一致する必要があります。

重要: コンソールへのアクセスを制御するネットワーク・セキュリティ・グループ・ルールで、ポート7001でインバウンド・トラフィックが許可されていることを確認する必要があります。

WLS管理コンソールがまだ使用できない場合は、kubectl describe domainを使用してドメイン・ステータスを確認します。

$ kubectl describe domain domain1

cluster-1のステータスがServersReadyおよびAvailableであることを確認します。

「サンプルのドメイン・ステータスを表示するには、ここをクリックしてください。」

Name:         sample-domain1
Namespace:    sample-domain1-ns
Labels:       weblogic.domainUID=sample-domain1
Annotations:  <none>
API Version:  weblogic.oracle/v9
Kind:         Domain
Metadata:
  Creation Timestamp:  2020-11-30T05:40:11Z
  Generation:          1
  Resource Version:    9346
  Self Link:           /apis/weblogic.oracle/v9/namespaces/sample-domain1-ns/domains/sample-domain1
  UID:                 9f10a602-714a-46c5-8dcb-815616b587af
Spec:
  Admin Server:
    Server Start State:  RUNNING
  Clusters:
    Cluster Name:  cluster-1
    Replicas:      2
    Server Pod:
      Affinity:
        Pod Anti Affinity:
          Preferred During Scheduling Ignored During Execution:
            Pod Affinity Term:
              Label Selector:
                Match Expressions:
                  Key:       weblogic.clusterName
                  Operator:  In
                  Values:
                    $(CLUSTER_NAME)
              Topology Key:  kubernetes.io/hostname
            Weight:          100
    Server Start State:      RUNNING
  Configuration:
    Model:
      Domain Type:                WLS
      Runtime Encryption Secret:  sample-domain1-runtime-encryption-secret
  Domain Home:                    /u01/domains/sample-domain1
  Domain Home Source Type:        FromModel
  Image:                          docker.io/sleepycat2/wls-on-aks:model-in-image
  Image Pull Policy:              IfNotPresent
  Image Pull Secrets:
    Name:                         regsecret
  Include Server Out In Pod Log:  true
  Replicas:                       1
  Restart Version:                1
  Server Pod:
    Env:
      Name:   CUSTOM_DOMAIN_NAME
      Value:  domain1
      Name:   JAVA_OPTIONS
      Value:  -Dweblogic.StdoutDebugEnabled=false
      Name:   USER_MEM_ARGS
      Value:  -Djava.security.egd=file:/dev/./urandom -Xms256m -Xmx512m
    Resources:
      Requests:
        Cpu:            250m
        Memory:         768Mi
  Server Start Policy:  IfNeeded
  Web Logic Credentials Secret:
    Name:  sample-domain1-weblogic-credentials
Status:
  Clusters:
    Cluster Name:      cluster-1
    Maximum Replicas:  5
    Minimum Replicas:  0
    Ready Replicas:    2
    Replicas:          2
    Replicas Goal:     2
  Conditions:
    Last Transition Time:        2020-11-30T05:45:15.493Z
    Reason:                      ServersReady
    Status:                      True
    Type:                        Available
  Introspect Job Failure Count:  0
  Replicas:                      2
  Servers:
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-11-30T05:44:15.652Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      aks-pool1model-71528953-vmss000001
    Server Name:    admin-server
    State:          RUNNING
    Cluster Name:   cluster-1
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-11-30T05:44:54.699Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      aks-pool1model-71528953-vmss000000
    Server Name:    managed-server1
    State:          RUNNING
    Cluster Name:   cluster-1
    Desired State:  RUNNING
    Health:
      Activation Time:  2020-11-30T05:45:07.211Z
      Overall Health:   ok
      Subsystems:
        Subsystem Name:  ServerRuntime
        Symptoms:
    Node Name:      aks-pool1model-71528953-vmss000001
    Server Name:    managed-server2
    State:          RUNNING
    Cluster Name:   cluster-1
    Desired State:  SHUTDOWN
    Server Name:    managed-server3
    Cluster Name:   cluster-1
    Desired State:  SHUTDOWN
    Server Name:    managed-server4
    Cluster Name:   cluster-1
    Desired State:  SHUTDOWN
    Server Name:    managed-server5
  Start Time:       2020-11-30T05:40:11.709Z
Events:             <none>

アプリケーションへのアクセス

管理ロード・バランサのIPアドレスを使用して管理コンソールにアクセスします。

$ ADMIN_SERVER_IP=$(kubectl -n sample-domain1-ns get svc sample-domain1-admin-server-external-lb -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ echo "Administration Console Address: http://${ADMIN_SERVER_IP}:7001/console/"

クラスタ・ロード・バランサのIPアドレスを使用してサンプル・アプリケーションにアクセスします。

## Access the sample application using the cluster load balancer IP.
$ CLUSTER_IP=$(kubectl -n sample-domain1-ns get svc sample-domain1-cluster-1-lb -o=jsonpath='{.status.loadBalancer.ingress[0].ip}')

$ curl http://${CLUSTER_IP}: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-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>

Rolling updates

通常は、wlsdeploy/applications/myapp-v1のWDTアーカイブZIPファイルにある新しいバージョンのEARアプリケーションをデプロイします。これを行う方法を学習するには、「更新3」のステップに従います。

データベース接続

WebLogic ServerアプリケーションでデータベースをAKSに接続する方法のガイダンスは、「Azure Kubernetesサービス(AKS)クラスタにWebLogic Serverを使用してJavaアプリケーションをデプロイ」を参照してください。

リソースのクリーンアップ

次のコマンドを実行して、リソースをクリーンアップします。

$ az group delete --yes --no-wait --name $AKS_PERS_RESOURCE_GROUP

トラブルシューティング

トラブルシューティングのアドバイスについては、「トラブルシューティング」を参照してください。

便利なリンク

Model in Imageユーザー・ドキュメント
Model in Imageサンプル
Azure Kubernetesサービス(AKS)クラスタにWebLogic Serverを使用してJavaアプリケーションをデプロイ

Model in Image

目次

前提条件

パラメータの準備

Oracle Container Registry

Azure CLIでサインイン

WebLogic Kubernetes Operatorサンプルをダウンロードします。

リソース・グループの作成

AKSクラスタの作成

WebLogic Kubernetes Operatorのインストール

Dockerイメージの作成

イメージ作成の前提条件

イメージの作成 - 導入

最初のアーカイブの理解

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

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

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

Azure Container Registryへのイメージのプッシュ

WebLogicドメインの作成

ネームスペース

WebLogicイメージのKubernetesシークレット

WebLogicのKubernetesシークレット

ドメイン・リソース

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

Azureロード・バランサの作成

アプリケーションへのアクセス

Rolling updates

データベース接続

リソースのクリーンアップ

トラブルシューティング

便利なリンク