[Java] Extension of Oracle Java SE 8 Public Updates and Java Web Start support

原文はこちら。
https://blogs.oracle.com/java-platform-group/extension-of-oracle-java-se-8-public-updates-and-java-web-start-support

OracleはJava SE Support Roadmapをアップデートしました。
Java SE Support Roadmap
http://www.oracle.com/technetwork/java/eol-135779.html
詳細は追ってホワイトペーパーが発行されますが、主要な変更点を纏めておきます。
  • OracleからのJava SE 8アップデートの無償提供を少なくとも2019年1月にまで延長する。さらに、Oracleは(企業での利用ではなく)個人利用(non-corporate)の場合、少なくとも2020年末までアップデートを継続して提供する
  • Oracleは、Java SE 8 Web Startアプリケーションの無償サポート、(企業利用ではない)個人利用向けのサポートを上記の日まで引き続きサポートする。
    • 訳注)無償サポートは2019年1月まで、個人利用(non-corporate)向けのサポートは2020年末まで 
  • Oracleは、商用利用している場合、もしくはWeb Startに依存するOracle製品と一緒に使う場合、少なくとも2025年3月までJava SE 8のJava Web Startのサポートを継続する。
  • 2015年に発表したように、ブラウザベンダーによるサポートが継続される間、AppletsはJava SE 8で少なくとも2019年3月までサポートを継続する。

[Docker, Cloud] An API First Approach to Microservices Development

原文はこちら。
https://blogs.oracle.com/developers/an-api-first-approach-to-microservices-development

Introduction

ここ数年、クラウドでのさまざまなマイクロサービスプラットフォームに対する私たちの取り組みにより、多くのお客様と緊密な協力関係ができあがりました。その結果、開発者が分散システムの深い知識に加え、マイクロサービスアーキテクチャを採用する際の苦労を深く理解しました 。 Oracleに入社した大きな動機は、スタートアップ、Amazon、マイクロソフト出身の非常に優れた人材と協力して、開発者を真に対象とする、オープンソースコンポーネントに基づくプラットフォームをゼロから構築する機会があることでした。私たちの新しいプラットフォームのこの最初のブログエントリで、このプラットフォームの設計を推し進めるものと、アーキテクチャの概要を紹介します。

What developers are looking for

マイクロサービスへの移行は、これまでの伝統的な方法を使用してアプリケーションを構築している開発者にとっては容易な移行ではありません。分散アプリケーション(つまりこれこそがマイクロサービスアプリケーション)を設計する際に開発者が熟知し、考慮する必要がある新しい概念や詳細がたくさんあります。コンテナやオーケストレータが加われば、多くの開発者がこの新しい世界に対応するために苦労している理由が明確になります。
開発者は、多くの可動パーツを備えた分散システムの観点から、そのアプリケーションについて考える必要があります。その結果、ちょっと例示すると、resiliency(復元性、回復力)、idempotency(冪等性)、eventual consistency(結果整合性)などの課題は、今や考慮すべき重要な側面です。
さらに、マイクロサービスの設計とベストプラクティスの最新動向を踏まえて、アプリケーションやサービスを動作させるためにコンテナやオーケストレーターについて学ぶ必要もあります。Kubernetes、Mesos/Marathon、Docker Swarmなどの最新のクラスター管理とコンテナオーケストレーションソリューションは、ネットワーク化やサービス発見などを単純化します。これらは時間をかけて改良されているとはいえ、これらはいまだインフラストラクチャーの活動です。これらのツールとテクノロジは、サービスのデプロイと接続のプロセスを処理し、障害発生時にサービスの継続実行を保証することを主目的としています。これらの側面は、実際のサービスそのものよりもサービスをホストするために使われるインフラストラクチャとより関連しています。開発者は、オーケストレータの仕組みをしっかりと理解している必要があります。また、サービスを構築する際には、そのことを考慮する必要があります。プログラミングモデルとインフラストラクチャは絡み合っており、明確に分かれていませんので、開発者はサービスを機能させるために基礎となるインフラストラクチャを理解する必要があります。
開発者は実際にサービスをデプロイする実行環境を処理するために必要なコードではなく、ロジックの開発に集中したいと考えている、とお客様やオープンソースコミュニティか何度も伺いましたが、それはどういうことでしょうか。
より複雑なサービスのデプロイや管理で非常にオーバーヘッドがかかりすぎる場合、とりわけ、開発者は(別のサービスに接続するために必要な唯一のもの)APIに注力し、リアクティブなスタイルでサービスを開発し、場合によってはfunction(関数)を使ってシンプルな操作を実行したいのです。
また、OSSスタック上にプラットフォームを構築して、ベンダーのロックインを回避し、パブリッククラウドをオンプレミスインフラストラクチャと組み合わせて使用​​するハイブリッドシナリオを可能にすることも、開発者の間で強く求められています。
API-firstなマイクロサービスプラットフォームの開発の主な動機となったのは、顧客および開発者からの沢山のご意見であり、以下の主要な要求事項に基づきます。
  • 開発者はコードを書くことだけに注力できる(API-firstアプローチ)
  • これは、伝統的なRESTベースのプログラミングモデルと最新のリアクティブイベント駆動モデルを組み合わせである
  • 従来のコンテナベースのマイクロサービスをサーバレス/FaaSインフラストラクチャと統合し、柔軟性を高め、開発者が適切なツールを選択できるようにする
  • 「外部」サービスを簡単に利用することで、開発者がクラウドサービスなどを活用して、レガシーまたはサードパーティのサービスに簡単に接続できる
マイクロサービス以上の範囲を取り扱うため、私たちのプラットフォームをどのように表現するのか、何度も尋ねられました。一瞬にして、Grand Unified Theory of Container Native Development(コンテナネイティブ開発の大統一理論)に追いつきました。

The Platform Approach 

そんなわけで、プラットフォームがどのようなもので、どのコンポーネントを使っているのか、その詳細に入る前に、このプラットフォームを構築するための基本原則を見てみましょう。
  • Opinionated and open: 開発者が簡単かつ速やかに生産性を上げるだけでなく、スタックの深耕や、モジュール交換のオプションも提供
  • クラウドベンダー非依存:新しいアプリケーション開発スタックでプラットフォームが最適に機能するにもかかわらず、任意のクラウドインフラストラクチャ上でインストールできる必要がある
    Meet the New Application Development Stack - Managed Kubernetes, Serverless, Registry, CI/CD, Java
    https://blogs.oracle.com/developers/meet-the-new-application-development-stack-kubernetes-serverless-registry-cicd-java
  • オープンソースベースのスタック:私たちはOSSを強く信じている、我々のスタックは、人気のあるOSSコンポーネント上で構築されており、OSSとして利用可能。

The Platform Architecture 

Figure 1は我々のプラットフォームのハイレベル・アーキテクチャと各コンポーネントの機能を示したものです。
プラットフォームのすべての主要コンポーネントを見てみましょう。APIレジストリは、開発者がマイクロサービスをどのように考え、構築し、使用するかを変えるものです。

API Registry: 

APIレジストリは、クラスタ内で利用可能なAPIに関するすべての情報を格納します。公開したサービスを他の開発者にとって使いやすくするために、開発者はAPIを公開できます。開発者は、特定のサービスまたは(Fn Projectのようなserverlessフレームワークがクラスタにインストールされている場合)Functionを検索できます。
Fn Project
http://fnproject.io/
実際のサービスがまだ準備されていない、、またはデプロイされていない場合でも、開発者はモックサービスに対してAPIをテストできます。クラスタ内のマイクロサービスまたはFunctionに接続するために、開発者はさまざまな言語でクライアントライブラリを生成できます。クライアントライブラリはソースコードに統合され、サービスの呼び出しに使用されます。実行時にクラスタ内のエンドポイントを常に自動的に検出するので、サービスのライフサイクルで変化の可能性のあるIPアドレスやポート番号などのインフラストラクチャの詳細に対処する必要はありません。将来のバージョンでは、開発者がAPIレジストリにセキュリティとルーティングのポリシーを直接設定する機能を追加する予定です。

Event Manager: 

Event Manager(イベントマネージャー)により、サービスおよびFunctionが、他のサービスおよびFunctionがサブスクライブ可能なイベントを公開できます。これは、EventProviderがイベントを発行し、コンシューマ(Functionまたはマイクロサービスのいずれか)がそれらを消費するという、イベント駆動型プログラミングモデルを可能にする主要コンポーネントです。EventManagerを使えば、開発者は、従来のRESTベースのプログラミングモデルと、リアクティブ/イベント駆動モデルの両方を、統合されたプラットフォームで組み合わせることができ、ワークフローやツールに関して一貫したエクスペリエンスを提供します。

Service Broker: 

主要なクラウドベンダーに移行する過程で、Kubernetesクラスタ上でサービスを実行、運用するのではなく、マネージド・クラウドサービスを使用することを多くのお客様が選択していることがわかりました。これの一般的な例はRedisキャッシュであり、ほぼすべての主要なクラウドプロバイダーがマネージド・サービスとして提供しています。その結果、マイクロサービスベースのアプリケーションは、開発チームによって開発されたサービスだけでなく、マネージド・クラウドサービスから構成されることが非常に一般的です。Kubernetesは、Kubernetesクラスター内で外部サービスを利用できるようにする、service catalog(サービスカタログ)という素晴らしい新機能を導入しました。そのため、初期設計を拡張し、外部サービスへのアクセスを構成するだけでなく、ユーザーサービスをAPIレジストリに登録することで、開発者がマネージド・サービスと一緒にそれらを簡単に使用できるようにしました。
このように、クラウドベンダーが提供するような外部サービスは、クラスタ内の他のサービスと同様に、同じワークフローを使用する開発者と共に使用できます。利用したいAPIを特定し、クライアントライブラリを生成し、サービスとの実際の通信を処理します。
Service Brokerは、既存のインフラストラクチャの最新化に携わる開発者をサポートします。例えば、既存のコードをクラスタに展開できるコンテナにパッケージングできます。モダナイズできない既存アプリケーションが存在する場合のソリューションも検討しています。この場合、Service Brokerを使用してAPIレジストリ内の一連のAPIを公開するプロキシサービスを「公開」することで、クラスタ内の他のマイクロサービスを利用するのと同様に外部/レガシーシステムを利用できます。

Kubernetes and Istio: 

我々のプラットフォームの基礎としてKubernetesを選択したのは、マイクロサービスを実行するための最も一般的なコンテナ管理プラットフォームとしてKubernetesが台頭しているためです。さらに、Kubernetes周辺のコミュニティが急速に成長しており、すべての主要クラウドベンダーでKubernetesがサポートされていることももう一つの重要な要素です。
先に述べたように、主たる目標の1つは開発者にとっての複雑性を軽減することです。複数のマイクロサービス間の通信の管理は困難な作業です。 このため、Istioをサービスメッシュとしてプラットフォームに追加する必要があると判断しました。Istioを使えば、監視、診断、複雑なルーティング、復元力、ポリシーを無料で享受できます。Istioのおかげで、これらの機能を実装する開発者の大きな負担がなくなります。 Istioを使えば、こうした機能をプラットフォームレベルで利用可能です。

Monitoring

監視は、マイクロサービスプラットフォームの重要なコンポーネントです。潜在的に多くの可動部分があるならば、システムは実行時にその動作を監視する方法が必要です。当社のマイクロサービスプラットフォームでは、我々のプラットフォームの他のコンポーネントと同様、Prometheus、Zipkin/Jaeger、Grafana、Vizsceralなど、統合されかつ実戦で叩かれた技術をベースにした、すぐに使える監視ソリューションを提供することを選択しました。
API-firstアプローチを監視にも推し進めるべく、我々の監視ソリューションでは、マイクロサービスが(Vizsceralを使って)互いにどのように接続されているか、それらをまたがって流れるデータを開発者が確認できます。将来的には、どのAPIが利用されてきたかを示すことも考えています。これにより、開発者は、Zipkin/Jaegerの分散トラッキング情報を使って、潜在的なレイテンシの問題を調査したり、サービスの効率を向上したりできます。将来、他のサービスとの統合を追加する予定です。例えば、マイクロサービス間のリクエストをJVM内のデータ構造と相関させる機能を追加することで、開発者は各リクエストに対してデータがどのように処理されているかを追うことで、複数のマイクロサービス全体(の性能)を最適化できます。

What’s Next? 

このエントリは、

  • 新しいプラットフォームの初期の概要
  • 私たちのモチベーションに対する洞察
  • 使用した設計ガイドライン

を示したものです。私たちは、2018年初頭の初期OSSリリースに近づくにつれて、プラットフォームのさまざまな側面をより深く理解してもらうためのブログを投稿する予定です。それまでの間、以下のJavaOneセッションをご覧ください。
このトピックの背景については、Getting Started with Microservicesシリーズの他のブログ記事を参照してください。Part 1では、マイクロサービスの主な利点のいくつかについて説明すると共に、マイクロサービスを扱う際に考慮すべきいくつかの領域に触れています。
Getting Started with Microservices, Part 1: Advantages and Considerations
https://blogs.oracle.com/developers/getting-started-with-microservices-part-one
Part 2では、コンテナがマイクロサービスの話にどのように適合しているかを検討します。
Getting Started with Microservices, Part 2: Containers and Microservices
https://blogs.oracle.com/developers/getting-started-with-microservices-part-two
Part 3では、マイクロサービスを実装するための基本的なパターンとベストプラクティスについて説明します。
Getting Started with Microservices, Part 3: Basic Patterns and Best Practices
https://blogs.oracle.com/developers/getting-started-with-microservices-part-three
Part 4では、コンテナ化されたマイクロサービスでDevOpsの原則とプラクティスを使用する際の重要な側面について検討します。
Getting Started with Microservices, Part 4: Fundamentals of DevOps with Containerized Microservices
https://blogs.oracle.com/developers/getting-started-with-microservices-part-four

Related content

[Database, Analytics] Introducing Oracle Machine Learning SQL Notebooks for the Oracle Autonomous Data Warehouse Cloud!

原文はこちら。
https://blogs.oracle.com/datamining/introducing-oracle-machine-learning-sql-notebooks-for-the-oracle-autonomous-data-warehouse-cloud

データサイエンティストがOracle Autonomous Data Warehouse CloudでコラボレーションするためのApache ZeppelinベースのMachine Learning SQL Notebookに関する記事です。

Overview

Oracle Machine Learningは、データサイエンティストがOracle Autonomous Data Warehouse Cloud(ADWC)で機械学習を実行するための新しいSQLノートブック・インタフェースです。ノートブック・テクノロジーは、データサイエンス・チームの生産性を向上させるための前提条件、アプローチ、および理論的根拠の文書化のサポートだけでなく、スクリプトの作成もサポートします。Oracle Machine Learning SQLノートブックはApache Zeppelinテクノロジーをベースとしており、これを使えば、チームは協力してOracle ADWCで予測モデルと分析手法を構築、評価、および展開することができます。
Apache Zeppelin
https://zeppelin.apache.org/
Multi-user collaboration機能により、同じノートブックを異なるユーザーが同時に開くことができます。あるユーザーが行った変更は、すぐに他のチームメンバー向けにアップデートされます。
Oracle Machine Learning SQLノートブックを使うと、Oracle Advanced Analyticsの機械学習アルゴリズム(分類、回帰、異常検出、クラスタリング、関連付け、属性の重要性、特徴抽出、時系列など)のOracleの並列化されたスケーラブルなデータベース内実装、SQL、PL/SQL、Oracleの統計や分析のためのSQL関数へ簡単にアクセスできます。
Oracle Machine Learning SQLノートブックとOracle Advanced Analyticsの機械学習SQL関数もライブラリとPL/SQLを組み合わせて使うと、企業はダッシュボードやエンタープライズ・アプリケーションを通して、新しいインサイトの発見の自動化や、予測の生成、データへのAIの追加が可能です。

(訳注)原文ではviz(すなわち)と言っていますが、文脈からviaのtypoと判断しました。

Oracle Machine Learning SQLノートブックは、セキュリティ、認証、および監査のエンタープライズ要件をサポートするために、すべてのOracle標準に準拠し、データ、モデル、およびノートブックへの特権アクセスをサポートします。
Oracle Machine Learning Notebook Included in Autonomous Data Warehouse Cloud
https://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/c78ae504-6f73-42eb-a868-64143436b9ae/File/93a28ec22dd433a9c84d417106d22425/oracle_machine_learning_for_otn.pdf

Key Features

  • データサイエンティスト用のコラボレーションSQLノートブックUI
  • Autonomous Data Warehouse Cloudにパッケージ済み
  • 共有されたノートブックやテンプレート、権限、スケジューラなどへの簡単アクセス
  • 30以上の並列、スケーラブルな機械学習アルゴリズムがデータベース内に実装され、アクセス可能
  • SQLやPL/SQLのスクリプト言語をサポート
  • ADWCのエンタープライズ機械学習方法論のデプロイメントの有効化ならびにサポート

Screen Shots   

免責事項:製品の詳細機能は変更の可能性があります。

データサイエンス・チームは、Oracle Machine Learningを使ってOracle ADWC内で機械学習のメソドロジーを共同して構築できます



Oracle Machine Learningノートブックでは、迅速な分析、シンプルな可視化、機械学習ソリューションの構築のためにOracle ADWCで管理されたデータに簡単にアクセスできます


Oracle Machine Learning SQLノートブックのスタートページ



Oracle Machine Learningノートブックの新規作成



Oracle ADWCで管理されているデータも簡単に可視化できます



Oracleのデータベースに組み込まれたSQL統計関数を使えば、迅速に統計分析の実行も簡単です



Oracle Advanced Analyticsの機械学習アルゴリズムの並列化された実装がデータベース内に含まれており、これを使って、Oracle ADWCで機械学習メソドロジーをビルド、評価、およびデプロイします。

[Java] Introduction to the JDK HTTP Client

原文はこちら。
https://blogs.oracle.com/java/jdk-http-client

Chris Hegartyによるエントリです。

JDK HTTP ClientがJDK 9に追加されました。これを使ってHTTPリソースをリクエストできます。
  • HTTP/1.1、HTTP/2のサポート
  • 同期/非同期プログラミングモデルの両方をサポート
  • reactive-streamsとしてリクエスト及びレスポンスを処理
  • ビルダーパターンの利用
reactive-streams
http://reactive-streams.org/
以下は文字列としてレスポンスボディを出力する基本的なリクエストの例です。
HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder()
                                 .uri(URI.create("http://openjdk.java.net/"))
                                 .build();
client.sendAsync(request, asString())
      .thenApply(HttpResponse::body)
      .thenAccept(System.out::println)
      .join();

Incubation

APIは現在、Incubatingの状態にあり、モジュールとパッケージ名に反映されています。これは、APIを育てて、将来のバージョンのJava SEで標準に取り込むことを目的としています。インキュベーションに関する詳細はJEP 11にありますが、現時点では、パッケージ名を認識し、そのパッケージに含まれているモジュールjdk.incubator.httpclientをコマンドラインオプション--add-modulesで指定するとAPIにアクセスできると知っていれば十分です。
JEP 11: Incubator Modules
http://openjdk.java.net/jeps/11
以下のようにMavenコンパイラとsurefireプラグインを設定できます。
<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>9</source>
                    <target>9</target>
                    <compilerArgument>--add-modules=jdk.incubator.httpclient</compilerArgument>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.20.1</version>
                <configuration>
                    <argLine>--add-modules=jdk.incubator.httpclient</argLine>
                </configuration>
            </plugin>
        </plugins>
    </build>

HttpClient

リクエストを送信する場合、まずビルダーでHttpClientを作成します。ビルダーを使ってクライアントの状態毎に以下のように構成します。
  • 所望のプロトコルバージョン(HTTP/1.1 もしくは HTTP/2)
  • リダイレクトに従うか否かの指定
  • プロキシの設定
  • authenticatorの設定
HttpClient client = HttpClient.newBuilder()
                              .version(Version.HTTP_2)
                              .followRedirects(Redirect.SAME_PROTOCOL)
                              .proxy(ProxySelector.of(new InetSocketAddress("www-proxy.com", 8080)))
                              .authenticator(Authenticator.getDefault())
                              .build();
ビルダーを使ってHttpClientを作成後、HttpClientを使って複数のリクエストを送信できます。

HttpRequest

HttpRequestはビルダーを使って作成します。リクエストビルダーを使って以下の構成を設定できます。
  • リクエストURI
  • リクエストメソッド(GET、PUT、POST)
  • リクエスト本体(必要であれば)
  • タイムアウト
  • リクエスト・ヘッダー
HttpRequest request = HttpRequest.newBuilder()
                                 .uri(URI.create("http://openjdk.java.net/"))
                                 .timeout(Duration.ofMinutes(1))
                                 .header("Content-Type", "application/json")
                                 .POST(BodyPublisher.fromFile(Paths.get("file.json")))
                                 .build()
ビルダーを使って作成したHttpRequestはイミュータブルなので、複数回送信できます。

Synchronous or Asynchronous

リクエストを同期・非同期のいずれの方法でも送信できます。同期APIは想定通りHttpResponseが利用可能になるまでブロックします。
HttpResponse<String> response = client.send(request, BodyHandler.asString());
System.out.println(response.statusCode());
System.out.println(response.body());
非同期APIは、使用可能になったときにHttpResponseで完了するCompletableFutureですぐに戻ります。CompletableFutureはJava 8で追加され、構成可能な非同期プログラミングをサポートしています。
client.sendAsync(request, BodyHandler.asString())
      .thenApply(response -> { 
                                 System.out.println(response.statusCode());
                                 return response;
                             } )
      .thenApply(HttpResponse::body)
      .thenAccept(System.out::println);

Data as reactive-streams

リクエストおよびレスポンス本体は、reactive stream(ノンブロッキングのバックプレッシャーを持つ非同期データストリーム)として利用できます。HttpClientは、事実上、リクエスト本体のサブスクライバであり、レスポンス本体のパブリッシャです。BodyHandlerインターフェイスを使って、実際のレスポンス本体を受信する前にレスポンスコードとヘッダーを検査し、レスポンスBodySubscriberを作成する必要があります。
public abstract class HttpRequest {
        ...
    public interface BodyPublisher
                    extends Flow.Publisher<ByteBuffer> { ... }
}

public abstract class HttpResponse<T> {
        ...
    public interface BodyHandler<T> {
            BodySubscriber<T> apply(int statusCode, HttpHeaders responseHeaders);
    }

    public interface BodySubscriber<T>
                    extends Flow.Subscriber<List<ByteBuffer>> { ... }
} 
HttpRequestとHttpResponseでは、リクエスト・パブリッシャとレスポンス・サブスクライバを作成するための便利なファクトリメソッドを多数提供しており、ファイル、文字列、バイトといった、よく使われる本体のデータtタイプを処理できます。これらの便利な実装では、Stringのように高水準のJavaタイプを作成できるようになるまでデータを蓄積するか、ファイルの場合はデータをストリーミングします。BodySubscriberとBodyPublisherインターフェースを実装し、カスタムのリアクティブストリームとしてデータを処理することも可能です。
HttpRequest.BodyPublisher::fromByteArray(byte[])
HttpRequest.BodyPublisher::fromByteArrays(Iterable)
HttpRequest.BodyPublisher::fromFile(Path)
HttpRequest.BodyPublisher::fromString(String)
HttpRequest.BodyPublisher::fromInputStream(Supplier< InputStream>)

HttpResponse.BodyHandler::asByteArray()
HttpResponse.BodyHandler::asString()
HttpResponse.BodyHandler::asFile(Path)
HttpResponse.BodyHandler::discard()
java.util.concurrent.FlowのPublisher/SubscriberタイプとHTTP ClientのBodyPublisher/BodySubscriberタイプとの間のAdapterがJDK 10で追加されました。詳細はJDK-8193366を参照してください。
Improve interoperability between HTTP Client's BodyPublisher/BodySubscriber and Flow.Subscriber/Publisher
https://bugs.openjdk.java.net/browse/JDK-8193366

HTTP/2

JDK HTTP Clientは、HTTP/1.1とHTTP/2の両方をサポートしています。デフォルトでは、クライアントはHTTP/2を使用してリクエストを送信します。まだHTTP/2をサポートしていないサーバーに送信されたリクエストは自動的にHTTP/1.1にダウングレードされます。HTTP/2がもたらす主な改善点の概要は以下の通りです。

  • ヘッダー圧縮:HTTP/2ではHPACK圧縮を使用しているため、オーバーヘッドが減少します。
  • サーバーへの1個の接続:複数のTCP接続をセットアップするために必要なラウンドトリップが減ります。
  • 多重化:同一接続で同時に複数リクエストを送信できます。
  • サーバープッシュ:必要なりソースをクライアントに送信可能な追加機能
  • バイナリフォーマット:テキスト形式に比べてメッセージサイズが小さくなります

HTTP/2はデフォルトの優先プロトコルであり、必要に応じてシームレスにHTTP/1.1にフォールバックします。将来HTTP/2がより広く普及すれば、JDK HTTP Clientはよい状況になることでしょう。

The Future

incubation状態のJDK HTTP Clientは、コミュニティからのフィードバックに基づいてJDK 10で更新されました。便利なリクエスト本体のパブリッシャおよびレスポンス本体のサブスクライバが追加されました。実装は完全に非同期に書き直されました。
Java SEでHTTP Clientを標準化するためにJEP 321を作成しました。
JEP 321: HTTP Client (Standard)
http://openjdk.java.net/jeps/321
これはつまり、jdk.incubatorというモジュールとパッケージの接頭辞を削除して、java.net名前空間の何かに変わるということです。--add-modulesという追加コマンドラインオプションは不要になり、モジュールはデフォルトで利用可能になる予定です。

References

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