WebLogic Mavenプラグインを使って依存モジュールの解決を楽にする

jBatch×WebLogicのネタも考え中ですが、閑話休題ということで。

以下のような開発をしているエンジニアの方は、WebLogic Mavenプラグインを利用するのがおすすめです。

  • WebLogic Serverで動かすアプリケーションを開発している
  • アプリケーションのビルドにMavenを利用している

例えば、Servlet-APIJDBCドライバのjarファイルを、pom.xmlにひとつひとつ書いて取得してたりしないでしょうか。しかも、WebLogicに入っているモジュールのバージョンを確認して、自力でローカルリポジトリにインストールしたりとか…。

WebLogic Mavenプラグインを使うと、個別にpom.xmlに記述せずとも、WebLogicに入っているモジュールを自動取得することができます。
手間が減るのはもちろん、コンパイルとランタイム間での、バージョン不整合を防止することができます。

というわけで、WebLogic Mavenプラグインを使って、WebLogicに入っているモジュール解決する手順を紹介します。

1. 手順

1-1. 前提条件

この手順は、以下の条件を満たしていることが前提です。

  • ビルドを実行するマシンにmvnがインストールされている
  • WebLogic Serverの、ORACLE_HOMEが参照できる

また、これ移行の手順は、WebLogic Server 12.2.1を使う想定で書きます。

1-2. WebLogic Mavenプラグインのインストール

以下のコマンドを実行します(WebLogic Server 12.2.1 の場合)

> cd ${ORACLE_HOME}\oracle_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.2.1
> mvn install:install-file -DpomFile=oracle-maven-sync-12.2.1.pom -Dfile=oracle-maven-sync-12.2.1.jar

※${ORACLE_HOME}は環境に合わせて変更してください。

以下のような内容がコンソールに出力されればOKです。

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-install-plugin:2.4:install-file (default-cli) @ standalone-pom---
[INFO] Installing C:\WLSHandsOn\mw\oracle_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.2.1\oracle-maven-sync-12.2.1.jar to C:\Users\hhayakaw\.m2\repository\com\oracle\maven\oracle-maven-sync\12.2.1-0-0\oracle-maven-sync-12.2.1-0-0.jar
[INFO] Installing C:\WLSHandsOn\mw\oracle_common\plugins\maven\com\oracle\maven\oracle-maven-sync\12.2.1\oracle-maven-sync-12.2.1.pom to C:\Users\hhayakaw\.m2\repository\com\oracle\maven\oracle-maven-sync\12.2.1-0-0\oracle-maven-sync-12.2.1-0-0.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.076 s
[INFO] Finished at: 2016-03-07T09:32:09+09:00
[INFO] Final Memory: 9M/245M
[INFO] ------------------------------------------------------------------------

1-3. ローカルリポジトリにモジュールを取り込む

MavenのローカルリポジトリOracle_Home配下からモジュールを取り込みます。

以下のコマンドを実行します(12.2.1の場合)

>mvn com.oracle.maven:oracle-maven-sync:push -DoracleHome=${ORACLE_HOME}

※${ORACLE_HOME}は環境に合わせて変更してください。

取り込むモジュールがたくさんあるので、コンソールに大量のメッセージが出力されますが、最終的に以下の内容が出力されれば成功のようです。

[INFO] SUMMARY
[INFO] ------------------------------------------------------------------------
[INFO] PUSH SUMMARY - ARTIFACTS PROCESSED SUCCESSFULLY
[INFO] ------------------------------------------------------------------------
[INFO] Number of artifacts pushed: 1013
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] PUSH SUMMARY - ERRORS ENCOUNTERED
[INFO] ------------------------------------------------------------------------
[INFO] No issues encountered.
[INFO]
[INFO] IMPORTANT NOTE
[INFO] This operation may have added/updated archetypes in your repository.
[INFO] To update your archetype catalog, you should run:
[INFO] 'mvn archetype:crawl -Dcatalog=$HOME/.m2/archetype-catalog.xml'
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:51 min
[INFO] Finished at: 2016-03-07T09:39:33+09:00
[INFO] Final Memory: 11M/162M
[INFO] ------------------------------------------------------------------------

1-4. pom.xmlを編集する

ビルドするプロジェクトのpom.xml<dependency>と、<plugin>タグを追加します。

以下の様に、両タグを記述します。また、既存の記述の不要な<dependency>は削除しておきます。

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/xsd/maven-4.0.0.xsd"><dependencies><dependency>
            <groupId>com.oracle.weblogic</groupId>
            <artifactId>weblogic-server-pom</artifactId>
            <version>12.2.1-0-0</version>
            <type>pom</type>
            <scope>provided</scope>
        </dependency>
    </dependencies><build>
        <plugins><plugin>
                <groupId>com.oracle.weblogic</groupId>
                <artifactId>weblogic-maven-plugin</artifactId>
                <version>12.2.1-0-0</version>
            </plugin>
        </plugins>
    </build></project>

1-5. ビルドする

普段どおりビルドを実行します。例えば、

> mvn clean package

初回は結構時間がかかります。WebLogicから取り込んだモジュールの、メタデータのダウンロードらしき処理がおこなわれます。

2. 適用例

例えば、以前紹介したjBatchのサンプルアプリケーションですと、以下のモジュールの記述を削減できます。

  • javax.batch-api
  • cdi-api
  • javax.inject
  • javax.transaction-api
  • javax.ws.rs-api
  • javax.persistence

実際のコードはこちらJava EE系が軒並み減らせました。


WebLogic Mavneプラグインの機能は、今回紹介したものだけではありません。ビルドしたものをテスト環境に自動デプロイしたり、WLSTを実行したりなど、もっと高度な機能があります。

詳細は公式のドキュメントを参照ください。

パーティショニングを使ったjBatchのサンプルアプリケーションを作った

本記事では、先日のWebLogic Server勉強会で、デモに使用した、jBatchのサンプルアプリケーションを紹介します。

このアプリケーションでは、jBatchのパーティショニングを利用した並列処理を実装しており、ジョブの開始時に、パーティション数とスレッド数を指定することができます。

アプリケーションの概要

このアプリケーションは、テキストデータを形態素解析(単語に分割する処理)し、結果をデータベースに保存する処理をおこないます。
DBに格納された言語データは後々統計分析をかけるという想定で、その前処理に当たる、DBにデータを格納する部分をバッチジョブとして実装したという想定です。

分析対象のデータは、複数の日本語のテキストファイルです。
処理対象のテキストファイルのパスを特定するため、パスをリストしたインデックスを用意しておきます。バッチジョブは、インデックスを参照しながら、複数のテキストファイルに順次形態素解析をかけていきます。

f:id:charlier_shoe:20160229191107p:plain

このアプリケーションでは、jBatchのパーティショニングを利用した並列処理を実装しています。
インデックスを複数パーティションに分け、パーティション毎に、異なるスレッドで並列に処理を行うことができます。また、ジョブの開始時に、パーティション数とスレッド数を指定することができます。

ソースコード

本アプリケーションのソースコードは、GitHubに公開してあります。

アプリケーションの動かし方

ソースコードリポジトリ上のREADME.mdを参照下さい。

実際に動かしてみる

実際に動かしてみた結果を紹介します。

3パーティション、3スレッドでジョブを実行すると、標準出力に以下の様な内容が出力されます。 パーティション毎に別の番号を振っていますが、うまく3パーティションに分かれて処理が進んでいる事がわかります。

finished(parti tion: 0 | piece: "odazai/1047_ruby_20129_chikusei.txt")
finished(partition: 0 | piece: "odazai/1059_ruby_4748_hashiranu_meiba.txt")
finished(partition: 0 | piece: "odazai/1084_ruby_4753_nyozegamon.txt")
finished(partition: 0 | piece: "odazai/1093_ruby_20122_sakkano_techo.txt")
finished(partition: 1 | piece: "odazai/1573_ruby_4930_yukino_yono_hanashi.txt")
finished(partition: 0 | piece: "odazai/1095_ruby_20124_sange.txt")
finished(partition: 0 | piece: "odazai/1109_ruby_20131_tokyodayori.txt")
finished(partition: 0 | piece: "odazai/1562_ruby_14574_asa.txt")
finished(partition: 0 | piece: "odazai/1563_ruby_9706_gyofukuki.txt")
finished(partition: 0 | piece: "odazai/1564_ruby_14093_mangan.txt")
finished(partition: 1 | piece: "odazai/1574_ruby_15426_omoide.txt")
finished(partition: 2 | piece: "rakutagawa/109_ruby_1423_nidai.txt")
finished(partition: 2 | piece: "rakutagawa/110_ruby_1195_nikko_shohin.txt")
finished(partition: 2 | piece: "rakutagawa/111_ruby_1573_niwa.txt")
finished(partition: 1 | piece: "odazai/1575_ruby_24932_das_gemeine.txt")
finished(partition: 2 | piece: "rakutagawa/112_ruby_3165_noroma_ningyo.txt")
…

以下は、パーティション数、スレッド数を変えてジョブを実行しつつ、モニタリングダッシュボードでその様子を確認したものです。 待機スレッド数、アクティブスレッド数、CPU負荷の様子をグラフに表示しています。

f:id:charlier_shoe:20160229191139p:plain

指定されたスレッド数が増えるにしたがって、アクティブスレッド数も増えていることが分かります。
また、3パーティション/3スレッドまで上げると、CPUにきちんと負荷がかかって(CPUが利用されて)、処理時間が短くなっていることも確認できます。今回は1~1.5分で終わる程度の処理だったので、顕著な差ではありませんでしたが、もっと長時間のジョブではより意味のある効果が得られそうです。

ちなみに今回は、3コアのDockerホスト上で、DBとWebLogic Serverの2つのコンテナを稼働させています。そのためか、4パーティション/4スレッドにあげても、ほとんど性能向上はありませんでした。

以上、jBatchのサンプルアプリケーションの紹介でした。

Dockerコンテナ上にWebLogic Serverのクラスターを構成する

先日のWebLogic Server勉強会 特別編では、DockerコンテナでWebLogic Serverのクラスターを構成するデモを紹介しました。

Oracle公式のDockerfileのリポジトリにいくとreadmeにコマンドの使い方が記載されていますが、勉強会では若干アレンジして使っていた部分があります。
本記事では、その時に使用したコマンドの詳細を解説したいと思います。

前提条件

Dockerのホストマシンに、Oracle公式のDockerfileとスクリプトをダウンロードして、配置しておきます。本記事では、"~/sync"配下にこれらのファイルが配置されているものとします。

また、JDKWebLogic Serverのインストーラを別途ダウンロードし、所定のパスに配置する必要があります。
以下のようなディレクトリ構成になるよう、配置して下さい((※)がダウンロードして追加したファイルです)。

~/sync
├── GlassFish
│   └── …
├── MySQL
│   └── …
├── NoSQL
│   └── …
├── OpenJDK
│   └── …
├── OracleCoherence
│   └── …
├── OracleJDK
│   └── …
└── OracleWebLogic
     ├── COPYRIGHT
     ├── dockerfiles
     │   ├── 12.1.3
     │   │   └── …
     │   ├── 12.2.1
     │   │   ├── Dockerfile.developer
     │   │   ├── Dockerfile.generic
     │   │   ├── Dockerfile.infrastructure
     │   │   ├── fmw_12.2.1.0.0_infrastructure_Disk1_1of1.zip.download
     │   │   ├── fmw_12.2.1.0.0_wls_Disk1_1of1.zip.download
     │   │   ├── fmw_12.2.1.0.0_wls_quick_Disk1_1of1.zip(※)
     │   │   ├── fmw_12.2.1.0.0_wls_quick_Disk1_1of1.zip.download
     │   │   ├── install.file
     │   │   ├── oraInst.loc
     │   │   ├── server-jre-8u73-linux-x64.tar.gz(※)
     │   │   ├── server-jre-8u73-linux-x64.tar.gz.download
     │   │   └── …
     │   └── buildDockerImage.sh
     ├── LICENSE
     ├── README.md
     └── samples
         ├── 1213-domain
         │   ├── Dockerfile
         │   ├── README.md
         │   └── …
         ├── 1221-appdeploy
         │   └── …
         ├── 1221-docker-compose
         │   └── …
         ├── 1221-domain
         │   ├── container-scripts
         │   │   ├── add-machine.py
         │   │   ├── add-server.py
         │   │   ├── commonfuncs.py
         │   │   ├── createMachine.sh
         │   │   ├── createServer.sh
         │   │   ├── create-wls-domain.py
         │   │   └── waitForAdminServer.sh
         │   ├── Dockerfile
         │   └── README.md
         ├── 1221-medrec
         │   └── …
         ├── 1221-multihost
         │   └── …
         ├── 1221-webtier-apache
         │   └── …
         ├── clean-up-docker.sh
         └── rm-containers.sh

ツリーをよく見ると、気になる名前のディレクトリが結構ありますね。個人的には、GrassFish、CoherenceFusion Middleware Infrastractureのイメージ当たりを、後々試したいところです。

コマンドの説明

以下、コマンド群の説明です。

1. Install Imageの作成

はじめに、WebLogic ServerのInstall Imageを作成します。Install Imageは、Docker HubのOracle Linuxのイメージに、JDKWebLogicインストーラを適用したものです。

$ cd ~/sync/OracleWebLogic/dockerfiles
$ ./buildDockerImage.sh -v 12.2.1 -d

このコマンドでは、Oracle公式のスクリプトを介してdocker buildコマンドを実行しています。オプションの意味は以下のとおりです。

  • -v 12.2.1
  • -d
    • WebLogicを開発者モードでインストールする

2. Domain Imageの作成

次にWebLogic ServerのDomain Imageを作成します。Domain Imageは、Install Imageをベースにして空のWLSドメインを構成したものです。
以下のようにdocker runコマンドを実行します。

$ cd ~/sync/OracleWebLogic/samples/1221-domain
$ docker build -t oracle/1221-domain --build-arg ADMIN_PASSWORD=welcome1 .

このコマンドで実行されるDockerfileでは、ドメインを構成するWLSTを呼び出すよう記述されています。オプションの意味は以下のとおりです。

  • -t oracle/1221-domain
    • このコマンドで作成されるイメージの名前
  • --build-arg ADMIN_PASSWORD=welcome1
    • WebLogicの管理者ユーザーのパスワード

3. 管理サーバーの起動

管理サーバーを起動します。Domain Imageを指定してdocker runコマンドを実行します。

(※実際には1行)
$ docker run
    -v /vagrant:/tmp/shared --privileged=true
    -p 8001:8001 --hostname=wlsadmin
    --name=wlsadmin
    oracle/1221-domain

オプションの意味は以下のとおりです。

  • -v /vagrant:/tmp/shared
    • Dockerのホストとコンテナとの共有フォルダの指定。上記の場合、ホストの/vagrant配下のファイル、ディレクトリが、コンテナの/tmp/shared配下に共有されます
  • --privileged=true
    • 共有フォルダ(/tmp/shaared)へのアクセス権を与える
  • -p 8001:8001
    • ホストの8001番ポートを、コンテナの8001番ポートにフォワードする
  • --hostname=wlsadmin
    • コンテナホスト名の指定
  • oracle/1221-domain
    • 使用するイメージの名前

-vオプションでコンテナからホストのファイルを参照できるようにしています。これは、コンテナ上で動作するアプリケーションから、アプリで使用するデータを参照させるためです。
このようなやり方をすると、アプリケーションのためにデータを転送する手間が省けて便利です。

このコマンドでは、runの時に実行されるコマンドを明示的に指定していませんので、イメージ作成時にDockerfileで指定されたコマンドが実行されます。

    # Define default command to start bash.
    CMD ["startWebLogic.sh"]

Domain ImageのDockerfileでは、startWebLogic.shが指定されているので、これが実行されます。

また、-dオプションをつけていないので、フォアグラウンドでstartWebLogic.shが実行されます。管理サーバーの標準出力が表示され続けて操作が帰ってこないので、以降は別のターミナルで作業します。
Dockerコンテナは、ホスト上の1つのプロセスとして実行されていますが、それを体感できる挙動だと思います。

4. 管理対象サーバーの起動

管理対象サーバーを起動します。管理サーバーのときと同じく、Domain Imageを指定してdocker runコマンドを実行します。

(※実際には1行)
$ docker run
    -d
    -v /vagrant:/tmp/shared
    --privileged=true
    -p 5556:5556 -p 7001:7001 --hostname=wlsmanaged0
    --link wlsadmin:wlsadmin
    --name=wlsmanaged0
    oracle/1221-domain
    createServer.sh

オプションの意味は以下のとおりです(管理サーバーと同じものは省略)。

  • -d
    • バックグラウンドでコンテナコンテナを実行する
  • -p 5556:5556 -p 7001:7001
    • ホストの5556/7001番ポートをコンテナの5556/7001番ポートにフォワードする
  • --link wlsadmin:wlsadmin
    • 接続先の管理サーバー(wlsadmin)に対するエイリアス名の設定
  • --hostname=wlsmanaged0
    • コンテナホスト名の指定
  • createServer.sh
    • コンテナ起動時に実行するコマンド

管理サーバーと同じように、-vオプションで、ホスト上の同じファイルを参照できるようにしています。このようにすると、WebLogic Serverドメイン内の各サーバーから同じファイルを参照できるので、アプリケーション用のデータをサーバーごとに用意する手間が省けます。

--linkオプションは、WLSTで管理サーバーに接続する際の、接続先のエイリアスを設定しています。後述のcreateServer.shからWLSTで管理サーバーに接続しますが、WLSTのスクリプトは、wlsadminというエイリアスで接続先を指定しています。これが実際の管理サーバーのホスト名に紐づくようにしています。
この例では、ホスト名もエイリアスも同じ名前になっていますが、"wlsadmin:wlsamdin"の先に記述した方が接続先の実際の名前で、後に記述した方がエイリアスです。

このコマンドでは、コンテナ起動時にcreateServer.shを実行するよう指定しています。 createServer.shでは、管理対象サーバー、ノードマネージャの起動、WLSTによるマシン、サーバー、クラスターの構成をおこないます(wlsmanaged0からwlsamdinに対してWLSTを実行)。

管理対象サーバーを複数起動する場合は、ホスト名とポートフォワードの値だけを変えて、同じコマンドを実行すればOKです。

$ docker run
    -d
    -v /vagrant:/tmp/shared --privileged=true
    -p 15556:5556 -p 17001:7001 --hostname=wlsmanaged1
    --link wlsadmin:wlsadmin
    --name=wlsmanaged1
    oracle/1221-domain
    createServer.sh

数十秒程度待ってからWebLogic Server 管理コンソールを見ると、管理対象サーバー2つを含むクラスターが構成されているはずです。

その他知っておくと役に立つコマンド

イメージやコンテナを操作する上で、よく使うコマンドを以下に挙げておきます。コンテナ名やイメージ名は、これまでのコマンドを使った場合の実際の値になっているので、それ以外の場面で使うときは適宜読み替えてください。

コンテナの停止、起動

1つのコンテナを停止

docker stop wlsadmin

複数のコンテナを停止

docker stop wlsadmin wlsmanaged0 wlsmanaged1

1つのコンテナを起動

docker start wlsadmin

1つのコンテナをフォワグラウンドで起動

docker start -a wlsadmin

複数のコンテナを起動

docker start wlsadmin wlsmanaged0 wlsmanaged1

コンテナの一覧

起動中のコンテナの一覧

docker ps

全てのコンテナの一覧

docker ps -a

コンテナの削除

1つのコンテナを削除

docker rm wlsadmin

複数削除は停止、起動と同様)

イメージの削除

Domain Imageの削除

docker rmi oracle/weblogic:12.2.1

Install Imageの削除

docker rmi oracle/1221-domain

コンテナIPの確認

sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' wlsmanaged0

覚えるのが面倒であれば、以下のやり方でも十分です。

sudo docker inspect wlsmanaged0 | grep IP

以上、DockerコンテナでWebLogic Serverのクラスターを構成する際の、コマンドの解説でした。

2/16 WebLogic Server 勉強会に登壇しました

2/16にオラクル青山センターにて開催された、WebLogic Server勉強会 特別編に登壇いたしました。会場まで足を運んで頂いた方も、リモートで聴講頂いた方も、ご参加いただきありがとうございました。
当日の資料は、SlideShareOracle Fusion Middlewareアカウントにて公開しておりますので、どうぞ御覧ください。

今回のWLS勉強会は、以下2セッションで、私は前半のJave EE/Docker/DevOpsのテーマの方で話をさせていただきました。

Java EE対応のセッションを受け持っておきながらなんですが、業務でエンジニアのみなさんと接していると、マルチテナントへの期待をひしひしと感じます。
実際の運用事例が出てくるまでにはまだ時間が必要かもしれませんが、Javaアプリケーションサーバーの世界において非常に画期的な機能ですので、今後ともご注目頂きたいと思います。

もちろん、Java EE 7やDocker対応の方も、よろしくお願いします。このブログでは、そのとき私が興味を持ったものを記事にしていくつもりですので、MTよりもJavaの方の記事が多くなると思います。

しばらくの間は、WLS勉強会では時間の都合で説明できなかった、デモの詳細を記事にしていきたいと思います。DockerでWebLogicクラスターを組む時のコマンドとか、jBatchのデモアプリの詳細とか。

当ブログも引き続きよろしくお願いします。

Cygwin 環境構築手順の備忘録

Cygwinに関しては、本格的に使うようになって約半年程度の初心者ですが、追加パッケージの導入など環境の変更がだいぶ積み重なってきました。 そろそろ何をやってきたか思い出せなくなりそうなので、やった作業と手順の参照先を残しておくことにしました。

unzip, scp/ssh

unzip はzip アーカイブのユーティリティ。
scp,ssh は SCP と SSH のクライアント(そのまんま…)。Linux系のサーバーを使って開発をするときには、必須。

これらは Cygwinインストーラで導入してしまいました。
パッケージの選択画面で、"unzip"、"openssh" でフィルタすれば見つかります。

wget

Cygwinwget コマンドが使えるようにします。手順は以下を参考させていただきました。

wget は、apt-cyg 追加するときにも必要になります。

apt-cyg

Cygwin で apt-get や yum ライクにパッケージのインストールを行えるようにします。apt-cyg を使うと、Cygwinインストーラ無しでパッケージの追加ができるようになるので便利です。
また後述する tree コマンドのように、Cygwinインストーラでは導入できないものもあります。

手順は以下を参考にさせていただきました。

rsync

Vagrant を使っていて、ゲストOSとファイル共有したいときに重宝します。rsyncは、"vagrant rsync" を使うために必要です。左記コマンドを打つと、ホストOS上の更新がゲストOSの共有フォルダに反映されます。

導入は、apt-cyg で一発。

$ apt-cyg install rsync

tree

tree ディレクトリ階層を出力するコマンド。テキストでREADME的なメモを書くときに、ディレクトリ階層を図示したいときに重宝します。

導入は、apt-cyg で一発。

$ apt-cyg install tree

vim

これは説明不要ですかね。Windows環境では gvim もありますが、テキスト編集をターミナル内で完結させた方が楽な場面は、結構多いと思います。

導入は、こちらも apt-cyg で。

$ apt-cyg install vim

git

GUIのリッチなクライアントもありますが、コマンドが嬉しい時もあり。

導入はまたまた apt-cyg。apt-cyg 便利。

$ apt-cyg install git

chere

エクスプローラで、コンテキストメニューから現在のフォルダで Cygwin のターミナルを開けるようにします。

手順は以下を参考にさせていただきました。

open コマンドで、デフォルトのアプリでファイルを開くようにする

元々 Cygwin には、cygstart というコマンドがありまして、これを使うと、指定したファイルをデフォルトのアプリで開きます。
Cygwin を使う人には、このコマンドのエイリアスとして、"open" を設定している方が多いようです(Mac では標準でそうなっているそうな)。やってみると、確かに "cygstart" と打つよりかなり楽です。

"cygstart" は字数が多い上に左手にキーが集中しているので、ミスタイプしやすい。

手順は以下を参考にさせていただきました。

ついでに、私の場合、拡張子なしのファイルは gVim で開くように設定しています。これは Windows の機能ですが。
Vagrantfile とか、Dockerfile を編集するのに便利です。

こちらの手順は以下を参考にさせていただきました。

以上です。

WebLogic Server 12.2.1で、動的クラスターの自動スケーリングを試してみた

WebLogic Server 12cR2では、クラスターのメンバーを自動的に増減する機能が追加されました。この機能では、スケジュールベース、メトリックベースの動的スケーリングをサポートしています。

  • スケジュールベース
    • 予め指定されたスケジュールで、クラスターメンバーの増減を行います
    • (例)決められた曜日/時刻が来たら、サーバーを追加して予想される負荷に対応
  • メトリックベース
    • 指定したメトリックの値が、一定の値を超えるなどした場合に、クラスターメンバーの増減を行います。
    • (例)所定の時間内に一定数以上のリクエストを検出したらサーバーを追加し、突発的な負荷に対応

今回は、スケジュールベースの自動スケーリングを試して見ます。

構成手順

0. (準備)マシンを構成する

追加されるクラスターメンバーを稼働させるためのマシンを、予め構成しておきます。

  • 管理サーバーとは別のホストに、管理対象サーバーを一台構成
  • 上記管理サーバーに対し、マシンを構成。マシン名は"Machine-wlsmanaged0"
  • クラスターメンバーへのアクセス用に以下のポートを開放
    • 7101
    • 7102
    • 8101
    • 8102

本記事では、上記の様な構成を実施済みであるものとします。

1. 動的クラスターを作成する

まずはメンバーの増減を試すための動的クラスターを作成します。

WebLogic Server管理コンソールにアクセスし、[チェンジセンター] の [ロックして編集] をクリックします。

f:id:charlier_shoe:20160121154853p:plain

[クラスターのサマリー] で、[新規] > [動的クラスタ] の順にクリックします。

f:id:charlier_shoe:20160121154912p:plain

[新規動的クラスタの作成] で、以下のように値を設定し、[次] をクリックします。

  • 名前: DynamicCluster0(任意の名前でよい)
  • メッセージング・モード: ユニキャスト
  • (他はデフォルトのまま)

f:id:charlier_shoe:20160121154929p:plain

次の画面(画面名は同じ)で、以下のように値を設定し、[次] をクリックします。

  • 動的クラスタ・サイズ: 1
  • (他はデフォルトのまま)

f:id:charlier_shoe:20160121154945p:plain

次の画面(画面名は同じ)で、以下のように値を設定し、[次] をクリックします。
(今回は管理対象サーバーを1台しか構成しないので、単一のマシン上にクラスターメンバーが追加されるようにします)

  • ラジオボックス: すべての動的サーバーに単一マシンを使用する
  • 選択したマシン: Machine-wlsmanaged0

f:id:charlier_shoe:20160121155004p:plain

次の画面ではデフォルトのまま [次]をクリックします。

f:id:charlier_shoe:20160121155017p:plain

次は確認画面です。[終了] をクリックします。

f:id:charlier_shoe:20160121155035p:plain

最後に、[チェンジセンター] > [変更のアクティブ化] をクリックして、これまでの作業をサーバーに反映させます。

これで動的クラスターの作成は完了です。

2. 診断モジュールを作成する

動的クラスターの自動スケーリングは、WebLogic診断フレームワークの一機能として提供されています。
診断モジュールを構成して、ポリシーとアクション(12.1.3以前の「監視」、「通知」が改名)を設定しておくことで、自動スケーリングを実現できます。今回の場合、

  • ポリシー: 毎日 06:00(06:05) に
  • アクション: スケールアップ(ダウン)を実行する

という設定をします。

2-1. 診断モジュールを作成する

まずは診断モジュールを構成します。

まずはWebLogic Server管理コンソールにアクセスし、[チェンジセンター] の [ロックして編集] をクリックします。

次に、[ドメイン構造] の [診断] > [診断モジュール] を選択し、[診断モジュールのサマリー] で、[新規] をクリックします。

f:id:charlier_shoe:20160121155219p:plain

[診断システム・モジュールの作成] で、以下のように値を設定し、[OK] をクリックします。

  • 名前: CalendarBasedScalingModule
  • 説明: カレンダーベースで、動的クラスターを自動スケーリングします。(任意の説明書きでよい)
  • (他はデフォルトのまま)

f:id:charlier_shoe:20160121155238p:plain

2-2. 診断モジュールにポリシー/アクションを設定する

続いて、診断モジュールにポリシーを設定します。ポリシーの設定を行う操作の中で、アクションの作成も併せて行います。

まずはスケールアップのポリシー/アクションからです。
今回は毎日 06:00(UTC) に、クラスターメンバーが1つ追加されるようにします(タイムゾーンUTCなのは、私が利用している環境の都合です)。

[ドメイン構造] の [診断] > [診断モジュール] を選択し、診断システムモジュールの一覧から、"CalendarBasedScalingModule" をクリックします。

f:id:charlier_shoe:20160121155305p:plain

[CalendarBasedScalingModuleの設定] で、[構成]、[ポリシーとアクション] タブを順に選択します。
更に、画面下方のポリシーの一覧で、[新規] をクリックします。

f:id:charlier_shoe:20160121155330p:plain

[ポリシーの作成] で、以下のように値を設定し、[次] をクリックします。

  • ポリシー名: 06-00-00 UTC everyday(任意の名前でよい)
  • ポリシー・タイプ: カレンダー・ベース
  • (他はデフォルトのまま)

f:id:charlier_shoe:20160121155349p:plain

次の画面(画面名は同じ)で、以下のように値を設定し、[次] をクリックします。

  • 頻度: カスタム

f:id:charlier_shoe:20160121155403p:plain

次の画面(画面名は同じ)で、以下のように値を設定し、[次] をクリックします。

f:id:charlier_shoe:20160121155418p:plain

次の画面(画面名は同じ)ではデフォルトのまま [次]をクリックします。

f:id:charlier_shoe:20160121155435p:plain

次の画面(画面名は同じ)では、ラジオボタンで [アクションのスケール・アップ] を選択し、[新規スケール・アップ・アクション] をクリックします。

f:id:charlier_shoe:20160121155455p:plain

次の画面(画面名は同じ)では、アクションの作成をおこないます。以下のように値を設定し、[次] をクリックします。

  • アクション名: ScaleUp(任意の名前でよい)
  • (他はデフォルトのまま)

f:id:charlier_shoe:20160121155520p:plain

次の画面(画面名は同じ)は、まだアクションの作成の続きです。以下のように値を設定し、[終了] をクリックします。

  • クラスタ名: DynamicCluster0(最初に作った動的クラスターを選択)
  • スケーリング・サイズ: 1

f:id:charlier_shoe:20160121155534p:plain

ポリシーの作成に戻ります。以下のように値を設定し、[終了] をクリックします。ここまでで、スケールアップのポリシー/アクションの作成は完了です。

  • スケール・アップ・アクションの選択: ScaleUp(作成したアクションの名前に合わせる)
  • (他はデフォルトのまま)

f:id:charlier_shoe:20160121155555p:plain

スケールダウンのポリシー/アクションも同様に作成します。
毎日 06:05(UTC) に、クラスターメンバーが1つ削減されるようにします。
スケールアップと要領は同じなので画面イメージは省略しますが、以下の様に値を設定するようにします。

  • [ポリシーの作成] 画面 1枚目
    • ポリシー名: 06-05-00 UTC everyday(任意の名前でよい)
    • ポリシー・タイプ: カレンダー・ベース
    • (他はデフォルトのまま)
  • [ポリシーの作成] 画面 2枚目
    • 頻度: カスタム
  • [ポリシーの作成] 画面 3枚目
  • [ポリシーの作成] 画面 4枚目
    • (デフォルトのまま)
  • [ポリシーの作成] 画面 5枚目
    • ラジオボタン: アクションのスケールダウン
    • スケール・ダウン・アクションの選択: ScaleDown(先に[新規スケール・ダウン・アクション]をクリックして、同名のアクションを作っておきます)
  • [ポリシーの作成] 画面のアクションの作成部分 1枚目
    • アクション名: ScaleUp(任意の名前でよい)
    • (他はデフォルトのまま)
  • [ポリシーの作成] 画面のアクションの作成部分 2枚目
    • クラスタ名: DynamicCluster0(最初に作った動的クラスターを選択)
    • スケーリング・サイズ: 1

これでポリシー/アクションの作成は完了です。

念のため、ポリシー、アクションが作成されているか確認してみます。

[ドメイン構造] の [診断] > [診断モジュール] を選択し、診断システムモジュールの一覧から、"CalendarBasedScalingModule" をクリックします。
更に、[CalendarBasedScalingModuleの設定] で、[構成]、[ポリシーとアクション] タブを順に選択します。

画面下部のポリシーの一覧に、以下のように2つのポリシーが表示されます。

f:id:charlier_shoe:20160121155635p:plain

[アクション] タブをクリックしてアクションの一覧に切り替えると、以下のように2つのアクションが表示されます。

f:id:charlier_shoe:20160121155648p:plain

2-3. 診断モジュールのターゲットを設定する

[ドメイン構造] の [診断] > [診断モジュール] を選択し、診断システムモジュールの一覧から、"CalendarBasedScalingModule" をクリックします。
更に、[CalendarBasedScalingModuleの設定] で、[ターゲット] タブを選択します。

[AdminServer] のチェックボックスをオンにして、[保存] をクリックします。

f:id:charlier_shoe:20160121155713p:plain

ここまでで、診断モジュールの全ての設定が完了しました。最後に、[チェンジセンター] > [変更のアクティブ化] をクリックして、これまでの作業をサーバーに反映させます。

後は動作確認を残すのみ…。

動作確認

いよいよ動作確認です。

動的クラスターを作成した際に、それに属するサーバーが1つ構成されていますので、予め起動しておきます。

[ドメイン構造] の [環境] > [サーバー] を選択し、[サーバーのサマリー] 画面で [制御] タブをクリックします。 "DynamicCluster0-1" というサーバーができているので、これに対応するチェックボックスをONにして、[起動] をクリックします。

f:id:charlier_shoe:20160121155758p:plain

続く確認画面で、[はい] を選択すると、サーバーの起動は完了です。

f:id:charlier_shoe:20160121155814p:plain

後は、メトリックブラウザでクラスターメンバー数のモニタリングを設定しつつ、時間が来るのを待ちます…。

結果はこちら。

f:id:charlier_shoe:20160121155836p:plain

あれ、06:00にスケールアップはできていますが、06:05になってもメンバーが減らない…。

管理サーバーのログを確認して見たところ、以下の様なエラーが記録されていました。どうやら、スケールアップ後にもう少し時間を置かないと、続くスケーリングは失敗するようです。

#### <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <0c8309f6-60d6-4929-904a-472ef040511f-0000005e> <1453269900660> <[severity-value: 8] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-2192046> during execute operation. Requested resolution is FAIL. Reason: Scaling operation failed because the cluster DynamicCluster0 is in cool-off period and cannot be scaled for another 624 seconds.>

※このあと設定を変えて再挑戦し、期待通り動作することを確認しております。

以上、動的クラスターの自動スケーリング機能の検証でした。

Oracle Database Express EditionにjBatchのJobRepositoryを構成する(Dockerコンテナもあります)

jBatchを使うには、JobRepositoryと呼ばれる、ジョブのステータスやシリアライズされたcheckpointinfoを保持するデータベースが必要です。
Oracle WebLogic Serverでは、デフォルトではDerbyの組み込みデータベースを利用しています。しかし、これはあくまで開発用で、本番環境はもちろん、UTより後のテスト工程では別途データベースを構成する必要があるものと思います。

今回は、Oracle Database Express Editionを使ってJobRepositoryを構成して見たので、手順を紹介します。

1. データベースにJobRepository用のスキーマを作成する

まず、WebLogic Server 12.2.1がインストールされた環境から、テーブルを作成するためのスクリプトを取得します。
スクリプトは、以下のパスに格納されています。

${ORACLE_HOME}/oracle_common/common/sql/wlservices/batch/Oracle

今回は、このパス配下のスクリプトを、DBサーバーの "/tmp/jbatch/" にコピーしておきます。

続いて、DB上にJobRepository用のユーザーを作成し、必要なアクセス権を付与します。
例えば以下の様な感じです。

$ sqlplus system/oracle
SQL> CREATE USER repuser IDENTIFIED BY reppswd
  2  DEFAULT TABLESPACE USERS
  3  TEMPORARY TABLESPACE TEMP
  4  ;
SQL> GRANT CONNECT, RESOURCE TO repuser;

作成したユーザーで再接続し、テーブルを作成するスクリプトを実行します。

SQL> CONNECT repuser/reppswd;
SQL> @/tmp/jbatch/jbatch.sql

2. JobRepositroryに接続するためのデータソースを作成する

データソースの作成は、WebLogic Server管理コンソールから行います。

管理コンソールにアクセスして、チェンジ・センターの[ロックして編集]ボタンをクリックします。

f:id:charlier_shoe:20160114020753p:plain

ドメイン構造の、[${ドメイン名}] > [サービス] > [データ・ソース]を選択します。

f:id:charlier_shoe:20160114020757p:plain

[JDBCデータ・ソースのサマリー]で、[新規] > [汎用データソース]を選択します。

f:id:charlier_shoe:20160114020801p:plain

[JDBCデータ・ソースのプロパティ]画面で、以下の値を設定し、[次]をクリックします。

  • 名前: (任意の名前)
  • スコープ: グローバル
  • JNDI名: (任意のJNDI名)
  • データベースのタイプ: Oracle

f:id:charlier_shoe:20160114020944p:plain

[JDBCデータ・ソースのプロパティ]画面(2枚目)で、以下の値を設定し、[次]をクリックします*1

  • データベース・ドライバ: Oracle's Driver (Thin XA) for Instance connections; Versions:Any

f:id:charlier_shoe:20160114020950p:plain

[トランザクション・オプション]画面では設定する項目はありません。[次]をクリックします。

f:id:charlier_shoe:20160114020956p:plain

[接続プロパティ]画面で、以下の値を設定し、[次]をクリックします。

  • データベース名: (データベースのSID)
  • ホスト名: (DBサーバーのホスト名またはIPアドレス
  • ポート: (DBのポート。Oracle DBでは1521が基本)
  • データーベース・ユーザー名: repuser
  • パスワード: reppswd

f:id:charlier_shoe:20160114021051p:plain

[データーベース接続のテスト]画面で[構成のテスト]をクリックして、接続テストが成功することを確認します。問題なければ[次]をクリックします。

f:id:charlier_shoe:20160114021106p:plain

[ターゲットの選択]画面で、バッチアプリケーションをデプロイする予定のターゲットを選択し、[終了]をクリックします。

f:id:charlier_shoe:20160114021123p:plain

3. バッチジョブとデータソースの関連付けの設定をおこなう

最後に、2.で作成したデータソースを、JobRepositoryにアクセスするときに利用するデータソースとして登録します。

ドメイン構造の[${ドメイン名}]をクリックし、画面右のタブで[構成] > [バッチ]を選択します。

以下の値を設定し、[保存]をクリックします。

  • データソースJNDI名: (2.の[JDBCデータ・ソースのプロパティ]画面(一枚目)で指定したJNDI名)
  • スキーマ名: repuser

f:id:charlier_shoe:20160114021136p:plain

最後に[チェンジ・センター]で[変更のアクティブ化]をクリックすると、必要な設定は完了です。

試しに、前回の記事で紹介したサンプルアプリを動かしてみたところ、ちゃんと結果が表示されることが確認できました。

f:id:charlier_shoe:20160114021145p:plain

上の画面は、ドメイン構造の[${ドメイン名}]をクリックし、画面右のタブで[モニタリング] > [バッチ・ジョブ]を選択すると表示されます。

おまけ: JobRepostitoryを構成済みの、Oracle Database XEのDockerコンテナ

JobRepositoryを構成済みのDockerコンテナを作成する、スクリプトを作ってみました。こちらはgithubに公開してあります。
ベースとなるOracle Express Editionのイメージはwnamelessさんのものを利用させて頂いています。

ダウンロードしたら、tablesフォルダに上記のsqlスクリプト群を配置し、以下のコマンドを実行してください。

$ docker build -t [タグ名] ./
$ docker run  sudo docker run -d -p 1521:1521 --name=[コンテナ名] [タグ名]

JobRepositoryのユーザー名、パスワードは以下のとおりとなっています。この辺はDockerfileを適当に編集して、好きなものに変更してください。

  • ユーザー名: repuser
  • パスワード: reppswd

*1:マニュアルによると、JobRepositoryへのアクセスに使用するデータ・ソースは、XAトランザクションに対応したドライバを使用する必要があります