検索

3.6. 設定データ

download PDF

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

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

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

standalone.xml

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

standalone-ha.xml

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

standalone-full.xml

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

standalone-full-ha.xml

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

standalone-load-balancer.xml

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

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

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

3.6.1.1. YAML ファイルを使用してスタンドアロンサーバー設定を更新します。

YAML ファイルを使用してスタンドアロンサーバーを設定すると、カスタマイズプロセスを外部化し、サーバーアップグレードの速度が向上します。この機能を使用する場合、サーバーは読み取り専用モードで起動します。これは、サーバーの再起動後に設定の変更が維持されないことを意味します。

注記

YAML 設定は、管理対象ドメインのサーバーではサポートされ ません

ユーザーは YAML ファイル内のさまざまなリソースを変更できます。以下のリソースは YAML ファイルでサポートされています。

  • core-service
  • interface
  • socket-binding-group
  • subsystem
  • system-property

以下のリソースは、YAML ファイルではサポートされてい ません

  • Extension: 拡張 をサーバーに追加します。この要素は、欠落しているモジュールが必要となる可能性があるため、サポートされていません。
  • Deployment: デプロイメントをサーバーに追加します。この要素は設定に加えてより詳細な変更が必要であるため、サポート対象外です。
  • deployment-overlay: deployment-overlays をサーバーに追加します。この要素は設定に加えてより詳細な変更が必要であるため、サポート対象外です。
  • path: YAML ファイルが解析される際に定義されます。

YAML ルートノードは wildfly-configuration です。モデルツリーに従って、リソースを変更できます。すでにリソースが存在する場合(XML 設定ファイルまたは以前の YAML ファイルによって作成された)、モデルツリーを使用してリソースを更新できます。リソースが存在しない場合は、モデルツリーを使用してリソースを作成できます。

新しい PostGresql データソースを定義する YAML 設定ファイルの例

wildfly-configuration:
  subsystem:
    datasources:
      jdbc-driver:
        postgresql:
          driver-name: postgresql
          driver-xa-datasource-class-name: org.postgresql.xa.PGXADataSource
          driver-module-name: org.postgresql.jdbc
      data-source:
        PostgreSQLDS:
          enabled: true
          exception-sorter-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
          jndi-name: java:jboss/datasources/PostgreSQLDS
          jta: true
          max-pool-size: 20
          min-pool-size: 0
          connection-url: "jdbc:postgresql://localhost:5432}/demo"
          driver-name: postgresql
          user-name: postgres
          password: postgres
          validate-on-match: true
          background-validation: false
          background-validation-millis: 10000
          flush-strategy: FailingConnectionOnly
          statistics-enable: false
          stale-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
          valid-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
          transaction-isolation: TRANSACTION_READ_COMMITTED

上記の例では、postgresql という jdbc-driver と、PostgreSQLDS と呼ばれる データソース を定義します。

注記

YAML 設定ファイルを使用してモジュールを管理することはできません。代わりに、org.postgresql.jdbc モジュールを手動で作成またはプロビジョニングするか、管理 CLI を使用する必要があります。

3.6.1.2. タグを使用した YAML ファイル操作

タグを使用して、YAML 設定ファイルに対して複数の操作を実行できます。

  • !undefine: 属性の定義を解除します

    定義解除 CONSOLE ロガーレベルの YAML 設定ファイルの例

    wildfly-configuration:
        subsystem:
            logging:
              console-handler:
                CONSOLE:
                  level: !undefine

  • !remove : リソースを削除します。

    埋め込み Artemis ブローカーを削除し、リモートブローカーの YAML 設定ファイルの例に接続します。

    wildfly-configuration:
      socket-binding-group:
        standard-sockets:
          remote-destination-outbound-socket-binding:
            remote-artemis:
              host: localhost
              port: 61616
      subsystem:
        messaging-activemq:
          server:
            default: !remove
          remote-connector:
            artemis:
              socket-binding: remote-artemis
          pooled-connection-factory:
            RemoteConnectionFactory:
              connectors:
                - artemis
              entries:
                - "java:jboss/RemoteConnectionFactory"
                - "java:jboss/exported/jms/RemoteConnectionFactory"
              enable-amq1-prefix: false
              user: admin
              password: admin
        ejb3:
          default-resource-adapter-name: RemoteConnectionFactory
        ee:
          service:
            default-bindings:
              jms-connection-factory: "java:jboss/RemoteConnectionFactory"

  • !list-add : 要素をリストに追加します(任意のインデックスを含む)

    RemoteTransactionPermission をパーミッション一覧の YAML 設定ファイルの例に追加します。

    wildfly-configuration:
        subsystem:
            elytron:
              permission-set:
               default-permissions:
                 permissions: !list-add
                  - class-name: org.wildfly.transaction.client.RemoteTransactionPermission
                    module: org.wildfly.transaction.client
                    target-name: "*"
                    index: 0

    注記

    index 属性が定義されていない場合は、エントリーがリストの最後に追加されます。

3.6.1.3. YAML ファイルを使用したスタンドアロンサーバーの起動

YAML 設定ファイルを使用してスタンドアロンサーバーを起動できます。

手順

  1. ターミナルを開きます。
  2. 以下のコマンドを使用して、YAML ファイルでスタンドアロンサーバーを起動します。

    ./standalone.sh -y=/home/ehsavoie/dev/wildfly/config2.yml:config.yml -c standalone-full.xml

    - yaml 引数またはy 引数を使用すると、YAML ファイルのリストを渡すことができます。Windows Server の場合はセミコロン(;)を使用し、Mac および Unix ベースのオペレーティングシステムの場合はコロン(:)を使用して各 YAML ファイルパスを区切る必要があります。絶対パス、現在の実行ディレクトリーへの相対パス、またはスタンドアロン設定ディレクトリーからの相対パスを使用できます。

操作は、ファイルが定義された順序で適用され、初期操作は XML 設定によって定義されます。

3.6.2. マネージドドメイン設定ファイル

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

表3.3 マネージドドメイン設定ファイル
設定ファイル目的

domain.xml

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

host.xml

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

host-master.xml

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

host-slave.xml

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

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

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

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

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

  • EAP_HOME/standalone/configuration/

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

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

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

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

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

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

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

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

スナップショットの作成

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

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

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

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

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

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

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

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

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

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

3.6.5. 設定変更の確認

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

重要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--git-repo

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

--git-branch

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

--git-auth

Elytron 設定ファイルへの URL には、リモート Git リポジトリーへの接続時に使用される認証情報が含まれています。この引数は、Git リポジトリーに認証が必要な場合に必要となります。この引数は 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>

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

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

SSH 認証では、SSH 認証情報を指定して elytron 設定ファイルを指定できます。このファイルで SSH 認証情報を指定した後に、スタンドアロンサーバーインスタンスを起動し、リモートの Git SSH リポジトリーでサーバー設定ファイル履歴を管理できます。

また、elytron-tool.sh スクリプトを使用してアクセスできる WildFly Elytron ツールを使用して SSH キーペアを生成し、クレデンシャルストアに保存することもできます。WildFly Elytron ツールは、サーバーに SSH 認証情報を指定していない場合に使用する場合に便利です。

elytron 設定ファイルに認証情報を追加すると、リモート Git SSH リポジトリーに接続できます。

前提条件

手順

  • ターミナルで以下のコマンドを実行して、リモートの git SSH リポジトリーに接続します。

    $ <eap_home_path>/bin/standalone.sh --git-repo=<git_repository_url> --git-auth=<elytron_configuration_file_url>

    スタンドアロンサーバーが起動し、サーバーの設定ファイル履歴がリモート Git SSH リポジトリーで管理されるようになります。

関連情報

elytron 設定ファイルでの OpenSSH キーの使用

elytron サブシステムは、OpenSSH コマンドラインツールを使用して生成された SSH キーペアをサポートします。このツールは、RSA アルゴリズム、DSA アルゴリズム、および ECDSA アルゴリズムを使用します。

ssh-keygen コマンドを使用して、SSH 鍵ペアを生成できます。

さらに、3 つの要素タイプのいずれかを使用してパスワードを指定することもできます。

  • clear-password
  • masked-password
  • credential-store-reference

前提条件

  • SSH キーペアを生成している。以下の例は、サイズが 256 メガバイトの ECDSA 鍵の生成を示しています。パスフレーズは シークレット として設定されている。

    [~/.ssh]$ ssh-keygen -t ecdsa -b 256
    
    Generating public/private ecdsa key pair.
    Enter file in which to save the key (/home/user/.ssh/id_ecdsa):
    Enter passphrase (empty for no passphrase): secret
    Enter same passphrase again: secret
    Your identification has been saved in /home/user/.ssh/id_ecdsa.
    Your public key has been saved in /home/user/.ssh/id_ecdsa.pub.

手順

  • 以下の 2 つの方法のいずれかを選択して、elytron 設定ファイルでキーペアを指定します。

    • キーペアの認証情報を使用して、設定ファイルでキーペアを指定します。以下に例を示します。

      <authentication-configurations>
          <configuration name="example">
              <credentials>
                  <key-pair>
                      <openssh-private-key pem="-----BEGIN OPENSSH PRIVATE KEY-----
                                                                  b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABDaZzGpGV
                                                                  922xmrL+bMHioPAAAAEAAAAAEAAABoAAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlz
                                                                  dHAyNTYAAABBBIMTU1m6pmpnSTZ2k/cbKnxXkRpXUmWwqN1SSNLpRswGsUhmLG2H21br1Z
                                                                  lEHRiRn6zQmA4YCtCw2hLuz8M8WVoAAADAQk+bMNWFfaI4Ej1AQdlLl6v4RDa2HGjDS3V4
                                                                  39h0pOx4Ix7YZKydTN4SPkYRt78CNK0AhhtKsWo2lVNwyfh8/6SeqowhgCG9MJYW8yRR1R
                                                                  3DX/eQTx6MV/gSSRLDTpcVWUY0jrBGpMaEvylKoNcabiEo44flkIYlG6E/YtFXsmXsoBsj
                                                                  nFcjvmfE7Lzyin5Fowwpbqj9f0XOARu9wsUzeyJVAwT7+YCU3mWJ3dnO1bOxK4TuLsxD6j
                                                                  RB7bJemsfr
                                                                  -----END OPENSSH PRIVATE KEY-----">
                         <clear-password password="secret"/>
                      </openssh-private-key>
                  </key-pair>
              </credentials>
          </configuration>
      </authentication-configurations>

      この例は、OpenSSH 形式のキーペアを示しています。シークレット のパスフレーズは clear-password タイプとして設定されており、秘密鍵を復号化する必要があります。

      重要

      elytron サブシステムは、PKCS8 形式のキーペアをサポートします。ただし、キーペアを元の形式に復号化する必要がある場合に問題が発生する可能性があるため、PKCS8 形式のキーペアをパスフレーズで暗号化しないでください。

    • 設定ファイルの <ssh-credential> 要素に秘密鍵が含まれるファイルの場所を指定します。以下に例を示します。

      <authentication-configurations>
          <configuration name="example">
              <credentials>
                  <ssh-credential ssh-directory="/user/home/example/.ssh" private-key-file="id_test_ecdsa" known-hosts-file="known_hosts_test"> 1 2 3
                      <clear-password password="secret"/>
                  </ssh-credential>
               </credentials>
          </configuration>
      </authentication-configurations>
      1
      ssh-directory 属性は、キーの場所と既知のホストファイルの場所を指定します。
      2
      private-key-file 属性は、秘密鍵を含むファイルの名前を指定します。
      3
      known-hosts-file 属性は、既知の SSH ホストを含むファイルの名前を指定します。

関連情報

  • OpenSSH とその機能の詳細は、OpenSSH のドキュメント を参照してください。
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.