[misc.] Tech Deep Dive #1 の参加受付を開始しました

先日Tweetした通り、Tech Deep Dive #1の募集を開始しました。

今回は、「Javaアプリケーションのチューニング」をテーマに、Javaの言語仕様やアプリケーションの特性を踏まえた上で、オープンソース化(というよりは、OpenJDKに入る)予定のJava Flight Recorderを使って、
  • Webアプリケーションが稼働しているときのJavaスレッドの状態を見る
  • 実際のトラブルシューティング例を見る
を通じて、トラブルの原因やチューニングポイント、Java Flight Recorderの効果的な使い方をご紹介できればと考えています。前回( #0 )でデモ出来なかったあのWebアプリケーションのパフォーマンスもご紹介できる、かも。

# 前回と同様、ロジ子は前説をちょびっとやるだけです。

もし、作成されたアプリケーションが
  • なんか徐々に遅くなってるんだよなー。。
  • もっと性能が出るはずなんだけど、なんでだろう。。
と感じたり、そういう症状を見せていたりするのであれば、また、実際にこれから作ろうとしているアプリケーションで上記のような症状が出ないようにしたい、と思ってらっしゃるのであれば、一つの方法として頭の片隅に入れても損しない内容になると考えています。
2月20日(火)19時開始(開場は18時30分)です(#0 からちょうど2ヵ月後!)。みなさまの参加登録・ご来場をお待ちしています(参加登録者数が多い場合には、枠を広げる可能性もあります)。

[WLS, Docker] WebLogic Server Certification on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/weblogic-server-certification-on-kubernetes

KubernetesでのOracle WebLogic Serverの動作保証を発表できうれしく思っています。この動作保証の一環として、Kubernetes上で動作するOracle WebLogic Server 12.2.1.3ドメインイメージを作成するためのGitHubサンプルをリリースします。
WebLogic Sample on Kubernetes with Shared Domain Home
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain
また、WebLogic Serverの構成と機能のサポート、およびベストプラクティスについて詳しく説明する一連のブログを公開しています。
How to... WebLogic Server on Kubernetes
https://blogs.oracle.com/weblogicserver/how-to-weblogic-server-on-kubernetes
https://orablogs-jp.blogspot.jp/2018/01/how-to-weblogic-server-on-kubernetes.html
Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、および管理を自動化するためのオープンソースシステムで、Dockerを含むさまざまなコンテナツールをサポートしています。
What is Kubernetes?
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
Dockerコンテナで実行されるOracle WebLogic Serverの構成を、Kubernetesプラットフォーム上にデプロイしオーケストレーションできます。
下表は、KubernetesでWebLogic Serverの動作保証されている構成(Oracle WebLogic Server、JDK、Linux、Kubernetes、Docker、およびネットワークファブリックのバージョン)です。
WebLogic Server JDK Host OS Kubernetes Docker Network Fabric
12.2.1.3 8 Oracle Linux 7  UEK 4 1.7.5 and 1.8.0 17.03-ce Flannel  v0.9.1-amd64
Oracle WebLogic ServerのDockerでの動作保証の詳細は、My Oracle Supportの以下のサポート文書をご覧ください(サポート契約が必要です)。
Support Information for Oracle WebLogic Server Running in Docker Containers (Doc ID 2017945.1)
https://support.oracle.com/rs?type=doc&id=2017945.1
Flannel以外のネットワークファブリックを使用し、Oracle Linux以外のプラットフォームでKubernetesを構成して、その上でWebLogic Serverドメインを実行する場合のサポートについては、以下のサポート文書をご覧ください。
WebLogic Server 12.2.1.3 Certification on Kubernetes (Doc ID 2349228.1)
https://support.oracle.com/rs?type=doc&id=2349228.1
サポート対象の構成に関する最新情報は、以下のURLをご覧ください。
Supported Virtualization and Partitioning Technologies for Oracle Fusion Middleware
http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.html
この動作保証は、クラスタ化された、クラスタ化されていないに関わらず、Kubernetesクラスタ上で稼働するOracle WebLogic Serverドメイン構成(開発モードと本番モードの両方を含む)の作成が可能であることを示しています。この動作保証には、以下のサポートが含まれています。
  • Kubernetesクラスタ内での1個以上のWebLogicドメインの稼働
  • 1個以上のノードのKubernetesクラスタ
  • クラスタ、非クラスタ構成のWebLogic管理対象サーバー
  • (動的クラスタに対する)WebLogic Serverの構成済みクラスタ。詳細はドキュメントを参照
  • ユニキャストWebLogic Serverクラスタメッセージングプロトコル
  • Kubernetesクラスタ上のIngressコントローラとしてTræfikを使った、HTTPリクエストの負荷分散
  • HTTPセッションレプリケーション
  • 外部データベースシステムとのJDBC通信
  • JMS
  • JTA
  • 永続ボリュームを使うJDBCストアおよびファイルストア
  • ドメイン間通信(JMS、トランザクション、EJBなど)
  • WebLogicクラスタのオートスケーリング
  • WebLogic Monitoring Exporterを使いPrometheusと連携して監視
  • Kubernetesクラスタの内外からのRMI通信
  • アプリケーションのアップグレード
  • WebLogicドメインへのパッチ適用
  • シングルトンサービスのサービス移行
  • データベース・リース
以下の構成や機能は、WebLogic Server on Kubernetes上でのWebLogic Serverの動作保証の範囲外です(サポートされません)。
  • KubernetesクラスタにまたがるWebLogicドメイン
  • サーバー全体の移行
  • WebLogic Serverのライフサイクル管理(開始/停止)のためのノードマネージャの使用
  • コンセンサスリース
  • 動的クラスタ(将来動的クラスタの動作保証を追加する予定です)
  • マルチキャストWebLogic Serverクラスタメッセージングプロトコル
  • マルチテナント
  • プロダクション再デプロイメント
  • portmapを使うFlannel

Kubernetesを使ってWebLogic Serverドメインを作成、実行する方法を示すサンプルをGitHubに公開しました。サンプルのREADME.mdにすべての手順が示されています。
WebLogic Sample on Kubernetes with Shared Domain Home
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain
README.md
https://github.com/oracle/docker-images/blob/master/OracleWebLogic/samples/wls-k8s-domain/README.md
このサンプルは、Kubernetes上で稼働するsampleドメインとクラスタを作成し、動作保証されたOracle WebLogic Server 12.2.1.3のdeveloperインストールイメージを拡張します。WebLogicドメインは、管理サーバーと、WebLogicクラスタで実行されている複数の管理対象サーバーで構成されており、すべてのWebLogic Serverは、外部ボリュームにマップされている同じドメインホームを共有します。永続ボリュームには、すべてのWebLogic Serverインスタンスがドメインホーム内のファイルにアクセスできるように、read/writeの権限が必要です。以下のエントリに記載のベストプラクティスをチェックしてください。このエントリでは、通常共有ストレージを利用するように構成されるWebLogic Serverのサービスとファイルについて説明しながら、KubernetesがオーケストレーションするWebLogicドメインのための共有ストレージをマウントする、完全なEnd-to-Endのサンプルを提供しています。
WebLogic Server on Kubernetes Data Volume Usage
https://blogs.oracle.com/weblogicserver/weblogic-server-on-kubernetes-data-volume-usage
https://orablogs-jp.blogspot.jp/2018/01/weblogic-server-on-kubernetes-data.html
このドメインを稼働させた後、JMSおよびJDBCリソースをデプロイできます。以下のエントリでは、Kubernetesクラスタ内のサンプルWebLogic JMSアプリケーションを構成、実行するための手順を順を追って説明しています。WebLogic JMSおよびJDBCリソースのデプロイ方法、アプリケーションのデプロイ方法、およびアプリケーションの実行方法についても説明しています。
Run a WebLogic JMS Sample on Kubernetes
https://blogs.oracle.com/weblogicserver/run-a-weblogic-jms-sample-on-kubernetes
https://orablogs-jp.blogspot.jp/2017/12/run-weblogic-jms-sample-on-kubernetes.html
このアプリケーションは、WebLogic Serverのサンプルアプリケーションに含まれている 'Classic API - Using Distributed Destination' (分散送り先の使用)をベースにしており、従業員が到着時に自身の名前を送信し、スーパーバイザが従業員の到着時間を監視するというシナリオを実装したものです。従業員はチェックインメッセージを分散キューもしくは分散トピックへの送信を選択します。これらの宛先は2個のアクティブな管理対象サーバーを持つクラスタで構成されています。これらの2個の宛先に対応する2個のmessage-driven bean(MDB)がデプロイされ、チェックインメッセージを処理してデータベースにそのメッセージを格納します。スーパーバイザーは、データベースに照会してすべてのチェックインメッセージをスキャンできます。
後続のブログエントリ「Run Standalone WebLogic JMS Clients on Kubernetes」では、以前のブログエントリの内容から一歩進んで、WebLogic JMSサービスおよびJDBCストアを使い、相互に通信するスタンドアロンJMSクライアントの例を紹介しています。
Run Standalone WebLogic JMS Clients on Kubernetes
https://blogs.oracle.com/weblogicserver/run-standalone-weblogic-jms-clients-on-kubernetes
https://orablogs-jp.blogspot.jp/2018/01/run-standalone-weblogic-jms-clients-on.html 
WebLogic ServerとKubernetesとも、アプリケーションのデプロイをサポートする豊富な機能を備えています。Kubernetes上でのWebLogic Serverの動作保証作業の一環として、KubernetesおよびDocker環境で動作するWebLogic ServerインスタンスへのJava EEアプリケーションのデプロイのためのベストプラクティスを確認しました。ブログエントリ「The blog Best Practices for Application Deployment on WebLogic Server Running on Kubernetes」では、これらのベストプラクティスについて説明しています。
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
https://orablogs-jp.blogspot.jp/2018/01/best-practices-for-application.html 
このエントリには、以下のドキュメントで説明されている一般的な推奨事項と、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
Oracle® Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ 12c (12.2.1.2.0)
WebLogic Serverデプロイメントの理解
https://docs.oracle.com/cd/E84527_01/wls/DEPGD/understanding.htm#DEPGD114
ソフトウェアシステムの最適なパフォーマンスとセキュリティを提供する上で最も重要な作業の1つは、システムの可用性の崩壊を最小限に抑えながら、確実に最新のソフトウェアアップデートをインストール、テスト、ロールアウトすることです。Oracleは、Patch Set UpdateやOne-Offパッチなど、WebLogic Server用のさまざまなタイプのパッチを提供しています。インストールすべきパッチとそれらのインストール方法は、カスタムニーズと環境によって異なります。
Kubernetes、Docker、およびオンプレミス環境では、同じOPatchツールを使用してWebLogic Serverにパッチを適用しますが、Kubernetesでクラスタをオーケストレーションする場合、StatefulSetコントローラのupdate strategyオプションを利用して、更新済みのWebLogic Serverイメージからパッチをロールアウトできます。「Patching WebLogic Server in a Kubernetes Environment」で説明しています。
Patching WebLogic Server in a Kubernetes Environment
https://blogs.oracle.com/weblogicserver/patching-weblogic-server-in-a-kubernetes-environment
https://orablogs-jp.blogspot.jp/2018/01/patching-weblogic-server-in-kubernetes.html
もちろん、動作保証において非常に重要なのはセキュリティです。「Security Best Practices for WebLogic Server Running in Docker and Kubernetes」で説明しているように、WebLogic Serverの実行時のDockerおよびKubernetes環境を保護するためのベストプラクティスを確認しました。
Security Best Practices for WebLogic Server Running in Docker and Kubernetes
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes
https://orablogs-jp.blogspot.jp/2017/10/security-best-practices-for-weblogic.html 
これらのベストプラクティスは、以下のドキュメントで説明されている一般的なWebLogic Serverの推奨事項に加えて考慮すべきものです。
Oracle® Fusion Middleware Securing a Production Environment for Oracle WebLogic Server 12c (12.2.1.3.0)
https://docs.oracle.com/middleware/12213/wls/LOCKD/toc.htm
Oracle® Fusion Middleware Oracle WebLogic Server本番環境の保護 12c (12.2.1.2.0)
https://docs.oracle.com/cd/E84527_01/wls/LOCKD/toc.htm 
監視と診断の分野では、オープンソース向けにWebLogic Monitoring Exporterという新しいツールを開発しました。WebLogic Serverは、WebLogicドメインで実行されているサーバー、クラスタ、アプリケーションやその他のリソースの詳細なパフォーマンスおよび診断データを提供する豊富なメトリックとランタイムの状態情報を生成します。このツールは、Docker/Kubernetes環境での動作時にWebLogicの監視および診断機能を活用します。
「Announcing The New Open Source WebLogic Monitoring Exporter on GitHub」のブログエントリでは、GitHubプロジェクトのDockerfileとソースコードからWebLogic Monitoring Exporterをビルドする方法を紹介しています。
Announcing The New Open Source WebLogic Monitoring Exporter on GitHub
https://blogs.oracle.com/developers/the-new-weblogic-monitoring-exporterWebLogic Monitoring Exporter exposes metrics and monitoring data through REST APIs for consumption by other tools (e.g. Prometheus)
https://github.com/oracle/weblogic-monitoring-exporter
WebLogic Monitoring Exporterは、監視対象のWebLogicクラスタ内のWebLogic Server管理対象サーバーにデプロイされるWebアプリケーションとして実装されます。WebLogic Monitoring Exporterの設計と実装の詳細については、「Exporting Metrics from WebLogic Server」のエントリを参照してください。
Exporting Metrics from WebLogic Server
https://blogs.oracle.com/weblogicserver/exporting-metrics-from-weblogic-server
https://orablogs-jp.blogspot.jp/2017/11/exporting-metrics-from-weblogic-server.html
WebLogic Monitoring Exporterがクラスタ内の実行中の管理対象サーバにデプロイされ、メトリックと統計情報を収集すると、PrometheusとGrafanaを使いデータ収集、表示の準備が整います。「Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes」のエントリでは、Prometheusでメトリックを収集し、Grafanaダッシュボードに表示する手順を紹介しています。
Using Prometheus and Grafana to Monitor WebLogic Server on Kubernetes
https://blogs.oracle.com/weblogicserver/use-prometheus-and-grafana-to-monitor-weblogic-server-on-kubernetes
https://orablogs-jp.blogspot.jp/2017/12/using-prometheus-and-grafana-to-monitor.html
WebLogic ServerクラスタのElasticity(スケールアップまたはスケールダウン)により、お客様のアプリケーションの信頼性向上とリソース使用率の最適化が実現します。WebLogic診断フレームワーク(WLDF)が提供するリソースメトリックに基づいて、Podの数を増やす(または減らす)ことにより、WebLogic Serverクラスタを自動的に拡大/縮小できます。WebLogicクラスタがスケールアップ・スケールダウンすると、HTTPセッションレプリケーションやシングルトンサービスのサービス移行といったWebLogic Serverの機能を活用し、最大限の可用性を実現します。Kubernetesクラウド環境でのWebLogic Serverクラスタの自動スケーリングの例については、「Automatic Scaling of WebLogic Clusters on Kubernetes」を参照してください。
Automatic Scaling of WebLogic Clusters on Kubernetes
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2
https://orablogs-jp.blogspot.jp/2018/01/automatic-scaling-of-weblogic-clusters.html
WebLogic Serverチームは、KubernetesでWebLogic Serverの動作保証の作業だけでなく、近い将来にリリースされるWebLogic Server Kubernetes Operatorを開発しています。Kubernetes Operatorは、「Kubernetes APIを拡張して複雑なアプリケーションのインスタンスを作成、構成、管理するアプリケーション固有のコントローラ」です。 WebLogic Server Kubernetes Operatorのリリースについての情報は、しばしお待ちください。
KubernetesでのWebLogic Serverの動作保証には、このブログで説明しているさまざまなWebLogicの設定と機能がすべて含まれています。WebLogic ServerをKubernetesで実行すること、まもなくリリース予定のKubernetesベースのOracle Container EngineでWebLogic Serverを実行し、KubernetesベースのContainer Native Application Development PlatformとWebLogic Serverアプリケーションの統合を可能にすることを目的としています。この情報がKubernetes上でWebLogic Serverをデプロイしようとするお客様に役立つことを願っております。フィードバックをお待ちしております。

[Docker, WLS] How to... WebLogic Server on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/how-to-weblogic-server-on-kubernetes

WebLogic Serverチームは、KubernetesでオーケストレーションされるWebLogicドメインの動作保証に取り組んでいます。この作業の一環として、ユーザーからもらう可能性のある質問に対する回答のための一連のブログエントリを公開します。これらは、KubernetesでWebLogic Serverを実行するためのベストプラクティスについて説明しています。これらのエントリでは、セキュリティのベストプラクティス、監視、ログ、メッセージング、トランザクション、クラスタのスケーリング、ボリュームの状態の外部化、パッチ適用、アプリケーションの更新などのトピックを扱います。最初のエントリでは、GitHubのサンプルを使ってすぐに試すことができます。みなさまがフォローしやすいように、このブログエントリのリストを更新し続けていきますので、ご期待ください。

[Java] Updates for Java SE Platform

原文はこちら。
https://blogs.oracle.com/java/java-se-8-9

Java SE 9.0.4はJava Platformの最新のアップデートです。このリリースは発表済みのCritical Patch Update(以下CPU)の一部であり、重要なバグ修正が含まれています。このリリースのJRE(version 9.0.4)は次回のCPUリリースで有効期限が切れますので、Java 8をお使いのすべての方がこのリリースにアップデートされることをOracleは強く推奨します。
Release Notes for JDK 9 and JDK 9 Update Releases
http://www.oracle.com/technetwork/java/javase/9all-relnotes-3704433.html
Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Critical Patch Updates, Security Alerts and Bulletins
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
Java CPU and PSU Releases Explained
http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html
[訳注]
リリースノートにあるとおり、2018/1のCPUでは2種類のJDK 9バンドルがリリースされています。
  • Oracle JDK 9.0.4 :商用機能(deploy、installerなど)を含む
  • OpenJDK 9.0.4:OpenJDKソースコードからビルドしたもの
リリースノートは両方のバンドルを対象にしていますが、いずれかのバンドル固有の内容の場合、タイトルにOpenJDKもしくはOracle JDKが明示されています。明示されていない場合には両バンドルともに関係する内容です。
このリリースはJDK 9の最終リリースの予定ですので、2018年3月から次回のCPUリリース(2018年4月)までの間にJDK 10にアップデートされることを推奨します。

Java SE 8u161/162 (Java SE 8 update 161 および Java SE 8 update 162) がご利用いただけるようになりました。
Java SE Development Kit 8 Downloads
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html 
Java SE 8u162はPSU(Patch Set Update)で、8u161を包含し、さらに追加機能を含んでいます。Java SEをご利用のほとんどの方が、重要なセキュリティ修正を含む最新のJava 8アップデートにアップグレードされることをOracleは強く推奨します。このリリースに含まれる新機能やバグ修正の情報は、以下のリリースノートをご覧ください。
JDK 8u161 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u161-relnotes-4021379.html
JDK 8u162 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u162-relnotes-4021436.html
Oracle Java SE Embedded Version 8 Update 161もご利用いただけるようになりました。
Oracle Java SE Embedded Downloads
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/index.html
JRECreateツールを使いカスタマイズしたJREを作成できます。始めるには、対象とするプラットフォームに適したeJDKバンドルをダウンロードし、アプリケーションのニーズにあうJREを以下の手順に従って作成します。
Java Platform, Standard Edition (Java SE) 8 - Oracle Java SE Embedded: Developer's Guide
Create Your JRE with jrecreate
http://docs.oracle.com/javase/8/embedded/develop-apps-platforms/jrecreate.htm#JEMAG270
Oracle Java SE 8 EmbeddedはOracle Java SE Embedded製品の最終メジャーリリースです。JDK 9からは、Oracleは個別のJava SE Embedded製品のダウンロードを提供する予定はありません。
Java SE 7u171、Java SE 6u181もリリースされましたが、いずれもOracle Java SE Supportの契約が必要です。
Java SE 7 Advanced and Java SE 7 Support (formerly known as Java for Business 7) Release Notes
Java™ SE Development Kit 7, Update 161 (JDK 7u171)
http://www.oracle.com/technetwork/java/javaseproducts/documentation/javase7supportreleasenotes-1601161.html#R170_171
Java SE 6 Advanced and Java SE 6 Support (formerly known as Java SE for Business 6) Release Notes
Java™ SE Development Kit 6, Update 171 (JDK 6u181)
http://www.oracle.com/technetwork/java/javase/overview-156328.html#R160_181

Related Blogs

Java 9 Release Now Available!
https://blogs.oracle.com/java/java-9-release-now-available
https://orablogs-jp.blogspot.jp/2017/09/java-9-release-now-available.html
Java Magazine Issue: More Java 9
https://blogs.oracle.com/java/java-magazine-more-java-9
https://orablogs-jp.blogspot.jp/2017/09/new-java-magazine-issue-more-java-9.html
Java Magazine Issue: Inside Java 9
https://blogs.oracle.com/java/java-magazine-inside-java-9
https://orablogs-jp.blogspot.jp/2017/07/new-java-magazine-issue-inside-java-9.html

[WLS, Docker] Run Standalone WebLogic JMS Clients on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/run-standalone-weblogic-jms-clients-on-kubernetes

Overview

JMSアプリケーションは、JMSサービスを使用してメッセージを送受信するアプリケーションです。WebLogic JMSアプリケーションには、サーバーサイドのJMSアプリケーションとスタンドアロンのJMSクライアントの2種類があります。サーバーサイドアプリケーションは、WebLogic Serverまたはクラスタ上で実行されているアプリケーションで、通常はMDB、サーブレットなどのJava EEアプリケーションです。スタンドアロンJMSクライアントは、外部EEサーバー、デスクトップアプリケーション、またはマイクロサービスで実行されるアプリケーションです。直近のエントリ「Run a WebLogic JMS Sample on Kubernetes」で、Kubernetes上で稼働するJava EEアプリケーション間でWebLogic JMS通信の説明をいたしました。
Run a WebLogic JMS Sample on Kubernetes
https://blogs.oracle.com/weblogicserver/run-a-weblogic-jms-sample-on-kubernetes
https://orablogs-jp.blogspot.jp/2017/12/run-weblogic-jms-sample-on-kubernetes.html
その際、JMSストアとしてファイルストアを使用しました。このエントリでは、前回のエントリから一歩進めて、WebLogic JMSサービスを使用して相互に通信するスタンドアロンJMSクライアントを説明します。今回はJMSストアとしてJDBCストアを使用します。
最初に、GitHubにあるサンプルWebLogicドメインをベースにして、管理サーバー、およびWebLogicクラスタをもつWebLogicドメインを作成します。
WebLogic Sample on Kubernetes with Shared Domain Home
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain
次に、データソース、JDBCストア、およびJMSリソースをKubernetesクラスタ上のWebLogicドメインにデプロイします。WebLogic JMSサービスの準備ができて稼働した後、WebLogic JMS宛先との間でメッセージを送受信するために、同じKubernetesクラスタにJavaマイクロサービスを作成してデプロイします。

REST APIを使用して、管理サーバーPodに対してスクリプトを実行して、クラスタをターゲットとするリソースをデプロイします。

Creating WebLogic JMS Services on Kubernetes

Preparing the WebLogic Base Domain and Data Source

「Run a WebLogic JMS Sample on Kubernetes」のエントリの説明に従って、ドメインの作成、MySQLデータベースの設定、データソースの作成という手順を完了していれば、次のセクションに進むことができます。それ以外の場合は、「Run a WebLogic JMS Sample on Kubernetes」のエントリの以下のセクションの手順を完了する必要があります。
Run a WebLogic JMS Sample on Kubernetes
https://blogs.oracle.com/weblogicserver/run-a-weblogic-jms-sample-on-kuberneteshttps://orablogs-jp.blogspot.jp/2017/12/run-weblogic-jms-sample-on-kubernetes.html
  1. "Creating the WebLogic Base Domain"
  2. "Setting Up and Running MySQL Server in Kubernetes"
  3. "Creating a Data Source for the WebLogic Server Domain"
今回は、Kubernetesクラスタ上で実行されるbaseというWebLogicドメインと、同じKubernetesクラスタ内で実行されるMySQLデータベースに接続するデータソースを設定しておく必要があります。

Deploying the JMS Resources with a JDBC Store

まず、1つのデータベースストア、1つのJMSサーバー、および1つのJMSモジュールの定義を含むJSONデータファイルを準備します。ファイルはPythonスクリプトで処理され、WebLogic Server REST APIを使ってリソースを1つずつ作成します。
File jms2.json:
{"resources": {  
  "jdbc1": {
    "url": "JDBCStores",
    "data": {
      "name": "jdbcStore1",
      "dataSource": [
        "JDBCSystemResources",
        "ds1"
      ],
      "targets": [{
                 "identity":["clusters", "myCluster"]
                }]
    }
  },
 
  "jms2": {
    "url": "JMSServers",
    "data": {
      "messagesThresholdHigh": -1,
      "targets": [{
                   "identity":["clusters", "myCluster"]
                  }],
      "persistentStore": [
         "JDBCStores",
         "jdbcStore1"
        ],
      "name": "jmsserver2"
    }
  },
 
  "module": {
    "url": "JMSSystemResources",
    "data": {
      "name": "module2",
      "targets":[{
                  "identity": [ "clusters", "myCluster" ]
                }]
    }
  },
 
  "sub2": {
    "url": "JMSSystemResources/module2/subDeployments",
    "data": {
      "name": "sub2",
      "targets":[{
                  "identity": [ "JMSServers", "jmsserver2" ]
                }]
    }
  }
}}
続いて、JMSモジュールファイルを準備します。これには接続ファクトリ、分散キュー、分散トピックが含まれています。
File module2-jms.xml:
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-jms http://xmlns.oracle.com/weblogic/weblogic-jms/1.1/weblogic-jms.xsd">
  <connection-factory name="cf2">
    <default-targeting-enabled>true</default-targeting-enabled>
    <jndi-name>cf2</jndi-name>
    <transaction-params>
      <xa-connection-factory-enabled>true</xa-connection-factory-enabled>
    </transaction-params>
    <load-balancing-params>
      <load-balancing-enabled>true</load-balancing-enabled>
      <server-affinity-enabled>false</server-affinity-enabled>
    </load-balancing-params>
  </connection-factory>
  <uniform-distributed-queue name="dq2">
    <sub-deployment-name>sub2</sub-deployment-name>
    <jndi-name>dq2</jndi-name>
  </uniform-distributed-queue>
  <uniform-distributed-topic name="dt2">
    <sub-deployment-name>sub2</sub-deployment-name>
    <jndi-name>dt2</jndi-name>
    <forwarding-policy>Partitioned</forwarding-policy>
  </uniform-distributed-topic>
</weblogic-jms>
これらの2ファイルを管理サーバーのPodにコピーしてから、管理サーバーPodでPythonスクリプトを実行し、すべてのJMSリソースを作成します。
$ kubectl exec $adminPod -- mkdir /u01/wlsdomain/config/jms/
$ kubectl cp ./module2-jms.xml $adminPod:/u01/wlsdomain/config/jms/
$ kubectl cp ./jms2.json $adminPod:/u01/oracle/
$ kubectl exec $adminPod -- python /u01/oracle/run.py createRes /u01/oracle/jms2.json
WebLogic Server管理コンソール(http://<hostIP>:30007/console)を開き、すべてのJMSリソースが正常に動作していることを確認します。宛先 dq2 の監視ページに移動して、2個のメンバー(jmsserver2@managed-server-0@dq2 と jmsserver2@managed-server-1@dq2)の存在を確認します。



これでWebLogic JMSサービスの準備は完了です。このサービスに送信されたJMSメッセージはMySQLデータベースに格納されます。

Running the WebLogic JMS Client

JMSクライアントPodは、WebLogicクライアントJARファイルとともにパッケージされたopenjdk8イメージに基づくJavaマイクロサービスです。クライアント関連のスクリプト(Dockerfile、JMSクライアントJavaファイル、およびyamlファイルを含む)はGitHubにあります。
JMS Client関連のスクリプト
https://github.com/lilyhe123/jms-client/
(注意)インストール済みのWebLogicディレクトリ($WL_HOME/server/lib)からwlthint3client.jarを取得し、jms-client/container-scripts/lib</>フォルダに入れる必要があります。

(Step 1)JMSクライアントのDockerイメージをビルドします。イメージには、直接実行可能なコンパイル済みのJMSクライアントクラスが含まれます。

$ cd jms-client
$ docker build -t jms-client .
(Step 2)JMSクライアントPodを作成します。
$ kubectl create -f jmsclient.yml
Javaプログラムを実行してWebLogic JMSの宛先からメッセージを送受信します。$clientPodwith を実際のJMSクライアントPod名に置き換えてください。

送信プログラムを実行して宛先dq2にメッセージを送信します。
$ kubectl exec -it $clientPod java samples.JMSSender


デフォルトで、送信側は実行毎に10個のメッセージを送信します。これらのメッセージは宛先dq2の2個のメンバーに分配されます。管理コンソールで確認してみましょう。

受信プログラムを実行して宛先dq2からメッセージを受け取ります。
$ kubectl exec -it $clientPod java samples.JMSReceiver dq2
受信プログラムは、WebLogicのJMSDestinationAvailabilityHelper APIを使用して分散キューのメンバーシップの変化に関する通知を取得します。それゆえ、受信プログラムはdq2の両方のメンバーからメッセージを受信できます。詳細な使用方法については、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Oracle WebLogic Server JMSアプリケーションの開発 12c (12.2.1.2.0)
JMS宛先の可用性ヘルパーAPIを使用した分散宛先に関する拡張プログラミング
https://docs.oracle.com/cd/E84527_01/wls/JMSPG/dahelper.htm#GUID-516D21A5-EEE5-4397-806F-DB9DB28AD1E8
Oracle® Fusion Middleware Developing JMS Applications for Oracle WebLogic Server 12c (12.2.1.3.0)
Advanced Programming with Distributed Destinations Using the JMS Destination Availability Helper API
https://docs.oracle.com/middleware/12213/wls/JMSPG/dahelper.htm#JMSPG928

Summary

このエントリでは、「Run a WebLogic Sample on Kubernetes」のサンプルを拡張して、外部JMSクライアントを使った、Kubernetesクラスタで動作しているWebLogic JMSサービスとの通信を説明しました。
Run a WebLogic JMS Sample on Kubernetes
https://blogs.oracle.com/weblogicserver/run-a-weblogic-jms-sample-on-kubernetes
https://orablogs-jp.blogspot.jp/2017/12/run-weblogic-jms-sample-on-kubernetes.html
基本的なKubernetesの機能を利用してWebLogic Serverのライフサイクルを管理し、データベースベースのメッセージ永続性(JDBCストア)を使用して、Podのライフサイクルを超えてデータを保持しました。今後、将来予定されている完全に動作保証されたWebLogic KubernetesのオペレータベースのKubernetes環境を使用して、WebLogic JMSクラスタをホストする方法を紹介する予定です。また、WebLogic JMSの自動サービス移行を使用して、JMSインスタンスをシャットダウンされたPodから実行中のPodに移行する方法についても紹介する予定です。

[Docker, WLS] Automatic Scaling of WebLogic Clusters on Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/automatic-scaling-of-weblogic-clusters-on-kubernetes-v2

WebLogic ServerクラスタのElasticity(拡張度、スケールアップまたはスケールダウン)により、お客様のアプリケーションの信頼性向上とリソース使用率の最適化を実現します。ElasticityはWebLogic Server 12.2.1で導入され、Elasticサービスフレームワークと動的クラスタの概念を基に作られました。
Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.2.1.2.0)
動的クラスタ
https://docs.oracle.com/cd/E84527_01/wls/CLUST/dynamic_clusters.htm
Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1.3.0)
Dynamic Clusters
http://docs.oracle.com/middleware/12213/wls/CLUST/dynamic_clusters.htm#CLUST678
[訳注]
日本語ドキュメントでは、拡張度や拡張度フレームワークという表現を使っていますが、耳なじみがないと思いますので、このエントリでは英語のまま、つまりElasticityやElasticをそのまま使います。

Elasticity in WebLogic ServerにおけるElasticityは以下のいずれかによって達成されます。
  • WebLogic Server管理コンソールまたはWebLogic Scripting Tool(WLST)を使用して動的なWebLogic Serverクラスタ内の実行中のサーバインスタンスを手動で追加または削除(オンデマンドスケーリング)
  • 動的クラスタを拡大または縮小する条件を設定するWLDFスケーリングポリシーや、スケーリング処理自体を定義するアクションを設定する。スケーリングポリシーで定義された条件が発生すると、対応するスケーリング動作が自動的にトリガされる。
スケーリングアクションが発生すると、WebLogic Serverノードマネージャを使用して管理対象サーバーインスタンスを起動および停止します。ノードマネージャは、管理対象サーバーインスタンスのライフサイクル(起動、シャットダウン、再起動)を管理するWebLogic Serverユーティリティです。
WebLogic Serverチームは、Kubernetesクラウド環境でのWebLogic Serverの稼働に投資しています。WebLogic診断フレームワーク(WLDF)が提供するリソースメトリックに基づき、Podの数を増やす(または減らす)ことで、WebLogic Serverクラスタを自動的に拡大/縮小できます。以下のエントリのサンプルデモを使い、Kubernetesクラウド環境でのWebLogic Serverクラスタの自動スケールを説明します。
WebLogic on Kubernetes, Try It!
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes,-try-it
https://orablogs-jp.blogspot.jp/2017/10/weblogic-on-kubernetes-try-it.html
従来のWebLogic Serverデプロイメント環境と比較して、Kubernetesクラウド環境のサンプルデモにおけるelasticityの効果には、いくつかの重要な違いがあります。
  1. サンプルデモでは、静的に構成されたクラスタを使用しますが、elasticityは従来のデプロイメントでは動的クラスタと連動します。今後のエントリでは、Kubernetesクラウド環境におけるWebLogic Serverクラスタのelasticityについて説明します。
  2. サンプルデモでは、スケーリングアクションによってKubernetes APIサーバーへのリクエストが呼び出され、Podをスケールしますが、従来のデプロイメントではNode Managerへのリクエストを呼び出します。
このブログエントリでは、WLDFが提供するメトリックに基づいて、Kubernetes環境でWebLogic Serverクラスタを自動的に拡大または縮小する方法を説明します。

WebLogic on Kubernetes Sample Demo

以下では、「WebLogic on Kubernetes, Try It!」のエントリで説明したKubernetes上で稼働するWebLogicドメインを使います。
WebLogic on Kubernetes, Try It!
https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes,-try-it
https://orablogs-jp.blogspot.jp/2017/10/weblogic-on-kubernetes-try-it.html

Kubernetesクラスタで実行されているWebLogicドメインは、以下のもので構成されています。
  1. 独自のポッド(Pod 1)内のDockerコンテナで実行されている管理サーバー(AS)インスタンス。
  2. 管理サーバー(Pod 1)と同じPodにある独自のDockerコンテナで実行されるwebhookの実装。
    Webhookとは、軽量なHTTPサーバーで、複数のエンドポイント(フック)を使ってシェルスクリプトなどの設定済みコマンドを実行可能です。サンプルデモで使用しているwebhookの詳細については、以下のURLを参照してください。
    webhook is a lightweight configurable incoming webhook server which can execute shell commands
    https://github.com/adnanh/webhook/
    (注意)「WebLogic on Kubernetes, Try It!」にあるように、WLDFをトリガーとするスケールを実行するための前提条件として、Webhook Dockerイメージ(oow-demo-webhook)のビルドおよびインストールが必要です。
  3. 一連の管理対象サーバーインスタンスで構成されているWebLogic Serverクラスタ。各インスタンスはDockerコンテナ内で動作し、それぞれ個別のPodにある(Pod 2からPod 6)。

WebLogic Diagnostic Framework

WebLogic Diagnostics Framework(WebLogic診断フレームワーク、WLDF)は、サーバとアプリケーションのパフォーマンスを可視化するメトリックを収集し浮かび上がらせるサービスとAPIの集合です。動的クラスタの自動スケーリングをサポートするため、WLDFにはポリシー(Policy)とアクション(Action)というコンポーネントが用意されています。このコンポーネントを使用すると、動的クラスタで自動的にスケーリング操作を実行するポリシー式を記述できます。これらのポリシーは、メモリ、アイドルスレッド、CPU負荷など、1つ以上の種類のWebLogic Serverメトリックを監視します。ポリシー内に設定したしきい値を満たすと、ポリシーが呼び出され、対応するスケーリングアクションを実行します。WLDFと診断ポリシーとアクションの詳細については、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用 12c (12.2.1.2.0)
ポリシーとアクションの構成
https://docs.oracle.com/cd/E84527_01/wls/WLDFC/config_watch_notif.htm#WLDFC188
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1.3.0)
Configuring Policies and Actions
https://docs.oracle.com/middleware/12213/wls/WLDFC/config_watch_notif.htm#WLDFC188
ポリシーは、以下のデータに基づいています。
  • 特定の時間間隔中の平均値の変化のような、時間経過に伴う傾向または履歴データ。例えば、特定のしきい値を超える平均JVMヒープ使用量に基づきポリシーを設定できる。
  • 1つのサーバーインスタンスだけでなく、クラスタ内のすべてのサーバーインスタンスに関連する実行時メトリック
  • 一緒に考慮すべき複数のサービスからのデータ。例えばロードバランサが報告する応答時間メトリックとメッセージキューからのメッセージバックログメトリックに基づいたポリシーを設定できる。
  • カレンダーベースのスケジュール。ポリシーは、スケーリングアクションを実行する必要がある時間帯や曜日などの特定のカレンダー時刻を識別できる。
  • ログルールまたはイベントデータルール。

    Automatic Scaling of a WebLogic Server Cluster in Kubernetes

    WLDFを使用してKubernetes環境でWebLogic Serverクラスタの自動スケーリングを実現する方法を紹介しますが、ここでは自動スケーリングに関連する設定変更についてのみ説明します。サンプルデモの設定と実行の手順については、「WebLogic on Kubernetes, Try It!」のエントリをご覧ください。
    まず、KubernetesでのWebLogic Serverクラスタの自動スケーリングの動作を簡単に説明します。
    サンプルデモでは、WebLogic ServerクラスタをKubernetesクラスタで実行し、WebLogic Server管理対象サーバーインスタンスはKubernetes Podに1対1でマッピングされています。PodはStatefulSetコントローラが管理しています。ReplicaSetsとDeploymentsと同様、StatefulSetは、レプリケーションコントローラの一種で、目的のレプリカ・カウント・フィールド(replica count field)を増減するだけで拡張できます。ポリシーとスケーリングアクションは、WebLogic Serverクラスタ用に構成されています。WebLogic Serverクラスタの稼働中、WLDFはWebAppComponentRuntimeMBeanのOpenSessionsCurrentCount属性など、さまざまな実行時メトリックを収集して監視します。ポリシーで定義された条件が発生すると、ポリシーが呼び出され、対応するスケーリングアクションが実行されます。 Kubernetes環境で実行されているWebLogic Serverクラスタの場合、スケーリング処理では、目的のレプリカカウントフィールドを設定して、対応するStatefulSetをスケーリングします。これにより、StatefulSetコントローラは、必要なレプリカ数に一致するように、ポッドの数(WebLogic Server管理対象サーバインスタンス)を増減させます。
    StatefulSetは管理対象サーバーインスタンスが稼働しているPodを管理しているため、kubectlなどのツールを使用して、以下のようにWebLogic Serverクラスタをオンデマンドでスケーリングすることもできます。
    $ kubectl scale statefulset ms --replicas=3

    WLDF Policies and Actions

    WLDFのポリシーとアクションコンポーネントの設定については、以下のドキュメントを参照してください。
    Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用
    12c (12.2.1.2.0)
    ポリシーとアクションの構成
    https://docs.oracle.com/cd/E84527_01/wls/WLDFC/config_watch_notif.htm#WLDFC188
    Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1.3.0)
    Configuring Policies and Actions
    https://docs.oracle.com/middleware/12213/wls/WLDFC/config_watch_notif.htm#WLDFC188
    このサンプルでは、ポリシーとアクションをWLDF診断システムモジュール内で構成します。対応するリソース記述子ファイル(Module-0-3905.xml)は以下の通りです。
    <?xml version='1.0' encoding='UTF-8'?>
    <wldf-resource  xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"  xmlns:sec="http://xmlns.oracle.com/weblogic/security"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls"  xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics   http://xmlns.oracle.com/weblogic/weblogic-diagnostics/2.0/weblogic-diagnostics.xsd">
      <name>Module-0</name>
      <watch-notification>
        <watch>
          <name>myScaleUpPolicy</name>
          <enabled>true</enabled>
          <rule-type>Harvester</rule-type>
          <rule-expression>wls:ClusterGenericMetricRule("DockerCluster",
    "com.bea:Type=WebAppComponentRuntime,ApplicationRuntime=OpenSessionApp,*",
    "OpenSessionsCurrentCount","&gt;=",0.01,5,"1 seconds","10 seconds")
          </rule-expression>
          <expression-language>EL</expression-language>
          <alarm-type>AutomaticReset</alarm-type>
          <schedule>
            <minute>*</minute>
            <second>*/15</second>
          </schedule>
          <alarm-reset-period>60000</alarm-reset-period>
          <notification>RestScaleUpAction</notification>
        </watch>
        <rest-notification>
          <name>RestScaleUpAction</name>
          <enabled>true</enabled>
          <timeout>0</timeout>
          <endpoint-url>http://${OPERATOR_ENDPOINT}/hooks/scale-up</endpoint-url>
          <rest-invocation-method-type>PUT</rest-invocation-method-type>
          <accepted-response-type>application/json</accepted-response-type>
          <http-authentication-mode>None</http-authentication-mode>
          <custom-notification-properties></custom-notification-properties>
        </rest-notification>
      </watch-notification>
    </wldf-resource> 
    ポリシーとアクションを定義するための基本要素は<watch-notification>です。ポリシーは<watch>要素で定義します。アクションは、アクションタイプに対応する名前の要素で定義します。 例えば、RESTアクションの要素は<rest-notification>です。

    前述のリソース記述子ファイルで指定されているポリシーとアクションに関する主要な構成の詳細を説明します。利用可能なすべてのアクションタイプの詳細については、以下のドキュメントを参照してください。
    Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用
    12c (12.2.1.2.0)
    ポリシーとアクションの構成
    https://docs.oracle.com/cd/E84527_01/wls/WLDFC/config_notifications.htm#WLDFC204
    Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1.3.0)
    Configuring Actions
    https://docs.oracle.com/middleware/12213/wls/WLDFC/config_notifications.htm#WLDFC204 

    Policies:

    サンプルデモには、myScaleUpPolicyという名前のポリシーが含まれています。このポリシーには、以下のようなポリシー式があり、WebLogic Server管理コンソールで確認できます。

    myScaleUpPolicyのポリシー式では、ClusterGenericMetricRuleというスマートルールを使っています。このスマートルールの設定は以下のようです。
    DockerClusterクラスタでは、WLDFがOpenSessionAppアプリケーションのためにWebAppComponentRuntimeMBeanのOpenSessionsCurrentCount属性を監視します。OpenSessionsCurrentCountがクラスタ内の管理対象サーバインスタンスの5%で0.01%以上に達する場合、ポリシーをtrueと評価します。サンプリングレートを1秒としてメトリックを収集し、サンプルデータは保存ウィンドウの時間の指定された10秒間で平均化されます
    スマートルールに関する詳細は、以下のドキュメントをご覧ください。
    Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用
    12c (12.2.1.2.0)
    スマート・ルールのリファレンス
    https://docs.oracle.com/cd/E84527_01/wls/WLDFC/appendix_smartrules.htm
    Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1.3.0)
    Smart Rule Reference
    https://docs.oracle.com/middleware/12213/wls/WLDFC/appendix_smartrules.htm

    Actions:

    アクションは、ポリシー式がtrueと評価されたときに実行される操作です。従来のWebLogic Serverデプロイメントでは、スケーリングアクション(スケールアップおよびスケールダウン)は、動的クラスタをスケーリングするためのポリシーに関連付けられています。Elasticアクションは、ノードマネージャと対話することで、動的クラスタ内の管理対象サーバーインスタンスを拡張します。

    WLDFではその他の種類の診断アクションも数多くサポートしています。
    • Java Management Extensions (JMX)
    • Java Message Service (JMS)
    • Simple Network Management Protocol (SNMP)
    • Simple Mail Transfer Protocol (SMTP)
    • 診断イメージのキャプチャ
    • REST
    • WebLogicロギングシステム
    • WebLogic Scripting Tool (WLST)
    • ヒープダンプ
    • スレッドダンプ
    サンプルでは、RESTアクションを使用して、RESTエンドポイントを呼び出してスケーリング操作を開始する様子を示しています。Kubernetes環境ではノードマネージャを実行しておらず、Kubernetes APIとAPIサーバーを使用してPodをスケーリングしているため、ElasticアクションではなくRESTアクションを選択しました。WLDFでサポートされるすべての診断アクションの詳細については、以下のドキュメントを参照してください。
    Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用
    12c (12.2.1.2.0)
    アクションの構成
    https://docs.oracle.com/cd/E84527_01/wls/WLDFC/config_notifications.htmOracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1.3.0)
    Configuring Actions
    http://docs.oracle.com/middleware/12213/wls/WLDFC/config_notifications.htm
    • ポリシーmyScaleUpPolicyに関連付けられたRESTアクションは、WebLogic Server管理コンソールのポリシー設定ページの[アクション]タブで設定されました。

    • アクションを送信するRESTエンドポイントURLは診断システムモジュールのリソース記述子ファイルの<endpoint-url>要素によって設定します。
    RESTアクションの構成要素を見ると、REST呼び出しでは認証無しでエンドポイントに空のPUTリクエストを送信することがわかります。必要に応じて、<http-authentication-mode>属性をBasicに設定するだけで基本認証付きRESTリクエストを送信することもできます。

    注目すべきその他のWLDFリソース記述子の構成設定は以下のとおりです。
    1. WLDFリソース記述子のファイル名は任意です。サンプルデモでは、WebLogic Server管理コンソールを使用してWLDFポリシーとRESTアクションを構成する際にModule-0-3905.xmlが生成されました。
    2. WebLogicドメインdemoでは、container-scripts/add- app-to-domain.pyスクリプトを使用してWLDF診断システムモジュールを作成しました。
    # Configure WLDF
    # ============-=
    as_name = sys.argv[3]
    
    print('Configuring WLDF system resource');
    cd('/')
    
    create('Module-0','WLDFSystemResource')
    cd('/WLDFSystemResources/Module-0')
    set('DescriptorFileName', 'diagnostics/Module-0-3905.xml')
    
    cd('/')
    assign('WLDFSystemResource', 'Module-0', 'Target', as_name)
    
    スクリプトから以下のことがわかります。
    • Module-0という名前のWLDF診断システムモジュールが作成されます。
    • WLDFリソース記述子ファイル(Module-0-3905.xml)は、Module-0に関連付けられています。
    • 診断システムモジュールは、システム引数として渡されるas_nameで指定された管理サーバーをターゲットにしています。この診断システムモジュールは、そのポリシーにClusterGenericMetricRuleスマートルールが含まれているため、管理サーバーをターゲットとしていました。このルールは、クラスタ全体から見える必要があるため、管理サーバーから実行する必要があります。 スマートルールとそのターゲットの詳細については、以下のドキュメントを参照してください。
    Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用
    12c (12.2.1.2.0)
    スマート・ルールのリファレンス
    https://docs.oracle.com/cd/E84527_01/wls/WLDFC/appendix_smartrules.htm
    Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1.3.0)
    Smart Rule Reference
    https://docs.oracle.com/middleware/12213/wls/WLDFC/appendix_smartrules.htm

    Demo Webhook

    サンプルデモでは、webhookを使用してWLDFからREST通知を受信し、StatefulSetを拡張して、WebLogic Serverクラスタを拡張します。以下のフックはwebhooks/hooks.jsonで定義されています。
    [
      {
        "id": "scale-up",
        "execute-command": "/var/scripts/scaleUpAction.sh",
        "command-working-directory": "/var/scripts",
        "response-message": "scale-up call ok\n"
      }
    ] 
    scale-upと命名されたこのフックは、REST通知で指定された<endpoint-url>に対応します。
    <endpoint-url>http://${OPERATOR_ENDPOINT}/hooks/scale-up</endpoint-url> 
    エンドポイントURLに環境変数 ${OPERATOR_ENDPOINT} が含まれていることに注意してください。この環境変数は、管理サーバー起動時にWebHookの正しいホストとポートに置き換えられます。
    Webフックのエンドポイントが呼び出されると、 "execute-command"プロパティで指定されたコマンドが実行されます。今回の場合、シェルスクリプト /var/scripts/scaleUpAction.shが呼び出されます。
    #!/bin/sh
    echo "called" >> scaleUpAction.log
    num_ms=`curl -v  --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H  "Authorization: Bearer $(cat  /var/run/secrets/kubernetes.io/serviceaccount/token)" -X GET https://kubernetes/apis/apps/v1beta1/namespaces/default/statefulsets/${MS_STATEFULSET_NAME}/status  | grep -m 1 replicas| sed 's/.*\://; s/,.*$//'`
    echo "current number of servers is $num_ms" >> scaleUpAction.log
    new_ms=$(($num_ms + 1))
    echo "new_ms is $new_ms" >> scaleUpAction.log
    curl -v --cacert  /var/run/secrets/kubernetes.io/serviceaccount/ca.crt -H "Authorization:  Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" -X  PATCH -H "Content-Type: application/strategic-merge-patch+json" -d  '{"spec":{"replicas":'"$new_ms"'}}'  https://kubernetes/apis/apps/v1beta1/namespaces/default/statefulsets/${MS_STATEFULSET_NAME} 
    このスクリプトでは、Kubernetes APIサーバーのRESTエンドポイントに「curl」でリクエストを発行し、JSONのレスポンスを解析しています。最初のリクエストは、StatefulSetの現在のreplica数の取得です。続いて、replica数を1つ増やして、リクエストボディのreplicasプロパティに新しい値を入れてPATCHリクエストを送信し、StatefulSetをスケールアップします。

    Wrap Up

    WLDFのポリシーおよびアクションコンポーネントを使用する簡単な設定を使えば、Kubernetes環境で静的に構成されたWebLogic Serverクラスタに対して自動スケーリング機能を利用できます。WLDFはWebLogic Serverとの緊密に統合されているので、スケールの決定に使用可能な非常に包括的な一連のWebLogicドメイン固有の(カスタム)メトリックを利用できます。WLDF通知を受け取るためのRESTエンドポイントとしてwebhookを使用しましたが、サンプルデモでWebLogic Serverクラスタを拡張するため、Kubernetesクラスタで実行されている別のKubernetesオブジェクトまたはサービスを簡単に実装できました。例えば、WebLogic Serverチームは、Kubernetes環境でWebLogic Serverを統合するためKubernetes Operatorパターンも調査しています。Kubernetes Operatorは、「複雑なアプリケーションのインスタンスを作成、構成、管理するためのKubernetes APIを拡張するアプリケーション固有のコントローラ」です。Operatorの詳細については、以下のエントリをご覧ください。
    Introducing Operators: Putting Operational Knowledge into Software
    https://coreos.com/blog/introducing-operators.html
    WebLogic ServerおよびKubernetesとの統合に関連する今後のエントリご期待ください。WebLogic Serverのクラスタリングに関連する次回のエントリは、KubernetesのWebLogic Serverの動的クラスタあたりを予定しています。

    [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
    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アプリケーションのデプロイメントプロセスは複数のパートから構成されています。
    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イメージに過剰な数のレイヤーを持たせるのはお勧めしません。
    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

    • ボリュームを使用してアプリケーションファイルを保存し、すべての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をクラウド環境に素早いデプロイ、素早いオートスケール、シームレスな更新も可能です。