設定ガイド

Red Hat JBoss Enterprise Application Platform 7.3

Red Hat JBoss Enterprise Application Platform 7.3 向け

Red Hat Customer Content Services

概要

本書は、JBoss EAP の設定や維持に必要な設定タスクと、JBoss EAP でアプリケーションやその他のサービスを稼働するために必要な設定タスクの多くを取り上げることを目的としています。

第1章 はじめに

本ガイドを使用して JBoss EAP を設定する前に、最新バージョンの JBoss EAP がダウンロードされ、インストールされていることを確認してください。インストールの手順は、『インストールガイド』を参照してください。

重要

ホストマシンによって JBoss EAP をインストールする場所が異なるため、本ガイドではインストール場所を EAP_HOME と示しています。管理タスクを行う際には、 EAP_HOME を実際の JBoss EAP のインストール場所に置き換えてください。

第2章 JBoss EAP の開始および停止

2.1. JBoss EAP の開始

JBoss EAP は、Red Hat Enterprise Linux、Windows Server、および Oracle Solaris でサポートされ、スタンドアロンサーバーまたは管理対象ドメイン操作モードで実行されます。JBoss EAP を起動するコマンドは、基盤のプラットフォームと選択する操作モードによって異なります。

サーバーは最初に一時停止状態で起動され、必要なサービスがすべて起動するまでリクエストを受け入れません。 必要なサービスがすべて起動すると、サーバーは通常の稼働状態となり、リクエストの受け入れを開始します。

JBoss EAP をスタンドアロンサーバーとして起動

$ EAP_HOME/bin/standalone.sh
注記

Windows Server の場合は、EAP_HOME\bin\standalone.bat スクリプトを使用します。

この起動スクリプトは、EAP_HOME/bin/standalone.conf ファイル (Windows Server の場合は standalone.conf.bat) を使用して、JVM オプションなどのデフォルト設定の一部を設定します。このファイルで設定をカスタマイズできます。

JBoss EAP はデフォルトで standalone.xml 設定ファイルを使用しますが、別の設定ファイルを使用して起動することもできます。利用できるスタンドアロン設定ファイルとそれらの使用方法については、「スタンドアロンサーバー設定ファイル」の項を参照してください。

使用できる起動スクリプトの引数の完全リストとそれら引数の目的については、--help 引数を使用するか、「サーバーランタイム引数」を参照してください。

管理対象ドメインでの JBoss EAP の起動

ドメイン内のサーバーグループのサーバーを起動する前にドメインコントローラーを起動する必要があります。このスクリプトを使用して最初にドメインコントローラーを起動した後、関連するホストコントローラーに対して使用します。

$ EAP_HOME/bin/domain.sh
注記

Windows Server の場合は EAP_HOME\bin\domain.bat スクリプトを使用します。

この起動スクリプトは、EAP_HOME/bin/domain.conf ファイル (Windows Server の場合は standalone.conf.bat) を使用して、JVM オプションなどのデフォルト設定の一部を設定します。このファイルで設定をカスタマイズできます。

JBoss EAP はデフォルトで host.xml ホスト設定ファイルを使用しますが、別の設定ファイルを使用して起動することもできます。利用できる管理対象ドメイン設定ファイルとそれらの使用方法については、「管理対象ドメイン設定ファイル」の項を参照してください。

管理対象ドメインを設定するとき、追加の引数を起動スクリプトに渡す必要があります。使用できる起動スクリプトの引数の完全リストとそれら引数の目的については、--help 引数を使用するか、「サーバーランタイム引数」を参照してください。

2.2. JBoss EAP の停止

JBoss EAP の停止方法は、開始した方法によって異なります。

JBoss EAP の対話的なインスタンスの停止

JBoss EAP を起動したターミナルで Ctrl+C を押します。

JBoss EAP のバックグラウンドインスタンスの停止

管理 CLI を使用して、稼働中のインスタンスへ接続し、サーバーをシャットダウンします。

  1. 管理 CLI を起動します。

    $ EAP_HOME/bin/jboss-cli.sh --connect
  2. shutdown コマンドを実行します。

    shutdown
注記

管理対象ドメインで実行している場合、shutdown コマンドに --host 引数を使用してシャットダウンする、ホスト名を指定する必要があります。

2.3. JBoss EAP の管理専用モードでの実行

JBoss EAP は管理専用モードで起動することができます。管理専用モードでは、JBoss EAP は管理リクエストを実行および許可できますが、その他のランタイムサービスを起動したりエンドユーザーリクエストを許可したりすることはできません。管理専用モードは スタンドアロンサーバー管理対象ドメイン の両方で使用できます。

管理専用モードでのスタンドアロンサーバーの実行

管理専用モードでのサーバーの起動

JBoss EAP インスタンスを管理専用モードで起動するには、JBoss EAP インスタンスの起動時に --start-mode=admin-only ランタイム引数を使用します。

$ EAP_HOME/bin/standalone.sh --start-mode=admin-only
サーバーが管理専用モードで実行されていることを確認

以下のコマンドを実行して、サーバーの実行モードを確認します。サーバーが管理専用モードで実行されている場合は、結果が ADMIN_ONLY になります。

:read-attribute(name=running-mode)
{
  "outcome" => "success",
  "result" => "ADMIN_ONLY"
}
注記

さらに、以下のコマンドを使用すると、JBoss EAP が起動された最初の実行モードを確認することもできます。

/core-service=server-environment:read-attribute(name=initial-running-mode)
管理 CLI から別のモードでリロード

異なるランタイムスイッチを使用して JBoss EAP インスタンスを停止および起動する他に、管理 CLI を使用して異なるモードでリロードすることもできます。

サーバーを管理専用モードでリロードするには、以下を実行します。

reload --start-mode=admin-only

サーバーを通常モードでリロードするには、以下を実行します。

reload --start-mode=normal

サーバーが管理専用モードで起動され、reload コマンドに --start-mode 引数の指定がない場合は、サーバーは通常モードで起動されます。

管理専用モードでの管理対象ドメインの実行

管理対象ドメインの場合、ドメインコントローラーが管理専用モードで起動されると、スレーブホストコントローラーからの受信接続を許可しません。

管理専用モードでのホストコントローラーの起動

--admin-only ランタイム引数を渡してホストコントローラーを管理専用モードで起動します。

$ EAP_HOME/bin/domain.sh --admin-only
ホストコントローラーが管理専用モードで実行されていることを確認

以下のコマンドを実行して、ホストコントローラーの実行モードを確認します。ホストコントローラーが管理専用モードで実行されている場合は、結果が ADMIN_ONLY になります。

/host=HOST_NAME:read-attribute(name=running-mode)
{
  "outcome" => "success",
  "result" => "ADMIN_ONLY"
}
管理 CLI から別のモードでリロード

異なるランタイムスイッチを使用してホストコントローラーを停止および起動する他に、管理 CLI を使用して異なるモードでリロードすることもできます。

ホストコントローラーを管理専用モードでリロードするには、以下を実行します。

reload --host=HOST_NAME --admin-only=true

ホストコントローラーを通常モードでリロードするには、以下を実行します。

reload --host=HOST_NAME --admin-only=false

ホストコントローラーが管理専用モードで起動され、reload コマンドに --start-mode 引数の指定がない場合は、ホストコントローラーは通常モードで起動されます。

2.4. JBoss EAP の正常な一時停止およびシャットダウン

JBoss EAP は正常に一時停止およびシャットダウンできます。これにより、新しいリクエストを許可せずにアクティブなリクエストを正常に完了できます。タイムアウト値は、一時停止またはシャットダウン操作がアクティブなリクエストの完了まで待つ期間を指定します。サーバーが一時停止しても管理リクエストは処理されます。

正常なシャットダウンは、リクエストがサーバーに入るエントリーポイントを中心にサーバー全体のレベルで調整されます。以下のサブシステムが正常なシャットダウンをサポートします。

Undertow
undertow サブシステムはすべてのリクエストが終了するまで待機します。
mod_cluster
modcluster サブシステムは PRE_SUSPEND フェーズでサーバーが一時停止することをロードバランサーに通知します。
EJB
ejb3 サブシステムはすべてのリモート EJB リクエストおよび MDB メッセージ配信が終了するまで待機します。MDB への配信は PRE_SUSPEND フェーズで停止します。EJB タイマーは中断され、サーバーが再開したときにタイマーがアクティベートされます。
Transactions

サーバーは一時停止すると新しいリクエストを受け付けませんが、インフライトトランザクションおよびリクエストは完了するかタイムアウトが期限切れになるまで継続されます。これは、XTS トランザクションに関連する web サービスリクエストも同様です。

注記

デフォルトでは、ejb サブシステムでのトランザクションの正常シャットダウンは無効になっています。EJB 関連のトランザクションが完了してからサーバーを一時停止する場合は、トランザクションの正常シャットダウンを有効にする必要があります。例を以下に示します。

/subsystem=ejb3:write-attribute(name=enable-graceful-txn-shutdown,value=true)
EE Concurrency

サーバーはすべてのアクティブなジョブが終了するまで待機します。キューに置かれたジョブはすべてスキップされます。現在、EE Concurrency には永続性がないため、キューに置かれスキップされたジョブは失われます。

サーバーが一時停止状態である間、スケジュールされたタスクはスケジュールどおりの時間に実行されますが、java.lang.IllegalStateException が発生します。サーバーが再開されると、スケジュールされたタスクは通常どおり実行され、ほとんどの場合でタスクのスケジュールを変更する必要はありません。

Batch
サーバーはタイムアウト期間内の実行中のジョブをすべて停止し、スケジュール済みのジョブをすべて延期します。
注記

現在、正常シャットダウンは新しいインバウンド JMS メッセージを拒否しません。インフライトアクティビティーによってスケジュールされた EE バッチジョブおよび EE 同時実行タスクは、現在実行の継続が許可されます。しかし、タイムアウトウインドウを渡す EE 同時実行タスクが提出されると、実行時にエラーが発生します。

リクエストは request-controller サブシステムによって追跡されます。このサブシステムがないと、一時停止および再開機能が制限され、リクエストの完了を待たずにサーバーが一時停止またはシャットダウンします。 しかし、この機能が必要ない場合は、request-controller サブシステムを削除してパフォーマンスを若干向上することができます。

2.4.1. サーバーの一時停止

JBoss EAP 7 には、サーバーの操作を正常に一時停止する suspend モードが導入されました。このモードでは、アクティブなリクエストがすべて正常に完了されますが、新しいリクエストは許可されません。サーバーが中断されたら、シャットダウンすることができます。 さらに、元の実行状態に戻ったり、中断状態のままメンテナンスを実行することができます。

注記

管理インターフェースのサーバーの一時停止よる影響はありません。

管理コンソールまたは管理 CLI を使用するとサーバーを一時停止および再開できます。

サーバーの一時停止状態のチェック

以下の管理 CLI コマンドを使用するとサーバーの中断状態を表示できます。結果の値は、RUNNINGPRE_SUSPENDSUSPENDING、または SUSPENDED のいずれかになります。

  • スタンドアロンサーバーの中断状態をチェックします。

    :read-attribute(name=suspend-state)
  • 管理対象ドメインのサーバーの中断状態をチェックします。

    /host=master/server=server-one:read-attribute(name=suspend-state)
中断

アクティブなリクエストが完了するまでサーバーが待機するタイムアウト値を秒単位で指定し、以下の管理 CLI コマンドを使用してサーバーを中断します。デフォルト値は 0 で、即座に中断します。-1 を値として指定すると、サーバーはアクティブなリクエストがすべて完了するまで無期限に待機します。

以下の各例は、リクエストが完了するまで最大 60 秒待機した後、一時停止します。

  • スタンドアロンサーバーを一時停止します。

    :suspend(suspend-timeout=60)
  • 管理対象ドメインのすべてのサーバーを一時停止します。

    :suspend-servers(suspend-timeout=60)
  • 管理対象ドメインの単一のサーバーを一時停止します。

    /host=master/server-config=server-one:suspend(suspend-timeout=60)
  • サーバーグループのすべてのサーバーを一時停止します。

    /server-group=main-server-group:suspend-servers(suspend-timeout=60)
  • ホストレベルですべてのサーバーを一時停止します。

    /host=master:suspend-servers(suspend-timeout=60)
再開

resume コマンドは、新しいリクエストを受け入れるために、サーバーを通常の実行状態に戻します。ホスト、サーバー、サーバーグループ、またはドメインレベルでコマンドを起動できます。例を以下に示します。

:resume
サーバーを一時停止状態で起動

サーバーを一時停止状態で起動し、サーバーが再開するまでリクエストを受け入れないようにすることができます。

  • スタンドアロンサーバーを一時停止状態で起動するには、JBoss EAP インスタンスの起動時に --start-mode=suspend ランタイム引数を使用します。

    $ EAP_HOME/bin/standalone.sh --start-mode=suspend
  • 管理対象ドメインサーバーを一時停止モードで起動するには、管理 CLI コマンドで start-mode=suspend 引数を start 操作に渡します。

    /host=HOST_NAME/server-config=SERVER_NAME:start(start-mode=suspend)
    注記

    start-mode 引数をサーバーの reload および restart 操作に渡すこともできます。

  • 管理対象ドメインサーバーグループのすべてのサーバーを一時停止モードで起動するには、管理 CLI コマンドで start-mode=suspend 引数を start-servers 操作に渡します。

    /server-group=SERVER_GROUP_NAME:start-servers(start-mode=suspend)
    注記

    start-mode 引数をサーバーグループの reload-servers および restart-servers 操作に渡すこともできます。

2.4.2. 管理 CLI を使用したサーバーの正常なシャットダウン

サーバーの停止時に適切なタイムアウト値を指定すると、サーバーは正常にシャットダウンされます。コマンドを実行するとサーバーが一時停止され、すべてのリクエストが完了するまで最大で指定のタイムアウトの期間待機し、その後シャットダウンします。

以下の管理 CLI コマンドを使用してサーバーを正常にシャットダウンします。アクティブなリクエストが完了するまでサーバーが待機するタイムアウト値を秒単位で指定します。デフォルト値は 0 で、即座にサーバーをシャットダウンします。-1 を値として指定すると、アクティブなリクエストがすべて完了するまで無期限に待機した後、シャットダウンします。

以下の各例は、リクエストが完了するまで最大 60 秒待機した後、シャットダウンします。

  • スタンドアロンサーバーを正常にシャットダウンします。

    shutdown --suspend-timeout=60
  • 管理対象ドメインのすべてのサーバーを停止します。

    :stop-servers(suspend-timeout=60)
  • 管理対象ドメインの単一のサーバーを停止します。

    /host=master/server-config=server-one:stop(suspend-timeout=60)
  • サーバーグループのすべてのサーバーを正常に停止します。

    /server-group=main-server-group:stop-servers(suspend-timeout=60)
  • ホストコントローラーと、管理対象のサーバーをすべてシャットダウンします。

    /host=master:shutdown(suspend-timeout=60)
    注記

    suspend-timeout 属性は、ホストコントローラー自体ではなく、ホストコントローラーが管理するサーバーにのみ適用されます。

2.4.3. OS シグナルを使用したサーバーの正常なシャットダウン

kill -15 PID などで OS TERM シグナルを送信すると、サーバーを正常にシャットダウンできます。デフォルトでは、この値は管理 CLI の shutdown --suspend-timeout=0 コマンドの値と同じであるため、現在処理中のリクエストを即座に終了できます。タイムアウトは、org.wildfly.sigterm.suspend.timeout システムプロパティーで設定でき、サーバーのシャットダウン前に待機する最大秒数を指定します。-1 を値として指定すると、サーバーは永久に待機します。

重要

管理対象ドメインでは、OS シグナルを使用してサーバーをシャットダウンしないでください。サーバーは、管理するホストコントローラーより 管理 CLI を使用してシャットダウン してください。

シグナルの処理を無効にするよう JVM が設定された場合 (-Xrs java 引数が JVM オプションに渡された場合など) や、プロセスが送信されたシグナルに応答できない場合 (KILL シグナルが送信された場合など)、OS シグナルを使用して正常にシャットダウンすることはできません。

2.5. JBoss EAP の起動および停止 (RPM インストール)

RPM インストールの場合、JBoss EAP の起動と停止が ZIP またはインストーラーインストールの場合とは異なります。

2.5.1. JBoss EAP の起動 (RPM インストール)

RPM インストールの JBoss EAP を起動するコマンドは、開始する操作モード (スタンドアロンサーバーまたは管理対象ドメイン) や実行している Red Hat Enterprise Linux のバージョンによって異なります。

JBoss EAP をスタンドアロンサーバーとして起動 (RPM インストール)
  • Red Hat Enterprise Linux 6 の場合

    $ service eap7-standalone start
  • Red Hat Enterprise Linux 7 以降の場合:

    $ systemctl start eap7-standalone.service

これにより、standalone.xml 設定ファイルをデフォルトで使用して JBoss EAP が起動されます。JBoss EAP を別の スタンドアロンサーバー設定ファイル で起動するには、RPM サービス設定ファイルにプロパティーを設定します。詳細は「RPM サービスプロパティーの設定」の項を参照してください。

管理対象ドメインでの JBoss EAP の起動 (RPM インストール)
  • Red Hat Enterprise Linux 6 の場合

    $ service eap7-domain start
  • Red Hat Enterprise Linux 7 以降の場合:

    $ systemctl start eap7-domain.service

これにより、host.xml 設定ファイルをデフォルトで使用して JBoss EAP が起動されます。JBoss EAP を別の 管理対象ドメイン設定ファイル で起動するには、RPM サービス設定ファイルにプロパティーを設定します。詳細は「RPM サービスプロパティーの設定」の項を参照してください。

RPM サービスプロパティーの設定

本項では、RPM サービスプロパティーと JBoss EAP インストールのその他の起動オプションを設定する方法について説明します。変更を行う前に設定ファイルをバックアップすることが推奨されます。

RPM インストールで利用可能な起動オプションの完全リストは、「RPM サービス設定プロパティー」の項を参照してください。

重要

Red Hat Enterprise Linux 7 以降では、RPM サービス設定ファイルは systemd を使用してロードされるため、変数式は拡張されません。

  • サーバー設定ファイルを指定します。

    スタンドアロンサーバーを起動する場合、デフォルトで standalone.xml ファイルが使用されます。管理対象ドメインで実行する場合、デフォルトで host.xml ファイルが使用されます。他の設定ファイルを使用して JBoss EAP を起動するには、適切な RPM 設定ファイル (例: eap7-standalone.conf) に WILDFLY_SERVER_CONFIG プロパティーを設定します。

    WILDFLY_SERVER_CONFIG=standalone-full.xml
  • 特定の IP アドレスにバインドします。

    デフォルトでは、JBoss EAP RPM インストールは 0.0.0.0 にバインドします。JBoss EAP を特定の IP アドレスにバインドするには、適切な RPM 設定ファイル (例: eap7-standalone.conf) に WILDFLY_BIND プロパティーを設定します。

    WILDFLY_BIND=192.168.0.1
    注記

    管理インターフェースを特定の IPアドレスにバインドする場合は、次の例のように JBoss EAP 起動設定ファイルに設定を追加します。

  • JVM オプションまたは Java プロパティーを設定します。

    JBoss EAP の起動スクリプトに渡す JVM オプションまたは Java プロパティーを指定するには、起動設定ファイルを編集します。スタンドアロンサーバーの場合、このファイルは EAP_HOME/bin/standalone.conf になります。管理対象ドメインの場合、このファイルは EAP_HOME/bin/domain.conf になります。以下の例は、ヒープサイズを設定し、JBoss EAP 管理インターフェースを指定の IP アドレスにバインドします。

    JAVA_OPTS="$JAVA_OPTS -Xms2048m -Xmx2048m"
    JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address.management=192.168.0.1"
    注記

    場合によっては、標準の jboss.bind.address プロパティーを使用せずに WILDFLY_BIND プロパティーを使用して JBoss EAP バインドアドレスを設定する必要があります。

注記

同じ名前のプロパティーが RPM サービス設定ファイル (例: /etc/sysconfig/eap7-standalone) と JBoss EAP 起動設定ファイル (例:EAP_HOME/bin/standalone.conf) にある場合、JBoss EAP 起動設定ファイルのプロパティーの値が優先されます。このようなプロパティーの 1 つが JAVA_HOME です。

2.5.2. JBoss EAP の停止 (RPM インストール)

RPM インストールの JBoss EAP を停止するコマンドは、開始された操作モード (スタンドアロンサーバーまたは管理対象ドメイン) や実行している Red Hat Enterprise Linux のバージョンによって異なります。

JBoss EAP をスタンドアロンサーバーとして停止 (RPM インストール)
  • Red Hat Enterprise Linux 6 の場合

    $ service eap7-standalone stop
  • Red Hat Enterprise Linux 7 以降の場合:

    $ systemctl stop eap7-standalone.service
管理対象ドメインでの JBoss EAP の停止 (RPM インストール)
  • Red Hat Enterprise Linux 6 の場合

    $ service eap7-domain stop
  • Red Hat Enterprise Linux 7 以降の場合:

    $ systemctl stop eap7-domain.service

RPM インストールで利用可能な起動オプションの完全リストは、「RPM サービス設定ファイル」の項を参照してください。

2.6. PowerShell スクリプト (Windows Server)

重要

複数の PowerShell スクリプトはテクノロジープレビューとしてのみ提供されます。テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

JBoss EAP には、ほとんどの JBoss EAP 管理スクリプトに相当する PowerShell スクリプトが含まれています。これには、Microsoft Windows Server で JBoss EAP を起動する PowerShell スクリプトが含まれます。

JBoss EAP PowerShell スクリプトは、テストされた Windows Server バージョンで実行される PowerShell バージョン 2 以上で動作することを目的としています。

JBoss EAP PowerShell スクリプトは EAP_HOME\bin にあり、JBoss EAP のバッチスクリプトとほぼ同様に使用されます。

たとえば、standalone-full.xml 設定ファイルを使用してスタンドアロン JBoss EAP サーバーを起動するには、以下の PowerShell コマンドを使用します。

.\standalone.ps1 "-c=standalone-full.xml"
注記

JBoss EAP PowerShell スクリプトの引数は引用符で囲む必要があります。

第3章 JBoss EAP の管理

JBoss EAP は簡単な設定を使用し、スタンドアロンサーバーまたは管理対象ドメインごとに 1 つの設定ファイルを使用します。スタンドアロンサーバーのデフォルト設定は EAP_HOME/standalone/configuration/standalone.xml ファイルに保存され、管理対象ドメインのデフォルト設定は EAP_HOME/domain/configuration/domain.xml ファイルに保存されます。また、ホストコントローラーのデフォルト設定は EAP_HOME/domain/configuration/host.xml ファイルに保存されます。

JBoss EAP はコマンドラインの管理 CLI、Web ベースの管理コンソール、Java API、または HTTP API を使用して設定できます。これらの管理インターフェースを使用して加えられた変更は自動的に永続化され、XML 設定ファイルは管理 API によって上書きされます。管理 CLI と管理コンソールの使用が推奨され、XML 設定ファイルの手作業による編集は推奨されません。

3.1. サブシステム、エクステンション、およびプロファイル

JBoss EAP では、設定される機能の内容がサブシステムによって異なります。たとえば、アプリケーションおよびサーバーロギングが logging サブシステムに設定されます。

エクステンションは、サーバーのコア機能を拡張するモジュールです。エクステンションはデプロイメントが必要なときにロードされ、必要でなくなるとアンロードされます。『管理 CLI ガイド』で、テクステンションの追加方法および削除方法を確認してください。

サブシステム は特定のエクステンションの設定オプションを提供します。使用できるサブシステムの詳細は、「JBoss EAP サブシステムの概要」を参照してください。

サーバーの要求を満たすために設定される プロファイルは、複数のサブシステムで構成されます。スタンドアロンサーバーには名前のないプロファイルが 1 つあります。管理対象ドメインでは、ドメインのサーバーグループによって使用されるプロファイルを複数定義できます。

管理コンソールまたは管理 CLI の使用

JBoss EAP インスタンスの設定更新には管理コンソールと管理 CLI の両方を使用でき、サポートされます。どちらを使用するかはユーザーの好みによります。グラフィカルな Web ベースのインターフェースを好むユーザーは管理コンソールを使用する必要があります。コマンドラインインターフェースを好むユーザーは、管理 CLI を使用する必要があります。

3.2. 管理ユーザー

デフォルトの JBoss EAP 設定はローカル認証を提供するため、ユーザーは認証の必要なくローカルホスト上で管理 CLI にアクセスできます。

しかし、リモートで管理 CLI にアクセスする場合や管理コンソールを使用する場合 (トラフィックの送信元がローカルホストであってもリモートアクセスとして見なされます) は、管理ユーザーを追加する必要があります。管理ユーザーを追加せずに管理コンソールへアクセスしようとすると、エラーメッセージが出力されます。

グラフィカルインストーラーを使用して JBoss EAP がインストールされた場合は、インストールプロセス中に管理ユーザーが作成されます。

本ガイドでは、add-user スクリプトを使用した JBoss EAP の簡単なユーザー管理を取り上げます。 このスクリプトは既定の認証のプロパティーファイルに新しいユーザーを追加するためのユーティリティーです。

LDAP やロールベースアクセス制御 (RBAC) などの高度な認証および承認のオプションについては、JBoss EAP『セキュリティーアーキテクチャー』の「コア管理認証」を参照してください。

3.2.1. 管理ユーザーの追加

  1. add-user ユーティリティースクリプトを実行し、プロンプトに従います。

    $ EAP_HOME/bin/add-user.sh
    注記

    Windows Server の場合は、EAP_HOME\bin\add-user.bat スクリプトを使用します。

  2. ENTER を押して、デフォルトのオプション a を選択し、管理ユーザーを追加します。

    このユーザーは ManagementRealm に追加され、管理コンソールまたは管理 CLI を使用して管理操作を実行する権限が与えられます。代わりに b を選択すると、アプリケーションに使用される ApplicationRealm にユーザーが追加され、特定のパーミッションは提供されません。

  3. ユーザー名とパスワードを入力します。入力後、パスワードを確認するよう指示されます。

    注記

    ユーザー名には、以下の文字のみを使用できます。 文字の数と順番は自由です。

    • 英数字 (a-z、A-Z、0-9)
    • ダッシュ (-)、ピリオド (.)、コンマ (,)、アットマーク(@)
    • バックスラッシュ (\)
    • 等号 (=)

    デフォルトでは、脆弱なパスワードは許可されますが、警告が表示されます。

    このデフォルト動作の変更に関する詳細は、「Add-User ユーティリティーのパスワード制限の設定」を参照してください。

  4. ユーザーが属するグループのコンマ区切りリストを入力します。ユーザーがグループに属さないようにする場合は ENTER を押して空白のままにします。
  5. 情報を確認し、正しければ yes を入力します。
  6. このユーザーがリモート JBoss EAP サーバーインスタンスを表すかどうかを決定します。基本的な管理ユーザーの場合は no を入力します。

    ManagementRealm への追加が必要になることがあるユーザータイプの 1 つが、JBoss EAP の別のインスタンスを表すユーザーで、メンバーとしてクラスターに参加することを承認できる必要があります。この場合は、プロンプトで yes を選択すると、異なる設定ファイルに追加する必要がある、ユーザーのパスワードを表すハッシュ化された秘密の値が提供されます。

パラメーターを add-user スクリプトに渡すと、非対話的にユーザーを作成できます。ログや履歴ファイルにパスワードが表示されるため、この方法は共有システムでは推奨されません。詳細は「Add-User ユーティリティーを非対話的に実行」を参照してください。

3.2.2. Add-User ユーティリティーを非対話的に実行

コマンドラインで引数を渡すと add-user スクリプトを非対話的に実行することができます。最低でも、ユーザー名とパスワードを提供する必要があります。

警告

ログや履歴ファイルにパスワードが表示されるため、この方法は共有システムでは推奨されません。

複数のグループに属するユーザーの作成

以下のコマンドは、guest および mgmtgroup グループの管理ユーザー mgmtuser1 を追加します。

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'
代替プロパティーファイルの指定

デフォルトでは、add-user スクリプトを使用して作成されたユーザーおよびグループ情報は、サーバー設定ディレクトリーにあるプロパティーファイルに保存されます。

ユーザー情報は以下のプロパティーファイルに保存されます。

  • EAP_HOME/standalone/configuration/mgmt-users.properties
  • EAP_HOME/domain/configuration/mgmt-users.properties

グループ情報は以下のプロパティーファイルに保存されます。

  • EAP_HOME/standalone/configuration/mgmt-groups.properties
  • EAP_HOME/domain/configuration/mgmt-groups.properties

これらのデフォルトディレクトリーとプロパティーファイル名は上書きできます。以下のコマンドは、ユーザープロパティーファイルの名前と場所を指定して、新しいユーザーを追加します。

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser2' -p 'password1!' -sc '/path/to/standaloneconfig/' -dc '/path/to/domainconfig/' -up 'newname.properties'

新しいユーザーは /path/to/standaloneconfig/newname.properties および /path/to/domainconfig/newname.properties にあるユーザープロパティーファイルに追加されます。これらのファイルは存在している必要があり、存在しない場合はエラーが出力されます。

使用できる add-user のすべての引数の完全リストとそれら引数の目的については、--help 引数を指定するか「Add-User ユーティリティー引数」の項を参照してください。

3.2.3. Add-User ユーティリティーのパスワード制限

add-user ユーティリティースクリプトのパスワード制限は、EAP_HOME/bin/add-user.properties ファイルを使用して設定できます。

重要

add-user.properties ファイルは保護されていないプレーンテキストファイルです。コンテンツへの不正アクセスを回避するために保護する必要があります。

意図しないパスワードを設定しないようにするには、キーボードのシステムキーマップが正しいことを確認します。デフォルトのシステムキーマップは en-qwerty です。このデフォルト設定を変更して新しいパスワードを作成する場合は、SimplePasswordStrengthChecker クラスにある基準をパスワードが満たしていることを確認する必要があります。

JBoss EAP ではデフォルトで、脆弱なパスワードは許可されますが、警告が表示されます。指定の最低要件を満たさないパスワードを拒否するには、password.restriction プロパティーを REJECT に設定します。

以下の表は、EAP_HOME/bin/add-user.properties ファイルで設定できる追加のパスワード要件の設定を示しています。

表3.1 パスワード要件の追加設定

属性説明

minLength

パスワードの最小文字数。たとえば、password.restriction.minLength=8 はパスワードを最小文字に制限します。

strength

有効なパスワードに必要なしきい値を設定します。有効なしきい値エントリーには以下が含まれます。

* VERY_WEAK

* WEAK

* MODERATE

* MEDIUM

* STRONG

* VERY_STRONG

* EXCEPTIONAL

デフォルト値は MODERATE です。しきい値が定義され、そのデフォルト値が SimplePasswordStrengthChecker クラスに指定されます。

注記: しきい値を指定しない場合は、MODERATE がデフォルト値になります。この値は SimplePasswordStrengthChecker クラスに指定されます。

minAlpha

パスワードに設定されたアルファベットの最小文字数。たとえば、password.restriction.minAlpha=1 は、パスワードに最低 1 文字のアルファベット文字を含めるよう制限します。

minDigit

パスワードに設定された数字のの最小数。たとえば、password.restriction.minDigit=1 は、最低でも 1 つの数字を含むようにパスワードを制限します。

minSymbol

パスワードに設定された記号の最小数。たとえば、password.restriction.min=1 は、パスワードに記号を最低でも 1 文字含めるよう制限します。

forbiddenValue

簡単に思いつくパスワード (root など) を設定しないように、ユーザーを制限します。たとえば、password.restriction.forbidden=root,admin,administrator は、パスワードとして rootadmin、または administrator を設定できないように制限します。

mustNotMatchUsername

ユーザーがユーザー名をパスワードとして設定できないように制限します。たとえば、password.restriction.mustNotMatchUsername=TRUE と指定すると、ユーザーはユーザー名をパスワードとして設定できなくなります。false に設定すると、このルールは無視されます。

その他のリソース

Red Hat カスタマーポータルの「基本的なシステム設定の構成」を参照してください。

3.2.4. 管理ユーザーの更新

add-user ユーティリティースクリプトを使用し、プロンプトに従ってユーザー名を入力すると、既存の管理ユーザーの設定を更新できます。

$ EAP_HOME/bin/add-user.sh

What type of user do you wish to add?
 a) Management User (mgmt-users.properties)
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : test-user
User 'test-user' already exists and is enabled, would you like to...
 a) Update the existing user password and roles
 b) Disable the existing user
 c) Type a new username
(a):

すでに存在するユーザー名を入力すると、複数のオプションが出力されます。

  • 既存ユーザーのパスワードを更新する場合は a を入力します。
  • 既存ユーザーを無効にする場合は b を入力します。
  • 新しいユーザー名を入力する場合は c を入力します。
警告

add-user スクリプトを使用して非対話的にユーザーを更新すると、ユーザーは自動的に更新され、確認のプロンプトは表示されません。

3.3. JBoss EAP サーバー設定の最適化

JBoss EAP サーバーをインストールし、管理ユーザーを作成 したら、サーバー設定を最適化することが推奨されます。

パフォーマンスチューニングガイド』で、本番環境にアプリケーションをデプロイするときに一般的な問題が発生しないようサーバー設定を最適化する方法を必ず確認してください。通常の最適化には、ulimit の設定ガベッジコレクションの有効化Java ヒープダンプの作成スレッドプールサイズの調整などが含まれます。

また、製品のリリースに既存のパッチを適用するとよいでしょう。EAP の各パッチには、多くのバグ修正が含まれています。詳細は、JBoss EAP『パッチおよびアップグレードガイド』の「JBoss EAP のパッチ適用」を参照してください。

3.4. 管理インターフェース

3.4.1. 管理 CLI

管理コマンドラインインターフェース (CLI) は、JBoss EAP のコマンドライン管理ツールです。

管理 CLI を使用して、サーバーの起動および停止、アプリケーションのデプロイおよびアンデプロイ、システムの設定、他の管理タスクの実行を行います。管理 CLI は、管理対象ドメインのドメインコントローラーに接続し、ドメインで管理操作を実行することもできます。

lscdpwd など、多くの共通するターミナルコマンドを使用できます。管理 CLI はタブ補完をサポートします。

コマンドと操作、構文、およびバッチモードでの実行を含む、管理 CLI の使用に関する詳細は、JBoss EAP『管理 CLI ガイド』を参照してください。

管理 CLI の起動
$ EAP_HOME/bin/jboss-cli.sh
注記

Windows Server の場合は、EAP_HOME\bin\jboss-cli.bat スクリプトを使用します。

稼働中のサーバーへの接続
connect

上記の代わりに、管理 CLI を起動し、EAP_HOME/bin/jboss-cli.sh --connect コマンドを使用すると 1 度に接続できます。

ヘルプの表示

以下のコマンドを実行してヘルプを表示します。

help

コマンドで --help フラグを使用すると、そのコマンドの使用に関する説明が表示されます。たとえば、deploy コマンドの使用に関する情報を表示するには、以下のコマンドを実行します。

deploy --help
管理 CLI の終了
quit
システム設定の表示

以下のコマンドは read-attribute 操作を使用して、データソースの例が有効になっているかどうかを表示します。

/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
{
    "outcome" => "success",
    "result" => true
}

管理対象ドメインで実行している場合、コマンドの前に /profile=PROFILE_NAME を付けて更新するプロファイルを指定する必要があります。

/profile=default/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
システム設定の更新

以下のコマンドは write-attribute 操作を使用して、データソースの例を無効にします。

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
サーバーの起動

管理対象ドメインで実行している場合、管理 CLI を使用してサーバーを起動および停止することもできます。

/host=HOST_NAME/server-config=server-one:start

3.4.2. 管理コンソール

管理コンソールは、JBoss EAP の web ベースの管理ツールです。

管理コンソールを使用して、サーバーの開始および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の調整、サーバー設定の変更の永続化を行います。管理コンソールは管理タスクも実行でき、現在のユーザーが変更を行った後にサーバーインスタンスの再起動またはリロードが必要な場合はライブ通知も行います。

管理対象ドメインでは、同じドメインのサーバーインスタンスとサーバーグループをドメインコントローラーの管理コンソールから集中管理できます。

デフォルトの管理ポートを使用してローカルホストで稼働している JBoss EAP インスタンスの場合、Web ブラウザーを使用して http://localhost:9990/console/index.html で管理コンソールにアクセスできます。管理コンソールにアクセスできるパーミッションを持つユーザーで認証する必要があります。

管理コンソールでは、JBoss EAP スタンドアロンサーバーまたは管理対象ドメインを操作および管理するために以下のタブが提供されます。

Home (ホーム)
一般的な設定および管理タスクを行う方法を学ぶことができます。ツアーに参加して JBoss EAP 管理コンソールについてよく理解してください。
Deployments (デプロイメント)
デプロイメントを追加、削除、および有効化します。管理対象ドメインでは、デプロイメントをサーバーグループに割り当てます。
Configuration (設定)
Web サービス、メッセージング、高可用性などの機能を提供する利用可能なサブシステムを設定します。管理対象ドメインでは、異なるサブシステム設定が含まれるプロファイルを管理します。
Runtime (ランタイム)
サーバーの状態、JVM 使用率、サーバーログなどのランタイム情報を表示します。管理対象ドメインではホスト、サーバーグループ、およびサーバーを管理します。
Patching (パッチ)
JBoss EAP インスタンスにパッチを適用します。
Access Control (アクセス制御)
ロールベースアクセス制御を使用するときにユーザーとグループにロールを割り当てます。

3.4.2.1. 管理コンソールの属性の更新

リソースを編集するために管理コンソールの適切なセクションに移動した後、適切なパーミッションがあれば属性を編集できます。

  1. 編集 リンクをクリックします。
  2. 必要な変更を追加します。

    必要なフィールドにはアスタリスク (*) が付いています。ヘルプ リンクをクリックすると、属性の詳細を表示できます。

    注記

    入力フィールドは、属性のタイプに応じてテキストフィールド、ON/OFF フィールド、またはドロップダウンになります。テキストフィールドによっては、入力時に設定にある値が候補として表示されます。

  3. 保存 をクリックして変更を保存します。
  4. 必要な場合は、サーバーをリロードして変更を反映します。

    変更を保存するとき、変更の反映にリロードが必要な場合はポップアップが表示されます。スタンドアロンサーバーをリロードするには、ポップアップの 再読み込み リンクをクリックします。管理対象ドメインでサーバーをリロードするには、Topology リンクをクリックして、適切なサーバーを選択し、再読み込み ドロップダウンオプションをクリックします。

最近実行した設定に関するアクションの履歴を表示するには、管理コンソールの右上にある通知アイコンをクリックします。

3.4.2.2. 管理コンソールの有効化/無効化

/core-service=management/management-interface=http-interface リソースの console-enabled ブール値属性を設定すると、管理コンソールを有効または無効にできます。ドメインモードマスターホストの場合は、/host=master/core-service=management/management-interface=http-interface を使用します。

たとえば、有効にする場合は以下を設定します。

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=true)

無効にする場合は以下を設定します。

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=false)

3.4.2.3. 管理コンソールの言語の変更

管理リソースの言語はデフォルトの英語に設定されています。以下の言語の 1 つを選択することもできます。

  • ドイツ語 (de)
  • 簡体中国語 (zh-Hans)
  • ブラジルポルトガル語 (pt-BR)
  • フランス語 (fr)
  • スペイン語 (es)
  • 日本語 (ja)
管理コンソールの言語の変更方法
  1. 管理コンソールにログインします。
  2. 管理コンソールの右下隅にある Settings をクリックします。
  3. Locale 選択ボックスから必要な言語を選択します。
  4. Save を選択します。確認ボックスに、アプリケーションのリロードが必要であると表示されます。
  5. Yes をクリックします。システムによってブラウザーが自動的に更新され、選択したロケールが使用されます。

3.4.2.4. 管理コンソールタイトルのカスタマイズ

JBoss EAP インスタンスのそれぞれを一目で特定できるように、管理コンソールのタイトルをカスタマイズできます。

管理コンソールのタイトルをカスタマイズするには、以下の手順に従います。

  1. 管理コンソールにログインします。
  2. 管理コンソールの右下隅にある Settings をクリックします。
  3. Settings ウインドウで、Title フィールドのタイトルを変更します。
  4. Save をクリックします。

    確認ボックスに、管理コンソールのリロードが必要であることが表示されます。

  5. Yes をクリックします。

    システムは Web ブラウザーを自動的に更新し、新しいタイトルがタブヘッダーに表示されます。

3.5. 管理 API

3.5.1. HTTP API

HTTP API のエンドポイントは、HTTP プロトコルに依存して JBoss EAP 管理レイヤーと統合する管理クライアントのエントリーポイントです。

HTTP API は、JBoss EAP 管理コンソールによって使用されますが、他のクライアントの統合機能も提供します。デフォルトでは、http://HOST_NAME:9990/management で HTTP API にアクセスできます。この URL は、API に公開される raw 属性および値を表示します。

リソースの読み取り

HTTP POST メソッドを使用して他の操作を読み取り、書き込み、および実行できますが、GET リクエストを使用すると一部の読み取り操作を実行できます。HTTP GET メソッドは以下の URL 形式を使用します。

http://HOST_NAME:9990/management/PATH_TO_RESOURCE?operation=OPERATION&PARAMETER=VALUE

置き換え可能な値は必ず適切な値に置き換えてください。置き換え可能な OPERATION の値は、以下の値に置き換えられます。

Value説明

attribute

read-attribute 操作を実行します。

operation-description

read-operation-description 操作を実行します。

operation-names

read-operation-names 操作を実行します。

resource

read-resource 操作を実行します。

resource-description

read-resource-description 操作を実行します。

snapshots

list-snapshots 操作を実行します。

以下の URL 例は、HTTP API を使用して読み取り操作を実行する方法を示しています。

例: リソースに対するすべての属性および値の読み取り

http://HOST_NAME:9990/management/subsystem/undertow/server/default-server/http-listener/default

これは、default HTTP リスナーのすべての属性とそれらの値を表示します。

注記

デフォルトの操作は read-resource です。

例: リソースに対する属性の値の読み取り

http://HOST_NAME:9990/management/subsystem/datasources/data-source/ExampleDS?operation=attribute&name=enabled

これは、ExampleDS データソースの enabled 属性の値を読み取ります。

リソースの更新

HTTP POST メソッドを使用して設定値を更新するか、HTTP API を使用して他の操作を実行できます。これらの操作の認証を提供する必要があります。

以下の例は、HTTP API を使用してリソースを更新する方法を示しています。

例: リソースに対する属性の値の更新

$ curl --digest http://HOST_NAME:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"write-attribute", "address":["subsystem","datasources","data-source","ExampleDS"], "name":"enabled", "value":"false", "json.pretty":"1"}'

これは、ExampleDS データソースの enabled 属性の値を false に更新します。

例: サーバーに対する操作の実行

$ curl --digest http://localhost:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"reload"}'

これは、サーバーをリロードします。

HTTP API を使用して JBoss EAP にアプリケーションをデプロイする方法については、「HTTP API を使用したアプリケーションのデプロイ」を参照してください

3.5.2. ネイティブ API

ネイティブ API のエンドポイントは、ネイティブプロトコルに依存して JBoss EAP 管理レイヤーと統合する管理クライアントのエントリーポイントです。ネイティブ API は JBoss EAP 管理 CLI によって使用されますが、他のクライアントの統合機能も提供します。

以下の Java コードは、ネイティブ API を使用して Java コードから管理操作を実行する方法の例を示しています。

注記

EAP_HOME/bin/client/jboss-cli-client.jar ファイルにある、必要な JBoss EAP ライブラリーをクラスパスに追加する必要があります。

例: ネイティブ API を使用したリソースの読み取り

// Create the management client
ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);

// Create the operation request
ModelNode op = new ModelNode();

// Set the operation
op.get("operation").set("read-resource");

// Set the address
ModelNode address = op.get("address");
address.add("subsystem", "undertow");
address.add("server", "default-server");
address.add("http-listener", "default");

// Execute the operation and manipulate the result
ModelNode returnVal = client.execute(op);
System.out.println("Outcome: " + returnVal.get("outcome").toString());
System.out.println("Result: " + returnVal.get("result").toString());

// Close the client
client.close();

3.6. 設定データ

3.6.1. スタンドアロンサーバー設定ファイル

スタンドアロン設定ファイルは EAP_HOME/standalone/configuration/ ディレクトリーにあります。事前定義されたプロファイルは 5 つあり (defaulthafullfull-ha、および load-balancer)、それぞれに個別のファイルが存在します。

表3.2 スタンドアロン設定ファイル

設定ファイル目的

standalone.xml

このスタンドアロン設定ファイルは、スタンドアロンサーバーを起動したときに使用されるデフォルト設定です。このファイルには、サブシステム、ネットワーキング、デプロイメント、ソケットバインディング、およびその他の設定詳細など、サーバーに関するすべての情報が含まれます。メッセージングや高可用性に必要なサブシステムは提供しません。

standalone-ha.xml

このスタンドアロン設定ファイルには、デフォルトのサブシステムすべてが含まれ、高可用性の modcluster および jgroups サブシステムを追加します。メッセージングに必要なサブシステムは提供しません。

standalone-full.xml

このスタンドアロン設定ファイルには、デフォルトのサブシステムすべてが含まれ、messaging-activemq および iiop-openjdk サブシステムを追加します。高可用性に必要なサブシステムは提供しません。

standalone-full-ha.xml

このスタンドアロン設定ファイルには、メッセージングおよび高可用性を含むすべてのサブシステムのサポートが含まれます。

standalone-load-balancer.xml

このスタンドアロン設定ファイルには、ビルトインの mod_cluster フロントエンドロードバランサーを使用して他の JBoss EAP インスタンスの負荷を分散するために必要な最低限のサブシステムが含まれます。

デフォルトでは、スタンドアロンサーバーとして JBoss EAP を起動すると standalone.xml ファイルが使用されます。他の設定で JBoss EAP を起動するには --server-config 引数を使用します。以下に例を示します。

$ EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

3.6.2. 管理対象ドメイン設定ファイル

管理対象ドメインの設定ファイルは EAP_HOME/domain/configuration/ ディレクトリーにあります。

表3.3 管理対象ドメイン設定ファイル

設定ファイル目的

domain.xml

これは、管理対象ドメインの主要設定ファイルです。ドメインマスターのみがこのファイルを読み取ります。このファイルには、すべてのプロファイル (defaulthafullfull-ha、および load-balancer) の設定が含まれています。

host.xml

このファイルには、管理対象ドメインの物理ホスト固有の設定情報が含まれています (ネットワークインターフェース、ソケットバインディング、ホスト名、その他のホスト固有の詳細など)。host.xml ファイルには、host-master.xml および host-slave.xml (詳細は下記参照) の両方の機能がすべて含まれています。

host-master.xml

このファイルには、サーバーをマスタードメインコントローラーとして実行するために必要な設定情報のみが含まれています。

host-slave.xml

このファイルには、サーバーを管理対象ドメインのホストコントローラーとして実行するために必要な設定情報のみが含まれています。

デフォルトでは、JBoss EAP を管理対象ドメインで起動すると host.xml ファイルが使用されます。他の設定で JBoss EAP を起動するには --host-config 引数を使用します。以下に例を示します。

$ EAP_HOME/bin/domain.sh --host-config=host-master.xml

3.6.3. 設定データのバックアップ

JBoss EAP のサーバー設定を後で復元するため、以下の場所にあるものはバックアップしておく必要があります。

  • EAP_HOME/standalone/configuration/

    • ディレクトリー全体をバックアップして、スタンドアロンサーバーのユーザーデータ、サーバー設定、およびロギング設定を保存します。
  • EAP_HOME/domain/configuration/

    • ディレクトリー全体をバックアップして、管理対象ドメインのユーザーおよびプロファイルデータ、ドメインおよびホスト設定、およびロギング設定を保存します。
  • EAP_HOME/modules/

    • カスタムモジュールをバックアップします。
  • EAP_HOME/welcome-content/

    • カスタムのウェルカムコンテンツをバックアップします。
  • EAP_HOME/bin/

    • カスタムスクリプトまたは起動設定ファイルをバックアップします。

3.6.4. 設定ファイルのスナップショット

サーバーの保守や管理をしやすくするため、JBoss EAP は起動時に元の設定ファイルにタイムスタンプを付けたものを作成します。管理操作によってその他の設定変更が行われると、元のファイルが自動的にバックアップされ、インスタンスの作業用コピーが参照およびロールバック用に保持されます。さらに、現在のサーバー設定の現時点のコピーである設定スナップショットを撮ることができます。これらのスナップショットは管理者によって保存およびロードされます。

以下の例では、standalone.xml ファイルが使用されますが、同じプロセスが domain.xml および host.xml にも適用されます。

スナップショットの作成

管理 CLI を使用して、現在の設定のスナップショットを作成します。

:take-snapshot
{
    "outcome" => "success",
    "result" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20151022-133109702standalone.xml"
}
スナップショットのリスト

管理 CLI を使用して、作成したすべてのスナップショットをリストします。

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
        "names" => [
            "20151022-133109702standalone.xml",
            "20151022-132715958standalone.xml"
        ]
    }
}
スナップショットの削除

管理 CLI を使用して、スナップショットを削除します。

:delete-snapshot(name=20151022-133109702standalone.xml)
スナップショットを用いたサーバーの起動

スナップショットまたは自動保存された設定を使用してサーバーを起動できます。

  1. EAP_HOME/standalone/configuration/standalone_xml_history ディレクトリーへ移動し、ロードするスナップショットまたは保存された設定ファイルを確認します。
  2. サーバーを起動し、選択した設定ファイルを示します。設定ディレクトリー EAP_HOME/standalone/configuration/ からの相対パスを渡します。

    $ EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20151022-133109702standalone.xml
注記

管理対象ドメインで実行している場合は、代わりに --host-config 引数を使用し、設定ファイルを指定します。

3.6.5. 設定変更の確認

JBoss EAP 7 には、稼働中のシステムに加えられた設定変更を追跡する機能があります。この機能を使用すると、管理者は他の許可されたユーザーが追加した設定変更の履歴を確認することができます。

重要

変更はメモリーに保存され、サーバーを再起動すると永続化されません。この機能は 管理監査ログ の代替機能ではありません。

管理 CLI または 管理コンソール から設定変更の追跡と表示を有効にできます。

管理 CLI からの設定変更の追跡および表示

設定変更の追跡を有効にするには、以下の管理 CLI コマンドを使用します。max-history 属性を使用すると保存するエントリーの数を指定できます。

/subsystem=core-management/service=configuration-changes:add(max-history=20)
注記

管理対象ドメインでは、ホストおよびサーバー関連の設定変更はホストレベルで追跡されます。ホストコントローラーの設定変更を可能にすると、そのホストコントローラーが管理するサーバーすべてで設定の変更が可能になります。以下のコマンドを使用すると、ホストごとに設定の変更を追跡できます。

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:add(max-history=20)

最近行われた設定変更のリストを表示するには、以下の管理 CLI コマンドを使用します。

/subsystem=core-management/service=configuration-changes:list-changes
注記

管理対象ドメインでは、以下のコマンドを使用してホストの設定変更をリストできます。

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:list-changes

以下のコマンドを使用すると、特定のサーバーに影響する設定の変更をリストできます。

/host=HOST_NAME/server=SERVER_NAME/subsystem=core-management/service=configuration-changes:list-changes

このコマンドは、各設定変更とその変更日、変更元、結果、および操作の詳細を一覧で表示します。たとえば、以下の list-changes コマンドの出力は、変更日が新しい順に設定変更を表示しています。

{
    "outcome" => "success",
    "result" => [
        {
            "operation-date" => "2016-02-12T18:37:00.354Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [],
                "operation" => "reload",
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:34:16.859Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [
                    ("subsystem" => "datasources"),
                    ("data-source" => "ExampleDS")
                ],
                "operation" => "write-attribute",
                "name" => "enabled",
                "value" => false,
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:24:11.670Z",
            "access-mechanism" => "HTTP",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "operation" => "remove",
                "address" => [
                    ("subsystem" => "messaging-activemq"),
                    ("server" => "default"),
                    ("jms-queue" => "ExpiryQueue")
                ],
                "operation-headers" => {"access-mechanism" => "HTTP"}
            }]
        }
    ]
}

この例は、設定に影響した以下 3 つの操作の詳細を表しています。

  • 管理 CLI から行ったサーバーのリロード。
  • 管理 CLI から行った ExampleDS データソースの無効化。
  • 管理コンソールから行った ExpiryQueue キューの削除。
管理コンソールからの設定変更の追跡および表示

管理コンソールからの設定変更の追跡を有効にするには、Runtime タブを選択して、変更を追跡するサーバーまたはホストに移動し、ドロップダウンメニューで 設定変更 を選択します。Enable Configuration Changes をクリックし、最大の履歴値を指定します。

そのページの表に変更された設定が日付、変更元、結果、および操作詳細とともに表示されます。

3.6.6. プロパティーの置き換え

JBoss EAP では、設定のリテラル値の代わりに式を使用して置換可能なプロパティーを定義できます。式の形式は ${PARAMETER:DEFAULT_VALUE} になります。指定のパラメーターが設定されると、パラメーターの値が使用されます。設定されない場合は、デフォルト値が使用されます。

式の解決でサポートされるリソースはシステムプロパティー、環境変数、および vault になります。デプロイメントの場合のみ、デプロイメントアーカイブの META-INF/jboss.properties ファイルにリストされたプロパティーをソースとすることができます。サブデプロイメントをサポートするデプロイメントタイプでは、プロパティーファイルが EAR などの外部のデプロイメントにある場合は解決がすべてのサブデプロイメントに対してスコープ指定されます。プロパティーファイルがサブデプロイメントにある場合は、解決はそのサブデプロイメントのみに対してスコープ指定されます。

以下の例では、jboss.bind.address パラメーターが設定されていなければ、standalone.xml 設定ファイルによって public インターフェースの inet-address127.0.0.1 に設定されます。

<interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>

以下のコマンドを使用して、EAP をスタンドアロンサーバーとして起動するときに jboss.bind.address パラメーターを設定できます。

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS
ネストされた式

式はネストすることができるため、固定値の代わりにさらに高度な式を使用できます。ネストされた式の書式は、通常の式の場合と同様ですが、ある式が別の式に組み込まれます。 例を以下に示します。

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

ネストされた式は、再帰的に評価されるため、最初に 内部の式が評価され、次に 外部の式が評価されます。式が別の式へ解決する場合は式も再帰的になることがあり、その後解決されます。ネストされた式は式が許可された場所ならどこでも許可されます (ただし、管理 CLI コマンドを除く)。

ネストされた式が使用される例としては、データソース定義で使用されるパスワードがマスクされている場合などがあります。データソースの設定には以下のような行がある場合があります。

<password>${VAULT::ds_ExampleDS::password::1}</password>

この場合、ネストされた式を使用すると、ds_ExampleDS の値をシステムプロパティー (datasource_name) に置き換えることができます。上記の行の代わりに以下の行をデータソースの設定に使用できます。

<password>${VAULT::${datasource_name}::password::1}</password>

JBoss EAP は、最初に式 ${datasource_name} を評価し、次にこれを外側の大きい式に入力して、結果となる式を評価します。この設定の利点は、データソースの名前が固定された設定から抽象化されることです。

記述子ベースのプロパティー置換

データソース接続パラメーターなどのアプリケーションの設定は、通常は開発デプロイメント、テストデプロイメント、および本番環境によって異なります。Jakarta EE 仕様にはこれらの設定を外部化するメソッドが含まれていないため、このような違いはビルドシステムスクリプトで対応することがあります。JBoss EAP では、記述子ベースのプロパティー置換を使用して設定を外部的に管理できます。

記述子ベースのプロパティー置換は、記述子を基にプロパティーを置き換えるため、アプリケーションやビルドチェーンから環境に関する仮定を除外できます。環境固有の設定は、アノテーションやビルドシステムスクリプトでなく、デプロイメント記述子に指定できます。設定はファイルに指定したり、パラメーターとしてコマンドラインで提供したりできます。

ee サブシステムには、プロパティー置換が適用されたかどうかを制御する複数のフラグがあります。

JBoss 固有の記述子置換は jboss-descriptor-property-replacement フラグによって制御され、デフォルトで有効になっています。有効にすると、以下のデプロイメント記述子でプロパティーを置換できます。

  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml

以下の管理 CLI コマンドを使用すると、JBoss 固有の記述子でプロパティー置換を有効または無効にできます。

/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Jakarta EE の記述子置換は spec-descriptor-property-replacement フラグによって制御され、デフォルトで無効になっています。有効にすると、以下のデプロイメント記述子でプロパティーを置換できます。

  • ejb-jar.xml
  • persistence.xml
  • application.xml
  • web.xml

以下の管理 CLI コマンドを使用すると、Jakarta EE の記述子でプロパティー置換を有効または無効にできます。

/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

3.6.7. Git を使用した設定データの管理

JBoss EAP 7.3 より、Git を使用してサーバー設定データ、プロパティーファイル、およびデプロイメントを管理および永続化できるようになりました。これにより、これらのファイルのバージョン履歴を管理できるだけでなく、1 つ以上の Git リポジトリーを使用して複数のサーバーおよびノード全体でサーバーやアプリケーションの設定を共有することができます。この機能は、デフォルトの設定ディレクトリーレイアウトを使用するスタンドアロンサーバーでのみ動作します。

ローカル Git リポジトリー で設定データの使用を選択でき、remote Git repository からデータを取得することもできます。Git リポジトリーは、スタンドアロンサーバーコンテンツのベースディレクトリーである jboss.server.base.dir ディレクトリーで設定されます。jboss.server.base.dir ディレクトリーが Git を使用するよう設定されると、JBoss EAP は管理 CLI または管理コンソールを使用して設定へ加えられた各更新を自動的にコミットします。設定ファイルを手作業で編集してサーバー外部で追加された変更は、コミットおよび永続化されません。しかし、Git CLI を使用して手作業の変更を追加およびコミットすることができます。また、Git CLI を使用してコミット履歴の表示、ブランチの管理、およびコンテンツの管理を行うこともできます。

この機能を使用するには、サーバーの起動時に以下の引数を 1 つ以上コマンドラインに渡します。

表3.4 Git 設定管理のサーバー起動引数

引数説明

--git-repo

サーバー設定データの管理および永続化に使用される Git リポジトリーの場所。これは、ローカルで保存する場合は local を指定し、リモートの場合はリモートリポジトリーへの URL を指定します。

--git-branch

使用する Git リポジトリーのブランチまたはタグ名。ブランチまたはタグ名が存在しないと作成されないため、この引数には既存のブランチまたはタグ名を指定する必要があります。タグ名を使用する場合、リポジトリーを detached HEAD 状態にし、今後のコミットがブランチにアタッチされないようにします。タグ名は読み取り専用で、通常複数のノード全体で設定をレプリケートする必要があるときに使用されます。

--git-auth

Elytron 設定ファイルへの URL には、リモート Git リポジトリーへの接続時に使用される認証情報が含まれています。この引数は、Git リポジトリーに認証が必要な場合に必要となります。Git は SSH 認証をサポートしますが、Elytron はサポートしないため、プライベートキーを使用してパスワードのないデフォルトの SSH 認証のみがサポートされます。この引数は local リポジトリーとは使用されません。

ローカル Git リポジトリーの使用

ローカル Git リポジトリーを使用するには、--git-repo=local 引数を使用してサーバーを起動します。サーバーの起動時に --git-branch=GIT_BRANCH_NAME 引数を追加して、オプションのブランチまたはタグ名をリモートリポジトリーで指定することもできます。ブランチまたはタグ名が存在しないと作成されないため、この引数には既存のブランチまたはタグ名を指定する必要があります。タグ名を使用する場合、リポジトリーを detached HEAD 状態にし、今後のコミットがブランチにアタッチされないようにします。

以下のコマンド例は、local リポジトリーの 1.0.x ブランチを使用して、サーバーを起動します。

$ EAP_HOME/bin/standalone.sh --git-repo=local --git-branch=1.0.x

local Git リポジトリーを使用する引数を使用してサーバーを起動した場合、JBoss EAP は jboss.server.base.dir ディレクトリーがすでに Git に対して設定されているかどうかを確認します。設定されていない場合、JBoss EAP は既存の設定コンテンツを使用して jboss.server.base.dir ディレクトリーに Git リポジトリーを作成し、初期化します。JBoss EAP は --git-branch 引数によって渡されたブランチ名をチェックアウトします。引数が渡されていない場合は master ブランチをチェックアウトします。初期化後、スタンドアロンサーバーコンテンツのベースディレクトリーに .git/ ディレクトリーと .gitignore ファイルがあることを確認できるはずです。

リモート Git リポジトリーの使用

Git リポジトリーを使用するには、--git-repo=REMOTE_REPO 引数を使用してサーバーを起動します。引数の値は、ローカル Git 設定に手作業で追加した URL またはリモートエイリアスになります。

サーバーの起動時に --git-branch=GIT_BRANCH_NAME 引数を追加して、オプションのブランチまたはタグ名をリモートリポジトリーで指定することもできます。ブランチまたはタグ名が存在しないと作成されないため、この引数には既存のブランチまたはタグ名を指定する必要があります。タグ名を使用する場合、リポジトリーを detached HEAD 状態にし、今後のコミットがブランチにアタッチされないようにします。

Git リポジトリーに認証が必要な場合は、サーバーの起動時に --git-auth=AUTH_FILE_URL 引数も追加する必要があります。この引数は、Git リポジトリーへの接続に必要な認証情報が含まれる Elytron 設定ファイルへの URL になります。以下は、認証に使用できる Elytron 設定ファイルの例になります。

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <authentication-client xmlns="urn:elytron:client:1.2">
    <authentication-rules>
      <rule use-configuration="test-login">
      </rule>
    </authentication-rules>
    <authentication-configurations>
      <configuration name="test-login">
        <sasl-mechanism-selector selector="BASIC" />
        <set-user-name name="eap-user" />
        <credentials>
          <clear-password password="my_api_key" />
        </credentials>
        <set-mechanism-realm name="testRealm" />
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>
注記

Git は SSH 認証をサポートしますが、Elytron はサポートしないため、プライベートキーを使用してパスワードのないデフォルトの SSH 認証のみがサポートされます。

以下は、リモート eap-configuration リポジトリーの 1.0.x ブランチを使用し、認証情報が含まれる Elytron 設定ファイルに URL を渡して、full プロファイルでサーバーを起動するコマンドの例になります。

$ EAP_HOME/bin/standalone.sh --git-repo=https://github.com/MY_GIT_ID/eap-configuration.git --git-branch=1.0.x --git-auth=file:///home/USER_NAME/github-wildfly-config.xml --server-config=standalone-full.xml

リモート Git リポジトリーを使用する引数を使用してサーバーを起動した場合、JBoss EAP は jboss.server.base.dir ディレクトリーがすでに Git に対して設定されているかどうかを確認します。設定されていない場合、JBoss EAP は jboss.server.base.dir ディレクトリーにある既存の設定ファイルを削除し、代わりにリモート Git 設定データを置きます。JBoss EAP は --git-branch 引数によって渡されたブランチ名をチェックアウトします。引数が渡されていない場合は master ブランチをチェックアウトします。この処理の完了後、スタンドアロンサーバーコンテンツのベースディレクトリーに .git/ ディレクトリーと .gitignore ファイルがあることを確認できるはずです。

警告

この処理の完了後、当初使用したものとは異なる --git-repo URL または --git-branch 名を渡して、サーバーを起動すると、サーバーの起動時にエラーメッセージ java.lang.RuntimeException: WFLYSRV0268: Failed to pull the repository GIT_REPO_NAME が表示されます。これは、JBoss EAP が jboss.server.base.dir ディレクトリーに現在設定されていないリポジトリーとブランチから設定データをプルしようとし、競合が発生するためです。

Git 使用時のリモート設定データの公開

管理 CLI の publish-configuration 操作を使用すると、Git リポジトリーの変更をリモートリポジトリーにプッシュすることができます。JBoss EAP は、サーバー起動時のブート処理中にリモート Git リポジトリーから設定をプルするため、複数のサーバー間で設定データを共有できます。この操作はリモートリポジトリーにのみ使用できます。ローカルリポジトリーでは動作しません。

以下の管理 CLI 操作は、設定データをリモート eap-configuration リポジトリーに公開します。

:publish-configuration(location="=https://github.com/MY_GIT_ID/eap-configuration.git")
{"outcome" => "success"}
Git でのスナップショットの使用

Git のコミット履歴を使用して設定の変更を追跡する他に、スナップショットを作成して特定時の設定を保持することもできます。スナップショットを一覧表示し、削除することができます。

Git 使用時におけるスナップショットの作成

スナップショットは、Git にタグとして保存されます。take-snapshot 操作で、スナップショットタグ名とコミットメッセージを引数として指定します。

以下の管理 CLI 操作は、スナップショットを作成し、タグに「snapshot-01」という名前を付けます。

:take-snapshot(name="snapshot-01", comment="1st snapshot")
{
    "outcome" => "success",
    "result" => "1st snapshot"
}
Git 使用時におけるスナップショットの一覧表示

list-snapshots 操作を使用すると、スナップショットタグをすべて一覧表示できます。

以下の管理 CLI 操作は、スナップショットタグを一覧表示します。

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "",
        "names" => [
            "snapshot : 1st snapshot",
            "refs/tags/snapshot-01",
            "snapshot2 : 2nd snapshot",
            "refs/tags/snapshot-02"
        ]
    }
}
Git 使用時におけるスナップショットの削除

delete-snapshot 操作にタグ名を渡すと特定のスナップショットを削除できます。

以下の管理 CLI 操作は、タグ名が「snapshot-01」のスナップショットを削除します。

:delete-snapshot(name="snapshot-01")
{"outcome" => "success"}

3.7. ファイルシステムパス

JBoss EAP はファイルシステムパスに論理名を使用します。他の設定は論理名を使用してパスを参照できます。そのため、各インスタンスに完全パスを使用する必要がなく、特定のホスト設定が汎用論理名に解決することができます。

たとえば、デフォルトの logging サブシステム設定は jboss.server.log.dir をサーバーログディレクトリーの論理名として宣言します。

例: サーバーログディレクトリーの相対パスの例

<file relative-to="jboss.server.log.dir" path="server.log"/>

JBoss EAP では、複数の標準的なパスが自動的に提供されるため、ユーザーが設定ファイルでこれらのパスを設定する必要はありません。

表3.5 標準的なパス

プロパティー説明

java.home

Java インストールディレクトリー。

jboss.controller.temp.dir

スタンドアロンサーバーおよび管理対象ドメインの共通のエイリアス。ディレクトリーは一時ファイルのストレージとして使用されます。管理対象ドメインの jboss.domain.temp.dir と スタンドアロンサーバーの jboss.server.temp.dir と同等です。

jboss.domain.base.dir

ドメインコンテンツのベースディレクトリー。

jboss.domain.config.dir

ドメイン設定が含まれるディレクトリー。

jboss.domain.data.dir

ドメインが永続データファイルの格納に使用するディレクトリー。

jboss.domain.log.dir

ドメインが永続ログファイルの格納に使用するディレクトリー。

jboss.domain.temp.dir

ドメインが一時ファイルの格納に使用するディレクトリー。

jboss.domain.deployment.dir

ドメインがデプロイ済みコンテンツの格納に使用するディレクトリー。

jboss.domain.servers.dir

ドメインが管理対象ドメインインスタンスの出力を格納するために使用するディレクトリー。

jboss.home.dir

JBoss EAP ディストリビューションのルートディレクトリー。

jboss.server.base.dir

スタンドアロンサーバーコンテンツのベースディレクトリー。

jboss.server.config.dir

スタンドアロンサーバー設定が含まれるディレクトリー。

jboss.server.data.dir

スタンドアロンサーバーが永続データファイルの格納に使用するディレクトリー。

jboss.server.log.dir

スタンドアロンサーバーがログファイルの格納に使用するディレクトリー。

jboss.server.temp.dir

スタンドアロンサーバーが一時ファイルの格納に使用するディレクトリー。

jboss.server.deploy.dir

スタンドアロンサーバーがデプロイ済みコンテンツを格納するために使用するディレクトリー。

user.dir

ユーザーのカレントワーキングディレクトリー。

user.home

ユーザーのホームディレクトリー。

標準パスの上書き または カスタムパスの追加 を行うことができます。

3.7.1. ファイルシステムパスの表示

以下の管理 CLI コマンドを使用して、ファイルシステムパスの一覧を表示します。

ls /path
注記

管理対象ドメインでは、以下の管理 CLI コマンドを使用して、特定のサーバーのファイルシステムパスをリストできます。

ls /host=HOST_NAME/server=SERVER_NAME/path

以下の管理 CLI コマンドを使用して、ファイルシステムパスの値を読み取ります。

/path=PATH_NAME:read-resource
注記

管理対象ドメインでは、以下の管理 CLI コマンドを使用して、特定サーバーのファイルシステムパスの値を読み取りできます。

/host=HOST_NAME/server=SERVER_NAME/path=PATH_NAME:read-resource

3.7.2. 標準パスの上書き

jboss.server.* または jboss.domain.* で始まる標準パスのデフォルトの場所を上書きできます。これには 2 つの方法があります。

  • サーバーの起動時にコマンドライン引数を渡します。例を以下に示します。

    $ EAP_HOME/bin/standalone.sh -Djboss.server.log.dir=/var/log
  • standalone.conf または domain.conf のいずれかのサーバー設定ファイルで JAVA_OPTS 変数を変更し、新しい場所が含まれるようにします。例を以下に示します。

    JAVA_OPTS="$JAVA_OPTS -Djboss.server.log.dir=/var/log"
管理対象ドメインの標準パスの上書き

この例の目的は、/opt/jboss_eap/domain_data ディレクトリーにドメインファイルを格納し、各トップレベルディレクトリーにカスタム名を付けることです。デフォルトのディレクトリーグルーピングである by-server が使用されます。

  • ログファイルは all_logs サブディレクトリーに格納します。
  • データファイルは all_data サブディレクトリーに格納します。
  • 一時ファイルは all_temp サブディレクトリーに格納します。
  • サーバーのファイルは all_servers サブディレクトリーに格納します。

この設定を行うには、JBoss EAP の起動時に複数のシステムプロパティーを上書きします。

$ EAP_HOME/bin/domain.sh -Djboss.domain.temp.dir=/opt/jboss_eap/domain_data/all_temp -Djboss.domain.log.dir=/opt/jboss_eap/domain_data/all_logs -Djboss.domain.data.dir=/opt/jboss_eap/domain_data/all_data -Djboss.domain.servers.dir=/opt/jboss_eap/domain_data/all_servers

この結果、パス構造は次のようになります。

/opt/jboss_eap/domain_data/
               ├── all_data
               ├── all_logs
               ├── all_servers
               │   ├── server-one
               │   │   ├── data
               │   │   ├── log
               │   │   └── tmp
               │   └── server-two
               │       ├── data
               │       ├── log
               │       └── tmp
               └── all_temp

3.7.3. カスタムパスの追加

管理 CLI または管理コンソールを使用してカスタムのファイルシステムパスを追加できます。

  • 管理 CLI の場合、以下の管理 CLI コマンドを使用して新しいパスを追加できます。

    /path=my.custom.path:add(path=/my/custom/path)
  • 管理コンソールからファイルシステムパスを設定するには、設定タブに移動し、パスを選択して表示をクリックします。ここからは、パスを追加、変更、および削除できます。

このカスタムパスを設定で使用できます。たとえば、以下のログハンドラーは相対パスにカスタムパスを使用します。

<subsystem xmlns="urn:jboss:domain:logging:6.0">
  ...
  <periodic-rotating-file-handler name="FILE" autoflush="true">
    <formatter>
      <named-formatter name="PATTERN"/>
    </formatter>
    <file relative-to="my.custom.path" path="server.log"/>
    <suffix value=".yyyy-MM-dd"/>
    <append value="true"/>
  </periodic-rotating-file-handler>
  ...
</subsystem>

3.8. ディレクトリーのグループ化

管理対象ドメインでは、各サーバーのファイルは EAP_HOME/domain ディレクトリーに格納されます。ホストコントローラーの directory-grouping 属性を使用すると、サーバーのサブディレクトリーの編成を指定できます。ディレクトリーはサーバーまたはタイプを基にしてグループ化できます。デフォルトではディレクトリーはサーバーを基にしてグループ化されます。

サーバーを基にしたディレクトリーのグループ化

デフォルトでは、ディレクトリーはサーバーを基にしてグループ化されます。管理作業がサーバー中心である場合はこの設定が推奨されます。たとえば、サーバーインスタンスごとにバックアップやログファイルの処理を設定することができます。

ZIP インストールで JBoss EAP がインストールされた場合、デフォルトのディレクトリー構造 (サーバーによるグループ化) は次のようになります。

EAP_HOME/domain
         └─ servers
            ├── server-one
            │   ├── data
            │   ├── tmp
            │   └── log
            └── server-two
                ├── data
                ├── tmp
                └── log

サーバーを基にしてドメインディレクトリーをグループ化するには、以下の管理 CLI コマンドを入力します。

/host=HOST_NAME:write-attribute(name=directory-grouping,value=by-server)

このコマンドにより、ホストコントローラーの host.xml 設定ファイルが更新されます。

<servers directory-grouping="by-server">
  <server name="server-one" group="main-server-group"/>
  <server name="server-two" group="main-server-group" auto-start="true">
    <socket-bindings port-offset="150"/>
  </server>
</servers>

タイプを基にしたディレクトリーのグループ化

サーバーを基にディレクトリーをグループ化する代わりに、ファイルタイプを基にしてグループ化することもできます。管理作業がファイルタイプ中心である場合は、この設定が推奨されます。たとえば、data ファイルのみを簡単にバックアップすることができます。

ZIP インストールで JBoss EAP がインストールされ、ドメインのファイルがタイプを基にグループ化された場合、ディレクトリー構造は次のようになります。

EAP_HOME/domain
         ├── data
         │   └── servers
         │       ├── server-one
         │       └── server-two
         ├── log
         │   └── servers
         │       ├── server-one
         │       └── server-two
         └── tmp
             └── servers
                 ├── server-one
                 └── server-two

タイプを基にしてドメインディレクトリーをグループ化するには、以下の管理 CLI コマンドを入力します。

/host=HOST_NAME:write-attribute(name=directory-grouping,value=by-type)

このコマンドにより、ホストコントローラーの host.xml 設定ファイルが更新されます。

<servers directory-grouping="by-type">
  <server name="server-one" group="main-server-group"/>
  <server name="server-two" group="main-server-group" auto-start="true">
    <socket-bindings port-offset="150"/>
  </server>
</servers>

3.9. システムプロパティー

Java システムプロパティーを使用すると、JBoss EAP の多くのオプションや、アプリケーションサーバー内で使用する名前と値のペアを設定することができます。

システムプロパティーを使用して JBoss EAP 設定のデフォルトの値を上書きできます。たとえば、以下のパブリックインターフェースバインドアドレスの XML 設定は、jboss.bind.address システムプロパティーによる設定が可能で、このシステムプロパティーが提供されないとデフォルトで 127.0.0.1 が使用されることを表しています。

<inet-address value="${jboss.bind.address:127.0.0.1}"/>

JBoss EAP でシステムプロパティーを設定する方法は複数あり、以下の方法が含まれます。

JBoss EAP の管理対象ドメインを使用する場合、ドメイン全体、特定のサーバーグループ、特定のホストとそのすべてのサーバーインスタンス、または 1 つのサーバーインスタンスにシステムプロパティーを適用できます。他の多くの JBoss EAP ドメイン設定と同様に、より具体的なレベルで設定されたシステムプロパティーはより抽象的なものを上書きします。詳細は「ドメイン管理」の章を参照してください。

起動スクリプトにシステムプロパティーを渡す

JBoss EAP 起動スクリプトにシステムプロパティーを渡すには -D 引数を使用します。例を以下に示します。

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=192.168.1.2

このシステムプロパティーの設定方法は、JBoss EAP が起動する前に JBoss EAP のオプションを設定する必要がある場合に便利です。

管理 CLI を使用したシステムプロパティーの設定

管理 CLI で以下の構文を使用すると、システムプロパティーを設定できます。

/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)

例を以下に示します。

/system-property=jboss.bind.address:add(value=192.168.1.2)

管理 CLI を使用してシステムプロパティーを設定する場合、一部の JBoss EAP オプション (上記の例の jboss.bind.address など) を有効にするにはサーバーの再起動が必要です。

管理対象ドメインの場合、上記の例はドメイン全体のシステムプロパティーを設定しますが、ドメイン設定のより具体的なレベルでシステムプロパティーを設定または上書きすることもできます。

管理コンソールを使用したシステムプロパティーの設定

  • スタンドアロン JBoss EAP サーバーでは、管理コンソールの Configuration タブでシステムプロパティーを設定できます。System Properties を選択し、表示 ボタンをクリックします。
  • 管理対象ドメインの場合:

    • ドメインレベルのシステムプロパティーは Configuration タブで設定できます。System Properties を選択し、表示 ボタンをクリックします。
    • サーバーグループおよびサーバーレベルのシステムプロパティーは Runtime タブで設定できます。設定するサーバーグループまたはサーバーを選択し、サーバーグループまたはサーバー名の横にある 表示 ボタンをクリックした後、System Properties タブを選択します。
    • ホストレベルのシステムプロパティーは Runtime タブで設定できます。設定するホストを選択し、ホスト名の横にあるドロップダウンメニューで Properties を選択します。

<ph x="1"/>

システムプロパティーは JAVA_OPTS 環境変数を使用して設定することもできます。JAVA_OPTS を編集する方法は多くありますが、JBoss EAP では JBoss EAP のプロセスで使用される JAVA_OPTS を設定する設定ファイルが提供されます。

スタンドアロンサーバーの場合、このファイルは EAP_HOME/bin/standalone.conf になります。管理対象ドメインの場合は、EAP_HOME/bin/domain.conf になります。Microsoft Windows システムではこれらのファイルに .bat 拡張子が付きます。

注記

RPM インストールの場合、RPM サービス設定ファイルJAVA_OPTS を編集してシステムプロパティーを設定することが推奨されます。「RPM サービスプロパティーの設定」を参照してください。

適切な設定ファイルで JAVA_OPTS にシステムプロパティー定義を追加します。以下は、Red Hat Enterprise Linux システムでバインドアドレスを設定する例になります。

  • standalone.conf では、JAVA_OPTS システムプロパティー定義をファイルの最後に追加します。例を以下に示します。

    ...
    # Set the bind address
    JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address=192.168.1.2"
  • domain.conf では、プロセスコントローラーの JAVA_OPTS 設定の前に JAVA_OPTS を設定する必要があります。例を以下に示します。

    ...
    # Set the bind address
    JAVA_OPTS="$JAVA_OPTS -Djboss.bind.address=192.168.1.2"
    
    # The ProcessController process uses its own set of java options
    if [ "x$PROCESS_CONTROLLER_JAVA_OPTS" = "x" ]; then
    ...

3.10. 管理監査ロギング

管理コンソール、管理 CLI、または管理 API を使用するカスタムアプリケーションを使用して実行されたすべての操作をログに記録する、管理インターフェースの監査ロギングを有効にできます。監査ログエントリーは JSON 形式で保存されます。監査ロギングはデフォルトでは無効になっています。

監査ロギングを設定して ファイル または syslog サーバー へ出力できます。

注記

JBoss EAP には認証されたセッションがないため、ログインおよびログアウトイベントは監査できません。その代わりに、ユーザーから操作を受信すると監査メッセージがログに記録されます。

スタンドアロンサーバーの監査ロギング

監査ロギングはデフォルトでは無効になっていますが、デフォルトの監査ロギング設定はファイルに書き込みします。

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="file"/>
        </handlers>
    </logger>
</audit-log>

この設定は、以下の管理 CLI コマンドを使用して読み取ることができます。

/core-service=management/access=audit:read-resource(recursive=true)

スタンドアロンサーバーの監査ロギングを有効にする場合は、「監査ロギングの有効化」を参照してください。

管理対象ドメインの監査ロギング

監査ロギングはデフォルトでは無効になっていますが、デフォルトの監査ロギング設定は各ホストおよび各サーバーに対してファイルを書き込みします。

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/>
        <file-handler name="server-file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="host-file"/>
        </handlers>
    </logger>
    <server-logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="server-file"/>
        </handlers>
    </server-logger>
</audit-log>

この設定は、以下の管理 CLI コマンドを使用して読み取ることができます。

/host=HOST_NAME/core-service=management/access=audit:read-resource(recursive=true)

管理対象ドメインの監査ロギングを有効にする場合は、「監査ロギングの有効化」を参照してください。

3.10.1. 管理監査ロギングの有効化

監査ロギングはデフォルトでは無効になっていますが、JBoss EAP には監査ロギングのファイルハンドラーが事前設定されています。監査ロギングを有効にする管理 CLI コマンドは、スタンドアロンサーバーとして実行しているかまたは管理対象ドメインで実行しているかによって異なります。ファイルハンドラーの属性は「管理監査ロギング属性」を参照してください。

次の手順では、NATIVE および HTTP 監査ロギングを有効にします。JMX 監査ロギングを設定する場合は「JMX 管理監査ロギングの有効化」を参照してください。

syslog 監査ロギングを設定する場合は「 syslog サーバーへの管理監査ロギングの送信」を参照してください。

スタンドアロンサーバー監査ロギングの有効化

監査ロギングは以下のコマンドを使用して有効にできます。

/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

デフォルトでは、このコマンドによって監査ログが EAP_HOME/standalone/data/audit-log.log に書き込まれます。

管理対象ドメイン監査ロギングの有効化

管理対象ドメインのデフォルトの監査ログ設定は、各ホストおよび各サーバーに対して監査ログを書き込むよう事前設定されています。

各ホストの監査ロギングは以下のコマンドを使用して有効にできます。

/host=HOST_NAME/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

デフォルトでは、このコマンドによって監査ログが EAP_HOME/domain/data/audit-log.log に書き込まれます。

各サーバーの監査ロギングは以下のコマンドを使用して有効にできます。

/host=HOST_NAME/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)

デフォルトでは、このコマンドによって監査ログが EAP_HOME/domain/servers/SERVER_NAME/data/audit-log.log に書き込まれます。

3.10.2. JMX 管理監査ロギングの有効化

JBoss EAP には、JMX 監査ロギングのファイルハンドラーが事前設定されていますが、これらのログはデフォルトで無効になっています。監査ロギングを有効にする管理 CLI コマンドは、スタンドアロンサーバーまたは管理対象ドメインとして実行しているかによって異なります。

NATIVE または HTTP 監査ロギングを設定する場合は「管理監査ロギングの有効化」を参照してください。

スタンドアロンサーバーの JMX 監査ロギングの有効化

以下のコマンドを使用すると、スタンドアロンサーバーでの JMX 監査ロギングを有効にできます。

/subsystem=jmx/configuration=audit-log:add()
/subsystem=jmx/configuration=audit-log/handler=file:add()

これにより、JMX 監査ロギングが有効になり、定義された file ハンドラーを使用してこれらのログを EAP_HOME/standalone/data/audit-log.log に書き込むことができるようになります。

管理対象ドメインの JMX 監査ロギングの有効化

管理対象ドメインの各ホストおよびプロファイルに JMX 監査ロギングを有効にすることができます。

ホストの JMX 監査ロギングの有効化

  1. ホストの jmx サブシステムで監査ロギングを有効にします。

    /host=HOST_NAME/subsystem=jmx/configuration=audit-log:add()
  2. jmx サブシステムの監査ロギングが有効になったら、以下のコマンドでホストにハンドラーを定義することができます。

    /host=HOST_NAME/subsystem=jmx/configuration=audit-log/handler=host-file:add()

    デフォルトでは、このコマンドによって JMX 監査ログが EAP_HOME/domain/data/audit-log.log に書き込まれます。

プロファイルの JMX 監査ロギングの有効化

  1. プロファイルの jmx サブシステムで監査ロギングを有効にします。

    /profile=PROFILE_NAME/subsystem=jmx/configuration=audit-log:add()
  2. jmx サブシステムの監査ロギングが有効になったら、以下のコマンドでプロファイルにハンドラーを定義することができます。

    /profile=PROFILE_NAME/subsystem=jmx/configuration=audit-log/handler=server-file:add()

    デフォルトでは、このコマンドによって JMX 監査ログが EAP_HOME/domain/servers/SERVER_NAME/data/audit-log.log に書き込まれます。

3.10.3. syslog サーバーへの管理監査ロギングの送信

syslog ハンドラーは、監査ログエントリーが syslog サーバーに送信されるときのパラメーター (syslog サーバーのホスト名および syslog サーバーがリッスンするポート) を指定します。監査ロギングを syslog サーバーへ送信すると、ローカルファイルまたはローカル syslog サーバーへロギングする場合よりも、セキュリティーオプションが多くなります。複数の syslog ハンドラーを同時に定義およびアクティブ化することができます。

デフォルトでは、監査ロギングが有効である場合にファイルへ出力するよう事前設定されています。以下の手順に従って、syslog サーバーへの監査ロギングを設定および有効化します。syslog ハンドラーの属性については「管理監査ロギング属性」を参照してください。

  1. syslog ハンドラーを追加します。

    syslog サーバーのホストとポートを指定して syslog ハンドラーを作成します。管理対象ドメインでは、/core-service コマンドの前に /host=HOST_NAME を追加する必要があります。

    batch
    /core-service=management/access=audit/syslog-handler=SYSLOG_HANDLER_NAME:add(formatter=json-formatter)
    /core-service=management/access=audit/syslog-handler=SYSLOG_HANDLER_NAME/protocol=udp:add(host=HOST_NAME,port=PORT)
    run-batch
    注記

    渡すパラメーターは指定されたプロトコルによって異なります。

    TLS を使用して syslog サーバーとセキュアに通信するようハンドラーを設定するには、認証を設定する必要もあります。以下に例を示します。

    /core-service=management/access=audit/syslog-handler=SYSLOG_HANDLER_NAME/protocol=tls/authentication=truststore:add(keystore-path=PATH_TO_TRUSTSTORE,keystore-password=TRUSTSTORE_PASSWORD)
  2. syslog ハンドラーへの参照を追加します。

    管理対象ドメインでは、このコマンドの前に /host=HOST_NAME を追加する必要があります。

    /core-service=management/access=audit/logger=audit-log/handler=SYSLOG_HANDLER_NAME:add
  3. 監査ロギングを有効にします。

    管理監査ロギングの有効化」を参照して監査ロギングを有効にします。

重要

オペレーティングシステムでロギングが有効になっていないと、JBoss EAP で syslog サーバーへの監査ロギングを有効にしても動作しません。

Red Hat Enterprise Linux の rsyslog 設定の詳細は、https://access.redhat.com/documentation/ja/red-hat-enterprise-linux/ にて『システム管理者のガイド』の「Rsyslog の基本設定」の項を参照してください。

3.10.4. 監査ログエントリーの読み取り

ファイルに出力される監査ログエントリーは、テキストビューアーで参照することをお勧めします。 syslog サーバーに出力される監査ログエントリーは syslog ビューアーアプリケーションで参照することをお勧めします

注記

ログファイルの参照にテキストエディターを使用することは推奨されません。 これは、追加のログエントリーがログファイルに書き込まれなくなることがあるためです。

監査ログエントリーは JSON 形式で保存されます。各ログエントリーは最初にオプションのタイムスタンプ、次に以下の表のフィールドが示されます。

表3.6 管理監査ログフィールド

フィールド名説明

access

以下のいずれかの値を使用できます。

  • NATIVE - 操作がネイティブ管理インターフェースから実行されます。
  • HTTP - 操作がドメイン HTTP インターフェースから実行されます。
  • JMX - 操作が jmx サブシステムから実行されます。

booting

起動プロセス中に操作が実行された場合は、値が true になります。 サーバーの起動後に操作が実行された場合は false になります。

domainUUID

ドメインコントローラーからサーバー、スレーブホストコントローラー、およびスレーブホストコントローラーサーバーへ伝播されるすべての操作をリンクする ID。

ops

実行される操作。JSON へシリアライズ化された操作のリストになります。起動時は、XML の解析で生じたすべての操作がリストされます。起動後は、通常 1 つのエントリーがリストされます。

r/o

操作によって管理モデルが変更されない場合は、値が true になります。 変更される場合は false になります。

remote-address

この操作を実行するクライアントのアドレス。

success

操作に成功した場合は値が true になります。 ロールバックされた場合は false になります。

type

管理操作であることを示す core、または jmx サブシステムからであることを示す jmx を値として指定できます。

user

認証されたユーザーのユーザー名。稼働しているサーバーと同じマシンの管理 CLI を使用して操作を行った場合は、特別な $local ユーザーが使用されます。

version

JBoss EAP インスタンスのバージョン番号。

3.11. サーバーライフサイクルイベントの通知

JBoss EAP core-management サブシステム または JMX を使用してサーバーライフサイクルイベントの通知を設定できます。サーバーランタイム設定の状態やサーバー稼働の状態が変更されると、通知が発生します。

JBoss EAP のサーバーランタイム設定の状態には、STARTINGRUNNINGRELOAD_REQUIREDRESTART_REQUIREDSTOPPING、および STOPPED があります。

JBoss EAP のサーバー稼働の状態には、STARTINGNORMALADMIN_ONLYPRE_SUSPENDSUSPENDINGSUSPENDEDSTOPPING、および STOPPED があります。

3.11.1. core-management サブシステムを使用したサーバーライフサイクルイベントの監視

リスナーを JBoss EAP core-management サブシステムに登録すると、サーバーのライフサイクルイベントを監視できます。以下の手順は、イベントをログファイルの記録するサンプルリスナーを作成および登録する方法を示しています。

  1. リスナーを作成します。

    以下の例のように、org.wildfly.extension.core.management.client.ProcessStateListener の実装を作成します。

    例: リスナークラス

    package org.simple.lifecycle.events.listener;
    
    import java.io.File;
    import java.io.FileWriter;
    import java.io.IOException;
    
    import org.wildfly.extension.core.management.client.ProcessStateListener;
    import org.wildfly.extension.core.management.client.ProcessStateListenerInitParameters;
    import org.wildfly.extension.core.management.client.RunningStateChangeEvent;
    import org.wildfly.extension.core.management.client.RuntimeConfigurationStateChangeEvent;
    
    public class SimpleListener implements ProcessStateListener {
    
        private File file;
        private FileWriter fileWriter;
        private ProcessStateListenerInitParameters parameters;
    
        public void init(ProcessStateListenerInitParameters parameters) {
            this.parameters = parameters;
            this.file = new File(parameters.getInitProperties().get("file"));
            try {
                fileWriter = new FileWriter(file, true);
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    
        public void cleanup() {
            try {
                fileWriter.close();
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                fileWriter = null;
            }
        }
    
        public void runtimeConfigurationStateChanged(RuntimeConfigurationStateChangeEvent evt) {
            try {
                fileWriter.write(String.format("Runtime configuration state change for %s: %s to %s\n", parameters.getProcessType(), evt.getOldState(), evt.getNewState()));
                fileWriter.flush();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    
        public void runningStateChanged(RunningStateChangeEvent evt) {
            try {
                fileWriter.write(String.format("Running state change for %s: %s to %s\n", parameters.getProcessType(), evt.getOldState(), evt.getNewState()));
                fileWriter.flush();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    注記

    リスナーの実装時には以下に気をつけてください。

    • サーバーがリロードすると、サーバーの停止時にリスナーはリッスンを停止し、サーバーの起動時にリスナーはリロードされます。そのため、実装では同じ JVM 内部でリスナーを適切に複数回ロード、初期化、および削除できるようにする必要があります。
    • サーバー状態の変更に対応できるようにするため、リスナーへの通知はブロッキング状態になります。実装では、リスナーがブロックまたはデッドロックしないようにする必要があります。
    • 各リスナーインスタンスは独自のスレッドで実行され、順番は保証されません。
  2. クラスおよびパッケージを JAR にコンパイルします。

    コンパイルするには、org.wildfly.core:wildfly-core-management-client Maven モジュールに依存する必要があります。

  3. JAR を JBoss EAP モジュールとして追加します。

    以下の管理 CLI コマンドを使用し、モジュール名と JAR へのパスを提供します。

    module add --name=org.simple.lifecycle.events.listener --dependencies=org.wildfly.extension.core-management-client --resources=/path/to/simple-listener-0.0.1-SNAPSHOT.jar
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  4. リスナーを登録します。

    以下のかんり CLI コマンドを使用してリスナーを core-management サブシステムに追加します。クラス、モジュール、およびサーバーライフサイクルイベントを記録するログファイルの場所を指定します。

    /subsystem=core-management/process-state-listener=my-simple-listener:add(class=org.simple.lifecycle.events.listener.SimpleListener, module=org.simple.lifecycle.events.listener,properties={file=/path/to/my-listener-output.txt})

上記の SimpleListener クラスを基にしてサーバーライフサイクルのイベントが my-listener-output.txt ファイルに記録されるようになりました。たとえば、管理 CLI で :suspend コマンドを実行すると、以下が my-listener-output.txt ファイルに出力されます。

Running state change for STANDALONE_SERVER: normal to suspending
Running state change for STANDALONE_SERVER: suspending to suspended

これを見ると、稼働状態が normal から suspending に変わった後、suspending から suspended に変わったことがわかります。

3.11.2. JMX 通知を使用したサーバーライフサイクルイベントの監視

JMX 通知リスナーを登録すると、サーバーのライフサイクルイベントを監視できます。以下の手順は、イベントをログファイルの記録するサンプルリスナーを作成および追加する方法を示しています。

  1. リスナーを作成します。

    以下の例のように、javax.management.NotificationListener の実装を作成します。

    例: リスナークラス

    import java.io.BufferedWriter;
    import java.io.IOException;
    import java.nio.charset.StandardCharsets;
    import java.nio.file.Files;
    import java.nio.file.Path;
    import java.nio.file.Paths;
    import java.nio.file.StandardOpenOption;
    
    import javax.management.AttributeChangeNotification;
    import javax.management.Notification;
    import javax.management.NotificationListener;
    
    import org.jboss.logging.Logger;
    
    public class StateNotificationListener implements NotificationListener {
    
      public static final String RUNTIME_CONFIGURATION_FILENAME = "runtime-configuration-notifications.txt";
      public static final String RUNNING_FILENAME = "running-notifications.txt";
      private final Path targetFile;
    
      public StateNotificationListener() {
        this.targetFile = Paths.get("notifications/data").toAbsolutePath();
        init(targetFile);
      }
    
      protected Path getRuntimeConfigurationTargetFile() {
        return this.targetFile.resolve(RUNTIME_CONFIGURATION_FILENAME);
      }
    
      protected Path getRunningConfigurationTargetFile() {
        return this.targetFile.resolve(RUNNING_FILENAME);
      }
    
      protected final void init(Path targetFile) {
        try {
          Files.createDirectories(targetFile);
    
          if (!Files.exists(targetFile.resolve(RUNTIME_CONFIGURATION_FILENAME))) {
            Files.createFile(targetFile.resolve(RUNTIME_CONFIGURATION_FILENAME));
          }
    
          if (!Files.exists(targetFile.resolve(RUNNING_FILENAME))) {
            Files.createFile(targetFile.resolve(RUNNING_FILENAME));
          }
        } catch (IOException ex) {
            Logger.getLogger(StateNotificationListener.class).error("Problem handling JMX Notification", ex);
        }
      }
    
      @Override
      public void handleNotification(Notification notification, Object handback) {
        AttributeChangeNotification attributeChangeNotification = (AttributeChangeNotification) notification;
        if ("RuntimeConfigurationState".equals(attributeChangeNotification.getAttributeName())) {
          writeNotification(attributeChangeNotification, getRuntimeConfigurationTargetFile());
        } else {
          writeNotification(attributeChangeNotification, getRunningConfigurationTargetFile());
        }
      }
    
      private void writeNotification(AttributeChangeNotification notification, Path path) {
        try (BufferedWriter in = Files.newBufferedWriter(path, StandardCharsets.UTF_8, StandardOpenOption.APPEND)) {
          in.write(String.format("%s %s %s %s", notification.getType(), notification.getSequenceNumber(), notification.getSource().toString(), notification.getMessage()));
          in.newLine();
          in.flush();
        } catch (IOException ex) {
          Logger.getLogger(StateNotificationListener.class).error("Problem handling JMX Notification", ex);
        }
      }
    }

  2. 通知リスナーを登録します。

    通知リスナーを MBeanServer に追加します。

    例: 通知リスナーの追加

    MBeanServer server = ManagementFactory.getPlatformMBeanServer();
    server.addNotificationListener(ObjectName.getInstance("jboss.root:type=state"), new StateNotificationListener(), null, null);

  3. JBoss EAP にパッケージ化およびデプロイします。

上記の StateNotificationListener クラスを基にしてサーバーライフサイクルイベントがファイルに記録されるようになりました。たとえば、管理 CLI で :suspend コマンドを実行すると、以下が running-notifications.txt ファイルに出力されます。

jmx.attribute.change 5 jboss.root:type=state The attribute 'RunningState' has changed from 'normal' to 'suspending'
jmx.attribute.change 6 jboss.root:type=state The attribute 'RunningState' has changed from 'suspending' to 'suspended'

これを見ると、稼働状態が normal から suspending に変わった後、suspending から suspended に変わったことがわかります。

第4章 ネットワークおよびポート設定

4.1. インターフェース

JBoss EAP は設定全体で名前付きインターフェースを参照します。これにより、使用ごとにインターフェースの完全な詳細を必要とせず、論理名を使用して個々のインターフェース宣言を参照できます。

また、複数のマシンでネットワークインターフェースの詳細が異なる場合に管理対象ドメインの設定が容易になります。各サーバーインスタンスは、論理名グループに対応できます。

standalone.xmldomain.xml、および host.xml ファイルにはインターフェース宣言が含まれます。使用されるデフォルトの設定に応じて、複数の事前設定されたインターフェース名があります。management インターフェースは、HTTP 管理エンドポイントを含む、管理レイヤーが必要なすべてのコンポーネントおよびサービスに使用できます。public インターフェースは、アプリケーション関連のネットワーク通信すべてに使用できます。unsecure インターフェースは、標準設定の IIOP ソケットに使用されます。private インターフェースは、標準設定の JGroups ソケットに使用されます。

4.1.1. デフォルトインターフェース設定

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="private">
    <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

デフォルトでは、JBoss EAP はこれらのインターフェースを 127.0.0.1 にバインドしますが、適切なプロパティーを設定すると起動時に値を上書きできます。たとえば、以下のコマンドで JBoss EAP をスタンドアロンサーバーとして起動するときに public インターフェースの inet-address を設定できます。

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

この代わりに、サーバー起動のコマンドラインで -b スイッチを使用することができます。サーバー起動オプションの詳細は、「サーバーランタイム引数」を参照してください。

重要

JBoss EAP が使用するデフォルトのネットワークインターフェースまたはポートを変更する場合は、変更したインターフェースまたはポートを使用するスクリプトを変更する必要があることに注意してください。これには JBoss EAP サービススクリプトが含まれます。 また、管理コンソールまたは CLI にアクセスするときに適切なインターフェースとポートを指定するようにしてください。

4.1.2. インターフェースの設定

ネットワークインターフェースは、物理インターフェースの論理名および選択基準を指定して宣言されます。選択基準はワイルドカードアドレスを参照したり、一致が有効となるためにインターフェースまたはアドレスで必要となる 1 つ以上の特徴のセットを指定したりできます。使用できるすべてのインターフェース選択基準は「インターフェース属性」を参照してください。

インターフェースは管理コンソールまたは管理 CLI を使用して設定できます。以下にインターフェースの追加および更新の例をいくつか示します。最初に管理 CLI コマンドを示し、その後に対応する設定 XML を示します。

NIC 値があるインターフェースの追加

NIC 値が eth0 であるインターフェースを新たに追加します。

/interface=external:add(nic=eth0)
<interface name="external">
   <nic name="eth0"/>
</interface>
複数の条件値があるインターフェースの追加

稼働時に適切なサブネットのすべてのインターフェースまたはアドレスと一致し、マルチキャストをサポートする、ポイントツーポイントでないインターフェースを新たに追加します。

/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})
<interface name="default">
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>
インターフェース属性の更新

public インターフェースのデフォルトの inet-address 値を更新し、jboss.bind.address プロパティーによってこの値が起動時に設定されるようにします。

/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")
<interface name="public">
    <inet-address value="${jboss.bind.address:192.168.0.0}"/>
</interface>
管理対象ドメインでインターフェースをサーバーに追加
/host=HOST_NAME/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)
<servers>
   <server name="SERVER_NAME" group="main-server-group">
      <interfaces>
         <interface name="INTERFACE_NAME">
            <inet-address value="127.0.0.1"/>
         </interface>
      </interfaces>
   </server>
</servers>

4.2. ソケットバインディング

ソケットバインディングとソケットバインディンググループを使用することにより、ネットワークポートと、JBoss EAP の設定で必要なネットワーキングインターフェースとの関係を定義できます。ソケットバインディングはソケットの名前付き設定です。ソケットバインディンググループは、ある論理名でグループ化されたソケットバインディング宣言のコレクションです。

これにより、使用ごとにソケット設定の完全な詳細を必要とせずに、設定の他のセクションが論理名でソケットバインディングを参照できるようになります。

これらの名前付き設定の宣言は standalone.xml および domain.xml 設定ファイルにあります。スタンドアロンサーバーにはソケットバインディンググループが 1 つのみ含まれますが、管理対象ドメインには複数のグループを含むことができます。管理対象ドメインで各サーバーグループのソケットバインディンググループを作成するか、複数のサーバーグループ間でソケットバインディンググループを共有することができます。

デフォルトで JBoss EAP によって使用されるポートは、使用されるソケットバインディンググループと、個々のデプロイメントの要件に応じて異なります。

JBoss EAP 設定のソケットバインディンググループで定義できるソケットバインディングには 3 つの種類があります。

インバウンドソケットバインディング

socket-binding 要素は、JBoss EAP サーバーのインバウンドソケットバインディングを設定するために使用されます。デフォルトの JBoss EAP 設定には、HTTP や HTTPS トラフィック用などの、事前設定された socket-binding 要素が複数提供されます。JBoss EAP『Configuring Messaging』の「Broadcast Groups」には他の例も記載されています。

この要素の属性については、インバウンドソケットバインディングの属性の表を参照してください。

リモートアウトバウンドソケットバインディング

remote-destination-outbound-socket-binding 要素は、JBoss EAP サーバーのリモートとなる宛先のアウトバウンドソケットバインディングを設定するために使用されます。デフォルトの JBoss EAP 設定には、メールサーバーに使用できるリモート宛先のソケットバインディングの例が含まれています。JBoss EAP『Configuring Messaging』の「Using the Integrated Artemis Resource Adapter for Remote Connections」には、他の例も記載されています。

この要素の属性については、リモートアウトバウンドソケットバインディングの属性の表を参照してください。

ローカルアウトバウンドソケットバインディング

local-destination-outbound-socket-binding 要素は、JBoss EAP サーバーのローカルとなる宛先のアウトバウンドソケットバインディングを設定するために使用されます。通常、このソケットバインディングはあまり使用されません。

この要素の属性については、ローカルアウトバウンドソケットバインディングの属性 の表を参照してください。

4.2.1. 管理ポート

JBoss EAP 7 では、管理ポートが集約されました。JBoss EAP 7 は、管理 CLI によって使用されるネイティブ管理と、Web ベース管理コンソールによって使用される HTTP 管理の両方に 9990 ポートを使用します。JBoss EAP 6 でネイティブ管理ポートとして使用されていた 9999 ポートは使用されなくなりましたが、必要な場合は有効にできます。

管理コンソールに対して HTTPS を有効にすると、デフォルトではポート 9993 が使用されます。

4.2.2. デフォルトのソケットバインディング

JBoss EAP には、事前設定された 5 つのプロファイル (defaulthafullfull-haload-balancer) のソケットバインディンググループが含まれています。

デフォルトのポートや説明などのデフォルトのソケットバインディングに関する詳細情報は、「デフォルトのソケットバインディング」を参照してください。

重要

JBoss EAP が使用するデフォルトのネットワークインターフェースまたはポートを変更する場合は、変更したインターフェースまたはポートを使用するスクリプトを変更する必要があることに注意してください。これには JBoss EAP サービススクリプトが含まれます。 また、管理コンソールまたは CLI にアクセスするときに適切なインターフェースとポートを指定するようにしてください。

スタンドアロンサーバー

スタンドアロンサーバーとして実行されている場合、設定ファイルごとに 1 つのソケットバインディンググループのみが定義されます。各スタンドアロン設定ファイル (standalone.xmlstandalone-ha.xmlstandalone-full.xmlstandalone-full-ha.xmlstandalone-load-balancer.xml) は、対応するプロファイルによって使用される技術のソケットバインディングを定義します。

たとえば、デフォルトのスタンドアロン設定ファイル (standalone.xml) は以下のソケットバインディングを指定します。

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>
管理対象ドメイン

管理対象ドメインで実行されている場合、すべてのソケットバインディンググループは domain.xml ファイルで定義されます。事前定義されたソケットバインディンググループは 5 つあります。

  • standard-sockets
  • ha-sockets
  • full-sockets
  • full-ha-sockets
  • load-balancer-sockets

各ソケットバインディンググループは、対応するプロファイルによって使用される技術のソケットバインディングを指定します。たとえば、full-ha-sockets ソケットバインディンググループは、高可用性のために full-ha プロファイルによって使用される複数の jgroups ソケットバインディングを定義します。

<socket-binding-groups>
  <socket-binding-group name="standard-sockets" default-interface="public">
    <!-- Needed for server groups using the 'default' profile  -->
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
      <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
  </socket-binding-group>
  <socket-binding-group name="ha-sockets" default-interface="public">
    <!-- Needed for server groups using the 'ha' profile  -->
    ...
  </socket-binding-group>
  <socket-binding-group name="full-sockets" default-interface="public">
    <!-- Needed for server groups using the 'full' profile  -->
    ...
  </socket-binding-group>
  <socket-binding-group name="full-ha-sockets" default-interface="public">
    <!-- Needed for server groups using the 'full-ha' profile  -->
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="iiop" interface="unsecure" port="3528"/>
    <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/>
    <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
    <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
    <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
    <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
      <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
  </socket-binding-group>
  <socket-binding-group name="load-balancer-sockets" default-interface="public">
    <!-- Needed for server groups using the 'load-balancer' profile  -->
    ...
  </socket-binding-group>
</socket-binding-groups>
注記

管理インターフェースのソケット設定は、ドメインコントローラーの host.xml ファイルに定義されます。

4.2.3. ソケットバインディングの設定

ソケットバインディングを設定するとき、port および interface 属性や、multicast-address および multicast-port などのマルチキャスト設定を設定できます。使用できるソケットバインディング属性すべての詳細は、「ソケットバインディングの属性」を参照してください。

ソケットバインディングは管理コンソールまたは管理 CLI を使用して設定できます。以下の手順では、ソケットバインディンググループの追加、ソケットバインディングの追加、および管理 CLI を使用したソケットバインディングの設定を行います。

  1. 新しいソケットバインディンググループを追加します。スタンドアロンサーバーとして実行している場合は追加できないことに注意してください。

    /socket-binding-group=new-sockets:add(default-interface=public)
  2. ソケットバインディングを追加します。

    /socket-binding-group=new-sockets/socket-binding=new-socket-binding:add(port=1234)
  3. ソケットバインディンググループによって設定されるデフォルト以外のインターフェースを使用するよう、ソケットバインディングを変更します。

    /socket-binding-group=new-sockets/socket-binding=new-socket-binding:write-attribute(name=interface,value=unsecure)

以下の例は、上記の手順の完了後に XML 設定がどのようになるかを示しています。

<socket-binding-groups>
    ...
    <socket-binding-group name="new-sockets" default-interface="public">
        <socket-binding name="new-socket-binding" interface="unsecure" port="1234"/>
    </socket-binding-group>
</socket-binding-groups>

4.2.4. サーバーのソケットバインディングおよび解放ポートの表示

管理コンソールからソケットバインディング名とサーバーの解放ポートを表示できます。サーバーの状態が以下になると、情報が表示されます。

  • running
  • reload-required
  • restart-required

サーバーのソケットバインディングと解放ポートを表示するには、以下を実行します。

  1. 管理コンソールにアクセスし、Runtime に移動します。
  2. サーバーをクリックすると、ソケットバインディング名と解放ポートが右側のペインに表示されます。

4.2.5. ポートオフセット

ポートオフセットとは、該当するサーバーのソケットバインディンググループに指定されたすべてのポート値に追加される数値のオフセットのことです。これにより、同じホストの別のサーバーとの競合を防ぐため、サーバーはソケットバインディンググループに定義されたポート値とオフセットを継承できるようになります。たとえば、ソケットバインディンググループの HTTP ポートが 8080 で、サーバーが 100 をポートオフセットとして使用する場合、HTTP ポートは 8180 になります。

管理 CLI を使用して管理対象ドメインのサーバーにポートオフセットとして 250 を設定する例を以下に示します。

/host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)

ポートオフセットは、管理対象ドメインのサーバーと、同じホストで複数のスタンドアロンサーバーを実行する場合に使用できます。

jboss.socket.binding.port-offset プロパティーを使用してスタンドアロンサーバーを起動するときにポートオフセットを渡すことができます。

$ EAP_HOME/bin/standalone.sh -Djboss.socket.binding.port-offset=100

4.3. IPv6 アドレス

デフォルトでは、JBoss EAP は IPv4 アドレスを使用して実行するように設定されます。以下の手順では、IPv6 アドレスを使用して実行するよう JBoss EAP を設定する方法を示します。

IPv6 アドレスの JVM スタックの設定

IPv6 アドレスを優先するように、起動設定を更新します。

  1. 起動設定ファイルを開きます。

    • スタンドアロンサーバーとして実行している場合は、EAP_HOME/bin/standalone.conf ファイル (Windows Server の場合は standalone.conf.bat) を編集します。
    • 管理対象ドメインで実行している場合は、EAP_HOME/bin/domain.conf ファイル (Windows Server の場合は domain.conf.bat) を編集します。
  2. java.net.preferIPv4Stack プロパティーを false に設定します。

    -Djava.net.preferIPv4Stack=false
  3. java.net.preferIPv6Addresses プロパティーを追加し、true に設定します。

    -Djava.net.preferIPv6Addresses=true

以下の例は、上記の変更を行った後に起動設定ファイルの JVM オプションがどのようになるかを示しています。

# Specify options to pass to the Java VM.
#
if [ "x$JAVA_OPTS" = "x" ]; then
   JAVA_OPTS="-Xms1303m -Xmx1303m -Djava.net.preferIPv4Stack=false"
   JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
   JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv6Addresses=true"
else

IPv6 アドレスのインターフェース宣言の更新

設定のデフォルトのインターフェース値は、IPv6 アドレスに変更できます。たとえば、以下の管理 CLI コマンドは management インターフェースを IPv6 ループバックアドレス (::1) に設定します。

/interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:[::1]}")

以下の例は、上記のコマンド実行後に XML 設定がどのようになるかを示しています。

<interfaces>
    <interface name="management">
        <inet-address value="${jboss.bind.address.management:[::1]}"/>
    </interface>
    ....
</interfaces>

第5章 JBoss EAP のセキュリティー

JBoss EAP は、独自のインターフェースおよびサービスのセキュリティーを設定できる機能と、JBoss EAP で実行されるアプリケーションのセキュリティーを提供します。

第6章 JBoss EAP クラスローディング

JBoss EAP は、デプロイされたアプリケーションのクラスパスを制御するためにモジュール形式のクラスロードシステムを使用します。このシステムは、階層クラスローダーの従来のシステムよりも、柔軟性があり、より詳細に制御できます。開発者は、アプリケーションで利用可能なクラスに対して粒度の細かい制御を行い、アプリケーションサーバーで提供されるクラスを無視して独自のクラスを使用するようデプロイメントを設定できます。

モジュール形式のクラスローダーにより、すべての Java クラスはモジュールと呼ばれる論理グループに分けられます。各モジュールは、独自のクラスパスに追加されたモジュールからクラスを取得するために、他のモジュールの依存関係を定義できます。デプロイされた各 JAR および WAR ファイルはモジュールとして扱われるため、開発者はモジュール設定をアプリケーションに追加してアプリケーションのクラスパスの内容を制御できます。

6.1. モジュール

モジュールは、クラスローディングおよび依存関係管理に使用されるクラスの論理グループです。JBoss EAP は、静的モジュールと動的モジュールの 2 つの種類のモジュールを識別します。この 2 つの種類のモジュールの主な違いは、パッケージ化方法です。

静的モジュール

静的モジュールは、アプリケーションサーバーの EAP_HOME/modules/ ディレクトリーで定義されます。各モジュールは EAP_HOME/modules/com/mysql/ のようにサブディレクトリーとして存在します。各モジュールには、module.xml 設定ファイルとすべての必要な JAR ファイルが含まれるスロットサブディレクトリー (デフォルトでは main) が含まれます。アプリケーションサーバーにより提供される API は、Jakarta EE API と他の API を含む静的モジュールとして提供されます。

例: MySQL JDBC ドライバー module.xml ファイル

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-8.0.12.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

モジュール名 com.mysql は、スロット名 main を除くモジュールのディレクトリー構造と一致する必要があります。

カスタム静的モジュールの作成は、同じサードパーティーライブラリーを使用する同じサーバー上に多くのアプリケーションがデプロイされる場合に役立ちます。これらのライブラリーを各アプリケーションとバンドルする代わりに、管理者はこれらのライブラリーが含まれるモジュールを作成およびインストールできます。アプリケーションは、カスタム静的モジュールで明示的な依存関係を宣言できます。

JBoss EAP ディストリビューションで提供されるモジュールは、EAP_HOME/modules ディレクトリー内の system ディレクトリーにあります。このため、サードパーティーによって提供されるモジュールから分離されます。また、JBoss EAP 上で使用する、Red Hat により提供されるすべての製品によって、system ディレクトリー内にモジュールがインストールされます。

モジュールごとに 1 つのディレクトリーを使用して、カスタムモジュールが EAP_HOME/modules ディレクトリーにインストールされるようにする必要があります。こうすると、同梱されたバージョンではなく、system ディレクトリーに存在するカスタムバージョンのモジュールがロードされるようになります。これにより、ユーザー提供のモジュールがシステムモジュールよりも優先されます。

JBOSS_MODULEPATH 環境変数を使用して JBoss EAP がモジュールを検索する場所を変更する場合は、指定された場所の 1 つで system サブディレクトリー構造を探します。system 構造は、JBOSS_MODULEPATH で指定された場所のどこかに存在する必要があります。

注記

JBoss EAP 7.1 より、module.xml ファイルの resource-root path 要素で絶対パスを使用できるようになりました。これにより、リソースライブラリーを EAP_HOME/modules/ ディレクトリーに移動しなくてもリソースライブラリーにアクセスできるようになりました。

例: module.xml ファイルの絶対パス

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="oracle.jdbc">
    <resources>
        <resource-root path="/home/redhat/test.jar"/>
    </resources>
</module>

動的モジュール

動的モジュールは、各 JAR または WAR デプロイメント (または、EAR 内のサブデプロイメント) に対してアプリケーションサーバーによって作成およびロードされます。動的モジュールの名前は、デプロイされたアーカイブの名前に由来します。デプロイメントはモジュールとしてロードされるため、依存関係を設定し、他のデプロイメントで依存関係として使用することが可能です。

モジュールは必要な場合にのみロードされます。通常、モジュールは、明示的または暗黙的な依存関係があるアプリケーションがデプロイされる場合にのみロードされます。

事前定義されたモジュール

JBoss EAP 7.2 より、デフォルトのモジュールローダーを使用する場合に事前設定されたモジュールのセットを使用できるようになりました。このモジュールはすべての JBoss Modules API が含まれる org.jboss.modules で、JBoss Modules によって提供され、常に利用可能です。Java 9 以上で提供される標準の Java Platform Module System (JPMS) モジュールも標準の名前で利用可能です。JDK 8 を使用する場合、JDK 9 モジュールは JBoss Module によってエミュレートされます。

Java 9 以上で使用できるプラットフォームモジュールの一覧は、該当する JDK のドキュメントを参照してください。

Java 8 向けに提供されるプラットフォームモジュールの一覧は、「Java 8 向けに提供されるプラットフォームモジュール」を参照してください。

6.2. モジュールの依存性

モジュール依存関係は、あるモジュールに他の 1 つまたは複数のモジュールのクラスが必要になるという宣言です。JBoss EAP がモジュールをロードするときに、モジュール形式のクラスローダーがモジュールの依存関係を解析し、各依存関係のクラスをクラスパスに追加します。指定の依存関係が見つからない場合、モジュールはロードできません。

注記

モジュールとモジュール形式のクラスロードシステムに関する完全な詳細については、「モジュール」を参照してください。

JAR や WAR などのデプロイされたアプリケーションは動的モジュールとしてロードされ、依存関係を利用して JBoss EAP によって提供される API にアクセスします。

依存関係には明示的暗黙的の 2 つのタイプがあります。

明示的な依存関係
明示的な依存関係は開発者が設定ファイルで宣言します。静的モジュールでは、依存関係を module.xml ファイルに宣言できます。動的モジュールでは、デプロイメントの MANIFEST.MF または jboss-deployment-structure.xml デプロイメント記述子に依存関係を宣言できます。
暗黙的な依存関係

暗黙的な依存関係は、デプロイメントで特定の状態やメタデータが見つかったときに自動的に追加されます。JBoss EAP に同梱される Jakarta EE API は、デプロイメントで暗黙的な依存関係が検出されたときに追加されるモジュールの例になります。

jboss-deployment-structure.xml デプロイメント記述子ファイルを使用して、特定の暗黙的な依存関係を除外するようデプロイメントを設定することも可能です。これは、JBoss EAP が暗黙的な依存関係として追加しようとする特定バージョンのライブラリーをアプリケーションがバンドルする場合に役に立つことがあります。

オプションの依存関係

明示的な依存関係は、オプションとして指定できます。オプションの依存関係をロードできなくても、モジュールのロードは失敗しません。ただし、依存関係は後で使用できるようになっても、モジュールのクラスパスには追加されません。依存関係はモジュールがロードされるときに利用可能である必要があります。

依存関係のエクスポート

モジュールのクラスパスには独自のクラスとその直接の依存関係のクラスのみが含まれます。モジュールは 1 つの依存関係の依存関係クラスにはアクセスできませんが、暗黙的な依存関係のエクスポートを指定できます。ただし、モジュールは、明示的な依存関係をエクスポートするように指定できます。エクスポートした依存関係は、エクスポートするモジュールに依存するモジュールに提供されます。

たとえば、モジュール A はモジュール B に依存し、モジュール B はモジュール C に依存します。モジュール A はモジュール B のクラスにアクセスでき、モジュール B はモジュール C のクラスにアクセスできます。モジュール Aは以下のいずれかの条件を満たさない限り、モジュール C のクラスにアクセスできません。

  • モジュール A が、モジュール C に対する明示的な依存関係を宣言する
  • モジュール B がモジュール C の依存関係をエクスポートする

グローバルモジュール

グローバルモジュールは、JBoss EAP が各アプリケーションへの依存関係として提供するモジュールです。このモジュールをグローバルモジュールの JBoss EAP のリストへ追加すると、モジュールをグローバルモジュールにすることができます。モジュールへの変更は必要ありません。

詳細は「グローバルモジュールの定義」の項を参照してください。

6.3. カスタムモジュールの作成

カスタムの静的モジュールを追加して、JBoss EAP で実行しているデプロイメントがリソースを利用できるようにすることができます。モジュールは 手動 で作成するか、管理 CLI を使用して作成することができます。

モジュールの作成後、アプリケーションがリソースを使用できるようにするにはモジュールを依存関係として追加する必要があります。

カスタムモジュールの手動作成

カスタムモジュールを手動で作成するには、以下の手順に従います。

  1. EAP_HOME/modules/ ディレクトリーに適切なディレクトリー構造を作成します。

    例: MySQL JDBC ドライバーディレクトリー構造の作成

    $ cd EAP_HOME/modules/
    $ mkdir -p com/mysql/main

  2. JAR ファイルまたはその他必要なリソースを main/ サブディレクトリーにコピーします。

    例: MySQL JDBC ドライバー JAR のコピー

    $ cp /path/to/mysql-connector-java-8.0.12.jar EAP_HOME/modules/com/mysql/main/

  3. module.xml ファイルを main/ サブディレクトリーに作成し、そのファイルの適切なリソースおよび依存関係を指定します。

    例: MySQL JDBC ドライバー module.xml ファイル

    <?xml version="1.0" ?>
    <module xmlns="urn:jboss:module:1.1" name="com.mysql">
      <resources>
        <resource-root path="mysql-connector-java-8.0.12.jar"/>
      </resources>
      <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
      </dependencies>
    </module>

管理 CLI を使用したカスタムモジュールの作成

module add 管理 CLI コマンドを使用してカスタムモジュールを作成できます。

重要

module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  1. JBoss EAP サーバーを起動します。
  2. 管理 CLI を起動します。

    $ EAP_HOME/bin/jboss-cli.sh
  3. module add 管理 CLI コマンドを使用して新しいコアモジュールを追加します。

    module add --name=MODULE_NAME --resources=PATH_TO_RESOURCE --dependencies=DEPENDENCIES

    例: MySQL モジュールの作成

    module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javax.api,javax.transaction.api

    独自の module.xml ファイルの提供、外部モジュールディレクトリーの使用、モジュールの代替スロットの指定など、このコマンドのカスタマイズに使用できる引数については、「モジュールコマンド引数」を参照してください。また、module --help を実行すると、このコマンドを使用したモジュールの追加および削除に関する詳細を表示することもできます。

モジュールを依存関係として追加

アプリケーションがこのモジュールのリソースにアクセスできるようにするには、モジュールを依存関係として追加する必要があります。

  • デプロイメント記述子を使用してアプリケーション固有の依存関係を追加するには、『開発ガイド』の「デプロイメントへの明示的なモジュール依存関係の追加」を参照してください。

たとえば、以下の手順は複数のプロパティーファイルが含まれる JAR ファイルをモジュールとして追加し、グローバルモジュールを定義して、アプリケーションがこれらのプロパティーをロードできるようにします。

  1. JAR ファイルをコアモジュールとして追加します。

    module add --name=myprops --resources=/path/to/properties.jar
  2. すべてのデプロイメントが使用できるようにするため、このモジュールをグローバルモジュールとして定義します。

    /subsystem=ee:list-add(name=global-modules,value={name=myprops})
  3. アプリケーションは、JAR 内に含まれるプロパティーファイルの 1 つからプロパティーを読み出すことができます。

    Thread.currentThread().getContextClassLoader().getResource("my.properties");

6.4. カスタムモジュールの削除

カスタムモジュールは、手作業 または管理 CLI を使用して削除できます。

手作業によるカスタムモジュールの削除

モジュールを手作業で削除する前に、デプロイされたアプリケーションやサーバー設定 (データソースなど) がそのモジュールを必要としていないことを確認してください。

カスタムモジュールを削除するには、module.xml ファイルと関連する JAR ファイルまたはその他のリソースが含まれる EAP_HOME/modules/ 以下にあるモジュールのディレクトリーを削除します。たとえば、main スロットのカスタム MySQL JDBC ドライバーモジュールを削除するには、EAP_HOME/modules/com/mysql/main/ ディレクトリーを削除します。

管理 CLI を使用したカスタムモジュールの削除

module remove 管理 CLI コマンドを使用するとカスタムモジュールを削除できます。

重要

module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  1. JBoss EAP サーバーを起動します。
  2. 管理 CLI を起動します。

    $ EAP_HOME/bin/jboss-cli.sh
  3. module remove 管理 CLI コマンドを使用してカスタムモジュールを削除します。

    module remove --name=MODULE_NAME
    • 削除するモジュールが main 以外のスロットにある場合は、--slot 引数を使用します。

    例: MySQL モジュールの削除

    module remove --name=com.mysql

module --help を実行すると、このコマンドを使用したモジュールの追加および削除の詳細を表示できます。

6.5. グローバルモジュールの定義

モジュールを依存関係としてすべてのデプロイメントに追加する、グローバルモジュールのリストを定義できます。

注記

グローバルモジュールとして設定するモジュールの名前を知っている必要があります。含まれるモジュールの完全なリストとこれらのモジュールがサポートされているかについては、Red Hat カスタマーポータルの「JBoss Enterprise Application Platform (EAP) 7 に含まれるモジュール 」を参照してください。デプロイメントにおけるモジュールの名前付けの規則は、Dynamic Module Namingの項を参照してください。

以下の管理 CLI コマンドを使用してグローバルモジュールのリストを定義します。

/subsystem=ee:write-attribute(name=global-modules,value=[{name=MODULE_NAME_1},{name=MODULE_NAME_2}]

以下の管理 CLI コマンドを使用して、1 つのモジュールを既存のグローバルモジュールのリストに追加します。

/subsystem=ee:list-add(name=global-modules,value={name=MODULE_NAME})

管理コンソールを使用してグローバルモジュールを追加および削除することもできます。 Configuration タブから EE サブシステムに移動し、Global Modules セクションを選択します。

外部依存関係からグローバルモジュールにアクセスできるようにする必要がある場合は、明示的に可能にする必要があります。以下グローバルモジュールのサービスを外部で利用できるようにするには、以下のオプションを指定します。

  • services="import" を、jboss-deployment-structure.xml のモジュールに追加します。
  • global モジュール定義に services="true" を追加します。

    /subsystem=ee:write-attribute(name=global-modules,value=[{name=module1,services=true}]

    または、複数のモジュールを追加する場合は以下を使用します。

    /subsystem=ee:write-attribute(name=global-modules,value=[{name=module1,services=true},{name=module2,services=false}]

    新しいモジュールを既存のリストに追加するには、以下を行います。

    /subsystem=ee:list-add(name=global-modules,value={name=module1,services=true})
  • 管理コンソールを使用してグローバルモジュールを定義する場合は、Services プロパティーの値が On であることを確認します。

6.6. サブデプロイメント分離の設定

エンタープライズアーカイブ (EAR) の各サブデプロイメントは独自のクラスローダーを持つ動的モジュールです。サブデプロイメントは、EAR/lib のクラスへのアクセスを提供する親モジュールの暗黙的な依存関係を常に持ちます。デフォルトでは、サブデプロイメントはその EAR 内にある他のサブデプロイメントのリソースにアクセスできます。

サブデプロイメントが他のサブデプロイメントに属するクラスにアクセスできないようにするには、JBoss EAP で厳格なサブデプロイメント分離を有効にします。この設定はすべてのデプロイメントに影響します。

すべてのデプロイメントを対象とするサブデプロイメントモジュール分離の有効化

サブデプロイメント分離は ee サブシステムから管理コンソールまたは管理 CLI を使用して有効または無効にできます。デフォルトでは、サブデプロイメント分離は false に設定され、サブデプロイメントは EAR 内にある他のサブデプロイメントのリソースにアクセスできます。

以下の管理 CLI を使用して EAR サブデプロイメント分離を有効にします。

/subsystem=ee:write-attribute(name=ear-subdeployments-isolated,value=true)

EAR のサブデプロイメントは他のサブデプロイメントからリソースにアクセスできなくなります。

6.7. 外部 JBoss EAP モジュールディレクトリーの定義

JBoss EAP モジュールのデフォルトのディレクトリーは EAP_HOME/modules です。JBOSS_MODULEPATH 変数を使用すると JBoss EAP モジュールの他のディレクトリーを指定できます。以下の手順に従って、JBoss EAP 起動設定ファイルでこの変数を設定します。

注記

JBOSS_MODULEPATH を JBoss EAP 起動設定ファイルで設定する代わりに、環境変数として設定することもできます。

  1. 起動設定ファイルを編集します。

    • スタンドアロンサーバーとして実行している場合は、EAP_HOME/bin/standalone.conf ファイル (Windows Server の場合は standalone.conf.bat) を編集します。
    • 管理対象ドメインで実行している場合は、EAP_HOME/bin/domain.conf ファイル (Windows Server の場合は domain.conf.bat) を編集します。
  2. JBOSS_MODULEPATH 変数を設定します。 例を以下に示します。

    JBOSS_MODULEPATH="/path/to/modules/directory/"

    ディレクトリーのリストを指定するには、ディレクトリーのリストをコロン (:) で区切ります。

    注記

    Windows Server の場合、次の構文を使用して JBOSS_MODULEPATH 変数を設定します。

    set "JBOSS_MODULEPATH /path/to/modules/directory/"

    ディレクトリーのリストを指定するには、ディレクトリーのリストをセミコロン (;) で区切ります。

6.8. 動的モジュールの命名規則

JBoss EAP では、すべてのデプロイメントが、以下の規則に従って名前が付けられたモジュールとしてロードされます。

  • WAR および JAR ファイルのデプロイメントは次の形式で名前が付けられます。

    deployment.DEPLOYMENT_NAME

    たとえば、inventory.warstore.jar のモジュール名はそれぞれ deployment.inventory.wardeployment.store.jar になります。

  • エンタープライズアーカイブ (EAR) 内のサブデプロイメントは次の形式で名前が付けられます。

    deployment.EAR_NAME.SUBDEPLOYMENT_NAME

    たとえば、エンタープライズアーカイブ accounts.ear 内にある reports.war のサブデプロイメントのモジュール名は deployment.accounts.ear.reports.war になります。

第7章 アプリケーションのデプロイ

JBoss EAP には、管理者向けと開発者向けのアプリケーションデプロイメントおよび設定オプションが多くあります。管理者は、管理コンソールのグラフィカルインターフェースや管理 CLI のコマンドラインインターフェースを使用して本番環境のアプリケーションデプロイメントを管理できます。開発者は、設定可能なファイルシステムのデプロイメントスキャナーHTTP API、Red Hat Developer Studio などの IDE、および Maven などを含む、多くのテストオプションをアプリケーションのデプロイメントで使用できます。

アプリケーションをデプロイするときにデプロイメント記述子の検証を有効にするには、org.jboss.metadata.parser.validate システムプロパティーを true に設定します。これには、以下の方法の 1 つを使用します。

  • サーバー起動時

    $ EAP_HOME/bin/standalone.sh -Dorg.jboss.metadata.parser.validate=true
  • 以下の管理 CLI コマンドでサーバー設定に追加

    /system-property=org.jboss.metadata.parser.validate:add(value=true)

7.1. 管理 CLI を使用したアプリケーションのデプロイ

管理 CLI を使用してアプリケーションをデプロイすると、単一のコマンドラインインターフェースでデプロイメントスクリプトを作成および実行できます。このスクリプト機能を使用して、特定のアプリケーションデプロイメントおよび管理シナリオを設定できます。スタンドアロンサーバーとして稼働している場合は単一サーバーのデプロイメント状態を管理でき、管理対象ドメインで稼働している場合はサーバーのネットワーク全体のデプロイメントを管理できます。

7.1.1. 管理 CLI を使用したアプリケーションのスタンドアロンサーバーへのデプロイ

アプリケーションのデプロイ

管理 CLI で deployment deploy-file コマンドを使用し、アプリケーションデプロイメントへのパスを指定します。

deployment deploy-file /path/to/test-application.war

正常にデプロイされると、管理 CLI には何も出力されませんが、サーバーログにデプロイメントメッセージが記録されます。

WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war")
WFLYUT0021: Registered web context: /test-application
WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")

同様に、以下の deployment コマンドを使用できます。

  • deployment deploy-cli-archive を使用してコンテンツを .cli アーカイブファイルからデプロイします。CLI デプロイメントアーカイブは、.cli 拡張子を持つ JAR ファイルです。デプロイする必要があるアプリケーションアーカイブと、コマンドおよび操作が含まれる deploy.scr および undeploy.scr CLI スクリプトファイルが含まれます。deploy.scr スクリプトファイルには、アプリケーションアーカイブをデプロイし、環境を設定するコマンドと操作が含まれます。undeploy.scr スクリプトファイルには、アプリケーションアーカイブをアンデプロイし、環境をクリーンアップするコマンドが含まれます。
  • deployment deploy-url を使用して、URL によって参照されるコンテンツをデプロイします。

deployment enable コマンド を使用して、無効になっている アプリケーションを有効にすることもできます。

アプリケーションのアンデプロイ

管理 CLI で deployment undeploy コマンドを使用し、デプロイメント名を指定します。これにより、リポジトリーからデプロイメントコンテンツが削除されます。アンデプロイする際にデプロイメントコンテンツを維持する場合は、「Disable an Application」を参照してください。

deployment undeploy test-application.war

正常にアンデプロイされると、管理 CLI には何も出力されませんが、サーバーログにアンデプロイメントメッセージが記録されます。

WFLYUT0022: Unregistered web context: /test-application
WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 62ms
WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")

同様に、deployment undeploy-cli-archive を使用して .cli アーカイブファイルからコンテンツをアンデプロイできます。ワイルドカード (*) を使用してすべてのデプロイメントをアンデプロイすることも可能です。

deployment undeploy *
アプリケーションの無効化

デプロイメントコンテンツをリポジトリーから削除せずに、デプロイされたアプリケーションを無効にします。

deployment disable test-application.war

deployment disable-all コマンドを使用するとすべてのデプロイメントを無効化することができます。

deployment disable-all
アプリケーションの有効化

無効になっているデプロイされたアプリケーションを有効にします。

deployment enable test-application.war

deployment enable-all コマンドを使用するとすべてのデプロイメントを有効化することができます。

deployment enable-all
デプロイメントの一覧表示

管理 CLI で deployment info コマンドを使用して、デプロイメントの情報を表示します。

deployment info

出力には、ランタイム名、状態、有効であるかどうかなど、各デプロイメントの詳細が表示されます。

NAME                 RUNTIME-NAME         PERSISTENT ENABLED STATUS
helloworld.war       helloworld.war       true       true    OK
test-application.war test-application.war true       true    OK

以下のコマンドは、名前を指定してデプロイメント情報を表示します。

deployment info helloworld.war

deployment list コマンドを使用して、デプロイメントをすべて表示することもできます。

7.1.2. 管理 CLI を使用した管理対象ドメインでのアプリケーションのデプロイ

アプリケーションのデプロイ

管理 CLI で deployment deploy-file コマンドを使用し、アプリケーションデプロイメントへのパスを指定します。また、アプリケーションをデプロイするサーバーグループを指定する必要もあります。

  • すべてのサーバーグループにアプリケーションをデプロイする場合

    deployment deploy-file /path/to/test-application.war --all-server-groups
  • 特定のサーバーグループにアプリケーションをデプロイする場合

    deployment deploy-file /path/to/test-application.war --server-groups=main-server-group,other-server-group

正常にデプロイされると、管理 CLI には何も出力されませんが、サーバーログに各サーバーのデプロイメントメッセージが記録されます。

[Server:server-one] WFLYSRV0027: Starting deployment of "test-application.war" (runtime-name: "test-application.war")
[Server:server-one] WFLYUT0021: Registered web context: /test-application
[Server:server-one] WFLYSRV0010: Deployed "test-application.war" (runtime-name : "test-application.war")

同様に、以下の deployment コマンドを使用できます。

  • deployment deploy-cli-archive コマンドを使用してコンテンツを .cli アーカイブファイルからデプロイします。CLI デプロイメントアーカイブは、.cli 拡張子を持つ JAR ファイルです。デプロイする必要があるアプリケーションアーカイブと、コマンドおよび操作が含まれる deploy.scr および undeploy.scr CLI スクリプトファイルが含まれます。deploy.scr スクリプトファイルには、アプリケーションアーカイブをデプロイし、環境を設定するコマンドと操作が含まれます。undeploy.scr スクリプトファイルには、アプリケーションアーカイブをアンデプロイし、環境をクリーンアップするコマンドが含まれます。
  • deployment deploy-url コマンドを使用して、URL によって参照されるコンテンツをデプロイします。

deployment enable コマンド を使用して、無効になっている アプリケーションを有効にすることもできます。

アプリケーションのアンデプロイ

管理 CLI で deployment undeploy コマンドを使用し、デプロイメント名を指定します。また、アプリケーションをアンデプロイするサーバーグループを指定する必要もあります。特定のサーバーグループからのアンデプロイについては、「アプリケーションの無効化」を参照してください。

すべてのサーバーグループからアプリケーションをアンデプロイします。

deployment undeploy test-application.war --all-relevant-server-groups

正常にアンデプロイされると、管理 CLI には何も出力されませんが、サーバーログに各サーバーのアンデプロイメントメッセージが記録されます。

[Server:server-one] WFLYUT0022: Unregistered web context: /test-application
[Server:server-one] WFLYSRV0028: Stopped deployment test-application.war (runtime-name: test-application.war) in 74ms
[Server:server-one] WFLYSRV0009: Undeployed "test-application.war" (runtime-name: "test-application.war")

同様に、deployment undeploy-cli-archive コマンドを使用して .cli アーカイブファイルからコンテンツをアンデプロイできます。ワイルドカード (*) を使用してすべてのデプロイメントをアンデプロイすることも可能です。

deployment undeploy * --all-relevant-server-groups
アプリケーションの無効化

特定のサーバーグループからデプロイされたアプリケーションを無効にし、そのデプロイメントを持つ他のサーバーグループのリポジトリーにそのコンテンツを保持します。

deployment disable test-application.war --server-groups=other-server-group

deployment disable-all コマンドを使用するとすべてのデプロイメントを無効化することができます。

deployment disable-all --server-groups=other-server-group
アプリケーションの有効化

無効になっているデプロイされたアプリケーションを有効にします。

deployment enable test-application.war

deployment enable-all コマンドを使用するとすべてのデプロイメントを有効化することができます。

deployment enable-all --server-groups=other-server-group
デプロイメントの一覧表示

管理 CLI で deployment info コマンドを使用して、デプロイメントの情報を表示します。デプロイメント名またはサーバーグループでデプロイメント情報を絞り込むことができます。

以下のコマンドは、名前を指定してデプロイメント情報を表示します。

deployment info helloworld.war

出力には、デプロイメントと各サーバーグループでの状態が表示されます。

NAME               RUNTIME-NAME
helloworld.war     helloworld.war

SERVER-GROUP       STATE
main-server-group  enabled
other-server-group added

以下のコマンドは、サーバーグループを指定してデプロイメント情報を表示します。

deployment info --server-group=other-server-group

出力には、デプロイメントと、指定のサーバーグループに対する状態が表示されます。

NAME                 RUNTIME-NAME         STATE
helloworld.war       helloworld.war       added
test-application.war test-application.war enabled

deployment list コマンドを使用して、ドメインのデプロイメントをすべて表示することもできます。

7.2. 管理コンソールを使用したアプリケーションのデプロイ

管理コンソールを使用してアプリケーションをデプロイすると、使用が簡単なグラフィカルインターフェースを利用することができます。サーバーまたはサーバーグループにデプロイされたアプリケーションを一目で確認できるほか、必要に応じてアプリケーションを有効または無効にしたり、アプリケーションをコンテンツリポジトリーから削除したりすることができます。

7.2.1. 管理コンソールを使用したアプリケーションのスタンドアロンサーバーへのデプロイ

JBoss EAP 管理コンソールの Deployments タブからデプロイメントを表示および管理できます。

アプリケーションのデプロイ

追加 (+) ボタンをクリックします。デプロイメントのアップロード未管理デプロイメントの追加、または 空のデプロイメントの作成 を選択して、アプリケーションをデプロイできます。デプロイメントはデフォルトで有効になります。

  • 新規デプロイメントのアップロード

    サーバーのコンテンツリポジトリーにコピーされ、JBoss EAP によって管理されるアプリケーションをアップロードします。

  • 未管理デプロイメントの追加

    デプロイメントの場所を指定します。このデプロイメントはサーバーのコンテンツリポジトリーにはコピーされず、JBoss EAP によって管理されません。

  • 空のデプロイメントの作成

    空の展開形式 (exploded) のデプロイメントを作成します。このデプロイメントの作成後、ファイルをデプロイメントに追加できます。

アプリケーションのアンデプロイ

デプロイメントを選択し、Undeploy オプションを選びます。JBoss EAP により、コンテンツリポジトリーからデプロイメントが削除されます。

アプリケーションの無効化

デプロイメントを選択し、無効オプションを選択してアプリケーションを無効にします。これにより、デプロイメントがアンデプロイされますが、コンテンツリポジトリーから削除されません。

アプリケーションの置換

デプロイメントを選択し、置換オプションを選択します。元のバージョンと同じ名前を持つ新しいバージョンのデプロイメントを選択し、Finish をクリックします。これにより、元のバージョンのデプロイメントがアンデプロイおよび削除され、新しいバージョンがデプロイされます。

7.2.2. 管理コンソールを使用した管理対象ドメインでのアプリケーションのデプロイ

JBoss EAP 管理コンソールの Deployments タブではデプロイメントを表示および管理できます。

  • Content Repository

    管理されるデプロイメントと管理されないデプロイメントはすべて Content Repository セクションで表示されます。ここで、デプロイメントを追加したり、デプロイメントをサーバーグループにデプロイすることができます。

  • Server Groups

    1 つまたは複数のサーバーグループにデプロイされたデプロイメントは Server Groups セクションにリストされます。ここで、デプロイメントを直接サーバーグループに追加したり、有効にしたりすることができます。

アプリケーションの追加
  1. Content Repository追加ボタンをクリックします。
  2. デプロイメントのアップロード または 未管理のデプロイメント作成 を選択し、アプリケーションを追加します。
  3. プロンプトに従ってアプリケーションをデプロイします。

    デプロイメントを有効にするには、デプロイメントをサーバーグループにデプロイする必要があります。

アプリケーションのサーバーグループへのデプロイ
  1. Content Repository でデプロイメントを選択し、Deploy を選択します。
  2. このデプロイメントをデプロイするサーバーグループを 1 つ以上選択します。
  3. 選択したサーバーグループのデプロイメントを有効にするオプションを任意で選択することもできます。
アプリケーションのサーバーグループからのアンデプロイ
  1. Server Groups で適切なサーバーグループを選択します。
  2. 希望のデプロイメントを選択し、Undeploy ボタンをクリックします。

また、Content Repository でデプロイメントの Undeploy ボタンを選択して、複数のサーバーグループから 1 度にデプロイメントをアンデプロイすることもできます。

アプリケーションの削除
  1. デプロイメントがサーバーグループにデプロイされている場合は、必ずデプロイメントをアンデプロイします。
  2. Content Repository でデプロイメントを選択し、削除 を選択します。

これにより、コンテンツリポジトリーからデプロイメントが削除されます。

アプリケーションの無効化
  1. Server Groups で適切なサーバーグループを選択します。
  2. 無効にするデプロイメントを選択し、無効 を選択します。

これにより、デプロイメントがアンデプロイされますが、コンテンツリポジトリーから削除されません。

アプリケーションの置換
  1. Content Repository からデプロイメントを選択し、置換ボタンをクリックします。
  2. 元のバージョンと同じ名前を持つ新しいバージョンのデプロイメントを選択し、置換 をクリックします。

これにより、元のバージョンのデプロイメントがアンデプロイおよび削除され、新しいバージョンがデプロイされます。

7.3. デプロイメントスキャナーを使用したアプリケーションのデプロイ

デプロイメントスキャナーは、デプロイするアプリケーションのデプロイメントディレクトリーを監視します。デフォルトでは、デプロイメントスキャナーは 5 秒ごとに EAP_HOME/standalone/deployments/ をスキャンし、変更を確認します。デプロイメントの状態を示し、アンデプロイや再デプロイなどのデプロイメントに対するアクションをトリガーするため、マーカーファイルが使用されます。

本番環境では、アプリケーションのデプロイメントに管理コンソールまたは管理 CLI の使用が推奨されますが、デプロイメントスキャナーは開発者の便宜を図るために提供されます。これにより、ペースの早い開発サイクルに適した方法でアプリケーションを構築およびテストできます。デプロイメントスキャナーは、他のデプロイメント方法と併用しないでください。

デプロイメントスキャナーは JBoss EAP をスタンドアロンサーバーとして実行している場合のみ利用できます。

7.3.1. デプロイメントスキャナーを使用したアプリケーションのスタンドアロンサーバーへのデプロイ

デプロイメントスキャナーを設定して XML 、zip 形式、および展開形式のコンテンツの自動デプロイメントを有効または無効にすることができます。自動デプロイメントが無効の場合、マーカーファイルを手作業で作成してデプロイメントのアクションをトリガーする必要があります。利用できるマーカーファイルタイプやそれらの目的に関する詳細は、「デプロイメントスキャナーのマーカーファイル」の項を参照してください。

デフォルトでは、XML および zip 形式のコンテンツの自動デプロイメントは有効になっています。各コンテンツタイプの自動デプロイメントの設定に関する詳細は「デプロイメントスキャナーの設定」を参照してください。

警告

デプロイメントスキャナーを使用したデプロイメントは開発者の便宜を図るために提供され、本番環境での使用は推奨されません。デプロイメントスキャナーは他のデプロイメント方法と併用しないでください。

アプリケーションのデプロイ

コンテンツをデプロイメントフォルダーにコピーします。

$ cp /path/to/test-application.war EAP_HOME/standalone/deployments/

自動デプロイメントが有効の場合、このファイルは自動的に選択され、デプロイされます。さらに、.deployed マーカーファイルが作成されます。自動デプロイメントが無効の場合、.dodeploy マーカーファイルを手作業で追加し、デプロイメントをトリガーする必要があります。

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy
アプリケーションのアンデプロイ

.deployed マーカーファイルを削除して、アンデプロイメントをトリガーします。

$ rm EAP_HOME/standalone/deployments/test-application.war.deployed

自動デプロイメントが有効な場合、アンデプロイメントをトリガーする test-application.war ファイルを削除することもできます。これは、展開形式のデプロイメントには適用されないことに注意してください。

アプリケーションの再デプロイ

.dodeploy マーカーファイルを作成し、再デプロイを開始します。

$ touch EAP_HOME/standalone/deployments/test-application.war.dodeploy

7.3.2. デプロイメントスキャナーの設定

デプロイメントスキャナーは管理コンソールまたは管理 CLI を使用して設定できます。スキャンの間隔、デプロイメントフォルダーの場所、特定のアプリケーションファイルタイプの自動デプロイメントなど、デプロイメントスキャナーの動作を設定できます。また、デプロイメントスキャナーを完全に無効にすることもできます。

利用できるデプロイメントスキャナー属性の詳細は、「デプロイメントスキャナーの属性」の項を参照してください。

以下の管理 CLI コマンドを使用してデフォルトのデプロイメントスキャナーを設定します。

デプロイメントスキャナーの無効化
/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)

default デプロイメントスキャナーが無効になります。

スキャン間隔の変更
/subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-interval,value=10000)

スキャンの間隔が 5000 ミリ秒 (5 秒) から 10000 ミリ秒 (10 秒) に変更されます。

デプロイメントフォルダーの変更
/subsystem=deployment-scanner/scanner=default:write-attribute(name=path,value=/path/to/deployments)

デプロイメントフォルダーの場所がデフォルトの EAP_HOME/standalone/deployments から /path/to/deployments に変更されます。

relative-to 属性が指定されていない場合、path の値は絶対パスになります。relative-to 属性が指定されている場合は相対パスになります。

展開形式のコンテンツの自動デプロイメントの有効化
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-exploded,value=true)

デフォルトで無効になっている展開形式のコンテンツの自動デプロイメントを有効にします。

zip 形式のコンテンツの自動デプロイメントの無効化
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-zipped,value=false)

デフォルトで有効になっている zip 形式のコンテンツの自動デプロイメントを無効にします。

XML コンテンツの自動デプロイメントの無効化
/subsystem=deployment-scanner/scanner=default:write-attribute(name=auto-deploy-xml,value=false)

デフォルトで有効になっている XML コンテンツの自動デプロイメントを無効にします。

7.3.3. カスタムデプロイメントスキャナーの定義

新しいデプロイメントスキャナーを追加するには、管理 CLI を使用するか、管理コンソールの Configuration タブから Deployment Scanners サブシステムに移動します。デプロイメントを確認するためにスキャンする新しいディレクトリーを定義します。デフォルトのデプロイメントスキャナーは EAP_HOME/standalone/deployments を監視します。既存のデプロイメントスキャナーの設定に関する詳細は「デプロイメントスキャナーの設定」を参照してください。

以下の管理 CLI コマンドは、EAP_HOME/standalone/new_deployment_dir を 5 秒ごとにチェックしてデプロイメントを確認する新しいデプロイメントスキャナーを追加します。

/subsystem=deployment-scanner/scanner=new-scanner:add(path=new_deployment_dir,relative-to=jboss.server.base.dir,scan-interval=5000)
注記

指定のディレクトリーがすでに存在しないと、このコマンドに失敗し、エラーが発生します。

新しいデプロイメントスキャナーが定義され、デプロイメントを確認するために指定のディレクトリーが監視されます。

7.4. Maven を使用したアプリケーションのデプロイ

Apache Maven を使用してアプリケーションをデプロイすると、JBoss EAP へのデプロイメントを簡単に既存の開発ワークフローに取り入れることができます。

アプリケーションをアプリケーションサーバーにデプロイおよびアンデプロイする簡単な操作を提供する WildFly Maven Plugin を使用すると、Maven を使用してアプリケーションを JBoss EAP にデプロイできます。

7.4.1. Maven を使用したアプリケーションのスタンドアロンサーバーへのデプロイ

以下の手順では、Maven を使用して JBoss EAP の helloworld クイックスタートをスタンドアロンサーバーにデプロイおよびアンデプロイする方法を示します。

JBoss EAP クイックスタートの詳細は、JBoss EAP『スタートガイド』の「クイックスタートサンプルの使用」を参照してください。

アプリケーションのデプロイ

Maven pom.xml ファイルで WildFly Maven Plugin を初期化します。これは、JBoss EAP クイックスタートの pom.xml ファイルで設定されているはずです。

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>${version.wildfly.maven.plugin}</version>
</plugin>

helloworld クイックスタートディレクトリーで以下の Maven コマンドを実行します。

$ mvn clean install wildfly:deploy

デプロイする Maven コマンドの実行後、ターミナルウインドウにはデプロイメントの成功を表す以下の出力が表示されます。

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.981 s
[INFO] Finished at: 2015-12-23T15:06:13-05:00
[INFO] Final Memory: 21M/231M
[INFO] ------------------------------------------------------------------------

アクティブなサーバーインスタンスのサーバーログでデプロイメントの成功を確認することもできます。

WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war")
WFLYUT0021: Registered web context: /helloworld
WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")
アプリケーションのアンデプロイ

helloworld クイックスタートディレクトリーで以下の Maven コマンドを実行します。

$ mvn wildfly:undeploy

アンデプロイする Maven コマンドの実行後、ターミナルウインドウにはアンデプロイメントの成功を表す以下の出力が表示されます。

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.237 s
[INFO] Finished at: 2015-12-23T15:09:10-05:00
[INFO] Final Memory: 10M/183M
[INFO] ------------------------------------------------------------------------

アクティブなサーバーインスタンスのサーバーログでアンデプロイメントの成功を確認することもできます。

WFLYUT0022: Unregistered web context: /helloworld
WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 27ms
WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")

7.4.2. Maven を使用した管理対象ドメインでのアプリケーションのデプロイ

以下の手順では、Maven を使用して管理対象ドメインで JBoss EAP の helloworld クイックスタートをデプロイおよびアンデプロイする方法を示します。

JBoss EAP クイックスタートの詳細は、JBoss EAP『スタートガイド』の「クイックスタートサンプルの使用」を参照してください。

アプリケーションのデプロイ

管理対象ドメインでアプリケーションをデプロイする場合、アプリケーションをデプロイするサーバーグループを指定する必要があります。これは、Maven の pom.xml ファイルで設定されます。

pom.xml の以下の設定は WildFly Maven Plugin を初期化し、main-server-group をアプリケーションがデプロイされるサーバーグループとして指定します。

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>wildfly-maven-plugin</artifactId>
  <version>${version.wildfly.maven.plugin}</version>
  <configuration>
    <domain>
      <server-groups>
        <server-group>main-server-group</server-group>
      </server-groups>
    </domain>
  </configuration>
</plugin>

helloworld クイックスタートディレクトリーで以下の Maven コマンドを実行します。

$ mvn clean install wildfly:deploy

デプロイする Maven コマンドの実行後、ターミナルウインドウにはデプロイメントの成功を表す以下の出力が表示されます。

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.005 s
[INFO] Finished at: 2016-09-02T14:36:17-04:00
[INFO] Final Memory: 21M/226M
[INFO] ------------------------------------------------------------------------

アクティブなサーバーインスタンスのサーバーログでデプロイメントの成功を確認することもできます。

WFLYSRV0027: Starting deployment of "helloworld.war" (runtime-name: "helloworld.war")
WFLYUT0021: Registered web context: /helloworld
WFLYSRV0010: Deployed "helloworld.war" (runtime-name : "helloworld.war")
アプリケーションのアンデプロイ

helloworld クイックスタートディレクトリーで以下の Maven コマンドを実行します。

$ mvn wildfly:undeploy

アンデプロイする Maven コマンドの実行後、ターミナルウインドウにはアンデプロイメントの成功を表す以下の出力が表示されます。

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.750 s
[INFO] Finished at: 2016-09-02T14:45:10-04:00
[INFO] Final Memory: 10M/184M
[INFO] ------------------------------------------------------------------------

アクティブなサーバーインスタンスのサーバーログでアンデプロイメントの成功を確認することもできます。

WFLYUT0022: Unregistered web context: /helloworld
WFLYSRV0028: Stopped deployment helloworld.war (runtime-name: helloworld.war) in 106ms
WFLYSRV0009: Undeployed "helloworld.war" (runtime-name: "helloworld.war")

7.5. HTTP API を使用したアプリケーションのデプロイ

HTTP API を使用してアプリケーションを JBoss EAP にデプロイするには、curl コマンドを使用します。HTTP API の使用に関する詳細は、「HTTP API」を参照してください。

7.5.1. HTTP API を使用したアプリケーションのスタンドアロンサーバーへのデプロイ

デフォルトでは、HTTP API は http://HOST:PORT/management でアクセスできます (例: http://localhost:9990/management)。

アプリケーションのデプロイ
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}]},{"operation" : "deploy", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'
アプリケーションのアンデプロイ
$ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "test-application.war"}},{"operation" : "remove", "address" : {"deployment" : "test-application.war"}}],"json.pretty":1}'

JSON リクエストをプログラムで生成する方法の詳細は、この Red Hat ナレッジベースの記事を参照してください。

7.5.2. HTTP API を使用した管理対象ドメインでのアプリケーションのデプロイ

デフォルトでは、HTTP API は http://HOST:PORT/management でアクセスできます (例: http://localhost:9990/management)。

アプリケーションのデプロイ
  1. デプロイメントをコンテンツリポジトリーに追加します。

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "add", "address" : {"deployment" : "test-application.war"}, "content" : [{"url" : "file:/path/to/test-application.war"}],"json.pretty":1}'
  2. デプロイメントを指定のサーバーグループに追加します。

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "add", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
  3. サーバーグループにアプリケーションをデプロイします。

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "deploy", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
アプリケーションのアンデプロイ
  1. 割り当てられたサーバーグループすべてからデプロイメントを削除します。

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "remove", "address" : {"server-group" : "main-server-group","deployment":"test-application.war"},"json.pretty":1}'
  2. コンテンツリポジトリーからデプロイメントを削除します。

    $ curl --digest -L -D - http://HOST:PORT/management --header "Content-Type: application/json" -u USER:PASSWORD -d '{"operation" : "remove", "address" : {"deployment" : "test-application.war"}, "json.pretty":1}'

7.6. デプロイメントの動作のカスタマイズ

7.6.1. デプロイメントコンテンツのカスタムディレクトリーの定義

JBoss EAP では、デプロイされたコンテンツを格納する場所をカスタマイズし、定義できます。

スタンドアロンサーバーでのカスタムディレクトリーの定義

デフォルトでは、スタンドアロンサーバーのデプロイされたコンテンツは EAP_HOME/standalone/data/content ディレクトリーに格納されます。この場所を変更するには、サーバーの起動時に -Djboss.server.deploy.dir 引数を渡します。

$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content

選択する場所は JBoss EAP インスタンスすべてで一意になる必要があります。

注記

jboss.server.deploy.dir プロパティーは、管理コンソールまたは管理 CLI を使用してデプロイされたコンテンツの格納に使用されるディレクトリーを指定します。デプロイメントスキャナーによって監視されるカスタムデプロイメントディレクトリーを定義する場合は、「デプロイメントスキャナーの設定」を参照してください。

管理対象ドメインでのカスタムディレクトリーの定義

デフォルトでは、管理対象ドメインのデプロイされたコンテンツは EAP_HOME/standalone/data/content ディレクトリーに格納されます。この場所を変更するには、ドメインの起動時に -Djboss.domain.deployment.dir 引数を渡します。

$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content

選択する場所は JBoss EAP インスタンスすべてで一意になる必要があります。

7.6.2. デプロイメント順序の制御

JBoss EAP では、サーバー起動時にアプリケーションがデプロイされる順序を細かく制御できます。複数の EAR ファイルに存在するアプリケーションのデプロイメント順序を徹底することができ、再起動後の順序を永続化することもできます。

jboss-all.xml デプロイメント記述子を使用してトップレベルのデプロイメント間で依存関係を宣言できます。

たとえば、最初にデプロイされた framework.ear に依存する app.ear がある場合、以下のように app.ear/META-INF/jboss-all.xml ファイルを作成できます。

<jboss xmlns="urn:jboss:1.0">
  <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
    <dependency name="framework.ear" />
  </jboss-deployment-dependencies>
</jboss>
注記

デプロイメントのランタイム名を jboss-all.xml ファイルの依存名として使用することができます。

これにより、app.ear の前に framework.ear がデプロイされます。

重要

jboss-all.xml ファイルや他のデプロイメント記述子では、宣言しないとサーバーが検出しない依存関係を宣言できますが、これは厳格な順序付け機能ではありません。JBoss EAP は、デプロイメント記述子で指定されたすべての依存関係はデプロイ済みで利用可能であると仮定します。不足している依存関係がある場合、JBoss EAP はそれらの依存関係を自動的にデプロイせず、デプロイメントは失敗します。

7.6.3. デプロイメントコンテンツのオーバーライド

デプロイメントオーバーレイ を使用すると、デプロイメントアーカイブのコンテンツを物理的に変更せずに既存デプロイメントにコンテンツをオーバーレイすることができます。これにより、アーカイブを再構築せずに実行時にデプロイメント記述子、ライブラリー JAR ファイル、クラス、JSP ページ、およびその他のファイルをオーバーライドできます。

これは、異なる設定が必要な異なる環境にデプロイメントを適応する必要がある場合に便利です。たとえば、アプリケーションのライフサイクルに従って開発からテスト、ステージ、および実稼働とデプロイメントを移動する場合、目的の環境に応じてデプロイメント記述子の交換、アプリケーションのブランディングを変更するための静的 Web リソースの変更、JAR ライブラリーの別バージョンへの置き換えなどを行う可能性があります。また、方針やセキュリティーの制限によりアーカイブを変更できない、設定変更が必要なインストールにも便利な機能です。

デプロイメントオーバーレイを定義する場合、デプロイメントアーカイブのファイルを置き換える、ファイルシステム上のファイルを定義します。さらに、デプロイメントオーバーレイの影響を受けるデプロイメントを指定する必要もあります。変更を有効にするには、影響を受けるデプロイメントを再デプロイする必要があります。

deployment-overlay add 管理 CLI コマンドを使用してデプロイメントオーバーレイを追加します。

deployment-overlay add --name=new-deployment-overlay --content=WEB-INF/web.xml=/path/to/other/web.xml --deployments=test-application.war --redeploy-affected
注記

管理対象ドメインでは、--server-groups を使用して該当するサーバーグループを指定するか、--all-server-groups を使用してすべてのサーバーグループを指定します。

作成後、既存のオーバーレイへのコンテンツの追加、オーバーレイのデプロイメントへのリンク、またはオーバーレイの削除を行うことができます。使用方法の詳細を表示するには deployment-overlay --help を実行してください。

パラメーター

name
デプロイメントオーバーレイの名前。
content
ファイルシステム上のファイルをアーカイブの置き換えるファイルにマップするカンマ区切りリスト。各エントリーの形式は ARCHIVE_PATH=FILESYSTEM_PATH です。
deployments
このオーバーレイがリンクされるデプロイメントのカンマ区切りリスト。
redeploy-affected
影響を受けるデプロイメントをすべて再デプロイします。

7.6.4. ロールアウト計画の使用

ロールアウト計画

管理対象ドメインでは、ドメインまたはホストレベルのリソースで目的となる操作は複数のサーバーに影響する可能性があります。このような操作には、サーバーに適用される操作の順序を説明するロールアウト計画や、一部のサーバーで実行に失敗した場合に操作を元に戻すかどうかを指示するポリシーなどが含まれます。指定されたロールアウト計画がない場合、デフォルトのロールアウト計画 が使用されます。

以下は 5 つのサーバーグループが関係するロールアウト計画の例になります。操作は順次 (in-series) または同時 (concurrent-groups) にサーバーグループへ適用することができます。構文の詳細は「ロールアウト計画の構文」を参照してください。

{"my-rollout-plan" => {"rollout-plan" => {
    "in-series" => [
        {"concurrent-groups" => {
            "group-A" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            },
            "group-B" => undefined
        }},
        {"server-group" => {"group-C" => {
            "rolling-to-servers" => "false",
            "max-failed-servers" => "1"
        }}},
        {"concurrent-groups" => {
            "group-D" => {
                "max-failure-percentage" => "20",
                "rolling-to-servers" => "true"
            },
            "group-E" => undefined
        }}
    ],
    "rollback-across-groups" => "true"
}}}

上記の例を見ると、3 つの段階を経てドメインのサーバーに操作が適用されることが分かります。あるサーバーグループのポリシーによってサーバーグループ全体で操作のロールバックが引き起こされると、他のサーバーグループもすべてロールバックされます。

  1. サーバーグループ group-Agroup-B には同時に操作が適用されます。group-A のサーバーには操作が順次適用され、group-B のすべてのサーバーは操作を同時に処理します。group-A で操作の適用に失敗したサーバーが 20 % を超えると、グループ全体でロールバックが実行されます。group-B で操作を適用できなかったサーバーがあると、このグループ全体でロールバックが実行されます。
  2. group-Agroup-B のすべてのサーバーが完了すると、group-C のサーバーに操作が適用されます。これらのサーバーは操作を同時に処理します。group-C では操作を適用できなかったサーバーが 2 台以上あると、グループ全体でロールバックが実行されます。
  3. group-C のすべてのサーバーが完了すると、操作が group-Dgroup-E に同時に適用されます。group-D のサーバーには操作が順次適用され、group-E のすべてのサーバーは操作を同時に処理します。group-D で操作の適用に失敗したサーバーが 20 % を超えると、グループ全体でロールバックが実行されます。group-E で操作を適用できなかったサーバーがあると、このグループ全体でロールバックが実行されます。
ロールアウト計画の構文

ロールアウト計画は以下のいずれかの方法で指定できます。

上記の方法で最初に使用するコマンドは異なりますが、どちらも rollout 操作ヘッダーを使用してロールアウト計画を定義します。以下の構文を使用します。

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]
  • PLAN_NAME は、rollout-plan コマンドを使用して保存されたロールアウト計画の名前です。
  • SERVER_GROUP_LIST はサーバーグループのリストです。各サーバーグループで操作を順次実行する場合はコンマ (,) を使用して複数のサーバーグループを区切ります。各サーバーグループで同時に操作を実行する場合はキャレット (^) を区切り文字として使用します。

    • 各サーバーグループでは、以下のポリシーをかっこで囲んで設定します。複数のポリシーはコンマで区切ります。

      • rolling-to-servers: ブール値。true に設定すると、操作はグループの各サーバーに順次適用されます。false に設定した場合、または指定がない場合は、操作はグループのサーバーに同時に適用されます。
      • max-failed-servers: 整数値。グループにおける操作の適用に失敗したサーバー合計数の最大率 (パーセント) で、失敗したサーバーの率がこの値を超えるとグループのすべてのサーバーが元に戻されます。指定がない場合のデフォルト値は 0 で、操作の適用に失敗したサーバーが 1 台でもあるとグループ全体でロールバックが引き起こされます。
      • max-failed-servers: 0 から 100 までの整数値。グループにおける操作の適用に失敗したサーバー合計数の最大率 (パーセント) で、失敗したサーバーの率がこの値を超えるとグループのすべてのサーバーが元に戻されます。指定がない場合のデフォルト値は 0 で、操作の適用に失敗したサーバーが 1 台でもあるとグループ全体でロールバックが引き起こされます。

        注記

        max-failed-serversmax-failure-percentage の両方がゼロ以外の値に設定された場合、max-failure-percentage が優先されます。

  • rollback-across-groups: ブール値。1 つのサーバーグループのサーバーすべてで操作をロールバックする必要があると、すべてのサーバーグループでロールバックの実行を引き起こすかどうかを指定します。デフォルトは false です。
ロールアウト計画を使用したデプロイ

ロールアウト計画の完全詳細を直接 deploy コマンドに提供するには、rollout 設定を headers 引数に渡します。形式の詳細は「ロールアウト計画の構文」を参照してください。

以下の管理 CLI コマンドは、順次のデプロイメントに rolling-to-servers=true を指定するデプロイメント計画を使用して、アプリケーションを main-server-group サーバーグループにデプロイします。

deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}
保存したロールアウト計画を使用したデプロイ

ロールアウト計画は複雑になることがあるため、ロールアウト計画の詳細を保存するオプションがあります。これにより、毎回ロールアウト計画の完全詳細を必要とせずに、ロールアウト計画を使用するときにロールアウト計画の名前を参照することができます。

  1. rollout-plan 管理 CLI コマンドを使用してロールアウト計画を保存します。形式の詳細は「ロールアウト計画の構文」を参照してください。

    rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}

    これにより、以下のデプロイメント計画が作成されます。

    "rollout-plan" => {
        "in-series" => [
            {"server-group" => {"main-server-group" => {
                "rolling-to-servers" => false,
                "max-failed-servers" => 1
            }}},
            {"server-group" => {"other-server-group" => {
                "rolling-to-servers" => true,
                "max-failure-percentage" => 20
            }}}
        ],
        "rollback-across-groups" => true
    }
  2. アプリケーションのデプロイ時に保存されたロールアウト計画名を指定します。

    以下の管理 CLI コマンドは、保存されたロールアウト計画 my-rollout-plan を使用してすべてのサーバーグループにアプリケーションをデプロイします。

    deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
保存されたロールアウト計画の削除

削除するロールアウト計画の名前を指定して rollout-plan 管理 CLI コマンドを使用すると、保存されたロールアウト計画を削除できます。

rollout-plan remove --name=my-rollout-plan
デフォルトのロールアウト計画

複数のサーバーに影響する操作はすべてロールアウト計画を使用して実行されます。操作リクエストにロールアウト計画が指定されていない場合は、デフォルトのロールアウト計画が生成されます。計画には以下の特徴があります。

  • ハイレベルなフェーズは 1 つのみです。操作に影響するすべてのサーバーグループには同時に操作が適用されます。
  • 各サーバーグループ内では、操作がすべてのサーバーに同時に適用されます。
  • サーバーグループのいずれかのサーバーに操作を適用できないと、グループ全体でロールバックが実行されます。
  • あるサーバーグループに操作を適用できないと、他のすべてのサーバーグループでロールバックが実行されます。

7.7. 展開形式のデプロイメントの管理

JBoss EAP 7.1 以前では、ファイルシステム上のファイルを操作するのが展開形式のデプロイメントを管理する唯一の方法でした。JBoss EAP 7.1 より、管理インターフェースを使用して展開形式のデプロイメントを管理できるようになりました。これにより、新しいバージョンのアプリケーションをデプロイしなくても、展開形式のアプリケーションのコンテンツを変更できるようになりました。

注記

JavaScript や CSS ファイルなど、デプロイメントの静的ファイルが更新されると、即座に更新が反映されます。Java クラスなどの他のファイルが変更された場合は、変更の反映にアプリケーションの再デプロイが必要になることがあります。

最初に、空のデプロイメント を使用するか、既存のアーカイブデプロイメントを展開した後、コンテンツを追加または削除します。

デプロイメントのコンテンツの表示」を参照してデプロイメントのファイルを閲覧するか、ファイルのコンテンツを読み取ります。

空の展開形式のデプロイメントを作成

必要時にコンテンツを追加できる空の展開形式のデプロイメントを作成できます。以下の管理 CLI コマンドを使用して空の展開形式のデプロイメントを作成します。

/deployment=DEPLOYMENT_NAME.war:add(content=[{empty=true}])

empty=true オプションは、空のデプロイメントの作成を確認するために必要です。

既存のアーカイブデプロイメントの展開

既存のアーカイブデプロイメントを展開してコンテンツを更新できます。展開する前にデプロイメントを無効化する必要があります。以下の管理 CLI コマンドを使用してデプロイメントを展開します。

/deployment=ARCHIVE_DEPLOYMENT_NAME.ear:explode

これで、このデプロイメントのコンテンツを追加または削除できるようになります。

注記

管理コンソールから既存のアーカイブデプロイメントを展開することもできます。Deployments タブからデプロイメントを選択し、ドロップダウンメニューで Explode を選択します。

展開形式のデプロイメントへのコンテンツの追加

デプロイメントにコンテンツを追加するには、add-content 管理 CLI 操作を使用します。コンテンツを追加するデプロイメントの場所へのパスを指定し、アップロードするコンテンツを提供します。アップロードするコンテンツは、ローカルファイルストリーム、URL、JBoss EAP コンテンツリポジトリーにすでに存在するコンテンツのハッシュ、またはコンテンツのバイトアレイとして提供できます。以下の管理 CLI コマンドは、input-stream-index オプションを使用してローカルファイルのコンテンツをデプロイメントにアップロードします。

/deployment=DEPLOYMENT_NAME.war:add-content(content=[{target-path=/path/to/FILE_IN_DEPLOYMENT, input-stream-index=/path/to/LOCAL_FILE_TO_UPLOAD}]
注記

add-content 操作を使用してコンテンツをデプロイメントに追加するとき、デプロイメントのコンテンツはデフォルトで上書きされます。この挙動を変更するには、overwrite オプションを false に設定します。

展開形式のデプロイメントのコンテンツの削除

デプロイメントからコンテンツを削除するには、remove-content 管理 CLI 操作を使用し、デプロイメントの削除するコンテンツへのパスを指定します。

/deployment=DEPLOYMENT_NAME.war:remove-content(paths=[/path/to/FILE_1, /path/to/FILE_2])

7.8. デプロイメントのコンテンツの表示

JBoss EAP の管理インターフェースを使用すると、管理されたデプロイメントのファイルに関する情報を閲覧 し、ファイルの内容を読み取る ことができます。

7.8.1. デプロイメントのファイルの閲覧

管理されたデプロイメントのファイルやディレクトリーを閲覧するには、browse-content 操作を使用します。引数を指定しないと、デプロイメント構造全体が返されます。 特定のディレクトリーへのパスを指定するには、path 引数を使用します。

注記

また、管理コンソールからデプロイメントの内容を閲覧することもできます。 Deployments タブに移動してデプロイメントを選択し、ドロップダウンメニューで 表示 を選択します。

/deployment=helloworld.war:browse-content(path=META-INF/)

上記は、helloworld.war デプロイメントの META-INF/ ディレクトリーにあるファイルとディレクトリーを表示します。

{
    "outcome" => "success",
    "result" => [
        {
            "path" => "MANIFEST.MF",
            "directory" => false,
            "file-size" => 827L
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.properties",
            "directory" => false,
            "file-size" => 106L
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/helloworld/pom.xml",
            "directory" => false,
            "file-size" => 2713L
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/helloworld/",
            "directory" => true
        },
        {
            "path" => "maven/org.jboss.eap.quickstarts/",
            "directory" => true
        },
        {
            "path" => "maven/",
            "directory" => true
        },
        {
            "path" => "INDEX.LIST",
            "directory" => false,
            "file-size" => 251L
        }
    ]
}

以下の引数を browse-content 操作に指定することもできます。

archive
アーカイブファイルのみを返すかどうか。
depth
返すファイルの深さを指定します。

7.8.2. デプロイメントコンテンツの読み取り

管理されたデプロイメントでファイルの内容を読み取るには、read-content 操作を使用します。引数を指定しないと、デプロイメント全体が返されます。または、path 引数を指定して、特定のファイルへのパスを提供します。例を以下に示します。

/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

上記は、管理 CLI に表示 または ファイルシステムに保存 できるファイルストリームを返します。

{
    "outcome" => "success",
    "result" => {"uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95"},
    "response-headers" => {"attached-streams" => [{
        "uuid" => "24ba8e06-21bd-4505-b4d4-bdfb16451b95",
        "mime-type" => "text/plain"
    }]}
}

7.8.2.1. ファイルの内容の表示

attachment display コマンドを使用して MANIFEST.MF ファイルの内容を読み取ります。

attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

上記は、helloworld.war デプロイメントからの MANIFEST.MF ファイルの内容を管理 CLI に表示します。

ATTACHMENT 8af87836-2abd-423a-8e44-e731cc57bd80:
Manifest-Version: 1.0
Implementation-Title: Quickstart: helloworld
Implementation-Version: 7.3.0.GA
Java-Version: 1.8.0_131
Built-By: username
Scm-Connection: scm:git:git@github.com:jboss/jboss-parent-pom.git/quic
 kstart-parent/helloworld
Specification-Vendor: JBoss by Red Hat
...

7.8.2.2. ファイルの内容の保存

attachment save コマンドを使用して、MANIFEST.MF ファイルの内容をファイルシステムに保存します。

attachment save --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF) --file=/path/to/MANIFEST.MF

上記は、helloworld.war デプロイメントからの MANIFEST.MF ファイルを path/to/MANIFEST.MF のファイルシステムに保存します。--file 引数を使用してファイルパスを指定しないと、一意な添付 ID を使用してファイル名が付けられ、管理 CLI の作業ディレクトリー (デフォルトは EAP_HOME/bin/) に保存されます。

第8章 ドメイン管理

本項では、管理対象ドメインの操作モードに固有する概念や設定について説明します。

管理対象ドメインのセキュア化については、JBoss EAP『How to Configure Server Security』の「Securing a Managed Domain」の項を参照してください。

8.1. 管理対象ドメイン

管理対象ドメインの操作モードを使用すると、単一の制御ポイントから複数の JBoss EAP インスタンスを管理できます。

一元管理された複数の JBoss EAP サーバーは、ドメインのメンバーと呼ばれます。ドメインの JBoss EAP インスタンスは共通の管理ポリシーを共有します。

各ドメインは 1 つのドメインコントローラー、1 つ以上のホストコントローラー、およびホスト毎に 0 個以上のサーバーグループによって構成されます。

A managed domain.

ドメインコントローラーは、ドメインが制御される中心点であり、各サーバーはドメインの管理ポリシーに従って設定されます。ドメインの管理ポリシーに従って各サーバーが設定されるようにします。ドメインコントローラーはホストコントローラーでもあります。

ホストコントローラーはドメインコントローラーと対話して、ホスト上で実行されているアプリケーションサーバーインスタンスのライフサイクルを制御し、ドメインコントローラーがこれらのインスタンスを管理できるようにします。各ホストに複数のサーバーグループが含まれるようにすることが可能です。

サーバーグループは、JBoss EAP がインストールされているサーバーインスタンスの集まりで、すべてが 1 つとして管理および設定されます。ドメインコントローラーはサーバーグループにデプロイされたアプリケーションとその設定を管理します。そのため、サーバーグループの各サーバーは同じ設定とデプロイメントを共有します。

ホストコントローラーは特定の物理または仮想ホストに割り当てられます。異なる設定を使用する場合は、同じハードウェア上で複数のホストコントローラーを実行でき、ポートとその他のリソースが競合しないようにします。1 つのドメインコントローラー、1 つのホストコントローラー、および複数のサーバーを、同じ物理システムの同じ JBoss EAP インスタンス内で実行することができます。

8.1.1. ドメインコントローラー

ドメインコントローラーは、ドメインの集中管理点として動作する JBoss EAP サーバーインスタンスです。1 つのホストコントローラーインスタンスがドメインコントローラーとして動作するよう設定されます。

ドメインコントローラーの主な役割は次のとおりです。

  • ドメインの集中管理ポリシーを維持する。
  • すべてのホストコントローラーが現在のコンテンツを認識するようにする。
  • 実行中のすべての JBoss EAP サーバーインスタンスがこのポリシーに従って設定されるよう、ホストコントローラーをサポートする。

デフォルトでは、集中管理ポリシーは EAP_HOME/domain/configuration/domain.xml ファイルに格納されます。このファイルは、ドメインコントローラーとして実行するよう設定されたホストコントローラーのこのディレクトリーに必要です。

domain.xml ファイルには、ドメインのサーバーに適用できるプロファイル設定が含まれています。プロファイルには、そのプロファイルで使用できるさまざまなサブシステムの詳細設定が含まれています。ドメイン設定には、ソケットグループの定義とサーバーグループの定義も含まれます。

注記

JBoss EAP 7 ドメインコントローラーは、JBoss EAP 6.2 以上を実行している JBoss EAP 6 ホストおよびサーバーを管理できます。詳細は、「JBoss EAP 6 インスタンスを管理するよう JBoss EAP 7.x ドメインコントローラーを設定」を参照してください

詳細は「管理対象ドメインの起動」および「ドメインコントローラーの設定」の項を参照してください。

8.1.2. ホストコントローラー

ホストコントローラーの主な役割はサーバーを管理することです。ドメイン管理タスクを委譲し、ホスト上で実行される個別のアプリケーションサーバープロセスを開始および停止します。

ホストコントローラーはドメインコントローラーと対話し、サーバーとドメインコントローラー間の通信を管理できるようにします。ドメインの複数のホストコントローラーは 1 つのドメインコントローラーのみと対話できます。そのため、単一のドメインモード上で実行されるホストコントローラーおよびサーバーインスタンスはすべて単一のドメインコントローラーを持ち、同じドメインに属する必要があります。

デフォルトでは、各ホストコントローラーは、ホストのファイルシステムの未展開の JBoss EAP インストールファイルにある EAP_HOME/domain/configuration/host.xml ファイルから設定を読み取ります。host.xml ファイルには、特定のホストに固有する以下の設定情報が含まれています。

  • このインストールから実行されるサーバーインスタンスの名前。
  • ローカルの物理インストールに固有する設定。たとえば、domain.xml に宣言された名前付きインターフェースの定義は host.xml にある実際のマシン固有の IP アドレスへマップできます。さらに、domain.xml の抽象パス名を host.xml のファイルシステムパスへマップできます。
  • 次の設定のいずれか。

    • ホストコントローラーがドメインコントローラーへ通知して、ホストコントローラー自体を登録し、ドメイン設定へアクセスする方法。
    • リモートドメインコントローラーの検索および通知方法。
    • ホストコントローラーがドメインコントローラーとして動作するかどうか。

詳細は「管理対象ドメインの起動」および「ホストコントローラーの設定」の項を参照してください。

8.1.3. プロセスコントローラー

プロセスコントローラーは小型のライトウェイトなプロセスで、ホストコントローラープロセスを起動し、そのライフサイクルを監視します。ホストコントローラーがクラッシュすると、プロセスコントローラーによって再起動されます。さらに、ホストコントローラーの指示に従ってサーバープロセスを開始しますが、クラッシュしたサーバープロセスは自動的に再起動しません。

プロセスコントローラーのログは EAP_HOME/domain/log/process-controller.log ファイルに記録されます。プロセスコントローラーの JVM オプションは、PROCESS_CONTROLLER_JAVA_OPTS 変数を使用して EAP_HOME/bin/domain.conf ファイルに設定します。

8.1.4. サーバーグループ

サーバーグループとは、1 つのグループとして管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、各アプリケーションサーバーインスタンスは唯一のメンバーである場合でも 1 つのサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイされたコンテンツを共有します。

ドメインコントローラーとホストコントローラーは、ドメインにある各サーバーグループのすべてのインスタンスに標準設定を強制します。

ドメインを複数のサーバーグループで構成できます。異なるサーバーグループを異なるプロファイルやデプロイメントで設定できます。たとえば、ドメインは異なるサービスを提供する異なるサーバー層で設定できます。

異なるサーバーグループが同じプロファイルやデプロイメントを持つこともできます。これにより、最初のサーバーグループでアプリケーションがアップグレードされた後に 2 つ目のサーバーグループでアプリケーションがアップデートされるアプリケーションのローリングアップグレードが可能になり、サービスの完全停止を防ぎます。

詳細は、「サーバーグループの設定」の項を参照してください。

8.1.5. サーバー

サーバーはアプリケーションサーバーインスタンスを表します。管理対象ドメインでは、すべてのサーバーインスタンスがサーバーグループのメンバーになります。ホストコントローラーは各サーバーインスタンスを独自の JVM プロセスで起動します。

詳細は「サーバーの設定」の項を参照してください。

8.3. 管理対象ドメインの起動

8.3.1. 管理対象ドメインの起動

ドメインおよびホストコントローラーは、JBoss EAP に同梱される domain.sh または domain.bat スクリプトを使用して起動できます。使用できる起動スクリプトの引数の完全リストとそれら引数の目的については、--help 引数を使用するか、「サーバーランタイム引数」を参照してください。

ドメイン内のサーバーグループのスレーブサーバーを起動する前にドメインコントローラーを起動する必要があります。最初にドメインコントローラーを起動した後、ドメイン内の関連する他のホストコントローラーを起動します。

ドメインコントローラーの起動

専用のドメインコントローラー向けに事前設定された host-master.xml 設定ファイルを使用してドメインコントローラーを起動します。

$ EAP_HOME/bin/domain.sh --host-config=host-master.xml

ドメインの設定に応じて、ホストコントローラーの接続を可能にするために設定を追加する必要があります。また、以下のドメイン設定例を参照してください。

ホストコントローラーの起動

スレーブホストコントローラー向けに事前設定された host-slave.xml 設定ファイルを使用してホストコントローラーを起動します。

$ EAP_HOME/bin/domain.sh  --host-config=host-slave.xml

ドメインの設定に応じて、ドメインコントローラーへ接続し、ドメインコントローラーとの競合を回避するために設定を追加する必要があります。また、以下のドメイン設定例を参照してください。

8.3.2. ドメインコントローラーの設定

ドメイン内のホストをドメインコントローラーとして設定する必要があります。

重要

RPM インストールで JBoss EAP をインストールした場合、複数のドメインまたはホストコントローラーを同じマシン上に設定することはサポートされません。

<domain-controller> 宣言に <local/> 要素を追加 て、ホストをドメインコントローラー として設定します。<domain-controller> には他のコンテンツを含めないでください。

<domain-controller>
  <local/>
</domain-controller>

ドメインコントローラーとして動作するホストは、ドメインの他のホストがアクセスできる管理インターフェースを公開する必要があります。HTTP インターフェースは標準の管理インターフェースです。

<management-interfaces>
  <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true">
    <socket interface="management" port="${jboss.management.http.port:9990}"/>
  </http-interface>
</management-interfaces>

最小のドメインコントローラー設定ファイルの例 (EAP_HOME/domain/configuration/host-master.xml) には、以下の設定が含まれます。

8.3.3. ホストコントローラーの設定

ホストコントローラー自体をドメインに登録するようにホストコントローラーを設定する必要があります。

重要

RPM インストールで JBoss EAP をインストールした場合、複数のドメインまたはホストコントローラーを同じマシン上に設定することはサポートされません。

設定の <domain-controller> 要素を使用して、ドメインコントローラーへの接続を設定します。

<domain-controller>
  <remote security-realm="ManagementRealm">
    <discovery-options>
      <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
    </discovery-options>
  </remote>
</domain-controller>

最小のホストコントローラー設定ファイルのサンプル EAP_HOME/domain/configuration/host-slave.xml には、ドメインコントローラーに接続する設定が含まれています。この設定は、ホストコントローラーの起動時に jboss.domain.master.address プロパティーを指定するものと想定しています。

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=IP_ADDRESS

ドメインコントローラーの検出に関する詳細は、「ドメインコントローラーの検出およびフェイルオーバー」の項を参照してください。

ドメインの設定によっては、認証を提供して、ホストコントローラーがドメインコントローラーによって認証されるようにする必要がある場合があります。管理ユーザーと秘密の値の生成や、その値を用いたホストコントローラー設定の更新に関する詳細は、「2 台のマシンで管理対象ドメインを設定」を参照してください。

8.3.4. ホスト名の設定

管理対象ドメインで実行されている各ホストには一意な名前を付ける必要があります。管理を容易にし、複数のホストで同じホスト設定ファイルを使用できるようにするために、以下の優先順位を用いてホスト名が決定されます。

  1. 設定されている場合、host.xml 設定ファイルのホスト要素名属性。
  2. jboss.host.name システムプロパティーの値。
  3. jboss.qualified.host.name システムプロパティーの最後のピリオド (.) の後に続く値。 最後のピリオド (.) がない場合は全体の値。
  4. POSIX ベースのオペレーティングシステムでは、HOSTNAME 環境変数のピリオド (.) の後に続く値。 Microsoft Windows では COMPUTERNAME 環境変数のピリオド (.) の後に続く値。 最後のピリオドがない場合は、全体の値。

関連する host.xml 設定ファイルの上部にある host 要素に設定されたホストコントローラーの名前。 例は次のとおり。

<host xmlns="urn:jboss:domain:8.0" name="host1">

以下の手順に従って、管理 CLI を使用してホスト名を更新します。

  1. JBoss EAP ホストコントローラーを起動します。

    $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml
  2. 管理 CLI を起動し、ドメインコントローラーに接続します。

    $ EAP_HOME/bin/jboss-cli.sh --connect --controller=DOMAIN_CONTROLLER_IP_ADDRESS
  3. 以下のコマンドを実行して新しいホスト名を設定します。

    /host=EXISTING_HOST_NAME:write-attribute(name=name,value=NEW_HOST_NAME)

    これにより、host-slave.xml ファイルのホスト名属性が以下のように変更されます。

    <host name="NEW_HOST_NAME" xmlns="urn:jboss:domain:8.0">
  4. 変更を反映するためにホストコントローラーをリロードします。

    reload --host=EXISTING_HOST_NAME

ホストコントローラーの名前が設定ファイルに設定されていない場合は、起動時にホスト名を渡すこともできます。

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.host.name=HOST_NAME

8.4. サーバーの管理

8.4.1. サーバーグループの設定

以下はサーバーグループ定義の例になります。

<server-group name="main-server-group" profile="full">
  <jvm name="default">
    <heap size="64m" max-size="512m"/>
  </jvm>
  <socket-binding-group ref="full-sockets"/>
  <deployments>
    <deployment name="test-application.war" runtime-name="test-application.war"/>
    <deployment name="helloworld.war" runtime-name="helloworld.war" enabled="false"/>
  </deployments>
</server-group>

サーバーグループの設定は、管理 CLI を使用するか、管理コンソールの Runtime タブから行います。

サーバーグループの追加

以下の管理 CLI コマンドを実行すると、サーバーグループを追加できます。

/server-group=SERVER_GROUP_NAME:add(profile=PROFILE_NAME,socket-binding-group=SOCKET_BINDING_GROUP_NAME)
サーバーグループの更新

以下の管理 CLI コマンドを実行すると、サーバーグループ属性を更新できます。

/server-group=SERVER_GROUP_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)
サーバーグループの削除

以下の管理 CLI コマンドを実行すると、サーバーグループを削除できます。

/server-group=SERVER_GROUP_NAME:remove
サーバーグループ属性

サーバーグループには次の属性が必要です。

  • name: サーバーグループの名前。
  • profile: サーバーグループプロファイル名。
  • socket-binding-group: グループのサーバーに使用されるデフォルトのソケットバインディンググループ。サーバーごとに上書きできます。

サーバーグループに含まれる任意の属性は次のとおりです。

  • management-subsystem-endpoint: remoting サブシステムからエンドポイントを使用してサーバーグループに属するサーバーを再びホストコントローラーに接続するには true に設定します。これは、remoting サブシステムが存在しないと機能しません。
  • socket-binding-default-interface: このサーバーのソケットバインディンググループのデフォルトインターフェース。
  • socket-binding-port-offset: ソケットバインディンググループによって提供されたポート値に追加するデフォルトのオフセット。
  • deployments: グループのサーバーにデプロイするデプロイメントコンテンツ。
  • jvm: グループの全サーバーに対するデフォルトの JVM 設定。ホストコントローラーはこれらの設定を host.xml の他の設定とマージし、サーバーの JVM を開始するために使用される設定を作成します。
  • deployment-overlays: 定義されたデプロイメントオーバーレイと、このサーバーグループのデプロイメントとの間をリンクします。
  • system-properties: グループのサーバーに設定するシステムプロパティー。

8.4.2. サーバーの設定

デフォルトの host.xml 設定ファイルは 3 つのサーバーを定義します。

<servers>
  <server name="server-one" group="main-server-group">
  </server>
  <server name="server-two" group="main-server-group" auto-start="true">
    <socket-bindings port-offset="150"/>
  </server>
  <server name="server-three" group="other-server-group" auto-start="false">
    <socket-bindings port-offset="250"/>
  </server>
</servers>

server-one という名前のサーバーインスタンスは main-server-group に関連付けられ、そのサーバーグループによって指定されるサブシステム設定とソケットバインディングを継承します。server-two という名前のサーバーインスタンスも main-server-group に関連付けられていますが、server-one によって使用されるポートの値と競合しないようにソケットバインディングの port-offset の値も定義します。server-three という名前のサーバーインスタンスは other-server-group に関連付けられ、そのグループの設定を使用します。また、 port-offset の値も定義し、ホストコントローラーの起動時にこのサーバーが起動しないように auto-startfalse に設定します。

サーバーの設定は、管理 CLI を使用するか、管理コンソールの Runtime タブから行います。

サーバーの追加

以下の管理 CLI コマンドを実行すると、サーバーを追加できます。

/host=HOST_NAME/server-config=SERVER_NAME:add(group=SERVER_GROUP_NAME)
サーバーの更新

以下の管理 CLI コマンドを実行すると、サーバー属性を更新できます。

/host=HOST_NAME/server-config=SERVER_NAME:write-attribute(name=ATTRIBUTE_NAME,value=VALUE)
サーバーの削除

以下の管理 CLI コマンドを実行すると、サーバーを削除できます。

/host=HOST_NAME/server-config=SERVER_NAME:remove
サーバーの属性

サーバーには以下の属性が必要です。

  • name: サーバーの名前。
  • group: ドメインモデルからのサーバーグループの名前。

サーバーには以下の任意の属性が含まれます。

  • auto-start: ホストコントローラーの起動時にこのサーバーが起動されるかどうか。
  • socket-binding-group: このサーバーが属するソケットバインディンググループ。
  • socket-binding-port-offset: このサーバーのソケットバイディンググループによって提供されたポート値に追加されるオフセット。
  • update-auto-start-with-server-status: サーバーの状態で auto-start 属性を更新します。
  • interface: サーバーで使用できる完全に指定された名前付きのネットワークインターフェースのリスト。
  • jvm: このサーバーの JVM 設定。宣言されていない場合、設定は親のサーバーグループまたはホストから継承されます。
  • path: 名前付きのファイルシステムパスのリスト。
  • system-property: このサーバーに設定するシステムプロパティーのリスト。

8.4.3. サーバーの起動と停止

管理コンソールから起動、停止、リロードなどの操作をサーバーで実行するには、Runtime タブに移動して適切なホストまたはサーバーグループを選択します。

管理 CLI を使用してこれらの操作を実行する場合は以下のコマンドを参照してください。

サーバーの起動

特定のホストで 1 台のサーバーを起動できます。

/host=HOST_NAME/server-config=SERVER_NAME:start

指定のサーバーグループのサーバーをすべて起動できます。

/server-group=SERVER_GROUP_NAME:start-servers
サーバーの停止

特定のホストで 1 台のサーバーを停止できます。

/host=HOST_NAME/server-config=SERVER_NAME:stop

指定のサーバーグループのサーバーをすべて停止できます。

/server-group=SERVER_GROUP_NAME:stop-servers
サーバーのリロード

特定のホストで 1 台のサーバーをリロードできます。

/host=HOST_NAME/server-config=SERVER_NAME:reload

指定のサーバーグループのサーバーをすべてリロードできます。

/server-group=SERVER_GROUP_NAME:reload-servers
サーバーの Kill

指定のサーバーグループのすべてのサーバープロセスを kill することができます。

/server-group=SERVER_GROUP_NAME:kill-servers

8.5. ドメインコントローラーの検出およびフェイルオーバー

管理対象ドメインの設定時、ドメインコントローラーに接続するために必要な情報を使用して各ホストコントローラーを設定する必要があります。JBoss EAP では、ドメインコントローラーを検索する 複数のオプション を使用して各ホストコントローラーを設定できます。ホストコントローラーは、適切なオプションが見つかるまでオプションのリストを繰り返し処理します。

プライマリードメインコントローラーに問題がある場合は、バックアップホストコントローラーを ドメインコントローラーに昇格できます。これにより、昇格後にホストコントローラーを新しいドメインコントローラーへ自動的にフェイルオーバーできます。

8.5.1. ドメイン検出オプションの設定

以下は、ドメインコントローラー検索の複数のオプションを持つホストコントローラーを設定する方法の例になります。

例: 複数のドメインコントローラーオプションを持つホストコントローラー

<domain-controller>
  <remote security-realm="ManagementRealm">
    <discovery-options>
      <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="172.16.81.100" port="${jboss.domain.master.port:9990}"/>
      <static-discovery name="backup" protocol="${jboss.domain.master.protocol:remote}" host="172.16.81.101" port="${jboss.domain.master.port:9990}"/>
    </discovery-options>
  </remote>
</domain-controller>

静的検出オプションには、以下の必須属性が含まれます。

name
このドメインコントローラー検出オプションの名前。
host
リモートドメインコントローラーのホスト名。
port
リモートドメインコントローラーのポート。

上記の例では、最初の検出オプションが指定されることが予想されます。2 つ目のオプションはフフェイルオーバーの状況で使用される可能性があります。

8.5.2. キャッシュされたドメイン設定を用いたホストコントローラーの起動

--cached-dc オプションを使用すると、ドメインコントローラーへ接続していなくてもホストコントローラーを起動できますが、ホストコントローラーは前もってドメインコントローラーからドメイン設定をローカルでキャッシュする必要があります。--cached-dc オプションを使用してホストコントローラーを起動すると、ドメインコントローラーからホストコントローラーのドメイン設定がキャッシュされます。

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --cached-dc

これにより、このホストコントローラーがドメインコントローラーに接続せずに現在のサーバーを一時的に管理するために必要な情報が含まれる EAP_HOME/domain/configuration/ ディレクトリーに domain.cached-remote.xml ファイルが作成されます。

注記

デフォルトでは、--cached-dc オプションを使用すると、このホストコントローラーによって使用される設定のみがキャッシュされます。そのため、ドメイン全体のドメインコントローラーには昇格されません。 ドメイン設定全体をキャッシュしてホストコントローラーをドメインコントローラーとする場合は、「ドメイン設定のキャッシュ」を参照してください。

--cached-dc を使用してこのホストコントローラーを起動したときにドメインコントローラーを利用できない場合、ホストコントローラーは domain.cached-remote.xml ファイルに保存されたキャッシュされた設定の使用を開始します。このファイルが存在しないとホストコントローラーは起動しないことに注意してください。

この状態の間、ホストコントローラーはドメイン設定を編集できませんが、サーバーを開始したり、デプロイメントを管理することはできます。

ホストコントローラーがキャッシュされた設定を使用して起動されると、ホストコントローラーは継続してドメインコントローラーへの再接続を試みます。ドメインコントローラーが使用できるようになると、ホストコントローラーは自動的にドメインコントローラーに再接続し、ドメイン設定を同期化します。変更された設定によっては、変更の反映のにホストコントローラーのリロードが必要になることがあります。この場合、警告がホストコントローラーのログに記録されます。

8.5.3. ホストコントローラーがドメインコントローラーとして動作するよう昇格

主要のドメインコントローラーに問題が発生した場合に、ホストコントローラーがドメインコントローラーとして動作するよう昇格できます。ホストコントローラーを 昇格 する前に、ドメインコントローラーから ドメイン設定をローカルでキャッシュする必要があります。

ドメイン設定のキャッシュ

ドメインコントローラーとして使用したいホストコントローラーに --backup オプションを使用します。

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml --backup

これにより、ドメイン設定全体のコピーが含まれる EAP_HOME/domain/configuration/ ディレクトリーに domain.cached-remote.xml ファイルが作成されます。この設定は、ホストコントローラーがドメインコントローラーとして動作するよう再設定された場合に使用されます。

注記

ignore-unused-configuration 属性は、特定のホストがキャッシュする設定の範囲を判断するために使用されます。true を指定すると、このホストコントローラーに関係する設定のみがキャッシュされ、ドメインコントローラーとして引き継ぐことはできません。false を指定すると、ドメイン設定全体がキャッシュされます。

The --backup 引数はデフォルトでこの属性の値を false とし、ドメイン全体をキャッシュします。しかし、この属性を host.xml ファイルで設定した場合は、その値が使用されます。

また、--cached-dc オプションのみを使用して、ドメイン設定のコピーを作成できますが、host.xmlignore-unused-configuration の値を false と設定し、ドメイン全体をキャッシュする必要があります。例を以下に示します。

<domain-controller>
  <remote username="$local" security-realm="ManagementRealm" ignore-unused-configuration="false">
    <discovery-options>
      ...
    </discovery-options>
  </remote>
</domain-controller>
ホストコントローラーをドメインコントローラーに昇格
  1. 元のドメインコントローラーが停止した状態であることを確認します。
  2. 管理 CLI を使用して、新しいドメインコントローラーとなるホストコントローラーへ接続します。
  3. 以下のコマンドを実行してホストコントローラーを設定し、新しいドメインコントローラーとして動作するようにします。

    /host=HOST_NAME:write-local-domain-controller
  4. 以下のコマンドを実行し、ホストコントローラーをリロードします。

    reload --host=HOST_NAME

このホストコントローラーがドメインコントローラーとして動作するようになります。

8.6. 管理対象ドメインの設定

8.6.1. 1 台のマシンで管理対象ドメインを設定

jboss.domain.base.dir プロパティーを使用すると 1台のマシンで複数のホストコントローラーを実行できます。

重要

複数の JBoss EAP ホストコントローラーを 1 台のマシン上でシステムサービスとして設定することはサポートされません。

  1. ドメインコントローラーの EAP_HOME/domain ディレクトリーをコピーします。

    $ cp -r EAP_HOME/domain /path/to/domain1
  2. ホストコントローラーの EAP_HOME/domain ディレクトリーをコピーします。

    $ cp -r EAP_HOME/domain /path/to/host1
  3. /path/to/domain1 を使用してドメインコントローラーを起動します。

    $ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.domain.base.dir=/path/to/domain1
  4. /path/to/host1 を使用してホストコントローラーを起動します。

    $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.base.dir=/path/to/host1 -Djboss.domain.master.address=IP_ADDRESS -Djboss.management.http.port=PORT
    注記

    ホストコントローラーの起動時に、jboss.domain.master.address プロパティーを使用してドメインコントローラーのアドレスを指定する必要があります。

    さらに、このホストコントローラーはドメインコントローラーと同じマシンで実行されているため、ドメインコントローラーの管理インターフェースと競合しないように管理インターフェースを変更する必要があります。このコマンドは jboss.management.http.port プロパティーを設定します。

このように起動された各インスタンスは、ベースインストールディレクトリー (例: EAP_HOME/modules/) のその他のリソースを共有しますが、jboss.domain.base.dir によって指定されたディレクトリーからドメイン設定を使用します。

8.6.2. 2 台のマシンで管理対象ドメインを設定

注記

この例の実行には、ファイアウォールの設定が必要になることがあります。

1 台がドメインコントローラーでもう 1 台がホストである 2 台のマシンで管理対象ドメインを作成できます。詳細は、「ドメインコントローラー」を参照してください。

  • IP1 = ドメインコントローラーの IP アドレス(マシン 1)
  • IP2 = ホストの IP アドレス (マシン 2)
2 台のマシンで管理対象ドメインを作成
  1. マシン 1 での作業

    1. ホストがドメインコントローラーによって認証されるよう、管理ユーザーを追加します。

      add-user.sh スクリプトを使用してホストコントローラー HOST_NAME の管理ユーザーを追加します。最後の質問で yes を指定し、提供される秘密の値を書き留めてください。この秘密の値はホストコントローラーの設定で使用され、以下のように表示されます。

      <secret value="SECRET_VALUE" />
    2. ドメインコントローラーを起動します。

      専用のドメインコントローラー用に事前設定された host-master.xml 設定ファイルを指定します。さらに、jboss.bind.address.management プロパティーを設定し、ドメインコントローラーが他のマシンにも表示されるようにします。

      $ EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.bind.address.management=IP1
  2. マシン 2 での作業

    1. ユーザー認証情報でホスト設定を更新します。

      EAP_HOME/domain/configuration/host-slave.xml を編集し、ホスト名 HOST_NAME と秘密の値 SECRET_VALUE を設定します。

      <host xmlns="urn:jboss:domain:8.0" name="HOST_NAME">
        <management>
          <security-realms>
            <security-realm name="ManagementRealm">
              <server-identities>
                <secret value="SECRET_VALUE" />
              </server-identities>
              ...
    2. ホストコントローラーを起動します。

      スレーブホストコントローラー用に事前設定された host-slave.xml 設定ファイルを指定します。さらに、jboss.domain.master.address プロパティーを設定してドメインコントローラーに接続し、jboss.bind.address プロパティーを設定してホストコントローラーバインドアドレスを設定します。

      $ EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.domain.master.address=IP1  -Djboss.bind.address=IP2

起動時に --controller パラメーターを使用してドメインコントローラーアドレスを指定し、管理 CLI からドメインを管理できるようになります。

$ EAP_HOME/bin/jboss-cli.sh --connect --controller=IP1

また、http://IP1:9990 で管理コンソールからドメインを管理することもできます。

8.7. 複数の JBoss EAP バージョンの管理

最新バージョンの JBoss EAP は、以前のバージョンの JBoss EAP を実行するサーバーおよびホストを管理できます。管理する JBoss EAP のバージョンに該当する項を参照してください。

8.7.1. JBoss EAP 6 インスタンスを管理するよう JBoss EAP 7.x ドメインコントローラーを設定

JBoss EAP 7.1 ドメインコントローラーは、実行している JBoss EAP 6 のバージョンが JBoss EAP 6.2 以上のホストおよびサーバーを管理できます。

注記

JBoss EAP 7.0 ドメインコントローラーが異なるパッチリリースの JBoss EAP 7.0 ホストを管理する場合は、設定を変更する必要はありません。しかし、JBoss EAP 7.0 ドメインコントローラーは、管理するホストコントローラーと同じパッチリリースバージョンまたはそれ以降のバージョンを実行している必要があります。

JBoss EAP 7 の管理対象ドメインで JBoss EAP 6 インスタンスを正常に管理するには、以下の作業を行います。

これらの作業が終了したら、管理 CLI を使用して JBoss EAP 7 ドメインコントローラーから JBoss EAP 6 サーバーおよび設定を管理できます。JBoss EAP 6 ホストは、バッチ処理などの JBoss EAP 7 の新機能を利用できないことに注意してください。

警告

管理コンソールは、最新バージョンの JBoss EAP に対して最適化されているため、管理コンソールを使用して JBoss EAP 6 のホスト、サーバー、およびプロファイルを更新しないでください。JBoss EAP 7 の管理対象ドメインから JBoss EAP 6 の設定を管理する場合は、代わりに 管理 CLI を使用してください。

8.7.1.1. Boss EAP 6 の設定を JBoss EAP 7 ドメインコントローラーに追加

ドメインコントローラーが JBoss EAP 6 サーバーを管理できるようにするには、JBoss EAP 7 のドメイン設定に JBoss EAP 6 の設定詳細を提供する必要があります。これには、JBoss EAP 6 のプロファイル、ソケットバインディンググループ、およびサーバーグループを JBoss EAP 7 の domain.xml 設定ファイルにコピーします。

JBoss EAP 7 の設定と名前が競合する場合は、リソースの名前を変更する必要があります。さらに、正しく動作するようにするため、追加の調整を行う必要もあります。

以下の手順では、JBoss EAP 6 の default プロファイル、standard-sockets ソケットバインディンググループ、および main-server-group サーバーグループが使用されます。

  1. JBoss EAP 7 の domain.xml 設定ファイルを編集します。このファイルをバックアップしてから編集することが推奨されます。
  2. 該当する JBoss EAP 6 のプロファイルを JBoss EAP 7 の domain.xml ファイルにコピーします。

    この手順では、JBoss EAP 6 の default プロファイルをコピーし、名前を eap6-default に変更したことを仮定します。

    JBoss EAP 7 の domain.xml

    <profiles>
      ...
      <profile name="eap6-default">
        ...
      </profile>
    </profiles>

  3. このプロファイルによって使用される必要なエクステンションを追加します。

    JBoss EAP 6 のプロファイルが JBoss EAP 7 には存在しないサブシステムを使用する場合は、JBoss EAP ドメイン設定に適切なエクステンションを追加する必要があります。

    JBoss EAP 7 の domain.xml

    <extensions>
      ...
      <extension module="org.jboss.as.configadmin"/>
      <extension module="org.jboss.as.threads"/>
      <extension module="org.jboss.as.web"/>
    <extensions>

  4. 該当する JBoss EAP 6 のソケットバインディンググループを JBoss EAP 7 の domain.xml ファイルにコピーします。

    この手順では、JBoss EAP 6 の standard-sockets ソケットバインディンググループをコピーし、名前を eap6-standard-sockets に変更したことを仮定します。

    JBoss EAP 7 の domain.xml

    <socket-binding-groups>
      ...
      <socket-binding-group name="eap6-standard-sockets" default-interface="public">
        ...
      </socket-binding-group>
    </socket-binding-groups>

  5. 該当する JBoss EAP 6 のサーバーグループを JBoss EAP 7 の domain.xml ファイルにコピーします。

    この手順では、JBoss EAP 6 の main-server-group サーバーグループをコピーし、名前を eap6-main-server-group に変更したことを仮定します。また、このサーバーグループを更新して、JBoss EAP 6 のプロファイル eap6-default と JBoss EAP 6 のソケットバインディンググループ eap6-standard-sockets を使用するようにする必要があります。

    JBoss EAP 7 の domain.xml

    <server-groups>
      ...
      <server-group name="eap6-main-server-group" profile="eap6-default">
        ...
        <socket-binding-group ref="eap6-standard-sockets"/>
      </server-group>
    </server-groups>

8.7.1.2. JBoss EAP 6 プロファイルの動作の更新

JBoss EAP のバージョンや必要な動作に応じて、JBoss EAP 6 インスタンスによって使用されるプロファイルを追加更新する必要があります。既存の JBoss EAP 6 インスタンスが使用するサブシステムや設定に応じて、追加の変更が必要になる場合があります。

JBoss EAP 7 ドメインコントローラーを起動して管理 CLI を起動し、以下の更新を実行します。これらの例では、JBoss EAP 6 のプロファイルが eap6-default であることを仮定します。

  • bean-validation サブシステムを削除します。

    JBoss EAP 7 では、bean バリデーション機能が ee サブシステムから独自の bean-validation サブシステムに移されました。JBoss EAP 7 ドメインコントローラーがレガシーの ee サブシステムを発見した場合、新しい bean-validation サブシステムを追加します。しかし、JBoss EAP 6 のホストはこのサブシステムを認識しないため、削除する必要があります。

    JBoss EAP 7 のドメインコントローラー CLI

    /profile=eap6-default/subsystem=bean-validation:remove

  • CDI 1.0 の挙動を設定します。

    これは、JBoss EAP 6 サーバーに JBoss EAP 7 で使用されるより新しいバージョンの CDI の挙動ではなく、CDI 1.0 の挙動を適用する場合のみ必要です。CDI 1.0 の挙動を提供する場合は、weld サブシステムに以下の更新を追加します。

    JBoss EAP 7 のドメインコントローラー CLI

    /profile=eap6-default/subsystem=weld:write-attribute(name=require-bean-descriptor,value=true)
    
    /profile=eap6-default/subsystem=weld:write-attribute(name=non-portable-mode,value=true)

  • JBoss EAP 6.2 のデータソース統計を有効にします。

    これは、プロファイルが JBoss EAP 6.2 サーバーによって使用される場合のみ必要です。JBoss EAP 6.3 には statistics-enabled 属性が導入され、デフォルトでは統計を収集しない false に設定されます。しかし、JBoss EAP 6.2 では統計を収集しました。このプロファイルが JBoss EAP 6.2 のホストとそれ以降のバージョンのJBoss EAP を実行するホストによって使用される場合、ホストによって動作が異なることになり、これは許可されません。そのため、JBoss EAP 6.2 ホスト向けのプロファイルは、データソースに以下の変更を追加する必要があります。

    JBoss EAP 7 のドメインコントローラー CLI

    /profile=eap6-default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=statistics-enabled,value=true)

8.7.1.3. JBoss EAP 6 サーバーのサーバーグループの設定

サーバーグループの名前を変更した場合は、JBoss EAP 6 のホスト設定を更新し、JBoss EAP 7 の設定に指定された新しいサーバーグループを使用する必要があります。この例では、JBoss EAP 7 の domain.xml に指定された eap6-main-server-group サーバーグループを使用します。

JBoss EAP 6 の host-slave.xml

<servers>
    <server name="server-one" group="eap6-main-server-group"/>
    <server name="server-two" group="eap6-main-server-group">
        <socket-bindings port-offset="150"/>
    </server>
</servers>

注記

ホストは、実行している JBoss EAP よりも新しいバージョンで導入された機能や設定を使用できません。

8.7.1.4. JBoss EAP 6 インスタンスが JBoss EAP 7 の更新を取得しないようにする

管理対象ドメインのドメインコントローラーは、設定の更新をホストコントローラーに転送します。host-exclude 設定を使用して、特定のバージョンが認識できないようにするリソースを指定する必要があります。事前設定された host-exclude のオプションは EAP62EAP63EAP64、および EAP64z です。 ご使用の JBoss EAP 6 のバージョンに該当するものを選択します。

host-exclude 設定の active-server-groups 属性は、特定のバージョンによって使用されるサーバーグループのリストを指定します。指定のバージョンのホストは、指定されたサーバーグループとそれらに関連するプロファイル、ソケットバインディンググループ、およびデプロイメントリソースを利用できますが、それ以外は認識しません。

以下の例では、JBoss EAP のバージョンが 6.4.z であることを仮定し、JBoss EAP 6 のサーバーグループ eap6-main-server-group をアクティブなサーバーグループとして追加します。

JBoss EAP 7 のドメインコントローラー CLI

/host-exclude=EAP64z:write-attribute(name=active-server-groups,value=[eap6-main-server-group])

必要な場合は、active-socket-binding-groups 属性を使用して、サーバーによって使用される追加のソケットバインディンググループを指定します。これは、active-server-groups に指定されたサーバーグループと関連していないソケットバインディンググループのみに必要です。

8.7.2. JBoss EAP 7.0 インスタンスを管理するよう JBoss EAP 7.1 ドメインコントローラーを設定

JBoss EAP 7.1 のドメインコントローラーは、JBoss EAP 7.0 を実行しているホストおよびサーバーを管理できます。

注記

JBoss EAP 7.1 ドメインコントローラーが異なるパッチリリースの JBoss EAP 7.1 ホストを管理する場合は、設定を変更する必要はありません。しかし、JBoss EAP 7.1 ドメインコントローラーは、管理するホストコントローラーと同じパッチリリースバージョンまたはそれ以降のバージョンを実行している必要があります。

JBoss EAP 7.1 の管理対象ドメインで JBoss EAP 7.0 インスタンスを正常に管理するには、以下の作業を行います。

これらの作業が終了したら、管理 CLI を使用して JBoss EAP 7.1 ドメインコントローラーから JBoss EAP 7.0 サーバーおよび設定を管理できます。JBoss EAP 7.0 ホストは、elytron サブシステムなどの JBoss EAP 7.1 の新機能を利用できないことに注意してください。

警告

管理コンソールは、最新バージョンの JBoss EAP に対して最適化されているため、管理コンソールを使用して JBoss EAP 7.0 のホスト、サーバー、およびプロファイルを更新しないでください。JBoss EAP 7.1 の管理対象ドメインから JBoss EAP 7.0 の設定を管理する場合は、代わりに 管理 CLI を使用してください。

8.7.2.1. Boss EAP 7.0 の設定を JBoss EAP 7.1 ドメインコントローラーに追加

ドメインコントローラーが JBoss EAP 7.0 サーバーを管理できるようにするには、JBoss EAP 7.1 のドメイン設定に JBoss EAP 7.0 の設定詳細を提供する必要があります。これには、JBoss EAP 7.0 のプロファイル、ソケットバインディンググループ、およびサーバーグループを JBoss EAP 7.1 の domain.xml 設定ファイルにコピーします。

JBoss EAP 7.1 の設定と名前が競合する場合は、リソースの名前を変更する必要があります。

以下の手順では、JBoss EAP 7.0 の default プロファイル、standard-sockets ソケットバインディンググループ、および main-server-group サーバーグループが使用されます。

  1. JBoss EAP 7.1 の domain.xml 設定ファイルを編集します。このファイルをバックアップしてから編集することが推奨されます。
  2. 該当する JBoss EAP 7.0 のプロファイルを JBoss EAP 7.1 の domain.xml ファイルにコピーします。

    この手順では、JBoss EAP 7.0 の default プロファイルをコピーし、名前を eap70-default に変更したことを仮定します。

    JBoss EAP 7.1 の domain.xml

    <profiles>
      ...
      <profile name="eap70-default">
        ...
      </profile>
    </profiles>

  3. 該当する JBoss EAP 7.0 のソケットバインディンググループを JBoss EAP 7.1 の domain.xml ファイルにコピーします。

    この手順では、JBoss EAP 7.0 の standard-sockets ソケットバインディンググループをコピーし、名前を eap70-standard-sockets に変更したことを仮定します。

    JBoss EAP 7.1 の domain.xml

    <socket-binding-groups>
      ...
      <socket-binding-group name="eap70-standard-sockets" default-interface="public">
        ...
      </socket-binding-group>
    </socket-binding-groups>

  4. 該当する JBoss EAP 7.0 のサーバーグループを JBoss EAP 7.1 の domain.xml ファイルにコピーします。

    この手順では、JBoss EAP 7.0 の main-server-group サーバーグループをコピーし、名前を eap70-main-server-group に変更したことを仮定します。また、このサーバーグループを更新して、JBoss EAP 7.0 のプロファイル eap70-default と JBoss EAP 7.0 のソケットバインディンググループ eap70-standard-sockets を使用するようにする必要があります。

    JBoss EAP 7.1 の domain.xml

    <server-groups>
      ...
      <server-group name="eap70-main-server-group" profile="eap70-default">
        ...
        <socket-binding-group ref="eap70-standard-sockets"/>
      </server-group>
    </server-groups>

8.7.2.2. JBoss EAP 7.0 サーバーのサーバーグループの設定

サーバーグループの名前を変更した場合は、JBoss EAP 7.0 のホスト設定を更新し、JBoss EAP 7.1 の設定に指定された新しいサーバーグループを使用する必要があります。この例では、JBoss EAP 7.1 の domain.xml に指定された eap70-main-server-group サーバーグループを使用します。

JBoss EAP 7.0 の host-slave.xml

<servers>
    <server name="server-one" group="eap70-main-server-group"/>
    <server name="server-two" group="eap70-main-server-group">
        <socket-bindings port-offset="150"/>
    </server>
</servers>

注記

ホストは、実行している JBoss EAP よりも新しいバージョンで導入された機能や設定を使用できません。

8.7.2.3. JBoss EAP 7.0 インスタンスが JBoss EAP 7.1 の更新を取得しないようにする

管理対象ドメインのドメインコントローラーは、設定の更新をホストコントローラーに転送します。JBoss EAP 7.0 のホストは JBoss EAP 7.1 固有の設定やリソースを取得しないため、JBoss EAP 7.0 のホストを設定してこれらのリソースを無視する必要があります。これには、JBoss EAP 7.0 のホストで ignore-unused-configuration 属性を設定します。

注記

また、host-exclude 設定を使用して、特定のバージョンの JBoss EAP を実行するホストが特定のリソースを認識しないよう、ドメインコントローラーに指示することもできます。host-exclude 設定の使用例については、「JBoss EAP 6 インスタンスが JBoss EAP 7 の更新を取得しないようにする」を参照してください。JBoss EAP 7.0 のホストの場合、host-exclude のオプションとして EAP70 を使用します。

JBoss EAP 7.0 ホストコントローラーのリモートドメインコントローラーへの接続設定で、ignore-unused-configuration 属性を true に設定します。

JBoss EAP 7.0 の host-slave.xml

<domain-controller>
    <remote security-realm="ManagementRealm" ignore-unused-configuration="true">
        <discovery-options>
            <static-discovery name="primary" protocol="${jboss.domain.master.protocol:remote}" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9990}"/>
        </discovery-options>
    </remote>
</domain-controller>

この設定では、このホストは使用するサーバーグループと、それらのサーバーグループに関連するプロファイル、ソケットバインディング、およびデプロイメントリソースのみを利用でます。その他はすべて無視されます。

8.8. JBoss EAP プロファイルの管理

8.8.1. プロファイル

JBoss EAP は、プロファイルを使用してサーバーが使用できるサブシステムを整理します。プロファイルは、利用可能なサブシステムと各サブシステムの特定の設定で構成されます。プロファイルのサブシステムの数が多いと、サーバーの機能が多くなります。プロファイルのサブシステムが集中的で数が少ないと、機能が少なくなりますが、フットプリントも少なくなります。

JBoss EAP にはほとんどのユースケースに対応する事前定義されたプロファイルが 5 つあります。

default
loggingsecuritydatasourcesinfinispanwebserviceseeejb3transactions など、一般的に使用されるサブシステムが含まれます。
ha
default プロファイルで提供されるサブシステムと、高可用性向けの jgroups および modcluster サブシステムが含まれます。
full
default プロファイルで提供されるサブシステムと、 messaging-activemq および iiop-openjdk サブシステムが含まれます。
full-ha
full プロファイルで提供されるサブシステムと、高可用性向けの jgroups および modcluster サブシステムが含まれます。
load-balancer
ビルトインの mod_cluster フロントエンドロードバランサーを使用して他の JBoss EAP インスタンスの負荷を分散するために必要な最低限のサブシステムが含まれます。
注記

JBoss EAP は、既存プロファイルの設定からサブシステムを削除して、エクステンションを無効にしたり、ドライバーやその他のサービスを手作業でアンロードしたりする機能を提供します。ただし、ほとんどの場合、これは必要ありません。JBoss EAP は必要時にサブシステムを動的にロードするため、サーバーまたはアプリケーションがサブシステムを使用しないと、そのサブシステムはロードされません。

既存のプロファイルが必要な機能を提供しない場合、JBoss EAP はカスタムプロファイルを定義する機能も提供します。

8.8.2. プロファイルのクローン

JBoss EAP では、既存のプロファイルをクローンして管理対象ドメインで新しいプロファイルを作成することができます。クローンした既存プロファイルの設定およびサブシステムのコピーが作成されます。

管理 CLI を使用してプロファイルをクローンするには、クローンするプロファイルに clone 操作を実行します。

/profile=full-ha:clone(to-profile=cloned-profile)

管理コンソールからプロファイルをクローンするには、クローンするプロファイルを選択し、Clone をクリックします。

8.8.3. 階層的なプロファイルの作成

管理対象ドメインでは、プロファイルの階層を作成できます。これにより、他のプロファイルが継承できる共通のエクステンションが含まれるベースプロファイルを作成できます。

管理対象ドメインは domain.xml の複数のプロファイルを定義します。複数のプロファイルが特定のサブシステムで同じ設定を使用する場合、複数のプロファイルで設定せずに、1 つのプロファイルで設定を行うことができます。親プロファイルの値はオーバーライドできません。

さらに、各プロファイルは他に依存しなくてもすむ必要があります。要素やサブシステムが参照される場合、参照されるプロファイルに定義する必要があります。

管理 CLI を使用して list-add 操作を実行し、含めるプロファイルを指定すると、プロファイルに階層の別のプロファイルを含めることができます。

/profile=new-profile:list-add(name=includes, value=PROFILE_NAME)

第9章 JVM の設定

Java Virtual Machine (JVM) の設定は、スタンドアロンの JBoss EAP サーバーと管理対象ドメインの JBoss EAP サーバーでは異なります。

スタンドアロン JBoss EAP サーバーインスタンスでは、起動時にサーバー起動プロセスが JVM 設定を JBoss EAP サーバーに渡します。これは、JBoss EAP を起動する前にコマンドラインから宣言できます。 また、管理コンソールの Configuration にある System Properties 画面を使用して宣言することもできます。

管理対象ドメインでは、JVM の設定は host.xml および domain.xml 設定ファイルで宣言され、ホスト、サーバーグループ、またはサーバーレベルで設定できます。

注記

システムプロパティーは、起動中に JBoss EAP モジュール (ロギングマネージャーなど) が使用する JAVA_OPTS で設定する必要があります。

9.1. スタンドアロンサーバーの JVM 設定

スタンドアロン JBoss EAP サーバーインスタンスの JVM 設定は、サーバーの起動前に JAVA_OPTS 環境変数を設定すると、起動時に宣言できます。

Linux で JAVA_OPTS 環境変数を設定する例は次のとおりです。

$ export JAVA_OPTS="-Xmx1024M"

Microsoft Windows 環境でも同じ設定を使用できます。

set JAVA_OPTS="Xmx1024M"

この代わりに、JVM に渡すオプションの例が含まれる EAP_HOME/bin フォルダーの standalone.conf ファイル (Windows Server の場合は standalone.conf.bat) に JVM 設定を追加することもできます。

警告

JAVA_OPTS 環境変数を設定すると、standalone.conf からのデフォルト値がオーバーライドされるため、JBoss EAP の起動に問題が発生する可能性があります。

9.2. 管理対象ドメインの JVM 設定

JBoss EAP 管理対象ドメインでは、複数のレベルで JVM の設定を定義できます。特定ホストのカスタム JVM 設定を定義し、それらの設定をサーバーグループまたは個別のサーバーインスタンスに適用できます。

デフォルトでは、サーバーグループおよび各サーバーは親から JVM 設定を継承しますが、各レベルで JVM 設定をオーバーライドすることもできます。

注記

domain.conf の JVM 設定 (Windows Server の場合は domain.conf.bat) は JBoss EAP ホストコントローラーの Java プロセスに適用されます。 ホストコントローラーによって制御される個別の JBoss EAP サーバーインスタンスには適用されません。

9.2.1. ホストコントローラーの JVM 設定の定義

ホストコントローラーの JVM 設定を定義し、これらの設定をサーバーグループまたは各サーバーに適用することができます。JBoss EAP には default の JVM 設定が含まれますが、以下の管理 CLI コマンドを実行すると、カスタム JVM 設定およびオプションがある production_jvm という名前の JVM 設定が新たに作成されます。

/host=HOST_NAME/jvm=production_jvm:add(heap-size=2048m, max-heap-size=2048m, max-permgen-size=512m, stack-size=1024k, jvm-options=["-XX:-UseParallelGC"])

使用できるすべてのオプションの説明は「管理対象ドメインの JVM 設定属性」を参照してください。

また、JBoss EAP 管理コンソールで JVM 設定を作成および編集するには、RuntimeHosts と選択し、ホストを選択して 表示 をクリックし、JVMs タブを選択します。

これらの設定は host.xml<jvm> タグ内に保存されます。

9.2.2. JVM 設定のサーバーグループへの適用

サーバーグループの作成時に、グループのすべてのサーバーが使用する JVM 設定を指定できます。以下の管理 CLI コマンドを実行すると、前の例で示された production_jvm JVM 設定を使用する groupA という名前のサーバーグループが作成されます。

/server-group=groupA:add(profile=default, socket-binding-group=standard-sockets)
/server-group=groupA/jvm=production_jvm:add

サーバーグループのすべてのサーバーは、production_jvm から JVM 設定を継承します。

サーバーグループレベルで特定の JVM 設定をオーバーライドすることもできます。たとえば、別のヒープサイズを設定するには、以下のコマンドを使用できます。

/server-group=groupA/jvm=production_jvm:write-attribute(name=heap-size,value="1024m")

上記コマンドの実行後、サーバーグループ groupAproduction_jvm から JVM 設定を継承しますが、ヒープサイズの値は 1024m にオーバーライドされます。

使用できるすべてのオプションの説明は「管理対象ドメインの JVM 設定属性」を参照してください。

また、JBoss EAP 管理コンソールでサーバーグループの JVM 設定を編集するには、RuntimeServer Groups と選択し、サーバーグループを選択して 表示 をクリックし、JVMs タブを選択します。

サーバーグループの設定は domain.xml に保存されます。

9.2.3. JVM 設定の個別のサーバーへの適用

デフォルトでは、個別の JBoss EAP サーバーインスタンスは属するサーバーグループの JVM 設定を継承します。しかし、継承した設定をホストコントローラーからの別の JVM 設定定義でオーバーライドしたり、特定の JVM 設定をオーバーライドすることもできます。

たとえば、以下のコマンドは 前の例で示したサーバーグループの JVM 定義をオーバーライドし、server-one の JVM 設定を default の JVM 定義に設定します。

/host=HOST_NAME/server-config=server-one/jvm=default:add

また、サーバーグループと同様に、サーバーレベルで特定の JVM 設定をオーバーライドすることもできます。たとえば、別のヒープサイズを設定するには、以下のコマンドを使用できます。

/host=HOST_NAME/server-config=server-one/jvm=default:write-attribute(name=heap-size,value="1024m")

使用できるすべてのオプションの説明は「管理対象ドメインの JVM 設定属性」を参照してください。

また、JBoss EAP 管理コンソールでサーバー JVM 設定を作成編集するには、RuntimeHosts と選択し、ホストを選択して 表示 をサーバー上でクリックし、JVMs タブを選択します。

各サーバーのこれらの設定は host.xml に保存されます。

9.3. JVM 状態の表示

ヒープおよびスレッドの使用状況など、スタンドアロンまたは管理対象ドメインサーバーの JVM リソースの状態は管理コンソールから表示できます。統計はリアルタイムでは表示されませんが、Refresh をクリックすると JVM リソースの最新の概要を表示できます。

スタンドアロン JBoss EAP サーバーの JVM の状態を表示するには、以下を行います。

  • Runtime タブに移動し、サーバーを選択して、状態 を選択します。

管理対象ドメインでの JBoss EAP サーバーの JVM の状態を表示するには、以下を行います。

  • RuntimeHosts と選択し、ホストとサーバーを選択して 状態 を選択します。

以下のヒープ使用情報が表示されます。

Max
メモリー管理に使用できるメモリーの最大量。
Used
使用されたメモリーの量。
Committed
JVM が使用するために確保されたメモリー量。

JVM のアップタイムやスレッドの使用状況などの他の情報も表示されます。

9.4. JVM の調整

JVM のパフォーマンスを最適化するための情報は、『パフォーマンスチューニングガイド』の「JVM の調整」を参照してください。

第10章 Mail サブシステム

10.1. Mail サブシステムの設定

mail サブシステムを使用すると、JBoss EAP でメールセッションを設定でき、JNDI を使用してこれらのセッションをアプリケーションにインジェクトできます。また、Jakarta EE の @MailSessionDefinition および @MailSessionDefinitions アノテーションを使用する設定もサポートします。

アプリケーションで使用する SMTP サーバーの設定

  1. 以下の CLI コマンドを使用して SMTP サーバーとアウトバウンドソケットバインディングを設定します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-smtp:add(host=localhost, port=25)
    /subsystem=mail/mail-session=mySession:add(jndi-name=java:jboss/mail/MySession)
    /subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-smtp, username=user, password=pass, tls=true)
  2. アプリケーション内で設定されたメールセッションを呼び出します。

    @Resource(lookup="java:jboss/mail/MySession")
    private Session session;

メールセッションおよびサーバーの設定で使用できる属性の完全リストは「Mail サブシステムの属性」を参照してください。

10.2. カスタムトランスポートの設定

POP3 や IMAP などの標準のメールサーバーを使用している場合、メールサーバーには定義できる属性のセットがあります。これらの属性の一部は必須です。最も重要な属性はアウトバウンドメールソケットバインディングの参照である outbound-socket-binding-ref で、ホストアドレスとポート番号で定義されます。

outbound-socket-binding-ref の定義は、負荷分散の目的でホスト設定に複数のホストを使用するユーザーにとっては最も効率的なソリューションではない場合があります。標準の Jakarta Mail は負荷分散のために複数のホストを使用するホスト設定をサポートしません。そのため、複数のホストを使用するこの設定を持つユーザーはカスタムメールトランスポートを実装する必要があります。カスタムメールトランスポートは outbound-socket-binding-ref を必要とせず、カスタムのホストプロパティー形式を許可します。

カスタムのメールトランスポートは管理 CLI から設定できます。

  1. 新しいメールセッションを追加し、JNDI 名を指定します。

    /subsystem=mail/mail-session=mySession:add(jndi-name=java:jboss/mail/MySession)
  2. アウトバウンドソケットバインディングを追加し、ホストとポートを指定します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-smtp-binding:add(host=localhost, port=25)
  3. SMTP サーバーを追加し、アウトバウンドソケットバインディング、ユーザー名、およびパスワードを指定します。

    /subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-smtp-binding, username=user, password=pass, tls=true)
注記

同様の手順で POP3 または IMAP サーバーを設定できます。

POP3 サーバー

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-pop3-binding:add(host=localhost, port=110)
/subsystem=mail/mail-session=mySession/server=pop3:add(outbound-socket-binding-ref=my-pop3-binding, username=user, password=pass)

IMAP サーバー

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=my-imap-binding:add(host=localhost, port=143)
/subsystem=mail/mail-session=mySession/server=imap:add(outbound-socket-binding-ref=my-imap-binding, username=user, password=pass)

カスタムサーバーを使用するには、アウトバウンドソケットバインディングを指定せずにカスタムメールサーバーを作成します。カスタムメールサーバーのプロパティー定義でホスト情報を指定できます。例を以下に示します。

/subsystem=mail/mail-session=mySession/custom=myCustomServer:add(username=user,password=pass, properties={"host" => "myhost", "my-property" =>"value"})

カスタムプロトコルを定義する場合、ピリオド (.) が含まれるプロパティー名は完全修飾名と見なされ、直接渡されます。my-property など、他の形式は mail.server-name.my-property という形式に変換されます。

以下の XML は、カスタムサーバーが含まれるメール設定の例になります。

<subsystem xmlns="urn:jboss:domain:mail:3.0">
   <mail-session name="default" jndi-name="java:jboss/mail/Default">
        <smtp-server outbound-socket-binding-ref="mail-smtp"/>
   </mail-session>
    <mail-session name="myMail" from="user.name@domain.org" jndi-name="java:/Mail">
        <smtp-server password="password" username="user" tls="true" outbound-socket-binding-ref="mail-smtp"/>
        <pop3-server outbound-socket-binding-ref="mail-pop3"/>
        <imap-server password="password" username="nobody" outbound-socket-binding-ref="mail-imap"/>
    </mail-session>
    <mail-session name="custom" jndi-name="java:jboss/mail/Custom" debug="true">
        <custom-server name="smtp" password="password" username="username">
            <property name="host" value="mail.example.com"/>
        </custom-server>
    </mail-session>
    <mail-session name="custom2" jndi-name="java:jboss/mail/Custom2" debug="true">
        <custom-server name="pop3" outbound-socket-binding-ref="mail-pop3">
            <property name="custom-prop" value="some-custom-prop-value"/>
        </custom-server>
    </mail-session>
</subsystem>

10.3. パスワードに認証情報ストアを使用

mail サブシステムでクリアテキストのパスワードを提供する他に、認証情報ストアを使用してパスワードを提供することもできます。elytron サブシステムを使用すると、認証情報ストアを作成してパスワードをセキュアに保存し、JBoss EAP 全体でパスワードを使用することができます。認証情報ストアの作成および使用に関する詳細は、『How to Configure Server Security』の「Credential Store」を参照してください。

管理 CLI を使用した認証情報ストアの使用

/subsystem=mail/mail-session=mySession/server=smtp:add(outbound-socket-binding-ref=my-smtp-binding, username=user, credential-reference={store=exampleCS, alias=mail-session-pw}, tls=true)

注記

以下は、クリアテキストパスワードを使用する credential-reference 属性を指定する方法の例になります。

credential-reference={clear-text="MASK-Ewcyuqd/nP9;A1B2C3D4;351"}

管理コンソールを使用した認証情報ストアの使用

  1. 管理コンソールにアクセスします。詳細は「管理コンソール」を参照してください。
  2. ConfigurationSubsystemsMail と選択します。
  3. 該当するメールセッションを選択し、表示 をクリックします。
  4. Server を選択し、該当するメールセッションサーバーを選択します。Credential Reference タブで認証情報リファレンスを設定でき、 Attributes タブでその他の属性を編集できます。

第11章 JBoss EAP を用いたロギング

JBoss EAP は、EAP での内部使用とデプロイされたアプリケーションによる使用の両方で設定可能なロギング機能を提供します。logging サブシステムは JBoss LogManager を基盤とし、JBoss Logging だけでなくサードパーティーアプリケーションのロギングフレームワークを複数サポートします。

11.1. サーバーロギング

11.1.1. サーバーロギング

デフォルトでは、すべての JBoss EAP ログエントリーは server.log ファイルに書き込みされます。このファイルの場所は操作するモードによって異なります。

  • スタンドアロンサーバーの場合: EAP_HOME/standalone/log/server.log
  • 管理対象ドメインの場合: EAP_HOME/domain/servers/SERVER_NAME/log/server.log

このファイルはサーバーログとも呼ばれます。詳細は「ルートロガー」を参照してください。

11.1.2. 起動時のロギング

起動中に JBoss EAP は Java 環境と各サービスの起動に関する情報をログに記録します。このログは、トラブルシューティングに役に立ちます。デフォルトでは、すべてのログエントリーがサーバーログに書き込まれます。

起動時のロギング設定は logging.properties 設定ファイルに指定されます。これは、JBoss EAP logging が開始され、継承するまでアクティブになります。このファイルの場所は操作するモードによって異なります。

  • スタンドアロンサーバーの場合: EAP_HOME/standalone/configuration/logging.properties
  • 管理対象ドメインの場合:

    ドメインコントローラーおよびサーバーごとに 1 つの logging.properties ファイルがあります。

    • ドメインコントローラー: EAP_HOME/domain/configuration/logging.properties
    • サーバー: EAP_HOME/domain/servers/SERVER_NAME/data/logging.properties
警告

logging.propertiesファイルは、直接編集する必要があるユースケース以外では直接編集しないことが推奨されます。直接編集する前に、Red Hat カスタマーポータルでサポートケースを作成することが推奨されます。

logging.propertiesファイルに手動で行った変更は起動時に上書きされます。

11.1.2.1. 起動エラーの表示

JBoss EAP をトラブルシューティングする場合、最初に行うべきことの 1 つは、起動時に発生したエラーをチェックすることです。提供された情報を使用して原因を診断し、解決します。起動時のエラーをトラブルシューティングする際にサポートが必要な場合はサポートケースを作成してください。

起動時のエラーを表示する方法は 2 つあり、どちらも利点があります。1 つは server.log ファイルを確認する方法で、もう 1 つは read-boot-errors管理 CLI コマンドを使用してブートエラーを確認する方法になります。

サーバーログファイルの確認

server.log ファイルを開いて起動中に発生したエラーを確認します。

この方法では、各エラーメッセージおよび関連するメッセージを確認でき、エラーが発生した理由の詳細を知ることができます。また、エラーメッセージをプレーンテキスト形式で表示することもできます。

  1. ファイルビューアーで server.log を開きます。
  2. ファイルの最後に移動します。
  3. 最後の起動シーケンスの開始を示す WFLYSRV0049 メッセージ ID を後方検索します。
  4. ログのその位置から ERROR を前方検索します。各検索一致箇所には、エラーの説明が示され、関連するモジュールがリストされます。

以下は、server.log ログファイルのエラー説明の例です。

2016-03-16 14:32:01,627 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
        at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.BindException: Address already in use
        ...
管理 CLI からのブートエラーの読み取り

サーバーが起動しても起動中にエラーが報告された場合、read-boot-errors 管理 CLI コマンドを使用してエラーを確認できます。

この方法では、サーバーのファイルシステムにアクセスする必要がありません。したがって、エラーを監視する担当者がファイルシステムアクセスを持ってない場合に役に立ちます。これは CLI コマンドであるため、スクリプトで使用できます。 たとえば、複数の JBoss EAP インスタンスを起動し、起動時に発生したエラーをチェックするスクリプトを記述できます。

次の管理 CLI コマンドを実行します。

/core-service=management:read-boot-errors

起動中に発生したすべてのエラーがリストされます。

{
    "outcome" => "success",
    "result" => [
        {
            "failed-operation" => {
                "operation" => "add",
                "address" => [
                    ("subsystem" => "undertow"),
                    ("server" => "default-server"),
                    ("http-listener" => "default")
                ]
            },
            "failure-description" => "{\"WFLYCTL0080: Failed services\" => {\"jboss.undertow.listener.default\" => \"org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
    Caused by: java.net.BindException: Address already in use\"}}",
            "failed-services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: Could not start http listener
    Caused by: java.net.BindException: Address already in use"}
        }
        ...
    ]
}

11.1.3. ガベッジコレクションのロギング

ガベッジコレクションロギングは、すべてのガベッジコレクションのアクティビティーをプレーンテキストのログファイルに記録します。これらのログファイルは診断を行うのに便利です。ガベッジコレクションロギングは、IBM の Java Development Kit を除くすべてのサポート対象設定の JBoss EAP スタンドアロンサーバーではデフォルトで有効になっています。

ガベッジコレクションログの場所は EAP_HOME/standalone/log/gc.log.DIGIT.current です。ガベッジコレクションのログは 3 MB ずつに制限され、最大 5 つのファイルがローテーションされます。

トラブルシューティングに便利で、オーバーヘッドは最低限であるため、ガベッジコレクションのロギングを有効にすることが強く推奨されます。しかし、スタンドアロンサーバーのガベッジコレクションのロギングを無効にする場合は、サーバーを起動する前に GC_LOG 変数を false に設定します。例を以下に示します。

$ export GC_LOG=false
$ EAP_HOME/bin/standalone.sh

11.1.4. デフォルトのログファイルの場所

以下のログファイルは、デフォルトのロギング設定に対して作成されます。デフォルトの設定では、periodic ログハンドラーを使用してサーバーログファイルが書き込まれます。

表11.1 スタンドアロンサーバーのデフォルトログファイル

ログファイル説明

EAP_HOME/standalone/log/server.log

サーバー起動メッセージを含むサーバーログメッセージが含まれます。

EAP_HOME/standalone/log/gc.log.DIGIT.current

ガベッジコレクションの詳細が含まれます。

表11.2 管理対象ドメイン用のデフォルトログファイル

ログファイル説明

EAP_HOME/domain/log/host-controller.log

ホストコントローラーの起動に関連するログメッセージが含まれます。

EAP_HOME/domain/log/process-controller.log

プロセスコントローラーの起動に関連するログメッセージが含まれます。

EAP_HOME/domain/servers/SERVER_NAME/log/server.log

サーバー起動メッセージを含む、名前付きサーバーのログメッセージが含まれます。

11.1.5. サーバーのデフォルトロケールの設定

JVM プロパティーを適切な起動設定ファイルに設定すると、デフォルトのロケールを設定できます。起動設定ファイルは、スタンドアロンサーバーの場合は EAP_HOME/bin/standalone.conf、管理対象ドメインの場合は EAP_HOME/bin/domain.conf になります。

注記

Windows Server の場合、JBoss EAP 起動設定ファイルは standalone.conf.batdomain.conf.bat になります。

国際化または現地化されたログメッセージはこのデフォルトロケールを使用します。JBoss EAP『開発ガイド』の国際化されたログメッセージの作成に関する情報を参照してください。

言語の設定

言語を指定するには、JAVA_OPTS 変数を使用して user.language プロパティーを設定します。たとえば、以下の行を起動設定ファイルに追加し、フランス語のロケールを設定します。

JAVA_OPTS="$JAVA_OPTS -Duser.language=fr"

国際化および現地化されたログメッセージがフランス語で出力されるようになります。

言語および国の設定

言語の他に、user.country プロパティーを設定して国を指定することもできます。たとえば、以下の行を起動設定ファイルに追加すると、ポルトガル語のロケールがブラジルに設定されます。

JAVA_OPTS="$JAVA_OPTS -Duser.language=pt -Duser.country=BR"

国際化および現地化されたログメッセージがブラジルポルトガル語で出力されるようになります。

org.jboss.logging.locale プロパティーを使用したサーバーロケールの設定

org.jboss.logging.locale プロパティーを使用すると、Boss EAP からのメッセージや JBoss EAP が所有する依存関係からのメッセージなど、JBoss Logging を使用してログに記録されたメッセージのロケールを上書きできます。JSF などの他の依存関係ではロケールを上書きできません。

JBoss EAP サーバーをシステムデフォルト以外のロケールで起動するには、操作モードに応じて EAP_HOME/bin/standalone.conf または EAP_HOME/bin/domain.conf ファイルを編集し、以下のコマンドを追加して必要なロケールの JVM パラメーターを設定します。プロパティーの値は BCP 47 形式で指定する必要があります。たとえば、ブラジルポルトガル語を設定する場合は「pt-BR 」を使用します。

JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.logging.locale=pt-BR"

11.2. ログファイルの表示

サーバーやアプリケーションログの確認は、診断エラー、パフォーマンスの問題、およびその他の問題に対応するために重要です。サーバーのファイルシステムで直接ログを表示したいユーザーもいます。直接ファイルシステムにアクセスできないユーザーやグラフィカルインターフェースを使用したいユーザーは JBoss EAP の管理コンソールからログを表示することができます。また、管理 CLI を使用してログを表示することもできます。

管理インターフェースの 1 つからログにアクセスするには、サーバーの jboss.server.log.dir プロパティーによって指定されたディレクトリーに存在し、File、Periodic rotating、Size rotating、または Periodic size rotating ログハンドラーとして定義される必要があります。RBAC ロール割り当ても考慮されるため、管理コンソールまたは管理 CLI にログインしたユーザーはアクセス権限を持つログのみ表示できます。

管理コンソールからのログの表示

管理コンソールから直接ログを表示できます。

  1. Runtime タブを選択し、該当するサーバーを選択します。
  2. ログファイル を選択し、リストからログファイルを選択します。
  3. 表示 をクリックしてログの内容を表示および検索するか、ドロップダウンリストから ダウンロード を選択してログファイルをローカルファイルシステムにダウンロードします。
警告

管理コンソールのログビューアーは、100MB 以上のログファイルなどの非常に大きなログファイルを表示するテキストエディターの代わりとして使用するものではありません。15MB を超えるログファイルを開こうとすると、確認を求められます。管理コンソールで非常に大きなファイルを開くと、ブラウザーがクラッシュする可能性があるため、大きなログファイルは常にローカルにダウンロードし、テキストエディターで開くようにしてください。

管理 CLI からのログの表示

read-log-file コマンドを使用すると管理 CLI からログファイルの内容を取得できます。デフォルトでは、指定されたログファイルの最後の 10 行が表示されます。

/subsystem=logging/log-file=LOG_FILE_NAME:read-log-file
注記

管理対象ドメインでは、このコマンドの前に /host=HOST_NAME/server=SERVER_NAME を追加してください。

以下のパラメーターを使用するとログの出力をカスタマイズできます。

encoding
ファイルの読み取りに使用される文字エンコーディング。
lines
ファイルから読み取る行数。-1 はログの行すべてを取得します。デフォルトは 10 です。
skip
読み取る前にスキップする行数。デフォルトは 0 です。
tail
ファイルの最後から読み取るかどうか。デフォルト値は true です。

たとえば、以下の管理 CLI コマンドは server.log ログファイルの最初の 5 行を読み取ります。

/subsystem=logging/log-file=server.log:read-log-file(lines=5,tail=false)

このコマンドを実行すると以下が出力されます。

{
    "outcome" => "success",
    "result" => [
        "2016-03-24 08:49:26,612 INFO  [org.jboss.modules] (main) JBoss Modules version 1.5.1.Final-redhat-1",
        "2016-03-24 08:49:26,788 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final-redhat-1",
        "2016-03-24 08:49:26,863 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: JBoss EAP 7.0.0.GA (WildFly Core 2.0.13.Final-redhat-1) starting",
        "2016-03-24 08:49:27,973 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)",
        "2016-03-24 08:49:27,994 INFO  [org.xnio] (MSC service thread 1-1) XNIO version 3.3.4.Final-redhat-1"
    ]
}

11.3. Logging サブシステム

JBoss EAP の logging サブシステムは ログカテゴリー および ログハンドラー のシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義します。ログハンドラーは、ディスクへの書き込みやコンソールへの送信など、これらのメッセージの対応方法を定義します。

ロギングプロファイル は、一意な名前が付けられたロギング設定の作成や、他のロギング設定に関係しないアプリケーションへの割り当てを可能にします。ロギングプロファイルの設定は、メインの logging サブシステムとほぼ同じです。

11.3.1. ルートロガー

JBoss EAP のルートロガーは、ログカテゴリーによってキャプチャーされないサーバーへ送信されたすべてのログメッセージ (指定のログレベル以上) をキャプチャーします。

デフォルトでは、ルートロガーはコンソールおよび周期ログハンドラーを使用するように設定されます。周期ログハンドラーは、server.log ファイルへ書き込むよう設定されます。このファイルはサーバーログとも呼ばれます。

詳細は「ルートロガーの設定」を参照してください。

11.3.2. ログカテゴリー

ログカテゴリーは、キャプチャーするログメッセージのセットと、メッセージを処理する 1 つ以上のログハンドラーを定義します。

キャプチャーするログメッセージは、指定された元の Java パッケージとログレベルによって定義されます。そのパッケージのクラスおよびそのログレベル以上のメッセージがログカテゴリーによってキャプチャーされ、指定のログハンドラーに送信されます。

注記

通常、ログカテゴリーは Java パッケージとクラス名ですが、Logger.getLogger(LOGGER_NAME) メソッドによって指定された名前をすべて使用できます。

ログカテゴリーは、独自のハンドラーの代わりにルートロガーのログハンドラーを任意で使用することができます。

詳細は「ログカテゴリーの設定」を参照してください。

11.3.3. ログハンドラー

ログハンドラーはキャプチャーしたメッセージの記録方法を定義します。使用できるログハンドラーの種類は consolefileperiodicsizeperiodic sizesyslogcustom、および async です。

注記

ログハンドラーは、アクティブにするために少なくとも 1 つのロガーに追加する必要があります。

ログハンドラーの種類
Console
Console ログハンドラーは、ログメッセージをホストオペレーティングシステムの標準出力 (stdout) または標準エラー (stderr) ストリームに書き込みます。これらのメッセージは、JBoss EAP がコマンドラインプロンプトから実行された場合に表示されます。オペレーティングシステムで標準出力または標準エラーストリームをキャプチャーするように設定されていない限り、Console ログハンドラーからのメッセージは保存されません。
File
File ログハンドラーは、ログメッセージを指定のファイルに書き込みます。
Periodic
Periodic ログハンドラーは、指定した時間が経過するまで、ログメッセージを指定ファイルに書き込みます。その時間が経過した後、指定のタイムスタンプが追記されてファイルの名前が変更され、 ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。
Size
Size ログハンドラーは、指定したファイルが指定したサイズに達するまで、そのファイルにログメッセージを書き込みます。ファイルが指定したサイズに達すると、数値の接尾辞が付いて名前が変更され、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。各サイズログハンドラーは、この方式で保管されるファイルの最大数を指定する必要があります。
Periodic Size

Periodic Size ログハンドラーは、ファイルが指定のサイズに達するまで、または指定の期間が経過するまで、ログメッセージを名前の付いたファイルに書き込みます。その後、ファイルの名前が変更され、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。

これは Periodic と Size ログハンドラーの組み合わせで、組み合わされた属性をサポートします。

Syslog
syslog ハンドラーは、リモートのロギングサーバーへメッセージを送信するために使用できます。これにより、複数のアプリケーションが同じサーバーにログメッセージを送信でき、そのサーバーですべてのログメッセージを解析できます。
Socket
ソケットログハンドラーを使用して、ログメッセージをソケット上でリモートロギングサーバーに送信できます。ソケットは TCP または UDP ソケットになります。
Custom
カスタムログハンドラーにより、実装された新たなタイプのログハンドラーを設定することができます。カスタムハンドラーは、java.util.logging.Handler を拡張する Java クラスとして実装し、モジュール内に格納する必要があります。Log4J アペンダーをカスタムログハンドラーとして使用することもできます。
Async
Async ログハンドラーは、 単一または複数のログハンドラーを対象とする非同期動作を提供するラッパーログハンドラーです。Async ログハンドラーは、待ち時間が長かったり、ネットワークファイルシステムへのログファイルの書き込みなどにパフォーマンス上の問題があるログハンドラーに対して有用です。

各ログハンドラーの設定に関する詳細は、「ログハンドラーの設定」の項を参照してください。

11.3.4. ログレベル

ログレベルとは、ログメッセージの性質と重大度を示す列挙値です。特定のログメッセージのレベルは、そのメッセージを送信するために選択したロギングフレームワークの適切なメソッドを使用して開発者が指定できます。

JBoss EAP は、サポートされるアプリケーションロギングフレームワークによって使用されるすべてのログレベルをサポートします。最も一般的に使用されるログレベルは、ログレベルの低い順に TRACEDEBUGINFOWARNERROR および FATAL となります。

ログレベルはログカテゴリーとログハンドラーによって使用され、それらが担当するメッセージを限定します。各ログレベルには、他のログレベルに対して相対的な順番を示す数値が割り当てられています。ログカテゴリーとハンドラーにはログレベルが割り当てられ、そのレベル以上のログメッセージのみを処理します。たとえば、WARN レベルのログハンドラーは、WARNERROR、および FATAL のレベルのメッセージのみを記録します。

サポート対象のログレベル
ログのレベルValue説明

ALL

Integer.MIN_VALUE

すべてのログメッセージを提供します。

FINEST

300

-

FINER

400

-

TRACE

400

TRACE レベルのログメッセージは、実行中のアプリケーションの状態に関する詳細な情報を提供し、デバッグ時のみキャプチャーされます。

DEBUG

500

DEBUG レベルのログメッセージは、個々の要求またはアプリケーションアクティビティーの進捗状況を示し、通常はデバッグ時のみキャプチャーされます。

FINE

500

-

CONFIG

700

-

INFO

800

INFO レベルのログメッセージはアプリケーションの全体的な進捗状況を示します。多くの場合、アプリケーションの起動、シャットダウン、およびその他の主要なライフサイクルイベントに使用されます。

WARN

900

WARN レベルのログメッセージはエラーではないが、理想的とは見なされない状況を示します。WARN ログメッセージは将来エラーが発生する可能性のある状況を示すことがあります。

WARNING

900

-

ERROR

1000

ERROR レベルのログメッセージは、現在のアクティビティーや要求の完了を妨げる可能性があるが、アプリケーションの実行を妨げない発生済みエラーを示します。

SEVERE

1000

-

FATAL

1100

FATAL レベルのログメッセージは重大なサービス障害やアプリケーションのシャットダウンを引き起こしたり、JBoss EAP のシャットダウンを引き起こしたりする可能性があるイベントを示します。

OFF

Integer.MAX_VALUE

ログメッセージを表示しません。

注記

ALL は、最低ログレベルであり、すべてのログレベルのメッセージを含みます。ロギングの量は最も多くなります。

FATAL は、最大ログレベルであり、そのレベルのメッセージのみを含みます。ロギングの量は最も少なくなります。

11.3.5. ログフォーマッター

フォーマッターはログメッセージのフォーマットに使用されます。named-formatter 属性を使用するとフォーマッターをログハンドラーに割り当てできます。ログハンドラー設定の詳細は「ログハンドラーの設定」を参照してください。

logging サブシステムには 4 種類のフォーマッターが含まれます。

パターンフォーマッター

パターンフォーマッターは、ログメッセージをプレーンテキストでフォーマットするために使用されます。ログハンドラーの named-formatter 属性としてフォーマットを使用する他に、あらかじめフォーマッターリソースを作成する必要なく formatter 属性として使用することもできます。パターン構文に関する詳細は「パターンフォーマッターのフォーマット文字」を参照してください。

パターンフォーマッターの設定方法は「パターンフォーマッターの設定」を参照してください。

JSON フォーマッター

JSON フォーマッターは、ログメッセージを JSON 形式でフォーマットするために使用されます。

JSON フォーマッターの設定方法は「JSON フォーマッターの設定」を参照してください。

XML フォーマッター

XML ログフォーマッターは、ログメッセージを XML 形式でフォーマットするために使用されます。

XML フォーマッターの設定方法は「XML フォーマッターの設定」を参照してください。

カスタムフォーマッター

ハンドラーと使用するカスタムフォーマッターです。ほとんどのログレコードは printf 形式でフォーマットされることに注意してください。メッセージを適切にフォーマットするには、org.jboss.logmanager.ExtLogRecord#getFormattedMessage() の呼び出しが必要になることがあります。

カスタムログフォーマッターの設定方法は「カスタムログフォーマッターの設定」を参照してください。

11.3.6. フィルター式

フィルター式は filter-spec 属性を使用して設定され、さまざまな基準に基づいてログメッセージを記録するために使用されます。フィルターチェックは、常に未フォーマットの raw メッセージに対して行われます。ロガーまたはハンドラーのフィルターを含めることができますが、ハンドラーに配置されたフィルターよりもロガーフィルターが優先されます。

注記

ルートロガーに対して指定された filter-spec は他のロガーによって継承されません。ハンドラーごとに filter-spec を指定する必要があります。

表11.3 ロギングのフィルター式

フィルター式説明

accept

すべてのログメッセージを許可します。

deny

すべてのログメッセージを拒否します。

not[filter expression]

単一のフィルター式の逆の値を返します。例を以下に示します。

not(match("WFLY"))

all[filter expression]

フィルター式のカンマ区切りリストから連結された値を返します。例を以下に示します。

all(match("WFLY"),match("WELD"))

any[filter expression]

フィルター式のカンマ区切りリストから 1 つの値を返します。例を以下に示します。

any(match("WFLY"),match("WELD"))

levelChange[level]

指定のレベルでログレコードを更新します。例を以下に示します。

levelChange(WARN)

levels[levels]

レベルのカンマ区切りリストにあるレベルの 1 つでログメッセージをフィルターします。例を以下に示します。

levels(DEBUG,INFO,WARN,ERROR)

levelRange[minLevel,maxLevel]

指定されたレベル範囲内でログメッセージをフィルターします。[ および ] は、含まれるレベルを示すために使用されます。( および ) は除外されるレベルを示すために使用されます。例を以下に示します。

  • levelRange[INFO,ERROR]

    • 最小レベルは INFO 以上で、最大レベルは ERROR 以下でなければなりません。
  • levelRange[DEBUG,ERROR)

    • 最小レベルは DEBUG 以上で、最大レベルは ERROR 未満でなければなりません。

match["pattern"]

提供される正規表現を使用してログメッセージをフィルターします。例を以下に示します。

match("WFLY\d+")

substitute["pattern","replacement value"]

最初にパターン (最初の引数) と一致した値を代替テキスト (2 番目の引数) に置き換えるフィルター。例を以下に示します。

substitute("WFLY","EAP")

substituteAll["pattern","replacement value"]

パターン (最初の引数) と一致したすべての値を代替テキスト (2 番目の引数) に置き換えるフィルター。例を以下に示します。

substituteAll("WFLY","EAP")

注記

管理 CLI を使用してフィルター式を設定する場合、値が文字列として正しく処理されるよう、フィルターテキストのコンマと引用符を必ずエスケープしてください。コンマと引用符の前にバックスラッシュ (\) を付け、式全体を引用符で囲む必要があります。以下は substituteAll("WFLY","YLFW") を適切にエスケープした例になります。

/subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value="substituteAll(\"WFLY\"\,\"YLFW\")")

11.3.7. 暗黙的なロギングの依存関係

JBoss EAP の logging サブシステムはデフォルトで暗黙的なロギング API 依存関係をデプロイメントに追加します。add-logging-api-dependencies 属性を使用すると、この暗黙的な依存関係をデプロイメントに追加するかどうかを制御できます。 この属性はデフォルトでは true に設定されています。

管理 CLI を使用して add-logging-api-dependencies 属性を false に設定すると、暗黙的なロギング API 依存関係がデプロイメントに追加されないようになります。

/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)

logging サブシステムの暗黙的な依存関係については、JBoss EAP『開発ガイド』の「暗黙的なモジュール依存関係」の項を参照してください。

11.4. ログカテゴリーの設定

ここでは、管理 CLI を使用してログカテゴリーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして Categories を選択するとログカテゴリーを設定することができます。

ログカテゴリーを設定するために実行する主なタスクは次のとおりです。

重要

ロギングプロファイルにログカテゴリーを設定する場合、 コマンドの最初は/subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

ログカテゴリーの追加

ログカテゴリー名は、元の Java パッケージによって定義されます。ログレベルなどのその他の設定に準拠する限り、そのパッケージのクラスからのメッセージはキャプチャーされます。

/subsystem=logging/logger=LOG_CATEGORY:add

ログカテゴリーの設定

必要性に応じて、以下のログカテゴリー属性を 1 つ以上設定する必要がある場合があります。利用できるログカテゴリー属性の完全リストと説明は、「ログカテゴリーの属性」を参照してください。

  • ログレベルを設定します。

    ログカテゴリーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=level,value=LEVEL)
  • このカテゴリーがルートロガーのログハンドラーを使用するかどうかを設定します。

    デフォルトでは、ログカテゴリーは独自のハンドラーと、ルートロガーのハンドラーを使用します。ログカテゴリーが割り当てられたハンドラーのみを使用する必要がある場合は use-parent-handlers 属性を false に設定します。

    /subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=use-parent-handlers,value=USE_PARENT_HANDLERS)
  • フィルター式を設定します。

    ログカテゴリーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/logger=LOG_CATEGORY:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

ハンドラーの割り当て

ログハンドラーをログカテゴリーに割り当てます。

/subsystem=logging/logger=LOG_CATEGORY:add-handler(name=LOG_HANDLER_NAME)

ログカテゴリーの削除

ログカテゴリーは remove 操作で削除できます。

/subsystem=logging/logger=LOG_CATEGORY:remove

11.5. ログハンドラーの設定

ログハンドラーはキャプチャーしたメッセージの記録方法を定義します。以下の項を参照して必要なログハンドラーのタイプを設定してください。

11.5.1. Console ログハンドラーの設定

ここでは、管理 CLI を使用して Console ログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerConsole Handler と選択すると Console ログハンドラーを設定することができます。

Console ログハンドラーを設定するために実行する主なタスクは次のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

Console ログハンドラーの追加
/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:add
Console ログハンドラーの設定

必要性に応じて、以下の Console ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Console ログハンドラー属性の完全リストと説明は、「Console ログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • ターゲットを設定します。

    ハンドラーのターゲットを設定します。値は System.outSystem.errconsole のいずれかになります。デフォルト System.out です。

    /subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=target,value=TARGET)
  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • ログフォーマッターを設定します。

    ヘッダーの書式設定文字列を設定します。たとえば、デフォルトの書式設定文字列は %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n です。FORMAT の値は必ず引用符で囲んでください。

    /subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
    注記

    保存されたフォーマッター を参照する場合は named-formatter 属性を使用します。

  • 自動フラッシュを設定します。

    毎回書き込みの後に自動的にフラッシュするかどうかを設定します。デフォルト値は true です。

    /subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

Console ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Console ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=CONSOLE_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Console ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=CONSOLE_HANDLER_NAME)
Console ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:remove

11.5.2. File ログハンドラーの設定

ここでは、管理 CLI を使用して File ログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerFile Handler と選択すると、File ログハンドラーを設定することができます。

File ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

File ログハンドラーの追加

File ログハンドラーを追加する場合、path および relative-to 属性で構成される file 属性を使用してファイルパスを指定する必要があります。path 属性を使用して名前を含むログのファイルパスを設定します (例: my-log.log)。オプションで relative-to 属性を使用すると path が名前付きのパスと相対的になるよう設定できます (例: jboss.server.log.dir)。

/subsystem=logging/file-handler=FILE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH})
File ログハンドラーの設定

必要性に応じて、以下の File ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる File ログハンドラー属性の完全リストと説明は、「File ログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • 追加動作を設定します。

    デフォルトでは、サーバーが再起動されたときに JBoss EAP はログメッセージを同じファイルに追加します。サーバーの再起動時にファイルを上書きする場合は append 属性を false に設定します。

    /subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=append,value=APPEND)
  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • ログフォーマッターを設定します。

    ヘッダーの書式設定文字列を設定します。たとえば、デフォルトの書式設定文字列は %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n です。FORMAT の値は必ず引用符で囲んでください。

    /subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
    注記

    保存されたフォーマッター を参照する場合は named-formatter 属性を使用します。

  • 自動フラッシュを設定します。

    毎回書き込みの後に自動的にフラッシュするかどうかを設定します。デフォルト値は true です。

    /subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/file-handler=FILE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

File ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは File ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=FILE_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに File ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=FILE_HANDLER_NAME)
File ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/file-handler=FILE_HANDLER_NAME:remove

11.5.3. Periodic rotating ログハンドラーの設定

ここでは、管理 CLI を使用して Periodic rotating ログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerPeriodic Handler と選択すると、Periodic ログハンドラーを設定することができます。

Periodic ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

Periodic ログハンドラーの追加

Periodic ログハンドラーを追加する場合、 path および relative-to 属性で構成される file 属性を使用してファイルパスを指定する必要があります。path 属性を使用して名前を含むログのファイルパスを設定します (例: my-log.log)。オプションで relative-to 属性を使用すると path が名前付きのパスと相対的になるよう設定できます (例: jboss.server.log.dir)。

また、suffix 属性を使用してローテーションしたログの接尾辞を設定する必要もあります。これは、 .yyyy-MM-dd-HH のように java.text.SimpleDateFormat が認識できる形式でなければなりません。ローテーションの周期はこの接尾辞を基に自動的に算出されます。

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH},suffix=SUFFIX)
Periodic ログハンドラーの設定

必要性に応じて、以下の Periodic ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Periodic ログハンドラー属性の完全リストと説明は、「Periodic ログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • 追加動作を設定します。

    デフォルトでは、サーバーが再起動されたときに JBoss EAP はログメッセージを同じファイルに追加します。サーバーの再起動時にファイルを上書きする場合は append 属性を false に設定します。

    /subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=append,value=APPEND)
  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • ログフォーマッターを設定します。

    ヘッダーの書式設定文字列を設定します。たとえば、デフォルトの書式設定文字列は %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n です。FORMAT の値は必ず引用符で囲んでください。

    /subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
    注記

    保存されたフォーマッター を参照する場合は named-formatter 属性を使用します。

  • 自動フラッシュを設定します。

    毎回書き込みの後に自動的にフラッシュするかどうかを設定します。デフォルト値は true です。

    /subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

Periodic ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Periodic ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=PERIODIC_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Periodic ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=PERIODIC_HANDLER_NAME)
Periodic ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/periodic-rotating-file-handler=PERIODIC_HANDLER_NAME:remove

11.5.4. Size rotating ログハンドラーの設定

ここでは、管理 CLI を使用して Size rotating ログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerSize Handler と選択すると、Size ログハンドラーを設定することができます。

Size ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

Size ログハンドラーの追加

Size ログハンドラーを追加する場合、path および relative-to 属性で構成される file 属性を使用してファイルパスを指定する必要があります。path 属性を使用して名前を含むログのファイルパスを設定します (例: my-log.log)。オプションで relative-to 属性を使用すると path が名前付きのパスと相対的になるよう設定できます (例: jboss.server.log.dir)。

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH})
Size ログハンドラーの設定

必要性に応じて、以下の Size ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Size ログハンドラー属性の完全リストと説明は、「Size ログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • ローテーションされるログの接尾辞を設定します。

    接尾辞の文字列を設定します。これは yyyy-MM-dd-HH のように java.text.SimpleDateFormat が認識できる形式でなければなりません。ローテーションの周期はこの接尾辞を基に自動的に算出されます。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=suffix, value=SUFFIX)
  • ローテーションサイズを設定します。

    ファイルの最大サイズを設定します。この値を超えるとファイルがローテーションされます。デフォルトは 2 メガバイトを意味する 2m です。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=rotate-size, value=ROTATE_SIZE)
  • 保持するバックアップログの最大数の設定

    保持するバックアップの数を設定します。デフォルト値は 1 です。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=max-backup-index, value=MAX_BACKUPS)
  • 起動時にログをローテーションするかどうかを設定します。

    デフォルトでは、サーバーの再起動時に新しいログファイルは作成されません。サーバーの再起動時にログをローテーションするには、true に設定します。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=rotate-on-boot, value=ROTATE_ON_BOOT)
  • 追加動作を設定します。

    デフォルトでは、サーバーが再起動されたときに JBoss EAP はログメッセージを同じファイルに追加します。サーバーの再起動時にファイルを上書きする場合は append 属性を false に設定します。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=append,value=APPEND)
  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • ログフォーマッターを設定します。

    ヘッダーの書式設定文字列を設定します。たとえば、デフォルトの書式設定文字列は %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n です。FORMAT の値は必ず引用符で囲んでください。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
    注記

    保存されたフォーマッター を参照する場合は named-formatter 属性を使用します。

  • 自動フラッシュを設定します。

    毎回書き込みの後に自動的にフラッシュするかどうかを設定します。デフォルト値は true です。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

Size ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Size ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=SIZE_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Size ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=SIZE_HANDLER_NAME)
Size ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/size-rotating-file-handler=SIZE_HANDLER_NAME:remove

11.5.5. Periodic Size rotating ログハンドラーの設定

ここでは、管理 CLI を使用して Periodic Size rotating ログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerPeriodic Size Handler と選択すると、Periodic Size ログハンドラーを設定することができます。

Periodic Size ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

Periodic Size ログハンドラーの追加

Periodic Size ログハンドラーを追加する場合、 path および relative-to 属性で構成される file 属性を使用してファイルパスを指定する必要があります。path 属性を使用して名前を含むログのファイルパスを設定します (例: my-log.log)。オプションで relative-to 属性を使用すると path が名前付きのパスと相対的になるよう設定できます (例: jboss.server.log.dir)。

また、suffix 属性を使用してローテーションしたログの接尾辞を設定する必要もあります。これは、 .yyyy-MM-dd-HH のように java.text.SimpleDateFormat が認識できる形式でなければなりません。ローテーションの周期はこの接尾辞を基に自動的に算出されます。

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:add(file={path=FILE_PATH,relative-to=RELATIVE_TO_PATH},suffix=SUFFIX)
Periodic Size ログハンドラーの設定

必要性に応じて、以下の Periodic Size ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Periodic Size ログハンドラー属性の完全リストと説明は、「Periodic Size ログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • ローテーションサイズを設定します。

    ファイルの最大サイズを設定します。この値を超えるとファイルがローテーションされます。デフォルトは 2 メガバイトを意味する 2m です。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=rotate-size, value=ROTATE_SIZE)
  • 保持するバックアップログの最大数の設定

    保持するバックアップの数を設定します。デフォルト値は 1 です。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=max-backup-index, value=MAX_BACKUPS)
  • 起動時にログをローテーションするかどうかを設定します。

    デフォルトでは、サーバーの再起動時に新しいログファイルは作成されません。サーバーの再起動時にログをローテーションするには、true に設定します。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=rotate-on-boot, value=ROTATE_ON_BOOT)
  • 追加動作を設定します。

    デフォルトでは、サーバーが再起動されたときに JBoss EAP はログメッセージを同じファイルに追加します。サーバーの再起動時にファイルを上書きする場合は append 属性を false に設定します。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=append,value=APPEND)
  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • ログフォーマッターを設定します。

    ヘッダーの書式設定文字列を設定します。たとえば、デフォルトの書式設定文字列は %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n です。FORMAT の値は必ず引用符で囲んでください。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
    注記

    保存されたフォーマッター を参照する場合は named-formatter 属性を使用します。

  • 自動フラッシュを設定します。

    毎回書き込みの後に自動的にフラッシュするかどうかを設定します。デフォルト値は true です。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

Periodic Size ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Periodic Size ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=PERIODIC_SIZE_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Periodic Size ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=PERIODIC_SIZE_HANDLER_NAME)
Periodic Size ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE_HANDLER_NAME:remove

11.5.6. Syslog ハンドラーの設定

ここでは、管理 CLI を使用して Syslog ハンドラーを設定する方法を説明します。Syslog ハンドラーを使用すると、Syslog プロトコル (RFC-3164 または RFC-5424) をサポートするリモートロギングサーバーにメッセージを送信できます。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerSyslog Handler と選択すると、Syslog ハンドラーを設定することができます。

Syslog ハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

Syslog ハンドラーの追加
/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:add
Syslog ハンドラーの設定

必要性に応じて、以下の Syslog ハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Syslog ハンドラー属性の完全リストと説明は、「Syslog ハンドラーの属性」を参照してください。

  • ハンドラーのログレベルを設定します。デフォルトのレベルは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • ログに記録するアプリケーションの名前を設定します。デフォルトの名前は java です。

    /subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=app-name,value=APP_NAME)
  • Syslog サーバーのアドレスを設定します。デフォルトのアドレスは localhost です。

    /subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=server-address,value=SERVER_ADDRESS)
  • syslog サーバーのポートを設定します。デフォルトのポートは 514 です。

    /subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=port,value=PORT)
  • RFC 仕様の定義どおりに syslog 形式を設定します。デフォルトの形式は RFC5424 です。

    /subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=syslog-format,value=SYSLOG_FORMAT)
  • syslog ペイロードのメッセージをフォーマットするために named-formatter 属性を指定します。

    /subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:write-attribute(name=named-formatter, value=FORMATTER_NAME)
Syslog ハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Syslog ハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=SYSLOG_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Syslog ハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=SYSLOG_HANDLER_NAME)
Syslog ハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:remove

11.5.7. Socket ログハンドラーの設定

ここでは、管理 CLI を使用して Socket ログハンドラーを設定する方法を説明します。ソケットは TCP または UDP ソケットになります。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerSize Handler と選択すると、Size ログハンドラーの設定も可能になります。

注記

サーバーが管理者専用モードで起動された場合、ログメッセージは破棄されます。

Socket ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

ソケットバインディングの追加

remote-destination-outbound-socket-binding または local-destination-outbound-socket-binding を使用する ソケットバインディング として定義します。

/socket-binding-group=SOCKET_BINDING_GROUP/remote-destination-outbound-socket-binding=SOCKET_BINDING_NAME:add(host=HOST, port=PORT)
ログフォーマッターの設定

JSON フォーマッターなど、使用する ログフォーマッター を定義します。

/subsystem=logging/json-formatter=FORMATTER:add
Socket ログハンドラーの追加

Socket ログハンドラーを追加する場合、使用するソケットバインディングとフォーマッターを指定する必要があります。

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:add(outbound-socket-binding-ref=SOCKET_BINDING_NAME,named-formatter=FORMATTER)
Socket ログハンドラーの設定

必要性に応じて、以下の Socket ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Socket ログハンドラー属性の完全リストと説明は、「Socket ログハンドラーの属性」を参照してください。

  • プロトコルを設定します。

    使用するプロトコルを設定します。デフォルトは TCP です。

    /subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=protocol,value=PROTOCOL)
  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
    注記

    サーバーの起動中、Socket ログハンドラーによって処理されるログメッセージは、ソケットバインディングが設定され、logging サブシステムが初期化されるまでキューに置かれます。ログレベルが TRACEDEBUG などの低レベルに設定されている場合、起動時に大量のメモリーが消費されることがあります。

  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • 自動フラッシュを設定します。

    毎回書き込みの後に自動的にフラッシュするかどうかを設定します。デフォルト値は true です。

    /subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=autoflush,value=AUTO_FLUSH)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

Socket ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Socket ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=SOCKET_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Socket ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=SOCKET_HANDLER_NAME)
Socket ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/socket-handler=SOCKET_HANDLER_NAME:remove
SSL/TLS を使用したソケット上でのログメッセージの送信

次の手順は、SSL_TCP プロトコルを使用してソケット上でログメッセージを送信するように Socket ログハンドラーを設定する方法の例を示しています。この例では、Socket ログハンドラーによって使用される elytron サブシステムのキーストア、トラストマネージャー、およびクライアント SSL コンテキストを設定します。ルートロガーからのログメッセージは指定のソケット上で送信され、JSON フォーマッターによってフォーマットされます。

Elytron コンポーネントの設定に関する詳細は、JBoss EAP『How to Configure Server Security』の「Elytron Subsystem」を参照してください。

  1. Elytron を設定します。

    1. キーストアを追加します。

      /subsystem=elytron/key-store=log-server-ks:add(path=/path/to/keystore.jks, type=JKS, credential-reference={clear-text=mypassword})
    2. トラストマネージャーを追加します。

      /subsystem=elytron/trust-manager=log-server-tm:add(key-store=log-server-ks)
    3. クライアント SSL コンテキストを追加します。

      /subsystem=elytron/client-ssl-context=log-server-context:add(trust-manager=log-server-tm, protocols=["TLSv1.2"])
  2. ソケットバインディングを追加します。

    /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=log-server:add(host=localhost, port=4560)
  3. JSON フォーマッターを追加します。

    /subsystem=logging/json-formatter=json:add
  4. Socket ログハンドラーを追加します。

    /subsystem=logging/socket-handler=log-server-handler:add(named-formatter=json, level=INFO, outbound-socket-binding-ref=log-server, protocol=SSL_TCP, ssl-context=log-server-context)
  5. ログハンドラーをルートロガーに割り当てます。

    /subsystem=logging/root-logger=ROOT:add-handler(name=log-server-handler)

11.5.8. カスタムログハンドラーの設定

ここでは、管理 CLI を使用してカスタムログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerCustom Handler と選択すると、カスタムログハンドラーを設定することができます。

カスタムログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

カスタムログハンドラーの追加

カスタムログハンドラーを追加する場合、ハンドラーの Java クラスとハンドラーが含まれる JBoss EAP モジュールを指定する必要があります。クラスは java.util.logging.Handler を拡張する必要があります。

注記

すでに、カスタムロガーが含まれるモジュールが作成 されている必要があります。 作成されていないと、このコマンドの実行に失敗します。

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:add(class=CLASS_NAME,module=MODULE_NAME)
カスタムログハンドラーの設定

必要性に応じて、以下のカスタムログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できるカスタムログハンドラー属性の完全リストと説明は、「カスタムログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • プロパティーを設定します。

    ログハンドラーに必要なプロパティーを設定します。setter メソッドを使用してプロパティーにアクセスできなければなりません。

    /subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)
  • エンコーディングを設定します。

    ハンドラーのエンコーディングを設定します (例: utf-8)。

    /subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=encoding,value=ENCODING)
  • ログフォーマッターを設定します。

    ヘッダーの書式設定文字列を設定します。たとえば、デフォルトの書式設定文字列は %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n です。FORMAT の値は必ず引用符で囲んでください。

    /subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=formatter,value=FORMAT)
    注記

    保存されたフォーマッター を参照する場合は named-formatter 属性を使用します。

  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

カスタムログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは、カスタムログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=CUSTOM_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Size ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=CUSTOM_HANDLER_NAME)
カスタムログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーまたは Async ログハンドラーに割り当てられている場合は削除できません。

/subsystem=logging/custom-handler=CUSTOM_HANDLER_NAME:remove

11.5.9. Async ログハンドラーの設定

ここでは、管理 CLI を使用して Async ログハンドラーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして HandlerAsync Handler と選択すると、Async ログハンドラーを設定することができます。

Async ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

Async ログハンドラーの追加

Async ログハンドラーを追加するときにキューの長さを指定する必要があります。これは、キューに保持できるログリクエストの最大数のことです。

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:add(queue-length=QUEUE_LENGTH)
サブハンドラーの追加

1 つ以上のハンドラーを Async ログハンドラーのサブハンドラーとして追加できます。ハンドラーが設定に存在しないと、このコマンドの実行に失敗するため注意してください。

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:add-handler(name=HANDLER_NAME)
Async ログハンドラーの設定

必要性に応じて、以下の Async ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Async ログハンドラー属性の完全リストと説明は、「Async ログハンドラーの属性」を参照してください。

  • ログレベルを設定します。

    ハンドラーの適切なログレベルを設定します。デフォルトは ALL です。利用できるオプションは、「ログレベル」を参照してください。

    /subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=level,value=LEVEL)
  • オーバーフローアクションを設定します。

    オーバーフローが発生したときに行うアクションを設定します。デフォルトの値は BLOCK で、キューが満杯になるとスレッドがブロックされます。この値を DISCARD に変更すると、キューが満杯になったときにログメッセージが破棄されます。

    /subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=overflow-action,value=OVERFLOW_ACTION)
  • フィルター式を設定します。

    ハンドラーのログメッセージをフィルターするために式を設定します。必ずコンマと引用符はエスケープ処理し、引用符で囲むようにしてください。たとえば、以下の置換可能な FILTER_EXPRESSION 変数では、not(match("WFLY")) のフィルター式を "not(match(\"WFLY\"))" に置き換える必要があります。

    /subsystem=logging/async-handler=ASYNC_HANDLER_NAME:write-attribute(name=filter-spec, value=FILTER_EXPRESSION)

    利用可能なフィルター式の詳細は「フィルター式」の項を参照してください。

Async ログハンドラーのロガーへの割り当て

ログハンドラーをアクティブにするには、ロガーに割り当てる必要があります。

以下の管理 CLI コマンドは Async ログハンドラーをルートロガーに割り当てます。

/subsystem=logging/root-logger=ROOT:add-handler(name=ASYNC_HANDLER_NAME)

以下の管理 CLI コマンドは、名前が CATEGORY によって指定されるロガーに Async ログハンドラーを割り当てます。

/subsystem=logging/logger=CATEGORY:add-handler(name=ASYNC_HANDLER_NAME)
Async ログハンドラーの削除

ログハンドラーは remove 操作で削除できます。ログハンドラーが現在ロガーに割り当てられている場合は削除できません。

/subsystem=logging/async-handler=ASYNC_HANDLER_NAME:remove

11.6. ルートロガーの設定

ルートロガーは、ログカテゴリーによってキャプチャーされないサーバーへ送信されたすべてのログメッセージ (指定のログレベル以上) をキャプチャーします。

ここでは、管理 CLI を使用してルートロガーを設定する方法を説明します。管理コンソールでは、ConfigurationSubsystemsLoggingConfiguration と選択し、表示 をクリックして Root Logger を選択すると、ルートロガーを設定することができます。

ルートロガーの設定

重要

ロギングプロファイルにこのログハンドラーを設定する場合、コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

  1. ログハンドラーをルートロガーへ割り当てます。

    ログハンドラーを追加します。

    /subsystem=logging/root-logger=ROOT:add-handler(name=LOG_HANDLER_NAME)

    ログハンドラーの削除

    /subsystem=logging/root-logger=ROOT:remove-handler(name=LOG_HANDLER_NAME)
  2. ログレベルを設定します。

    /subsystem=logging/root-logger=ROOT:write-attribute(name=level,value=LEVEL)

使用できるルートロガー属性とその説明の完全リストは、「ルートロガーの属性」を参照してください。

11.7. ログフォーマッターの設定

ログフォーマッターはハンドラーでのログメッセージの形式を定義します。logging サブシステムでは以下のログフォーマッターを設定できます。

11.7.1. パターンフォーマッターの設定

ログハンドラーすべてで使用できる名前付きパターンフォーマッターを作成して、ログメッセージをフォーマットすることができます。

重要

ロギングプロファイルにこのログフォーマッターを設定する場合、 コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

パターンフォーマッターの作成

パターンフォーマッターを定義するとき、ログメッセージのフォーマットに使用するパターン文字列を指定します。パターン構文の詳細は、「パターンフォーマッターのフォーマット文字」を参照してください。

/subsystem=logging/pattern-formatter=PATTERN_FORMATTER_NAME:add(pattern=PATTERN)

たとえば、デフォルトの設定はサーバーログへのロギングメッセージのログフォーマッター文字列として %d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n を使用します。これにより、以下のようにフォーマットされるログメッセージが作成されます。

2016-03-18 15:49:32,075 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990

また、カラーマップを定義してログレベルごとに色を割り当てることもできます。形式は LEVEL:COLOR のカンマ区切りリストです。

  • 有効なレベル: finestfinerfineconfigtracedebuginfowarningwarnerrorfatalsevere
  • 有効な色: blackgreenredyellowbluemagentacyanwhitebrightblackbrightredbrightgreenbrightbluebrightyellowbrightmagentabrightcyanbrightwhite
/subsystem=logging/pattern-formatter=PATTERN_FORMATTER_NAME:write-attribute(name=color-map,value="LEVEL:COLOR,LEVEL:COLOR")

管理コンソールを使用してパターンログフォーマッターを設定することもできます。

  1. ブラウザーで管理コンソールを開きます。
  2. ConfigurationSubsystemsLogging と選択します。
  3. Configuration を選択し、表示 をクリックします。
  4. Formatter を選択し、Pattern Formatter オプションを選択します。

11.7.2. カスタムログフォーマッターの設定

JSON 形式でログメッセージをフォーマットする JSON ログフォーマッターを作成できます。

重要

ロギングプロファイルにこのログフォーマッターを設定する場合、 コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

JSON ログフォーマッターの追加
/subsystem=logging/json-formatter=JSON_FORMATTER_NAME:add(pretty-print=true, exception-output-type=formatted)

これにより、以下のようにフォーマットされるログメッセージが作成されます。

{
    "timestamp": "2018-10-18T13:53:43.031-04:00",
    "sequence": 62,
    "loggerClassName": "org.jboss.as.server.logging.ServerLogger_$logger",
    "loggerName": "org.jboss.as",
    "level": "INFO",
    "message": "WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.0.0.Final-redhat-20190924) started in 5672ms - Started 495 of 679 services (331 services are lazy, passive or on-demand)",
    "threadName": "Controller Boot Thread",
    "threadId": 22,
    "mdc": {
    },
    "ndc": "",
    "hostName": "localhost.localdomain",
    "processName": "jboss-modules.jar",
    "processId": 7461
}
Logstash JSON ログフォーマッターの追加の追加
/subsystem=logging/json-formatter=logstash:add(exception-output-type=formatted, key-overrides=[timestamp="@timestamp"], meta-data=[@version=1])

JSON フォーマッター属性は以下の説明どおりに使用できます。

  • key-overrides 属性は、定義されたキーの名前をオーバーライドするために使用できます。
  • exception-output-type 属性を formatted に設定すると、例外をオブジェクトとしてフォーマットできます。
  • exception-output-type 属性を detailed に設定すると、例外スタックトレースを含めることができます。
  • exception-output-type 属性を detailed-and-formatted に設定すると、例外をオブジェクトとしてフォーマットし、スタックトレースを含めることができます。
  • meta-data 属性を使用すると、メタデータをログレコードに追加できます。

JSON フォーマッター属性の詳細は「JSON ログフォーマッター属性」を参照してください。

管理コンソールを使用して JSON ログフォーマッターを設定することもできます。

  1. ブラウザーで管理コンソールを開きます。
  2. ConfigurationSubsystemsLogging と選択します。
  3. Configuration を選択し、表示 をクリックします。
  4. Formatter を選択し、JSON Formatter オプションを選択します。

11.7.3. XML ログフォーマッターの設定

XML 形式でログメッセージをフォーマットする XML ログフォーマッターを作成できます。

重要

ロギングプロファイルにこのログフォーマッターを設定する場合、 コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

XML ログフォーマッターの追加
/subsystem=logging/xml-formatter=XML_FORMATTER_NAME:add(pretty-print=true, exception-output-type=detailed-and-formatted)

これにより、以下のようにフォーマットされるログメッセージが作成されます。

<record>
    <timestamp>2018-10-18T13:55:53.419-04:00</timestamp>
    <sequence>62</sequence>
    <loggerClassName>org.jboss.as.server.logging.ServerLogger_$logger</loggerClassName>
    <loggerName>org.jboss.as</loggerName>
    <level>INFO</level>
    <message>WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.0.0.Final-redhat-20190924) started in 6271ms - Started 495 of 679 services (331 services are lazy, passive or on-demand)</message>
    <threadName>Controller Boot Thread</threadName>
    <threadId>22</threadId>
    <mdc>
    </mdc>
    <ndc></ndc>
    <hostName>localhost.localdomain</hostName>
    <processName>jboss-modules.jar</processName>
    <processId>7790</processId>
</record>
キーオーバーライド XML ログフォーマッターの追加
/subsystem=logging/xml-formatter=XML_FORMATTER_NAME:add(pretty-print=true, print-namespace=true, namespace-uri="urn:custom:1.0", key-overrides={message=msg, record=logRecord, timestamp=date}, print-details=true)

XML フォーマッター属性は以下の説明どおりに使用できます。

  • key-overrides 属性は、定義されたキーの名前をオーバーライドするために使用できます。
  • exception-output-type 属性を formatted に設定すると、例外をオブジェクトとしてフォーマットできます。
  • exception-output-type 属性を detailed に設定すると、例外スタックトレースを含めることができます。
  • exception-output-type 属性を detailed-and-formatted に設定すると、例外をオブジェクトとしてフォーマットし、スタックトレースを含めることができます。
  • meta-data 属性を使用すると、メタデータをログレコードに追加できます。

XML フォーマッター属性の詳細は「XML ログフォーマッター属性」を参照してください。

管理コンソールを使用して XML ログフォーマッターを設定することもできます。

  1. ブラウザーで管理コンソールを開きます。
  2. ConfigurationSubsystemsLogging と選択します。
  3. Configuration を選択し、表示 をクリックします。
  4. Formatter を選択し、XML Formatter オプションを選択します。

11.7.4. カスタムログフォーマッターの設定

ログハンドラーすべてで使用できるカスタムログフォーマッターを作成して、ログメッセージをフォーマットすることができます。

ここでは、管理 CLI を使用してカスタムログフォーマッターを設定する方法を説明します。

カスタムログフォーマッターの設定
重要

ロギングプロファイルにこのログフォーマッターを設定する場合、 コマンドの最初は /subsystem=logging/ ではなく /subsystem=logging/logging-profile=LOGGING_PROFILE_NAME/ になります。

さらに、管理対象ドメインで実行している場合はコマンドの前に /profile=PROFILE_NAME を付けます。

  1. カスタムログフォーマッターを追加します。

    カスタムログフォーマッターを追加する場合、フォーマッターの Java クラスとフォーマッターが含まれる JBoss EAP モジュールを指定する必要があります。クラスは java.util.logging.Formatter を拡張する必要があります。

    注記

    すでに、カスタムフォーマッターが含まれるモジュールが作成されている必要があります。 作成されていないと、このコマンドの実行に失敗します。

    /subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:add(class=CLASS_NAME, module=MODULE_NAME)
  2. ログフォーマッターに必要なプロパティーを設定します。

    setter メソッドを使用してプロパティーにアクセスできなければなりません。

    /subsystem=logging/custom-formatter=CUSTOM_FORMATTER_NAME:write-attribute(name=properties.PROPERTY_NAME,value=PROPERTY_VALUE)
  3. カスタムフォーマッターをログハンドラーに割り当てます。

    以下の管理 CLI コマンドは、Periodic Rotating ファイルハンドラーによって使用されるカスタムフォーマッターを割り当てます。

    /subsystem=logging/periodic-rotating-file-handler=FILE_HANDLER_NAME:write-attribute(name=named-formatter, value=CUSTOM_FORMATTER_NAME)
カスタム XML フォーマッターの例

以下の例は、カスタム XML フォーマッターを設定します。org.jboss.logmanager モジュールに提供される java.util.logging.XMLFormatter クラスを使用し、Console ログハンドラーに割り当てます。

/subsystem=logging/custom-formatter=custom-xml-formatter:add(class=java.util.logging.XMLFormatter, module=org.jboss.logmanager)
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=named-formatter, value=custom-xml-formatter)

このフォーマッターを使用するログメッセージは以下のようにフォーマットされます。

<record>
  <date>2016-03-23T12:58:13</date>
  <millis>1458752293091</millis>
  <sequence>93963</sequence>
  <logger>org.jboss.as</logger>
  <level>INFO</level>
  <class>org.jboss.as.server.BootstrapListener</class>
  <method>logAdminConsole</method>
  <thread>22</thread>
  <message>WFLYSRV0051: Admin console listening on http://%s:%d</message>
  <param>127.0.0.1</param>
  <param>9990</param>
</record>
管理コンソールを使用したカスタムログフォーマッターの設定

管理コンソールを使用してカスタムログフォーマッターを設定することもできます。

  1. ブラウザーで管理コンソールを開きます。
  2. ConfigurationSubsystemsLogging と選択します。
  3. Configuration を選択し、表示 をクリックします。
  4. Formatter を選択し、Custom Formatter オプションを選択します。

11.8. アプリケーションのロギング

アプリケーションのロギングは、JBoss EAP の logging サブシステムを使用するか、デプロイメントごとに設定できます。

ログメッセージの取得に JBoss EAP ログカテゴリーおよびハンドラーを使用する方法は「Logging サブシステム」を参照してください。

サポートされるアプリケーションロギングフレームワークやデプロイメントごとのロギング設定など、アプリケーションロギングの詳細は JBoss EAP『開発ガイド』の「ロギング」の章を参照してください。

11.8.1. デプロイメントごとのロギング

デプロイメントごとのロギングを使用すると、開発者はアプリケーションのロギング設定を事前に設定できます。アプリケーションがデプロイされると、定義された設定に従ってロギングが開始されます。この設定によって作成されたログファイルにはアプリケーションの動作に関する情報のみが含まれます。

注記

デプロイメントごとのロギング設定が行われない場合、すべてのアプリケーションとサーバーには logging サブシステムの設定が使用されます。

この方法では、システム全体のロギングを使用する利点と欠点があります。利点は、JBoss EAP インスタンスの管理者がサーバーロギング以外のロギングを設定する必要がないことです。欠点は、デプロイメントごとのロギング設定はサーバーの起動時に読み取り専用であるため、実行時に変更できないことです。

アプリケーションでデプロイメントごとのロギングを使用する手順については、JBoss EAP『開発ガイド』の「デプロイメントごとのロギングをアプリケーションに追加」を参照してください。

11.8.1.1. デプロイメントごとのロギングの無効化

以下の方法の 1 つを使用するとデプロイメントごとのロギングを無効にできます。

  • use-deployment-logging-config 属性を false に設定します。

    use-deployment-logging-config 属性は、デプロイメントがデプロイメントごとにロギングに対してスキャンされるかどうかを制御します。デフォルトは true です。デプロイメントごとのロギングを無効にするにはこの属性を false に設定します。

    /subsystem=logging:write-attribute(name=use-deployment-logging-config,value=false)
  • jboss-deployment-structure.xml ファイルを使用して logging サブシステムを除外します。

    手順については、JBoss EAP『開発ガイド』の「サブシステムをデプロイメントから除外」を参照してください。

11.8.2. ロギングプロファイル

ロギングプロファイルは、デプロイされたアプリケーションに割り当てることができる独立したロギング設定のセットです。通常の logging サブシステム同様にロギングプロファイルはハンドラー、カテゴリー、およびルートロガーを定義できますが、他のプロファイルや主要な logging サブシステムを参照できません。設定が容易である点でロギングプロファイルは logging サブシステムと似ています。

ロギングプロファイルを使用すると、管理者は他のロギング設定に影響を与えずに 1 つ以上のアプリケーションに固有するロギング設定を作成することができます。各プロファイルはサーバー設定で定義されるため、ロギング設定を変更しても影響を受けるアプリケーションを再デプロイする必要はありません。

各ロギングプロファイルには以下の項目を設定できます。

  • 一意な名前。この値は必須です。
  • 任意の数のログハンドラー。
  • 任意の数のログカテゴリー。
  • 最大 1 つのルートロガー。

アプリケーションでは Logging-Profile 属性を使用して、MANIFEST.MF ファイルで使用するロギングプロファイルを指定できます。

11.8.2.1. ロギングプロファイルの設定

ロギングプロファイルは、ログハンドラー、カテゴリー、およびルートロガーで設定できます。ロギングプロファイルの設定には、logging サブシステムの設定と同じ構文を使用しますが、以下の点が異なります。

  • ルート設定パスが /subsystem=logging/logging-profile=NAME になります。
  • ロギングプロファイルに他のロギングプロファイルを追加できません。
  • logging サブシステムには、ロギングプロファイルに使用できない以下の属性があります。

    • add-logging-api-dependencies
    • use-deployment-logging-config
ロギングプロファイルの作成および設定

以下の手順では、管理 CLI を使用してロギングプロファイルを作成し、ファイルハンドラーとロガーカテゴリーを設定します。管理コンソールでは ConfigurationSubsystemsLoggingLogging Profiles と選択するとロギングプロファイルを設定することができます。

  1. ロギングプロファイルを作成します。

    /subsystem=logging/logging-profile=PROFILE_NAME:add
  2. ファイルハンドラーを作成します。

    /subsystem=logging/logging-profile=PROFILE_NAME/file-handler=FILE_HANDLER_NAME:add(file={path=>"LOG_NAME.log", "relative-to"=>"jboss.server.log.dir"})
    /subsystem=logging/logging-profile=PROFILE_NAME/file-handler=FILE_HANDLER_NAME:write-attribute(name="level", value="DEBUG")

    ファイルハンドラー属性の一覧は、「File ログハンドラーの属性 」を参照してください。

  3. ロガーカテゴリーを作成します。

    /subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add(level=TRACE)

    ログカテゴリー属性のリストは、「ログカテゴリーの属性」を参照してください。

  4. ファイルハンドラーをカテゴリーに割り当てます。

    /subsystem=logging/logging-profile=PROFILE_NAME/logger=CATEGORY_NAME:add-handler(name="FILE_HANDLER_NAME")

この後、アプリケーションによって使用されるロギングプロファイルを MANIFEST.MF ファイルに設定できます。詳細は、JBoss EAP『開発ガイド』の「アプリケーションでのロギングプロファイルの指定」を参照してください。

11.8.2.2. ロギングプロファイル設定の例

この例は、ロギングプロファイルとそれを使用するアプリケーションの設定を表しています。管理 CLI コマンド、結果となる XML、およびアプリケーションの MANIFEST.MF が示されています。

ロギングプロファイルの例には次のような特徴があります。

  • 名前は accounts-app-profile です。
  • ログカテゴリーは com.company.accounts.ejbs です。
  • ログレベルは TRACE です。
  • ログハンドラーは、ejb-trace.log ファイルを使用するファイルハンドラーです。

管理 CLI セッション

/subsystem=logging/logging-profile=accounts-app-profile:add

/subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:add(file={path=>"ejb-trace.log", "relative-to"=>"jboss.server.log.dir"})

/subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:write-attribute(name="level", value="DEBUG")

/subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add(level=TRACE)

/subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add-handler(name="ejb-trace-file")

XML 設定

<logging-profiles>
   <logging-profile name="accounts-app-profile">
      <file-handler name="ejb-trace-file">
         <level name="DEBUG"/>
         <file relative-to="jboss.server.log.dir" path="ejb-trace.log"/>
      </file-handler>
      <logger category="com.company.accounts.ejbs">
         <level name="TRACE"/>
         <handlers>
            <handler name="ejb-trace-file"/>
         </handlers>
      </logger>
   </logging-profile>
</logging-profiles>

アプリケーションの MANIFEST.MF ファイル

Manifest-Version: 1.0
Logging-Profile: accounts-app-profile

11.8.3. デプロイメントロギング設定の表示

以下の管理 CLI コマンドを使用すると、特定のデプロイメントのロギング設定に関する情報を取得できます。

/deployment=DEPLOYMENT_NAME/subsystem=logging/configuration=CONFIG:read-resource

デプロイメントのロギング設定値である CONFIG には、以下の 3 つの値の 1 つを指定します。

  • デプロイメントが logging サブシステムを使用する場合は default を指定します。これにより、logging サブシステムの設定が出力されます。
  • デプロイメントが logging サブシステムに定義されている ロギングプロファイル を使用する場合は、profile-PROFILE_NAME を指定します。これにより、ロギングプロファイルの設定が出力されます。
  • 使用される設定ファイルへのパス (例: myear.ear/META-INF/logging.properties) を指定します。

たとえば、以下の管理 CLI コマンドは、特定のデプロイメントによって使用される MYPROFILE ロギングプロファイルの設定を表示します。

/deployment=mydeployment.war/subsystem=logging/configuration=profile-MYPROFILE:read-resource(recursive=true,include-runtime=true)

以下の情報が出力されます。

{
    "outcome" => "success",
    "result" => {
        "error-manager" => undefined,
        "filter" => undefined,
        "formatter" => {
            "MYFORMATTER" => {
                "class-name" => "org.jboss.logmanager.formatters.PatternFormatter",
                "module" => undefined,
                "properties" => {"pattern" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"}
            }
        },
        "handler" => {
            "MYPERIODIC" => {
                "class-name" => "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler",
                "encoding" => undefined,
                "error-manager" => undefined,
                "filter" => undefined,
                "formatter" => "MYFORMATTER",
                "handlers" => [],
                "level" => "ALL",
                "module" => undefined,
                "properties" => {
                    "append" => "true",
                    "autoFlush" => "true",
                    "enabled" => "true",
                    "suffix" => ".yyyy-MM-dd",
                    "fileName" => "EAP_HOME/standalone/log/deployment.log"
                }
            }
        },
        "logger" => {"MYCATEGORY" => {
            "filter" => undefined,
            "handlers" => [],
            "level" => "DEBUG",
            "use-parent-handlers" => true
        }},
        "pojo" => undefined
    }
}

また、再帰的な read-resource 操作を使用して、ロギング設定やデプロイメントに関する他の情報を取得することができます。

/deployment=DEPLOYMENT_NAME/subsystem=logging:read-resource(include-runtime=true, recursive=true)

11.9. Logging サブシステムの調整

logging サブシステムのパフォーマンスを監視および最適化するための情報は、『パフォーマンスチューニングガイド』の「Logging サブシステムの調整」の項を参照してください。

第12章 データソース管理

12.1. JBoss EAP データソース

JDBC

JDBC API は、Java アプリケーションがデータベースにアクセスする方法を定義する基準です。アプリケーションは JDBC ドライバーを参照するデータソースを設定します。その後、データベースではなくドライバーに対してアプリケーションを記述できます。ドライバーはコードをデータベース言語に変換します。そのため、適切なドライバーがインストールされていればアプリケーションをサポートされるデータベースで使用できます。

詳細は JDBC 4.0 の仕様を参照してください。

サポートされているデータベース

JBoss EAP 7 によってサポートされる JDBC 対応データベースのリストは、「JBoss EAP 7 でサポートされる構成」を参照してください。

データソースタイプ

リソースの一般的なタイプには、データソースXA データソースの 2 つのタイプがあります。

非 XA データソース
トランザクションを使用しないアプリケーション、または単一のデータベースでトランザクションを使用するアプリケーションに使用されます。
XA データソース
複数のデータベースまたはある XA トランザクションの一部として他の XA リソースを使用するアプリケーションによって使用されます。XA データソースを使用すると追加のオーバーヘッドが発生します。

JBoss EAP 管理インターフェースを使用してデータソースを作成するときに、使用するデータソースのタイプを指定します。

ExampleDS データソース

JBoss EAP には、データソースの定義方法を実証するために提供されるデータソース設定例 ExampleDS が含まれています。このデータソースは、 H2 データベースを使用します。 H2 データベースはライトウェイトなリレーショナルデータベース管理システムで、アプリケーションを迅速に構築できる開発者向けの機能を提供します。

警告

ExampleDS データソースと H2 データベースは本番環境で使用しないでください。これは、アプリケーションのテストおよび構築に必要なすべての標準をサポートする非常に小さい自己完結型のデータソースであり、本番稼働用として堅牢またはスケーラブルではありません。

12.2. JDBC ドライバー

JBoss EAP でアプリケーションが使用するデータソースを定義する前に、最初に適切な JDBC ドライバーをインストールする必要があります。

12.2.1. コアモジュールとしての JDBC ドライバーのインストール

JDBC ドライバーをコアモジュールとしてインストールするには、最初に JDBC ドライバーをコアモジュールとして追加 し、datasources サブシステムで JDBC ドライバーを登録 する必要があります。

12.2.1.1. JDBC ドライバーをコアモジュールとして追加

以下の手順に従うと、管理 CLI を使用して JDBC ドライバーをコアモジュールとしてインストールすることができます。

  1. JDBC ドライバーをダウンロードします。

    データベースのベンダーから適切な JDBC ドライバーをダウンロードします。一般的なデータベースの JDBC ドライバーをダウンロードできる場所については、「JDBC ドライバーのダウンロードできる場所」を参照してください。

    JDBC ドライバーの JAR ファイルが ZIP または TAR アーカイブ内に含まれている場合は、必ずそのアーカイブを展開してください。

  2. JBoss EAP サーバーを起動します。
  3. 管理 CLI を起動します。

    $ EAP_HOME/bin/jboss-cli.sh
  4. module add 管理 CLI コマンドを使用して新しいコアモジュールを追加します。

    module add --name=MODULE_NAME --resources=PATH_TO_JDBC_JAR --dependencies=DEPENDENCIES

    たとえば、以下のコマンドは MySQL JDBC ドライバーモジュールを追加します。

    module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

    module --help を実行すると、このコマンドを使用したモジュールの追加および削除の詳細を表示できます。

次に、アプリケーションデータソースによって参照されるよう、JDBC ドライバーとして登録する必要があります。

12.2.1.2. JDBC ドライバーの登録

ドライバーが コアモジュールとしてインストール されたら、以下の管理 CLI コマンドを使用して JDBC ドライバーとして登録する必要があります。管理対象ドメインを実行している場合は、コマンドの前に /profile=PROFILE_NAME を付けてください。

/subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)
注記

driver-class-name パラメーターは、JDBC ドライバー jar が /META-INF/services/java.sql.Driver ファイルで複数の jar を定義する場合のみ必要です。

たとえば、MySQL 5.1.36 JDBC ドライバー JAR の /META-INF/services/java.sql.Driver ファイルは、以下の 2 つのクラスを定義します。

  • com.mysql.jdbc.Driver
  • com.mysql.fabric.jdbc.FabricMySQLDriver

この場合、 driver-class-name=com.mysql.jdbc.Driver で渡します。

たとえば、以下のコマンドは MySQL JDBC ドライバーを登録します。

/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)

アプリケーションのデータソースが JDBC ドライバーを参照できる状態になります。

12.2.2. JDBC ドライバーの JAR デプロイメントとしてのインストール

管理 CLI または管理コンソールを使用して JDBC ドライバーを JAR デプロイメントとしてインストールできます。JDBC 4 に対応するドライバーは、自動的に認識され、デプロイメント時に JDBC ドライバーとしてインストールされます。

以下の手順は、管理 CLI を使用した JDBC ドライバーのインストール方法になります。

注記

JDBC ドライバーをコアモジュールとしてインストールする方法が推奨されます。

  1. JDBC ドライバーをダウンロードします。

    データベースのベンダーから適切な JDBC ドライバーをダウンロードします。一般的なデータベースの JDBC ドライバーをダウンロードできる場所については、「JDBC ドライバーのダウンロードできる場所」を参照してください。

    JDBC ドライバーの JAR ファイルが ZIP または TAR アーカイブ内に含まれている場合は、必ずそのアーカイブを展開してください。

  2. JDBC ドライバーが JDBC 4 に対応していない場合は、「JDBC ドライバー JAR を JDBC 4 対応に更新」の手順を参照してください。
  3. JAR を JBoss EAP にデプロイします。

    deploy PATH_TO_JDBC_JAR
    注記

    管理対象ドメインでは、適切なサーバーグループを指定します。

    たとえば、以下のコマンドは MySQL JDBC ドライバーをデプロイします。

    deploy /path/to/mysql-connector-java-8.0.12.jar

    JBoss EAP サーバーログにメッセージが表示され、データソースを定義するときに使用されるデプロイされたドライバーの名前が表示されます。

    WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-8.0.12.jar

アプリケーションのデータソースが JDBC ドライバーを参照できる状態になります。

JDBC ドライバー JAR を JDBC 4 対応に更新

JDBC ドライバー JAR が JDBC 4 に対応していない場合、以下の手順に従ってデプロイ可能にすることができます。

  1. 空の一時ディレクトリーを作成します。
  2. META-INF サブディレクトリーを作成します。
  3. META-INF/services サブディレクトリーを作成します。
  4. META-INF/services/java.sql.Driver ファイルを作成し、JDBC ドライバーの完全修飾クラス名を示す 1 行を追加します。

    たとえば、MySQL JDBC ドライバーでは以下の行を追加します。

    com.mysql.jdbc.Driver
  5. JAR コマンドラインツールを使用して、この新しいファイルを JAR に追加します。

    jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver

12.2.3. JDBC ドライバーをダウンロードできる場所

下表は、JBoss EAP で使用される一般的なデータベースの JDBC ドライバーをダウンロードできる場所を示しています。

注記

これらのリンク先は他社の Web サイトであるため、Red Hat は管理しておらず、積極的に監視も行っていません。ご使用のデータベースの最新ドライバーについては、データベースベンダーのドキュメントおよび Web サイトを確認してください。

表12.1 JDBC ドライバーをダウンロードできる場所

ベンダーダウンロード場所

MySQL

http://www.mysql.com/products/connector/

PostgreSQL

http://jdbc.postgresql.org/

Oracle

http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html

IBM

http://www-01.ibm.com/support/docview.wss?uid=swg21363866

Sybase

jConnect JDBC ドライバーは、SAP ASE インストールの SDK の一部です。現在、このドライバーのみをダウンロードできるサイトはありません。

Microsoft

http://msdn.microsoft.com/data/jdbc/

12.2.4. ベンダー固有クラスへのアクセス

場合によっては、アプリケーションが JDBC API の一部ではないベンダー固有の機能を使用する必要があることがあります。このような場合、そのアプリケーションで依存関係を宣言してベンダー固有の API にアクセスすることができます。

警告

これは高度な使用法です。JDBC API に含まれない機能を必要とするアプリケーションのみこれを実装します。

重要

このプロセスは、再認証メカニズムを使用し、ベンダー固有のクラスにアクセスする場合に必要です。

MANIFEST.MF ファイルまたは jboss-deployment-structure.xml ファイルを使用するとアプリケーションの依存関係を定義できます。

JDBC ドライバーをコアモジュールとしてインストール していない場合は、インストールしてください。

MANIFEST.MF ファイルの使用
  1. アプリケーションの META-INF/MANIFEST.MF ファイルを編集します。
  2. Dependencies 行を追加し、モジュール名を指定します。

    たとえば、以下の行は com.mysql モジュールを依存関係として宣言します。

    Dependencies: com.mysql
jboss-deployment-structure.xml ファイルの使用
  1. アプリケーションの META-INF/ または WEB-INF/ フォルダーで jboss-deployment-structure.xml というファイルを作成します。
  2. dependencies 要素を使用してモジュールを指定します。

    たとえば、以下の jboss-deployment-structure.xml ファイル例は com.mysql モジュールを依存関係として宣言します。

    <jboss-deployment-structure>
      <deployment>
        <dependencies>
          <module name="com.mysql"/>
        </dependencies>
      </deployment>
    </jboss-deployment-structure>

以下のコード例は MySQL API にアクセスします。

import java.sql.Connection;
...
Connection c = ds.getConnection();
if (c.isWrapperFor(com.mysql.jdbc.Connection.class)) {
    com.mysql.jdbc.Connection mc = c.unwrap(com.mysql.jdbc.Connection.class);
}
重要

接続は IronJacamar コンテナーによって制御されるため、ベンダー固有の API ガイドラインに従ってください。

12.3. データソースの作成

データソースは管理コンソールまたは管理 CLI を使用して作成できます。

JBoss EAP 7 では、enabled 属性などのデータソース属性値を式で使用することができます。設定で式を使用する場合の詳細は、「プロパティーの置換」の項を参照してください。

12.3.1. 非 XA データソースの作成

管理 CLI または管理コンソールを使用して、非 XA データソース作成できます。

管理コンソールを使用した非 XA データソースの定義
  1. ConfigurationSubsystemsDatasources & DriversDatasources と選択します。
  2. 追加 (+) ボタンをクリックし、Add Datasource を選択します。
  3. データソースタイプを選択できる Add Datasource ウィザードが表示されたら、Next をクリックします。これにより、データベースのテンプレートが作成されます。ウィザードの以下のページには、選択したデータソースに固有する値が自動的に入力されています。これにより、データソースの作成プロセスが簡単になります。
  4. データソースの作成を終了する前に、Test Connection ページで接続をテストできます。
  5. 詳細を確認し、Finish をクリックしてデータソースを作成します。
管理 CLI を使用した非 XA データソースの定義

data-source add 管理 CLI コマンドを使用すると、非 XA データソースを定義できます。

  1. JDBC ドライバーをコアモジュールとしてインストールおよび登録していない場合は、「コアモジュールとしての JDBC ドライバーのインストール」を参照してインストールと登録を行ってください。
  2. 適切な引数の値を指定し、data-source add コマンドを使用してデータソースを定義します。

    data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
    注記

    管理対象ドメインでは、--profile=PROFILE_NAME 引数を指定する必要があります。

    これらのパラメーター値については、以下の「データソースパラメーター」の項を参照してください。

詳細な例は、サポート対象データベースの「データソース設定例」を参照してください。

データソースのパラメーター
jndi-name
データソースの JNDI 名は、java:/ または java:jboss/ で始まる必要があります。たとえば、java:jboss/datasources/ExampleDSになります。
driver-name

ドライバー名の値は、JDBC ドライバーがコアモジュールまたは JAR デプロイメントとしてインストールされたかによって異なります。

  1. コアモジュールでは、ドライバー名の値は登録時に指定した JDBC ドライバーの名前になります。
  2. JAR デプロイメントでは、/META-INF/services/java.sql.Driver ファイルに 1 つのクラスのみがある場合はドライバー名が JAR の名前になります。複数のクラスがリストされている場合は値が JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION (例: mysql-connector-java-5.1.36-bin.jar_com.mysql.jdbc.Driver_5_1) になります。

    また、JDBC JAR がデプロイされると JBoss EAP サーバーログにドライバー名がリストされます。

    WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-5.1.36-bin.jar_com.mysql.jdbc.Driver_5_1
connection-url
サポートされるデータベースの接続 URL 形式の詳細は、「データソース接続 URL」のリストを参照してください。

利用できるデータソース属性の完全リストは、「データソース属性」を参照してください。

12.3.2. XA データソースの作成

管理 CLI または管理コンソールを使用して XA データソースを作成できます。

管理コンソールを使用した XA データソースの定義
  1. ConfigurationSubsystemsDatasources & DriversDatasources と選択します。
  2. 追加 (+) ボタンをクリックし、XA データソースを追加 を選択します。
  3. データソースタイプを選択できる XA データソースを追加 ウィザードが表示されたら、Next をクリックします。これにより、データベースのテンプレートが作成されます。ウィザードの以下のページには、選択したデータソースに固有する値が自動的に入力されています。これにより、データソースの作成プロセスが簡単になります。
  4. データソースの作成を終了する前に、Test Connection ページで接続をテストできます。
  5. 詳細を確認し、Finish をクリックしてデータソースを作成します。
管理 CLI を使用した XA データソースの定義

xa-data-source add 管理 CLI コマンドを使用すると XA データソースを定義できます。

注記

管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理 CLI コマンドの形式に応じて、コマンドの前に /profile=PROFILE_NAME を付けるか、--profile=PROFILE_NAME 引数に渡します。

  1. JDBC ドライバーをコアモジュールとしてインストールおよび登録していない場合は、「コアモジュールとしての JDBC ドライバーのインストール」を参照してインストールと登録を行ってください。
  2. 適切な引数の値を指定し、xa-data-source add コマンドを使用してデータソースを定義します。

    xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS --xa-datasource-properties={"ServerName"=>"HOST_NAME","DatabaseName"=>"DATABASE_NAME"}

    これらのパラメーター値については、以下の「データソースパラメーター」の項を参照してください。

  3. XA データソースプロパティー を設定します。

    XA データソースを定義するときに最低でも 1 つの XA データソースプロパティーが必要になります。XA データソースプロパティーがないと、前のステップでデータソースを追加するときにエラーが発生します。XA データソースを定義するときに設定しなかったプロパティーは後で個別に設定することができます。

    1. サーバー名を設定します。

      /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOST_NAME)
    2. データベース名を設定します。

      /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)

詳細な例は、サポート対象データベースの「データソース設定例」を参照してください。

データソースのパラメーター
jndi-name
データソースの JNDI 名は、java:/ または java:jboss/ で始まる必要があります。たとえば、java:jboss/datasources/ExampleDSになります。
driver-name

ドライバー名の値は、JDBC ドライバーがコアモジュールまたは JAR デプロイメントとしてインストールされたかによって異なります。

  1. コアモジュールでは、ドライバー名の値は登録時に指定した JDBC ドライバーの名前になります。
  2. JAR デプロイメントでは、/META-INF/services/java.sql.Driver ファイルに 1 つのクラスのみがある場合はドライバー名が JAR の名前になります。複数のクラスがリストされている場合は値が JAR_NAME + "_" + DRIVER_CLASS_NAME + "_" + MAJOR_VERSION + "_" + MINOR_VERSION (例: mysql-connector-java-5.1.36-bin.jar_com.mysql.jdbc.Driver_5_1) になります。

    また、JDBC JAR がデプロイされると JBoss EAP サーバーログにドライバー名がリストされます。

    WFLYJCA0018: Started Driver service with driver-name = mysql-connector-java-5.1.36-bin.jar_com.mysql.jdbc.Driver_5_1
xa-datasource-class
JDBC ドライバーの javax.sql.XADataSource クラスの実装に対する XA データソースクラスを指定します。
xa-datasource-properties
XA データソースを定義するときに最低でも 1 つの XA データソースプロパティーが必要になります。XA データソースプロパティーがないと、追加するときにエラーが発生します。 XA データソースの定義後にプロパティーを追加することもできます。

利用できるデータソース属性の完全リストは、「データソース属性」を参照してください。

12.4. データソースの編集

データソースは、管理コンソールまたは管理 CLI を使用して設定できます。

JBoss EAP 7 では、enabled 属性などのデータソース属性値を式で使用することができます。設定で式を使用する場合の詳細は、「プロパティーの置換」の項を参照してください。

12.4.1. 非 XA データソースの編集

非 XA データソース設定は data-source 管理 CLI コマンドを使用して更新できます。管理コンソールでは、ConfigurationSubsystemsDatasources & DriversDatasources と選択するとデータソース属性を更新できます。

注記

非 XA データソースは JTA トランザクションと統合できます。データソースを JTA と統合する場合、必ず jta パラメーターを true に設定してください。

データソースの設定は、以下の管理 CLI コマンドを使用して更新できます。

data-source --name=DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE
注記

管理対象ドメインでは、--profile=PROFILE_NAME 引数を指定する必要があります。

変更を反映するのにサーバーのリロードが必要になる場合があります。

12.4.2. XA データソースの編集

XA データソース設定は xa-data-source 管理 CLI コマンドを使用して更新できます。管理コンソールでは、ConfigurationSubsystemsDatasources & DriversDatasources と選択するとデータソース属性を更新できます。

  • XA データソースの設定は、以下の管理 CLI コマンドを使用して更新できます。

    xa-data-source --name=XA_DATASOURCE_NAME --ATTRIBUTE_NAME=ATTRIBUTE_VALUE
    注記

    管理対象ドメインでは、--profile=PROFILE_NAME 引数を指定する必要があります。

  • 以下の管理 CLI コマンドを使用すると XA データソースプロパティーを追加できます。

    /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=PROPERTY:add(value=VALUE)
    注記

    管理対象ドメインでは、このコマンドの前に /profile=PROFILE_NAME を追加する必要があります。

変更を反映するのにサーバーのリロードが必要になる場合があります。

12.5. データソースの削除

データソースは管理コンソールまたは管理 CLI を使用して削除できます。

12.5.1. 非 XA データソースの削除

非 XA データソースは data-source remove 管理 CLI コマンドを使用して削除できます。管理コンソールでは、ConfigurationSubsystemsDatasources & DriversDatasources と選択するとデータソースを削除できます。

data-source remove --name=DATASOURCE_NAME
注記

管理対象ドメインでは、--profile=PROFILE_NAME 引数を指定する必要があります。

データソースの削除後にサーバーのリロードが必要になります。

12.5.2. XA データソースの削除

XA データソースは xa-data-source remove 管理 CLI コマンドを使用して削除できます。管理コンソールでは、ConfigurationSubsystemsDatasources & DriversDatasources と選択するとデータソースを削除できます。

xa-data-source remove --name=XA_DATASOURCE_NAME
注記

管理対象ドメインでは、--profile=PROFILE_NAME 引数を指定する必要があります。

XA データソースの削除後にサーバーのリロードが必要になります。

12.6. データソース接続のテスト

管理 CLI または管理コンソールを使用してデータソースの接続をテストし、設定が適切であることを検証できます。

管理 CLI を使用したデータソース接続のテスト

以下の管理 CLI コマンドを実行すると、データソースの接続をテストできます。

/subsystem=datasources/data-source=DATASOURCE_NAME:test-connection-in-pool
注記

管理対象ドメインでは、このコマンドの前に /host=HOST_NAME/server=SERVER_NAME を追加する必要があります。XA データソースをテストする場合は、 data-source=DATASOURCE_NAMExa-data-source=XA_DATASOURCE_NAME に置き換えてください。

管理コンソールを使用したデータソース接続のテスト

管理コンソールで データソースの追加 ウィザードを使用する場合、データソースの作成前に接続をテストできます。ウィザードの テスト接続 画面で テスト接続 ボタンをクリックします。

データソースが追加されたら、ConfigurationSubsystemsDatasources & DriversDatasources と選択し、データソースを選択します。 ドロップダウンメニューから テスト接続 を選択すると、接続をテストできます。

12.7. データソース接続のフラッシュ

以下の管理 CLI コマンドを使用して、データベースの接続をフラッシュします。

注記

管理対象ドメインでは、コマンドの前に /host=HOST_NAME/server=SERVER_NAME を追加する必要があります。

  • プールの接続をすべてフラッシュします。

    /subsystem=datasources/data-source=DATASOURCE_NAME:flush-all-connection-in-pool
  • プールの接続をすべて正常にフラッシュします。

    /subsystem=datasources/data-source=DATASOURCE_NAME:flush-gracefully-connection-in-pool

    サーバーは、接続がアイドル状態なるまで待ってから接続をフラッシュします。

  • プールのアイドル状態の接続をすべてフラッシュします。

    /subsystem=datasources/data-source=DATASOURCE_NAME:flush-idle-connection-in-pool
  • プールの無効な接続をすべてフラッシュします。

    /subsystem=datasources/data-source=DATASOURCE_NAME:flush-invalid-connection-in-pool

    サーバーは、「データベース接続の検証」で説明した valid-connection-checker-class-name または check-valid-connection-sql 検証メカニズムなどによって無効と判断されたすべての接続をフラッシュします。

管理コンソールを使用して接続をフラッシュすることもできます。Runtime タブでサーバーを選択し、Datasources を選択してデータソースを指定します。 ドロップダウンメニューを使用してアクションを選択します。

12.8. XA データソースのリカバリー

XA データソースは、XA グローバルトランザクションに参加できるデータソースです。XA グローバルトランザクションはトランザクションマネージャーによって調整され、1 つのトランザクションで複数のリソースにまたがる可能性があります。参加者の 1 つが変更のコミットに失敗した場合、他の参加者がトランザクションをアボートし、トランザクション発生前の状態にリストアします。これにより、一貫性を保持し、データの損失や破損を防ぎます。

XA リカバリーは、リソースやトランザクションの参加者がクラッシュしたり利用できない状態になっても、トランザクションの影響を受けるすべてのリソースが更新またはロールバックされるようにするプロセスです。XA リカバリーはユーザーが関与せずに行われます。

各 XA リソースにはその設定に関連するリカバリーモジュールが必要になります。リカバリーモジュールは、リカバリーの実行中に実行されるコードです。JBoss EAP は JDBC XA リソースのリカバリーモジュールを自動的に登録します。カスタムのリカバリーコードを実装する場合は XA データソースでカスタムモジュールを登録できます。リカバリーモジュールは com.arjuna.ats.jta.recovery.XAResourceRecovery クラスを拡張する必要があります。

12.8.1. XA リカバリーの設定

ほとんどの JDBC では、リカバリーモジュールがリソースに自動的に関連付けられます。この場合は、リカバリーモジュールがリソースに接続してリカバリーを実行することを許可するオプションのみを設定する必要があります。

以下の表は、XA リカバリーに固有する XA データソースパラメーターを表しています。これらの設定属性はデータソースの作成中または作成後に設定できます。これらは管理コンソールまたは管理 CLI を使用して設定できます。XA データソースのせって の設定に関する詳細は、「 XA データソースの編集」を 参照してください。

表12.2 XA リカバリーのデータソースパラメーター

属性説明

recovery-username

リカバリーでリソースに接続するために使用するユーザー名。指定しないと、データソースのセキュリティー設定が使用されます。

recovery-password

リカバリーのリソースへの接続に使用するパスワード。指定しないと、データソースのセキュリティー設定が使用されます。

recovery-security-domain

リカバリーでリソースに接続するために使用するセキュリティードメイン。

recovery-plugin-class-name

カスタムのリカバリーモジュールを使用する必要がある場合は、この属性をモジュールの完全修飾クラス名に設定します。モジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。

recovery-plugin-properties

プロパティーを設定する必要があるカスタムのリカバリーモジュールを使用する場合は、この属性をプロパティーに対するコンマ区切りの KEY=VALUE ペアのリストに設定します。

XA リカバリーの無効化

複数の XA データソースが同じ物理データベースに接続する場合、通常 XA リカバリーは XA データソースの 1 つのみに設定する必要があります。

以下の管理 CLI コマンドを使用して XA データソースのリカバリーを無効にします。

/subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=no-recovery,value=true)

12.8.2. ベンダー固有の XA リカバリー

ベンダー固有の設定

一部のデータベースは、JBoss EAP トランザクションマネージャーによって管理される XA トランザクションに対応するために特定の設定が必要になります。詳細な最新情報については、データベースベンダーの資料を参照してください。

MySQL
特別な設定は必要ありません。詳細は MySQL のドキュメントを参照してください。
PostgreSQL および Postgres Plus Advanced Server
PostgreSQL による XA トランザクションの処理を可能にするには、max_prepared_transactions 設定パラメーターを 0よりも大きい値または max_connections 以上の値に変更します。
Oracle

必ず Oracle ユーザー USER がリカバリーに必要なテーブルにアクセスできるようにしてください。

GRANT SELECT ON sys.dba_pending_transactions TO USER;
GRANT SELECT ON sys.pending_trans$ TO USER;
GRANT SELECT ON sys.dba_2pc_pending TO USER;
GRANT EXECUTE ON sys.dbms_xa TO USER;

Oracle ユーザーに適切なパーミッションがないと、以下のようなエラーが表示される可能性があります。

WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
Microsoft SQL Server
詳細は、http://msdn.microsoft.com/en-us/library/aa342335.aspx を含む Microsoft SQL Server のドキュメントを参照してください。
IBM DB2
特別な設定は必要ありません。詳細は IBM DB2 のドキュメントを参照してください。
Sybase

Sybase は、XA トランザクションがデータベース上で有効であることを想定します。XA トランザクションはデータベース設定が正しくないと動作しません。enable xact coordination パラメーター は、Adaptive Server トランザクションコーディネーションサービスを有効または無効にします。このパラメーターを有効にすると、リモート Adaptive Server データのアップデートが、確実に元のトラザクションでコミットまたはロールバックされるようになります。

トラザクションコーディネーションを有効にするには、以下を使用します。

sp_configure 'enable xact coordination', 1
MariaDB
特別な設定は必要ありません。詳細は MariaDB のドキュメントを参照してください。
既知の問題

ここで取り上げる既知の問題は、JBoss EAP 7 でサポートされる特定のデータベースおよび JDBC ドライバーバージョンの XA トランザクションの処理に関する問題になります。サポートされるデータベースの最新情報は、「JBoss Enterprise Application Platform (EAP) 7 でサポートされる構成」を参照してください。

MySQL
MySQL は XA トランザクションを完全に処理できません。クライアントと MySQL の接続が切断されると、トランザクションに関する情報がすべて失われます。詳細は MySQL のバグを参照してください。この問題は MuSQL 5.7 で修正されました。
PostgreSQL および Postgres Plus Advanced Server

2 フェーズコミット (2PC) のコミットフェーズ中にネットワークの障害が発生すると、JDBC ドライバーによって XAER_RMERR XAException エラーコードが返されます。このエラーは、トランザクションマネージャーでリカバリー不可能な重大なイベントが発生したことを示しますが、トランザクションはデータベース側で in-doubt 状態を維持し、ネットワーク接続の回復後に簡単に修正できます。適切な戻りコードは XAER_RMFAIL または XAER_RETRY になります。誤ったエラーコードにより、トランザクションが JBoss EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、手動の介入が必要になります。詳細は PostgreSQL のバグを参照してください。

1 フェーズコミットの最適化が使用されたときに接続の障害が発生した場合、JDBC ドライバーは XAER_RMERR を返しますが、適切な戻りコードは XAER_RMFAIL になります。そのため、1 フェーズコミット中にデータベースがデータをコミットし、同時に接続が切断されると、クライアントにはトラザクションがロールバックされたと伝えられるため、データの不整合が発生する場合があります。

Postgres Plus JDBC ドライバーは、Postgres Plus Server に存在するすべての準備済みトランザクションの XID を返すため、XID が属するデータベースを判断する方法がありません。JBoss EAP で複数のデータソースを同じデータベースに定義すると、in-doubt トランザクションリカバリーが誤ったアカウントで実行される可能性があります。 この場合、リカバリーに失敗します。

Oracle

一部のユーザー認証情報で設定されたデータソースを使用してリカバリーマネージャーがリカバリーを呼び出すと、JDBC ドライバーはデータベースインスタンスのすべてのユーザーに属する XID を返します。JDBC ドライバーは他のユーザーに属する XID をリカバリーしようとするため、例外 ORA-24774: cannot switch to specified transaction が発生します。

この問題を回避するには、リカバリーデータソース設定で認証情報が使用されるユーザーに FORCE ANY TRANSACTION 権限を付与します。特権の設定に関する詳細は http://docs.oracle.com/database/121/ADMIN/ds_txnman.htm#ADMIN12259 を参照してください。

Microsoft SQL Server

2 フェーズコミット (2PC) のコミットフェーズ中にネットワークの障害が発生すると、JDBC ドライバーによって XAER_RMERR XAException エラーコードが返されます。このエラーは、トランザクションマネージャーでリカバリー不可能な重大なイベントが発生したことを示しますが、トランザクションはデータベース側で in-doubt 状態を維持し、ネットワーク接続の回復後に簡単に修正できます。適切な戻りコードは XAER_RMFAIL または XAER_RETRY になります。誤ったエラーコードにより、トランザクションが JBoss EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、手動の介入が必要になります。詳細は Microsoft SQL Server の問題レポートを参照してください。

1 フェーズコミットの最適化が使用されたときに接続の障害が発生した場合、JDBC ドライバーは XAER_RMERR を返しますが、適切な戻りコードは XAER_RMFAIL になります。そのため、1 フェーズコミット中にデータベースがデータをコミットし、同時に接続が切断されると、クライアントにはトラザクションがロールバックされたと伝えられるため、データの不整合が発生する場合があります。

IBM DB2
1 フェーズコミット中に接続の障害が発生した場合、JDBC ドライバーは XAER_RMERR を返しますが、適切な戻りコードは XAER_RMFAIL です。そのため、1 フェーズコミット中にデータベースがデータをコミットし、同時に接続が切断されると、クライアントにはトラザクションがロールバックされたと伝えられるため、データの不整合が発生する場合があります。
Sybase

2 フェーズコミット (2PC) のコミットフェーズ中にネットワークの障害が発生すると、JDBC ドライバーによって XAER_RMERR XAException エラーコードが返されます。このエラーは、トランザクションマネージャーでリカバリー不可能な重大なイベントが発生したことを示しますが、トランザクションはデータベース側で in-doubt 状態を維持し、ネットワーク接続の回復後に簡単に修正できます。適切な戻りコードは XAER_RMFAIL または XAER_RETRY になります。誤ったエラーコードにより、トランザクションが JBoss EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、手動の介入が必要になります。

1 フェーズコミットの最適化が使用されたときに接続の障害が発生した場合、JDBC ドライバーは XAER_RMERR を返しますが、適切な戻りコードは XAER_RMFAIL になります。そのため、1 フェーズコミット中にデータベースがデータをコミットし、同時に接続が切断されると、クライアントにはトラザクションがロールバックされたと伝えられるため、データの不整合が発生する場合があります。

Sybase トランザクションブランチが準備済み状態になる前に、Sybase 15.7 または 16 データベースへの挿入が含まれる XA トランザクションが失敗すると、XA トランザクションの繰り返しや同じ主キーでの同じレコードの挿入に失敗し、エラー com.sybase.jdbc4.jdbc.SybSQLException: Attempt to insert duplicate key row が発生します。この例外は、元の終了していない Sybase トランザクションブランチがロールバックするまで発生します。

MariaDB
MariaDB は XA トランザクションを完全に処理できません。クライアントと MariaDB の接続が切断されると、トランザクションに関する情報がすべて失われます。
MariaDB Galera クラスター
MariaDB Galera クラスターでは XA トランザクションはサポートされません。

12.9. データベース接続の検証

データベースのメンテナンス、ネットワークの問題、またはその他の障害により、JBoss EAP からデータベースへの接続が失われることがあります。このような状況から回復するために、データソースのデータベース接続検証を有効にすることができます。

データベース接続の検証を設定するには、検証発生時を定義する検証タイミングメソッド、検証の実行方法を決定する検証メカニズム、および例外の処理方法を定義する例外ソーターを指定します。

  1. 検証タイミングメソッドを 1 つ選択します。

    validate-on-match

    validate-on-match オプションが true に設定されている場合は、データ接続が、次の手順で指定された検証メカニズムを使用して接続プールからチェックアウトされるたびに検証されます。

    接続が有効でない場合は、警告がログに書き込まれ、プール内の次の接続が取得されます。このプロセスは、有効な接続が見つかるまで続行します。プール内の各接続を繰り返し処理しない場合は、use-fast-fail オプションを使用できます。有効な接続がプールにない場合は、新しい接続が作成されます。接続の作成に失敗すると、例外が要求元アプリケーションに返されます。

    この設定により、最も早いリカバリーが実現されますが、データベースへの負荷が最も大きくなります。ただし、これは、パフォーマンスを気にする必要がない場合は最も安全な方法です。

    background-validation

    background-validation オプションを true に設定すると、使用前にバックグラウンドスレッドで接続が周期的に検証されます。検証の頻度は background-validation-millis プロパティーによって指定されます。background-validation-millisのデフォルト値は 0 で、無効になっています。

    以下を考慮して background-validation-millis プロパティーの値を決定してください。

    • この値は idle-timeout-minutes 設定とは違う値に設定してください。
    • 値が小さいほどプールの検証頻度が高くなり、より迅速に無効な接続がプールから削除されます。
    • 値が小さいほど使用されるデータベースリソースが多くなります。値が大きいほど接続検証チェックの頻度が低くなり、データベースリソースの使用量が減りますが、無効な接続が検出されない期間が長くなります。
    注記

    これらのオプションは相互排他的です。validate-on-matchtrue に設定された場合は、background-validationfalseに設定する必要があります。background-validation が true に設定された場合は validate-on-matchfalse に設定する必要があります。

  2. 検証メカニズムを 1 つ選択します。

    valid-connection-checker-class-name

    検証メカニズムとして valid-connection-checker-class-name を使用することが推奨されます。これは、使用中のデータベースの接続を検証するために使用される接続チェッカークラスを指定します。JBoss EAP は以下の接続チェッカーを提供します。

    • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
    • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
    check-valid-connection-sql

    check-valid-connection-sql を使用して、接続の検証に使用する SQL ステートメントを提供します。

    以下は、Oracle の接続を検証するために使用する SQL ステートメントの例になります。

    select 1 from dual

    以下は、MySQL または PostgreSQL の接続を検証するために使用する SQL ステートメントの例になります。

    select 1
  3. 例外ソータークラス名を設定します。

    例外が致命的とマークされた場合、接続はトランザクションに参加していてもすぐに閉じられます。致命的な接続例外を適切に検出およびクリーンアップするには、例外ソータークラスオプションを使用します。データソースタイプに適切な JBoss EAP 例外ソーターを選択します。

    • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.informix.InformixExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter

12.10. データソースセキュリティー

データソースセキュリティーとは、データソース接続のパスワードを暗号化したり分かりにくくすることを言います。これらのパスワードはプレーンテキストで設定ファイルに保存できますが、セキュリティーリスクが高くなります。

データソースセキュリティーに使用できるメソッドは複数あります。以下には、各メソッドの例が含まれています。

セキュリティードメインを使用したデータソースのセキュア化

データソースのセキュリティードメインが定義されます。

 <security-domain name="DsRealm" cache-type="default">
  <authentication>
    <login-module code="ConfiguredIdentity" flag="required">
      <module-option name="userName" value="sa"/>
      <module-option name="principal" value="sa"/>
      <module-option name="password" value="sa"/>
    </login-module>
  </authentication>
</security-domain>
注記

セキュリティードメインが複数のデータソースと使用される場合は、セキュリティードメインでキャッシュを無効にする必要があります。キャッシュを無効にするには、 cache-type 属性の値を none に設定するか、この属性を削除します。しかし、キャッシュが必要な場合は、各データソースに個別のセキュリティードメインを使用する必要があります。

DsRealm セキュリティードメインはデータソース設定によって参照されます。

<datasources>
  <datasource jndi-name="java:jboss/datasources/securityDs"
    pool-name="securityDs">
    <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
      <driver>h2</driver>
      <new-connection-sql>select current_user()</new-connection-sql>
      <security>
        <security-domain>DsRealm</security-domain>
      </security>
    </datasource>
</datasources>

セキュリティードメインの使用に関する詳細は、『How to Configure Identity Management』を参照してください。

パスワード Vault を使用したデータソースのセキュア化

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>

パスワード vault の使用に関する詳細は、JBoss EAP『How to Configure Server Security』の「Password Vault」の項を参照してください。

認証情報ストアを使用したデータソースのセキュア化

認証情報ストアを使用してパスワードを提供することもできます。elytron サブシステムを使用すると、認証情報ストアを作成してパスワードをセキュアに保存し、JBoss EAP 全体でパスワードを使用することができます。認証情報ストアの作成および使用に関する詳細は、JBoss EAP『How to Configure Server Security』の「Credential Store」を参照してください。

認証情報ストア参照を ExampleDS に追加

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=credential-reference,value={store=exampleCS, alias=example-ds-pw})

認証コンテキストを使用したデータソースのセキュア化

Elytron 認証コンテキストを使用して、ユーザー名とパスワードを提供することもできます。

以下の手順にしたがって、データソースセキュリティーの認証コンテキストを設定および使用します。

  1. passworduser-name を削除します。

    /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=password)
    /subsystem=datasources/data-source=ExampleDS:undefine-attribute(name=user-name)
  2. データソースの Elytron セキュリティーを有効にします。

    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=elytron-enabled,value=true)
    
    reload
  3. 認証情報の authentication-configuration を作成します。

    認証設定には、接続時にデータソースに使用させる認証情報が含まれています。以下の例は、認証情報ストアへの参照を使用しますが、Elytron セキュリティードメインを使用することもできます。

    /subsystem=elytron/authentication-configuration=exampleAuthConfig:add(authentication-name=sa,credential-reference={clear-text=sa})
  4. authentication-context を作成します。

    /subsystem=elytron/authentication-context=exampleAuthContext:add(match-rules=[{authentication-configuration=exampleAuthConfig}])
  5. 認証コンテキストを使用するよう、データソースを更新します。

    以下の例は、認証コンテキストを使用するよう、ExampleDS を更新します。

    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=authentication-context,value=exampleAuthContext)
    
    reload
    注記

    authentication-context が設定されておらず、elytron-enabledtrue に設定された場合、JBoss EAP は現在のコンテキストを使用して認証を行います。

Kerberos を使用したデータソースの保護

kerberos 認証を使用してデータソースを保護にするには、以下の設定が必要です。

  • Kerberos がデータベースサーバーに設定されている。
  • JBoss EAP ホストサーバーには、データベースサーバーのキータブエントリーがある。

kerberos を使用してデータソースを保護にするには、以下を実行します。

  1. Kerberos を使用するよう JBoss EAP を設定

    /system-property=java.security.krb5.conf:add(value="/path/to/krb5.conf")
    /system-property=sun.security.krb5.debug:add(value="false")
    /system-property=sun.security.spnego.debug:add(value="false")

    デバッグを行う場合は、sun.security.krb5.debugsun.security.spnego.debug の値を trueに変更します。本番環境では、値を false に設定することが推奨されます。

  2. セキュリティーを設定します。

    データソースを保護にするには、レガシーセキュリティーまたは Elytron セキュリティーを使用できます。

    • レガシーのセキュリティーで kerberos を使用するには、以下の手順に従います。

      1. 期限切れのチケットをキャッシュから定期的に削除するように infinispan キャッシュを設定します。

        batch
        /subsystem=infinispan/cache-container=security:add(default-cache=auth-cache)
        /subsystem=infinispan/cache-container=security/local-cache=auth-cache:add()
        /subsystem=infinispan/cache-container=security/local-cache=auth-cache/expiration=EXPIRATION:add(lifespan=3540000,max-idle=3540000)
        /subsystem=infinispan/cache-container=security/local-cache=auth-cache/eviction=EVICTION:add(strategy=LRU, max-entries=1000)
        run-batch

        以下の属性はチケットの有効期限を定義します。

        • lifespan: KDC から新しい証明書を要求する間隔 (ミリ秒単位)。KDC で定義される lifespan 条件よりも小さい値になるように、lifespan 属性 の値を設定します。
        • max-idle: 未使用の場合に、有効なチケットがキャッシュから削除される間隔 (ミリ秒単位)。
        • max-entries: キャッシュに保持する kerberos チケットの最大コピー数。この値は、データソースで設定された接続の数に対応します。

          エビクションの詳細は、『Infinispan』ユーザーガイドの「Eviction and Data Container」以下の項を参照してください。

      2. セキュリティードメインを作成します。

        batch
        /subsystem=security/security-domain=KerberosDatabase:add(cache-type=infinispan)
        /subsystem=security/security-domain=KerberosDatabase/authentication=classic:add
        /subsystem=security/security-domain=KerberosDatabase/authentication=classic/login-module="KerberosDatabase-Module":add(code="org.jboss.security.negotiation.KerberosLoginModule",module="org.jboss.security.negotiation",flag=required, module-options={ "debug" => "false", "storeKey" => "false", "useKeyTab" => "true", "keyTab" => "/path/to/eap.keytab", "principal" => "PRINCIPAL@SERVER.COM", "doNotPrompt" => "true", "refreshKrb5Config" => "true", "isInitiator" => "true", "addGSSCredential" => "true", "credentialLifetime" => "-1"})
        run-batch
        • SQL サーバーに Microsoft JDBC ドライバーを使用する場合は、module-options に属性と "wrapsphinx" ⇒ "true" の値を追加します。
        • デバッグするには、module-optionsdebug 属性の値を true に変更します。
    • Elytron で kerberos を使用するには、以下を行います。

      1. Elytron で kerberos ファクトリーを設定します。

        /subsystem=elytron/kerberos-security-factory=krbsf:add(debug=false, principal=PRINCIPAL@SERVER.COM, path=/path/to/keytab, request-lifetime=-1, obtain-kerberos-ticket=true, server=false)
        • デバッグを行う場合は、属性および debug = true の値を追加します。

          対応している属性の一覧は、『How to Configure Server Security』の「Kerberos Security Factory Attributes」を参照してください。

      2. kerberos ファクトリーを使用するよう認証設定を作成します。

        /subsystem=elytron/authentication-configuration=kerberos-conf:add(kerberos-security-factory=krbsf)
      3. authentication-context を作成します。

        /subsystem=elytron/authentication-context=ds-context:add(match-rules=[{authentication-configuration=kerberos-conf}])
  3. データソースを kerberos で保護します。

    • レガシーのセキュリティーを使用する場合:

      1. セキュリティードメインを使用するようにデータソースを設定します。

        /subsystem=datasources/data-source=KerberosDS:add(connection-url="URL", min-pool-size=0, max-pool-size=10, jndi-name="java:jboss/datasource/KerberosDS", driver-name=<jdbc-driver>.jar, security-domain=KerberosDatabase, allow-multiple-users=false, pool-prefill=false, pool-use-strict-min=false, idle-timeout-minutes=2)
      2. ベンダー固有の接続プロパティーを設定します。

        /subsystem=datasources/data-source=KerberosDS/connection-properties=<connection-property-name>:add(value="(<kerberos-value>)")

        例: Oracle データベースの接続プロパティー。

        /subsystem=datasources/data-source=KerberosDS/connection-properties=oracle.net.authentication_services:add(value="(KERBEROS5)")
    • Elytron を使用する場合:

      1. 認証コンテキストを使用するようにデータソースを設定します。

        /subsystem=datasources/data-source=KerberosDS:add(connection-url="URL", min-pool-size=0, max-pool-size=10, jndi-name="java:jboss/datasource/KerberosDS", driver-name=<jdbc-driver>.jar, elytron-enabled=true, authentication-context=ds-context, allow-multiple-users=false, pool-prefill=false, pool-use-strict-min=false, idle-timeout-minutes=2)
      2. ベンダー固有の接続プロパティーを設定します。

        /subsystem=datasources/data-source=KerberosDS/connection-properties=<connection-property-name>:add(value="(<kerberos-value>)")

        例: Oracle データベースの接続プロパティー

        /subsystem=datasources/data-source=KerberosDS/connection-properties=oracle.net.authentication_services:add(value="(KERBEROS5)")

      kerberos 認証を使用する場合は、データソースに以下の属性と値を使用することが推奨されます。

      • pool-prefill=false
      • pool-use-strict-min=false
      • idle-timeout-minutes

    対応している属性のリストは、「データソース属性」を参照してください。

12.11. データソースの統計

データソースの統計収集が 有効化 されている場合、データソースの ランタイム統計を表示 できます。

12.11.1. データソース統計の有効化

データソース統計は、デフォルトでは有効になっていません。データソース統計の収集は、 管理 CLI または 管理コンソール を使用して有効にできます。

管理 CLI を使用したデータソース統計の有効化

以下の管理 CLI コマンドは、ExampleDS データソースの統計の収集を有効にします。

注記

管理対象ドメインでは、このコマンドの前に /profile=PROFILE_NAME を付けます。

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=statistics-enabled,value=true)

変更を反映するためにサーバーをリロードします。

管理コンソール使用したデータソース統計の有効化

以下の手順にしたがって管理コンソールを使用し、統計の収集を有効にします。

  1. ConfigurationSubsystemsDatasources & DriversDatasources と選択します。
  2. データソースを選択し、表示 をクリックします。
  3. Attributes タブ下の Edit をクリックします。
  4. Statistics enabled? フィールドを ON に設定し、Save をクリックします。変更の反映にはリロードが必要であることを伝えるポップアップが表示されます。
  5. サーバーをリロードします。

    • スタンドアロンサーバーの場合は、ポップアップの Reload ボタンをクリックしてサーバーをリロードします。
    • 管理対象ドメインの場合は、ポップアップの Topology リンクをクリックします。Topology タブで該当するサーバーを選択し、Reload ドロップダウンオプションを選択してサーバーをリロードします。

12.11.2. データソース統計の表示

管理 CLI または 管理コンソール を使用してデータソースのランタイム統計を表示できます。

管理 CLI を使用したデータソース統計の表示

以下の管理 CLI コマンドは、ExampleDS データソースのコアプールの統計を取得します。

注記

管理対象ドメインでは、コマンドの前に /host=HOST_NAME/server=SERVER_NAME を追加します。

/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "ActiveCount" => 1,
        "AvailableCount" => 20,
        "AverageBlockingTime" => 0L,
        "AverageCreationTime" => 122L,
        "AverageGetTime" => 128L,
        "AveragePoolTime" => 0L,
        "AverageUsageTime" => 0L,
        "BlockingFailureCount" => 0,
        "CreatedCount" => 1,
        "DestroyedCount" => 0,
        "IdleCount" => 1,
        ...
}

以下の管理 CLI コマンドは、ExampleDS データソースの JDBC の統計を取得します。

/subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "PreparedStatementCacheAccessCount" => 0L,
        "PreparedStatementCacheAddCount" => 0L,
        "PreparedStatementCacheCurrentSize" => 0,
        "PreparedStatementCacheDeleteCount" => 0L,
        "PreparedStatementCacheHitCount" => 0L,
        "PreparedStatementCacheMissCount" => 0L,
        "statistics-enabled" => true
    }
}
注記

統計はラインタイム情報であるため、必ず include-runtime=true 引数を指定してください。

利用可能な統計の詳細リストは、「データソースの統計」を参照してください。

管理コンソールを使用したデータソース統計の表示

管理コンソールからデータソースの統計を表示するには、Runtime タブで Datasources サブシステムを選択し、データソースを選択してから 表示 をクリックします。

利用可能な統計の詳細リストは、「データソースの統計」を参照してください。

12.12. データソースの調整

datasources サブシステムのパフォーマンスを監視および最適化するための情報は、『パフォーマンスチューニングガイド』の「データソースおよびリソースアダプターの調整」の項を参照してください。

12.13. キャパシティーポリシー

JBoss EAP は、データソースを含む JCA デプロイメントのキャパシティーポリシーの定義をサポートします。キャパシティーポリシーは、キャパシティーのインクリメントと呼ばれるプールの物理接続の作成方法と、キャパシティーのデクリメントと呼ばれる破棄方法を定義します。デフォルトのポリシーは、キャパシティーのインクリメントではリクエストごとに 1 つの接続を作成し、キャパシティーのデクリメントではアイドル状態のタイムアウトがスケジュールされたときにタイムアウトするとすべての接続が破棄されるよう設定されます。

キャパシティーポリシーを設定するには、キャパシティーインクリメンタークラスかキャパシティーデクリメンタークラスのいずれか、または両方を指定する必要があります。

例: キャパシティーポリシーの定義

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-incrementer-class, value="org.jboss.jca.core.connectionmanager.pool.capacity.SizeIncrementer")

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-decrementer-class, value="org.jboss.jca.core.connectionmanager.pool.capacity.SizeDecrementer")

指定したキャパシティーインクリメンターまたはデクリメンタークラスにプロパティーを設定することもできます。

例: キャパシティーポリシーのプロパティー設定

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-incrementer-properties.size, value=2)

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=capacity-decrementer-properties.size, value=2)

MaxPoolSize インクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.MaxPoolSizeIncrementer

MaxPoolSize インクリメンターポリシーは、リクエストごとにプールを最大サイズまでインクリメントします。このポリシーは、常時利用できる接続を最大数維持したい場合に便利です。

Size インクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.SizeIncrementer

Size インクリメンターポリシーは、リクエストごとにプールを指定の接続数までインクリメントします。このポリシーは、次のリクエストにも接続が必要であることを予想する場合に追加の接続数でインクリメントしたい場合に便利です。

表12.3 Size ポリシープロパティー

名前説明

Size

作成される接続数

注記

これはデフォルトのインクリメントポリシーで、size の値は 1 になります。

Watermark インクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.WatermarkIncrementer

Watermark インクリメンターポリシーは、リクエストごとにプールを指定の接続数までインクリメントします。このポリシーは、常時プールに指定数の接続を維持したい場合に便利です。

表12.4 Watermark ポリシープロパティー

名前説明

Watermark

接続数のウォーターマークレベル

MinPoolSize デクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.MinPoolSizeDecrementer

MinPoolSize デクリメンターポリシーは、リクエストごとにのプールを最小サイズまでデクリメントします。このポリシーは、各アイドルタイムアウトリクエストの後に接続の数を制限したい場合に便利です。プールは先入れ先出し (FIFO) で操作します。

Size デクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.SizeDecrementer

Size デクリメンターポリシーは、アイドルタイムアウトリクエストごとにプールを指定の接続数までデクリメントします。

表12.5 Size ポリシープロパティー

名前説明

Size

破棄されるべき接続の数

このポリシーは、プールの使用度が徐々に減少することが予想されるためアイドルタイムアウトリクエストごとの追加接続数をデクリメントしたい場合に便利です。

プールは先入れ先出し (FIFO) で操作します。

TimedOut デクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.TimedOutDecrementer

TimedOut デクリメンターポリシーは、アイドルタイムアウトリクエストごとにタイムアウトした接続をすべてプールから削除します。プールは先入れ後出し (FILO) で操作します。

注記

このポリシーはデフォルトのデクリメントポリシーです。

TimedOut/FIFO デクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.TimedOutFIFODecrementer

TimedOutFIFO デクリメンターポリシーは、アイドルタイムアウトリクエストごとにタイムアウトした接続をすべてプールから削除します。プールは先入れ先出し (FIFO) で操作します。

Watermark デクリメンターポリシー

クラス名: org.jboss.jca.core.connectionmanager.pool.capacity.WatermarkDecrementer

Watermark デクリメンターポリシーは、アイドルタイムアウトリクエストごとにプールを指定の接続数までデクリメントします。このポリシーは、常時プールに指定数の接続を維持したい場合に便利です。プールは先入れ先出し (FIFO) で操作します。

表12.6 Watermark ポリシープロパティー

名前説明

Watermark

接続数のウォーターマークレベル

12.14. エンリストメントトレース

XAResource インスタンスのエンリストメント中に発生するエラーを特定できるようにするために、エンリストメントトレースを記録することができます。エンリストメントトレースが有効である場合、必要時に正確なスタックトレースを作成できるように jca サブシステムはプール操作ごとに例外オブジェクトを作成しますが、これにはパフォーマンスのオーバーヘッドが発生します。

JBoss EAP 7.1 より、エンリストメントトレースはデフォルトで無効になっています。管理 CLI を使用してデータソースのエンリストメントトレースを有効にするには、enlistment-trace 属性を true に設定します。

非 XA データソースのエンリストメントトレースを有効にします。

data-source --name=DATASOURCE_NAME --enlistment-trace=true

XA データソースのエンリストメントトレースを有効にします。

xa-data-source --name=XA_DATASOURCE_NAME --enlistment-trace=true
警告

エンリストメントトレースを有効にするとパフォーマンスに影響することがあります。

12.15. データソース設定例

12.15.1. MySQL データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる MySQL データソースの設定例になります。

例: MySQL データソース例
<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <driver-class>com.mysql.jdbc.Driver</driver-class>
      <xa-datasource-class>com.mysql.cj.jdbc.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: MySQL JDBC ドライバー module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-8.0.12.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. MySQL JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. MySQL JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)
  3. MySQL データソースを追加します。

    data-source add --name=MySqlDS --jndi-name=java:jboss/MySqlDS --driver-name=mysql --connection-url=jdbc:mysql://localhost:3306/jbossdb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter

12.15.2. MySQL XA データソースの例

以下は、XA データソースプロパティー、基本のセキュリティー、およびバリデーションオプションが含まれる MySQL XA データソースの設定例になります。

例: MySQL XA データソースの設定
<datasources>
  <xa-datasource jndi-name="java:jboss/MySqlXADS" pool-name="MySqlXADS">
    <xa-datasource-property name="ServerName">
      localhost
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
      mysqldb
    </xa-datasource-property>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <driver-class>com.mysql.jdbc.Driver</driver-class>
      <xa-datasource-class>com.mysql.cj.jdbc.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: MySQL JDBC ドライバー module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-8.0.12.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. MySQL JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.mysql --resources=/path/to/mysql-connector-java-8.0.12.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. MySQL JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.cj.jdbc.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)
  3. MySQL XA データソースを追加します。

    xa-data-source add --name=MySqlXADS --jndi-name=java:jboss/MySqlXADS --driver-name=mysql --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mysqldb"}

12.15.3. PostgreSQL データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる PostgreSQL データソースの設定例になります。

例: PostgreSQL データソースの設定
<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
        <user-name>admin</user-name>
        <password>admin</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <validate-on-match>true</validate-on-match>
        <background-validation>false</background-validation>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="com.postgresql">
        <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: PostgreSQL JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.postgresql">
  <resources>
    <resource-root path="postgresql-9.3-1102.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. PostgreSQL JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.postgresql --resources=/path/to/postgresql-9.3-1102.jdbc4.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. PostgreSQL JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,driver-module-name=com.postgresql,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
  3. PostgreSQL データソースを追加します。

    data-source add --name=PostgresDS --jndi-name=java:jboss/PostgresDS --driver-name=postgresql --connection-url=jdbc:postgresql://localhost:5432/postgresdb --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter

12.15.4. PostgreSQL XA データソースの例

以下は、XA データソースプロパティー、基本のセキュリティー、およびバリデーションオプションが含まれる PostgreSQL XA データソースの設定例になります。

例: PostgreSQL XA データソースの例
<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <xa-datasource-property name="ServerName">
      localhost
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
      5432
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
      postgresdb
    </xa-datasource-property>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="com.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: PostgreSQL JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.postgresql">
  <resources>
    <resource-root path="postgresql-9.3-1102.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. PostgreSQL JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.postgresql --resources=/path/to/postgresql-9.3-1102.jdbc4.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. PostgreSQL JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,driver-module-name=com.postgresql,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
  3. PostgreSQL XA データソースを追加します。

    xa-data-source add --name=PostgresXADS --jndi-name=java:jboss/PostgresXADS --driver-name=postgresql --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --xa-datasource-properties={"ServerName"=>"localhost","PortNumber"=>"5432","DatabaseName"=>"postgresdb"}

12.15.5. Oracle データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる Oracle データソースの設定例になります。

例: Oracle データソースの例
<datasources>
  <datasource jndi-name="java:jboss/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
        <user-name>admin</user-name>
        <password>admin</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
        <validate-on-match>true</validate-on-match>
        <background-validation>false</background-validation>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
        <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: Oracle JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
    <resources>
        <resource-root path="ojdbc7.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. Oracle JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.oracle --resources=/path/to/ojdbc7.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. Oracle JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)
  3. Oracle データソースを追加します。

    data-source add --name=OracleDS --jndi-name=java:jboss/OracleDS --driver-name=oracle --connection-url=jdbc:oracle:thin:@localhost:1521:XE --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter

12.15.6. Oracle XA データソースの例

重要

Oracle XA データソースにアクセスするユーザーは、以下の設定を適用しないと XA リカバリーが適切に操作しません。値 user は、JBoss EAP から Oracle に接続するために定義されたユーザーです。

  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user;

以下は、XA データソースプロパティー、基本のセキュリティー、およびバリデーションオプションが含まれる Oracle XA データソースの設定例になります。

例: Oracle XA データソースの設定
<datasources>
  <xa-datasource jndi-name="java:jboss/OracleXADS" pool-name="OracleXADS">
    <xa-datasource-property name="URL">
      jdbc:oracle:thin:@oracleHostName:1521:orcl
    </xa-datasource-property>
    <driver>oracle</driver>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"/>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: Oracle JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
    <resources>
        <resource-root path="ojdbc7.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. Oracle JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.oracle --resources=/path/to/ojdbc7.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. Oracle JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=oracle:add(driver-name=oracle,driver-module-name=com.oracle,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource)
  3. Oracle XA データソースを追加します。

    xa-data-source add --name=OracleXADS --jndi-name=java:jboss/OracleXADS --driver-name=oracle --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter --same-rm-override=false --xa-datasource-properties={"URL"=>"jdbc:oracle:thin:@oracleHostName:1521:orcl"}

12.15.7. Microsoft SQL Server データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる Microsoft SQL Server データソースの設定例になります。

例: Microsoft SQL Server データソースの設定
<datasources>
  <datasource jndi-name="java:jboss/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"/>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: Microsoft SQL Server JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc42.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
    <module name="javax.xml.bind.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. Microsoft SQL Server の JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.microsoft --resources=/path/to/sqljdbc42.jar --dependencies=javax.api,javax.transaction.api,javax.xml.bind.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. Microsoft SQL Server の JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-xa-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerXADataSource)
  3. Microsoft SQL Server データソースを追加します。

    data-source add --name=MSSQLDS --jndi-name=java:jboss/MSSQLDS --driver-name=sqlserver --connection-url=jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter

12.15.8. Microsoft SQL Server XA データソースの例

以下は、XA データソースプロパティー、基本のセキュリティー、およびバリデーションオプションが含まれる Microsoft SQL Server XA データソースの設定例になります。

例: Microsoft SQL Server XA データソースの設定
<datasources>
  <xa-datasource jndi-name="java:jboss/MSSQLXADS" pool-name="MSSQLXADS">
    <xa-datasource-property name="ServerName">
      localhost
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
      mssqldb
    </xa-datasource-property>
    <xa-datasource-property name="SelectMethod">
      cursor
    </xa-datasource-property>
    <driver>sqlserver</driver>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"/>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: Microsoft SQL Server JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc42.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
    <module name="javax.xml.bind.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. Microsoft SQL Server の JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.microsoft --resources=/path/to/sqljdbc42.jar --dependencies=javax.api,javax.transaction.api,javax.xml.bind.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. Microsoft SQL Server の JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-xa-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerXADataSource)
  3. Microsoft SQL Server XA データソースを追加します。

    xa-data-source add --name=MSSQLXADS --jndi-name=java:jboss/MSSQLXADS --driver-name=sqlserver --user-name=admin --password=admin --validate-on-match=true --background-validation=false --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter --same-rm-override=false --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mssqldb","SelectMethod"=>"cursor"}

12.15.9. IBM DB2 データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる IBM DB2 データソースの設定例になります。

例: IBM DB2 データソースの設定
<datasources>
  <datasource jndi-name="java:jboss/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2://localhost:50000/ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"/>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
        <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: IBM DB2 JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. IBM DB2 の JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.ibm --resources=/path/to/db2jcc4.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. IBM DB2 の JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm,driver-xa-datasource-class-name=com.ibm.db2.jcc.DB2XADataSource)
  3. IBM DB2 データソースを追加します。

    data-source add --name=DB2DS --jndi-name=java:jboss/DB2DS --driver-name=ibmdb2 --connection-url=jdbc:db2://localhost:50000/ibmdb2db --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter --min-pool-size=0 --max-pool-size=50

12.15.10. IBM DB2 XA のデータソースの例

以下は、XA データソースプロパティー、基本のセキュリティー、およびバリデーションオプションが含まれる IBM DB2 XA データソースの設定例になります。

例: IBM DB2 XA データソースの設定
<datasources>
  <xa-datasource jndi-name="java:jboss/DB2XADS" pool-name="DB2XADS">
    <xa-datasource-property name="ServerName">
      localhost
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
      ibmdb2db
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
      50000
    </xa-datasource-property>
    <xa-datasource-property name="DriverType">
      4
    </xa-datasource-property>
    <driver>ibmdb2</driver>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">
          false
        </config-property>
        <config-property name="IsValidOverride">
          false
        </config-property>
        <config-property name="EnableClose">
          false
        </config-property>
      </recover-plugin>
    </recovery>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"/>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
        <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: IBM DB2 JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. IBM DB2 の JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.ibm --resources=/path/to/db2jcc4.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. IBM DB2 の JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm,driver-xa-datasource-class-name=com.ibm.db2.jcc.DB2XADataSource)
  3. IBM DB2 XA データソースを追加します。

    xa-data-source add --name=DB2XADS --jndi-name=java:jboss/DB2XADS --driver-name=ibmdb2 --user-name=admin --password=admin --validate-on-match=true --background-validation=false --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter --same-rm-override=false --recovery-plugin-class-name=org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin --recovery-plugin-properties={"EnableIsValid"=>"false","IsValidOverride"=>"false","EnableClose"=>"false"} --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"ibmdb2db","PortNumber"=>"50000","DriverType"=>"4"}

12.15.11. Sybase データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる Sybase データソースの設定例になります。

例: Sybase データソースの設定
<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <driver>sybase</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"/>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: Sybase JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
    <resources>
      <resource-root path="jconn4.jar"/>
    </resources>
    <dependencies>
      <module name="javax.api"/>
      <module name="javax.transaction.api"/>
    </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. Sybase JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.sybase --resources=/path/to/jconn4.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. Sybase JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=sybase:add(driver-name=sybase,driver-module-name=com.sybase,driver-xa-datasource-class-name=com.sybase.jdbc4.jdbc.SybXADataSource)
  3. Sybase データソースを追加します。

    data-source add --name=SybaseDB --jndi-name=java:jboss/SybaseDB --driver-name=sybase --connection-url=jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6 --user-name=admin --password=admin --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter

12.15.12. Sybase XA データソースの例

以下は、XA データソースプロパティー、基本のセキュリティー、およびバリデーションオプションが含まれる Sybase XA データソースの設定例になります。

例: Sybase XA データソースの設定
<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS">
    <xa-datasource-property name="ServerName">
      localhost
    </xa-datasource-property>
    <xa-datasource-property name="DatabaseName">
      mydatabase
    </xa-datasource-property>
    <xa-datasource-property name="PortNumber">
      4100
    </xa-datasource-property>
    <xa-datasource-property name="NetworkProtocol">
      Tds
    </xa-datasource-property>
    <driver>sybase</driver>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"/>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"/>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
例: Sybase JDBC ドライバーの module.xml ファイル
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
    <resources>
      <resource-root path="jconn4.jar"/>
    </resources>
    <dependencies>
      <module name="javax.api"/>
      <module name="javax.transaction.api"/>
    </dependencies>
</module>
管理 CLI コマンドの例

以下の管理 CLI コマンドを使用すると、この設定例を実現できます。

  1. Sybase JDBC ドライバーをコアモジュールとして追加します。

    module add --name=com.sybase --resources=/path/to/jconn4.jar --dependencies=javax.api,javax.transaction.api
    重要

    module 管理 CLI コマンドを使用したモジュールの追加および削除は、テクノロジープレビューとしてのみ提供されます。このコマンドは、管理対象ドメインでの使用や、リモートによる管理 CLI への接続時には適していません。本番環境ではモジュールを手作業で 追加 および 削除 してください。

    テクノロジープレビューの機能は、Red Hat の本番環境のサービスレベルアグリーメント (SLA) ではサポートされず、機能的に完全ではないことがあるため、Red Hat は本番環境での使用は推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。

    テクノロジープレビュー機能のサポート範囲については、Red Hat カスタマーポータルの「テクノロジープレビュー機能のサポート範囲」を参照してください。

  2. Sybase JDBC ドライバーを登録します。

    /subsystem=datasources/jdbc-driver=sybase:add(driver-name=sybase,driver-module-name=com.sybase,driver-xa-datasource-class-name=com.sybase.jdbc4.jdbc.SybXADataSource)
  3. Sybase XA データソースを追加します。

    xa-data-source add --name=SybaseXADS --jndi-name=java:jboss/SybaseXADS --driver-name=sybase --user-name=admin --password=admin --validate-on-match=true --background-validation=false --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter --same-rm-override=false --xa-datasource-properties={"ServerName"=>"localhost","DatabaseName"=>"mydatabase","PortNumber"=>"4100","NetworkProtocol"=>"Tds"}

12.15.13. MariaDB データソースの例

以下は、接続情報、基本のセキュリティー、およびバリデーションオプションが含まれる MariaDB データソースの設定例になります。

例: MariaDB データソースの設定