設定ガイド

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

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

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

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

中断

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

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

再開

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

:resume

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

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

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

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

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

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

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

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

JBoss EAP をスタンドアロンサーバーとして起動 (RPM インストール)

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

管理対象ドメインでの JBoss EAP の起動 (RPM インストール)

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

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

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

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

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

JBoss EAP をスタンドアロンサーバーとして停止 (RPM インストール)

管理対象ドメインでの JBoss EAP の停止 (RPM インストール)

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

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

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

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

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

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'

代替プロパティーファイルの指定

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

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

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

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

$ 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 ユーティリティー引数 の項を参照してください。

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

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

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

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

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):

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

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

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

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

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

管理 CLI の起動

$ EAP_HOME/bin/jboss-cli.sh

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

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

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

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

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

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

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

/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)

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

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

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

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

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 を使用したアプリケーションのデプロイ を参照してください

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

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

// 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();

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

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

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

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

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

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

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

サーバーの保守や管理をしやすくするため、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)

スナップショットを用いたサーバーの起動

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

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 つの操作の詳細を表しています。

管理コンソールからの設定変更の追跡および表示

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

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

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

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

以下の例では、jboss.bind.address パラメーターが設定されていなければ、standalone.xml 設定ファイルによって public インターフェイスの inet-address が 127.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 フラグによって制御され、デフォルトで有効になっています。有効にすると、以下のデプロイメント記述子でプロパティーを置換できます。

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

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

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

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

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

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 つ以上コマンドラインに渡します。

ローカル 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>

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

$ 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 使用時のリモート設定データの公開

管理 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"}

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

ls /path

ls /host=HOST_NAME/server=SERVER_NAME/path

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

/path=PATH_NAME:read-resource

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

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

管理対象ドメインの標準パスの上書き

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

この設定を行うには、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

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

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

<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>

監査ロギングはデフォルトでは無効になっていますが、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 に書き込まれます。

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 監査ロギングを有効にすることができます。

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

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

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

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

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

上記の 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 に変わったことがわかります。

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

上記の 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 に変わったことがわかります。

<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 スイッチを使用することができます。サーバー起動オプションの詳細は、サーバーランタイム引数 を参照してください。

ネットワークインターフェイスは、物理インターフェイスの論理名および選択基準を指定して宣言されます。選択基準はワイルドカードアドレスを参照したり、一致が有効となるためにインターフェイスまたはアドレスで必要となる 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>

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

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

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

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

スタンドアロンサーバー

スタンドアロンサーバーとして実行されている場合、設定ファイルごとに 1 つのソケットバインディンググループのみが定義されます。各スタンドアロン設定ファイル (standalone.xml、standalone-ha.xml、standalone-full.xml、standalone-full-ha.xml、standalone-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 つあります。

各ソケットバインディンググループは、対応するプロファイルによって使用される技術のソケットバインディングを指定します。たとえば、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>

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

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

以下の例は、上記の手順の完了後に 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>

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

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

ポートオフセットとは、該当するサーバーのソケットバインディンググループに指定されたすべてのポート値に追加される数値のオフセットのことです。これにより、同じホストの別のサーバーとの競合を防ぐため、サーバーはソケットバインディンググループに定義されたポート値とオフセットを継承できるようになります。たとえば、ソケットバインディンググループの 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

アプリケーションのデプロイ

管理 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 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 コマンドを使用して、デプロイメントをすべて表示することもできます。

アプリケーションのデプロイ

管理 CLI で deployment deploy-file コマンドを使用し、アプリケーションデプロイメントへのパスを指定します。また、アプリケーションをデプロイするサーバーグループを指定する必要もあります。

正常にデプロイされると、管理 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 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 コマンドを使用して、ドメインのデプロイメントをすべて表示することもできます。

JBoss EAP 管理コンソールの Deployments タブからデプロイメントを表示および管理できます。

アプリケーションのデプロイ

追加 (+) ボタンをクリックします。デプロイメントのアップロード、未管理デプロイメントの追加、または 空のデプロイメントの作成 を選択して、アプリケーションをデプロイできます。デプロイメントはデフォルトで有効になります。

アプリケーションのアンデプロイ

デプロイメントを選択し、Undeploy オプションを選びます。JBoss EAP により、コンテンツリポジトリーからデプロイメントが削除されます。

アプリケーションの無効化

デプロイメントを選択し、無効オプションを選択してアプリケーションを無効にします。これにより、デプロイメントがアンデプロイされますが、コンテンツリポジトリーから削除されません。

アプリケーションの置換

デプロイメントを選択し、置換オプションを選択します。元のバージョンと同じ名前を持つ新しいバージョンのデプロイメントを選択し、Finish をクリックします。これにより、元のバージョンのデプロイメントがアンデプロイおよび削除され、新しいバージョンがデプロイされます。

JBoss EAP 管理コンソールの Deployments タブではデプロイメントを表示および管理できます。

アプリケーションの追加

アプリケーションのサーバーグループへのデプロイ

アプリケーションのサーバーグループからのアンデプロイ

また、Content Repository でデプロイメントの Undeploy ボタンを選択して、複数のサーバーグループから 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

デプロイメントスキャナーは管理コンソールまたは管理 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 コンテンツの自動デプロイメントを無効にします。

新しいデプロイメントスキャナーを追加するには、管理 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)

新しいデプロイメントスキャナーが定義され、デプロイメントを確認するために指定のディレクトリーが監視されます。

以下の手順では、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")

以下の手順では、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")

デフォルトでは、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 ナレッジベースの記事 を参照してください。

デフォルトでは、HTTP API は http://HOST:PORT/management でアクセスできます (例: http://localhost:9990/management)。

アプリケーションのデプロイ

アプリケーションのアンデプロイ

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 インスタンスすべてで一意になる必要があります。

管理対象ドメインでのカスタムディレクトリーの定義

デフォルトでは、管理対象ドメインのデプロイされたコンテンツは 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 インスタンスすべてで一意になる必要があります。

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>

これにより、app.ear の前に framework.ear がデプロイされます。

デプロイメントオーバーレイ を使用すると、デプロイメントアーカイブのコンテンツを物理的に変更せずに既存デプロイメントにコンテンツをオーバーレイすることができます。これにより、アーカイブを再構築せずに実行時にデプロイメント記述子、ライブラリー JAR ファイル、クラス、JSP ページ、およびその他のファイルをオーバーライドできます。

これは、異なる設定が必要な異なる環境にデプロイメントを適応する必要がある場合に便利です。たとえば、アプリケーションのライフサイクルに従って開発からテスト、ステージ、および実稼働とデプロイメントを移動する場合、目的の環境に応じてデプロイメント記述子の交換、アプリケーションのブランディングを変更するための静的 Web リソースの変更、JAR ライブラリーの別バージョンへの置き換えなどを行う可能性があります。また、方針やセキュリティーの制限によりアーカイブを変更できない、設定変更が必要なインストールにも便利な機能です。

デプロイメントオーバーレイを定義する場合、デプロイメントアーカイブのファイルを置き換える、ファイルシステム上のファイルを定義します。さらに、デプロイメントオーバーレイの影響を受けるデプロイメントを指定する必要もあります。変更を有効にするには、影響を受けるデプロイメントを再デプロイする必要があります。

使用方法の詳細を表示するには deployment-overlay --help を実行してください。

ロールアウト計画

管理対象ドメインでは、ドメインまたはホストレベルのリソースで目的となる操作は複数のサーバーに影響する可能性があります。このような操作には、サーバーに適用される操作の順序を説明するロールアウト計画や、一部のサーバーで実行に失敗した場合に操作を元に戻すかどうかを指示するポリシーなどが含まれます。指定されたロールアウト計画がない場合、デフォルトのロールアウト計画 が使用されます。

以下は 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 つの段階を経てドメインのサーバーに操作が適用されることが分かります。あるサーバーグループのポリシーによってサーバーグループ全体で操作のロールバックが引き起こされると、他のサーバーグループもすべてロールバックされます。

ロールアウト計画の構文

ロールアウト計画は以下のいずれかの方法で指定できます。

上記の方法で最初に使用するコマンドは異なりますが、どちらも rollout 操作ヘッダーを使用してロールアウト計画を定義します。以下の構文を使用します。

rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]

ロールアウト計画を使用したデプロイ

ロールアウト計画の完全詳細を直接 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)}

保存したロールアウト計画を使用したデプロイ

ロールアウト計画は複雑になることがあるため、ロールアウト計画の詳細を保存するオプションがあります。これにより、毎回ロールアウト計画の完全詳細を必要とせずに、ロールアウト計画を使用するときにロールアウト計画の名前を参照することができます。

保存されたロールアウト計画の削除

削除するロールアウト計画の名前を指定して rollout-plan 管理 CLI コマンドを使用すると、保存されたロールアウト計画を削除できます。

rollout-plan remove --name=my-rollout-plan

デフォルトのロールアウト計画

複数のサーバーに影響する操作はすべてロールアウト計画を使用して実行されます。操作リクエストにロールアウト計画が指定されていない場合は、デフォルトのロールアウト計画が生成されます。計画には以下の特徴があります。

管理されたデプロイメントのファイルやディレクトリーを閲覧するには、browse-content 操作を使用します。引数を指定しないと、デプロイメント構造全体が返されます。 特定のディレクトリーへのパスを指定するには、path 引数を使用します。

/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 操作に指定することもできます。

管理されたデプロイメントでファイルの内容を読み取るには、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"
    }]}
}

attachment display --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF)

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
...

attachment save --operation=/deployment=helloworld.war:read-content(path=META-INF/MANIFEST.MF) --file=/path/to/MANIFEST.MF

ドメインコントローラーは、ドメインの集中管理点として動作する JBoss EAP サーバーインスタンスです。1 つのホストコントローラーインスタンスがドメインコントローラーとして動作するよう設定されます。

ドメインコントローラーの主なロールは次のとおりです。

デフォルトでは、集中管理ポリシーは EAP_HOME/domain/configuration/domain.xml ファイルに格納されます。このファイルは、ドメインコントローラーとして実行するよう設定されたホストコントローラーのこのディレクトリーに必要です。

domain.xml ファイルには、ドメインのサーバーに適用できるプロファイル設定が含まれています。プロファイル には、そのプロファイルで使用できるさまざまなサブシステムの詳細設定が含まれています。ドメイン設定には、ソケットグループの定義とサーバーグループの定義も含まれます。

詳細は 管理対象ドメインの起動 および ドメインコントローラーの設定 の項を参照してください。

ホストコントローラーの主なロールはサーバーを管理することです。ドメイン管理タスクを委譲し、ホスト上で実行される個別のアプリケーションサーバープロセスを開始および停止します。

ホストコントローラーはドメインコントローラーと対話し、サーバーとドメインコントローラー間の通信を管理できるようにします。ドメインの複数のホストコントローラーは 1 つのドメインコントローラーのみと対話できます。そのため、単一のドメインモード上で実行されるホストコントローラーおよびサーバーインスタンスはすべて単一のドメインコントローラーを持ち、同じドメインに属する必要があります。

デフォルトでは、各ホストコントローラーは、ホストのファイルシステムの未展開の JBoss EAP インストールファイルにある EAP_HOME/domain/configuration/host.xml ファイルから設定を読み取ります。host.xml ファイルには、特定のホストに固有する以下の設定情報が含まれています。

詳細は 管理対象ドメインの起動 および ホストコントローラーの設定 の項を参照してください。

プロセスコントローラーは小型のライトウェイトなプロセスで、ホストコントローラープロセスを起動し、そのライフサイクルを監視します。ホストコントローラーがクラッシュすると、プロセスコントローラーによって再起動されます。さらに、ホストコントローラーの指示に従ってサーバープロセスを開始しますが、クラッシュしたサーバープロセスは自動的に再起動しません。

プロセスコントローラーのログは EAP_HOME/domain/log/process-controller.log ファイルに記録されます。プロセスコントローラーの JVM オプションは、PROCESS_CONTROLLER_JAVA_OPTS 変数を使用して EAP_HOME/bin/domain.conf ファイルに設定します。

サーバーグループとは、1 つのグループとして管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、各アプリケーションサーバーインスタンスは唯一のメンバーである場合でも 1 つのサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイされたコンテンツを共有します。

ドメインコントローラーとホストコントローラーは、ドメインにある各サーバーグループのすべてのインスタンスに標準設定を強制します。

ドメインを複数のサーバーグループで設定できます。異なるサーバーグループを異なるプロファイルやデプロイメントで設定できます。たとえば、ドメインは異なるサービスを提供する異なるサーバー層で設定できます。

異なるサーバーグループが同じプロファイルやデプロイメントを持つこともできます。これにより、最初のサーバーグループでアプリケーションがアップグレードされた後に 2 つ目のサーバーグループでアプリケーションが更新されるアプリケーションのローリングアップグレードが可能になり、サービスの完全停止を防ぎます。

詳細は、サーバーグループの設定 の項を参照してください。

サーバーはアプリケーションサーバーインスタンスを表します。管理対象ドメインでは、すべてのサーバーインスタンスがサーバーグループのメンバーになります。ホストコントローラーは各サーバーインスタンスを独自の JVM プロセスで起動します。

詳細は サーバーの設定 の項を参照してください。

ドメインおよびホストコントローラーは、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

ドメインの設定に応じて、ドメインコントローラーへ接続し、ドメインコントローラーとの競合を回避するために設定を追加する必要があります。また、以下のドメイン設定例を参照してください。

ドメイン内のホストをドメインコントローラーとして設定する必要があります。

<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) には、以下の設定が含まれます。

ホストコントローラー自体をドメインに登録するようにホストコントローラーを設定する必要があります。

設定の <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 台のマシンで管理対象ドメインを設定 を参照してください。

管理対象ドメインで実行されている各ホストには一意な名前を付ける必要があります。管理を容易にし、複数のホストで同じホスト設定ファイルを使用できるようにするために、以下の優先順位を用いてホスト名が決定されます。

関連する host.xml 設定ファイルの上部にある host 要素に設定されたホストコントローラーの名前。 例は次のとおり。

<host xmlns="urn:jboss:domain:8.0" name="host1">

以下の手順に従って、管理 CLI を使用してホスト名を更新します。

ホストコントローラーの名前が設定ファイルに設定されていない場合は、起動時にホスト名を渡すこともできます。

$ EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.host.name=HOST_NAME

以下はサーバーグループ定義の例になります。

<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

サーバーグループ属性

サーバーグループには次の属性が必要です。

サーバーグループに含まれる任意の属性は次のとおりです。

デフォルトの 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-start を false に設定します。

サーバーの設定は、管理 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

サーバーの属性

サーバーには以下の属性が必要です。

サーバーには以下の任意の属性が含まれます。

管理コンソールから起動、停止、リロードなどの操作をサーバーで実行するには、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

以下は、ドメインコントローラー検索の複数のオプションを持つホストコントローラーを設定する方法の例になります。

<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>

静的検出オプションには、以下の必須属性が含まれます。

上記の例では、最初の検出オプションが指定されることが予想されます。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 を使用してこのホストコントローラーを起動したときにドメインコントローラーを利用できない場合、ホストコントローラーは domain.cached-remote.xml ファイルに保存されたキャッシュされた設定の使用を開始します。このファイルが存在しないとホストコントローラーは起動しないことに注意してください。

この状態の間、ホストコントローラーはドメイン設定を編集できませんが、サーバーを開始したり、デプロイメントを管理することはできます。

ホストコントローラーがキャッシュされた設定を使用して起動されると、ホストコントローラーは継続してドメインコントローラーへの再接続を試みます。ドメインコントローラーが使用できるようになると、ホストコントローラーは自動的にドメインコントローラーに再接続し、ドメイン設定を同期化します。変更された設定によっては、変更の反映のにホストコントローラーのリロードが必要になることがあります。この場合、警告がホストコントローラーのログに記録されます。

主要のドメインコントローラーに問題が発生した場合に、ホストコントローラーがドメインコントローラーとして動作するよう昇格できます。ホストコントローラーを 昇格 する前に、ドメインコントローラーから ドメイン設定をローカルでキャッシュ する必要があります。

ドメイン設定のキャッシュ

ドメインコントローラーとして使用したいホストコントローラーに --backup オプションを使用します。

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

これにより、ドメイン設定全体のコピーが含まれる EAP_HOME/domain/configuration/ ディレクトリーに domain.cached-remote.xml ファイルが作成されます。この設定は、ホストコントローラーがドメインコントローラーとして動作するよう再設定された場合に使用されます。

<domain-controller>
  <remote username="$local" security-realm="ManagementRealm" ignore-unused-configuration="false">
    <discovery-options>
      ...
    </discovery-options>
  </remote>
</domain-controller>

ホストコントローラーをドメインコントローラーに昇格

このホストコントローラーがドメインコントローラーとして動作するようになります。

jboss.domain.base.dir プロパティーを使用すると 1 台のマシンで複数のホストコントローラーを実行できます。

このように起動された各インスタンスは、ベースインストールディレクトリー (例: EAP_HOME/modules/) のその他のリソースを共有しますが、jboss.domain.base.dir によって指定されたディレクトリーからドメイン設定を使用します。

1 台がドメインコントローラーでもう 1 台がホストである 2 台のマシンで管理対象ドメインを作成できます。詳細は、ドメインコントローラー を参照してください。

2 台のマシンで管理対象ドメインを作成

起動時に --controller パラメーターを使用してドメインコントローラーアドレスを指定し、管理 CLI からドメインを管理できるようになります。

$ EAP_HOME/bin/jboss-cli.sh --connect --controller=IP1

また、http://IP1:9990 で管理コンソールからドメインを管理することもできます。

JBoss EAP 7.1 ドメインコントローラーは、実行している JBoss EAP 6 のバージョンが JBoss EAP 6.2 以上のホストおよびサーバーを管理できます。

JBoss EAP 7 の管理対象ドメインで JBoss EAP 6 インスタンスを正常に管理するには、以下の作業を行います。

これらの作業が終了したら、管理 CLI を使用して JBoss EAP 7 ドメインコントローラーから JBoss EAP 6 サーバーおよび設定を管理できます。JBoss EAP 6 ホストは、バッチ処理などの JBoss EAP 7 の新機能を利用できないことに注意してください。

<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>

/host-exclude=EAP64z:write-attribute(name=active-server-groups,value=[eap6-main-server-group])

JBoss EAP 7.3 ドメインコントローラーは、以前の JBoss EAP のマイナーリリースからの実行中のホストおよびサーバーを管理できます。

JBoss EAP 7.3 の管理対象ドメインで JBoss EAP 7.2 インスタンスを正常に管理するには、以下の作業を行います。

これらの作業の完了後に、管理 CLI を使用して JBoss EAP 7.3 ドメインコントローラーから JBoss EAP 7.2 サーバーおよび設定を管理できます。

<servers>
    <server name="server-one" group="eap72-main-server-group"/>
    <server name="server-two" group="eap72-main-server-group">
        <socket-bindings port-offset="150"/>
    </server>
</servers>

<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>

JBoss EAP は、プロファイルを使用してサーバーが使用できるサブシステムを整理します。プロファイルは、利用可能なサブシステムと各サブシステムの特定の設定で設定されます。プロファイルのサブシステムの数が多いと、サーバーの機能が多くなります。プロファイルのサブシステムが集中的で数が少ないと、機能が少なくなりますが、フットプリントも少なくなります。

JBoss EAP にはほとんどのユースケースに対応する事前定義されたプロファイルが 5 つあります。

既存のプロファイルが必要な機能を提供しない場合、JBoss EAP はカスタムプロファイルを定義する機能も提供します。

JBoss EAP では、既存のプロファイルをクローンして管理対象ドメインで新しいプロファイルを作成することができます。クローンした既存プロファイルの設定およびサブシステムのコピーが作成されます。

管理 CLI を使用してプロファイルをクローンするには、クローンするプロファイルに clone 操作を実行します。

/profile=full-ha:clone(to-profile=cloned-profile)

管理コンソールからプロファイルをクローンするには、クローンするプロファイルを選択し、Clone をクリックします。

管理対象ドメインでは、プロファイルの階層を作成できます。これにより、他のプロファイルが継承できる共通のエクステンションが含まれるベースプロファイルを作成できます。

管理対象ドメインは domain.xml の複数のプロファイルを定義します。複数のプロファイルが特定のサブシステムで同じ設定を使用する場合、複数のプロファイルで設定せずに、1 つのプロファイルで設定を行うことができます。親プロファイルの値はオーバーライドできません。

さらに、各プロファイルは他に依存しなくてもすむ必要があります。要素やサブシステムが参照される場合、参照されるプロファイルに定義する必要があります。

管理 CLI を使用して list-add 操作を実行し、含めるプロファイルを指定すると、プロファイルに階層の別のプロファイルを含めることができます。

/profile=new-profile:list-add(name=includes, value=PROFILE_NAME)

ホストコントローラーの 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 設定を作成および編集するには、Runtime → Hosts と選択し、ホストを選択して 表示 をクリックし、JVMs タブを選択します。

これらの設定は host.xml の <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")

上記コマンドの実行後、サーバーグループ groupA は production_jvm から JVM 設定を継承しますが、ヒープサイズの値は 1024m にオーバーライドされます。

使用できるすべてのオプションの説明は 管理対象ドメインの JVM 設定属性 を参照してください。

また、JBoss EAP 管理コンソールでサーバーグループの JVM 設定を編集するには、Runtime → Server Groups と選択し、サーバーグループを選択して 表示 をクリックし、JVMs タブを選択します。

サーバーグループの設定は domain.xml に保存されます。

デフォルトでは、個別の 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 設定を作成編集するには、Runtime → Hosts と選択し、ホストを選択して 表示 をサーバー上でクリックし、JVMs タブを選択します。

各サーバーのこれらの設定は host.xml に保存されます。

デフォルトでは、すべての JBoss EAP ログエントリーは server.log ファイルに書き込みされます。このファイルの場所は操作するモードによって異なります。

このファイルはサーバーログとも呼ばれます。詳細は ルートロガー を参照してください。

起動中に JBoss EAP は Java 環境と各サービスの起動に関する情報をログに記録します。このログは、トラブルシューティングに役に立ちます。デフォルトでは、すべてのログエントリーが サーバーログ に書き込まれます。

起動時のロギング設定は logging.properties 設定ファイルに指定されます。これは、JBoss EAP logging が開始され、継承するまでアクティブになります。このファイルの場所は操作するモードによって異なります。

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
        ...

/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"}
        }
        ...
    ]
}

ガベッジコレクションロギングは、すべてのガベッジコレクションのアクティビティーをプレーンテキストのログファイルに記録します。これらのログファイルは診断を行うのに便利です。ガベッジコレクションロギングは、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

以下のログファイルは、デフォルトのロギング設定に対して作成されます。デフォルトの設定では、periodic ログハンドラーを使用してサーバーログファイルが書き込まれます。

JVM プロパティーを適切な起動設定ファイルに設定すると、デフォルトのロケールを設定できます。起動設定ファイルは、スタンドアロンサーバーの場合は EAP_HOME/bin/standalone.conf、管理対象ドメインの場合は EAP_HOME/bin/domain.conf になります。

国際化または現地化されたログメッセージはこのデフォルトロケールを使用します。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"

JBoss EAP のルートロガーは、ログカテゴリーによってキャプチャーされないサーバーへ送信されたすべてのログメッセージ (指定のログレベル以上) をキャプチャーします。

デフォルトでは、ルートロガーはコンソールおよび周期ログハンドラーを使用するように設定されます。周期ログハンドラーは、server.log ファイルへ書き込むよう設定されます。このファイルはサーバーログとも呼ばれます。

詳細は ルートロガーの設定 を参照してください。

ログカテゴリーは、キャプチャーするログメッセージのセットと、メッセージを処理する 1 つ以上のログハンドラーを定義します。

キャプチャーするログメッセージは、指定された元の Java パッケージとログレベルによって定義されます。そのパッケージのクラスおよびそのログレベル以上のメッセージがログカテゴリーによってキャプチャーされ、指定のログハンドラーに送信されます。

ログカテゴリーは、独自のハンドラーの代わりにルートロガーのログハンドラーを任意で使用することができます。

詳細は ログカテゴリーの設定 を参照してください。

ログハンドラーはキャプチャーしたメッセージの記録方法を定義します。使用できるログハンドラーの種類は console、file、periodic、size、periodic size、syslog、 custom、および async です。

ログハンドラーの種類

各ログハンドラーの設定に関する詳細は、ログハンドラーの設定 の項を参照してください。

ログレベルとは、ログメッセージの性質と重大度を示す列挙値です。特定のログメッセージのレベルは、そのメッセージを送信するために選択したロギングフレームワークの適切なメソッドを使用して開発者が指定できます。

JBoss EAP は、サポートされるアプリケーションロギングフレームワークによって使用されるすべてのログレベルをサポートします。最も一般的に使用されるログレベルは、ログレベルの低い順に TRACE、DEBUG、INFO、WARN、ERROR および FATAL となります。

ログレベルはログカテゴリーとログハンドラーによって使用され、それらが担当するメッセージを限定します。各ログレベルには、他のログレベルに対して相対的な順番を示す数値が割り当てられています。ログカテゴリーとハンドラーにはログレベルが割り当てられ、そのレベル以上のログメッセージのみを処理します。たとえば、WARN レベルのログハンドラーは、WARN、ERROR、および FATAL のレベルのメッセージのみを記録します。

サポート対象のログレベル

フォーマッターはログメッセージのフォーマットに使用されます。named-formatter 属性を使用するとフォーマッターをログハンドラーに割り当てできます。ログハンドラー設定の詳細は ログハンドラーの設定 を参照してください。

logging サブシステムには 4 種類のフォーマッターが含まれます。

パターンフォーマッター

パターンフォーマッターは、ログメッセージをプレーンテキストでフォーマットするために使用されます。ログハンドラーの named-formatter 属性としてフォーマットを使用する他に、あらかじめフォーマッターリソースを作成する必要なく formatter 属性として使用することもできます。パターン構文に関する詳細は パターンフォーマッターのフォーマット文字 を参照してください。

パターンフォーマッターの設定方法は パターンフォーマッターの設定 を参照してください。

JSON フォーマッター

JSON フォーマッターは、ログメッセージを JSON 形式でフォーマットするために使用されます。

JSON フォーマッターの設定方法は JSON フォーマッターの設定 を参照してください。

XML フォーマッター

XML ログフォーマッターは、ログメッセージを XML 形式でフォーマットするために使用されます。

XML フォーマッターの設定方法は XML フォーマッターの設定 を参照してください。

カスタムフォーマッター

ハンドラーと使用するカスタムフォーマッターです。ほとんどのログレコードは printf 形式でフォーマットされることに注意してください。メッセージを適切にフォーマットするには、org.jboss.logmanager.ExtLogRecord#getFormattedMessage() の呼び出しが必要になることがあります。

カスタムログフォーマッターの設定方法は カスタムログフォーマッターの設定 を参照してください。

フィルター式は filter-spec 属性を使用して設定され、さまざまな基準に基づいてログメッセージを記録するために使用されます。フィルターチェックは、常に未フォーマットの raw メッセージに対して行われます。ロガーまたはハンドラーのフィルターを含めることができますが、ハンドラーに配置されたフィルターよりもロガーフィルターが優先されます。

/subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value="substituteAll(\"WFLY\"\,\"YLFW\")")

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開発ガイド の暗黙的なモジュール依存関係の項を参照してください。

ここでは、管理 CLI を使用して Console ログハンドラーを設定する方法を説明します。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Console Handler と選択すると Console ログハンドラーを設定することができます。

Console ログハンドラーを設定するために実行する主なタスクは次のとおりです。

Console ログハンドラーの追加

/subsystem=logging/console-handler=CONSOLE_HANDLER_NAME:add

Console ログハンドラーの設定

必要性に応じて、以下の Console ログハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Console ログハンドラー属性の完全リストと説明は、Console ログハンドラーの属性 を参照してください。

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

ここでは、管理 CLI を使用して File ログハンドラーを設定する方法を説明します。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → File Handler と選択すると、File ログハンドラーを設定することができます。

File ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

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 ログハンドラーの属性 を参照してください。

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

ここでは、管理 CLI を使用して Periodic rotating ログハンドラーを設定する方法を説明します。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Periodic Handler と選択すると、Periodic ログハンドラーを設定することができます。

Periodic ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

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 ログハンドラーの属性 を参照してください。

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

ここでは、管理 CLI を使用して Size rotating ログハンドラーを設定する方法を説明します。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Size Handler と選択すると、Size ログハンドラーを設定することができます。

Size ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

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 ログハンドラーの属性 を参照してください。

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

ここでは、管理 CLI を使用して Periodic Size rotating ログハンドラーを設定する方法を説明します。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Periodic Size Handler と選択すると、Periodic Size ログハンドラーを設定することができます。

Periodic Size ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

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 ログハンドラーの属性 を参照してください。

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

ここでは、管理 CLI を使用して Syslog ハンドラーを設定する方法を説明します。Syslog ハンドラーを使用すると、Syslog プロトコル (RFC-3164 または RFC-5424) をサポートするリモートロギングサーバーにメッセージを送信できます。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Syslog Handler と選択すると、Syslog ハンドラーを設定することができます。

Syslog ハンドラーを設定するために実行する主なタスクは以下のとおりです。

Syslog ハンドラーの追加

/subsystem=logging/syslog-handler=SYSLOG_HANDLER_NAME:add

Syslog ハンドラーの設定

必要性に応じて、以下の Syslog ハンドラー属性を 1 つ以上設定する必要がある場合があります。利用できる Syslog ハンドラー属性の完全リストと説明は、Syslog ハンドラーの属性 を参照してください。

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

ここでは、管理 CLI を使用して Socket ログハンドラーを設定する方法を説明します。ソケットは TCP または UDP ソケットになります。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Size Handler と選択すると、Size ログハンドラーの設定も可能になります。

Socket ログハンドラーを設定するために実行する主なタスクは以下のとおりです。

ソケットバインディングの追加

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 ログハンドラーの属性 を参照してください。

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 EAPHow to Configure Server Security のElytron Subsystemを参照してください。

ここでは、管理 CLI を使用してカスタムログハンドラーを設定する方法を説明します。管理コンソールでは、Configuration → Subsystems → Logging → Configuration と選択し、表示 をクリックして Handler → Custom Handler と選択すると、カスタムログハンドラーを設定することができます。

カスタムログハンドラーを設定するために実行する主なタスクは以下のとおりです。

カスタムログハンドラーの追加

カスタムログハンドラーを追加する場合、ハンドラーの Java クラスとハンドラーが含まれる JBoss EAP モジュールを指定する必要があります。クラスは java.util.logging.Handler を拡張する必要があります。