[Database, Node.js] node-oracledb 2.0 with pre-built binaries is on npm

原文はこちら。
https://blogs.oracle.com/opal/node-oracledb-20-with-pre-built-binaries-is-on-npm

Release announcement

Oracle Database用のNode.jsアドオンであるnode-oracledb 2.0.15がnpmからご利用頂けるようになりました。
node-oracledb
https://www.npmjs.com/package/oracledb 

Top features: Pre-built binaries, Query fetch improvements

変化を起こす時がやってきました。node-oracledb version 1は安定していましたが、node-oracledb 2をご提供できることを誇りに思っています。コードとドキュメント全体を改善し、このリリースはよいものになっています。現在、3000を超える機能テストと、Oracle社内テストインフラストラクチャの下さまざまな環境で実行するストレステストを実施してきました。
全ての変更は変更履歴をご覧ください。
Change Log
https://github.com/oracle/node-oracledb/blob/master/CHANGELOG.md
node-oracledb 1.13から2.0への移行は、以下のURLをご覧ください。
Migrating from node-oracledb 1.13 to node-oracledb 2.0
https://github.com/oracle/node-oracledb/blob/master/doc/api.md#migratev1v2

node-oracledb v2 highlights

  • node-oracledb 2.0は、便利のために既製バイナリを持つ最初のリリースです。特にWindowsユーザーの方々にとってかなり簡単になっています。

    Node.js 4、6、8、9のバイナリは、Windows 64ビット、macOS 64ビット、およびLinux 64ビット(Oracle Linux 6上に構築)で使用できます。
    package.jsonの依存関係にoracledbを追加するか、手動で以下のコマンドでインストールしてください。
    npm install oracledb
    (もちろんOracle Clientはまだ別途必要です。これらは全て重労働です)。
    バイナリが利用できないときにはエラーメッセージが表示され、
    require('oracledb')
    で失敗したときにメッセージが改善されましたが、古いglibcライブラリを持つLinuxユーザの場合、Linuxランタイムエラーが発生する可能性がありますので、この場合は以前と同様ソースからnode-oracledbをビルドする必要があります。以下を参照してください。
    独自の内部Webサーバーにバイナリパッケージをホスティングするためのサポートがあります。これは、多数のデプロイメントを持つユーザーに最適です。以下のREADMEをご覧ください。
    node-oracledb/package/README.md
    https://github.com/oracle/node-oracledb/blob/master/package/README.md
    node-oracledb 2.0は、Pythonのcx_Oracle 6.x APIや他の言語のサードパーティ製APIでも使用されているODPI-C抽象化レイヤーを使用する最初のリリースです。
    Oracle Database Programming Interface for Drivers and Applications
    https://github.com/oracle/odpi
    このODPIの利用がnode-oracledb 2.0バイナリを配布できる主な変更です。ODPI-C利用の別の結果として、任意のnode-oracledb 2バイナリは、再コンパイルを必要とせずにOracleクライアント11.2,12.1または12.2ライブラリのいずれかで実行できます。これにより、マシン間でnode-oracledbビルドをコピーするときの移植性が向上します。利用可能なOracleの機能はOracle Client(およびOracle Database!)のバージョンによって異なるため、意図したデプロイメント環境を使用してアプリケーションをテストすることが重要です。
  • 必要であれば、ソースコードからドライバを構築できます。コンパイルはバージョン1より簡単になりました。Oracleヘッダー・ファイルは不要になり、環境変数OCI_INC_DIRまたはOCI_LIB_DIRも不要です。
    ソースからビルドする場合、GitHubブランチまたはタグからコードを取得する必要があります。一般に、必要なのは最新のリリースタグです。
    node-oracledb Releases
    https://github.com/oracle/node-oracledb/releases
    Python 2.7、 gitユーティリティ、コンパイラがあることを確認し、package.jsonの依存関係にoracle/node-oracledb.git#v2.0.15を追加するか、手動でインストールを実行します。
    npm install oracle/node-oracledb.git#v2.0.15
    
    gitを有していないユーザーや、ODPIサブモジュールコードをpullしない古いバージョンのNodeのユーザーは、ソースパッケージを使用できます。
    npm install https://github.com/oracle/node-oracledb/releases/download/v2.0.15/oracledb-src-2.0.15.tgz
    
    コンパイル開始前にGitHubがソースをダウンロードするのが少し遅くなる可能性があることがわかりました。
  • クエリ処理の改善
    • 直接フェッチを拡張して無制限の行数をフェッチできるようにしたり、このデフォルト・メソッドが取得する行数のデフォルト行数を無制限に変更できるようにしました。大量の行数を取り扱う場合において今なお既存のResultSetやStreamingメソッドの利用を推奨します。
    • ODPI-Cが内部的に「プリフェッチ」の代わりに「配列フェッチ」を使用しています(どちらも、バッファリングが行われる場所のみが異なるバッファリング/チューニングのための基礎となるメソッドで、どちらもアプリケーションには透過的です)ため、prefetchRowsを新しい同等のプロパティfetchArraySizeで置き換えました。
    • より良いパフォーマンスを得るために、getRow()のバッファリングや行をJavaScriptに移動しました。もはや、より低いレイヤーへの頻繁な呼び出しは不要です。
    いくつかのTipsを以下のエントリでご紹介しています。
    Node-oracledb v2 Query Methods and Fetch Tuning
    https://blogs.oracle.com/opal/node-oracledb-v2-query-methods-and-fetch-tuning
    https://orablogs-jp.blogspot.jp/2018/01/node-oracledb-v2-query-methods-and.html
  • アプリケーションがリソースリークしないように、リソース処理を強化しました。LOBまたはResultSetが開いているときに誤って接続をクローズしようとすると、新しいエラーDPI-1054が送出されます。
  • LOBのfetchAsStringおよびfetchAsBufferの問合せ、およびLOBバインドにおけるnode-oracledbのサイズ制限ですが、node-oracledb version 1では、Oracle 11gR2クライアントライブラリが使用されている場合にこれらの値が特に低いため、Oracleクライアントを更新していない人にとってはこれは歓迎されることでしょう。Node.jsおよびV8ではサイズが制限されるため、引き続きラージLOBに対してStreamインタフェースを使用します。
  • ROWIDとUROWIDをサポートするようになりました。データは文字列として取得します。
  • LONG(String型としてデータを取得)およびLONG RAW(Buffer型としてデータを取得)型の列をサポートするようになりました。
  • TIMESTAMP WITH TIME ZONEの日付型をサポートするようになりました。これらはLOCAL TIME ZONEを使ってnode-oracledbのDateオブジェクトにマップされます。TIME ZONEコンポーネントは、Dateオブジェクトでは使用できません。
  • NCHAR、NVARCHAR2、NCLOB 列のクエリサポートを追加しました。Database Character SetとDatabase National Character Setによっては、DMLとのバインドはデータを正しくインサートしない可能性があります。

Plans for Version 1

これまでに言明した計画では、Node.js 4のLTS保守が2018年4月で終了すると、バージョン1の正式サポートを中止するとしていました。
Node-oracledb 1.x and 2.x: Plans for 2017 #601
https://github.com/oracle/node-oracledb/issues/601
1.13.1がしばらく安定していたことを嬉しく思っており、例外的な状況が発生しない限り、node-oracledb 1リリースを追加する必要はないと考えています。

Plans for Version 2

現在、Node.js 4、6、8、9でテストしています。新しいnode.jsのバージョンがリリースされると、このリストはもちろん変更されます。既製バイナリも変更され、可用性は保証されません。
ODPI-Cは、node-oracledbを拡張するための強固な基盤を形成します。また、ODPI-CをベースにしたPython cx_Oracle 6のユーザーは、利用可能な詳細のOracle機能を理解しています。これらの機能の多くは、node-oracledbユーザーからも要求されてきました。他のオープンソースプロジェクトと同様に、node-oracledbのためのしっかりした保証はありませんが、私たちが向けるべき一般的な方向とご理解いただいて結構です。プルリクエストは大歓迎です。
気付かないかもしれませんが、Oracle Databaseの次期メジャーリリースをテストしています(作成を手助けしています)。そのため、node-oracledbの作業から離れて、Oracle Database全体にあわせて動く必要があったこともあります。クライアントおよびサーバーのいずれの場合でも、今後のリリースでは素晴らしいものをお届けできると思っています。

Resources

node-oracledbのインストール手順
Installing node-oracledb Version 2
https://github.com/oracle/node-oracledb/blob/master/INSTALL.md
node-oracledbのドキュメント
node-oracledb 2.0 Documentation for the Oracle Database Node.js Add-on
https://github.com/oracle/node-oracledb/blob/master/doc/api.md
node-oracledbの変更履歴
Change Log
https://github.com/oracle/node-oracledb/blob/master/CHANGELOG.md
node-oracledb 1.13から2.0への移行は、以下のURLをご覧ください。
Migrating from node-oracledb 1.13 to node-oracledb 2.0
https://github.com/oracle/node-oracledb/blob/master/doc/api.md#migratev1v2
node-oracledbに関する問題や質問はGitHubにお寄せください。
node-oracledb - issues
https://github.com/oracle/node-oracledb/issues
最後に、node-oracledbへの貢献は大歓迎です。以下のURLをご覧ください。
Contributing to node-oracledb
https://github.com/oracle/node-oracledb/blob/master/CONTRIBUTING.md

[Cloud] Announcing Open Source Jenkins Plugin for Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/developers/announcing-open-source-jenkins-plugin-for-oracle-cloud-infrastructure

Jenkinsは、ソフトウェアプロジェクトを継続的に構築およびテストするために使用できる continuous integration と continuous delivery のためのアプリケーションです。Jenkins OCI PluginはGithubからご利用いただけます。そしてユーザーはこのプラグインを使ってJenkinsからOracle Cloud Infrastructureリソースにアクセスし管理できます。Jenkins OCI Pluginを使うJenkinsマスター・インスタンスでは、Oracle Cloud Infrastructure内のスレーブ(インスタンス)をオンデマンドで起動し、ジョブ完了後自動的にスレーブを削除できます。
Oracle Cloud Infrastructure
https://cloud.oracle.com/cloud-infrastructure
Jenkins OCI Pluginをインストール後、OCI Cloudオプションと必要なシェイプ、イメージ、ドメインといったテンプレートを追加できます。テンプレートには、Jenkinsジョブで使用できるラベルがあり、複数のテンプレートをサポートしています。[テンプレート]オプションには、ラベル、ドメイン、資格証明、シェイプ、イメージ、スレーブリミット、およびタイムアウトが含まれます。

以下でプラグインのビルドとインストール手順をご紹介しますが、この内容はGitHubでもご覧いただけます。
Jenkins Plugin for Oracle Cloud Infrastructure (Compute)
https://github.com/oracle/jenkins-oci-plugin

Installing the Jenkins OCI Plugin

以下のセクションで、Jenkins OCI Pluginのコンパイルとインストールについて説明します。

Plugins required:

  • credentials v2.1.14以上
  • ssh-slaves v1.6以上
  • ssh-credentials v1.13以上

Compile and install OCI Java SDK:

以下のIssueページを参照してください。Maven 3.3.9および3.5.0でテスト済みです。
Maven release #25
https://github.com/oracle/oci-java-sdk/issues/25

Step 1 – Download plugin

$ git clone https://github.com/oracle/oci-java-sdk
$ cd oci-java-sdk
$ mvn compile install

Step 2 – Compile the Plugin hpi file

$ git clone https://github.com/oracle/jenkins-oci-plugin
$ cd jenkins-oci-plugin
$ mvn compile hpi:hpi

Step 3 – Install hpi

  • Option 1 – Manage Jenkins > Manage Plugins と辿りAdvancedタブをクリック、Upload Pluginを選択して、Choose Fileをクリックしてファイルを選択し、Uploadをクリックする
  • Option 2 – Copy the ダウンロード済みの.hpiファイルをJenkinsマスターのJENKINS_HOME/pluginsに配置する
Jenkinsを再起動すると、Manage PluginsInstalledセクションでOCI Pluginが現れるはずです。

OCI Jenkins Pluginの設定の詳細については、GitHubのドキュメントを参照ください。
Jenkins Plugin for Oracle Cloud Infrastructure (Compute) - Configuration
https://github.com/oracle/oci-compute-jenkins-plugin#configuration
また、問題や質問がある場合は、Issuesタブから送信して開発チームにお問い合わせください。
Jenkins Plugin for Oracle Cloud Infrastructure (Compute) - Issues
https://github.com/oracle/jenkins-oci-plugin/issues

Related content

[Linux] Tracing NFS: Beyond tcpdump

原文はこちら。
https://blogs.oracle.com/linuxkernel/tracing-nfs%3a-beyond-tcpdump

このブログエントリはLinuxカーネル開発者のChuck Leverによるものです。歴史的に、tcpdumpとrpcdebugはNFSクライアントのトラブルシューティングで使われてきましたが、さすがに古くなってきました。Oracleでは、既存のツールをチェックし、タイミングに影響を与えたり、キャプチャ情報の損失を招くことなく、高負荷のワークロードや高性能ネットワーク・ファブリック上でNFSクライアントの動作を監視できる新しいツールを提供したいと考えています。

Historical NFS and RPC Debugging Facilities

ネットワークトラフィックが暗号化されていない限り、NFSの操作はNFSクライアントとNFSサーバーの間でネットワークをスヌーピングするすべての人から見えてしまいます。NFSの操作は、tcpdump、wireshark、またはsnoopなどを使い、クライアントまたはサーバーのいずれかで利用できるスヌーピングツールで取得できます。これらのツールには、ネットワークキャプチャやpcapファイルに含まれるNFSの操作を解析し、後で解析するためにファイルに保存したり、人間が読める解析形式で表示する機能があります。

これはNFS開発者が使用できる最も貴重なツールの1つですが、いくつかの欠点があります。
  • 最も有用なデータをキャプチャするためには、問題が発生したときに、ツールが実行されている必要があります。問題が発生した後にキャプチャされたデータは、一般に役に立ちません。
  • キャプチャツールは膨大な量のデータを非常に迅速に生成できます。パケット・フィルタリングとパケット・キャプチャを旨く使ってファイルに束ねることで、解析対象のデータを軽減できます。
  • データレートが高いため、このツールではキャプチャ実行中のシステムに大きなオーバーヘッドが発生する可能性がありますが、問題の再現を避けるため、タイミングを変更できます。そうしない場合、システムが追いつくのに十分なパフォーマンスがないために、重要なパケットがキャプチャされない可能性があります。
  • ユーザーデータもこのツールでキャプチャされるため、結果として得られるキャプチャファイルのサイズが大きくなり、機密データの保存にNFSを使用している場合にはプライバシーの問題が発生します。
正確なキャプチャ構成の権利を取得し、適切な環境で根本的な問題をきれいにキャプチャできるようになるまで、キャプチャを繰り返し実行する必要があります。

Linuxには、NFSクライアントとRPCクライアントとサーバースタックに組み込まれた内部トレースメカニズムがあります。これは "rpcdebug"ファシリティとして知られています。これを有効にすると、NFS READの送信やRPCの各実行ステップなどの特定のイベントに対するメッセージをカーネルログ(通常は/var/log/messages)に追加します。

このメカニズムは、ネットワークキャプチャと同様の欠点を抱えています。より批判的に言えば、ユーザファイルではなくカーネルログやシステムコンソールに書き込むため、以下のような重大な欠点があります。
  • システムコンソールは、実際のシリアルポートであることことが多々あるため、デバッグメッセージの生成速度が制限され、NFS操作が遅くます。大量のNFSワークロードを実行している本番システムでrpcdebugを使用することは適切ではありません。
  • 最近のLinuxディストリビューションでは、カーネルログにレート制限が組み込まれているため、短期間に数百のデバッグメッセージが表示された後、レートリミッタによって新しいメッセージが送信されます。問題の再現時には、問題が再現される前にレート制限が頻繁に発生します。
さらに、デバッグレベルの細かさももちろん関係します。たとえば、各NFS GETATTR操作を確認するには、すべてのNFS操作でデバッグメッセージを有効にする必要があり、結果として大量のデータが生成されます。

Introducing static trace points

大規模なワークロードや、NFSの同時ユーザーが多いシステム、またはますます高速なネットワークでNFSを頻繁に使用する場合、従来のデバッグ・メカニズムはもはや実行可能ではなく、代わりに、低いオーバヘッドと柔軟なイベント・フィルタリングを持つメカニズムが必要です。Linux NFSコミュニティは、この目的のために静的トレースポイントを採用しています。

これらのトレースポイントは、開発者がソースコードの固定部分に追加した、重要な情報(RPC XID、ユーザーID、I/Oのサイズ、エラーコードなど)を取得できるポイントです。トレースポイントは常に使用可能であり、有効にしてもオーバーヘッドは低いままです。さらに、必要に応じて個々のトレースポイントのオン/オフを切り替えることができます。トレース・データはユーザー・ファイルに送られ、コンパクトな形式で保管されます。ユーザーデータはトレースポイントで公開されないので、キャプチャデータのサイズはずっと小さくなります。

LinuxカーネルのNFSクライアントには、すでに複数のNFSトレースポイントがあり、NFSクライアントおよびRPC層の操作のさまざまな運用時の情報を取得します。しかし、Oracleは最近、特にNFS I/O操作をキャプチャする一連のトレース・ポイントを提供しました。新しいトレースポイントは、v4.14 LinuxカーネルのNFSクライアントで初めて登場しました。

これには、すべてのNFS READ、WRITE、COMMIT操作の開始と操作の引数(データペイロードを除く)、終了、そしてそれぞれの操作で発生したエラーが含まれます。これらの6つのトレースポイントのそれぞれを個別に有効にすることも、一度に有効にすることもできます。生成される各イベントには、タイムスタンプ情報と、操作を要求したCPUコアおよびプロセスに関する情報が含まれます。

これらのトレースポイントを以下のような洗練された方法で使用できます。
  • 一連の個々のNFS READ操作を記録し、記録されたタイムスタンプを使用して外れ値分析を生成する
  • 本番ワークロードで、特定のエラー状態のNFS WRITE結果を監視する
  • 負荷の大きいワークロードでも、サーバーの再起動時にNFS COMMITが正しく動作することを確認する
  • NFSv4の状態回復がNFS I / O操作に与える影響を調べる
NFSトレースポイントは、カーネルの他の静的トレースポイントと同様に、trace-cmdツールを使用して制御します。以下のコマンド
trace-cmd list | grep nfs:
を使用して、カーネルNFSクライアントに関連するトレースポイントを検出します。v4.14のNFSクライアントに導入されたトレースポイントには以下のものが含まれます。
  • nfs:nfs_initiate_read
  • nfs:nfs_readpage_done
  • nfs:nfs_initiate_write
  • nfs:nfs_writeback_done
  • nfs:nfs_initiate_commit
  • nfs:nfs_commit_done
Oracleは、NFS導入を担当するシステム管理者にとって、優れたトラブルシューティングおよび監視ツールがどれほど重要であるかを認識しています。私たちは、通常の操作を妨げずに深い可視性を提供するLinuxに機能を引き続き提供することを意図しています。

[Linux, Cloud] A Simple Guide to Nested KVM Virtualization on Oracle Cloud Infrastructure

原文はこちら。
https://blogs.oracle.com/cloud-infrastructure/nested-kvm-virtualization-on-oracle-iaas

Why KVM Nested Virtualization?

Nested virtualizationを使えば、物理ホストのハードウェアアクセラレーションを使いつつ、仮想マシン(VM)を別のVM内で実行できます。簡単なプロビジョニングプロセスで、エンタープライズや通常のユーザーに対し、ワークロードの要件に基づいて低コストかつ大きな柔軟性を提供します。このエントリでは、Oracle Cloud Infrastructure(OCI)KVMハイパーバイザー仮想マシンの上にKVMゲストをインストール、構成、および使用する手順を紹介します。このプロセスは、Nested KVM Virtualizationとも呼ばれます。

Getting Started

以下は、KVMハイパーバイザーホストとして利用できる現在のシェイプオプションです(注:原文執筆時(2017/10/27)の情報は古いため、最新情報のためにURLに差し替えています)。 環境で使用できる現行のオプションと機能については、Oracle Cloud Infrastructureのパブリック・ドキュメントを参照した後、作業負荷要件に基づいて仮想マシン・シェイプを選択し、プロビジョニングしてから手順をすすめてください。以下はNested KVM Hypervisorに利用可能なインスタンスシェイプの一例です。

* ネットワーク帯域幅はVCN内のトラフィックの予想帯域幅に基づいています。
** Windows VMインスタンスではVNIC1個のみをサポートします。
Oracle Compute Infrastructure - Launching an Instance
https://docs.us-phoenix-1.oraclecloud.com/Content/Compute/Tasks/launchinginstance.htm
Bare Metal Shapes
https://cloud.oracle.com/infrastructure/compute/bare-metal/features
VM Shapes
https://cloud.oracle.com/en_US/infrastructure/compute/virtual-machine/features

Requirements

  • Oracle Linux 7.xを実行する仮想マシンインスタンス(KVMをサポートしている限り、他のLinuxディストリビューションも使用できます)
  • サード・パーティのアプリケーション・ライセンスをOracle Cloud Infrastructureに持ち込む場合、KVM Server Instance上で使用しているサード・パーティのOS/アプリケーション・ベンダーとのライセンス義務を負います
  • ゲストVMのインストールのために、KVM VM OSのISOファイルをKVMサーバインスタンスにアップロードする必要があります
  • 追加のブロックストレージボリュームをNested KVM Serverインスタンスに接続し、KVM VM qcow2ディスクイメージファイルを保持することを推奨します。また、KVM VM qcow2ディスクイメージファイル用に、iSCSIブロックストレージをアタッチせず、NVMeディスク付きのVM.DenseIOシェイプも利用できます。

Installing KVM

KVMハイパーバイザー用に利用する仮想マシンをプロビジョニング後、以下のコマンドを実行して最新のqemuパッケージをvirt-managerと共にインストールします。
$ sudo yum -y install qemu-kvm qemu-img virt-manager libvirt libvirt-python libvirt-client virt-install virt-viewer

Installing VNC and Xorg packages for GUI Remote Connection

以下のコマンドを実行して、VNCとXorgパッケージをインストールします。これらのパッケージを使って仮想マシンのGUIを使ってKVMゲストを管理できます。
$ sudo yum groupinstall "Server with GUI" -y

$ sudo yum install xorg-x11-xauth xorg-x11-fonts-* xorg-x11-utils tigervnc-server -y
vncserver@.serviceを vncserver@:1.serviceにコピーします。
$ cd /lib/systemd/system

$ sudo cp vncserver@.service vncserver@:1.service

$ sudo vi vncserver\@\:1.service
vncserver@1.service のをユーザー名 "opc" に置き換え、vncserver@.serviceで定義済みのopcユーザー用のVNCパスワードを設定します。
### run the following command as opc user

$ vncpasswd

Password:

Verify:

$ exit
VNC接続を許可するようfirewallサービスを構成します。
$ sudo firewall-cmd --permanent --zone=public --add-service vnc-server
再起動時に自動起動するようにVNCサービスを有効化します。
$ sudo systemctl daemon-reload

$ sudo systemctl enable vncserver@:1.service

$ sudo systemctl start vncserver@:1.service

Preparing the KVM Server for IOMMU Passthrough and Nested Virtualization

Nested KVMサーバーを実行するには、まず仮想NICのパススルー(IOMMU)オプションを使用する機能を有効にした上で、Nested VMハイパーバイザーでNested KVMを有効化する必要があります。
How to assign devices with VT-d in KVM
https://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
Oracle Linux 7.xのNested KVM仮想マシンインスタンスでは、以下の操作をします。
### Backup Grub File

$ sudo cp /etc/default/grub /etc/default/grub.bck

### Edit grub and include the following opitons

$ sudo vi /etc/default/grub

### Append the following parameters in GRUB_CMDLINE_LINUX line

intel_iommu=on  kvm-intel.nested=1

### Below is an example of how grub file should look like:

$ sudo cat /etc/default/grub |grep CMDLINE

GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 ip=dhcp netroot=iscsi:169.254.0.2::::iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 intel_iommu=on kvm-intel.nested=1"
保存してviを終了してから、以下のコマンドを実行します。
### Enable tuned

$ sudo systemctl enable tuned

$ sudo systemctl start tuned

$ sudo tuned-adm profile virtual-host

### Recreate grub to validate all the changes

$ sudo cp /boot/efi/EFI/redhat/grub.cfg /boot/efi/EFI/redhat/grub.cfg.orig

$ sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Using the OCIコンソールを使い、仮想クラウドネットワークセキュリティリストを編集し、(利用中のVNCで使っているポートが5901/tcpである場合)5901/tcpを有効化します。環境に応じてVNCポート番号を変更してください。
Source: 0.0.0.0/0

IP Protocol: TCP

Source Port Range: All

Destination Port Range: 5901

Allows: TCP traffic for ports: 5901
OCI Nested KVM VMインスタンスを再起動して、KVMカーネルモジュール、VNCおよびXorgサービスをロードします。 VMがオンラインに戻ったら、vncviewerのようなVNCアプリケーションを使用してKVM VMハイパーバイザーインスタンスに接続します。
RealVNC Viewer
https://www.realvnc.com/en/download/viewer/
Screen Shot 2017-08-04 at 4.28.09 PM.png

Creating an Oracle Cloud Infrastructure Secondary vNIC

続いてセカンダリvNICを作成し、それをKVM Nested VMインスタンスにアタッチします。このセカンダリvNICは、Nested VMゲストで使用します。OCIダッシュボードを使って、KVM Nested VMインスタンスの詳細をクリックし、[Attached vNIC]を選択し、[Create vNIC]をクリックします。以下の例では、アベイラビリティ・ドメイン1(AD1)でNew-BM-172と呼ばれるVirtual Cloud Network(VCN)を使用しています。

vNIC作成後、以下のような表示が出ます。後で使用するため、MACアドレスとIPアドレス情報を覚えておいてください。
Screen Shot 2017-10-04 at 10.44.13 AM.png

Associating OCI Secondary vNIC with the KVM Guest VM

ゲストをインストールする前に、KVM VM Hypervisorで以下のコマンドを実行します。
$ sudo ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 00:00:17:01:16:5d brd ff:ff:ff:ff:ff:ff

3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 00:00:17:01:ce:47 brd ff:ff:ff:ff:ff:ff

4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT

    link/ether 52:54:00:40:76:12 brd ff:ff:ff:ff:ff:ff

5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT qlen 500

    link/ether 52:54:00:40:76:12 brd ff:ff:ff:ff:ff:ff
以前の手順で作成したOCIセカンダリvNIC MACアドレスに一致するインターフェイスを特定します。上記のように、インタフェースens4は、KVMゲストのインストールプロセスで使用するインタフェースです。次の手順でKVMゲストVMをプロビジョニングし、上記のvNIC情報を追加します。

Creating a KVM guest instance

コマンドラインまたはグラフィカルツールでKVMを管理できますが、ここでは、GUIツールを中心に説明します。VNCを使用してOCI KVM Hypervisorインスタンスに接続し、gnome-terminalを開いて次のコマンドを実行します。
$ sudo virt-manager
virt-managerを初めて実行する場合、ローカルのQEMU/KVM接続を作成する必要があります。作成完了後、"Create a new Virtual Machine"ボタンをクリックし、図のように必要なオプションに従います。Requirementsの章に記載の通り、OSファイルはまずKVM Nested VMにアップロードする必要があります。SCPコマンドライン(MacまたはLinuxワークステーション)またはwinscp(Windowsワークステーション )を使うなどの方法でアップロードします。OS ISOファイルのアップロードが終了したら、KVM Guestのインストールプロセスを続行します。
Oracle® Linux Administrator's Guide for Release 7
Using scp and sftp to Copy Files Between Systems
https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-s9-openssh.html
WinSCP - Uploading Files
https://winscp.net/eng/docs/task_upload

1- KVM Guestインストールを選択
Screen Shot 2017-08-04 at 4.42.27 PM.png

2- セットアップに基づく情報を選択


3- KVMゲストVM上で利用するサービスワークロードに基づいてメモリやCPU設定を選択


4- ストレージのサイズおよび場所を設定


5- "Customize Configuration before install"を選択していることを確認して、finishをクリック


6- virt-managerのゲスト作成プロセスで追加されたデフォルトのNICをクリックしてPassthrough(パススルー)に変更し、識別したOCIセカンダリvNIC MACアドレスを正しいネットワークインターフェイス名(つまりens4)と一緒に追加します。
Screen Shot 2017-10-04 at 11.15.09 AM.png
7- "Apply"をクリックして"Begin Installation"ボタンをクリックしてからは、通常のOSインストールプロセスに従います。

(注意)インストール中またはインストール後にネットワーク情報を追加する必要があるため、ネットワーク構成として静的IP(上記で作成したセカンダリvNICに基づくIP情報を使用)とDNS(サーバーと検索ドメインオプション)、ゲートウェイIPを設定することをお忘れなく。
Screen Shot 2017-10-04 at 11.19.37 AM.png

Additional Security Recommendations

  • SSHパスワード認証を無効にし、SSH鍵認証を有効にする(/home/opc/.ssh/authorized_keysファイルにssh公開鍵を追加)
  • KVMゲストファイアウォールを有効にしておき、必要なポートだけを開ける
  • KVMゲストVMに定期的にパッチを適用する
  • 可能であればVPNを使用する
  • VNCポートをブロックしたままにし、 "ssh -L"(SSHポートフォワード)を使用して、OCI Nested KVM VMハイパーバイザーとローカルホスト間にトンネルを作成し、暗号化されたチャネルを介してVNCを使用できるようにする

Conclusion

Oracle Cloud InfrastructureでNested KVMハイパーバイザーを設定する方法を説明しました。これは、旧バージョンのKVM上で実行中のアプリケーションに対処したり、オンプレミスのインフラストラクチャコストを削減して、KVM環境をクラウドに移行するのに最適な方法です。Oracle Cloud Infrastructureは、仮想マシンやベアメタル・シェイプ上で直接実行するための完全なKVMサポートを備えていますし、別のユースケースには、既存のKVM環境の移行および管理においてRavelloも適しています。
Ravello Service - Oracle Cloud
https://cloud.oracle.com/ja_JP/ravello

[Database, Integration] Oracle Databaseのプロキシ認証をJCA Adapter for Databaseから利用する

この内容はJPOUG Advent Calendar 2017の12月23日版です。
JPOUG Advent Calendar 2017
https://jpoug.doorkeeper.jp/events/67051
12月22日は@mogmetさんの「まだbondingで消耗しているの?HAIPでインターコネクト冗長化の時代が来たよ!」でした。
まだbondingで消耗しているの?HAIPでインターコネクト冗長化の時代が来たよ!
http://blog.mogmet.com/oracle-interconnect-haip/ 
今日は、Oracle Databaseのプロキシ認証をOracle SOA Suiteで利用可能なOracle JCA Adapter for Databaseでも利用可能、というお話です(本当ならコンテナ関連の話にしたかったのですが、イケメン敏腕エバンジェリストのチェックが厳しいので、やめておきますw)。

背景

プロキシ認証を多用されているOracle Databaseユーザーから、「JDBCドライバではプロキシ認証サポートしているけど、Oracle SOA Suite/Service Busで利用できるOracle JCA Adapter for Databaseではサポートしているの?」という問い合わせを受けました。ドキュメントにもサポートしていると明記されているので、「Yes」で終わりなのですが、「本当なの?」という疑いの眼差しが刺さったことでちょいとお手伝いしました。
JCA Adapter for DatabaseはオンプレミスのSOA Suite/Service Busだけでなく、SOA Cloud Serviceでもご利用いただけます。設定はドキュメントに記載があるので、ドキュメントに沿って実施するだけです。
Oracle® Fusion Middlewareテクノロジ・アダプタの理解 12c (12.2.1.2.0)
プロキシ認証のサポート
https://docs.oracle.com/cd/E84527_01/adapters/develop-soa-adapters/GUID-B03AD33F-2383-4E53-BF58-09D284CDDE97.htm#GUID-11B2D79B-714A-43EA-97D0-3AD64A0C7DFD
Oracle® Fusion Middleware Understanding Technology Adapters 12c (12.2.1.3.0)
Proxy Authentication Support
https://docs.oracle.com/middleware/12213/adapters/develop-soa-adapters/overview7.htm#TKADP1337
JDBCドライバのドキュメントでのプロキシ認証に関する記述はこちら。
Oracle® Database JDBC開発者ガイド 12cリリース2 (12.2)
プロキシ認証
https://docs.oracle.com/cd/E82638_01/JJDBC/proxy-authentication.htm
Oracle® Database JDBC Developer's Guide 12c Release 2 (12.2)
Proxy Authentication
https://docs.oracle.com/database/121/JJDBC/proxya.htm#JJDBC28352 

データベースの設定


前提として、Databaseにはuser1、user2というユーザーが存在し、user1、user2には同じ名前、同じ構成の表があるものとします(今回はSHIPという表を使いますが、特に意味はありません)。
SHIPはこんな感じの表です。
名前                NULL?     型
------------------ --------- ---------------
ORDERID            NOT NULL  VARCHAR2(100)
STATUS                       VARCHAR2(100)
CREATEDDATE                  DATE
UPDATEDDATE                  DATE
ISCHECKED          NOT NULL  VARCHAR2(1)
その上で、プロキシユーザーproxy_user1を作成します。権限は最小限のものを付与します。
CREATE USER proxy_user1 IDENTIFIED BY welcome1;
GRANT CONNECT, RESOURCE, CREATE ANY DIRECTORY, DROP ANY DIRECTORY TO proxy_user1;
プロキシユーザーにuser1、user2として接続できるよう権限を付与します。今回は簡単のため、ロールは使いませんでしたが、単にユーザーだけで通すのはよろしくないので、パスワードで認証するようにしました(証明書を使った認証も可能です)。
ALTER USER user1 GRANT CONNECT THROUGH proxy_user1 authenticated using password;
ALTER USER user2 GRANT CONNECT THROUGH proxy_user1 authenticated using password;
これでデータベース側の設定は終わりです。

Application Serverの設定

データソースとJCA Adapter for Databaseの設定が必要です。

1) データソースの作成
WebLogic Server管理コンソールに管理者としてログインし、ドメイン>サービス>データ・ソースとたどり、データソースを作成します。今回は汎用データ・ソースを選択しています。Database接続ユーザーはproxy_user1を使うことにご注意ください。


2)JCA Adapter for Databaseの設定
WebLogic Server管理コンソールで、ドメイン>デプロイメントを開き、DbAdapterをクリック、[構成]>[アウトバウンド接続プール]をクリックして[新規]を押し、新規アウトバウンド接続プールを作成します。プロパティのDataSourceName(XAドライバを使っている場合にはXADataSourceName)にデータソースのJNDI名を指定します。以下は設定例です。

Adapterの設定が終了すると、再デプロイするように求められるので、更新しておきましょう。
これでApplication Serverの設定は終了です。

JCA Adapter利用時の設定

今回は、Oracle Service BusでJCA Adapter for Databaseを構成しました(SOA Infraを選ばなかった深い理由はありません)。処理自体は非常にシンプルで、キーであるORDERIDを使って表のレコードを取得する、というものです。SOAPだけだと面白くないのでRESTでも呼べるようにしています。

プロキシユーザーのままアクセスするわけにはいかないので、実際のユーザーとパスワードを指定する必要があります。ルーティングのリクエスト・アクションに[トランスポート・ヘッダー]アクティビティを配置し、
jca.db.ProxyUserName
jca.db.ProxyPassword 
という2個のプロパティにそれぞれユーザーとパスワードを指定します。今回は簡単のためにリテラルで指定していますが、実際にはHTTPヘッダーやリクエストメッセージ中に含めて渡すことになるでしょうし、エラー処理も全く入れていないので、実運用時にはエラーハンドラを設定する必要があります。

設定が終わればデプロイします。これでOracle Service Busでの設定は終了です。

試してみる

では、試してみます。まず、USER1でSHIP表の内容を(みんな大好き)SQL*Plusで確認します。
SQL> select * from ship;

ORDERID           STATUS        CREATEDD UPDATEDD I
----------------- ------------- -------- -------- -
P0001             COMPLETED     17-12-19 17-12-19 C
AX0001            STARTED       17-12-19 17-12-19 C
A0001             STARTED       17-12-19 17-12-19 C
USER2のSHIP表はこんな感じ。
SQL> select * from ship;

ORDERID           STATUS        CREATEDD UPDATEDD I
----------------- ------------- -------- -------- -
AX0001            COMPLETED     17-12-22 17-12-22 C
先ほどのService Busで作成したRESTサービスでデータを呼び出します。ORDERIDはAX0001を使うことにしましょう。user1ならSTARTEDが出てくるはずです。

user2の場合は、STATUSはCOMPLETEDで、日付が違うはずです。
 user2のパスワードを間違えて指定した場合、当然ながらエラーになってしまいます。Web APIとして利用するなら、当然エラー処理をして素のエラーメッセージを隠し、わかりやすいエラーメッセージに変更する必要があります。

まとめ

ドキュメントに記載の通り、JCA Adapter for Databaseでも問題なくプロキシ認証が動作することがわかりました。この機能を実際のシステムで使うかどうかはよくわかりませんが…。
なお、Oracle Integration CloudのIntegration(旧Integration Cloud Service)にもOracle Database Adapterがありますが、こちらではプロキシ認証はサポートされていませんのでご注意ください。

明日(2017/12/24) は吉田もとたか@OracleACEさんです。それでは、Happy Holiday!

[misc.] Tech Deep Dive #0

先日(2017/12/20)Tech Deep Dive #0を開催しました(#0の理由は、#1だと次が無いときに格好悪いからです。#0で終わると、1回もやってないって嘯くことができますw)。

たくさんの方にご参加いただきました。ありがとうございました。Wi-Fiの調子が悪くて申し訳ありませんでした。#0では、 @chiroito さんによる、「Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか」でした。「キャッシュは麻薬」は名言でしたね。 @chiroito さんありがとうございました。
@yamadamn さんがTogetterにも纏めてくださっています。ありがとうございます!
Tech Deep Dive #0 #oratdd (Togetter)
https://togetter.com/li/1182047
セッションスライドならびにセッション内で紹介したアプリケーション等のソースコードは既に公開済みです。
ソースコード
https://github.com/chiroito/High-Performance-WebApplication

イベントのコンセプト

上記ページにも記載している通りで、アプリケーション開発者向けの勉強会では新技術をテーマにしたものは多いのですが、それだと某サイトのように「○●やってみた」レベルで終わってしまうことになりかねず、「面白かったけど、で、どこで役立つの?」ってことに陥ったり、単なる製品紹介+デモだとつまらないな、と思いまして、
  • 今現場で必要とされているテクノロジーの話で、入門編ではない、もっと深い濃い話ができる場があればいいなー
  • ケーススタディを基に、システム全体を俯瞰した設計や実装について議論できる場があればいいなー
  • 要素技術についてとことん濃い話をする場があるといいなー 
って考えて企画しました(あと、ロジ子は裏方に徹し、基本前説するぐらいのアシスタントディレクター、ってのも重要なお約束です)。

# 他社だとこういう類いのイベントはあるのですが、弊社だとあまりなかったので、かなり実験的な企画だった、というのは内緒。

今後どうするの

#0のアンケートの結果、非常に好評でした。偏に @chiroito さまのおかげでございます(ありがたやありがたや)。なんとか#1を開催できそうです(これが一番うれしい!)。

Tech Deep Diveで取り扱う技術領域は制限していませんが、(個人的な興味関心とアンケート結果から)ミドルウェアの視点からみたアーキテクチャやJava、コンテナ、ストリーム処理などの話が多くなるのでは、と見ています。システム連携のあれこれやAPI Management、BlockChainなどもテーマにするかもしれません。種々のナイトセミナーのコンテンツと被らないよう調整しながら、2ヶ月に1回を目安に開催する予定です。

# データベースを取り扱うことも吝かではありませんが、既にTech Nightというイベントが継続開催されていますし、社内ではステルス性を発揮しまくるロジ子がしばちょーさんやゆっきー、みなみんといった有名人に近づくのは畏れ多くてそりゃあもう…。

あと、東京以外でご要望の多い地域に訪問して開催することを検討しています。既に以下のアンケートをご覧になったり、回答された方もいらっしゃるかもしれませんが、興味を持ってくださった方のうち、まだ回答されていない場合には、是非ご意見をお寄せください。

#1のテーマを何にするか決めるところが結構大変なのですが、是非次回以後もご興味あるトピックであればご参加ください!

[Docker, Linux] Announcing Oracle Container Services 1.1.8 for use with Kubernetes

原文はこちら。
https://blogs.oracle.com/linux/announcing-oracle-container-services-118-for-use-with-kubernetes

OracleはOracle Container Servicesが新しいCertified Kubernetes Conformanceプログラムを通ったことを発表できうれしく思っています。
Cloud Native Computing Foundation Launches Certified Kubernetes Program with 32 Conformant Distributions and Platforms
https://www.cncf.io/announcement/2017/11/13/cloud-native-computing-foundation-launches-certified-kubernetes-program-32-conformant-distributions-platforms/
"The new Certified Kubernetes Conformance Program gives enterprise organizations the confidence that workloads that run on any Certified Kubernetes Distribution or Platform will work correctly on any other version," said Dan Kohn, Executive Director, Cloud Native Computing Foundation. "The interoperability that this program ensures is essential to Kubernetes meeting its promise of offering a single open source software stack supported by many vendors that can deploy on any public, private or hybrid cloud."

(Cloud Native Computing FoundationのExecutive DirectorであるDan Kohnは次のように述べています。「このCertified Kubernetes Conformance Programは、エンタープライズ企業に対し、Certified Kubernetes DistributionまたはPlatform上で動作するワークロードが他のバージョンでも正常に動作するというお墨付きを与えます。このプログラムが保証する互換性は、Kubernetesがパブリック、プライベート、またはハイブリッドクラウドにデプロイ可能な、多くのベンダーがサポートする単一のオープンソースソフトウェアスタック提供の約束を果たすために不可欠なものです」)

Release Information

Oracle Container Services 1.1.8 for use with Kubernetesは、アップストリームでリリースされたKubernetesバージョン1.8.4に基づいています。これはOracle Linux 7で使用でき、Oracleが提供およびサポートするOracle Container Runtime for Dockerと統合するように設計されています。Oracle Container Services for use with Kubernetesは一連のDockerコンテナで実行され、これらのイメージはOracle Container Registryから入手できます。
Oracle Container Registry
https://container-registry.oracle.com/

Oracleでは、kubeadm-setup.sh(クラスタ構成ユーティリティ)を利用するセットアップおよび構成スクリプトを用意しています。このスクリプトを使用すると、ネットワーク、ファイアウォール、プロキシ、初期クラスタの構成、バックアップとリカバリのサポートの追加といったOracle Linuxの設定が簡単になります。

Notable updates from the previous release


Oracle Container Services 1.1.8 for use with Kubernetesは、アップストリームのKubernetes 1.8.4ベースで、Kubernetes Dashboardを含んでいます。

Installation and Update


Oracle Container Services 1.1.8 for use with Kubernetesは、Oracle Linux Yum Serverから無料でダウンロードできます。お客様は、Oracle Linux Yum ServerやOracle Unbreakable Linux NetworkでリリースされているOracle Container Serviceの最新アップデートの使用をお勧めします。標準のyum updateコマンドを使用してアップグレードを実行できます。
Oracle Linux Yum Server
http://yum.oracle.com/
Unbreakable Linux Network
https://linux.oracle.com/ 
Oracle Container Services for use with Kubernetesのインストールや構成方法に関する詳細情報はユーザーガイドをご覧ください。
Oracle® Container Services for use with Kubernetes User's Guide
https://docs.oracle.com/cd/E52668_01/E88884/html/index.html

Resources – Oracle Linux

Documentation

Software Download

Blogs

Community Pages

Social Media

Data Sheets, White Papers, Videos, Training, Support & more

Product Training and Education


コミュニティ・ベースのサポートをお求めの場合、Oracle Technology Network CommunityのOracle Linuxスペースにアクセスしてください。
Space - Oracle Linux
https://community.oracle.com/community/server_&_storage_systems/linux/oracle_linux
Oracle Technology Network Community
https://community.oracle.com/welcome

[WLS] Customize your ZDT Patching Workflows Using “Hooks”

原文はこちら。
https://blogs.oracle.com/weblogicserver/customize-your-zdt-patching-workflows-using-%E2%80%9Chooks%E2%80%9D

WebLogic Server 12.2.1.3.0で、事前定義済みの場所(拡張ポイント)でフックされ得るユーザー定義のスクリプトを追加することで、既存のパッチ適用ワークフローのロジックを拡張できるという、ZDT Patchingの新機能が利用できるようになりました。これらのユーザー定義スクリプト(extensionとしても知られます)をワークフローとともに実行します。
このカスタムフック機能を使うと、ビジネス要件に固有ではあるものの、基礎のパッチ適用ワークフローに含めるには適切でない任意の追加タスクをワークフローで実行できます。ワークフローの各ノードにチェックを追加して、Oracle Homeのロールアウトに十分なディスク・スペースがあることを確認したり、追加のアプリケーションのデプロイや再デプロイといった管理タスクをワークフローで実行したり、カスタム・ロジックを定義して電子メールでアップグレードの状況を通知するしたり、といったことができます。

この機能では、カスタムスクリプトやリソースを挿入できる、マルチテナントおよび非マルチテナントワークフローのための7個の拡張ポイントを提供します。カスタムフックを実装して、任意のパッチ適用ワークフローを簡単な5ステップで変更しましょう。
  1. 利用可能な事前定義済み拡張ポイントのリストの中から、extension(これは拡張ロジックに他なりません)を実装したいワークフロー内の拡張ポイントを決定します。拡張ポイントは、ワークフローのさまざまなステージで使用できます。例えば、ep_OnlineBeforeUpdateを使用して、各ノードでパッチ適用の処理が始まる前に任意のロジックを実行できます。このep_OnlineBeforeUpdateは、通常、前提条件チェックを実行可能な拡張ポイントです。マルチテナントおよび非マルチテナントワークフローで利用可能な拡張ポイントの完全なリストは、以下のドキュメントをご覧ください。
    Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1.3.0)
    About Extension Points
    https://docs.oracle.com/middleware/12213/wls/WLZDT/customhooks.htm#WLZDT-GUID-FA78C4FC-BB5C-4C3D-A0EE-14FB3AEA685E
  2. 拡張スクリプトを作成してカスタムロジックを定義します。このスクリプトは、UNIXのシェルスクリプトもしくはWindowsのバッチスクリプトです。必要に応じて、スクリプトでこの機能が提供する定義済みの環境変数を使用できます。
  3. extensionConfiguration.json ファイルにextensionを指定します。しかし、この機能を使うと、指定extensionを複数の方法で指定できるため、様々なレベルで柔軟にパラメータのオーバーライドやカスタマイズが可能です。これらのオプションの詳細配下のドキュメントをご覧ください。
    Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1.3.0)
    Specifying Extensions to Modify the Workflow
    https://docs.oracle.com/middleware/12213/wls/WLZDT/customhooks.htm#WLZDT-GUID-04D475B0-DAF4-4140-A417-26F54B55048B
  4. extensionConfiguration.jsonファイルを作成し、拡張スクリプトにカスタムロジックを定義したら、それらを特定のディレクトリ構造を持つJARファイルにパッケージする必要があります。extensionのJARファイルのディレクトリ構造は、ドキュメントに記載があります。この時点で、ロールアウトの前に全ノードにパッチ適用されたOracleホームが配置されるのと類似の方法で、extension JARファイルが全ノードに配置されることを覚えておいてください。
  5. WLSTもしくはWebLogic Server管理コンソールを使ってワークフローを構成し、アップデートのために作成したJARファイルの名前を指定します。
利用可能な拡張ポイントの完全な詳細や、カスタムフック機能の利用方法は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1.3.0)
Modifying Workflows Using Custom Hooks
https://docs.oracle.com/middleware/12213/wls/WLZDT/customhooks.htm#WLZDT-GUID-FA78C4FC-BB5C-4C3D-A0EE-14FB3AEA685E

[Docker, WLS] Docker Volumes in WebLogic

原文はこちら。
https://blogs.oracle.com/weblogicserver/docker-volumes-in-weblogic

Background Information

Dockerの世界では、コンテナは一時的(ephemeral)なものです。コンテナは破棄され、交換できます。コンテナ破棄後、コンテナに加えられたすべての変更はなくなります。コンテナのライフサイクルとは独立してデータを保持したい場合は、ボリュームを使用する必要があります。ボリュームは、コンテナファイルシステムの外部に存在するディレクトリです。

Docker Data Volume Introduction

このエントリでは、Dockerデータボリュームの概要を紹介します。なお、WebLogic Server 12.2.1.3イメージに基づいて記載しています。githubにあるスクリプトを使用してイメージを構築できます。
Oracle WebLogic Server on Docker
https://github.com/oracle/docker-images/tree/master/OracleWebLogic/dockerfiles/12.2.1.3
このエントリでは、この基本イメージをデータボリュームの使用方法を説明するためにのみ使用し、WebLogic Serverインスタンスは実際には実行しません。その代わりに、'sleep 3600' でコンテナは6分間稼働させた後に停止します。

Local Data Volumes

Anonymous Data Volumes

匿名データボリューム(anonymous data volume)は、(名前がないとはいえ)一意の名前が内部で自動生成されています。
以下の2方法で匿名データボリュームを作成できます。
  • '-v /container/fs/path'
    オプションを付けて
    docker create
    もしくは
    docker run
    でコンテナを作成もしくは開始する。
  • Dockerfile内でVOLUME命令を使う
    VOLUME ["/container/fs/path"]
$ docker run --name c1 -v /mydata -d weblogic-12.2.1.3-developer 'sleep 3600'
$ docker inspect c1 | grep Mounts -A 10
[        "Mounts": [
            {
                "Name": "625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421",
                "Source": "/scratch/docker/volumes/625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421/_data",
                "Destination": "/mydata",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],
# ここでボリュームにランダムに生成された名前が付いていることがわかります。
625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421
$ docker volume inspect 625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421
[
    {
        "Name": "625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421",
        "Driver": "local",
        "Mountpoint": "/scratch/docker/volumes/625672972c137c2e29b85f1e6ae70d6d4eb756002062792721a5ac0e9d0f1421/_data",
        "Labels": null,
        "Scope": "local"
    }
]     

Named Data Volumes

名前付きデータボリューム(Named data volumes)はDocker 1.9.0以後で利用できます。
名前付きデータボリュームは以下の2方法で作成できます。
  • docker volume create --name volume_name
    を使う
  • -v volume_name:/container/fs/path
    を付けて、
    docker create
    もしくは
    docker run
    でコンテナを生成もしくは実行する
$ docker volume create --name testv1
$ docker volume inspect testv1
[
    {
        "Name": "testv1",
        "Driver": "local",
        "Mountpoint": "/scratch/docker/volumes/testv1/_data",
        "Labels": {},
        "Scope": "local"
    }
]

Mount Host Directory or File

既存のホストディレクトリをコンテナに直接マウントできます。
コンテナ稼働中にホストを直接マウントするには
  • docker create もしくは docker runで
    -v /host/path:/container/path
    を付けてコンテナを作成もしくは実行する
同様の方法でホストのファイルをマウントできます。
  • docker create もしくは docker runで
    -v /host/file:/container/file
    を付けてコンテナを作成もしくは実行する
マウントされたホストディレクトリやファイルはDockerが管理している実際のデータボリュームではないため、docker volume lsを実行しても表示されないこと、また、Dockerfileでホストディレクトリやファイルをマウント出来ないことにご注意ください。
$ docker run --name c2 -v /home/data:/mydata -d weblogic-12.2.1.3-developer 'sleep 3600'
$ docker inspect c2 | grep Mounts -A 8
"Mounts": [
            {
                "Source": "/home/data",
                "Destination": "/mydata",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],

Data Volume Containers

データボリュームコンテナはデータ専用コンテナです。データボリュームコンテナが作成後、そのコンテナを起動する必要はありません。他のコンテナは--volumes-fromを使用して共有データにアクセスできます。
# step 1: create a data volume container 'vdata' with two anonymous volumes
$ docker create -v /vv/v1 -v /vv/v2 --name vdata weblogic-12.2.1.3-developer 

# step 2: run two containers c3 and c4 with reference to the data volume container vdata
$ docker run --name c3 --volumes-from vdata -d weblogic-12.2.1.3-developer 'sleep 3600'
$ docker run --name c4 --volumes-from vdata -d weblogic-12.2.1.3-developer 'sleep 3600'

Data Volume Plugins

Docker 1.8以降では、ボリュームプラグインをサポートしています。これにより、新しいボリュームドライバでDockerを拡張できます。例えばボリュームプラグインを使用して、iSCSI、NFS、FCなどの共有ストレージサーバーにリモートフォルダを直接マウントできます。別のホストで動作している別のコンテナから同じストレージに同じ方法でアクセスできます。 異なるホストのコンテナが同じデータを共有できます。
さまざまなストレージタイプに対応したプラグインがあります。ボリュームプラグインについては、以下のDockerのドキュメントを参照してください。
Volume plugins
https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins

WebLogic Persistence in Volumes

WebLogic ServerをDockerで実行する場合、データボリュームの利用にあたって基本的に2つのユースケースがあります。
  1. WebLogic Serverのライフサイクルからデータを分離するため、WebLogic Serverコンテナが破棄され、後で再起動または移動された後でもデータを再利用可能
  2. 異なるWebLogic Serverインスタンス間でデータを共有するため、(サービス移行時に)必要に応じて相互のデータを復元可能
以下のWebLogic Serverのアーティファクトでデータボリュームの利用が考えられます。
  • ドメインホーム・ディレクトリ
  • サーバーログ
  • JMSやJTAなどの永続ファイルストア
  • アプリケーション・デプロイメント
下表にWebLogic Serverのサブシステムが格納するデータを纏めました。
Subsystem or Service 格納されているもの 詳細情報
Diagnostic Service ログレコード
データイベント
収集されたメトリック
Understanding WLDF Configuration (Configuring and Using the Diagnostics Framework for Oracle WebLogic Server
JMS Messages 永続メッセージと恒久サブスクライバ Understanding the Messaging Models (Developing JMS Applications for Oracle WebLogic Server
JMS Paging Store JMSサーバごとに1個
永続メッセージと非永続メッセージをページング
Main Steps for Configuring Basic JMS System Resources (Administering JMS Resources for Oracle WebLogic Server
JTA Transaction Log (TLOG) 完了していない可能性がある、サーバーがコーディネートしたコミット済みトランザクションに関する情報
TLOGはデフォルトの永続ストアまたはJDBC TLOGストアに格納可能
Managing Transactions (Developing JTA Applications for Oracle WebLogic Server
Using a JDBC TLog Store (Developing JTA Applications for Oracle WebLogic Server)
    Path Service メッセージ・リソースへのメッセージ・グループのマッピング Using the WebLogic Path Service (Administering JMS Resources for Oracle WebLogic Server
    Store-and-Forward (SAF) Service Agents 受信SAFエージェントへの再送信のための送信SAFエージェントからのメッセージ Understanding the Store-and-Forward Service (Administering the Store-and-Forward Service for Oracle WebLogic Server
    Web Services 信頼性のあるWebLogic Web Serviceの呼び出しによるリクエストおよびレスポンスSOAPメッセージ Using Reliable SOAP Messaging (Programming Advanced Features of JAX-RPC Web Services for Oracle WebLogic Server
    EJB Timer Services EJBタイマーオブジェクト Understanding Enterprise JavaBeans (Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server
    WebLogic Serverの各インスタンスをそれぞれのコンテナで実行し、データボリューム内のドメイン構成を共有することをお勧めします。これは、WebLogic Serverでのデータボリュームの基本的な使用例です。ドメインホームが外部ボリュームにある場合、サーバーログもまた既定で外部ボリュームにあります。ただ、サーバーログにはドメインホーム内の他のファイルよりも機密性の高いデータが含まれており、アクセス管理を必要とするため、サーバーログを別のボリュームに配置するよう明示的に構成可能です。
    JMSやJTAなどのファイルストアは、外部ボリュームに配置し、共有ディレクトリを使用する必要があります。これは、サービス移行を機能させるためです。インスタンス毎に自動的にファイル名を一意に装飾するため、同一ドメイン内のすべてのデフォルトストアとカスタムストアで同じ共有ディレクトリを使用できます。しかし異なるドメインの場合、ファイル名が衝突する可能性があるため、同じディレクトリの場所を共有できません。同様に、2つの実行中の重複ドメインは、同じディレクトリの場所を共有できません。ファイルが衝突すると、通常はファイルロックエラーが発生し、その結果データが破損する可能性があります。
    ファイルストアは、さまざまな目的のために多数のファイルを作成します。 キャッシュファイルとページングファイルは、コンテナファイルシステムにローカルに格納できます。種々のファイルと場所の詳細については、次の表を参照してください。
    ストアのタイプ ディレクトリ構成 未構成のストア・パス 相対ストア・パス 絶対ストア・パス ファイル名
    default WebLogic Serverデフォルトストア上に構成されたディレクトリ(Using the Default Persistent Storeを参照) <domainRoot>/servers/<serverName>/data/store/default <domainRoot>/<relPath> <absPath> _WLS_<serverName>NNNNNN.DAT
    custom file カスタムファイルストア上に構成されたディレクトリ(Using Custom File Storesを参照) <domainRoot>/servers/<serverName>/data/store/<storeName> <domainRoot>/<relPath> <absPath> <storeName>NNNNNN.DAT
    cache DirectWriteWithCache同期書き込みポリシーを持つデフォルトもしくはカスタムファイルストア上に構成されたキャッシュディレクトリ(Tuning Performance of Oracle WebLogic Serverの Tuning the WebLogic Persistent Store を参照) ${java.io.tmpdir}/WLStoreCache/${domainName}/<storeUuid> <domainRoot>/<relPath> <absPath> <storeName>NNNNNN.CACHE
    paging The paging directory configured on a SAFエージェントもしくはJMSサーバ上に構成されたページング・ディレクトリ(Tuning Performance of Oracle WebLogic Serverの Paging Out Messages To Free Up Memory を参照) <domainRoot>/servers/<serverName>/tmp <domainRoot>/<relPath> <absPath> <jmsServerName>NNNNNN.TMP
    <safAgentName>NNNNNN.TMP
    外部ボリューム内のデータを適切に保護するためには、管理者の責任でこれらのディレクトリに対して適切な権限を設定する必要があります。WebLogic Serverプロセスがボリューム内のデータにアクセスできるようにするには、コンテナを実行しているユーザがボリュームフォルダへの適切なアクセス権を持っている必要があります。

    Summary

    • ローカルボリュームの利用
      • Docker 1.8.x以前では、(匿名データボリュームを持つ)データボリューム・コンテナの利用を推奨
      • Docker 1.9.0以後では、名前付きデータボリュームの利用を推奨
      • 複数のボリュームを持つ場合、複数コンテナ間で共有するためには、名前付きデータボリュームを持つデータボリュームコンテナの利用を推奨
    • 異なるホスト間でデータを共有するためには、まず共有ストレージサーバのフォルダをマウントし、その後一つのボリュームプラグインを選択して、Dockerにマウントする
    WebLogic Serverドメインホームをデータボリュームに外出しすることをお勧めします。外出ししたドメインホームは、それぞれが独自のコンテナで実行されている管理サーバーと管理対象サーバーによって共有されている必要があります。高可用性を実現するには、すべての管理対象サーバーが共有データボリューム内のストアを読み書きする必要があります。選択されるデータボリュームの種類は、ストア、ログ、および診断ファイルの永続性を考慮して選択する必要があります。

    [Linux] Announcing the Unbreakable Enterprise Kernel Release 4 Update 6 for Oracle Linux

    原文はこちら。
    https://blogs.oracle.com/linux/announcing-the-unbreakable-enterprise-kernel-release-4-update-6-for-oracle-linux

    Oracle Linuxオペレーティングシステムはオープンなクラウドインフラストラクチャ向けに設計されており、従来のエンタープライズアプリケーションだけでなく、エンタープライズSaaSおよびPaaSワークロードにも優れたパフォーマンス、スケーラビリティ、信頼性を提供します。Oracle Linux Supportでは、受賞実績のあるOracleサポート・リソースやLinuxサポート・スペシャリスト、Kspliceを使用したゼロダウンタイムアップデート、Oracle Enterprise Managerなどの追加の管理ツール、およびライフタイム・サポートを低コストで提供します。また、他の多くの商用Linuxディストリビューションとは異なり、Oracle Linuxは簡単にダウンロードでき、完全に無料で使用、配布、および更新できます。

    What's New?

    Unbreakable Enterprise Kernel Release 4 Update 6では 4.1.12-112.14.1 を利用しており、さまざまなサブシステムにわたるいくつかの新機能、機能、バグ修正が含まれています。

    Notable changes

    • Automatic NUMA balancing is disabled by default
      このアップデートでは、NUMA(Non-uniform Memory Access)自動バランシングの自動有効化が無効になっています。この変更により、NUMAの自動分散が有効になっている複数のNUMAノードを持つシステムで発生したいくつかの問題が解決されます。報告された事象・症状には、D状態で監察された(Oracle DBプロセスのような)高いiowait時間と多数のプロセスがあり、これらがプロセススタック内でwait_on_page_bit()関数を動作させない状況になっていたものがありました。
    • Deferred compaction of Transparent Hugepages is enabled
      Transparent Huge Pages(THP)の遅延コンパクション機能がメインラインカーネルからバックポートされ、デフォルトのデフラグ動作がmadviseに設定されています。これにより、メモリ断片化が原因でTHPからのhuge pageのアロケーションに時間がかかる場合に、THPによってアプリケーションの停止が発生する可能性があるという問題を解決します。

    Crypto API

    • Addition of the ccp driver
      ccp ドライバによって、AMD Cryptographic Coprocessor(CCP)がサポートされます。AMD CCPにより、ハードウェア暗号化、ハッシュ生成やその他の関連する操作が利用可能になります。
    • Jitter entropy RNG added
      Jitter Entropy Random Number Generator (RNG) はLinuxカーネルとのCPU時間の差異によってCPUタイミングのエントロピーを収集する機能です。

    DTrace

    • I/O provider for NFS
      このアップデートで、NFSへのstartdonereadおよびwriteリクエスト用のDTrace I/Oプロバイダ・プローブが追加されました。 
    • lockstat provider added
      DTraceがlockstatをサポートしたことにより、カーネルのロックイベントの動的な追跡が可能になりました。これにはどのロックが最もよく使われるのか、どのロックが最も競合を示しているのか、どのロックが最も保持されているのか、といったものが含まれます。
    • Packaging changes
      Unbreakable Enterprise Kernel Release 4 Update 6のリリースから、dtrace-modulesdtrace-modules-provider-headersおよびdtrace-modules-shared-headersパッケージは配布されなくなりました。これらのパッケージが提供する機能は、現在、ベースのkernel-uekおよび関連するヘッダーパッケージに含まれています。
    上記の内容ならびにその他の新機能や変更点に関する詳細は、リリースノートをご覧ください。
    Oracle® Linux Release Notes for Unbreakable Enterprise Kernel Release 4 Update 6
    https://docs.oracle.com/cd/E37670_01/E92390/html/index.html 

    Supported upgrade path

    お客様は既存のOracle Linux 6およびOracle Linux 7サーバをUnbreakable Linux NetworkやOracle Linux Yum Serverを使ってアップグレードできます。
    Unbreakable Linux Network
    http://linux.oracle.com/
    Oracle Linux Yum Server
    http://yum.oracle.com/

    Software Download

    Oracle Linuxは無料でダウンロード、利用、配布できます。そして、全てのアップデートおよびエラータも無料でご利用いただけます。
    Oracle Linux
    http://www.oracle.com/linux
    Free Updates and Errata for Oracle Linux
    https://blogs.oracle.com/linux/free-updates-and-errata-for-oracle-linux
    https://orablogs-jp.blogspot.jp/2012/03/free-updates-and-errata-for-oracle.html 
    このしくみを利用して、どのシステムでサポートを契約するかを決定できますので、Oracle Linuxは開発、テスト、本番システムのための理想的な選択肢となることでしょう。
    Oracle Linux Support
    http://www.oracle.com/us/technologies/linux/support/overview/index.html
    すべてのシステムを最新かつ安全に保ちながら、サポート対象範囲をシステムごとに個別に最適なものに決めてください。Oracle Linux Premier Supportをご利用のお客様は、Oracle Kspliceを使用したゼロ・ダウンタイムのカーネル・アップデートやOracle OpenStackのサポートもご利用いただけます。
    Ksplice : Zero Downtime Updates for Oracle Linux
    http://www.oracle.com/us/technologies/linux/ksplice-datasheet-487388.pdf
    Oracle OpenStack Release 3
    http://www.oracle.com/technetwork/server-storage/openstack/linux/documentation/datasheet-oracle-openstack-2296038.pdf

    Compatibility

    UEK R4 Update 6は以前のUEK R4 Updateと完全な互換性があります。UEK R4のカーネルABIは初期リリースに続く全てのリリースで変わりません。このリリースでは、カーネルABIがUEK R3に対して変更があるため、システム上の3rdパーティーカーネルモジュールを再コンパイルする必要があります。Before installing UEK R4をインストールする前に、お使いのアプリケーションベンダーにサポート状況を確認してください。

    Resources – Oracle Linux

    Documentation

    Software Download

    Blogs

    Community Pages

    Social Media

    Data Sheets, White Papers, Videos, Training, Support & more

    Product Training and Education

    [Database] ODPI-C 2.1 is now available for all your Oracle Database Access Needs

    原文はこちら。
    https://blogs.oracle.com/opal/odpi-c-21-is-now-available-for-all-your-oracle-database-access-needs

    ODPI-C

    Anthony TuiningaがOracle Database Programming Interface for C (ODPI-C)のversion 2.1をGitHubにリリースしました。
    Oracle Database Programming Interface for Drivers and Applications
    https://github.com/oracle/odpi
    ODPI-Cは、C言語やC++言語で記述されたアプリケーションがOracle Databaseに簡単にアクセスできるように作成された、C言語用オープンソースライブラリです。
    主要な新機能:シャードされたデータベースへのアクセスをサポート
    以下はAnthonyのコメントです。
    このリリースでは、数ヶ月前にリリースされたversion 2.0 に対しいくつかの小さな機能強化を施しています。何よりも、Oracle Database 12.2の新機能であるシャードされたデータベースへのアクセスをサポートしました。また、SYSBACKUP、SYSDG、SYDKM、およびSYSRACのロールを使用した接続作成もサポートしました。サブスクリプション・メッセージを生成したトランザクションのIDの識別もサポートします。Windows環境では、誤ったアーキテクチャのOracle ClientがPATH環境変数にある場合に生成されるエラーメッセージが改善されました。デバッグ機能およびインフラストラクチャやテストスイートもかなり拡張・改善されています。ODPI-Cの改善ならびにODPI-Cを使用するcx_Oracle6.1とnode-oracledb 2.0の今後のリリースに向けて、多くのバグが修正されました。
    cx_Oracle - Python Interface for Oracle Database
    https://oracle.github.io/python-cx_Oracle/index.htmlnode-oracledb
    https://www.npmjs.com/package/oracledb
    詳細は、リリースノートをご覧ください。
    ODPI-C Release notes
    https://oracle.github.io/odpi/doc/releasenotes.html

    ODPI-C References

    [Docker, WLS] Run a WebLogic JMS Sample on Kubernetes

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

    Overview

    このエントリは、Kubernetesクラスタ内でWebLogic Server JMSアプリケーションのサンプルを構成し、実行するためのステップバイステップガイドです。まず、管理サーバとWebLogicクラスタを持つWebLogicドメインを作成する方法について説明した上で、WebLogic JMSリソースとデータソースを追加し、アプリケーションをデプロイして、最後にアプリケーションを実行します。
    このアプリケーションは、WebLogic Serverのサンプルアプリケーションに含まれている 'Classic API - Using Distributed Destination' (分散送り先の使用)という名前のサンプルアプリケーションに基づいています。このアプリケーションは、従業員が到着時に自身の名前を送信し、スーパーバイザが従業員の到着時間を監視するというシナリオを実装したものです。
    従業員は、チェックインメッセージの送信先(分散キューまたは分散トピック)を選択します。これらの宛先は、2つのアクティブな管理対象サーバが存在するクラスタ上で構成されています。これらの2つの宛先に対応する2つのmessage driven bean(MDB)がデプロイされ、チェックインメッセージを処理してデータベースに格納します。スーパーバイザーは、データベースに照会することですべてのチェックインメッセージをスキャンできます。

    WebLogicの構成変更を自動化する方法には、主として、WLSTとREST APIがあります。KubernetesのWebLogicドメインでスクリプトやWLST、REST APIを実行するには、次の2つの方法があります。
    • KubernetesクラスタPod内でスクリプトを実行するこちらの方法を使う場合は、 'localhost'、NodePortサービス名、またはStatefulsetのヘッドレスサービス名と、Pod IP、Cluster IP、および内部ポートを使用します。このブログの手順では、 'localhost' を使用します。
    • Kubernetesクラスタ外でスクリプトを実行するこちらの方法を使う場合は、hostname/IPとNodePortを使用します。
    このブログでは、REST APIを使用して管理サーバPod内のスクリプトを実行し、すべてのリソースをデプロイします。すべてのリソースはクラスタ全体を対象としています。クラスタが拡大または縮小する場合にうまく動作するため、Kubernetes上のWebLogic Serverの推奨アプローチです。

    Creating the WebLogic Base Domain

    GitHubのサンプルWebLogicドメインを使用してbaseドメインを作成します。
    WebLogic Sample on Kubernetes with Shared Domain Home
    https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-k8s-domain
    このWebLogicサンプルアプリケーションには、​​Kubernetes上のWebLogicドメインでWebLogic Serverインスタンスとクラスタを構築して実行するためのDockerfile、スクリプト、yamlファイルがあります。サンプルドメインには、AdminServerという名前の管理サーバーと、managed-server-0からmanaged-server-3までの4つの管理対象サーバーを含むWebLogicクラスタが含まれています。今回4個の管理対象サーバを設定しますが、managed-server-0とmanaged-server-1の最初の2個だけ構成を開始します。
    JMSサービスが他と異なる機能の一つとして、ステートフルであり、永続メッセージ、永続サブスクリプションなどといった、永続ストアにデータの大部分を保存する必要がある点があります。永続ストアは、データベースストアまたはファイルストアを使うことができます。このサンプルでは、​​外部ボリュームを使用してこのデータをファイルストアに格納する方法をご紹介します。
    このWebLogicドメインでは、次の3つの永続ボリュームを構成します。
    • ドメインホームフォルダこのボリュームは、ドメイン内のすべてのWebLogic Serverインスタンス、つまり、管理サーバとWebLogicクラスタ内のすべての管理対象サーバーインスタンスが共有します。
    • ファイルストアこのボリュームは、WebLogicクラスタ内の管理対象サーバ・インスタンスが共有します。
    • MySQLデータベースこのボリュームの使用については、このブログの後半で説明します。
    デフォルトでは、ドメインホームフォルダには、構成ファイル、ログファイル、診断ファイル、アプリケーションバイナリ、およびドメイン内の各WebLogic Serverインスタンスのデフォルトファイルストアファイルが含まれていることにご注意ください。カスタムファイルストアファイルもデフォルトでドメインホームフォルダに配置されていますが、このサンプルの設定をカスタマイズして、これらのファイルを個別の専用永続ボリュームに配置します。2つの永続ボリューム(ドメインホームとカスタムファイルストア)は、複数のWebLogic Serverインスタンスが共有します。それゆえ、Kubernetesクラスタが複数のマシンで実行されている場合、これらのボリュームは共用ストレージ内になければなりません。
    README.mdファイルの手順を実行して、baseドメインを作成して実行し、すべてのWebLogic Serverインスタンス(管理サーバと2つの管理対象サーバ)が実行されるまで待ちます。管理サーバの実行、初期ドメインのプロビジョニングの完了後、管理対象サーバを順に開始するため、時間がかかることがあります。
    $ kubectl get pod
    NAME                           READY    STATUS    RESTARTS    AGE
    admin-server-1238998015-kmbt9  1/1      Running   0           5m
    managed-server-0               1/1      Running   0           3m
    managed-server-1               1/1      Running   0           3m
    ブログで使用するコマンドでは、$adminPodと$mysqlPodを実際のポッド名に置き換える必要があることに注意してください。

    Deploying the JMS Resources with a File Store

    ドメインが稼動中であれば、JMSリソースをデプロイできます。

    まず、1つのファイルストア、1つのJMSサーバ、および1つのJMSモジュールの定義を含むJSONデータファイルを準備します。ファイルはPythonスクリプトが処理し、WebLogic ServerのREST APIを使用してリソースを1つずつ作成します。
    file jms1.json:
    {"resources": { 
      "filestore1": {
        "url": "fileStores",
        "data": {
          "name": "filestore1",
          "directory": "/u01/filestores/filestore1",
          "targets": [{
                     "identity":["clusters", "myCluster"]
                    }]
        }
      },
      
      "jms1": {
        "url": "JMSServers",
        "data": {
          "messagesThresholdHigh": -1,
          "targets": [{
                       "identity":["clusters", "myCluster"]
                      }],
          "persistentStore": [
             "fileStores",
             "filestore1"
            ],
          "name": "jmsserver1"
        }
      },
      
      "module": {
        "url": "JMSSystemResources",
        "data": {
          "name": "module1",
          "targets":[{
                      "identity": [ "clusters", "myCluster" ]
                    }]
        }
      },
      
      "sub1": {
        "url": "JMSSystemResources/module1/subDeployments",
        "data": {
          "name": "sub1",
          "targets":[{
                      "identity": [ "JMSServers", "jmsserver1" ]
                    }]
        }
      }
    }}
    続いて、JMSモジュールファイルを準備します。これには接続ファクトリ、分散キュー、分散トピックが含まれます。
    file module1-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="cf1">
        <default-targeting-enabled>true</default-targeting-enabled>
        <jndi-name>cf1</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="dq1">
        <sub-deployment-name>sub1</sub-deployment-name>
        <jndi-name>dq1</jndi-name>
      </uniform-distributed-queue>
      <uniform-distributed-topic name="dt1">
        <sub-deployment-name>sub1</sub-deployment-name>
        <jndi-name>dt1</jndi-name>
        <forwarding-policy>Partitioned</forwarding-policy>
      </uniform-distributed-topic>
    </weblogic-jms>
    3つめに、これらの2ファイルをコピーして管理サーバのPodに配置し、Pythonスクリプトを実行して管理サーバPod内でJMSリソースを作成します。
    $ kubectl exec $adminPod -- mkdir /u01/wlsdomain/config/jms/
    $ kubectl cp ./module1-jms.xml $adminPod:/u01/wlsdomain/config/jms/
    $ kubectl cp ./jms1.json $adminPod:/u01/oracle/
    $ kubectl exec $adminPod -- python /u01/oracle/run.py createRes /u01/oracle/jms1.json
    ブラウザでhttp://<hostIP>:30007/consoleにアクセスしてWebLogic Server管理コンソールを開き、全てのJMSリソースが問題なく動作していることを確認します。

    Deploying the Data Source

    Setting Up and Running MySQL Server in Kubernetes

    このサンプルはCheck-inメッセージをデータベースに格納します。それではMySQL Serverを構成しKubernetes上で動作するようにしましょう。

    最初に、以下のものを準備します。
    • mysql.yml:暗号化されたユーザー名とパスワード資格証明を格納するシークレットが定義されている
    • 永続ボリュームクレーム(Permanent Volume Claim : PVC):外部ディレクトリにデータベース・データを格納するためのボリューム
    • MySQL Serverインストーラとサービス
    base domainで、mysql.ymlで定義されたPVCが利用できるように、一つの永続ボリュームを予約して利用可能にしておきます。
    file mysql.yml:
    apiVersion: v1
    kind: Secret
    metadata:
      name: dbsecret
    type: Opaque
    data:
      username: bXlzcWw=
      password: bXlzcWw=
      rootpwd: MTIzNHF3ZXI=
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: mysql-pv-claim
      labels:
        app: mysql-server 
    spec:
      storageClassName: manual
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
    ---
    apiVersion: apps/v1beta1 
    kind: Deployment 
    metadata:
      name: mysql-server
    spec:
      replicas: 1
      template:
        metadata:
          labels:
            app: mysql-server 
        spec:
          containers:
          - name: mysql-server
            image: mysql:5.7
            imagePullPolicy: IfNotPresent
            ports:
            - containerPort: 3306
            env:
            - name:  MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dbsecret
                  key: rootpwd
            - name: MYSQL_USER
              valueFrom:
                secretKeyRef:
                  name: dbsecret
                  key: username
            - name: MYSQL_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dbsecret
                  key: password
            - name: MYSQL_DATABASE
              value: "wlsdb"
            volumeMounts:
            - mountPath: /var/lib/mysql
              name: db-volume
          volumes:
          - name: db-volume
            persistentVolumeClaim:
              claimName: mysql-pv-claim
    ---
    apiVersion: v1 
    kind: Service
    metadata:
      name: mysql-server
      labels:
        app: mysql-server 
    spec:
      ports:
      - name: client
        port: 3306
        protocol: TCP
        targetPort: 3306
      clusterIP: None
      selector:
        app: mysql-server
    続いて、MySQL ServerをKubernetesクラスタにデプロイします。
    $ kubectl create -f mysql.yml

    Creating the Sample Application Table

    まず、サンプルのアプリケーション表のためのDDLファイルを準備します。
    file sampleTable.ddl:
    create table jms_signin (
              name varchar(255) not null,
              time varchar(255) not null,
              webServer varchar(255) not null,
              mdbServer varchar(255) not null);
    続いて、MySQL Serverで表を作成します。
    $ kubectl exec -it $mysqlPod -- mysql -h localhost -u mysql -pmysql wlsdb < sampleTable.ddl

    Creating a Data Source for the WebLogic Server Domain

    サンプルアプリケーションがMySQL Serverと通信できるよう、データソースを構成する必要があります。最初にFirst, prepare the ds1-jdbc.xml モジュールファイルを準備します。
    file ds1-jdbc.xml:
    <?xml version='1.0' encoding='UTF-8'?>
    <jdbc-data-source xmlns="http://xmlns.oracle.com/weblogic/jdbc-data-source" 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/jdbc-data-source http://xmlns.oracle.com/weblogic/jdbc-data-source/1.0/jdbc-data-source.xsd">
      <name>ds1</name>
      <datasource-type>GENERIC</datasource-type>
      <jdbc-driver-params>
        <url>jdbc:mysql://mysql-server:3306/wlsdb</url>
        <driver-name>com.mysql.jdbc.Driver</driver-name>
        <properties>
          <property>
            <name>user</name>
            <value>mysql</value>
          </property>
        </properties>
        <password-encrypted>mysql</password-encrypted>
        <use-xa-data-source-interface>true</use-xa-data-source-interface>
      </jdbc-driver-params>
      <jdbc-connection-pool-params>
        <capacity-increment>10</capacity-increment>
        <test-table-name>ACTIVE</test-table-name>
      </jdbc-connection-pool-params>
      <jdbc-data-source-params>
        <jndi-name>jndi/ds1</jndi-name>
        <algorithm-type>Load-Balancing</algorithm-type>
        <global-transactions-protocol>EmulateTwoPhaseCommit</global-transactions-protocol>
      </jdbc-data-source-params>
      <jdbc-xa-params>
        <xa-transaction-timeout>50</xa-transaction-timeout>
      </jdbc-xa-params>
    </jdbc-data-source>
    続いて、データソース・モジュールをWebLogic Serverドメインにデプロイします。
    $ kubectl cp ./ds1-jdbc.xml  $adminPod:/u01/wlsdomain/config/jdbc/
    $ kubectl exec $adminPod -- curl -v \
    --user weblogic:weblogic1 \
    -H X-Requested-By:MyClient \
    -H Accept:application/json \
    -H Content-Type:application/json \
    -d '{
    "name": "ds1",
    "descriptorFileName": "jdbc/ds1-jdbc.xml",
    "targets":[{
    "identity":["clusters", "myCluster"]
    }]
    }' -X POST http://localhost:8001/management/weblogic/latest/edit/JDBCSystemResources

    Deploying the Servlet and MDB Applications

    まず、2個のアプリケーション・アーカイブ(signin.war と signinmdb.jar)をダウンロードします。

    以下のコマンドを入力してこれらの2個のアプリケーションをREST APIを使ってWebLogic Server管理サーバが動作しているPodにデプロイします。
    # copy the two app files to admin pod
    $ kubectl cp signin.war $adminPod:/u01/wlsdomain/signin.war
    $ kubectl cp signinmdb.jar $adminPod:/u01/wlsdomain/signinmdb.jar
    
    # deploy the two app via REST api
    $ kubectl exec $adminPod -- curl -v \
    --user weblogic:weblogic1 \
    -H X-Requested-By:MyClient \
    -H Content-Type:application/json \
    -d "{
      name:       'webapp',
      sourcePath: '/u01/wlsdomain/signin.war',
      targets:    [ { identity: [ 'clusters', 'myCluster' ] } ]
    }" \
    -X POST http://localhost:8001/management/weblogic/latest/edit/appDeployments
    
    $ kubectl exec $adminPod -- curl -v \
    --user weblogic:weblogic1 \
    -H X-Requested-By:MyClient \
    -H Content-Type:application/json \
    -d "{
      name:       'mdb',
      sourcePath: '/u01/wlsdomain/signinmdb.jar',
      targets:    [ { identity: [ 'clusters', 'myCluster' ] } ]
    }" \
    -X POST http://localhost:8001/management/weblogic/latest/edit/appDeployments
    続いて、WebLogic Server管理コンソール(http://<hostIP>:30007/console)を開き、アプリケーションのデプロイに成功し、実行中であることを確認します。

    Running the Sample

    ブラウザで http://<hostIP>:30009/signIn/ にアクセスし、管理対象サーバ上にあるアプリケーションを起動します。数多くの異なるブラウザやマシンを使って複数のWebクライアントをシミュレートし、いくつかのユニークな従業員名を投稿します。その後、ブラウザで http://<hostIP>:30009/signIn/response.jsp にアクセスして結果を確認します。異なるレベルの2つの負荷分散がなされていることがわかるでしょう。
    • HTTPリクエストがクラスタ内の管理対象サーバ間で負荷分散されている。[Web Server Name]という列のエントリを見ると、従業員のチェックインごとに、このカラムで、対応するHTTPリクエストを処理しているサーブレットインスタンスを含むWebLogic Serverインスタンスの名前を確認できる。
    • 分散送り先に送信されたJMSメッセージは、クラスタ内のMDBインスタンス間で負荷分散されている。[MDB Server Name]という列のエントリを見ると、メッセージを処理しているMDBインスタンスを含むWebLogic Serverインスタンスを確認できる。

    Restarting All Pods

    Restart the MySQL、WebLogic Server管理サーバと管理対象サーバのPodをそれぞれ再起動します。ここでは外部ボリュームにあるデータが確かにPodのライフサイクルとは関係なく保存されていることを説明します。

    まず、正常にMySQL Podを停止します。
    $ kubectl exec -it $mysqlpod /etc/init.d/mysql stop
    Podが停止したら、Kubernetesコントロール・パネルが自動的に再起動させるでしょう。

    続いて、README.mdの"Restart Pods"の章に移り、全てのWebLogic ServerのPodを再起動します。
    $ kubectl get pod
    NAME                            READY   STATUS   RESTARTS   AGE
    admin-server-1238998015-kmbt9   1/1     Running  1          7d
    managed-server-0                1/1     Running  1          7d
    managed-server-1                1/1     Running  1          7d
    mysql-server-3736789149-n2s2l   1/1     Running  1          3h
    各Podの再起動のカウントがインクリメントされ、0から1に変わったことがわかるでしょう。

    全てのPodが再起動したら、WebLogic Server管理コンソールにアクセスしてサーバがRUNNING状態になっていることを確認します。サーバが再起動すると、全てのメッセージがリカバリされます。全てのデータは外部データボリュームに格納されており、そのためPodの再起動後リカバリできるため再起動前と同じ結果を確認できます。

    Cleanup

    以下のコマンドを入力して、MySQL Serverインスタンスが利用していたリソースのクリーンアップを実施します。
    $ kubectl delete -f mysql.yml
    続いて、README.mdの "Cleanup" の章に従い、base domainを削除し、このサンプルで利用したその他全てのリソースを削除します。

    Summary and Futures

    このエントリでは、KubernetesをWebLogic Server JMSクラスタをホストするための柔軟でスケーラブルな環境として使用する方法をご紹介しました。基本的なKubernetesの機能を利用して、WebLogicサーバーのライフサイクルを管理し、ファイルベースのメッセージ永続性を使用し、Java EEアプリケーション間のクラスター内JMS通信を実証しました。また、ポッドのライフサイクルを超えてデータを維持するため、Kubernetes Pod外の共有データボリュームにファイルを外出しすることで、FileベースのJMS永続化がうまく機能することも実証しました。
    今後のエントリで、WebLogicの将来的に完全に動作保証されたWebLogicのKubernetes ‘operator based’のKubernetes環境を使用してWebLogic JMSクラスタをホストする方法を紹介することを検討しています。さらに、外部JMSクライアントを使用して、Kubernetesクラスタ内で動作するWebLogic JMSサービスと通信する方法、永続ストアとしてファイルの代わりにデータベースを使用する方法、WebLogic JMS自動サービス移行を使用してJMSインスタンスをシャットダウンされたPodから実行中のPodに自動的に移行する方法についても説明する予定です。

    [Java] OSSユーザーのための勉強会 #21 Java EE

    先日OSSユーザーのための勉強会という枠でJava EEならびにJava EE 8についてお話する時間を頂きました。主催のSCSK様をはじめとする関係者のみなさま、どうもありがとうございました。
    OSSユーザーのための勉強会 <OSS X Users Meeting> #21 Java EE
    http://eventregist.com/e/ossx2017-12
    当日は当方がJava EE の概要と特徴(ほとんどはJava EE 8の概要や新機能)、伊藤さん( @itakash )がJava EE の最新動向と今後の方向性についてお話しました。
    当方ならびに伊藤さんのスライドは主催者であるSCSK様のページから近日公開される予定になっていますが、当方分はSlideShareにUpしましたので、ご興味あればどうぞ。

    [Docker, WLS] 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

    Kubernetes上でのWeblogic Serverの動作保証検証の一環として、WebLogicチームは、Kubernetes環境でWebLogic Serverクラスタのオーケストレーションのデモサンプルを作成しました。
    WebLogic on Kubernetes Sample
    https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s
    このサンプルには、WebLogic Monitoring Exporterが含まれており、特定のWebLogic Serverインスタンスの実行時メトリックを取得し、PrometheusおよびGrafanaツールに供給することができます。
    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
    Prometheus - Monitoring system & time series database
    https://prometheus.io/
    Grafana - The open platform for analytics and monitoring
    https://grafana.com/
    Weblogic Monitoring Exporterは監視したいWebLogic Serverインスタンスにデプロイ可能なWebアプリケーションです。Weblogic Monitoring ExporterはWebLogic Server 12.2.1.xのRESTful管理インターフェースを使ってランタイム状態やメトリックにアクセスします。
    Oracle® Fusion Middleware RESTful管理サービスによるOracle WebLogic Serverの管理 12c (12.2.1.2.0)
    WLS RESTful管理インタフェースについて
    https://docs.oracle.com/cd/E84527_01/wls/WLRUR/overview.htm#GUID-B193E8EF-1912-48D1-8FB9-99C5ADACCC3B
    Oracle® Fusion Middleware Administering Oracle WebLogic Server with RESTful Management Services 12c (12.2.1)
    About the WLS RESTful Management Interface
    https://docs.oracle.com/middleware/1221/wls/WLRUR/overview.htm#WLRUR111
    WebLogic Monitoring Exporter構成や利用方法に関する詳細は、以下のエントリをご覧ください。
    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
    このエントリでは、PrometheusやGrafanaを構成し、Kubernetesクラスタで動作しているWebLogic Serverインスタンスの監視方法をご紹介します。

    Monitoring Using Prometheus

    WebLogic Monitoring Exporterを使用して、WebLogic Serverのメトリックを取得し、Prometheusにフィードします。以前のブログエントリでは、Kuberbetesクラスタで動作している管理対象サーバにWebLogic Monitoring Exporterをデプロイして、KubernetesでWebLogic Serverインスタンスを起動および実行する方法について説明しました。
    WebLogic on Kubernetes, Try It!
    https://blogs.oracle.com/weblogicserver/weblogic-on-kubernetes%2c-try-it
    https://orablogs-jp.blogspot.jp/2017/10/weblogic-on-kubernetes-try-it.html
    WebLogic Monitoring Exporterがデプロイされ実行されていることを確認するには、次のリンクをクリックします。
    http://[hostname]:30011/wls-exporter/metrics
    メトリックデータにアクセスするために必要なWebLogicユーザー資格情報の入力を求められます(例えばweblogic/weblogic1)。メトリックページでは、WebLogic Monitoring Exporter用に構成されたメトリックを表示します。

    To create a Prometheus instance in KubernetesにPrometheusインスタンスを作成するには、Prometheus構成ファイル(prometheus-kubernetes.yml)を作成する必要があります。サンプルファイルを用意しましたので、これを環境にあわせて変更してください。
    docker-images/OracleWebLogic/samples/wls-K8s/prometheus/
    https://github.com/oracle/docker-images/tree/master/OracleWebLogic/samples/wls-K8s/prometheus
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: prometheus
      labels:
        app: prometheus
    spec:
      replicas: 1
      strategy:
        type: Recreate
      template:
        metadata:
          labels:
            app: prometheus
        spec:
          containers:
          - name: prometheus
            image: prom/prometheus:v1.7.1
            ports:
            - containerPort: 9090
            args:
            - -config.file=/etc/prometheus/prometheus.yml
            volumeMounts:
            - mountPath: /etc/prometheus/
              name: config-volume
    #        - mountPath: /prometheus
    #          name: prometheus-data
          restartPolicy: Always
          volumes:
          - name: config-volume
            configMap:
              name: prometheus-configuration
    #      - name: prometheus-data
    #        persistentVolumeClaim:
    #          claimName: prometheus-storage
    ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: prometheus-configuration
    data:
      prometheus.yml: |-
        global:
          scrape_interval:     5s
          external_labels:
            monitor: 'my-monitor'
        scrape_configs:
        - job_name: 'kubernetes-pods'
          kubernetes_sd_configs:
          - role: pod
          relabel_configs:
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
            action: keep
            regex: true
          - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
            action: replace
            target_label: __metrics_path__
            regex: (.+)
          - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
            action: replace
            regex: ([^:]+)(?::\d+)?;(\d+)
            replacement: $1:$2
            target_label: __address__
          - action: labelmap
            regex: __meta_kubernetes_pod_label_(.+)
          - source_labels: [__meta_kubernetes_pod_name]
            action: replace
            target_label: pod_name
          - regex: '(controller_revision_hash|job)'
            action: labeldrop
          - source_labels: [name]
            regex: '.*/(.*)$'
            replacement: $1
            target_label: webapp
          basic_auth:
           username: weblogic
           password: weblogic1
    
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: prometheus-storage
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi
    status: {}
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: prometheus
    spec:
      type: NodePort
      ports:
      - port: 9090
        targetPort: 9090
        nodePort: 32000
      selector:
        app: prometheus
    
    上記Prometheus構成ファイルの例では以下のように指定しています。
    • ユーザー資格証明はweblogic/weblogic1
    • WebLogic Serverのメトリックの更新間隔は5秒
    • Prometheusダッシュボードへアクセスするための外部ポートは32000/tcp
    これらの値は皆様の特定の環境や構成を反映するために、必要に応じて変更できます。
    Start Prometheusを起動して、管理対象サーバインスタンスを監視します。
    $ kubectl create -f prometheus-kubernetes.yml
    Prometheusがすべての管理対象サーバを監視していることを確認するために、以下のURLをブラウザで確認します。
    http://[hostname]:32000
    カーソルのプルダウンでInsertメトリックを調べます。WebLogic Monitoring Exporter Webアプリケーションの現在の設定に基づいてメトリック名がリスト表示されます。

    WebLogic Monitoring Exporterを正しく構成していることを確認するためには、以下のURLにブラウザで接続します。
    http//:[hostname]:30011/wls-exporter
    現在の構成が下図のように表示されるはずです。

    以下は対応するWebLogic Monitoring Exporterの構成ファイルです。
    metricsNameSnakeCase: true
    queries:
    - applicationRuntimes:
        key: name
        keyName: app
        componentRuntimes:
          type: WebAppComponentRuntime
          prefix: webapp_config_
          key: name
          values: [deploymentState, contextRoot, sourceInfo, openSessionsHighCount, openSessionsCurrentCount, sessionsOpenedTotalCount, sessionCookieMaxAgeSecs, sessionInvalidationIntervalSecs, sessionTimeoutSecs, singleThreadedServletPoolSize, sessionIDLength, servletReloadCheckSecs, jSPPageCheckSecs]
          servlets:
            prefix: weblogic_servlet_
            key: servletName
            values: [invocationTotalCount, reloadTotal, executionTimeAverage, poolMaxCapacity, executionTimeTotal, reloadTotalCount, executionTimeHigh, executionTimeLow]
    - JVMRuntime:
        key: name
        values: [heapFreeCurrent, heapFreePercent, heapSizeCurrent, heapSizeMax, uptime, processCpuLoad]
    
    上記構成ファイルはWebLogic Monitoring ExporterのWARファイルに埋め込まれていました。メトリックデータの変更や追加をする場合は、単純にランディングページ(http//:[hostname]:30011/wls-exporter)に接続して[Append or Replace]ボタンをクリックし、構成ファイルをyml形式でロードします。以下はその例です(workmanager.yml)。
    metricsNameSnakeCase: true
    queries:
    - applicationRuntimes:
        key: name
        workManagerRuntimes:
          prefix: workmanager_
          key: applicationName
          values: [pendingRequests, completedRequests, stuckThreadCount]
    
    prometheusが定義するクエリを構築することで、WebLogicドメインで動作しているサーバやアプリケーション、リソースの監視・診断に必要な任意のデータを取り出すことができます。
    QUERYING PROMETHEUS
    https://prometheus.io/docs/querying/basics/
    例えば、以下のクエリを入力すると、PrometheusはWebLogicクラスタ内で実行中のすべての管理対象サーバから現在のデータを返します。
    weblogic_servlet_execution_time_average > 1

    Prometheusはデータに基づいてグラフも生成します。例えば、Graphタブをクリックすると、Prometheusは平均実行時間がしきい値である1秒を超過するServletの数を示すグラフを生成します。

    Monitoring Using Grafana

    複数のグラフを持つ可視性の高いダッシュボードを使用するには、Grafanaを使用します。
    以下は設定ファイル(grafana-kubernetes.yml)の例で、これを使いKubernetes環境でGrafanaを起動することができます。
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: grafana
      labels:
        app: grafana
    spec:
      replicas: 1
      strategy:
        type: Recreate
      template:
        metadata:
          labels:
            app: grafana
        spec:
          containers:
          - name: grafana
            image: grafana/grafana:4.4.3
            ports:
            - containerPort: 3000
            env:
            - name: GF_SECURITY_ADMIN_PASSWORD
              value: pass
    #        volumeMounts:
    #        - mountPath: /var/lib/grafana
    #          name: grafana-data
          restartPolicy: Always
          volumes:
    #      - name: grafana-data
    #        persistentVolumeClaim:
    #          claimName: grafana-data
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      creationTimestamp: null
      name: grafana-data
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 100Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: grafana
      name: grafana
    spec:
      type: NodePort
      ports:
      - port: 3000
        targetPort: 3000
        nodePort: 31000
      selector:
        app: grafana
    
    Grafanaを起動して管理対象サーバを監視するには、以下のkubectlコマンドを実行します。
    $ kubectl create -f grafana-kubernetes.yml
    http://[hostname]:31000 でGrafanaに接続できるので、ホームページにログイン(ユーザー名はadmin、パスワードはpass)すると、Grafanaのホームページが表示されます。

    GrafanaをPrometheusに接続するには、[Add Data Source] を選択し、以下の値を入力します。
    Name: Prometheus
    Type: Prometheus
    Url: http://prometheus:9090
    Access: Proxy

    [Dashboards] タブを選択し、[Import]をクリックします。

    これで、WebLogic Serverを監視するダッシュボードの作成準備ができたので、以下の操作を完了させます。
    1. ホームページ左上部のGrafanaのアイコンをクリックし、Dashboards>Newを選択
    2. Graphを選択し、空白スペースにDragすると、空のグラフパネルができる。
    3. パネル上をクリックし、editを選択すると、編集可能なパネルが開き、メトリックグラフの表示方法をカスタマイズできる。
    4. GraphパネルでGeneralタブを選択し、タイトルに「WebLogic Servlet Execution Average Time(WebLogicサーブレット実行平均時間)」と入力。
    5. Metricsタブを選択し、Panel Data SourceのプルダウンメニューでPrometheusを選択。
    空のMetric参照フィールドをクリックすると、Prometheusの場合と同様に、WebLogic Monitoring Exporterで設定されたすべてのメトリックを引き込みます。 Prometheusの例で指定したweblogic_servlet_execution_time_average> 1というクエリを入力すると、クラスタ内のすべての管理対象サーバ上で平均実行時間が1秒を超えるすべての利用可能なServletのデータが生成されてグラフとして表示されます。 各色は特定のPodとServletの組み合わせを表します。

    特定のPodのデータを表示するには、対応する凡例をクリックします。これにより、他のPodのデータはグラフからすべて削除され、その凡例は強調表示されなくなります。データを追加するには、シフトキーを押して任意の凡例をクリックします。リセットするには、もう一度同じ凡例をクリックすると、他のすべてのグラフがグラフに再表示されます。
    凡例をカスタマイズするには、Legend Formatフィールドで目的の値をクリックします。 例えば以下の値をクリックした場合、Grafanaはカスタマイズされた凡例を表示し始めます。グラフをクリックすると、選択した時間のすべての値が表示されます。
    {{pod_name}} :appName={{webapp}} : servletName={{servletName}}

    Graph→Legendタブを選択すると、凡例をさらにカスタマイズできます。例えば、凡例の配置を移動したり、最小値、最大値、平均値などを表示することができます。
    Graph→Axesタブを選択すると、単位を対応するメトリックデータに切り替えることができます。この例では、時間(ミリ秒)です。
    Grafanaはアラートツールも提供しています。例えば、指定した条件にアラートを設定できます。下の例では、Servletの平均実行時間が100ミリ秒を超えると、Grafanaはアラートを送出し、管理者に電子メールを送信します。

    最後に、Prometheusのデータ収集間隔と同じリフレッシュ間隔である5秒ごとにグラフをリフレッシュする必要があります。また、データを監視する時間範囲をカスタマイズすることもできます。
    そのためには、作成したダッシュボードの右上隅をクリックする必要があります。デフォルトでは、現在の時刻までの過去6時間のメトリックを表示するように設定されているので、必要な変更を行います。例えば、5秒ごとに更新してApplyをクリックします。

    完了したら、画面の左上部にある[Save]をクリックして、ダッシュボードの名前を指定するだけです。

    Summary

    WebLogic Serverには豊富な一連のメトリックが用意されており、このメトリックはWebLogic Server Administration ConsoleやMonitoring Dashboardなどのよく知られたツールを使用して監視できます。これらのツールを使って、KubernetesにデプロイされているWebLogic Serverで実行されているWebLogic Serverインスタンス、アプリケーション、およびリソースを監視できます。このコンテナ・エコシステムにおいて、Kubernetes上で実行されているWebLogic Serverインスタンスのクラスタからメトリックをエクスポートおよび監視する別の方法をPrometheusやGrafanaのようなツールが提供します。また、こうしたツールを使うと、ドメインを再起動せずに、監視データを簡単に収集、アクセス、表示、カスタマイズすることができますし、さらにアラートを作成し、関係者に通知を簡単に送信することができます。是非使い始めてください。きっと気に入っていただけることでしょう!