原文はこちら。
https://blogs.oracle.com/weblogicserver/best-practices-for-application-deployment-on-weblogic-server-running-on-kubernetes-v2
Overview
WebLogic ServerとKubernetesはそれぞれ、アプリケーションのデプロイをサポートする豊富な機能を提供します。Kubernetes上でのWebLogic Serverの動作保証のための検証プロセスの一環として、KubernetesおよびDocker環境で動作するWebLogic ServerインスタンスにJava EEアプリケーションをデプロイするためのベストプラクティスを確認したので、その内容を説明します。このベストプラクティスには、以下のドキュメントにて説明されている一般的な推奨事項と、Kubernetesで提供されているアプリケーションデプロイメント機能が含まれています。
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Understanding WebLogic Server Deployment
https://docs.oracle.com/middleware/12213/wls/DEPGD/understanding.htm#DEPGD114
Application Deployment Terminology
WebLogic ServerとKubernetesは、管理するリソースに同じ用語を使用しますが、意味は異なります。具体的には、アプリケーションまたはデプロイメントの概念はわずかに異なる意味を持つため、混乱を招く可能性があります。 下表は、このエントリで使用する重要な用語と、WebLogic ServerとKubernetesでの定義内容の違いを示しています。 Kubernetes用語集のリストを含む標準化された用語集は、以下のURLをご覧ください。
Standardized Glossary
https://kubernetes.io/docs/reference/glossary/?tool=true
Table 1 Application Deployment Terminology | WebLogic Server | Kubernetes |
|---|
| アプリケーション | Java EE仕様に従って構成された、Java EEアプリケーション（エンタープライズアプリケーションまたはWebアプリケーション）またはスタンドアロンJava EEモジュール（EJBやリソースアダプタなど）。
アプリケーションユニットには、Webアプリケーション、エンタープライズアプリケーション、EJB、リソースアダプタ、Webサービス、Java EEライブラリ、またはオプションパッケージが含まれる。
アプリケーションユニットには、JDBC、JMS、WLDFモジュール、またはクライアントアプリケーションアーカイブが含まれることがある。 | Kubernetesがクラスタ環境でコンテナ化して管理するソフトウェア。 WebLogic ServerはKubernetesアプリケーションの一例。 |
| アプリケーション・デプロイメント | WebLogic Serverでクライアントリクエストを処理するためにJava Enterprise Edition（Java EE）アプリケーションまたはモジュールを使用可能にするプロセス。 | クラスタ化された環境でコンテナ化されたアプリケーションをパッケージ化し、インスタンス化し、実行し、通信する方法。
Kubernetesには、複製されたアプリケーションを管理するDeploymentというAPIオブジェクトもある。 |
| デプロイメント・ツール | - weblogic.Deployerユーティリティ
- 管理コンソール
- WebLogic Scripting Tool (WLST)
- wldeploy Ant task
- weblogic-maven-plugin Maven plug-in
- WebLogic Deployment API
- Auto-deployment機能
| - kubeadm
- kubectl
- minikube
- Helm Chart
- kops
|
| クラスタ | WebLogicクラスタは複数のWebLogic Serverインスタンスで構成され、拡張性と信頼性を向上するために同時に稼働・連携する。クラスタはクライアントからは、単一のWebLogic Serverインスタンスのように見える。クラスタを構成するサーバーインスタンスは、同じマシン上で実行することも、別のマシン上に配置することもできる。既存のマシンのクラスタにサーバーインスタンスを追加するか、追加サーバーインスタンスをホストするためにマシンをクラスタに追加して、クラスタの容量を増やすことも可能。クラスタ内の各サーバインスタンスは、同じバージョンのWebLogic Serverを実行する必要がある。 | Kubernetesクラスタは、マスタノードと一連のワーカーノードで構成される。本番環境では、これらは複数ノード上の分散配置で実行される。テスト目的では、すべてのコンポーネントを同じノード（物理ホストまたは仮想マシン）で実行可能。 |
このエントリでは、以下の定義を使用します。
- このエントリ内で述べるアプリケーションはJava EEアプリケーションを指す。
- このエントリ内で述べるアプリケーションデプロイメントは、WebLogic Serverへのアプリケーションデプロイメントを指す。
- KubernetesアプリケーションはKubernetesが管理するソフトウェアを指す（例えばWebLogic Server）。
Summary of Best Practices for Application Deployment in Kubernetes
このエントリの、Kubernetesで動作するWebLogic Serverのアプリケーションデプロイメントのベストプラクティスには、複数のパートに分かれています。
- Java EEアプリケーションデプロイメントファイルをKubernetes環境に配布し、Pod内のWebLogic Serverコンテナがデプロイメントファイルにアクセスできる。
- Kubernetes環境のJava EEアプリケーションをデプロイすると、アプリケーションはPod内のWebLogic Serverコンテナで利用可能になり、クライアントリクエストを処理できるようになる。
- KubernetesアプリケーションとReadyAppフレームワークを統合して、Kubernetesアプリケーションの準備状況を確認する。
General Java EE Application Deployment Best Practices Overview
ベストプラクティスの詳細を掘り下げて説明する前に、一般的なJava EEアプリケーション・デプロイメントのベストプラクティスについて簡単に説明します。この内容は、以下のドキュメントに記載があります。
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
https://docs.oracle.com/middleware/12213/wls/DEPGD/toc.htm
一般的なJava EEアプリケーションのデプロイメントプロセスは複数のパートから構成されています。
- Java EEアプリケーションまたはモジュールの準備
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Preparing Applications and Modules for Deployment
https://docs.oracle.com/middleware/12213/wls/DEPGD/deployunits.htm#DEPGD141
Handling Unsupported FastSwap Changes
https://docs.oracle.com/middleware/12213/wls/DEPGD/deployunits.htm#DEPGD163
- デプロイメントのためのJava EEアプリケーションまたはモジュールの構成
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Configuring Applications for Production Deployment
https://docs.oracle.com/middleware/12213/wls/DEPGD/config.htm#DEPGD165
Application Usage
https://docs.oracle.com/middleware/12213/wls/DEPGD/config.htm#DEPGD193
- 新環境にデプロイするためのJava EEアプリケーションまたはモジュールのエクスポート
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Exporting an Application for Deployment to New Environments
https://docs.oracle.com/middleware/12213/wls/DEPGD/export.htm#DEPGD195
Validating the Exported Deployment Configuration
https://docs.oracle.com/middleware/12213/wls/DEPGD/export.htm#DEPGD211
- Java EEアプリケーションもしくはモジュールのデプロイ
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Deploying Applications and Modules with weblogic.Deployer
https://docs.oracle.com/middleware/12213/wls/DEPGD/deploy.htm#DEPGD212
Best Practices for Deploying Applications
https://docs.oracle.com/middleware/12213/wls/DEPGD/deploy.htm#DEPGD253
- Java EEアプリケーションもしくはモジュールの再デプロイ
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Redeploying Applications in a Production Environment
https://docs.oracle.com/middleware/12213/wls/DEPGD/redeploy.htm#DEPGD258
Distributing Java EE Application Deployment Files in Kubernetes
WebLogic ServerインスタンスがKubernetesおよびDocker環境に展開されていると仮定します。WebLogic ServerインスタンスにJava EEアプリケーションをデプロイする前に、EAR、WAR、RARファイルなどのJava EEアプリケーションデプロイメントファイルを、Pod内のWebLogic Serverインスタンスがアクセスできる場所に配布する必要があります。Kubernetesでは、デプロイメントファイルはDockerイメージを使用して配布することも、管理者が手作業で配布することもできます。
Pre-distribution of Java EE Applications in Docker Images
Dockerイメージには、1つ以上のJava EEアプリケーションがデプロイされている、事前構築済みのWebLogic Serverドメインのホームディレクトリを含めることができます。同じDockerイメージを使用してPod内のコンテナを作成、起動すると、すべてのコンテナに同じJava EEアプリケーションが配備されているはずです。
Dockerイメージ内のJava EEアプリケーションを新しいバージョンに更新する場合、Figure 1に示すように、現在の既存のDockerイメージ上に新しいDockerイメージを作成できます。
しかしながら、より新しいアプリケーションのバージョンを導入するにつれ、イメージ内に追加のレイヤーが必要になりますが、これによりディスクスペースなどのより多くのリソースを消費します。したがって、Dockerイメージに過剰な数のレイヤーを持たせるのはお勧めしません。
![]() |
| Figure 1 Pre-distribution of Java EE Application in layered Docker Images |
Using Volumes in a Kubernetes Cluster
Podのアプリケーションボリュームディレクトリをホスト上の外部ディレクトリにマッピングすることによって、アプリケーションファイルをすべてのPod内のすべてのコンテナ間で共有できます。これにより、アプリケーションファイルはPod内のすべてのコンテナからアクセスできるようになります。ボリュームを使用する場合は、アプリケーションファイルをホスト上のディレクトリに一度だけコピーする必要があります。各Podにファイルをコピーする必要はありません。これにより、特に大規模なアプリケーションの場合、ディスクスペースとデプロイ時間を節約できます。Kubernetes上で実行しているWebLogic ServerインスタンスにJava EEアプリケーションを配布する場合は、ボリュームの使用をお勧めします。
![]() |
| Figure 2 Mounting Volumes to an External Directory |
Figure 2に示すように、3つのPodの各コンテナには、アプリケーションボリュームディレクトリ（/shared/applications）があります。これらのディレクトリはそれぞれ、ホスト上の同じ外部ディレクトリ（/host/apps）にマップされています。管理者がアプリケーションファイル（simpleApp.war）をホスト上の /host/apps ディレクトリに置くと、各Podのコンテナは /shared/applications ディレクトリからこのファイルにアクセスできます。
Kubernetesは異なるボリュームタイプをサポートします。使用するボリュームの種類の決定、ボリュームディレクトリの作成、バックアップするメディアの決定、およびボリュームの内容の特定については、KubernetesのドキュメントのVolumesの項をご覧ください。
Volumes
https://kubernetes.io/docs/concepts/storage/volumes/
Best Practices for Distributing Java EE Application Deployment Files in Kubernetes
Java EE Application Deployment in Kubernetes
アプリケーション・デプロイメント・ファイルをKubernetesクラスタ全体に配置した後、Pod内のコンテナにJava EEアプリケーションを展開するためのWebLogic Serverデプロイメントツールが数種類あります。
WebLogic Serverは、Java EEアプリケーションのデプロイ、アンデプロイ、リデプロイのための以下のデプロイメント・ツールをサポートします。
- WebLogic管理コンソール
- WebLogic Scripting Tool (WLST)
- weblogic.Deployerユーティリティ
- REST API
- wldeploy Ant タスク
- Javaクラスを使ってプログラムでデプロイメント・タスクを実行できるWebLogic Deployment API
- 自動デプロイ機能。 自動デプロイを有効にすると、管理サーバの /autodeploy ディレクトリにアプリケーションをコピーすれば、そのアプリケーションが自動的にデプロイされる。自動デプロイは、開発環境での評価またはテスト目的で使用されることを意図している。
これらのデプロイメントツールの使用の詳細は、以下のドキュメントを参照してください。
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
https://docs.oracle.com/middleware/12213/wls/DEPGD/toc.htm
これらのツールは、Kubernetesでも使用できます。以下は、WebLogicクラスタmyClusterにアプリケーションsimpleApp.warをデプロイおよびアンデプロイする方法の例です。
- DockerfileでのWLSTの利用
- weblogic.Deployerユーティリティの利用
- REST APIの利用
（注意）デプロイメントコマンドを実行する環境は、以下のGitHubにあるサンプルWebLogicドメインwls-k8s-domainに基づいて作成されています。
WebLogic Sample on Kubernetes with Shared Domain Home
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain
この環境では
- サンプルのWLS 12.2.1.3ドメインとクラスタは、Oracle WebLogic developerインストールイメージを拡張し、Kubernetesで実行して作成されます。WebLogicドメイン（例えば、base_domain）は、WebLogicクラスタmyClusterで実行されている管理サーバーといくつかの管理対象サーバーで構成されています。各WebLogic Serverはコンテナ内で起動されます。各PodにはWebLogic Serverコンテナが1つあります。wls-k8s-domainサンプルの詳細については、GitHubのページを参照してください。
Sample WebLogic 12.2.1.3 domain image orchestrated in Kubernetes
https://github.com/oracle/docker-images/pull/665/commits/676b878abcf4887b374759a8d6a767f1b7b85197
- 各Podには、1つのドメインホームボリュームディレクトリ（例えば/u01/wlsdomain）があります。このドメインホームボリュームディレクトリは、外部ディレクトリ（例えば、/host/domain）にマップされます。サンプルのWLS 12.2.1.3ドメインは、この外部ディレクトリの下に作成されます。
- 各Podには、ドメインホームボリュームディレクトリと同じ方法で作成されたアプリケーションボリュームディレクトリ（例えば、/shared/applications）があります。このアプリケーションボリュームディレクトリは、外部ディレクトリ（例えば、/host/apps）にマップされています。Java EEアプリケーションは、この外部ディレクトリに配布できます。
Sample of Using Offline WLST in a Dockerfile to Deploy a Java EE Application
このサンプルでは、Dockerfileを使い、アプリケーションDockerイメージを構築しています。このアプリケーションのDockerイメージは、wls-k8s-domainというサンプルドメインを作成するwls-k8s-domainイメージを拡張しています。また、このDockerfileは、wls-k8s-domainサンプルドメインの構成をオフラインモードで新しいアプリケーションデプロイメントでアップデートするPythonスクリプトを使ってWLSTを呼び出します。
# Dockerfile
# Extends wls-k8s-domain
FROM wls-k8s-domain
# Copy the script files and call a WLST script.
COPY container-scripts/* /u01/oracle/
# Run a py script to add a new application deployment into the domain configuration
RUN wlst /u01/oracle/app-deploy.py
スクリプト app-deploy.py を呼び出し、オフラインWLST APIを使ってアプリケーション simpleApp.war をデプロイします。
# app-deploy.py
# Read the domain
readDomain(domainhome)
# Create application
# ==================
cd('/')
app = create('simpleApp', 'AppDeployment')
app.setSourcePath('/shared/applications/simpleApp.war')
app.setStagingMode('nostage')
# Assign application to cluster
# =================================
assign('AppDeployment', 'simpleApp, 'Target', 'myCluster')
# Update domain. Close It. Exit
# =================================
updateDomain()
closeDomain()
exit()
アプリケーションは、アプリケーションのDockerイメージ構築フェーズでデプロイされます。WebLogic Serverコンテナが起動されると、simpleAppアプリケーションが起動され、クライアントリクエストを処理できる状態になります。
Sample of Using weblogic.Deployer to Deploy and Undeploy a Java EE Application in Kubernetes
このサンプルでは、アプリケーションsimpleApp.warは、Using External Volumes in Kubernetes Clusterに記載の通り、ホスト上の /host/appsという外部ディレクトリに存在します。
以下のコマンドは、管理サーバーPodでwebloigc.Deployerユーティリティを実行している様子を示したものです。
# Find the pod id for Admin Server pod: admin-server-1238998015-f932w
> kubectl get pods
NAME READY STATUS RESTARTS AGE
admin-server-1238998015-f932w 1/1 Running 0 11m
managed-server-0 1/1 Running 0 11m
managed-server-1 1/1 Running 0 8m
# Find the Admin Server service name that can be connected to from the deployment command.
# Here the Admin Server service name is admin-server which has a port 8001.
> kubectl get services
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
admin-server 10.102.160.123 <nodes> 8001:30007/TCP 11m
kubernetes 10.96.0.1 <none> 443/TCP 39d
wls-service 10.96.37.152 <nodes> 8011:30009/TCP 11m
wls-subdomain None <none> 8011/TCP 11m
# Execute the /bin/bash in the Admin Server pod
> kubectl exec -it admin-server-1238998015-f932w /bin/bash
# Once in the Admin Server pod, setup a WebLogic env, then run weblogic.Deployer
# to deploy the simpleApp.war located in the /shared/applications directory to
# the cluster "myCluster"
]$ cd /u01/wlsdomain/base_domain/bin
]$ . setDomainEnv.sh
]$ java weblogic.Deployer -adminurl t3://admin-server:8001 -user weblogic -password weblogic1 -name simpleApp -targets myCluster -deploy /shared/applications/simpleApp.war
以下のコマンドでWebLogicクラスタへのJava EEアプリケーションのデプロイメントが無事完了していることを確認します。
# Kubernetes routes the traffic to both managed-server-0 and managed-server-1 via the wls-service port 30009.
http://<hostIP>:30009/simpleApp/Scrabble.jsp
以下のコマンドは、weblogic.Deployerユーティリティを使ってアプリケーションをアンデプロイしています。デプロイメントと類似の手順であることにご注意ください。
# Execute the /bin/bash in the Admin Server pod
> kubectl exec -it admin-server-1238998015-f932w /bin/bash
# Undeploy the simpleApp
]$ cd /u01/wlsdomain/base_domain/bin
]$ . setDomainEnv.sh
]$ java weblogic.Deployer -adminurl t3://admin-server:8001 -user weblogic -password weblogic1 -undeploy -name simpleApp
Sample of Using REST APIs to Deploy and Undeploy a Java EE Application in Kubernetes
このサンプルでは、アプリケーションsimpleApp.warはすでにホストディレクトリ/host/appsにあります。このホストディレクトリは、admin-server-1238998015-f932wというPodのアプリケーションボリュームディレクトリ/shared/applicationsにマウントされます。
以下のサンプルでは、admin-server-1238998015-f932wというPodでcurlコマンドを実行しています。このcurlコマンドはNodePort 30007を使用してAdminstration ServerにRESTリクエストを送信し、WebLogicクラスタmyClusterにsimpleAppをデプロイします。
# deploy simpleApp.war file to the WebLogic cluster
> kubectl exec admin-server-1238998015-f932w -- curl -v --user weblogic:weblogic1 \
-H X-Requested-By:MyClient \
-H Content-Type:application/json \
-d "{ name: 'simpleApp', \
sourcePath: '/shared/applications/simpleApp.war', \
targets: [ { identity: [ 'clusters', 'myCluster' ] } ] }" \
-X POST http://<hostIP>:30007/management/weblogic/latest/edit/appDeployments
以下のコマンドはREST APIを使ってアプリケーションをアンデプロイします。
# undeploy simpleApp.war file from the WebLogic cluster
> kubectl exec admin-server-1238998015-f932w -- curl -v --user weblogic:weblogic1 \
-H X-Requested-By:MyClient \
-H Accept:application/json \
-X DELETE http://<hostIP>:30007/management/wls/latest/deployments/application/id/simpleApp
Best Practices for Deploying Java EE Applications in Kubernetes
- 個々のWebLogic Serverインスタンスではなく、WebLogicクラスタにJava EEアプリケーションまたはモジュールをデプロイする。これにより、デプロイメント戦略の変更をしなくて済むため、後のWebLogicクラスタのスケーリングが簡単になる。
- WebLogic Serverデプロイメントツールは、Kubernetes環境で使用可能。
- アプリケーション更新時は、前述の手順に従ってアプリケーションを配布しデプロイする。
- Dockerイメージで事前構築済みのWebLogic Serverドメインホームを使用する場合、アプリケーションをドメインへデプロイすると、ドメイン構成を自動的に更新する。ただし、この方法でアプリケーションをデプロイすると、Pod内のドメイン構成はDockerイメージのドメイン構成と同期しなくなる。この同期の問題は、必要なアプリケーションをDockerイメージの事前構築済みドメインホームに含めることで、可能な限り避けることが可能。この方法で、後の追加の展開手順を回避できる。
Integrating ReadyApp Framework in Kubernetes Readiness Probe
Kubernetesは、サービスデプロイメント方法の詳細からクライアントを隔離する上で、ロードバランサとフロントエンドを構成する柔軟なアプローチを提供します。このアプローチの一環として、Kubernetesは、コンテナがトラフィックを受け入れる準備ができたかどうかを判断するreadinessProbeを実行して対応します。
一方、WebLogic Serverでは、WebLogic Serverインスタンスの起動が完了し、クライアントリクエストを処理できる状態かどうかを報告するReadyAppフレームワークが利用できます。
ReadyAppフレームワークは、READYとNOT READYの2つの状態を使用します。READY状態は、WebLogic Serverインスタンスが実行中であることだけでなく、WebLogic Serverインスタンスにデプロイされているすべてのアプリケーションがリクエストを処理できる状態にあることを意味します。NOT READY状態の場合、WebLogic Serverインスタンスの起動は不完全で、トラフィックを受け入れることができません。
Kubernetes環境でWebLogic Serverコンテナを起動する場合は、KubernetesのreadinessProbeを使用してWebLogic ServerのReadyAppフレームワークにアクセスできます。ReadyAppフレームワークがWebLogic Serverコンテナ起動のREADY状態を報告すると、readinessProbeはWebLogic Serverコンテナがトラフィック受け入れ可能であることをKubernetesに通知します。
以下は、readinessProbeに統合されたReadyAppフレームワークを使用して、ポート8011上で実行されているWebLogic Serverコンテナがトラフィックを受け入れる準備ができているかどうかを判断する例です。
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
[...]
spec:
[...]
template:
[...]
spec:
containers:
[...]
readinessProbe:
failureThreshold: 3
httpGet:
path: /weblogic/ready
port: 8011
scheme: HTTP
[...]
WebLogic ServerのReadyAppフレームワークには、以下のURLからアクセスできます。
http://<hostIP>:<port>/weblogic/ready
WebLogic Serverが実行されている場合、このURLはステータス200（READY）または503 （NOT READY）を返します。WebLogic Serverが実行されていない場合は、エラー404ページが表示されます。
WebLogic Serverと同様に、他のKubernetesアプリケーションはReadyAppフレームワークに登録し、readinessProbeを使用してKubernetesアプリケーションでReadyAppフレームワークの状態をチェックできます。 ReadyAppフレームワークにアプリケーションを登録する方法については、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Deploying Applications to Oracle WebLogic Server
Using the ReadyApp Framework
https://docs.oracle.com/middleware/12213/wls/DEPGD/managing.htm#DEPGD-GUID-C98443B1-D368-4CA4-A7A4-97B86FFD3C28
Best Practices for Integrating ReadyApp Framework in Kubernetes Readiness Probe
ReadyAppフレームワークを使用してKubernetesアプリケーションを登録し、アプリケーションがサービスリクエストを受け入れ可能かどうかを判断するReadyAppフレームワークの状態をチェックするためにreadinessProbeを使うことをお奨めします。ReadyAppフレームワークの状態がREADY状態である場合にのみ、KubernetesはこれらのKubernetesアプリケーションにトラフィックをルーティングします。
Conclusion
WebLogic ServerをKubernetes環境とDocker環境に統合する場合、既存の強力なWebLogic Serverデプロイメントツールを使用して、Kubernetesで動作するWebLogic ServerインスタンスにJava EEアプリケーションをデプロイできますし、Kubernetesの機能を使用してWebLogic Serverを管理することもできます。Kubernetesの機能を使用してWebLogic Serverを管理することもできます。具体的には、ボリュームを使用して、Kubernetesクラスタ内のすべてのPodのすべてのコンテナでアプリケーションファイルを共有し、readinessProbeを使っておよびWebLogic Serverの起動状態を監視するといった具合です。この統合により、自社のビジネスプラクティスに適合する柔軟なデプロイメントシナリオをサポートできるだけでなく、WebLogic Serverをクラウド環境に素早いデプロイ、素早いオートスケール、シームレスな更新も可能です。
