[Docker, WLS] Best Practices for Application Deployment on WebLogic Server Running on Kubernetes

原文はこちら。
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

• このエントリ内で述べるアプリケーションは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アプリケーションのデプロイメントプロセスは複数のパートから構成されています。

1. 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

2. デプロイメントのための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

3. 新環境にデプロイするための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

4. 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

5. 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イメージに過剰な数のレイヤーを持たせるのはお勧めしません。

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

• ボリュームを使用してアプリケーションファイルを保存し、すべてのPodのコンテナに共有する。
• コンテナ内のディスク上のファイルは一時的（ephemeral）なので、Dockerイメージで事前構築済みのWebLogic Serverドメインホームを使用する場合、ボリュームを使用してドメインホームディレクトリをホスト上に格納する。事前構築されたWebLogic Serverドメインホームディレクトリを含むサンプルWebLogicドメインwls-k8s-domainは、GitHubから入手可能。
  

  WebLogic Sample on Kubernetes with Shared Domain Home
  https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain

• アプリケーションファイルは、ホスト上のドメインホームのボリュームディレクトリとは別の場所に格納する
• WebLogic Serverにデプロイ済みの既存のJava EE Webアプリケーション用に生成されたデプロイメントプランも、ボリュームに格納できる。デプロイメント・プランの使用方法の詳細は、以下のチュートリアルを参照。
  

  Oracle WebLogic Server 12c: Creating and Using a Deployment Plan
  http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/09-DeployPlan--4464/deployplan.htm

• デフォルトでは、WebLogic Server Pod内のすべてのプロセスは、ユーザID 1000およびグループID 1000で実行される。そのため、ユーザID 1000またはグループID 1000がアプリケーションボリュームディレクトリへの読み取りおよび書き込みアクセス権を持つように、アプリケーションボリュームディレクトリに対し、アクセス権が適切に設定されていることを確認する。

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をクラウド環境に素早いデプロイ、素早いオートスケール、シームレスな更新も可能です。