第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 サブシステムに設定されます。

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

サブシステム は特定のエクステンションの設定オプションを提供します。使用できるサブシステムの詳細は、「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)
    • ダッシュ (-)、ピリオド (.)、コンマ (,)、アットマーク(@)
    • バックスラッシュ (\)
    • 等号 (=)

    JBoss EAP はデフォルトで弱いパスワードを許可しますが、警告が出力されます。

    このデフォルト動作の変更に関する詳細は、「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 ファイルを使用して設定できます。

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

EAP_HOME/bin/add-user.properties ファイルで設定できる追加のパスワード要件は次のとおりです。

  • 最小文字数
  • アルファベットの最小文字数
  • 数字の最小文字数
  • シンボルの最大文字数
  • 禁止されたパスワードのリスト (admin など)
  • ユーザー名と一致するパスワードを許可するかどうか

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. 管理インターフェース

3.3.1. 管理 CLI

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

管理 CLI を使用して、サーバーの起動および停止、アプリケーションのデプロイおよびアンデプロイ、システムの設定、他の管理タスクの実行を行います。操作はバッチモードで実行でき、複数のタスクをグループとして実行できます。

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

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

管理 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.3.2. 管理コンソール

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

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

管理対象ドメインでは、同じドメイン内のサーバーインスタンスやサーバーグループをドメインコントローラーの管理コンソールから一元的に管理できます。

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

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

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

管理コンソールのツアーに参加するには、管理コンソールのホームページにある「ツアーをご覧ください」リンクをクリックします。

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

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

  1. Edit ボタンをクリックします。
  2. 必要な変更を追加します。

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

    注記

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

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

    変更を保存するとき、変更の反映にリロードが必要な場合はダイアログが表示されます。スタンドアロンサーバーをリロードするには、ダイアログの Reload Server Now ボタンをクリックします。監理対象ドメインでサーバーをリロードするには、Go to Runtime ボタンをクリックして、適切なサーバーを選択し、ドロップダウンの Reload をクリックします。

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

3.3.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.3.2.3. 管理コンソールの言語の変更

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

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

3.4. 管理 API

3.4.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 の値は、以下の値に置き換えられます。

説明

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.4.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.5. 設定データ

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

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

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

設定ファイル目的

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.5.2. 管理対象ドメイン設定ファイル

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

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

設定ファイル目的

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.5.3. 設定データのバックアップ

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

  • EAP_HOME/standalone/configuration/

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

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

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

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

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

3.5.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.5.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 タブに移動して、スタンドアロンサーバーまたは管理対象ドメインホストを選択し、ドロップダウンメニューで Configuration Changes を選択します。Enable ボタンをクリックし、最大の履歴値を指定します。

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

3.5.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} を評価し、次にこれを外側の大きい式に入力して、結果となる式を評価します。この設定の利点は、データソースの名前が固定された設定から抽象化されることです。

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

データソース接続パラメーターなどのアプリケーションの設定は、通常は開発デプロイメント、テストデプロイメント、および本番環境によって異なります。Java 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)

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

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

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

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

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

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

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

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

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

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

表3.3 標準的なパス

プロパティー説明

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.6.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.6.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.6.3. カスタムパスの追加

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

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

    /path=my.custom.path:add(path=/my/custom/path)
  • 管理コンソールでファイルシステムパスを設定するには Configuration タブで Paths を選択してパスを追加、編集、および削除します。

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

<subsystem xmlns="urn:jboss:domain:logging:3.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.7. ディレクトリーのグループ化

管理対象ドメインでは、各サーバーのファイルは 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.8. システムプロパティー

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 を選択し、View ボタンをクリックします。
  • 管理対象ドメインの場合

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

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

システムプロパティーは 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.9. 管理監査ロギング

管理コンソール、管理 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.9.1. 管理監査ロギングの有効化

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

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.9.2. 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.9.3. 監査ログエントリーの読み取り

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

注記

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

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

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

フィールド名説明

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.10. サーバーライフサイクルイベントの通知

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

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

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

3.10.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.10.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 に変わったことがわかります。