第3章 JBoss EAP の管理

パラメーターを 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 に変わったことがわかります。