検索

3.6. 設定データ

download PDF

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

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

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

standalone.xml

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

standalone-ha.xml

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

standalone-full.xml

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

standalone-full-ha.xml

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

standalone-load-balancer.xml

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

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

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

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

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

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

domain.xml

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

host.xml

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

host-master.xml

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

host-slave.xml

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

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

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

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

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

  • EAP_HOME/standalone/configuration/

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

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

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

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

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

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

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

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

スナップショットの作成

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

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

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

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

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

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

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

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

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

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

3.6.5. 設定変更の確認

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

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表3.3 Git 設定管理のサーバー起動引数
引数説明

--git-repo

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

--git-branch

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

--git-auth

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

警告

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.