管理および設定ガイド

JBoss Enterprise Application Platform 6.2

Red Hat JBoss Enterprise Application Platform 6 向け

Sande Gilda

David Le Sage

Red Hat Engineering Content Services

Darrin Mison

David Ryan

Misty Stanley-Jones

概要

本書は、Red Hat JBoss Enterprise Application Platform 6 およびそのパッチリリースに関する管理および設定ガイドです。

第1章 はじめに

1.1. Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) の概要

Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6) は、オープンな標準に基づき構築され、Java Enterprise Edition 6 の仕様に準拠する高速でセキュアな高性能ミドルウェアプラットフォームです。高可用性クラスタリング、強力なメッセージング、分散キャッシングなどの技術を JBoss Application Server 7 と統合し、安定したスケーラブルな高速プラットフォームを作り上げます。
新しいモジュラー構造により、必要な時だけサービスを有効にできるため、起動速度が大幅に向上します。管理コンソールと管理コマンドラインインターフェースを使用すると、XML 設定ファイルを手作業で編集する必要がなくなるため、スクリプトを作成して作業を自動化することが可能です。さらに、API と開発フレームワークも含まれており、これらを使用して堅牢で拡張性のある、セキュアな Java EE アプリケーションを迅速に開発することができます。

1.2. JBoss EAP 6 の機能

表1.1 6.1.0 の機能

機能 説明
Java 証明書 Java Enterprise Edition 6 Full Profile および Web Profile 仕様の認定実装
管理対象ドメイン
  • 複数のサーバーインスタンスおよび物理ホストを一元管理し、スタンドアロンサーバーで単一のサーバーインスタンスを使用することを可能にします。
  • 設定、デプロイメント、ソケットバインディング、モジュール、拡張、システムプロパティーはすべて、サーバーグループ別に管理されます。
  • セキュリティードメインなどのアプリケーションセキュリティーは、設定を簡素化できるよう一元管理されています。
管理コンソールおよび管理 CLI ドメインまたはスタンドアロンサーバーを管理するために新しいインターフェースが提供されます。XML 設定ファイルを手動で編集する必要がなくなります。また、管理 CLI は、管理タスクをスクリプティングおよび自動化できるバッチモードを提供します。
単純化されたディレクトリーレイアウト アプリケーションサーバーモジュールは、共通のサーバー固有 lib/ ディレクトリーではなく modules/ ディレクトリーに含まれるようになりました。domain/ および standalone/ ディレクトリーには、ドメインおよびスタンドアロンデプロイメント用のアーティファクトおよび設定ファイルが含まれます。
モジュラークラスローディングメカニズム モジュールをオンデマンドでロードおよびアンロードすると、パフォーマンスとセキュリティーの利点が提供され、起動および再起動の時間が短縮されます。
簡略化されたデータソース管理 データベースドライバーは他のサービスと同様にデプロイされます。また、データソースは、管理コンソールまたは管理 CLI で直接作成および管理されます。
起動および停止時間の短縮 JBoss EAP 6 は少ないリソースを使用するため、システムリソースが非常に効率的に使用されます。これは開発者にとって特に有利です。

1.3. JBoss EAP 6 の操作モード

JBoss EAP には JBoss EAP インスタンスを操作する 2 つのモードがあります。スタンドアロンサーバーまたは管理対象ドメインへブートできます。各モードはさまざまなビジネスシナリオの異なるニーズに適合するよう設計されています。ビジネスのニーズを活用するため、単一のサーバーインストールまたはコーディネートされたマルチサーバー管理のどちらかを選択することができ、プロセスを自動化して管理を容易にします。
管理対象ドメインとスタンドアロンサーバーのどちらを選択するかは、サーバーの管理方法によって決まります。エンドユーザーの要求に対応するために提供する機能は関係ありません。この区別は、高可用性 (HA) クラスターでは特に重要になります。HA の機能は、実行中のスタンドアロンサーバーや管理対象ドメインとは関連がないことを理解することが重要になります。よって、複数のスタンドアロンサーバーを設定して HA クラスターを形成することが可能です。

1.4. スタンドアロンサーバー

スタンドアロンサーバーは 2 つある JBoss EAP の操作モードの 1 つです。スタンドアロンサーバーモードは独立したプロセスで、以前のバージョンの JBoss EAP で唯一存在した実行モードと似ています。
スタンドアロンサーバーとして実行する JBoss EAP のインスタンスは 1 つのみですが、オプションでクラスター化された設定で実行することも可能です。

1.5. 管理対象ドメイン

管理対象ドメインは、JBoss EAP インスタンスの 2 つある操作モードの 1 つです。このモードは、単一の制御点より JBoss EAP の複数のインスタンスを管理するモードです。
集中管理された複数のサーバーはドメインのメンバーと呼ばれます。ドメインの JBoss EAP インスタンスはすべて共通の管理ポリシーを共有します。各ドメインは 1 つの ドメインコントローラー、1 つ以上の ホストコントローラー、およびホスト毎に 0 個以上のサーバーグループによって構成されます。
ドメインコントローラーはドメインが制御される中心点で、ドメインの管理ポリシーに従って各サーバーが確実に設定されるようにします。また、ドメインコントローラーはホストコントローラーでもあります。ホストコントローラーは、domain.sh または domain.bat スクリプトが実行される物理または仮想ホストのことです。ホストコントローラーはドメインコントローラーとは異なり、ドメイン管理タスクを委譲します。各ホスト上のホストコントローラーはドメインコントローラーと対話して、ホスト上で実行されているアプリケーションサーバーインスタンスのライフサイクルを制御し、ドメインコントローラーがこれらのインスタンスを管理できるようにします。各ホストに複数のサーバーグループが含まれるようにすることが可能です。サーバーグループはサーバーインスタンスのセットで、JBoss EAP がインストールされ、一体で管理および設定されます。ドメインコントローラーがサーバーグループにデプロイされた設定とアプリケーションを管理するため、サーバーグループの各サーバーは同じ設定とデプロイメントを共有します。
同じ物理システム上の同じ JBoss EAP 6 インスタンス内で、ドメインコントローラー、単一のホストコントローラー、および複数のサーバーを実行することが可能です。ホストコントローラーは特定の物理 (または仮想) ホストと関係します。ポートと他のリソースが競合しないため、異なる設定を使用する場合は複数のホストコントローラーを同じハードウェア上で実行できます。
ドメインコントローラーを 1 つ、ホストコントローラーを 3 つ、サーバーグループを 3 つ持つ管理対象ドメイン。サーバーはサーバーグループのメンバーで、このドメイン内のホストコントローラーのいずれかにあります。

図1.1 管理対象ドメインの図解

1.6. ドメインコントローラー

ドメインコントローラーは、ドメインの集中管理点として動作する JBoss EAP サーバーインスタンスです。1 つのホストコントローラーインスタンスがドメインコントローラーとして動作するよう設定されます。ドメインコントローラーの主な役割は次のとおりです。
  • ドメインの集中管理ポリシーを維持する。
  • すべてのホストコントローラーが現在のコンテンツを認識するようにする。
  • 実行中の JBoss EAP インスタンスがすべてこのポリシーに従って設定されるよう、ホストコントローラーをサポートする。
集中管理ポリシーはデフォルトで domain/configuration/domain.xml ファイルに格納されます。このファイルは、ドメインコントローラーのホストのファイルシステム上にある未展開の JBoss EAP 6 インストールファイル内に存在します。
domain.xml ファイルは、ドメインコントローラーとして実行するホストコントローラーの domain/configuration/ ディレクトリーになければなりません。このファイルは、ドメインコントローラーとして実行しないホストコントローラー上のインストールには必要ありませんが、このようなサーバー上に domain.xml ファイルが存在しても問題はありません。domain.xml ファイルには、あるドメインのサーバーインスタンス上で実行するよう設定できるさまざまなプロファイルの設定が含まれています。プロファイル設定には、プロファイルを構成するさまざまなサブシステムの詳細設定が含まれます。また、ドメイン設定にはソケットのグループの定義やサーバーグループの定義も含まれます。

1.7. ドメインコントローラーのフェイルオーバー

何らかの理由でドメインコントローラーに障害が発生した場合、ドメインコントローラーとして動作するよう他のホストコントローラーを設定することができます。

1.8. ホストコントローラー

ホストコントローラーは domain.sh または domain.bat script がホスト上で実行された時に起動します。ホストコントローラーの主な役割はサーバーを管理することです。ドメイン管理タスクを委譲し、ホスト上で実行される個別のアプリケーションサーバープロセスを開始および停止します。ホストコントローラーはドメインコントローラーと対話し、サーバーとドメインコントローラー間の通信を管理できるようにします。ドメインの複数のホストコントローラーは単一のドメインコントローラーのみと対話できます。そのため、単一のドメインモード上で実行されているホストコントローラーおよびサーバーインスタンスはすべて単一のドメインコントローラーを持つことができ、同じドメインに属する必要があります。
デフォルトでは、各ホストコントローラーは domain/configuration/host.xml ファイルより設定を読み取ります。このファイルは、ホストのファイルシステム上にある未展開の JBoss EAP 6 インストールファイルに存在します。host.xml ファイルには特定のホストに固有する次のような設定情報が含まれています。
  • このインストールより実行されるべきである実際の JBoss EAP 6 インスタンスの名前リスト。
  • 次の設定のいずれか。
    • ホストコントローラーがドメインコントローラーへ通知して、ホストコントローラー自体を登録し、ドメイン設定へアクセスする方法。
    • リモートドメインコントローラーの検索および通知方法。
    • ホストコントローラー自体がドメインコントローラーとして動作するよう、ホストコントローラーに伝える。
  • ローカルの物理インストールに固有する項目の設定。たとえば、domain.xml に宣言された名前付きインターフェースの定義を host.xml のマシン固有の IP アドレスへマップできます。domain.xml の抽象パス名を host.xml のファイルシステムパスへマップできます。

1.9. サーバーグループ

サーバーグループは、一体として管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、アプリケーションサーバーインスタンスはすべてサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイ済みコンテンツを共有します。ドメインコントローラーとホストコントローラーは、ドメインの各サーバーグループのサーバーインスタンスすべてに標準の設定を適用します。異なるサーバーグループには異なるプロファイルやデプロイメントを設定できます (たとえば、異なるサービスを提供する異なるサーバーの階層を持つドメインなど)。また、異なるサーバーグループが同じプロファイルやデプロイメントを持つこともできます (たとえば、最初に 1 つ目のサーバーグループのアプリケーションをアップグレードし、次に 2 つ目のサーバーグループをアップグレードすることで、完全なサービスの停止を回避するアプリケーションのローリングアップグレードなど)。
以下はサーバーグループ定義の例になります。
     
<server-group name="main-server-group" profile="default">
 <socket-binding-group ref="standard-sockets"/>
  <deployments>
   <deployment name="foo.war_v1" runtime-name="foo.war"/>
   <deployment name="bar.ear" runtime-name="bar.ear"/>
  </deployments>
</server-group>
サーバーグループに含まれる必須の属性は次のとおりです。
  • name: サーバーグループの名前。
  • profile: サーバーグループのプロファイルの名前。
サーバーグループに含まれる任意の属性は次のとおりです。
  • socket-binding-group: グループのサーバーに対して使用されるデフォルトのソケットバインディンググループの名前。この名前は host.xml でサーバーごとに上書きできます。socket-binding-group 名が server-group 要素に指定されていない場合、host.xml の各サーバーに対して指定する必要があります。
  • deployments: グループのサーバー上にデプロイするデプロイメントコンテンツ。
  • system-properties: グループのサーバーに設定するシステムプロパティー。
  • jvm: グループの全サーバーに対するデフォルトの jvm 設定。ホストコントローラーはこれらの設定を host.xml の他の設定とマージし、サーバーの JVM を開始するために使用される設定を作成します。

1.10. JBoss EAP 6 プロファイル

以前のバージョンの JBoss EAP で使用されたプロファイルのコンセプトは使用されないようになりました。JBoss EAP 6 では、設定に関するすべての情報を保持する少数の設定ファイルが使用されるようになりました。
モジュールとドライバーは必要に応じてロードされるため、JBoss EAP 6 の以前のバージョンで使用されたデフォルトプロファイルのコンセプト (プロファイルはサーバーを効率的に起動するために使用される) は適用されません。デプロイメント時に、モジュールの依存関係が決定および順序付けされ、サーバーまたはドメインコントローラーによって解決された後に、正しい順序でロードされます。アンデプロイメント中は、モジュールを必要とするデプロイメントがなくなった時点でそのモジュールがアンロードされます。
設定からサブシステムを削除すると、手作業でモジュールを無効にしたり、ドライバーまたは他のサービスをアンデプロイすることが可能ですが、ほとんどの場合でこの作業は必要ありません。モジュールを使用するアプリケーションがない場合、モジュールはロードされません。

第2章 アプリケーションサーバー管理

2.1. JBoss EAP 6 の起動および停止

2.1.2. JBoss EAP 6 をスタンドアロンサーバーとして起動

概要

ここでは、JBoss EAP 6 をスタンドアロンサーバーとして起動する手順を説明します。

手順2.1 プラットフォームサービスをスタンドアロンサーバーとして起動

  1. Red Hat Enterprise Linux の場合

    次のコマンドを実行します: EAP_HOME/bin/standalone.sh
  2. Microsoft Windows Server の場合

    次のコマンドを実行します: EAP_HOME\bin\standalone.bat
  3. 別のパラメーターを指定します (任意)

    起動スクリプトに渡すことができる他のパラメーターの一覧を出力するには、-h パラメーターを使います。
結果

JBoss EAP 6 スタンドアロンサーバーインスタンスが起動します。

2.1.3. JBoss EAP 6 を管理対象ドメインとして起動

操作の順序

ドメイン内のサーバーグループのスレーブサーバーを起動する前にドメインコントローラーを起動する必要があります。最初に、この手順をドメインコントローラーで使用した後に、関連するホストコントローラーおよびドメインに関連する他のホストに対して使用してください。

手順2.2 プラットフォームサービスを管理対象ドメインとして起動

  1. Red Hat Enterprise Linux の場合

    次のコマンドを実行します: EAP_HOME/bin/domain.sh
  2. Microsoft Windows Server の場合

    次のコマンドを実行します: EAP_HOME\bin\domain.bat
  3. 他のパラメーターを起動スクリプトに渡します (任意)

    起動スクリプトに渡すことができる各種パラメーターを確認するには、-h パラメーターを使います。
結果

JBoss EAP 6 管理対象ドメインインスタンスが起動します。

2.1.4. 代替設定を用いた JBoss EAP 6 の起動

設定ファイルを指定しない場合、サーバーはデフォルトファイルで起動します。しかし、サーバーを起動してから設定を手動で指定することができます。この手順は管理対象ドメインとスタンドアロンサーバーのどちらを使用するか、またどのオペレーティングシステムを使用するかによって多少の違いがあります。

要件

  • 代替の設定ファイルを使用する前に、デフォルト設定をテンプレートとして使用して、代替の設定ファイルを作成します。管理対象ドメインの場合は、設定ファイルを EAP_HOME/domain/configuration/ ディレクトリーに置く必要があります。スタンドアロンサーバーの場合は、設定ファイルを EAP_HOME/standalone/configuration/ ディレクトリーに置く必要があります。

注記

EAP_HOME/docs/examples/configs/ ディレクトリーに複数の設定例が含まれています。これらの例を使用し、クラスタリングや Transaction XTS API などの追加機能を有効にします。

手順2.3 代替設定を用いたインスタンスの起動

  1. スタンドアロンサーバー

    スタンドアロンサーバーでは、--server-config パラメーターに設定ファイルのファイル名をオプションとして指定します。設定ファイルは EAP_HOME/standalone/configuration/ ディレクトリーに置く必要があり、このディレクトリーからの相対パスで設定ファイルを指定する必要があります。

    例2.1 Red Hat Enterprise Linux のスタンドアロンサーバーに別の設定ファイルを使用

    [user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml
    この例は、EAP_HOME/standalone/configuration/standalone-alternate.xml 設定ファイルを使用します。

    例2.2 Microsoft Windows Server のスタンドアロンサーバーに別の設定ファイルを使用

    C:\EAP_HOME\bin>standalone.bat --server-config=standalone-alternate.xml
    この例は、EAP_HOME\standalone\configuration\standalone-alternative.xml 設定ファイルを使用します。
  2. 管理対象ドメイン

    管理対象ドメインでは、設定ファイルのファイル名を --domain-config パラメーターのオプションとして指定します。設定ファイルは EAP_HOME/domain/configuration/ ディレクトリーに置く必要があり、このディレクトリーからの相対パスを指定する必要があります。

    例2.3 Red Hat Enterprise Linux の管理対象ドメインに別の設定ファイルを使用

    [user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml
    この例は、EAP_HOME/domain/configuration/domain-alternate.xml 設定ファイルを使用します。

    例2.4 Microsoft Windows Server の管理対象ドメインに別の設定ファイルを使用

    C:\EAP_HOME\bin>domain.bat --domain-config=domain-alternate.xml 
    
    
    この例は、EAP_HOME\domain\configuration\domain-alternate.xml 設定ファイルを使用します。
結果

代替の設定ファイルを使用して JBoss EAP が起動されます。

2.1.5. JBoss EAP 6 の停止

JBoss EAP 6 を停止する方法は、起動方法によって異なります。このタスクでは、対話的に起動されたインスタンスを停止し、サービスにより起動されたインスタンスを停止して、スクリプトによりバックグラウンドにフォークされたインスタンスを停止します。

注記

このタスクは管理対象ドメイン内のサーバーまたはサーバーグループを停止しません。このようなサーバーまたはサーバーグループを停止する場合は「管理コンソールを使用したサーバーの停止」を参照してください。

手順2.4 JBoss EAP 6 のスタンドアロンインスタンスの停止

  1. コマンドラインプロンプトから対話的に起動したインスタンスを停止します。

    JBoss EAP 6 が実行されているターミナルで Ctrl-C を押します。
  2. オペレーティングシステムサービスとして起動されたインスタンスを停止します。

    オペレーティングシステムに応じて、以下のいずれかの手順を実行します。
    • Red Hat Enterprise Linux

      Red Hat Enterprise Linux でサービススクリプトを記述したときは、stop 機能を使用します。これは、スクリプトに記述する必要があります。次に、service scriptname stop を使用できます。ここで scriptname はスクリプトの名前に置き換えます。
    • Microsoft Windows Server

      Microsoft Windows の場合は、net service コマンドを使用するか、コントロールパネルの サービス アプレットからサービスを停止します。
  3. バックグラウンドで実行されているインスタンスを停止します (Red Hat Enterprise Linux)。

    1. プロセスリストからインスタンスを特定します。コマンド ps aux |grep "[j]ava -server" を実行することもできます。これにより、ローカルマシンで実行されている各 JBoss EAP 6 インスタンスの 1 つの結果が返されます。
    2. kill process_ID を実行してプロセスに TERM シグナルを送信します。ここで、process_ID は上記 ps aux コマンドの 2 番目のフィールドにある数字に置き換えます。
結果

JBoss EAP 6 がクリーンにシャットダウンされ、データは失われません。

2.1.6. サーバー実行時に渡すスイッチと引数のリファレンス

アプリケーションサーバーの起動スクリプトは実行時に追加の引数とスイッチを受け取ります。これらのパラメーターを使用すると、standalone.xmldomain.xml、および host.xml の設定ファイルで定義されたものとは別の設定でサーバーを起動できます。これには、ソケットバインディングの代替セットや二次設定でのサーバーの起動が含まれることがあります。利用可能なこれらのパラメーターのリストには、起動時にヘルプスイッチを渡すことによってアクセスできます。

例2.5

次の例は、「JBoss EAP 6 をスタンドアロンサーバーとして起動」で説明されているサーバーの起動に似ていますが、-h スイッチまたは --help スイッチが追加されています。ヘルプスイッチの結果は下表の説明を参照してください。
[localhost bin]$ standalone.sh -h

表2.1 実行時スイッチおよび引数

引数またはスイッチ 説明
--admin-only サーバーの実行タイプを ADMIN_ONLY に設定します。これにより管理インターフェースが開かれ、管理リクエストが許可されますが、他のランタイムサービスは起動されず、エンドユーザーのリクエストは許可されません。
-b=<value> システムプロパティー jboss.bind.address を該当する値に設定します。
-b <value> システムプロパティー jboss.bind.address を該当する値に設定します。
-b<interface>=<value> システムプロパティー jboss.bind.address.<interface> を該当する値に設定します。
-c=<config> 使用するサーバー設定ファイルの名前。デフォルト値は standalone.xml です。
-c <config> 使用するサーバー設定ファイルの名前。デフォルト値は standalone.xml です。
--debug [<port>] オプションの引数を用いてデバッグモードを有効にし、ポートを指定します。起動スクリプトがサポートする場合のみ動作します。
-D<name>[=<value>] システムプロパティーを設定します。
-h ヘルプメッセージを表示し、終了します。
--help ヘルプメッセージを表示し、終了します。
--read-only-server-config=<config> 使用するサーバー設定ファイルの名前。元のファイルは上書きされないため、「--server-config」 および 「-c」とは異なります。
-P=<url> 該当する URL からシステムプロパティーをロードします。
-P <url> 該当する URL からシステムプロパティーをロードします。
--properties=<url> 該当する URL からシステムプロパティーをロードします。
-S<name>[=<value>] セキュリティープロパティーを設定します。
--server-config=<config> 使用するサーバー設定ファイルの名前。デフォルト値は standalone.xml です。
-u=<value> システムプロパティー jboss.default.multicast.address を指定の値に設定します。
-u <value> システムプロパティー jboss.default.multicast.address を指定の値に設定します。
-V アプリケーションサーバーのバージョンを表示し、終了します。
-v アプリケーションサーバーのバージョンを表示し、終了します。
--version アプリケーションサーバーのバージョンを表示し、終了します。

2.2. サーバーの起動と停止

2.2.1. 管理 CLI を使用したサーバーの起動および停止

管理 CLI または管理コンソールを使用してサーバーを起動および停止できます。これらの管理ツールを使用すると、単一のスタンドアロンサーバーインスタンスを制御したり、管理対象ドメインのデプロイメント全体で複数のサーバーを選択的に管理したりできます。管理コンソールを使用する場合は、「管理コンソールを使用したサーバーの起動」の手順を参照してください。管理 CLI を使用する場合は、スタンドアロンサーバーインスタンスと管理対象ドメインインスタンスでプロセスが異なります。
管理 CLI を用いたスタンドアロンサーバーの起動および停止

スタンドアロンサーバーインスタンスは、コマンドラインスクリプトで起動でき、管理 CLI より shutdown コマンドを使用してシャットダウンできます。インスタンスが再度必要な場合は、「JBoss EAP 6 をスタンドアロンサーバーとして起動」の説明どおりに起動プロセスを再実行します。

例2.6 管理 CLI よりスタンドアロンサーバーインスタンスを停止する

[standalone@localhost:9999 /] shutdown
管理 CLI を用いた管理対象ドメインの起動および停止

管理対象ドメインを実行している場合は、管理コンソールを使用するとドメインの特定サーバーを選択的に起動または停止できます。これには、ドメイン全体のサーバーグループや、ホスト上の特定サーバーインスタンスが含まれます。

例2.7 管理 CLI より管理対象ドメインのサーバーホストを停止する

スタンドアロンサーバーと同様に、宣言された管理対象ドメインホストをシャットダウンするには shutdown コマンドを使用します。この例では、シャットダウン操作を呼び出す前にインスタンス名を宣言し、「master」という名前のサーバーホストを停止します。tab キーを使用して文字列を補完し、利用可能なホスト値などの可視変数を表示します。
[domain@localhost:9999 /] /host=master:shutdown

例2.8 管理 CLI より管理対象ドメインのサーバーホストを起動および停止する

この例は、start および stop 操作を呼び出す前に、サーバーグループを宣言することで、main-server-group という名前のデフォルトのサーバーグループをを起動します。tab キーを使用して文字列を補完し、利用可能なサーバーグループ名の値などの可視変数を表示します。
[domain@localhost:9999 /] /server-group=main-server-group:start-servers
[domain@localhost:9999 /] /server-group=main-server-group:stop-servers

例2.9 管理 CLI より管理対象ドメインのサーバーインスタンスを起動および停止する

この例は、start および stop 操作を呼び出す前に、ホストおよびサーバーの設定を宣言することで、master ホスト上の server-one という名前のサーバーインスタンスを起動および停止します。tab キーを使用して文字列を補完し、利用可能なホストおよびサーバー設定の値などの可視変数を表示します。
[domain@localhost:9999 /] /host=master/server-config=server-one:start
[domain@localhost:9999 /] /host=master/server-config=server-one:stop

2.2.2. 管理コンソールを使用したサーバーの起動

手順2.5 サーバーの起動

  1. 管理コンソールの Server Instances に移動します。

    1. コンソールの上部より Runtime タブを選択します。
  2. サーバーを選択します。

    Server Instances のリストから、起動するサーバーを選択します。実行されているサーバーはチェックマークで示されます。
    このリストにあるインスタンスにカーソルを合わせると、サーバーの詳細の下に青色でオプションが表示されます。
  3. Start ボタンをクリックします。

    インスタンスを起動するには、表示された Start Server テキストをクリックします。クリックすると、ダイアログボックスが開きます。Confirm ボタンをクリックしてサーバーを起動します。
結果

選択したサーバーが起動し、稼働状態になります。

2.2.3. 管理コンソールを使用したサーバーの停止

手順2.6 管理コンソールを使用したサーバーの停止

  1. 管理コンソールの Hosts, groups and server instances に移動します。

    1. コンソールの上部より Runtime タブを選択します。Topology タブのメインペインに、利用可能なサーバーインスタンスが表示されます。
  2. サーバーを選択します。

    Server Instances のリストから、停止するサーバーを選択します。実行されているサーバーはチェックマークで示されます。
  3. Stop Server テキストをクリックします。

    サーバーエントリーにカーソルを合わせると表示される Stop Server テキストをクリックします。確認ダイアログウインドウが表示されます。
  4. Confirm ボタンをクリックしてサーバーを停止します。
結果

選択されたサーバーが停止します。

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

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

JBoss EAP 6 では、ファイルシステムパスに論理名を使用します。domain.xmlhost.xml、および standalone.xml の設定には、パスを宣言できるセクションが含まれます。設定の他のセクションは、各インスタンスの絶対パスを宣言せず論理名を使用することにより、これらのパスを参照できます。これにより、特定のホスト設定をユニバーサルな論理名に解決できるため、設定や管理がしやすくなります。
たとえば、ロギングサブシステム設定には、サーバーのlog ディレクトリーを参照する jboss.server.log.dir パスの参照が含まれます。

例2.10 ロギングディレクトリーの相対パス例

<file relative-to="jboss.server.log.dir" path="server.log"/>
JBoss EAP 6 では、複数の標準的なパスが自動的に提供されるため、ユーザーが設定ファイルでこれらのパスを設定する必要はありません。

表2.2 標準的なパス

説明
jboss.home.dir JBoss EAP 6 ディストリビューションのルートディレクトリー。
user.home ユーザーホームディレクトリー。
user.dir ユーザーのカレントワーキングディレクトリー。
java.home Java インストールディレクトリー。
jboss.server.base.dir 各サーバーインスタンスのルートディレクトリー。
jboss.server.data.dir サーバーが永続データファイルストレージに使用するディレクトリー。
jboss.server.config.dir サーバー設定が含まれるディレクトリー。
jboss.server.log.dir サーバーがファイルストレージに使用するディレクトリー。
jboss.server.temp.dir サーバーが一時ファイルストレージに使用するディレクトリー。
jboss.controller.temp.dir ホストコントローラーが一時的なファイルストレージとして使用するディレクトリー。
ユーザーは、path 要素を設定ファイルに追加することにより、独自のパスを追加したり、上記の最初の 5 つを除くすべてをオーバーライドしたりできます。次の例は、各サーバーインスタンスのルートディレクトリーに対する新しい相対パス宣言を示しています。

例2.11 相対パスの形式

<path name="examplename" path="example/path" relative-to="jboss.server.data.dir"/>
パス宣言の構造では以下の属性が使用されます。

表2.3 パス属性

属性 説明
name パスの名前。
path 実際のファイルシステムパス。relative-to 属性が指定されない限り、絶対パスとして処理され、値はそのパスの相対パスとして処理されます。
relative-to 以前に指定された別のパスの名前を示すオプション属性、またはシステムにより提供される標準的ないずれかのパス。
domain.xml 設定ファイルの path 要素には、name 属性のみが必要です。以下の例のとおり、実際のファイルシステムパスを示す情報を含める必要はありません。

例2.12 ドメインパスの例

<path name="example"/>
この設定は、domain.xml 設定の他の部分が参照できる example という名前のパスがあることを宣言します。example で宣言された実際のファイルシステムの場所は、ドメイングループに参加しているホストインスタンスの各 host.xml 設定ファイルに固有です。この方法が使用された場合は、実際のファイルシステムパスを指定する各マシンの host.xml にパス要素が含まれる必要があります。

例2.13 ホストパスの例

<path name="example" path="path/to/example" />
standalone.xml 内の path 要素には、実際のファイルシステムパスの指定を含める必要があります。

2.4. ファイルの履歴設定

2.4.1. JBoss EAP 6 の設定ファイル

JBoss EAP 6 の設定は、以前のバージョンから大幅に変更されました。最も大きな違いの 1 つは、以下のファイルが 1 つ以上含まれる簡素化された設定ファイル構造を使用することです。

表2.4 設定ファイルの場所

サーバーモード 場所 目的
domain.xml EAP_HOME/domain/configuration/domain.xml 管理対象ドメインの主要の設定ファイルです。ドメインマスターのみがこのファイルを読み取ります。他のドメインメンバーでは削除することが可能です。
host.xml EAP_HOME/domain/configuration/host.xml このファイルには、管理対象ドメインの物理ホスト固有の設定情報が含まれています (ネットワークインターフェース、ソケットバインディング、ホスト名、その他のホスト固有の詳細など)。host.xml ファイルには、host-master.xml および host-slave.xml (詳細は下記参照) の両方の機能がすべて含まれています。このファイルはスタンドアロンサーバーの場合は存在しません。
host-master.xml EAP_HOME/domain/configuration/host-master.xml このファイルには、サーバーを管理対象ドメインのマスターサーバーとして実行するために必要な設定情報のみが含まれています。このファイルはスタンドアロンサーバーでは存在しません。
host-slave.xml EAP_HOME/domain/configuration/host-slave.xml このファイルには、サーバーを管理対象ドメインのスレーブサーバーとして実行するために必要な設定情報のみが含まれています。このファイルはスタンドアロンサーバーでは存在しません。
standalone.xml EAP_HOME/standalone/configuration/standalone.xml スタンドアロンサーバーのデフォルトの設定ファイルです。このファイルにはサブシステム、ネットワーキング、デプロイメント、ソケットバインディング、その他の設定情報などを含むスタンドアロンサーバーに関するすべての情報が含まれています。スタンドアロンサーバーの起動時にこの設定が自動的に使用されます。
standalone-full.xml EAP_HOME/standalone/configuration/standalone-full.xml スタンドアロンサーバーの設定例です。高可用性を要するサブシステムを除く、可能な全サブシステムのサポートが含まれます。使用するには、サーバーを停止し、次のコマンドを使用して再起動します: EAP_HOME/bin/standalone.sh -c standalone-full.xml
standalone-ha.xml EAP_HOME/standalone/configuration/standalone-ha.xml このサンプル設定ファイルは、デフォルトのサブシステムをすべて有効にし、高可用性または負荷分散クラスターに参加できるよう mod_cluster および JGroups サブシステムをスタンドアロンサーバーに対して追加します。このファイルは管理対象ドメインには適用されません。この設定を使用するには、サーバーを停止し、次のコマンドを使用して再起動します: EAP_HOME/bin/standalone.sh -c standalone-ha.xml
standalone-full-ha.xml EAP_HOME/standalone/configuration/standalone-full-ha.xml これはスタンドアロンサーバーの設定例です。高可用性に必要となるサブシステムを含む、可能なすべてのサブシステムのサポートが含まれます。使用するにはサーバーを停止し、次のコマンドを使用して再起動します: EAP_HOME/bin/standalone.sh -c standalone-full-ha.xml
これらはデフォルトの場所です。実行時に異なる設定ファイルを指定できます。

2.4.2. ファイルの履歴設定

アプリケーションサーバーの設定ファイルには、standalone.xmldomain.xml、および host.xml ファイルが含まれます。これらのファイルは直接編集して変更できますが、管理 CLI や管理コンソールといった利用可能な管理操作でアプリケーションサーバーモデルを設定する方法が推奨されます。
サーバーインスタンスの保守および管理をしやすくするため、アプリケーションサーバーは起動時に元の設定ファイルにタイムスタンプを付けたものを作成します。管理操作によってその他の設定変更が行われると、元ファイルが自動的にバックアップされ、インスタンスの作業用コピーが参照およびロールバック向けに保持されます。このアーカイブ機能には、サーバー設定のスナップショットの保存、ロード、および削除が含まれ、リコールおよびロールバックを可能にします。

2.4.3. サーバーを以前の設定で起動

以下の例は、standalone.xml を使用してスタンドアロンサーバーの以前の設定でアプリケーションサーバーを起動する方法を示しています。同じコンセプトは、domain.xmlhost.xml それぞれを使用した管理対象ドメインに適用されます。
この例では、管理操作によってサーバーモデルが変更される場合にアプリケーションサーバーにより自動的に保存される以前の設定が呼び出されます。
  1. 開始するバックアップバージョンを特定します。この例では、正常な起動後の最初の変更の前にサーバーモデルのインスタンスが呼び出されます。
    EAP_HOME/configuration/standalone_xml_history/current/standalone.v1.xml 
  2. jboss.server.config.dir 下で相対ファイル名を渡し、バックアップモデルのこの設定を用いてサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml 
結果

アプリケーションサーバーが、選択された設定で起動されます。

2.4.4. 管理 CLI を使用した設定スナップショットの保存

概要

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。

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

手順2.7 設定スナップショットの撮影および保存

  • スナップショットの保存

    take-snapshot 操作を実行して、現在のサーバー設定のコピーを取得します。
    [standalone@localhost:9999 /] :take-snapshot
    {
        "outcome" => "success",
        "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
    
結果

現在のサーバー設定のスナップショットが保存されます。

2.4.5. 管理 CLI を使用した設定スナップショットのロード

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。スナップショットのロードのプロセスは、「サーバーを以前の設定で起動」 で使用された方法に似ており、スナップショットを作成、リスト、および削除するために使用される管理 CLI インターフェースではなくコマンドラインから実行します。
次の例では standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルにも適用されます。

手順2.8 設定スナップショットのロード

  1. ロードするスナップショットを識別します。この例では、スナップショットディレクトリーから以下のファイルが呼び出されます。スナップショットファイルのデフォルトのパスは以下のとおりです。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml
    スナップショットは相対パスにより表されます。たとえば、上記の例は次のように記述できます。
    jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml
  2. ファイル名を渡し、選択したスナップショットを用いてサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml
結果

ロードしたスナップショットに選択された設定を用いてサーバーが再起動します。

2.4.6. 管理 CLI を使用した設定スナップショットの削除

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルにも適用されます。

手順2.9 特定のスナップショットの削除

  1. ロードするスナップショットを指定します。この例では、スナップショットディレクトリーから以下のファイルが削除されます。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml
  2. :delete-snapshot コマンドを実行して、特定のスナップショットを削除します。以下の例のようにスナップショットの名前を指定します。
    [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
    {"outcome" => "success"}
    
結果

スナップショットが削除されます。

手順2.10 スナップショットすべてを削除

  • :delete-snapshot(name="all") コマンドを以下の例のとおりに実行し、スナップショットをすべて削除します。
    [standalone@localhost:9999 /] :delete-snapshot(name="all")
    {"outcome" => "success"}
    
結果

スナップショットがすべて削除されます。

2.4.7. 管理 CLI を使用したすべての設定スナップショットのリスト

設定スナップショットは、現在のサーバー設定のポイントインタイムコピーです。これらのコピーは、管理者が保存およびロードできます。
次の例では standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルにも適用されます。

手順2.11 すべての設定スナップショットのリスト

  • すべてのスナップショットのリスト

    :list-snapshotsコマンドを実行して、保存されたすべてのスナップショットをリストします。
    [standalone@localhost:9999 /] :list-snapshots
    {
        "outcome" => "success",
        "result" => {
            "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
            "names" => [
                "20110818-133719699standalone.xml",
                "20110809-141225039standalone.xml",
                "20110802-152010683standalone.xml",
                "20110808-161118457standalone.xml",
                "20110912-151949212standalone.xml",
                "20110804-162951670standalone.xml"
            ]
        }
    }
    
結果

スナップショットがリストされます。

第3章 管理インターフェース

3.1. アプリケーションサーバーの管理

JBoss EAP 6 は、必要なときに実装を設定および管理できる複数の管理ツールを提供します。これらの管理ツールには、新しい管理コンソールや管理コマンドラインインターフェース (CLI) が含まれます。基礎となる管理 API を使用すると、上級ユーザーは必要に応じて独自のツールを開発できます。

3.2. 管理アプリケーションプログラミングインターフェース (API)

管理クライアント

JBoss EAP 6 は、サーバーを設定および管理する 3 つの方法 (Web インターフェース、コマンドラインクライアント、および XML 設定ファイルのセット) を提供します。設定ファイルを編集する推奨される方法には管理コンソールと管理 CLI が含まれますが、これら 3 つの方法で設定に行われた編集は、さまざまなビューで常に同期され、最終的に XML ファイルに永続化されます。サーバーインスタンスの実行中に XML 設定ファイルに行われた編集は、サーバーモデルによって上書きされることに注意してください。

HTTP API

管理コンソールは、Google Web Toolkit (GWT) で構築された Web インターフェースの例です。管理コンソールは、HTTP 管理インターフェースを使用してサーバーと通信します。HTTP API エンドポイントは、管理レイヤーと統合するために HTTP プロトコルに依存する管理クライアントのエントリーポイントです。HTTP API エンドポイントは、 JSON エンコードプロトコルと de-typed な RPC スタイル API を使用して管理対象ドメインまたはスタンドアロンサーバーに対して管理操作を定義および実行します。HTTP API は Web コンソールによって使用されますが、さまざまな他のクライアントに対して統合機能を提供します。

HTTP API エンドポイントはドメインコントローラーまたはスタンドアロンサーバーインスタンスと共存します。HTTP API エンドポイントサービスは、管理操作を実行するためのコンテキストと Web インターフェースにアクセスするためのコンテキストの 2 つの異なるコンテキストを処理します。デフォルトでは、ポート 9990 で実行されます。

例3.1 HTTP API 設定ファイルの例

<management-interfaces>
  [...]
  <http-interface security-realm="ManagementRealm">
     <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>
Web コンソールは、HTTP 管理 API と同じポートを介して提供されます。デフォルトの localhost でアクセスされる管理コンソール、特定のホストとポートの組み合わせによってリモートでアクセスされる管理コンソール、および公開されたドメイン API を区別することが重要です。

表3.1 管理コンソールへの URL

URL 説明
http://localhost:9990/console ローカルホストでアクセスされる管理コンソール (管理対象ドメイン設定を制御します)。
http://hostname:9990/console リモートでアクセスされる管理コンソール (ホストを指定し、管理対象ドメイン設定を制御します)。
http://hostname:9990/management HTTP 管理 API は管理コンソールと同じポートで実行され、API に公開された raw 属性と値を表示します。
ネイティブ API

ネイティブ API ツールの例には管理 CLI があります。この管理ツールは管理対象ドメインまたはスタンドアロンサーバーインスタンスに使用できるため、ユーザーはドメインコントローラーまたはスタンドアロンサーバーインスタンスに接続して、de-typed 管理モデルを介して利用可能な管理操作を実行できます。

ネイティブ API エンドポイントは、管理レイヤーと統合するためにネイティブプロトコルに依存する管理クライアントのエントリーポイントです。管理操作を定義および実行するために、オープンバイナリプロトコルと、非常に少数の Java タイプに基づいた RPC スタイル API を使用します。これは、管理 CLI 管理ツールによって使用されますが、さまざまな他のクライアントの統合機能も提供します。
ネイティブ API エンドポイントはホストコントローラーまたはスタンドアロンサーバーと共存します。管理 CLI を使用するには、これを有効にする必要があります。デフォルトでは、ポート 9999 で実行されます。

例3.2 ネイティブ API 設定ファイルの例

<management-interfaces>
  <native-interface security-realm="ManagementRealm">
    <socket-binding native="management-native"/>
  </native-interface>
  [...]
</management-interfaces>

3.3. 管理コンソールと管理 CLI

JBoss EAP 6 では、すべてのサーバーインスタンスと設定が、XML ファイルの編集ではなく管理インターフェースにより管理されます。設定 XML ファイルは引き続き編集できますが、管理インターフェースによる管理は、サーバーインスタンスの永続的な管理に対して追加の検証機能および上級機能を提供します。サーバーインスタンスの実行中に XML 設定ファイルに加えられた変更はサーバーモデルによって上書きされ、追加された XML コメントもすべて削除されます。サーバーインスタンスの実行中は管理インターフェースのみを使用して設定ファイルを変更する必要があります。
Web ブラウザーでグラフィカルユーザーインターフェースを使用してサーバーを管理するには、管理コンソールを使用します。
コマンドラインインターフェースを使用してサーバーを管理するには、管理 CLI を使用します。

3.4. 管理コンソール

3.4.1. 管理コンソール

管理コンソールは JBoss EAP 6 の Web ベースの管理ツールです。
管理コンソールを使用して、サーバーの開始および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の調整、サーバー設定の変更の永続化を行います。管理コンソールは管理タスクも実行でき、変更後にサーバーインスタンスの再起動またはリロードが必要な場合はライブ通知も行います。
管理対象ドメインでは、同じドメイン内のサーバーインスタンスやサーバーグループをドメインコントローラーの管理コンソールから集中管理することができます。

3.4.2. 管理コンソールへログイン

要件

  • JBoss EAP 6 が稼働している必要があります。

手順3.1 管理コンソールへログイン

  1. 管理コンソールのスタートページに移動

    Web ブラウザーで管理コンソールに移動します。デフォルトの場所は http://localhost:9990/console/ です。ポート 9990 は管理コンソールのソケットバインディングとして事前定義されています。
  2. 管理コンソールへログイン

    以前作成したアカウントのユーザー名とパスワードを入力し、管理コンソールのログイン画面でログインします。
    管理コンソールのログイン画面。

    図3.1 管理コンソールのログイン画面

結果

ログインすると、管理コンソールの最初のページが表示されます。
管理対象ドメイン
スタンドアロンサーバー

3.4.3. 管理コンソールの言語の変更

Web ベースの管理コンソールの言語設定では、デフォルトで英語が使用されます。英語の代わりに次のいずれかの言語を選択できます。

サポート言語

  • ドイツ語 (de)
  • 簡体中国語 (zh-Hans)
  • ブラジルポルトガル語 (pt-BR)
  • フランス語 (fr)
  • スペイン語 (es)
  • 日本語 (ja)

手順3.2 Web ベース管理コンソールの言語の変更

  1. 管理コンソールにログインします。

    Web ベースの管理コンソールにログインします。
  2. Settings ダイアログを開きます。

    画面の右下付近に Settings ラベルがあります。これをクリックして管理コンソールの設定を開きます。
  3. 必要な言語を選択します。

    Locale 選択ボックスから希望の言語を選択します。次に、Save を選択します。確認ボックスに、アプリケーションをリロードする必要があると表示されます。Confirm をクリックします。新しいロケールを使用するために Web ブラウザを更新します。

3.4.4. 管理コンソールを使用したサーバーの設定

手順3.3 サーバーの設定

  1. 管理コンソールで、サーバーの Server Configurations パネルに移動します。

    1. コンソールの上部より Hosts タブを選択します。利用可能なサーバーインスタンスの表が表示されます。
  2. サーバー設定の編集

    1. Available Server Configurations テーブルよりサーバーインスタンスを選択します。
    2. 選択したサーバーの下にある Edit ボタンを選択します。
    3. 設定属性を変更します。
    4. サーバーリストの下にある Save ボタンをクリックします。
結果

サーバー設定が変更され、サーバーが次回再起動した時に変更が反映されます。

3.4.5. 管理コンソールでのデプロイメントの追加

手順3.4 デプロイメントの追加および検証

  1. 管理コンソールの Manage Deployments パネルに移動します。

    1. コンソールの上部にある Runtime タブを選択します。
    2. スタンドアロンサーバーの場合、コンソールの左側にある Server メニューを展開し、Manage Deployments を選択します。管理対象ドメインの場合は、コンソールの左側にある Domain メニューを展開し、Manage Deployments を選択します。
    Manage Deployments パネルが表示されます。
  2. デプロイメントコンテンツの追加

    Content Repository タブ上の Add ボタンを選択します。Create Deployment ダイアログボックスが表示されます。
  3. デプロイするファイルの選択

    ダイアログボックスの Browse ボタンを選択します。デプロイするファイルを参照し、アップロードするために選択します。ファイルが選択されたら、Next ボタンを選択して作業を続行します。
  4. デプロイメント名の確認

    Create Deployments ダイアログボックスに表示されるデプロイメント名とランタイム名を確認します。名前を確認したら、Save ボタンを選択してファイルをアップロードします。
結果

選択したコンテンツがサーバーにアップロードされ、デプロイメント可能になります。

3.4.6. 管理コンソールでのサーバーの新規作成

手順3.5 サーバー設定の新規作成

  1. 管理コンソールの Server Configurations ページに移動します。

    コンソールの右上から Server タブを選択します。
  2. 設定の新規作成

    1. Server Configuration パネルの上部にある Add ボタンを選択します。
    2. Create Server Configuration ダイアログで基本的なサーバー設定を編集します。
    3. Save ボタンを選択して、新しいサーバー設定を保存します。
結果

新しいサーバーが作成され、Server Configurations リストに表示されます。

3.4.7. 管理コンソールを使用したデフォルトログレベルの変更

手順3.6 ロギングレベルの編集

  1. 管理コンソールの Logging パネルに移動します。

    1. 管理対象ドメインを使用している場合は、コンソールの上部にある Profiles タブを選択した後、コンソールの左側にあるドロップダウンリストから該当するプロファイルを選択します。
    2. 管理対象ドメインまたはスタンドアロンサーバーでは、コンソールの左側にあるメニューより CoreLogging メニューを展開し、Logging エントリーをクリックします。
    3. コンソール上部の Log Categories タグをクリックします。
  2. ロガー詳細の編集

    Log Categories テーブル内のエントリーの詳細を編集します。
    1. Log Categories テーブル内のエントリを選択し、その下にある Details セクションの Edit ボタンを押します。
    2. Log Level ドロップダウンボックスでカテゴリーのログレベルを設定します。設定したら、Save ボタンを押します。
結果

該当するカテゴリーのログレベルが更新されます。

3.4.8. 管理コンソールでのサーバーグループの新規作成

手順3.7 サーバーグループの新規作成および追加

  1. Server Groups のビューに移動します。

    右上隅の Host タブを選択します。
  2. 左側の欄の Server メニューにある Server Groups タブを選択します。
  3. サーバーグループの追加

    Add ボタンをクリックし新規サーバーグループを追加します。
  4. サーバーグループの設定

    1. サーバーグループ名を入力します。
    2. サーバーグループを追加するプロファイルを選択します。
    3. サーバーグループを追加するソケットバインディングを選択します。
    4. Save ボタンを押し、新規グループを保存します。
結果

新規サーバーグループが管理コンソールに表示されるようになります。

3.5. 管理 CLI

3.5.1. 管理コマンドラインインターフェース (CLI)

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

3.5.2. Management CLI の起動

手順3.8 Linux または Windows での CLI の起動

    • Linux での CLI の起動

      コマンドラインで以下のコマンドを入力して、EAP_HOME/bin/jboss-cli.sh ファイルを実行します。
      $ EAP_HOME/bin/jboss-cli.sh
    • Windows での CLI の起動

      ダブルクリックするか、コマンドラインで以下のコマンドを入力して、EAP_HOME\bin\jboss-cli.bat ファイルを実行します。
      C:\>EAP_HOME\bin\jboss-cli.bat

3.5.3. 管理 CLI の終了

手順3.9 管理 CLI の終了

  • quit コマンドの実行

    管理 CLI で、quit コマンドを入力します。
    [domain@localhost:9999 /] quit
    Closed connection to localhost:9999

3.5.4. 管理 CLI を使用した管理対象サーバーインスタンスへの接続

手順3.10 管理対象サーバーインスタンスへの接続

  • connect コマンドを実行します。

    管理 CLI で、connect コマンドを入力します。
    [disconnected /] connect
    Connected to domain controller at localhost:9999
    • Linux システムで管理 CLI を起動する時に管理対象サーバーへ接続するには、--connect パラメーターを使用します。
      $ EAP_HOME/bin/jboss-cli.sh --connect
    • --connect パラメーターは、ホストとサーバーのポートを指定するために使用できます。ポートの値が 9999 であるアドレス 192.168.0.1 に接続するには、次のコマンドを使用します。
      $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999

3.5.5. 管理 CLI でのヘルプの使用

概要

管理 CLI には、一般的なオプションと状況依存オプションから構成されるヘルプダイアログが組み込まれてます。運用状況に依存するヘルプコマンドでは、スタンドアロンまたはドメインコントローラーへの接続を確立する必要があります。接続が確立されない限り、これらのコマンドはリストに表示されません。

手順3.11 一般および状況依存ヘルプ

  1. help コマンドの実行

    管理 CLI で、help コマンドを入力します。
    [standalone@localhost:9999 /] help
  2. 状況依存ヘルプの使用

    管理 CLI で、help -commands 拡張コマンドを入力します。
    [standalone@localhost:9999 /] help --commands
  3. 特定のコマンドの詳細については、'--help' を引数として help コマンドを実行してください。
    [standalone@localhost:9999 /]  deploy --help
結果

CLI ヘルプ情報が表示されます。

3.5.6. バッチモードでの管理 CLI の使用

概要

バッチ処理により、複数の操作をシーケンスでグループ化し、ユニットとして一緒に実行できます。シーケンス内のいずれかの操作要求が失敗したら、操作のグループ全体がロールバックされます。

手順3.12 バッチモードのコマンドおよび操作

  1. バッチモードの開始

    batch コマンドを使用してバッチモードを開始します。
    [standalone@localhost:9999 /] batch
    [standalone@localhost:9999 / #]
    バッチモードは、プロンプトでハッシュ記号 (#) で示されます。
  2. バッチへの操作要求の追加

    バッチモードが開始されたら、操作要求を通常どおり入力します。操作要求は、入力された順序でバッチに追加されます。
    操作要求のフォーマット化の詳細については、「管理 CLI での操作およびコマンドの使用」 を参照してください。
  3. バッチの実行

    操作要求のシーケンス全体が入力されたら、run-batch コマンドを使用してバッチを実行します。
    [standalone@localhost:9999 / #] run-batch
    The batch executed successfully.
    バッチの作業に使用できるコマンドの完全リストは 「CLI のバッチモードコマンド」 を参照してください。
  4. 外部ファイルに保存されたバッチコマンド

    頻繁に実行するバッチコマンドは、外部のテキストファイルに保存できます。これらのバッチコマンドをロードするには、ファイルへのフルパスを引数として batch コマンドに渡すか、run-batch コマンドの引数として直接実行します。
    テキストエディターを使用してバッチコマンドファイルを作成できます。1 行に 1 つのコマンドのみががあるようにし、CLI がコマンドにアクセスできなければなりません。
    次のコマンドは、バッチモードで myscript.txt ファイルをロードします。このファイルのすべてのコマンドは編集または削除できます。新しいコマンドを挿入できます。このバッチセッションで変更された内容は myscript.txt ファイルへ保持されません。
    [standalone@localhost:9999 /] batch --file=myscript.txt
    次のコマンドは、myscript.txt ファイルに保存されたバッチコマンドを即時実行します。
    [standalone@localhost:9999 /] run-batch --file=myscript.txt
結果

操作要求の入力されたシーケンスはバッチとして完了します。

3.5.7. CLI のバッチモードコマンド

下表は JBoss EAP 6 の CLI で使用できる有効なバッチコマンドのリストになります。これらのコマンドはバッチの作業のみに使用できます。

表3.2 CLI のバッチモードコマンド

コマンド名 説明
list-batch 現在のバッチのコマンドおよび操作のリスト
edit-batch-line line-number edited-command 編集する行番号と edited コマンドを提供し、現在のバッチの行を編集します。例: edit-batch-line 2 data-source disable --name=ExampleDS
move-batch-line fromline toline 移動したい行の番号を最初の引数として指定し、移動先を 2 番目の引数として指定してバッチの行の順序を変更します。例: move-batch-line 3 1
remove-batch-line linenumber 特定の行でバッチコマンドを削除します。例: remove-batch-line 3
holdback-batch [batchname]
このコマンドを使用すると現在のバッチを延期または保存できます。バッチの外部にて急に CLI で実行するものがある場合にこのコマンドを使用します。保留したバッチへ戻るには、再度 CLI コマンドラインに batch を入力します。
holdback-batch コマンドの使用中にバッチ名を指定すると、バッチがその名前で保存されます。名前が付けられたバッチに戻るには、batch batchname コマンドを使用します。バッチ名を指定せずに batch コマンドを呼び出すと、新しい (名前が付けられていない) バッチが開始します。名前が付けられていない保留バッチは 1 つのみ存在できます。
保留されたバッチをすべて一覧表示するには、batch -l コマンドを使用します。
discard-batch 現在アクティブなバッチを破棄します。

3.5.8. 管理 CLI での操作およびコマンドの使用

手順3.13 リクエストの作成、設定、および実行

  1. 操作要求の構築

    操作要求では、管理モデルとの低レベルの対話が可能です。この場合、サーバー設定を制御された方法で編集できます。操作要求は、以下の 3 つの部分から構成されます。
    • スラッシュ (/) で始まる アドレス
    • コロン (:) で始まる 操作名
    • 丸かっこ「()」で囲まれたパラメーターのオプションセット。
    1. アドレスの決定

      設定はアドレス指定可能なリソースの階層ツリーとして表されます。各リソースノードは、異なる操作セットを提供します。アドレスは、操作を実行するリソースノードを指定します。アドレスでは以下の構文を使用します。
      /node-type=node-name
      • node-type は、リソースノードタイプです。これは、設定 XML の要素名に対してマッピングされます。
      • node-name はリソースノード名です。これは、設定 XML の要素の name 属性に対してマッピングされます。
      • スラッシュ (/) を使用してリソースツリーの各レベルを区切ります。
      設定 XML ファイルを参照して必要なアドレスを決定します。EAP_HOME/standalone/configuration/standalone.xml ファイルは、スタンドアロンサーバーの設定を保持し、EAP_HOME/domain/configuration/domain.xml ファイルと EAP_HOME/domain/configuration/host.xml ファイルは管理対象ドメインの設定を保持します。

      例3.3 操作アドレスの例

      ロギングサブシステムで操作を実行するには、操作要求に以下のアドレスを使用します。
      /subsystem=logging
      Java データソースに対して操作を実行するには、操作要求に以下のアドレスを使用します。
      /subsystem=datasources/data-source=java
    2. 操作の決定

      リソースノードのタイプによって操作は異なります。操作では以下の構文を使用します。
      :operation-name
      • operation-name は、要求する操作の名前です。
      利用可能な操作をリストするために、スタンドアロンサーバーの任意のリソースアドレスで read-operation-names 操作を使用します。

      例3.4 利用可能な操作

      ロギングサブシステムのすべての利用可能な操作をリストするために、スタンドアロンサーバーの以下の要求を入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove",
              "undefine-attribute",
              "whoami",
              "write-attribute"
          ]
      }
    3. パラメーターの決定

      各操作では異なるパラメーターが必要な場合があります。
      パラメーターは以下の構文を使用します。
      (parameter-name=parameter-value)
      • parameter-name は、パラメーターの名前です。
      • parameter-value は、パラメーターの値です。
      • 複数のパラメーターは、カンマ (,) で区切られます。
      必要なパラメーターを決定するには、リソースノードで操作名をパラメーターとして渡し、read-operation-description コマンドを実行します。詳細については、例3.5「操作パラメーターの決定」を参照してください。

      例3.5 操作パラメーターの決定

      ロギングサブシステムで read-children-types 操作に必須のパラメーターを決定するには、以下のように read-operation-description コマンドを入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "read-children-types",
              "description" => "Gets the type names of all the children under the selected resource",
              "reply-properties" => {
                  "type" => LIST,
                  "description" => "The children types",
                  "value-type" => STRING
              },
              "read-only" => true
          }
      }
  2. 完全操作要求の入力

    アドレス、操作、およびパラメーターが決定されたら、完全操作要求を入力します。

    例3.6 操作要求の例

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
結果

管理インターフェースは、サーバー設定の操作要求を実行します。

3.5.9. 管理 CLI コマンドのリファレンス

概要

トピック「管理 CLI でのヘルプの使用」では、一般オプションおよび状況依存オプションとのヘルプダイアログを含む管理 CLI ヘルプ機能にアクセスする方法について説明しています。ヘルプコマンドは、操作コンテキストに依存し、スタンドアロンまたはドメインコントローラへの確立された接続を必要とします。接続が確立されない限り、これらのコマンドはリストに表示されません。

表3.3

コマンド 説明
batch 新しいバッチを作成してバッチモードを開始するか、既存の保留中のバッチに応じて、バッチを再びアクティベートします。保留中のバッチがない場合は、引数なしで呼び出されたこのコマンドによって新しいバッチが開始されます。名前がない保留中のバッチがある場合は、このコマンドによってそのバッチが再びアクティベートされます。名前がある保留中のバッチがある場合は、保留中のバッチの名前を引数にしてこのコマンドを実行することにより、これらのバッチをアクティベートできます。
cd 現在のノードパスを引数に変更します。現在のノードパスはアドレス部分を含まない操作要求のアドレスとして使用されます。操作要求にアドレスが含まれる場合、そのアドレスは現在のノードパスに対して相対的であると見なされます。現在のノードパスは node-type で終わることがあります。その場合は、logging:read-resource などの node-name を指定すれば操作を実行できます。
clear 画面を消去します。
command 新しいタイプコマンドを追加し、既存の汎用タイプコマンドを削除およびリストできます。汎用タイプコマンドは、特定のノードタイプに割り当てられたコマンドであり、そのタイプのインスタンス向けの操作を実行可能にします。また、既存インスタンスのタイプにより公開された任意のプロパティーを変更することもできます。
connect 指定されたホストおよびポートのコントローラに接続します。
connection-factory 接続ファクトリーを定義します。
data-source データソースサブシステムで JDBC データソース設定を管理します。
deploy ファイルパスで指定されたアプリケーションをデプロイするか、リポジトリで無効な既存のアプリケーションを有効にします。引数なしで実行された場合は、このコマンドにより、既存のすべてのデプロイメントがリストされます。
help ヘルプメッセージを表示します。該当するコマンドの状況依存の結果を提供するには、--commands 引数とともに使用します。
history メモリー内の CLI コマンド履歴を表示し、履歴拡張が有効または無効であるかを表示します。必要に応じて履歴拡張をクリア、無効、および有効にするには、引数とともに使用します。
jms-queue メッセージングサブシステムで JMS キューを定義します。
jms-topic メッセージングサブシステムで JMS トピックを定義します。
ls ノードパスの内容をリストします。デフォルトでは、ターミナルの全体の幅を使用して結果が列で出力されます。-l スイッチを使用すると、1 行あたり 1 つの名前で結果が出力されます。
pwd 現在動作しているノードの完全ノードパスを出力します。
quit コマンドラインインターフェースを終了します。
read-attribute 値を出力し、引数によっては管理対象リソースの属性の説明も出力します。
read-operation 指定された操作の説明を表示します。指定された操作がない場合は利用可能なすべての操作をリストします。
undeploy 目的のアプリケーションの名前で実行された場合にアプリケーションをアンデプロイします。リポジトリからアプリケーションを削除するには引数とともに使用します。アプリケーションを指定せずに実行すると、既存のすべてのデプロイメントをリストします。
version アプリケーションサーバーのバージョンと環境情報を出力します。
xa-data-source データソースサブシステムで JDBC XA データソース設定を管理します。

3.5.10. 管理 CLI 操作のリファレンス

管理 CLI の操作の公開

管理 CLI の操作は、トピック「管理 CLI を使用した操作名の表示」で解説している read-operation-names を使用すると公開できます。また、操作の説明は、トピック「管理 CLI を使用した操作説明の表示」で解説している read-operation-descriptions 操作を使用すると表示できます。

表3.4 管理 CLI の操作

操作名 説明
add-namespace namespaces 属性のマップに名前空間接頭辞のマッピングを追加します。
add-schema-location schema-locations 属性のマップにスキーマロケーションマッピングを追加します。
delete-snapshot snapshots ディレクトリーからサーバー設定のスナップショットを削除します。
full-replace-deployment 以前にアップロードされたデプロイメントコンテンツを使用可能なコンテンツの一覧に追加して、ランタイムの同名の既存コンテンツを置き換え、その置き換えられたコンテンツを使用可能なコンテンツの一覧から削除します。詳細はリンク先を参照してください。
list-snapshots snapshots ディレクトリーに保存されているサーバー設定のスナップショットを一覧表示します。
read-attribute 選択したリソースの属性値を表示します。
read-children-names 指定タイプの選択したリソース配下にあるすべての子リソースの名前を表示します。
read-children-resources 指定のタイプであるすべての子リソースに関する情報を表示します。
read-children-types 選択したリソースの配下にあるすべての子リソースのタイプ名を表示します。
read-config-as-xml 現在の設定を読み込み、XML 形式で表示します。
read-operation-description 特定のリソースに対する操作の詳細を表示します。
read-operation-names 特定のリソースに対する全操作の名前を表示します。
read-resource モデルリソースの属性値および任意の子リソースの基本情報もしくは詳細情報を表示します。
read-resource-description リソースの属性、子リソースのタイプ、および操作についての詳細を表示します。
reload 全サービスをシャットダウンして再起動することにより、サーバーを再ロードします。
remove-namespace namespaces 属性マップから名前空間接頭辞のマッピングを削除します。
remove-schema-location schema-locations 属性マップからスキーマロケーションマッピングを削除します。
replace-deployment ランタイムの既存コンテンツを新規コンテンツに置き換えます。新規コンテンツはデプロイメントコンテンツリポジトリに事前にアップロードしておく必要があります。
resolve-expression 式を、式へ解析可能な入力または文字列として許可し、ローカルのシステムプロパティーおよび環境変数に対して解決する操作です。
resolve-internet-address インターフェース解決基準のセットを取得し、基準に一致するローカルマシンで IP アドレスを見つけます。一致する IP アドレスがない場合は失敗します。
server-set-restart-required 再起動が必要なモードにサーバーを設定します。
shutdown System.exit(0) の呼び出しにより、サーバーをシャットダウンします。
start-servers 現在実行されていないすべての設定済みサーバーを管理対象ドメインで起動します。
stop-servers 管理対象ドメインで現在実行しているすべてのサーバーを停止します。
take-snapshot サーバー設定のスナップショットを作成し、snapshots ディレクトリーに保存します。
upload-deployment-bytes 含まれるバイト配列のデプロイメントコンテンツは、デプロイメントコンテンツリポジトリに追加する必要があることを指定します。この操作は、コンテンツをランタイムへデプロイする必要があるとは指定しない点に注意してください。
upload-deployment-stream 含まれる入力ストリームインデックスで利用可能なデプロイメントコンテンツは、デプロイメントコンテンツリポジトリに追加する必要があることを指定します。この操作は、コンテンツがランタイムにデプロイされる必要があることは指定しない点に注意してください。
upload-deployment-url 含まれる URL で利用可能なデプロイメントコンテンツはデプロイメントコンテンツリポジトリに追加する必要があることを指定します。この操作は、コンテンツがランタイムにデプロイされる必要があることは指定しない点に注意してください。
validate-address 操作のアドレスを検証します。
write-attribute 選択したリソースの属性値を設定します。

3.6. 管理 CLI の操作

3.6.1. 管理 CLI によるリソースの属性の表示

概要

read-attribute 操作は、選択した属性の現在のランタイム値を読み取るために使用されるグローバル操作です。この操作を使用すると、デフォルトの値や非定義の値を無視し、ユーザーが設定した値のみを表示できます。要求プロパティーには次のパラメーターが含まれます。

要求プロパティー

name
選択したリソース下で値を取得する属性の名前。
include-defaults
false を設定すると、デフォルト値を無視し、ユーザーが設定した属性のみを表示するよう操作結果を制限できるブール値パラメーター。

手順3.14 選択した属性の現在のランタイム値を表示

  • read-attribute 操作の実行

    管理 CLI より read-attribute を使用してリソース属性の値を表示します。操作要求の詳細は「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-attribute(name=name-of-attribute)
read-attribute 操作の利点は、特定属性の現在のランタイム値を表示できることです。read-resource 操作でも同様の結果を得ることができますが、include-runtime 要求プロパティーを追加した場合のみ可能で、そのノードに対して使用できる全リソース一覧の一部のみを表示できます。次の例が示すように、read-attribute 操作は粒度の細かい属性クエリを対象としています。

例3.7 read-attribute 操作を実行したパブリックインターフェース IP の表示

表示したい属性の名前が分かる場合は、read-attribute を使用して現在のランタイムの厳密値を返します。
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}
resolved-address 属性はランタイム値であるため、標準的な read-resource 操作の結果には表示されません。
[standalone@localhost:9999 /] /interface=public:read-resource                        
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
resolved-address や他のランタイム値を表示するには、include-runtime 要求プロパティーを使用する必要があります。
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "resolved-address" => "127.0.0.1",
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
結果

現在のランタイム属性値が表示されます。

3.6.2. 管理 CLI でのアクティブユーザーの表示

概要

whoami の操作は、現在アクティブなユーザーの属性を識別するために使用されるグローバルな操作です。この操作はユーザー名の ID と割り当てられたレルムを表示します。whoami の操作は、管理者が複数のレルムで複数のユーザーを管理する場合や、複数のターミナルセッションやユーザーアカウントを持つドメインインスタンス全体でアクティブユーザーを追跡する場合に便利です。

手順3.15 whoami を使用した管理 CLI でのアクティブユーザーの表示

  • whoami の実行

    管理 CLI より whoami を使用し、アクティブなユーザーのアカウントを表示します。
    [standalone@localhost:9999 /] :whoami
    次の例はスタンドアロンサーバーで whoami を使用し、アクティブなユーザーは usernameManagementRealm レルムが割り当てられていることを表しています。

    例3.8 スタンドアロンインスタンスでの whoami の使用

    [standalone@localhost:9999 /]:whoami
    {
        "outcome" => "success",
        "result" => {"identity" => {
            "username" => "username",
            "realm" => "ManagementRealm"
        }}
    }
    
結果

現在アクティブなユーザーのアカウントが表示されます。

3.6.3. 管理 CLI でのシステムおよびサーバー情報の表示

手順3.16 管理 CLI でのシステムおよびサーバー情報の表示

  • version コマンドの実行

    管理 CLI で、version コマンドを入力します。
    [domain@localhost:9999 /] version
結果

アプリケーションサーバーのバージョンと環境情報が表示されます。

3.6.4. 管理 CLI を使用した操作説明の表示

手順3.17 管理 CLI でのコマンドの実行

  • read-operation-description 操作の実行

    管理 CLI で、read-operation-description を使用して、操作に関する情報を表示します。操作ではキーと値のペアの形式でパラメーターを追加して、表示する操作を示す必要があります。操作結果の詳細については、「管理 CLI での操作およびコマンドの使用」 を参照してください。
    [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)

例3.9 list-snapshots 操作の説明表示

次の例は、list-snapshots 操作を説明する方法を示しています。
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "list-snapshots",
        "description" => "Lists the snapshots",
        "request-properties" => {},
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "min-length" => 1L,
                    "max-length" => 2147483647L
                },
                "names" => {
                    "type" => LIST,
                    "description" => "The names of the snapshots within the snapshots directory",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "value-type" => STRING
                }
            }
        },
        "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}},
        "read-only" => false
    }
}
結果

選択した操作に関する説明が表示されます。

3.6.5. 管理 CLI を使用した操作名の表示

手順3.18 管理 CLI でのコマンドの実行

  • read-operation-names の実行

    管理 CLI より read-operation-names 操作を使用して利用可能な操作の名前を表示します。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-operation-names

例3.10 管理 CLI を使用した操作名の表示

次の例は、read-operation-names 操作を説明する方法を示しています。
[standalone@localhost:9999 /]:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "resolve-expression",
        "resolve-internet-address",
        "server-set-restart-required",
        "shutdown",
        "take-snapshot",
        "undefine-attribute",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "validate-operation",
        "whoami",
        "write-attribute"
    ]
}
結果

利用可能な操作名が表示されます。

3.6.6. 管理 CLI を使用した利用可能なリソースの表示

概要

read-resource 操作は、リソース値を読み取るために使用されるグローバル操作です。この操作を使用すると、現在のノードまたは子ノードのリソースに関する基本または詳細情報や、操作結果の範囲を拡大または制限するさまざまな要求プロパティーを表示できます。要求プロパティーには、以下のパラメーターが含まれます。

要求プロパティー

recursive
子リソースに関する詳細情報を再帰的に含めるかどうか。
recursive-depth
含まれる子リソースの情報の深さ。
proxies
再帰的なクエリにリモートリソースを含めるかどうか。たとえば、ドメインコントローラーのクエリにスレーブのホストコントローラーからのホストレベルのリソースを含めること。
include-runtime
応答に、永続的な設定ではない属性値などのランタイム属性を含めるかどうか。この要求プロパティーは、デフォルトで false に設定されます。
include-defaults
デフォルト属性の読み取りを有効または無効にするブール値要求プロパティー。false に設定された場合は、ユーザが設定した属性のみが返され、未定義のままの属性は無視されます。

手順3.19 管理 CLI でのコマンドの実行

  1. read-resource 操作の実行

    管理 CLI で、read-resource 操作を使用して利用可能なリソースを表示します。
    [standalone@localhost:9999 /]:read-resource
    以下の例は、スタンドアロンサーバーインスタンスで read-resource 操作を使用して一般的なリソース情報を表示する方法を示しています。結果は standalone.xml 設定ファイルに類似し、サーバーインスタンス向けにインストールまたは設定されたシステムリソース、拡張機能、インターフェース、およびサブシステムを表示します。これらの情報は、さらに直接問い合わせできます。

    例3.11 ルートレベルでの read-resource 操作の使用

    [standalone@localhost:9999 /]:read-resource
    {
        "outcome" => "success",
        "result" => {
            "deployment" => undefined,
            "deployment-overlay" => undefined,
            "management-major-version" => 1,
            "management-micro-version" => 0,
            "management-minor-version" => 4,
            "name" => "longgrass",
            "namespaces" => [],
            "product-name" => "EAP",
            "product-version" => "6.1.0.GA",
            "release-codename" => "Janus",
            "release-version" => "7.2.0.Final-redhat-3",
            "schema-locations" => [],
            "system-property" => undefined,
            "core-service" => {
                "management" => undefined,
                "service-container" => undefined,
                "server-environment" => undefined,
                "platform-mbean" => undefined
            },
            "extension" => {
                "org.jboss.as.clustering.infinispan" => undefined,
                "org.jboss.as.connector" => undefined,
                "org.jboss.as.deployment-scanner" => undefined,
                "org.jboss.as.ee" => undefined,
                "org.jboss.as.ejb3" => undefined,
                "org.jboss.as.jaxrs" => undefined,
                "org.jboss.as.jdr" => undefined,
                "org.jboss.as.jmx" => undefined,
                "org.jboss.as.jpa" => undefined,
                "org.jboss.as.jsf" => undefined,
                "org.jboss.as.logging" => undefined,
                "org.jboss.as.mail" => undefined,
                "org.jboss.as.naming" => undefined,
                "org.jboss.as.pojo" => undefined,
                "org.jboss.as.remoting" => undefined,
                "org.jboss.as.sar" => undefined,
                "org.jboss.as.security" => undefined,
                "org.jboss.as.threads" => undefined,
                "org.jboss.as.transactions" => undefined,
                "org.jboss.as.web" => undefined,
                "org.jboss.as.webservices" => undefined,
                "org.jboss.as.weld" => undefined
            },
            "interface" => {
                "management" => undefined,
                "public" => undefined,
                "unsecure" => undefined
            },
            "path" => {
                "jboss.server.temp.dir" => undefined,
                "user.home" => undefined,
                "jboss.server.base.dir" => undefined,
                "java.home" => undefined,
                "user.dir" => undefined,
                "jboss.server.data.dir" => undefined,
                "jboss.home.dir" => undefined,
                "jboss.server.log.dir" => undefined,
                "jboss.server.config.dir" => undefined,
                "jboss.controller.temp.dir" => undefined
            },
            "socket-binding-group" => {"standard-sockets" => undefined},
            "subsystem" => {
                "logging" => undefined,
                "datasources" => undefined,
                "deployment-scanner" => undefined,
                "ee" => undefined,
                "ejb3" => undefined,
                "infinispan" => undefined,
                "jaxrs" => undefined,
                "jca" => undefined,
                "jdr" => undefined,
                "jmx" => undefined,
                "jpa" => undefined,
                "jsf" => undefined,
                "mail" => undefined,
                "naming" => undefined,
                "pojo" => undefined,
                "remoting" => undefined,
                "resource-adapters" => undefined,
                "sar" => undefined,
                "security" => undefined,
                "threads" => undefined,
                "transactions" => undefined,
                "web" => undefined,
                "webservices" => undefined,
                "weld" => undefined
            }
        }
    }
    
  2. 子ノードに対する read-resource 操作の実行

    read-resource 操作は、ルートから子ノードを問い合わせるために実行できます。操作の構造は最初に公開するノードを定義し、ノードに対して実行する操作を追加します。
    [standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource
    以下の例では、特定の Web サブシステムノードに対して read-resource 操作を行うと、Web サブシステムコンポーネントに関する固有のリソース情報を公開できます。

    例3.12 ルートノードからの子ノードリソースの公開

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    cd コマンドを使用して子ノードに移動し、read-resource 操作を直接実行しても、同じ結果を得ることができます。

    例3.13 ディレクトリーの変更による子ノードリソースの公開

    [standalone@localhost:9999 /] cd subsystem=web
    [standalone@localhost:9999 subsystem=web] cd connector=http
    [standalone@localhost:9999 connector=http] :read-resource
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => undefined,
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
  3. 再帰的なパラメーターを使用して結果にアクティブな値を含める

    再帰的なパラメーターを使用して、永続的でない値、起動時に渡された値、またはランタイムモデルでアクティブな他の属性を含むすべての属性の値を公開できます。
    [standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)
    以前の例と比較して、include-runtime 要求プロパティーを含めることにより、HTTP コネクターにより送信されたバイトや受信されたバイトなどの追加のアクティブな属性が公開されます。

    例3.14 include-runtime パラメーターを使用して追加でアクティブな値を公開

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
    {
        "outcome" => "success",
        "result" => {
            "any" => undefined,
            "any-address" => undefined,
            "any-ipv4-address" => undefined,
            "any-ipv6-address" => undefined,
            "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
            "link-local-address" => undefined,
            "loopback" => undefined,
            "loopback-address" => undefined,
            "multicast" => undefined,
            "name" => "public",
            "nic" => undefined,
            "nic-match" => undefined,
            "not" => undefined,
            "point-to-point" => undefined,
            "public-address" => undefined,
            "resolved-address" => "127.0.0.1",
            "site-local-address" => undefined,
            "subnet-match" => undefined,
            "up" => undefined,
            "virtual" => undefined
        }
    }
    

3.6.7. 管理 CLI を使用した利用可能なリソース説明の表示

手順3.20 管理 CLI でのコマンドの実行

  1. read-resource-description の実行

    管理 CLI で、read-resource-description 操作を使用して利用可能なリソースを読み取り、表示します。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:read-resource-description
  2. オプションパラメーターの使用

    read-resource-description 操作では、追加パラメーターを使用できます。
    1. リソースの操作の説明を表示するには、operations パラメーターを使用します。
      [standalone@localhost:9999 /]:read-resource-description(operations=true)
    2. リソースの継承された操作の説明を表示または非表示にするには、inherited パラメーターを使用します。デフォルトは true です。
      [standalone@localhost:9999 /]:read-resource-description(inherited=false)
    3. 子リソースの操作の再帰的な説明を表示するには、recursive パラメーターを使用します。
      [standalone@localhost:9999 /]:read-resource-description(recursive=true)
    4. リソースの説明を表示するには、locale パラメーターを使用します。null の場合は、デフォルトのロケールが使用されます。
      [standalone@localhost:9999 /]:read-resource-description(locale=true)
結果

利用可能なリソースの説明が表示されます。

3.6.8. 管理 CLI を使用したアプリケーションサーバーのリロード

手順3.21 アプリケーションのリロード

  • reload 操作の実行

    管理 CLI で、reload 操作を使用して System.exit(0) システムコールを介してサーバーをシャットダウンします。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
    [standalone@localhost:9999 /]:reload
    {"outcome" => "success"}
    
結果

すべてのサービスをシャットダウンし、ランタイムを再び起動することにより、アプライアンスサーバーがリロードされます。管理 CLI が自動的に再接続されます。

3.6.9. 管理 CLI を使用したアプリケーションサーバーのシャットダウン

手順3.22 アプリケーションサーバーのシャットダウン

  • shutdown 操作の実行

    • 管理 CLI で、shutdown 操作を使用し System.exit(0) システムコールを介してサーバーをシャットダウンします。操作要求の詳細については、トピック「管理 CLI での操作およびコマンドの使用」を参照してください。
      • スタンドアロンモードでは、次のコマンドを使用します。
        [standalone@localhost:9999 /]:shutdown
      • ドメインモードでは、適切なホスト名を指定して次のコマンドを使用します。
        [domain@localhost:9999 /]/host=master:shutdown
    • デタッチした CLI インスタンスへ接続し、サーバーをシャットダウンするには、次のコマンドを実行します。
      jboss-cli.sh --connect command=:shutdown
      
    • リモート CLI インスタンスへ接続し、サーバーをシャットダウンするには、次のコマンドを実行します。
      [disconnected /] connect IP_ADDRESS
      Connected to IP_ADDRESS:PORT_NUMBER
      [192.168.1.10:9999 /] :shutdown
      
      IP_ADDRESS をインスタンスの IP アドレスに置き換えます。
結果

アプリケーションサーバーがシャットダウンされます。ランタイムが利用できない場合に、管理 CLI が切断されます。

3.6.10. 管理 CLI での属性の設定

概要

write-attribute 操作は、選択されたリソース属性を記述または変更するために使用するグローバル操作です。この操作を使用して永続的な変更を行い、管理対象サーバーインスタンスの設定を変更できます。要求プロパティーには以下のパラメーターが含まれます。

要求プロパティー

name
選択されたリソース下で値を設定する属性の名前。
value
選択されたリソース下の属性の必要な値。基礎となるモデルが null 値をサポートする場合は、null になることがあります。

手順3.23 管理 CLI でのリソース属性の設定

  • write-attribute 操作の実行

    管理 CLI で、write-attribute 操作を使用してリソース属性の値を変更します。操作は、完全リソースパスが指定されたリソースの子ノードまたは管理 CLI のルートノードで実行できます。

例3.15 write-attribute 操作によるデプロイメントスキャナーの無効化

以下の例では、write-attribute 操作を使用してデプロイメントスキャナーを無効にします。操作は、ルートノードから実行されます (タブ補完を使用して正しいリソースパスを入力します)。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}
操作の結果は、read-attribute 操作を直接使用して確認できます。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}
また、read-resource 操作を使用し、すべてのノードの利用可能なリソース属性をリストして結果を確認することもできます。以下の例では、scan-enabled 属性が false に設定されていることが分かります。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource                                 
{
    "outcome" => "success",
    "result" => {
        "auto-deploy-exploded" => false,
        "auto-deploy-xml" => true,
        "auto-deploy-zipped" => true,
        "deployment-timeout" => 600,
        "path" => "deployments",
        "relative-to" => "jboss.server.base.dir",
        "scan-enabled" => false,
        "scan-interval" => 5000
    }
}
結果

リソース属性が更新されます。

3.7. 管理 CLI コマンド履歴

3.7.1. 管理 CLI コマンド履歴の利用

管理 CLI にはコマンドの履歴機能があり、これはアプリケーションサーバーのインストール時にデフォルトで有効になっています。この履歴はアクティブな CLI セッションの揮発性メモリーでレコードとして保持されるか、ユーザーのホームディレクトリーに .jboss-cli-history として自動的に保存されるログファイルに追加されます。この履歴ファイルはデフォルトで、CLI コマンドを最大 500 件記録できるよう設定されます。
history コマンド自体は、現在のセッションの履歴を返しますが、引数を追加すると、セッションメモリーの履歴を無効化、有効化、または消去できます。管理 CLI では、キーボードの矢印キーを使用してコマンドや操作の履歴を前後に移動できます。

3.7.2. 管理 CLI コマンド履歴の表示

手順3.24 管理 CLI コマンド履歴の表示

  • history コマンドの実行

    管理 CLI で、history コマンドを入力します。
    [standalone@localhost:9999 /] history
結果

CLI の起動後または履歴削除コマンドの実行後にメモリーに格納された CLI コマンドの履歴が表示されます。

3.7.3. 管理 CLI コマンド履歴の消去

手順3.25 管理 CLI コマンド履歴の消去

  • history --clear コマンドの実行

    管理 CLI で、history --clear コマンドを入力します。
    [standalone@localhost:9999 /] history --clear
結果

CLI の起動後に記録されたコマンドの履歴がセッションメモリーから削除されます。コマンド履歴は、ユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに保持されます。

3.7.4. 管理 CLI コマンド履歴の無効化

手順3.26 管理 CLI コマンド履歴の無効化

  • history --disable コマンドの実行

    管理 CLI で、history --disable コマンドを入力します。
    [standalone@localhost:9999 /] history --disable
結果

CLI で実行されたコマンドは、メモリー内およびユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルには記録されません。

3.7.5. 管理 CLI コマンド履歴の有効化

手順3.27 管理 CLI コマンド履歴の有効化

  • history --enable コマンドの実行

    管理 CLI で、history --enable コマンドを入力します。
    [standalone@localhost:9999 /] history --enable
結果

CLI で実行されたコマンドは、メモリー内およびユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに記録されます。

3.8. 管理インターフェース監査ロギング

3.8.1. 管理インターフェース監査ロギング

監査ロギングを有効にすると、管理 API より実行された操作が監査ログに記録されます。管理コンソール、管理 CLI インターフェース、およびカスタムのインターフェースから実行された操作すべてが監査ロギングの対象となります。ログレコードは、ファイルへ出力したり、syslog サーバーへ転送したりできます。デフォルトでは、ロギングは無効になっています。
ログデータは JSON 形式で出力され、ログおよびログエントリーの形式に含まれる操作に対応する複数の設定オプションが使用できます。
ログエントリーは、保存される前にフォーマッターおよびハンドラーへ渡されます。フォーマッターはログエントリーの形式を指定し、ハンドラーはレコードを指定の宛先に出力します。現在、エントリーを JSON 形式で出力する 1 つのフォーマッターのみを使用できます。

注記

監査ロギングは、管理 CLI からのみ設定できます。

3.8.2. 管理 CLI より管理インターフェース監査ロギングを有効にする

管理 CLI より監査ロギングを有効にするには、次のコマンドを使用します。
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
監査ロギングは、ファイル EAP_HOME/standalone/data/audit-log.log. へ出力するよう事前設定されています。

3.8.3. 管理インターフェースの監査ロギングフォーマッター

フォーマッターはログエントリーの形式を指定します。

表3.5 JSON フォーマッターフィールド

属性 説明
include-date フォーマットされたログレコードにタイムスタンプが含まれるかどうかを定義するブール値。
date-separator 日付と日付以外のフォーマットされたログメッセージを区別する文字が含まれる文字列。include-date=false の場合は無視されます。
date-format java.text.SimpleDateFormat が理解するように、タイムスタンプに使用するデータ形式。include-date=false の場合は無視されます。
compact true の場合、JSON を 1 行でフォーマットします。新しい行が含まれる値が存在する可能性があるため、レコード全体を 1 行にするのが重要な場合は、escape-new-line または escape-control-characterstrue に設定します。
escape-control-characters true の場合、すべての制御文字 (10 進値が 32 未満の ASCII エントリー) を 8 進の ASCII コードでエスケープします。たとえば、新しい行は「#012」になります。true の場合、escape-new-line=false を上書きします。
escape-new-line true の場合、新しい行をすべて 8 進の ASCII コードでエスケープします (例:「#012」)。

3.8.4. 管理インターフェースの監査ロギングファイルハンドラー

ファイルハンドラーは、監査ログの記録がファイルへ出力されるようにするパラメーターを指定します。ファイルハンドラーは、ファイルのフォーマッター、ファイル名、およびパスを定義します。

表3.6 ファイルハンドラーの監査ログフィールド

属性 説明 読み取り専用
formatter ログレコードをフォーマットするために使用する JSON フォーマッターの名前。 False
path 監査ログファイルのパス。 False
relative-to 以前指定された別のパスの名前、またはシステムによって提供される標準的なパスの 1 つ。relative-to が指定された場合、パス属性の値は、この属性によって指定されたパスへの相対値としてみなされます。 False
failure-count ハンドラーが初期化された後に発生したロギング失敗数。 True
max-failure-count このハンドラーを無効化する前の最大ロギング失敗数。 False
disabled-due-to-failure ロギングの失敗によりこのハンドラーが無効になった場合は true になります。 True

3.8.5. 管理インターフェイスの監査ロギング syslog ハンドラー

syslog ハンドラーは、監査ログエントリーが syslog サーバーへ送信されるパラメーターを指定します。特に、syslog サーバーのホスト名と syslog サーバーがリッスンするポートを指定します。
監査ロギングを syslog サーバーへ送信すると、ローカルファイルまたはローカル syslog サーバーへロギングするよりも、セキュリティーオプションが多くなります。複数の syslog ハンドラーを定義できます。
syslog サーバーごとに実装が異なるため、すべての設定をすべての syslog サーバーに適用することはできません。テストは rsyslog syslog 実装を使用して実行されています。参照した RFC は次のとおりです。
  • http://www.ietf.org/rfc/rfc3164.txt
  • http://www.ietf.org/rfc/rfc5424.txt
  • http://www.ietf.org/rfc/rfc6587.txt

表3.7 syslog ハンドラーフィールド

フィールド 説明 読み取り専用
formatter ログレコードのフォーマットに使用するフォーマッターの名前。 False
failure-count ハンドラーが初期化された後に発生したロギング失敗数。 True
max-failure-count このハンドラーを無効化する前の最大ロギング失敗数。 False
disabled-due-to-failure ロギングの失敗によりこのハンドラーが無効になった場合は True になります。 True
syslog-format syslog 形式 (RFC-5424 または RFC-3164)。 False
max-length ヘッダーを含む、ログメッセージの最大長 (バイト単位)。未定義の場合、デフォルトは 1024 バイト (syslog-format が RFC3164 の場合) または 2048 バイト (syslog-format が RFC5424 の場合) になります。 False
truncate ヘッダーを含むメッセージの長さ (バイト長) が最大長を越える場合に、そのメッセージを省略するかどうか。false に設定すると、メッセージが分割され、同じヘッダー値で送信されます。 False

3.8.6. syslog サーバーへの管理インターフェース監査ロギングの有効化

注記

管理対象ドメインへ変更を適用する場合は、/host=HOST_NAME 接頭辞を /core-service コマンドへ追加します。

手順3.28 syslog サーバーへのロギングの有効化

  1. msyslog という名前の syslog ハンドラーを作成します。

    [standalone@localhost:9999 /]batch
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
    [standalone@localhost:9999 /]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
    [standalone@localhost:9999 /]run-batch
  2. syslog ハンドラーへの参照を追加します。

    [standalone@localhost:9999 /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
結果

管理インターフェースの監査ログエントリーが syslog サーバーに記録されます。

3.8.7. 管理インターフェースの監査ロギングオプション

管理インターフェースの監査ロギングを有効または無効にする以外に、他の設定オプションを使用することもできます。

設定オプション

log-boot
true に設定された場合、サーバーをブートするときの管理操作が監査ログに含まれます。false の場合は含まれません。デフォルトは false です。
log-read-only
true に設定された場合、すべての操作が監査ログに記録されます。false の場合は、モデルを変更する操作のみが記録されます。デフォルトは false です。

3.8.8. 管理インターフェースの監査ログフィールド

表3.8 管理インターフェースの監査ログフィールド

フィールド名 説明
type 管理操作であることを示す core、または JMX サブシステムからであることを示す jmx を値として指定できます (JMX サブシステムの監査ロギングの設定については JMX サブシステムを参照してください)。
r/o 操作によって、管理モデルが変更されない場合は true になります。変更される場合は false です。
booting 起動プロセス中に操作が実行された場合は true になります。サーバーの起動後に操作が実行された場合は false になります。
version JBoss EAP インスタンスのバージョン番号。
user 認証されたユーザーのユーザー名。
domainUUID ドメインコントローラーからサーバー、スレーブホストコントローラー、およびスレーブホストコントローラーサーバーへ伝播されるすべての操作をリンクする識別子。
access NATIVE、HTTP、または JMX のいずれかを指定できます。ネイティブの管理インターフェース (CLI など) を介した操作の場合は NATIVE になります。ドメイン HTTP インターフェース (管理コンソールなど) を介した操作の場合は HTTP になります。JMX サブシステムを介した操作の場合は JMX になります。JMX に監査ロギングを設定する方法は JMX を参照してください。
remote-address この操作を実行するクライアントのアドレス。
success 操作に成功した場合は true になります。ロールバックされた場合は false になります。
ops 実行された操作。JSON へシリアライズされた操作のリストになります。起動時は、XML の解析で生じたすべての操作がリストされます。起動後は、通常 1 つのエントリーがリストされます。

第4章 ユーザー管理

4.1. ユーザー作成

4.1.1. 管理インターフェースのユーザーの追加

概要

JBoss EAP 6 の管理インターフェースは、グラフィカルインストーラーを使用してインストールしないと最初から使用可能なユーザーアカウントが存在しないため、デフォルトでセキュアになっています。これは、単純な設定ミスによるリモートシステムからのセキュリティー侵害を防ぐためのセキュリティー対策です。ローカルの HTTP 以外のアクセスは SASL メカニズムによって保護され、クライアントがローカルホストから初めて接続するたびにクライアントとサーバー間のネゴシエーションが発生します。

このタスクでは、最初の管理ユーザーを作成する方法について説明します。このユーザーは、Web ベースの管理コンソールおよび管理 CLI のリモートインスタンスを使用して、リモートシステムから JBoss EAP 6 を設定および管理できます。

注記

JBoss EAP 6 との HTTP 通信は、トラフィックの送信元がローカルホストであってもリモートアクセスと見なされます。したがって、管理コンソールを使用するには、少なくとも 1 人のユーザーを作成する必要があります。ユーザーを追加する前に管理コンソールにアクセスしようとすると、ユーザーが追加されるまでデプロイされないため、エラーが発生します。

手順4.1 リモート管理インターフェースに最初の管理ユーザーを作成

  1. add-user.sh または add-user.bat スクリプトを呼び出します。

    EAP_HOME/bin/ ディレクトリーへ移動します。ご使用のオペレーティングシステムに対応するスクリプトを呼び出します。
    Red Hat Enterprise Linux
    [user@host bin]$ ./add-user.sh
    Microsoft Windows Server
    C:\bin>  add-user.bat
  2. 管理ユーザーの追加を選択します。

    ENTER を押してデフォルトオプション a を選択し、管理ユーザーを追加します。このユーザーは ManagementRealm に追加され、Web ベースの管理コンソールまたはコマンドラインベースの管理 CLI を使用して管理操作を実行することを許可されます。他のオプション b を選択すると、ユーザーが ApplicationRealm に追加され、特定のパーミッションは付与されません。このレルムはアプリケーションで使用するために提供されます。
  3. ユーザー名とパスワードを入力します。

    ユーザー名とパスワードの入力を要求されたら入力します。入力後、パスワードを確認するよう指示されます。
  4. グループ情報を入力します。

    ユーザーが属するグループを追加します。ユーザーが複数のグループに属する場合は、コンマ区切りリストを入力します。ユーザーのグループがない場合は空白のままにします。
  5. 情報を確認します。

    情報を確認するよう指示されます。情報が正しければ yes を入力します。
  6. ユーザーがリモート JBoss EAP 6 サーバーインスタンスを表すかどうかを選択します。

    管理者以外にも、場合によっては JBoss EAP 6 の別のインスタンスを表すユーザーを ManagementRealm で JBoss EAP 6 に追加する必要があることがあります。このユーザーは、メンバーとしてクラスターに参加することを認証できる必要があります。次のプロンプトでは、この目的のために追加されたユーザーを指定できます。yes を選択した場合は、ユーザーのパスワードを表すハッシュされた secret 値が提供されます。これは他の設定ファイルに追加する必要があります。このタスクでは、no を選択してください。
  7. 追加ユーザーを入力します。

    必要な場合は、この手順を繰り返すと追加のユーザーを入力できます。また、稼働中のシステムにいつでもユーザーを追加することが可能です。デフォルトのセキュリティーレルムを選択する代わりに他のレルムにユーザーを追加すると、承認を細かく調整できます。
  8. 非対話的にユーザーを作成します。

    コマンドラインで各パラメーターを渡すと非対話的にユーザーを作成できます。ログや履歴ファイルにパスワードが表示されるため、この方法は共有システムでは推奨されません。管理レルムを使用した、コマンドの構文は次のとおりです。
    [user@host bin]$ ./add-user.sh usernamepassword
    アプリケーションレルムを使用するには、-a パラメーターを使用します。
    [user@host bin]$ ./add-user.sh -a usernamepassword
  9. --silent パラメーターを渡すと add-user スクリプトの通常出力を無効にできます。これは、username および password の最低限のパラメーターが指定されている場合のみ適用されます。エラーメッセージは表示されます。
結果

追加したすべてのユーザーは、指定したセキュリティーレルム内でアクティベートされます。ManagementRealm レルム内でアクティブなユーザーは、リモートシステムから JBoss EAP 6 を管理できます。

4.1.2. ユーザー管理の add-user スクリプトへ引数を渡す

add-user.sh または add-user.bat コマンドを対話的に実行できますが、コマンドラインで引数を渡すこともできます。ここでは、コマンドライン引数を add-user スクリプトへ渡すときに使用可能なオプションについて説明します。
add-user.sh または add-user.bat コマンドで使用できるコマンドライン引数の一覧は、「add-user コマンド引数」 を参照してください。
代替のプロパティーファイルおよび場所を指定する方法については、「ユーザー管理情報の代替プロパティーファイルの指定」 を参照してください。
add-user.sh または add-user.bat コマンドで引数を渡す方法を実証する例は、「add-user スクリプトのコマンドラインの例」 を参照してください。

4.1.3. add-user コマンド引数

下表は、add-user.sh または add-user.bat コマンドで使用できる引数を表しています。

表4.1 add-user コマンド引数

コマンドライン引数 引数の値 説明
-a
該当なし
この引数は、アプリケーションレルムでユーザーを作成するよう指定します。省略した場合、デフォルトでは管理レルムでユーザーが作成されます。
-dc
DOMAIN_CONFIGURATION_DIRECTORY
この引数は、プロパティーファイルが含まれるドメイン設定ディレクトリーを指定します。省略した場合、デフォルトのディレクトリーは EAP_HOME/domain/configuration/ になります。
-sc
SERVER_CONFIGURATION_DIRECTORY
この引数は、プロパティーファイルが含まれる代替のスタンドアロンサーバー設定ディレクトリーを指定します。省略した場合、デフォルトのディレクトリーは EAP_HOME/standalone/configuration/ になります。
-up
--user-properties
USER_PROPERTIES_FILE
この引数は、代替のユーザープロパティーファイルの名前を指定します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
-g
--group
GROUP_LIST
このユーザーに割り当てるグループのコンマ区切りリスト。
-gp
--group-properties
GROUP_PROPERTIES_FILE
この引数は、代替のグループプロパティーファイルの名前を指定します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
-p
--password
PASSWORD
ユーザーのパスワード。パスワードは次の要件を満たしている必要があります。
  • ユーザー名と同じパスワードは使用できません。
  • 8 文字以上でなければなりません。
  • 1 文字以上のアルファベットが含まれなくてはなりません。
  • 1 文字以上の数字が含まれなければなりません。
  • 英数字以外の記号が 1 つ以上含まれなければなりません。
-u
--user
USER_NAME
ユーザー名。
-r
--realm
REALM_NAME
管理インターフェースをセキュアにするために使用されるレルムの名前。省略した場合、デフォルトは「ManagementRealm」になります。
-s
--silent
該当なし
コンソールへ出力せずに add-user スクリプトを実行します。
-h
--help
該当なし
add-user スクリプトの使用情報を表示します。

4.1.4. ユーザー管理情報の代替プロパティーファイルの指定

概要

デフォルトでは、add-user.sh または add-user.bat スクリプトを使用して作成されたユーザーおよびロール情報は、サーバー設定ディレクトリーにあるプロパティーファイルに保存されます。サーバー設定情報は EAP_HOME/standalone/configuration/ ディレクトリーに保存され、ドメイン設定情報は EAP_HOME/domain/configuration/ ディレクトリーに保存されます。ここでは、デフォルトのファイル名および場所を上書きする方法について説明します。

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

    • サーバー設定の代替のディレクトリーを指定するには、-sc 引数を使用します。この引数は、サーバー設定プロパティーファイルが含まれる代替のディレクトリーを指定します。
    • ドメイン設定の代替のディレクトリーを指定するには、-dc 引数を使用します。この引数は、ドメイン設定プロパティーファイルが含まれる代替のディレクトリーを指定します。
    • 代替のユーザー設定プロパティーファイルを指定するには、-up または --user-properties 引数を使用します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
    • 代替のグループ設定プロパティーファイルを指定するには、-gp または --group-properties 引数を使用します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。

注記

add-user コマンドは、既存のプロパティーファイルでの操作を目的とするコマンドです。コマンドライン引数に指定された代替のプロパティーファイルが存在しない場合は、次のエラーが表示されます。
JBAS015234: No appusers.properties files found
コマンド引数の詳細は、「add-user コマンド引数」 を参照してください。
add-user コマンドの例は、「add-user スクリプトのコマンドラインの例」 を参照してください。

4.1.5. add-user スクリプトのコマンドラインの例

以下の例は、add-user.sh または add-user.bat コマンドで引数を渡す方法を表しています。記載があるもの以外は、これらのコマンドはスタンドアローンサーバーの設定を前提としています。

例4.1 デフォルトのプロパティーファイルを使用して、単一のグループに属するユーザーを作成します。

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest'
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー appuser1 が、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • guest グループのユーザー appuser1 が、グループ情報が保存されるデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例4.2 デフォルトのプロパティーファイルを使用して、複数のグループに属するユーザーを作成します。

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest,app1group,app2group'
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー appuser1 が、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • グループが guestapp1group、および app2group のユーザー appuser1 が、グループ情報が保存されるデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例4.3 デフォルトのプロパティーファイルを使用して、デフォルトのレルムの管理特権を持つユーザーを作成します。

EAP_HOME/bin/add-user.sh -u 'adminuser1' -p 'password1!' -g 'admin'
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー adminuser1 が、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/mgmt-users.properties
    EAP_HOME/domain/configuration/mgmt-users.properties
  • admin グループのユーザー adminuser1 が、グループ情報が保存されるデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/mgmt-groups.properties
    EAP_HOME/domain/configuration/mgmt-groups.properties

例4.4 情報を保存する代替のプロパティーファイルを使用して、単一のグループに属するユーザーを作成します。

EAP_HOME/bin/add-user.sh -a -u appuser1 -p password1! -g app1group -sc /home/someusername/userconfigs/ -up appusers.properties -gp appgroups.properties 
上記のコマンドを実行した結果は次のとおりです。
  • ユーザー appuser1 が、以下のプロパティーファイルに追加され、このファイルがユーザー情報を保存するデフォルトファイルになります。
    /home/someusername/userconfigs/appusers.properties
  • app1group グループのユーザー appuser1 が、以下のプロパティーファイルに追加され、このファイルがグループ情報を保存するデフォルトファイルになります。
    /home/someusername/userconfigs/appgroups.properties

第5章 ネットワークおよびポート設定

5.1. インターフェース

5.1.1. インターフェース

アプリケーションサーバーは、設定全体で名前付きインターフェース参照を使用します。これにより、使用ごとにインターフェースの完全な詳細を使用するのではなく論理名を使用して個々のインターフェース宣言を参照できるようになります。また、論理名を使用することにより、管理対象ドメインのサーバーインスタンスに、複数のマシンのさまざまなインターフェース詳細が含まれることがある名前付きインターフェースへのグループ参照で整合性を取ることができます。この方法により、各サーバーインスタンスは、インターフェースグループ全体を簡単に管理できる論理名グループに対応できます。
ネットワークインターフェースは、物理インターフェースの論理名と選択基準を指定して宣言されます。アプリケーションサーバーは、管理およびパブリックインターフェース名のデフォルト設定で出荷されます。この設定では、パブリックインターフェースグループは、Web やメッセージングなどのアプリケーション関連ネットワーク通信で使用することを目的としています。管理インターフェースグループは、HTTP 管理エンドポイントを含む管理レイヤーで必要なすべてのコンポーネントとサービスに使用することを目的としています。インターフェース名自体は、推奨例としてのみ提供され、どのグループのどの名前でも必要に応じて置換または作成できます。
domain.xmlhost.xml、および standalone.xml 設定ファイルには、インターフェース宣言が含まれます。宣言基準はワイルドカードアドレスを参照したり、有効な一致となるためにインターフェースまたはアドレスで必要となる 1 つ以上の特徴を指定したりできます。次の例は、通常は standalone.xml 設定ファイルまたは host.xml 設定ファイルで定義される、インターフェース宣言の複数の設定を示しています。これにより、リモートホストグループが独自の固有インターフェース属性を維持できるようになる一方で、ドメインコントローラーの domain.xml 設定ファイルのインターフェースグループを引き続き参照できます。
最初の例は、management 相対名グループと public 相対名グループに対して指定された固有の inet-address 値を示します。

例5.1 inet-address 値で作成されたインターフェースグループ

<interfaces>
  <interface name="management">
   <inet-address value="127.0.0.1"/>
  </interface>
  <interface name="public">
   <inet-address value="127.0.0.1"/>
  </interface>
</interfaces>

次の例では、グローバルインターフェースグループが any-address 要素を使用してワイルドカードアドレスを宣言します。

例5.2 ワイルドカード宣言で作成されたグローバルグループ

<interface name="global">
   <!-- Use the wild-card address -->
   <any-address/>
</interface>

次の例では、相対グループ下のネットワークインターフェースカードを名前 external で宣言します。

例5.3 NIC 値で作成された外部グループ

        
<interface name="external">
   <nic name="eth0"/>
</interface>

次の例では、特定の要件に対して宣言がデフォルトグループとして作成されます。このインスタンスでは、追加要素の特徴によって、有効な一致となるインターフェースの条件が設定されます。これにより、特定のインターフェース宣言グループを作成でき、事前設定された方法でこれらを参照できるため、複数のサーバーインスタンス全体で設定および管理時間を短縮できます。

例5.4 特定の条件値で作成されたデフォルトグループ

<interface name="default">
   <!-- Match any interface/address on the right subnet if it's
        up, supports multicast, and isn't point-to-point -->
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

インターフェース宣言はソース設定ファイルで記述および編集できますが、管理 CLI と管理コンソールを使用すると、安全で制御された永続的な環境で設定を変更できます。

5.1.2. インターフェースの設定

standalone.xml 設定ファイルと host.xml 設定ファイルのデフォルトインターフェース設定は、それぞれの相対インターフェーストークンを持つ 3 つの名前付きインターフェースを提供します。管理コンソールまたは管理 CLI を使用して、以下の表で示されたような追加の属性と値を設定できます。また、必要に応じて、相対インターフェースバインディングを特定の値に置き換えることもできます。置き換える場合、-b スイッチは相対値のみを上書きできるため、サーバーの実行時にインターフェース値を渡すことはできません。

例5.5 デフォルトインターフェース設定

        <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="unsecure">
                <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
            </interface>
        </interfaces>

表5.1 インターフェース属性と値

インターフェース要素 説明
any 選択基準を制約するために使用されるアドレス除外タイプの空の要素。
any-address このインターフェースを使用するソケットをワイルドカードアドレスにバインドする必要があることを示す空の要素。java.net.preferIpV4Stack システムプロパティーが true に設定されていない限り、IPv6 ワイルドカードアドレス (::) が使用されます。true に設定された場合は、IPv4 ワイルドカードアドレス (0.0.0.0) が使用されます。ソケットがデュアルスタックマシンの IPv6 anylocal アドレスにバインドされた場合は、IPv6 および IPv4 トラフィックを受け取ることができます。IPv4 (IPv4 マッピング) anylocal アドレスにバインドされた場合は、IPv4 トラフィックのみを受け取ることができます。
any-ipv4-address このインターフェースを使用するソケットを IPv4 ワイルドカードアドレス (0.0.0.0) にバインドする必要があることを示す空の要素。
any-ipv6-address このインターフェースを使用するソケットを IPv6 ワイルドカードアドレス (::) にバインドする必要があることを示す空の要素。
inet-address IPv6 または IPv4 のドット区切り表記の IP アドレス、または IP アドレスに解決できるホスト名。
link-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがリンクローカルであるかどうかを示す空の要素。
loopback インターフェースの選択基準の一部として、ループバックインターフェースであるかどうかを示す空の要素。
loopback-address マシンのループバックインターフェースで実際には設定できないループバックアドレス。IP アドレスが関連付けられた NIC が見つからない場合であっても該当する値が使用されるため、inet-addressType とは異なります。
multicast インターフェースの選択基準の一部として、マルチキャストをサポートするかどうかを示す空の要素。
nic ネットワークインターフェースの名前 (eth0、eth1、lo など)。
nic-match 使用できるインターフェースを見つけるために、マシンで利用可能なネットワークインターフェースの名前を検索する正規表現。
not 選択基準を制約するために使用されるアドレス除外タイプの空の要素。
point-to-point インターフェースの選択基準の一部として、ポイントツーポイントインターフェースであるかどうかを示す空の要素。
public-address インターフェースの選択基準の一部として、公開されたルーティング可能なアドレスを持つかどうかを示す空の要素。
site-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがサイトローカルであるかどうかを示す空の要素。
subnet-match 「スラッシュ表記法」で記述されたネットワーク IP アドレスとアドレスのネットワーク接頭辞のビット数 (たとえば、192.168.0.0/16)。
up インターフェースの選択基準の一部として、現在稼動しているかどうかを示す空の要素。
virtual インターフェースの選択基準の一部として、仮想インターフェースであるかどうかを示す空の要素。
  • インターフェース属性の設定

    必要に応じて、インターフェース属性を設定するために、管理 CLI または管理コンソールを選択します。
    • 管理 CLI でのインターフェース属性の設定

      管理 CLI を使用して、新しいインターフェースを追加し、インターフェース属性に新しい値を書き込みます。
      1. 新しいインターフェースの追加

        必要な場合は、add 操作を使用して新しいインターフェースを作成します。このコマンドは、管理 CLI セッションのルートから実行できます。次の例では、新しいインターフェースの名前タイトル interfacename12.0.0.2 と宣言された inet-address とともに作成されます。
        /interface=interfacename/:add(inet-address=12.0.0.2)
      2. インターフェース属性の編集

        write 操作を使用して新しい値を属性に書き込みます。タブ補完を使用して、入力するコマンド文字列を補完したり、利用可能な属性を公開したりできます。以下の例では、inet-address 値を 12.0.0.8 に更新します。
        /interface=interfacename/:write(inet-address=12.0.0.8)
      3. インターフェース属性の編集

        include-runtime=true パラメーターを用いて read-resource 操作を実行し、値の変更を確認します。サーバーモデルでアクティブな現在の値をすべて表示します。
        [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)
    • 管理コンソールでのインターフェース属性の設定

      管理コンソールを使用して、新しいインターフェースを追加し、インターフェース属性に新しい値を書き込みます。
      1. 管理コンソールにログインします。

        管理対象ドメインまたはスタンドアロンサーバーインスタンスの管理コンソールにログインします。
      2. 管理対象ドメインを使用する場合は、適切なプロファイルを選択します。

        右上にある Profiles タブを選択し、次の画面の左上にある Profile メニューから適切なプロファイルを選択します。
      3. ナビゲーションメニューから Interfaces 項目を選択します。

        ナビゲーションメニューから Interfaces 項目を選択します。
      4. 新しいインターフェースの追加

        1. Add ボタンをクリックします。
        2. NameInet Address、および Address Wildcard に必要な値を入力します。
        3. Save をクリックして終了します。
      5. インターフェース属性の編集

        1. 編集するインターフェースを選択し Edit ボタンをクリックします。
        2. NameInet Address、および Address Wildcard に必要な値を入力します。
        3. Save をクリックして終了します。

5.2. ソケットバインディンググループ

5.2.1. ソケットバインディンググループ

ソケットバインディングとソケットバインディンググループを使用することにより、ネットワークポートと、JBoss EAP 6 の設定で必要なネットワーキングインターフェースとの関係を定義できます。
ソケットバインディングは、ソケットの名前付き設定です。これらの名前付き設定の宣言は、domain.xml 設定ファイルと standalone.xml 設定ファイルの両方にあります。設定の他のセクションは、論理名でこれらのソケットを参照できます。ソケット設定の完全な詳細を含める必要はありません。これにより、マシンによって異なる場合がある相対ソケットを参照できます。
ソケットバインディングは、ソケットバインディンググループ下に収集されます。ソケットバインディンググループは、論理名でグループ化されたソケットバインディング宣言のコレクションです。名前付きグループは、設定全体で参照できます。スタンドアロンサーバーにはこのようなグループが 1 つだけ含まれ、管理対象ドメインインスタンスには複数のグループを含めることができます。管理対象ドメインの各サーバーグループに対してソケットバインディングを作成するか、複数のサーバーグループ間でソケットバインディンググループを共有できます。
名前付きグループを使用すると、管理対象ドメインの場合に、サーバーグループを設定するときにソケットバインディングの特定のグループに、単純化された参照を使用できます。また、一般的に、1 つのシステムでのスタンドアロンサーバーの複数のインスタンスの設定と管理にも使用できます。次の例は、スタンドアロンおよびドメインインスタンスの設定ファイルのデフォルトソケットバインディンググループを示しています。

例5.6 スタンドアロン設定のデフォルトソケットバインディング

standalone.xml 設定ファイルのデフォルトソケットバインディンググループは、standard-sockets 下でグループ化されます。このグループは、同じ論理参照方法を使用して public インターフェースでも参照されます。
   
<socket-binding-group name="standard-sockets" default-interface="public">
    <socket-binding name="http" port="8080"/>
    <socket-binding name="https" port="8443"/>
    <socket-binding name="jacorb" port="3528"/>
    <socket-binding name="jacorb-ssl" port="3529"/>
    <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
    <socket-binding name="jmx-connector-server" port="1091" interface="management"/>
    <socket-binding name="jndi" port="1099"/>
    <socket-binding name="messaging" port="5445"/>
    <socket-binding name="messaging-throughput" port="5455"/>
    <socket-binding name="osgi-http" port="8090" interface="management"/>
    <socket-binding name="remoting" port="4447"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
</socket-binding-group>

例5.7 ドメイン設定のデフォルトソケットバインディング

domain.xml 設定ファイルのデフォルトソケットバインディンググループには standard-socketsha-socketsfull-sockets、および full-ha-sockets の 4 つのグループが含まれます。これらのグループは public と呼ばれるインターフェースでも参照されます。
<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="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <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 name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" port="57600"/>
        <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" port="54200"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <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="full-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jacorb" interface="unsecure" port="3528"/>
        <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <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="full-ha-sockets" default-interface="public">
        <!-- Needed for server groups using the 'full-ha' profile  -->
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jacorb" interface="unsecure" port="3528"/>
        <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
        <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
        <socket-binding name="jgroups-tcp" port="7600"/>
        <socket-binding name="jgroups-tcp-fd" port="57600"/>
        <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
        <socket-binding name="jgroups-udp-fd" port="54200"/>
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" multicast-port="23364"/>
        <socket-binding name="osgi-http" interface="management" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <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-groups>
ソケットバインディングインスタンスは、アプリケーションサーバーディレクトリーの standalone.xml ソースファイルと domain.xml ソースファイルで作成および編集できます。バインディングの管理には、管理コンソールまたは管理 CLI を使用することが推奨されます。管理コンソールを使用すると、General Configuration セクション下に専用の Socket Binding Group 画面があるグラフィカルユーザーインターフェースが使用できるなどの利点があります。管理 CLI は、アプリケーションサーバー設定の上位および下位レベル全体でバッチ処理やスクリプトの使用を可能にする、コマンドラインを基にした AIP およびワークフローを提供します。両方のインターフェースにより、変更を永続化したり、サーバー設定に保存したりできます。

5.2.2. ソケットバインディングの設定

ソケットバインディングは固有のソケットバインディンググループに定義できます。スタンドアロンサーバーにはこのようなグループの 1 つである standard-sockets が含まれ、この他のグループを作成することはできません。この他のグループを作成するには、別のスタンドアロンサーバー設定ファイルを作成します。管理対象ドメインでは複数のソケットバインディンググループを作成することが可能で、必要に応じて含まれるソケットバインディングを設定できます。下表は各ソケットバインディングに使用できる属性を表しています。

表5.2 ソケットバインディングの属性

コンポーネント 説明 ロール
名前 設定の他の場所で使用する必要があるソケット設定の論理名。 必須
ポート この設定に基づいたソケットをバインドする必要がある基本ポート。すべてのポートの値をインクリメントまたはデクリメントすることにより、サーバーがこの基本値を上書きするよう設定できることに注意してください。 必須
インターフェース この設定に基づいたソケットをバインドする必要があるインターフェースの論理名。定義されない場合は、囲んでいるソケットバインディンググループから「default-interface」属性の値が使用されます。 オプション
複数のアドレス マルチキャストにソケットが使用される場合は、使用するマルチキャストアドレス。 オプション
マルチキャストポート 会話のライフサイクルにバインドされます。会話スコープは、要求の長さとセッション長さの間にあり、アプリケーションによって制御されます。 オプション
固定ポート 上記のコンテキストでニーズが満たされない場合は、カスタムスコープを定義できます。 オプション
  • ソケットバインディンググループのソケットバインディングの設定

    管理 CLI または管理コンソールを選択して、必要に応じてソケットバインディングを設定します。
    • 管理 CLI を使用したソケットバインディングの設定

      管理 CLI を使用してソケットバインディングを設定します。
      1. 新しいソケットバインディングの追加

        add 操作を使用して、必要な場合に新しいアドレス設定を作成します。このコマンドは、管理 CLI セッションのルートから実行できます。この場合、以下の例では、newsocket という新しいソケットバインディングが作成され、port 属性が 1234 として宣言されます。以下の例は、standard-sockets ソケットバインディンググループ上で編集を行うスタンドアロンサーバーおよび管理対象ドメインの両方に適用されます。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)
      2. パターン属性の編集

        write-attribute 操作を使用して新しい値を属性に書き込みます。タブ補完を使用して、入力するコマンド文字列を補完したり、利用可能な属性を公開したりできます。以下の例では、port 値を 2020 に更新します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)
      3. パターン属性の確認

        read-resource 操作で include-runtime=true パラメーターを実行して値を変更し、サーバーモデルでアクティブな現在のすべての値を公開します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource
    • 管理コンソールを使用したソケットバインディングの設定

      管理コンソールを使用してソケットバインディングを設定します。
      1. 管理コンソールにログインします。

        管理対象ドメインまたはスタンドアロンサーバーの管理コンソールにログインします。
      2. Profile tab の選択

        右上の Profiles タブを選択します。
      3. ナビゲーションメニューより Socket Binding を選択

        ナビゲーションメニューから Socket Binding メニュー項目を選択します。管理対象ドメインを使用している場合は Socket Binding Groups メニューから希望のグループを選択します。
      4. 新しいソケットバインディングの追加

        1. Add ボタンをクリックします。
        2. NamePort、および Binding Group に必要な値を入力します。
        3. Save をクリックして終了します。
      5. インターフェース属性の編集

        1. 編集するソケットバインディングを選択し、Edit ボタンをクリックします。
        2. NameInterface、または Port など、必要な値を入力します。
        3. Save をクリックして終了します。

5.2.3. JBoss EAP 6 により使用されるネットワークポート

JBoss EAP 6 のデフォルト設定で使用されるポートは、次の複数の要因によって異なります。
  • サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
  • 個別デプロイメントの要件。

注記

数値ポートオフセットは、同じ物理サーバーで複数のサーバーを実行する場合にポートの競合を緩和するために設定できます。サーバーが数値ポートオフセットを使用する場合は、サーバーグループのソケットバインディンググループに対するオフセットをデフォルトのポート番号に追加します。たとえば、ソケットバインディンググループの HTTP ポートは 8080 であり、サーバーは 100 のポートオフセットを使用し、その HTTP ポートは 8180 です。
特に指定がない限り、ポートは TCP プロトコルを使用します。

デフォルトのソケットバインディンググループ

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

表5.3 デフォルトのソケットバインディングの参照

名前 ポート マルチキャストポート 説明 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。
http 8080 デプロイされた Web アプリケーションのデフォルトポート。
https 8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。
jacorb 3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 × ×
jacorb-ssl 3529 SSL 暗号化 CORBA サービス。 × ×
jgroups-diagnostics 7500 マルチキャスト。HA クラスターでのピアの検出に使用されます。管理インターフェースを使用しても設定できません。 × ×
jgroups-mping 45700 マルチキャスト。HA クラスターでの初期メンバーシップの検出に使用されます。 × ×
jgroups-tcp 7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。 × ×
jgroups-tcp-fd 57600 TCP を介した HA 障害検出に使用されます。 × ×
jgroups-udp 55200 45688 UDP を使用した、HA クラスター内でのユニキャストピア検出。 × ×
jgroups-udp-fd 54200 UDP を介した HA 障害検出に使用されます。 × ×
messaging 5445 JMS サービス。 × ×
messaging-group HornetQ JMS ブロードキャストと検出グループにより参照されます。 × ×
messaging-throughput 5455 JMS Remoting により使用されます。 × ×
mod_cluster 23364 JBoss EAP 6 と HTTP ロードバランサー間の通信に対するマルチキャストポート。 × ×
osgi-http 8090 OSGi サブシステムを使用する内部コンポーネントにより使用されます。管理インターフェースを使用して設定できません。
remoting 4447 リモート EJB の呼び出しに使用されます。
txn-recovery-environment 4712 JTA トランザクションリカバリーマネージャー。
txn-status-manager 4713 JTA / JTS トランザクションマネージャー。
管理ポート

ソケットバインディンググループの他に、各ホストコントローラーによって 2 つのポートが管理目的で開かれます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API により使用されるポート

5.2.4. ソケットバインディンググループのポートオフセット

ポートオフセットは、該当するサーバーのソケットバインディンググループにより提供されるポート値に追加される数値オフセットです。これにより、単一のサーバーが属するサーバーグループのソケットバインディングを継承します (グループ内の他のサーバーと競合しないようオフセットを使用)。たとえば、ソケットバインディンググループの HTTP ポートが 8080 であり、サーバが 100 のポートオフセットを使用する場合、その HTTP ポートは 8180 です。

5.2.5. ポートオフセットの設定

  • ポートオフセットの設定

    管理 CLI または管理コンソールを選択してポートオフセットを設定します。
    • 管理 CLI を使用したポートオフセットの設定

      管理 CLI を使用してポートオフセットを設定します。
      1. ポートオフセットの編集

        write-attribute 操作を使用して新しい値をポートオフセット属性に書き込みます。次の例は、server-twosocket-binding-port-offset 値を 250 に更新します。このサーバーはデフォルトローカルホストグループのメンバーです。変更を有効にするには再起動が必要となります。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
      2. ポートオフセット属性の確認

        read-resource 操作で include-runtime=true パラメーターを実行して値を変更し、サーバーモデルでアクティブな現在のすべての値を公開します。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)
    • 管理コンソールを使用したポートオフセットの設定

      管理コンソールを使用してポートオフセットを設定します。
      1. 管理コンソールにログインします。

        管理対象ドメインの管理コンソールにログインします。
      2. Hosts タブの選択

        右上の Hosts タブを選択します。
      3. ポートオフセット属性の編集

        1. Configuration Name セクションでサーバーを選択し、Edit ボタンをクリックします。
        2. Port Offset フィールドで必要な値を入力します。
        3. Save ボタンをクリックして終了します。

5.3. IPv6

5.3.1. IPv6 ネットワーキング向け JVM スタック設定の指定

概要
このトピックでは、JBoss EAP 6 インストールでの IPv6 ネットワーキングの有効化について説明します。

手順5.1 IPv4 Stack Java プロパティーの無効化

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      EAP_HOME/bin/standalone.conf を開きます。
    • 管理対象ドメインの場合:

      EAP_HOME/bin/domain.conf を開きます。
  2. IPv4 Stack Java プロパティーを false に変更します。
    -Djava.net.preferIPv4Stack=false
    例:
    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

5.3.2. IPv6 ネットワークに対するインターフェース宣言の設定

概要

次の手順に従って、インターフェース inet アドレスを IPv6 のデフォルトに設定します。

手順5.2 IPv6 ネットワーキングのインターフェースの設定

  1. コンソールの右上にある Profile タブを選択します。
  2. General ConfigurationInterfaces オプションを選択します。
  3. 設定する名前付きネットワークインターフェースを選択します。
  4. Edit ボタンをクリックします。
  5. 下記の inet アドレスを設定します。
    ${jboss.bind.address.management:[ADDRESS]}
  6. Save ボタンをクリックして変更を保存します。
  7. サーバーを再起動し、変更を実装します。

5.3.3. IPv6 アドレス用 JVM スタック設定の指定

概要
このトピックでは、JBoss EAP 6 インストールで IPv6 アドレスを優先するよう設定ファイルで設定する方法について説明します。

手順5.3 IPv6 アドレスを優先するよう JBoss EAP 6 インストールを設定する

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      EAP_HOME/bin/standalone.conf を開きます。
    • 管理対象ドメインの場合:

      EAP_HOME/bin/domain.conf を開きます。
  2. 以下の Java プロパティーを Java VM オプションに追加します。
    -Djava.net.preferIPv6Addresses=true
    例:
    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    

第6章 データソース管理

6.1. はじめに

6.1.1. JDBC

JDBC API は、Java アプリケーションがデータベースにアクセスする方法を定義する基準です。アプリケーションは JDBC ドライバーを参照するデータソースを設定します。その後、データベースではなくドライバーに対してアプリケーションを記述できます。ドライバーはコードをデータベース言語に変換します。そのため、適切なドライバーがインストールされていればアプリケーションをサポートされるデータベースで使用できます。
JDBC 4.0 の仕様は、次のサイトで定義されています: http://jcp.org/en/jsr/detail?id=221
JDBC とデータソースの使用を開始するにあたっては、JBoss EAP 6 の管理設定ガイドの JDBC ドライバーのセクションを参照してください。

6.1.2. JBoss EAP 6 でサポートされるデータベース

JBoss EAP 6 でサポートされる JDBC 準拠のデーターベースの一覧は https://access.redhat.com/site/articles/111663 を参照してください。

6.1.3. データソースの型

一般的なリソースタイプには、datasourcesXA datasources の 2 つがあります。
非 XA データソースは、トランザクションを使用しないアプリケーション、または単一のデータベースでトランザクションを使用するアプリケーションに使用されます。
XA データソースは、トランザクションが複数のデータベースにわたって分散されるアプリケーションによって使用されます。
管理コンソールあるいは管理 CLI でデータソースを作成するときに、データソースの型を指定します。

6.1.4. データソースの例

JBoss EAP 6 には H2 データベースが含まれています。これは、軽量な関係データベース管理システムであり、開発者がアプリケーションを迅速に構築できるようにします。また、このプラットフォームのデータソースの例になります。

警告

本番稼働環境では使用しないでください。これは、アプリケーションをテストおよび構築するために必要なすべての標準をサポートする非常に小さい自己完結型のデータソースであり、本番稼働用として堅牢またはスケーラブルではありません。
サポートおよび認定済みのデータソースの一覧は、「JBoss EAP 6 でサポートされるデータベース」を参照してください。

6.1.5. -ds.xml ファイルのデプロイメント

JBoss EAP 6 では、データソースはサーバーサブシステムのリソースとして定義されます。以前のバージョンでは、サーバー設定のデプロイメントディレクトリーに *-ds.xml データソース設定ファイルが必要でした。*-ds.xml ファイルを JBoss EAP 6 にデプロイするには、http://www.ironjacamar.org/documentation.html の「Schemas」下にある Data sources の 1.1 にしたがいます。

警告

この機能は開発目的でのみ使用するようにしてください。JBoss の管理ツールではサポートされないため、本番環境での使用は推奨されません。

重要

*-ds.xml ファイルをデプロイする場合、すでにデプロイまたは定義されている <driver> エントリーへの参照を使用しなければなりません。

6.2. JDBC ドライバー

6.2.1. 管理コンソールを用いた JDBC ドライバーのインストール

概要

アプリケーションが JDBC データソースに接続する前に、データソースベンダーの JDBC ドライバーを JBoss EAP 6 が使用できる場所にインストールする必要があります。JBoss EAP 6 では、これらのドライバーを他のデプロイメントと同じようにデプロイできます。そのため、管理対象ドメインを使用する場合は、サーバーグループ内の複数のサーバー全体でドライバーをデプロイできます。

注記

起動サーバーが適切に挙動するようにするため、JDBC ドライバーをコアモジュールとしてインストールする方法が推奨されます。JDBC ドライバーをコアモジュールとしてインストールするには、「コアモジュールとしての JDBC ドライバーのインストール」を参照してください。
前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

  • データベースのベンダーから JDBC ドライバーをダウンロードする必要があります。

手順6.1 JDBC ドライバーのデプロイ

  1. 管理コンソールへアクセスします。

  2. JAR ファイルをサーバーあるいはサーバーグループにデプロイします。

    管理対象ドメインを使用する場合は、JAR ファイルをサーバーグループにデプロイします。使用しない場合はサーバーにデプロイします。「管理コンソールを使用したアプリケーションのデプロイ」を参照してください。
結果

JDBC ドライバーがデプロイされ、アプリケーションが使用できるようになります。

6.2.2. コアモジュールとしての JDBC ドライバーのインストール

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

手順6.2 コアモジュールとしての JDBC ドライバーのインストール

  1. EAP_HOME/modules/ ディレクトリー下にファイルパス構造を作成します。たとえば、MySQL JDBC ドライバーの場合には、EAP_HOME/modules/com/mysql/main/ のようなディレクトリー構造を作成します。
  2. JDBC ドライバー JAR を main/ サブディレクトリーにコピーします。
  3. main/ サブディレクトリーで、「モジュール」の例に似た module.xml ファイルを作成します。module XSD は EAP_HOME/docs/schema/module-1_2.xsd ファイルに定義されます。
  4. サーバーを起動します。
  5. 管理 CLI を起動します。
  6. 次の CLI コマンドを実行して、JDBC ドライバーモジュールをドライバーとして追加します。
    /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)

    例6.1 CLI コマンドの例

    /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
結果

JDBC ドライバーがインストールされ、コアモジュールとして設定されます。アプリケーションのデータソースが JDBC ドライバーを参照できる状態になります。

6.2.3. JDBC ドライバーをダウンロードできる場所

下表は、JBoss EAP 6 と使用する一般的なデータベースの JDBC ドライバーをダウンロードする場所を示しています。これらのリンク先は、Red Hat が管理しない他企業の Web サイトであるため、Red Hat は頻繁に確認していません。データベースの最新のドライバーについては、データベースのベンダーのドキュメントや Web サイトを確認してください。

6.2.4. ベンダー固有クラスへのアクセス

概要

このトピックでは、JDBC 固有クラスを使用するのに必要な手順について説明します。これは、アプリケーションが JDBC API の一部でないベンダー固有の機能を使用する必要がある場合に必要です。

警告

これは、高度な手順であり、JDBC API に含まれない機能を必要とするアプリケーションのみこれを実装します。

重要

このプロセスは、再認証メカニズムを使用し、ベンダー固有のクラスにアクセスする場合に必要です。

重要

接続は IronJacamar コンテナによって制御されるため、ベンダー固有の API ガイドラインに厳密に従ってください。

手順6.3 アプリケーションへの依存関係の追加

    • MANIFEST.MF ファイルの設定

      1. テキストエディターでアプリケーションの META-INF/MANIFEST.MF ファイルを開きます。
      2. JDBC モジュールの依存関係を追加し、ファイルを保存します。
        依存関係: MODULE_NAME

        例6.2 依存関係の例

        依存関係: com.mysql
      1. jboss-deployment-structure.xml ファイルの作成

        アプリケーションの META-INF/ または WEB-INF フォルダーで jboss-deployment-structure.xml という名前のファイルを作成します。

        例6.3 サンプル jboss-deployment-structure.xml ファイル

        <jboss-deployment-structure>
          <deployment>
            <dependencies>
              <module name="com.mysql" />
            </dependencies>
          </deployment>
        </jboss-deployment-structure>
        

例6.4 ベンダー固有 API へのアクセス

以下のサンプルは MySQL API にアクセスします。
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();

6.3. 非 XA データソース

6.3.1. 管理インターフェースによる非 XA データソースの作成

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを作成する手順について取り上げます。

要件

  • JBoss EAP 6 サーバーが稼働している必要があります。

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが必要ではなくなりました。

手順6.4 管理 CLI または管理コンソールのいずれかを使用したデータソースの作成

    • 管理 CLI

      1. CLI ツールを起動し、サーバーに接続します。
      2. 以下のコマンドを実行して非 XA データソースを作成し、適切に変数を設定します。
        data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
      3. データソースを有効にします。
        data-source enable --name=DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールへログインします。
      2. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの上部より Profile を選択します。
          • ドメインモード

            1. コンソールの上部より Profiles を選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
      3. 新しいデータソースの作成

        1. Datasources パネル上部にある Add ボタンを選択します。
        2. Create Datasource ウィザードで新しいデータソースの属性を入力し、Next ボタンを押します。
        3. Create Datasource ウィザードで JDBC ドライバーの詳細を入力し、Next ボタンを押します。
        4. Create Datasource ウィザードで接続設定を入力し、Done ボタンを押します。
結果

非 XA データソースがサーバーに追加されます。standalone.xml または domain.xml ファイル、および管理インターフェースで追加を確認することができます。

6.3.2. 管理インターフェースによる非 XA データソースの編集

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを編集する手順について取り上げます。

注記

非 XA データソースは JTA トランザクションと統合できます。データソースを JTA と統合する場合、必ず jta パラメーターを true に設定してください。

手順6.5 非 XA データソースの編集

    • 管理 CLI

      1. write-attribute コマンドを使用してデータソース属性を設定します。
        /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
      2. サーバーを再ロードして変更を確認します。
        :reload
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの上部より Profile を選択します。
          • ドメインモード

            1. コンソールの上部より Profiles を選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
      2. データソースの編集

        1. Available Datasources リストより関連する データソースを選択します。下にある Attributes パネルにデータソースの属性が表示されます。
        2. Edit ボタンを選択してデータソース属性を編集します。
        3. データソース属性を編集し、作業が終了したら、Save ボタンを選択します。
結果

非 XA データソースが設定されます。変更は standalone.xml または domain.xml ファイルのどちらかと、管理インターフェースで確認できます。

6.3.3. 管理インターフェースによる非 XA データソースの削除

概要

ここでは、管理コンソールまたは管理 CLI を使用して、JBoss EAP 6 より非 XA データソースを削除するために必要な手順について説明します。

手順6.6 非 XA データソースの削除

    • 管理 CLI

      1. 次のコマンドを実行して非 XA データソースを削除します。
        data-source remove --name=DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの上部より Profile を選択します。
          • ドメインモード

            1. コンソールの上部より Profiles を選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
      2. 削除する登録済みのデータソースを選択し、コンソールの右上隅にある Remove ボタンをクリックします。
結果

非 XA データソースがサーバーより削除されます。

6.4. XA データソース

6.4.1. 管理インターフェースによる XA データソースの作成

必読トピック:

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して XA データソースを作成する手順について取り上げます。

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが必要ではなくなりました。

手順6.7 管理 CLI または管理コンソールのいずれかを使用した XA データソースの作成

    • 管理 CLI

      1. 以下のコマンドを実行して XA データソースを作成し、適切に変数を設定します。
        xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS
      2. XA データソースプロパティーの設定

        1. サーバー名の設定

          次のコマンドを実行し、ホストのサーバー名を設定します。
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)
        2. データベース名の設定

          次のコマンドを実行し、データベース名を設定します。
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
      3. データソースを有効にします。
        xa-data-source enable --name=XA_DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの上部より Profile タブ を選択します。
          • ドメインモード

            1. コンソールの上部より Profiles タブ を選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
      2. XA Datasource タブを選択します。
      3. 新しい XA データソースの作成

        1. XA Datasource パネルの上にある Add ボタンを選択します。
        2. Create XA Datasource ウィザードに新しい XA データソースの属性を入力し、Next ボタンを押します。
        3. Create XA Datasource ウィザードに JDBC ドライバーの詳細を入力し、Next ボタンを押します。
        4. XA プロパティーを編集し、Next ボタンを押します。
        5. Create XA Datasource ウィザードに接続設定を入力し、Done ボタンを押します。
結果

XA データソースがサーバーに追加されます。追加内容は standalone.xml または domain.xml ファイルのどちらかと、管理インターフェースで確認することができます。

6.4.2. 管理インターフェースによる XA データソースの編集

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して XA データソースを編集する手順について取り上げます。

手順6.8 管理 CLI または管理コンソールのいずれかを使用した XA データソースの編集

    • 管理 CLI

      1. XA データソース属性の設定

        write-attribute コマンドを使用してデータソース属性を設定します。
        /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
      2. XA データソースプロパティーの設定

        次のコマンドを実行して XA データソースサブリソースを設定します。
        /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      3. サーバーを再ロードして変更を確認します。
        :reload
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの上部より Profile タブ を選択します。
          • ドメインモード

            1. コンソールの上部より Profiles タブ を選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
      2. XA Datasource タブを選択します。
      3. データソースの編集

        1. Available XA Datasources リストより関連する XA データソースを選択します。下にある Attributes パネルに XA データソースの属性が表示されます。
        2. Edit ボタンを選択してデータソース属性を編集します。
        3. XA データソースの属性を編集し、終わったら Save ボタンを選択します。
結果

XA データソースが設定されます。変更は standalone.xml または domain.xml ファイルのどちらかと、管理インターフェースで確認できます。

6.4.3. 管理インターフェースによる XA データソースの削除

概要

ここでは、管理コンソールまたは管理 CLI を使用して、JBoss EAP 6 より XA データソースを削除するために必要な手順について説明します。

手順6.9 管理 CLI または管理コンソールのいずれかを使用した XA データソースの削除

    • 管理 CLI

      1. 次のコマンドを実行して XA データソースを削除します。
        xa-data-source remove --name=XA_DATASOURCE_NAME
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

          • スタンドアロンモード

            コンソールの上部より Profile タブ を選択します。
          • ドメインモード

            1. コンソールの上部より Profiles タブ を選択します。
            2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
            3. コンソールの左側にある Subsystems メニューを展開します。
        1. コンソールの左側にあるメニューより ConnectorDatasources と選択します。
      2. XA Datasource タブを選択します。
      3. 削除する登録済みの XA データソースを選択し、コンソールの右上隅にある Remove ボタンをクリックします。
結果

XA データソースがサーバーより削除されます。

6.4.4. XA リカバリー

6.4.4.1. XA リカバリーモジュール

各 XA リソースは、設定が関連付けられたリカバリーモジュールを必要とします。リカバリーモジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
JBoss EAP 6 は、JDBC および JMS XA リソースのリカバリーモジュールを提供します。このようなタイプのリソースでは、リカバリーモジュールは自動的に登録されます。カスタムモジュールを使用する必要がある場合は、データベースに登録できます。

6.4.4.2. XA リカバリーモジュールの設定

ほとんどの JDBC および JMS リソースでは、リカバリーモジュールがリソースに自動的に関連付けられます。この場合は、リカバリーモジュールがリソースに接続して復元を実行することを許可するオプションのみを設定する必要があります。
JDBC または JMS でないカスタムリソースの場合は、サポートされる設定について Red Hat グローバルサポートサービスにお問い合わせください。
これらの各設定属性は、データソースの作成時または作成後に設定できます。設定属性は、Web ベースの管理コンソールまたはコマンドライン管理 CLI を使用して設定できます。XA データソースの設定の一般情報については、「管理インターフェースによる XA データソースの作成」「管理インターフェースによる XA データソースの編集」を参照してください。
一般的なデータソース設定属性と、特定のデータベースベンダーに関連する設定詳細については、以下の表を参照してください。

表6.2 一般的な設定属性

属性 説明
recovery-username
リソースに接続してリカバリー行うためにリカバリーモジュールが使用する必要があるユーザー名。
recovery-password
リソースに接続してリカバリーを行うためにリカバリーモジュールが使用する必要があるパスワード。
recovery-security-domain
リソースに接続して復元を行うためにリカバリーモジュールが使用する必要があるセキュリティードメイン。
recovery-plugin-class-name
カスタムのリカバリーモジュールを使用する必要がある場合は、この属性をモジュールの完全修飾クラス名に設定します。モジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
recovery-plugin-properties
プロパティーを設定する必要があるカスタムのリカバリーモジュールを使用する場合は、この属性をプロパティーに対するカンマ区切りの key=value ペアのリストに設定します。

ベンダー固有の設定情報

Oracle
Oracle データソースが不適切に設定された場合は、ログ出力に次のようなエラーが示されることがあります。
WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
このエラーを解決するには、recovery-username で設定された Oracle ユーザーがリカバリーに必要なテーブルにアクセスできる必要があります。以下の SQL ステートメントは、Oracle バグ 5945463 用のパッチが適用された Oracle 11g または Oracle 10g R2 インスタンスに対する適切なステートメントです。
GRANT SELECT ON sys.dba_pending_transactions TO recovery-username;
GRANT SELECT ON sys.pending_trans$ TO recovery-username;
GRANT SELECT ON sys.dba_2pc_pending TO recovery-username;
GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
11g よりも前の Oracle 11 バージョンを使用する場合は、最後の EXECUTE ステートメントを以下のように変更します。
	GRANT EXECUTE ON sys.dbms_system TO recovery-username;
PostgreSQL
準備された (つまり、XA) トランザクションを有効にする手順については、PostgreSQL ドキュメンテーションを参照してください。PostgreSQL の JDBC ドライバーのバージョン 8.4-701 では、org.postgresql.xa.PGXAConnection にバグがあり、特定の状況でリカバリーが中断されます。このバグは新しいバージョンで修正されています。
MySQL
http://bugs.mysql.com/bug.php?id=12161 に基づき、XA トランザクションのリカバリーは一部の MySQL 5 バージョンでは動作しませんでした。この問題は MySQL 6.1 で修正されました。詳細については、バグの URL または MySQL ドキュメンテーションを参照してください。
IBM DB2
IBM DB2 では、クラッシュまたは障害の発生後にアプリケーションサーバーが再起動すると発生する、指定の再同期ステージの間でのみ XAResource.recover メソッドが呼び出されることを想定します。これは、DB2 実装の設計に関する決まりであり、本書の範囲外となります。

6.5. データソースセキュリティー

6.5.1. データソースセキュリティー

データソースセキュリティーのソリューションには、セキュリティードメインまたはパスワード vault のいずれかを使用することが推奨されます。以下にそれぞれの例を示します。詳細については、以下のドキュメントを参照してください。

例6.5 セキュリティードメインの例

<security>
   <security-domain>mySecurityDomain</security-domain>
</security>

例6.6 パスワード vault の例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>

6.6. データソース設定

6.6.1. データソースのパラメーター

表6.3 非 XA および XA データソースに共通のデータソースパラメーター

パラメーター 説明
jndi-name データソースの一意の JNDI 名。
pool-name データソースの管理プール名。
enabled データソースが有効かどうか。
use-java-context
データソースをグローバルの JNDI にバインドするかどうか。
spy
JDBC レイヤーで spy 機能を有効にします。この機能は、データソースへの JDBC トラフィックをすべてログに記録します。また、logging-category パラメーターを org.jboss.jdbc に設定する必要があります。
use-ccm キャッシュ接続マネージャーを有効にします。
new-connection-sql 接続プールに接続が追加された時に実行する SQL ステートメント。
transaction-isolation
次のいずれかになります。
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-delimiter 高可用性 (HA) クラスターデータベースの connection-url にある URL の区切り文字。 
url-selector-strategy-class-name インターフェース org.jboss.jca.adapters.jdbc.URLSelectorStrategy を実装するクラス。
security
セキュリティー設定である子要素が含まれます。表6.8「セキュリティーパラメーター」 を参照してください。
validation
検証設定である子要素が含まれます。表6.9「検証パラメーター」 を参照してください。
timeout
タイムアウト設定である子要素が含まれます。表6.10「タイムアウトパラメーター」 を参照してください。
statement
ステートメント設定である子要素が含まれます。表6.11「ステートメントのパラメーター」 を参照してください。

表6.4 非 XA データソースのパラメーター

パラメーター 説明
jta 非 XA データソースの JTA 統合を有効にします。XA データソースには適用されません。
connection-url JDBC ドライバーの接続 URL。
driver-class JDBC ドライバークラスの完全修飾名。
connection-property
Driver.connect(url,props) メソッドに渡される任意の接続プロパティー。各 connection-property は、文字列名と値のペアを指定します。プロパティー名は名前、値は要素の内容に基づいています。
pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」 を参照してください。

表6.5 XA データソースのパラメーター

パラメーター 説明
xa-datasource-property
実装クラス XADataSource に割り当てるプロパティー。name=value で指定。 setName という形式で setter メソッドが存在する場合、プロパティーは setName(value) という形式の setter メソッドを呼び出すことで設定されます。
xa-datasource-class
実装クラス javax.sql.XADataSource の完全修飾名。
driver
JDBC ドライバーが含まれるクラスローダーモジュールへの一意参照。driverName#majorVersion.minorVersion の形式にのみ対応しています。
xa-pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」 および 表6.7「XA プールパラメーター」 を参照してください。
recovery
リカバリー設定である子要素が含まれます。表6.12「リカバリーパラメーター」 を参照してください。

表6.6 非 XA および XA データソースに共通のプールパラメーター

パラメーター 説明
min-pool-size プールが保持する最小接続数
max-pool-size プールが保持可能な最大接続数
prefill 接続プールのプレフィルを試行するかどうか。要素が空の場合は true を示します。デフォルトは、false です。
use-strict-min pool-size が厳密かどうか。デフォルトは false に設定されています。
flush-strategy
エラーの場合にプールがフラッシュされるかどうか。有効な値は次のとおりです。
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
デフォルトは FailingConnectionOnly です。
allow-multiple-users 複数のユーザーが getConnection(user, password) メソッドを介してデータソースにアクセスするかどうかを指定します。また、この動作が内部プールタイプによるものかどうかを指定します。

表6.7 XA プールパラメーター

パラメーター 説明
is-same-rm-override javax.transaction.xa.XAResource.isSameRM(XAResource) クラスが true あるいは false のどちらを返すか。
interleaving XA 接続ファクトリーのインターリービングを有効にするかどうか。
no-tx-separate-pools コンテキスト毎に sub-pool を作成するかどうか。これには Oracle のデータソースが必要ですが、JTA トランザクションの内部と外部の両方で XA 接続が使用できなくなります。
pad-xid Xid のパディングを行うかどうか
wrap-xa-resource
XAResource を org.jboss.tm.XAResourceWrapper インスタンスでラップするかどうか。

表6.8 セキュリティーパラメーター

パラメーター 説明
user-name 新規接続の作成に使うユーザー名
password 新規接続の作成に使うパスワード
security-domain 認証処理を行う JAAS security-manager 名が入ります。この名前は、JAAS ログイン設定のapplication-policy/name 属性を相関します。
reauth-plugin 物理接続の再認証に使う再認証プラグインを定義します。

表6.9 検証パラメーター

パラメーター 説明
valid-connection-checker
SQLException.isValidConnection(Connection e) メソッドを提供し接続を検証する インターフェース org.jboss.jca.adaptors.jdbc.ValidConnectionChecker の実装。例外が発生すると接続が破棄されます。存在する場合、check-valid-connection-sql パラメーターが上書きされます。
check-valid-connection-sql プール接続の妥当性を確認する SQL ステートメント。これは、管理接続をプールから取得し利用する場合に呼び出される場合があります。
validate-on-match
接続ファクトリーが指定のセットに対して管理された接続をマッチしようとした時に接続レベルの検証を実行するかどうかを示します。
通常、validate-on-match に true を指定した時に background-validation を true に指定することはありません。クライアントが使用する前に接続を検証する必要がある場合に Validate-on-match が必要になります。このパラメーターはデフォルトでは true になっています。
background-validation
接続がバックグラウンドスレッドで検証されることを指定します。validate-on-match を使用しない場合、バックグラウンドの検証はパフォーマンスを最適化します。validate-on-match が true の時に background-validation を使用すると、チェックが冗長になることがあります。バックグラウンド検証では、不良の接続がクライアントに提供される可能性があります (検証スキャンと接続がクライアントに提供されるまでの間に接続が悪くなります)。そのため、クライアントアプリケーションはこの接続不良の可能性に対応する必要があります。
background-validation-millis バックグラウンド検証を実行する期間 (ミリ秒単位)。
use-fast-fail
true の場合、接続が無効であれば最初に接続を割り当てしようとした時点で失敗します。デフォルトは false です。
stale-connection-checker
ブール値の isStaleConnection(SQLException e) メソッドを提供する org.jboss.jca.adapters.jdbc.StaleConnectionChecker のインスタンス。このメソッドが true を返すと、SQLException のサブクラスである org.jboss.jca.adapters.jdbc.StaleConnectionException に例外がラップされます。
exception-sorter
ブール値である isExceptionFatal(SQLException e) メソッドを提供する org.jboss.jca.adapters.jdbc.ExceptionSorter のインスタンス。このメソッドは、例外が connectionErrorOccurred メッセージとして javax.resource.spi.ConnectionEventListener のすべてのインスタンスへブロードキャストされるかどうかを検証します。

表6.10 タイムアウトパラメーター

パラメーター 説明
use-try-lock lock() の代わりに tryLock() を使用します。これは、ロックが使用できない場合に即座に失敗するのではなく、設定された秒数間ロックの取得を試みます。デフォルトは 60 秒です。たとえば、タイムアウトを 5 分に設定するには、<use-try-lock>300</use-try-lock> を設定します。
blocking-timeout-millis 接続待機中にブロックする最大時間 (ミリ秒)。この時間を超過すると、例外がスローされます。これは、接続許可の待機中のみブロックし、新規接続の作成に長時間要している場合は例外をスローしません。デフォルトは 30000 (30 秒) です。
idle-timeout-minutes
アイドル接続が切断されるまでの最大時間 (分単位)。実際の最大時間は idleRemover のスキャン時間によって異なります。idleRemover のスキャン時間はプールの最小 idle-timeout-minutes の半分になります。
set-tx-query-timeout
トランザクションがタイムアウトするまでの残り時間を基にクエリーのタイムアウトを設定するかどうか。トランザクションが存在しない場合は設定済みのクエリーのタイムアウトが使用されます。デフォルトは false です。
query-timeout クエリーのタイムアウト (秒)。デフォルトはタイムアウトなしです。
allocation-retry 例外をスローする前に接続の割り当てを再試行する回数。デフォルトは 0 で、初回の割り当て失敗で例外がスローされます。
allocation-retry-wait-millis
接続の割り当てを再試行するまで待機する期間 (ミリ秒単位)。デフォルトは 5000 (5 秒) です。
xa-resource-timeout
ゼロでない場合、この値は XAResource.setTransactionTimeout メソッドへ渡されます。

表6.11 ステートメントのパラメーター

パラメーター 説明
track-statements
接続がプールへ返され、ステートメントが準備済みステートメントキャッシュへ返された時に、閉じられていないステートメントをチェックするかどうか。false の場合、ステートメントは追跡されません。

有効な値

  • true: ステートメントと結果セットが追跡され、ステートメントが閉じられていない場合は警告が出力されます。
  • false: ステートメントと結果セットのいずれも追跡されません。
  • nowarn: ステートメントは追跡されますが、警告は出力されません。これがデフォルト設定となっています。
prepared-statement-cache-size LRU (Least Recently Used) キャッシュにある接続毎の準備済みステートメントの数。
share-prepared-statements
閉じずに同じステートメントを 2 回要求した場合に、同じ基盤の準備済みステートメントを使用するかどうか。デフォルトは false です。

表6.12 リカバリーパラメーター

パラメーター 説明
recover-credential リカバリーに使用するユーザー名とパスワードのペア、あるいはセキュリティドメイン。
recover-plugin
リカバリーに使用される org.jboss.jca.core.spi.recoveryRecoveryPlugin クラスの実装。

6.6.2. データソース接続 URL

表6.13

データソース 接続 URL
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME

6.6.3. データソースの拡張

データソースのデプロイメントは、JDBC リソースアダプターにある複数の拡張を使用して接続の検証を改善でき、例外が接続を再確立するべきかどうかを確認できます。これらの拡張は次のとおりです。

表6.14 データソースの拡張

データソースの拡張 設定パラメーター 説明
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> SQLException が発生した接続にとってこの例外は致命的かどうかを確認します。
org.jboss.jca.adapters.jdbc.spi.StaleConnection <stale-connection-checker> org.jboss.jca.adapters.jdbc.StaleConnectionException の陳腐 SQLExceptions をラップします。
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> アプリケーションによる接続の使用が有効であるかどうかを確認します。
JBoss EAP 6 は、これらの拡張の実装を、サポートされるデータベースに提供します。

拡張の実装

汎用
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.6.4. データソース統計の表示

以下のコマンドを適切に編集すると、jdbc および pool の定義済みデータソースより統計を表示できます。

手順6.10

  • /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:read-resource(include-runtime=true)
    
    /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
    

注記

統計はすべてランタイムのみの情報で、デフォルトは false であるため、必ず include-runtime=true 引数を指定するようにしてください。

6.6.5. データソースの統計

主要統計

サポートされるデータソースの主要統計は下表のとおりです。

表6.15 主要統計

名前 説明
ActiveCount
アクティブな接続の数。各接続はアプリケーションによって使用されているか、プールで使用可能な状態であるかのいずれかになります。
AvailableCount
プールの使用可能な接続の数。
AverageBlockingTime
プールの排他ロックの取得をブロックするために費やされた平均時間。値はミリ秒単位です。
AverageCreationTime
接続の作成に費やされた平均時間。値はミリ秒単位です。
CreatedCount
作成された接続の数。
DestroyedCount
破棄された接続の数。
InUseCount
現在使用中の接続の数。
MaxCreationTime
接続の作成にかかった最大時間。値はミリ秒単位です。
MaxUsedCount
使用される接続の最大数。
MaxWaitCount
同時に接続を待機するリクエストの最大数。
MaxWaitTime
プールの排他ロックを待つために費やされた最大時間。
TimedOut
タイムアウトした接続の数。
TotalBlockingTime
プールの排他ロックを待つために費やされた合計時間。値はミリ秒単位です。
TotalCreationTime
接続の作成に費やされた合計時間。値はミリ秒単位です。
WaitCount
接続を待つ必要があるリクエストの数。
JDBC の統計

サポートされるデータソースの JDBC 統計は下表のとおりです。

表6.16 JDBC の統計

名前 説明
PreparedStatementCacheAccessCount
ステートメントキャッシュがアクセスされた回数。
PreparedStatementCacheAddCount
ステートメントキャッシュに追加されたステートメントの数。
PreparedStatementCacheCurrentSize
ステートメントキャッシュに現在キャッシュされた準備済みおよび呼び出し可能ステートメントの数。
PreparedStatementCacheDeleteCount
キャッシュから破棄されたステートメントの数。
PreparedStatementCacheHitCount
キャッシュからのステートメントが使用された回数。
PreparedStatementCacheMissCount
ステートメント要求がキャッシュのステートメントと一致しなかった回数。

6.7. データソース例

6.7.1. PostgreSQL のデータソースの例

例6.7

PostgreSQL のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 PostgreSQL データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.2. PostgreSQL XA のデータソースの例

例6.8

PostgreSQL XA のデータソースの設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 PostgreSQL XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.3. MySQL のデータソースの例

例6.9

MySQL のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 MySQL データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.4. MySQL XA のデータソースの例

例6.10

MySQL XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 MySQL XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.5. Oracle のデータソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが必要ではなくなりました。

例6.11

Oracle のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Oracle データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.6. Oracle XA データソースの例

注記

バージョン 10.2 以前の Oracle データソースでは非トランザクション接続とトランザクション接続が混在するとエラーが発生したため、<no-tx-separate-pools/> パラメーターが必要でした。一部のアプリケーションでは、このパラメーターが必要ではなくなりました。

重要

Oracle XA データソースにアクセスするユーザーは、以下の設定を適用しないと XA リカバリーが適切に操作しません。値 user は、JBoss から Oracle に接続するために定義されたユーザーです。
  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user; (パッチ済みの Oracle 10g R2、または Oracle 11g を使用する場合)
    または
    GRANT EXECUTE ON sys.dbms_system TO user; (パッチされていない 11g 以前のバージョンの Oracle を使用する場合)

例6.12

Oracle XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Oracle XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.7. Microsoft SQLServer のデータソースの例

例6.13

Microsoft SQLServer のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
</datasources>
上記 Microsoft SQLServer データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.8. Microsoft SQLServer XA のデータソースの例

例6.14

Microsoft SQLServer XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Microsoft SQLServer XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.9. IBM DB2 のデータソースの例

例6.15

IBM DB2 のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jdbc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 IBM DB2 データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.10. IBM DB2 XA のデータソースの例

例6.16

IBM DB2 XA のデータソース設定例は以下のとおりです。データソースの有効化、ユーザーの追加、および検証オプションの設定が行われます。
<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">false</config-property>
        <config-property name="IsValidOverride">false</config-property>
        <config-property name="EnableClose">false</config-property>
      </recover-plugin>
    </recovery>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 IBM DB2 XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc.jar"/>
    <resource-root path="db2jcc_license_cisuz.jar"/>
    <resource-root path="db2jcc_license_cu.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.11. Sybase データソースの例

例6.17

Sybase データソースの設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Sybase データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

6.7.12. Sybase XA データソースの例

例6.18

Sybase XA データソースの設定例は以下のとおりです。データソースが有効化され、ユーザーが追加されて、検証オプションが設定されています。
<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <background-validation>true</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc2.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc3.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
上記 Sybase XA データソースの module.xml ファイルの例は次のとおりです。
<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

第7章 モジュールの設定

7.1. はじめに

7.1.1. モジュール

モジュールは、クラスローディングおよび依存関係管理に使用されるクラスの論理グループです。JBoss EAP 6 は、静的および動的モジュールと呼ばれる 2 つのタイプのモジュールを識別します。この 2 つのタイプのモジュールは、パッケージ化された方法のみが異なります。すべてのモジュールは同じ機能を提供します。
静的モジュール
静的モジュールは、アプリケーションサーバーの EAP_HOME/modules/ ディレクトリーに事前定義されます。各サブディレクトリーは 1 つのモジュールを表し、1 つまたは複数の JAR ファイルと設定ファイル (module.xml) が含まれます。モジュールの名前は、module.xml ファイルで定義されます。アプリケーションサーバーで提供されるすべての API (Java EE API や JBoss Logging などの他の API を含む) は、静的モジュールとして提供されます。

例7.1 module.xml ファイルの例

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.1.15.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
モジュール名 com.mysql はそのモジュールのディレクトリー構造と一致する必要があります。
カスタム静的モジュールの作成は、同じサードパーティーライブラリーを使用する同じサーバー上に多くのアプリケーションがデプロイされる場合に役立ちます。これらのライブラリーを各アプリケーションとバンドルする代わりに、JBoss 管理者はこれらのライブラリーが含まれるモジュールを作成およびインストールできます。アプリケーションは、カスタム静的モジュールで明示的な依存関係を宣言できます。
動的モジュール
動的モジュールは、各 JAR または WAR デプロイメント (または、EAR 内のサブデプロイメント) に対してアプリケーションサーバーによって作成およびロードされます。動的モジュールの名前は、デプロイされたアーカイブの名前から派生されます。デプロイメントはモジュールとしてロードされるため、依存関係を設定でき、他のデプロイメントは依存関係として使用することが可能です。
モジュールは必要なときのみロードされます。通常、明示的または暗黙的な依存関係があるアプリケーションがデプロイされるときのみ、モジュールがロードされます。

7.1.2. グローバルモジュール

グローバルモジュールは、JBoss EAP 6 がすべてのアプリケーションへの依存関係として提供するモジュールです。このモジュールをアプリケーションサーバーのグローバルモジュールリストへ追加すると、どのモジュールもグローバルモジュールになります。モジュールへの変更は必要ありません。

7.1.3. モジュールの依存性

モジュール依存関係とは、あるモジュールが機能するには別のモジュールのクラスを必要とする宣言のことです。モジュールはいくつでも他のモジュールの依存関係を宣言することができます。アプリケーションサーバーがモジュールをロードするとき、モジュールクラスローダーがモジュールの依存関係を解析し、各依存関係のクラスをクラスパスに追加します。指定の依存関係が見つからない場合、モジュールはロードできません。
デプロイされたアプリケーション (JAR または WAR) は動的モジュールとしてロードされ、依存関係を利用して JBoss EAP 6 によって提供される API にアクセスします。
依存関係には明示的と暗黙的の 2 つのタイプがあります。
明示的な依存関係は開発者が設定に宣言します。静的モジュールでは、依存関係を modules.xml ファイルに宣言できます。動的モジュールでは、デプロイメントの MANIFEST.MF または jboss-deployment-structure.xml デプロイメント記述子に依存関係を宣言できます。
明示的な依存関係は、任意の依存関係として指定できます。任意の依存関係をロードできなくても、モジュールによるロードは失敗しません。しかし、依存関係が後で使用できるようになっても、モジュールのクラスパスには追加されません。モジュールがロードされるときに依存関係が使用できなければなりません。
暗黙的な依存関係は、デプロイメントで特定の状態やメタデータが見つかったときに、アプリケーションサーバーによって自動的に追加されます。JBoss EAP 6 に同梱される Java EE 6 API は、デプロイメントで暗黙的な依存関係が検出されたときに追加されるモジュールの例になります。
デプロイメントを設定して特定の暗黙的な依存関係を除外することも可能です。この設定は jboss-deployment-structure.xml デプロイメント記述子ファイルで行います。これは、アプリケーションサーバーが暗黙的な依存関係として追加しようとする特定バージョンのライブラリーを、アプリケーションがバンドルする場合に一般的に行われます。
モジュールのクラスパスには独自のクラスとその直接の依存関係のみが含まれます。モジュールは 1 つの依存関係の依存関係クラスにはアクセスできませんが、暗示的な依存関係のエクスポートを指定できます。エクスポートされた依存関係は、エクスポートするモジュールに依存するモジュールへ提供されます。

例7.2 モジュールの依存関係

モジュール A はモジュール B に依存し、モジュール B はモジュール C に依存します。モジュール A はモジュール B のクラスにアクセスでき、モジュール B はモジュール C のクラスにアクセスできます。以下の場合を除き、モジュール A はモジュール C のクラスにはアクセスできません。
  • モジュール A がモジュール C への明示的な依存関係を宣言する場合。
  • または、モジュール B がモジュール B の依存関係をモジュール C でエクスポートする場合。

7.1.4. サブデプロイメントクラスローダーの分離

エンタープライズアーカイブ (EAR) の各サブデプロイメントは独自のクラスローダーを持つ動的モジュールです。デフォルトでは、サブデプロイメントは他のサブデプロイメントのリソースにアクセスできます。
サブデプロイメントが他のサブデプロイメントのリソースにアクセスすべきでない場合 (厳格なサブデプロイメントの分離が必要な場合) は、この挙動を有効にできます。

7.2. すべてのデプロイメントを対象とするサブデプロイメントモジュール分離の無効化

このタスクでは、サーバー管理者がアプリケーションサーバーでサブデプロイメントモジュールの分離を無効化する方法を説明します。このタスクは、すべてのデプロイメントに影響します。

警告

このタスクでは、サーバーの XML 設定ファイルを編集する必要があります。この作業を行う前に、サーバーを停止する必要があります。最終リリースの管理ツールでは、このような設定がサポートされるようになるため、これは一時的な措置になります。
  1. サーバーを停止する

    JBoss EAP サーバーを停止します。
  2. サーバー設定ファイルを開く

    サーバー設定ファイルをテキストエディターで開きます。
    このファイルは、管理対象ドメインまたはスタンドアロンサーバーによって異なります。また、デフォルト以外の場所とファイル名が使用されることがあります。デフォルトの設定ファイルは、 domain/configuration/domain.xml (管理対象ドメインの場合) と standalone/configuration/standalone.xml (スタンドアロンサーバー) です。
  3. EE サブシステム設定を特定する

    設定ファイルの EE サブシステム設定要素を特定します。設定ファイルの <profile> 要素には、複数のサブシステム要素が含まれます。EE サブシステム要素には urn:jboss:domain:ee:1.0 のネームスペースがあります。
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.0" />
    
       ...
    デフォルト設定には単一の自己終了タグがありますが、カスタム設定は、以下のような個別の開始タグと終了タグを持つことがあります (タグ間に別の要素が含まれることがあります)。
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
  4. 自己終了タグを置き換える (必要な場合)

    EE サブシステム要素が単一の自己終了タグである場合は、以下のように適切な開始タグと終了タグで置き換えます。
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ></subsystem>
  5. ear-subdeployments-isolated 要素を追加する

    以下のように、ear-subdeployments-isolated 要素を EE サブシステム要素の子として追加し、false の内容を追加します。
    <subsystem xmlns="urn:jboss:domain:ee:1.0" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
  6. サーバーを起動する

    新しい設定で実行されるよう JBoss EAP サーバーを再起動します。
結果

すべてのデプロイメントに対してサブデプロイメントモジュール分離が無効化された状態で、サーバーが実行されます。

7.3. すべてのデプロイメントへのモジュールの追加

このタスクは JBoss 管理者によるグローバルモジュールリストの定義方法を実証します。

要件

  1. グローバルモジュールとして設定されるモジュールの名前を知っている必要があります。JBoss EAP 6 に含まれる静的モジュールの一覧は、「含まれるモジュール」を参照してください。モジュールが他のデプロイメントにある場合は、「動的モジュールの名前付け」を参照してモジュール名を判断してください。

手順7.1 グローバルモジュールのリストへモジュールを追加する

  1. 「管理コンソールへログイン」に従って、管理コンソールへログインします。
  2. EE Subsystem パネルへ移動します。
      • スタンドアロンモード

        コンソールの上部より Profile タブ を選択します。
      • ドメインモード

        1. コンソールの上部より Profiles タブ を選択します。
        2. 左上のドロップダウンボックスより該当するプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開します。
    1. コンソールの左側にあるメニューより ContainerEE の順で選択します。
  3. Subsystem Defaults セクションの Add ボタンをクリックします。Create Module ダイアログが表示されます。
  4. モジュールの名前と任意でモジュールスロットを入力します。
  5. Save ボタンをクリックして新しいグローバルモジュールを追加するか、 Cancel リンクをクリックしてキャンセルします。
    • Save ボタンをクリックすると、ダイアログが閉じられ指定のモジュールがグローバルモジュールのリストに追加されます。
    • Cancel をクリックするとダイアログが閉じられ、何も変更されません。
結果

グローバルモジュールのリストに追加されたモジュールは各デプロイメントへの依存関係に追加されます。

7.4. リファレンス

7.4.1. 含まれるモジュール

  • asm.asm
  • ch.qos.cal10n
  • com.google.guava
  • com.h2database.h2
  • com.sun.jsf-impl
  • com.sun.jsf-impl
  • com.sun.xml.bind
  • com.sun.xml.messaging.saaj
  • gnu.getopt
  • javaee.api
  • javax.activation.api
  • javax.annotation.api
  • javax.api
  • javax.ejb.api
  • javax.el.api
  • javax.enterprise.api
  • javax.enterprise.deploy.api
  • javax.faces.api
  • javax.faces.api
  • javax.inject.api
  • javax.interceptor.api
  • javax.jms.api
  • javax.jws.api
  • javax.mail.api
  • javax.management.j2ee.api
  • javax.persistence.api
  • javax.resource.api
  • javax.rmi.api
  • javax.security.auth.message.api
  • javax.security.jacc.api
  • javax.servlet.api
  • javax.servlet.jsp.api
  • javax.servlet.jstl.api
  • javax.transaction.api
  • javax.validation.api
  • javax.ws.rs.api
  • javax.wsdl4j.api
  • javax.xml.bind.api
  • javax.xml.jaxp-provider
  • javax.xml.registry.api
  • javax.xml.rpc.api
  • javax.xml.soap.api
  • javax.xml.stream.api
  • javax.xml.ws.api
  • jline
  • net.sourceforge.cssparser
  • net.sourceforge.htmlunit
  • net.sourceforge.nekohtml
  • nu.xom
  • org.antlr
  • org.apache.ant
  • org.apache.commons.beanutils
  • org.apache.commons.cli
  • org.apache.commons.codec
  • org.apache.commons.collections
  • org.apache.commons.io
  • org.apache.commons.lang
  • org.apache.commons.logging
  • org.apache.commons.pool
  • org.apache.cxf
  • org.apache.httpcomponents
  • org.apache.james.mime4j
  • org.apache.log4j
  • org.apache.neethi
  • org.apache.santuario.xmlsec
  • org.apache.velocity
  • org.apache.ws.scout
  • org.apache.ws.security
  • org.apache.ws.xmlschema
  • org.apache.xalan
  • org.apache.xerces
  • org.apache.xml-resolver
  • org.codehaus.jackson.jackson-core-asl
  • org.codehaus.jackson.jackson-jaxrs
  • org.codehaus.jackson.jackson-mapper-asl
  • org.codehaus.jackson.jackson-xc
  • org.codehaus.woodstox
  • org.dom4j
  • org.hibernate
  • org.hibernate.envers
  • org.hibernate.infinispan
  • org.hibernate.validator
  • org.hornetq
  • org.hornetq.ra
  • org.infinispan
  • org.infinispan.cachestore.jdbc
  • org.infinispan.cachestore.remote
  • org.infinispan.client.hotrod
  • org.jacorb
  • org.javassist
  • org.jaxen
  • org.jboss.as.aggregate
  • org.jboss.as.appclient
  • org.jboss.as.cli
  • org.jboss.as.clustering.api
  • org.jboss.as.clustering.common
  • org.jboss.as.clustering.ejb3.infinispan
  • org.jboss.as.clustering.impl
  • org.jboss.as.clustering.infinispan
  • org.jboss.as.clustering.jgroups
  • org.jboss.as.clustering.service
  • org.jboss.as.clustering.singleton
  • org.jboss.as.clustering.web.infinispan
  • org.jboss.as.clustering.web.spi
  • org.jboss.as.cmp
  • org.jboss.as.connector
  • org.jboss.as.console
  • org.jboss.as.controller
  • org.jboss.as.controller-client
  • org.jboss.as.deployment-repository
  • org.jboss.as.deployment-scanner
  • org.jboss.as.domain-add-user
  • org.jboss.as.domain-http-error-context
  • org.jboss.as.domain-http-interface
  • org.jboss.as.domain-management
  • org.jboss.as.ee
  • org.jboss.as.ee.deployment
  • org.jboss.as.ejb3
  • org.jboss.as.embedded
  • org.jboss.as.host-controller
  • org.jboss.as.jacorb
  • org.jboss.as.jaxr
  • org.jboss.as.jaxrs
  • org.jboss.as.jdr
  • org.jboss.as.jmx
  • org.jboss.as.jpa
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate
  • org.jboss.as.jpa.hibernate.infinispan
  • org.jboss.as.jpa.openjpa
  • org.jboss.as.jpa.spi
  • org.jboss.as.jpa.util
  • org.jboss.as.jsr77
  • org.jboss.as.logging
  • org.jboss.as.mail
  • org.jboss.as.management-client-content
  • org.jboss.as.messaging
  • org.jboss.as.modcluster
  • org.jboss.as.naming
  • org.jboss.as.network
  • org.jboss.as.osgi
  • org.jboss.as.platform-mbean
  • org.jboss.as.pojo
  • org.jboss.as.process-controller
  • org.jboss.as.protocol
  • org.jboss.as.remoting
  • org.jboss.as.sar
  • org.jboss.as.security
  • org.jboss.as.server
  • org.jboss.as.standalone
  • org.jboss.as.threads
  • org.jboss.as.transactions
  • org.jboss.as.web
  • org.jboss.as.webservices
  • org.jboss.as.webservices.server.integration
  • org.jboss.as.webservices.server.jaxrpc-integration
  • org.jboss.as.weld
  • org.jboss.as.xts
  • org.jboss.classfilewriter
  • org.jboss.com.sun.httpserver
  • org.jboss.common-core
  • org.jboss.dmr
  • org.jboss.ejb-client
  • org.jboss.ejb3
  • org.jboss.iiop-client
  • org.jboss.integration.ext-content
  • org.jboss.interceptor
  • org.jboss.interceptor.spi
  • org.jboss.invocation
  • org.jboss.ironjacamar.api
  • org.jboss.ironjacamar.impl
  • org.jboss.ironjacamar.jdbcadapters
  • org.jboss.jandex
  • org.jboss.jaxbintros
  • org.jboss.jboss-transaction-spi
  • org.jboss.jsfunit.core
  • org.jboss.jts
  • org.jboss.jts.integration
  • org.jboss.logging
  • org.jboss.logmanager
  • org.jboss.logmanager.log4j
  • org.jboss.marshalling
  • org.jboss.marshalling.river
  • org.jboss.metadata
  • org.jboss.modules
  • org.jboss.msc
  • org.jboss.netty
  • org.jboss.osgi.deployment
  • org.jboss.osgi.framework
  • org.jboss.osgi.resolver
  • org.jboss.osgi.spi
  • org.jboss.osgi.vfs
  • org.jboss.remoting3
  • org.jboss.resteasy.resteasy-atom-provider
  • org.jboss.resteasy.resteasy-cdi
  • org.jboss.resteasy.resteasy-jackson-provider
  • org.jboss.resteasy.resteasy-jaxb-provider
  • org.jboss.resteasy.resteasy-jaxrs
  • org.jboss.resteasy.resteasy-jsapi
  • org.jboss.resteasy.resteasy-multipart-provider
  • org.jboss.sasl
  • org.jboss.security.negotiation
  • org.jboss.security.xacml
  • org.jboss.shrinkwrap.core
  • org.jboss.staxmapper
  • org.jboss.stdio
  • org.jboss.threads
  • org.jboss.vfs
  • org.jboss.weld.api
  • org.jboss.weld.core
  • org.jboss.weld.spi
  • org.jboss.ws.api
  • org.jboss.ws.common
  • org.jboss.ws.cxf.jbossws-cxf-client
  • org.jboss.ws.cxf.jbossws-cxf-factories
  • org.jboss.ws.cxf.jbossws-cxf-server
  • org.jboss.ws.cxf.jbossws-cxf-transports-httpserver
  • org.jboss.ws.jaxws-client
  • org.jboss.ws.jaxws-jboss-httpserver-httpspi
  • org.jboss.ws.native.jbossws-native-core
  • org.jboss.ws.native.jbossws-native-factories
  • org.jboss.ws.native.jbossws-native-services
  • org.jboss.ws.saaj-impl
  • org.jboss.ws.spi
  • org.jboss.ws.tools.common
  • org.jboss.ws.tools.wsconsume
  • org.jboss.ws.tools.wsprovide
  • org.jboss.xb
  • org.jboss.xnio
  • org.jboss.xnio.nio
  • org.jboss.xts
  • org.jdom
  • org.jgroups
  • org.joda.time
  • org.junit
  • org.omg.api
  • org.osgi.core
  • org.picketbox
  • org.picketlink
  • org.python.jython.standalone
  • org.scannotation.scannotation
  • org.slf4j
  • org.slf4j.ext
  • org.slf4j.impl
  • org.slf4j.jcl-over-slf4j
  • org.w3c.css.sac
  • sun.jdk

7.4.2. 動的モジュールの名前付け

すべてのデプロイメントは JBoss EAP 6 によってモジュールとしてロードされ、以下の慣例に従って名前が付けられます。
  1. WAR および JAR ファイルのデプロイメントは次の形式で名前が付けられます。
     deployment.DEPLOYMENT_NAME 
    たとえば、inventory.war のモジュール名は deployment.inventory.war となり、store.jar のモジュール名は deployment.store.jar となります。
  2. エンタープライズアーカイブ内のサブデプロイメントは次の形式で名前が付けられます。
     deployment.EAR_NAME.SUBDEPLOYMENT_NAME 
    たとえば、エンタープライズアーカイブ accounts.ear 内にある reports.war のサブデプロイメントのモジュール名は deployment.accounts.ear.reports.war になります。

第8章 グローバル値

8.1. バルブ

バルブは、アプリケーションのパイプラインを処理するリクエストに挿入される Java クラスです。バルブはサーブレットフィルターの前にパイプラインへ挿入されます。バルブはリクエストを渡す前に変更を加えることができ、認証またはリクエストのキャンセルなどの他の処理を実行できます。通常、バルブはアプリケーションとパッケージ化されます。
6.1.0 およびそれ以降のバージョンはグローバルバルブをサポートします。

8.2. グローバルバルブ

グローバルバルブは、デプロイされたすべてのアプリケーションのパイプラインを処理するリクエストへ挿入されるバルブです。バルブは、JBoss EAP 6 で静的モジュールとしてパッケージ化およびインストールされ、グローバルバルブとなります。グローバルバルブは Web サブシステムで設定されます。
6.1.0 およびそれ以降のバージョンのみがグローバルバルブをサポートします。

8.3. オーセンティケーターバルブ

オーセンティケーターバルブは、リクエストの証明情報を認証するバルブです。オーセンティケーターバルブは org.apache.catalina.authenticator.AuthenticatorBase のサブクラスで、authenticate() メソッドを上書きします。
このバルブを使用して追加の認証スキームを実装できます。

8.4. グローバルバルブのインストール

グローバルバルブは、JBoss EAP 6 で静的モジュールとしてパッケージ化およびインストールされる必要があります。このタスクでは、モジュールのインストール方法について説明します。

要件:

  • バルブを作成し、JAR ファイルにパッケージ化する必要があります。
  • モジュールに対して module.xml ファイルを作成する必要があります。
    module.xml ファイルの例は、「モジュール」を参照してください。

手順8.1 グローバルモジュールのインストール

  1. モジュールインストールディレクトリーの作成

    インストールするモジュールのディレクトリーはアプリケーションサーバーの modules ディレクトリーに作成する必要があります。
    EAP_HOME/modules/system/layers/base/MODULENAME/main
    $ mkdir -P /usr/share/jboss/modules/system/layers/base/MyValveModule/main
  2. ファイルのコピー

    JAR および module.xml ファイルを 1. で作成したディレクトリーにコピーします。
    $ cp MyValves.jar modules.xml /usr/share/jboss/modules/system/layers/base/MyValveModule/main
モジュールで宣言したバルブクラスを Web サブシステムで設定できるようになります。

8.5. グローバルバルブの設定

グローバルバルブは Web サブシステムで有効化および設定されます。これには JBoss CLI ツールを使用します。

手順8.2 グローバルバルブの設定

  1. バルブの有効化

    add 操作を使用して新しいバルブエントリーを追加します。
    /subsystem=web/valve=VALVENAME:add(module="MODULENAME",class-name="CLASSNAME")
    次の値を指定する必要があります。
    • VALVENAME (アプリケーション設定でこのバルブの参照に使用される名前)
    • MODULENAME (設定される値が含まれるモジュール)
    • CLASSNAME (モジュールの特定バルブのクラス名)
    /subsystem=web/valve=clientlimiter:add(module="clientlimitermodule",class-name="org.jboss.samplevalves.restrictedUserAgentsValve")
  2. オプション: パラメーターの指定

    バルブに設定パラメーターがある場合は、add-param 操作で指定します。
    /subsystem=web/valve=testvalve:add-param(param-name="NAME", param-value="VALUE")
    /subsystem=web/valve=testvalve:add-param(
       param-name="restricteduseragents", 
       param-value="^.*MS Web Services Client Protocol.*$"
    )
バルブがデプロイされたすべてのアプリケーションに対して有効になり、設定されます。

第9章 アプリケーションデプロイメント

9.1. アプリケーションデプロイメント

JBoss EAP 6 は、管理環境と開発環境の両方に対応するよう、さまざまなアプリケーションデプロイメントおよび設定オプションを提供します。管理者向けには、管理コンソールと管理 CLI によって、本番環境でアプリケーションデプロイメントを管理できる理想的なグラフィカルおよびコマンドラインインターフェースが提供されます。開発者用には、アプリケーションデプロイメントのテストオプションとして、設定可能なファイルシステムデプロイメントスキャナー、JBoss Developer Studio などの IDE の使用、Maven を介したデプロイメントおよびアンデプロイメントなどが提供されます。

9.2. 管理コンソールでのデプロイ

9.2.1. 管理コンソースでのアプリケーションデプロイメント管理

管理コンソールよりアプリケーションをデプロイすると、使いやすさが利点のグラフィカルインターフェースを使用できます。ご使用のサーバーもしくはサーバーグループにデプロイされているアプリケーションを一目で確認できるほか、必要に応じてアプリケーションを無効にしたり、コンテンツリポジトリーから削除したりできます。

9.2.2. 管理コンソールを使用したアプリケーションのデプロイ

手順9.1 管理コンソールを使用したアプリケーションのデプロイ

  1. 管理コンソールの Manage Deployments パネルに移動します

    1. コンソールの上部より Runtime タブを選択します。
    2. Domain または Standalone メニューを展開します (展開されていない場合)。
    3. コンソールの左側にあるメニューより Manage Deployments オプションを選択します。
  2. アプリケーションをデプロイします

    デプロイメントの方法は、デプロイ先がスタンドアロンサーバーインスタンスであるか、または管理対象ドメインであるかによって異なります。
    • スタンドアロンサーバーインスタンスへのデプロイメント

      Available Deployment Content テーブルは、利用可能なすべてのアプリケーションデプロイメントとそれらの状態を表示します。
      1. スタンドアロンサーバーインスタンスでアプリケーションを有効にします

        Deployments の表のEnable ボタンをクリックし、アプリケーションのデプロイメントを有効にします。
      2. 確定します

        confirm ボタンをクリックし、サーバーインスタンスでのアプリケーションの有効化を確定します。
    • 管理対象ドメインへのデプロイメント

      Deployment Content 部には、 Content Repository の表が含まれており、利用可能なアプリケーションデプロイメントとその状態がすべて表示されます。
      1. 管理対象ドメインでアプリケーションを有効にします

        Content Repository テーブルの Add ボタンをクリックします。
      2. サーバーグループを選択します

        アプリケーションを追加したいサーバーグループのボックスにチェックマークを付け、Save ボタンをクリックして続行します。
      3. 確定します

        Server Group Deployments タブをクリックし、Server Groups の表を表示します。お使いのアプリケーションは先ほど選択したサーバーグループにデプロイされています。
結果

該当のサーバーあるいはサーバーグループにアプリケーションがデプロイされます。

9.2.3. 管理コンソールを使用したアプリケーションのアンデプロイ

手順9.2 管理コンソールを使用したアプリケーションのアンデプロイ

  1. 管理コンソールの Manage Deployments パネルに移動します

    1. コンソールの上部より Runtime タブを選択します。
    2. Domain または Standalone メニューを展開します (展開されていない場合)。
    3. コンソールの左側にあるメニューより Manage Deployments オプションを選択します。
  2. アプリケーションをアンデプロイします

    アンデプロイする方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらからアンデプロイするかによって異なります。
    • スタンドアロンサーバーインスタンスからのアンデプロイ

      Available Deployment Content テーブルは、利用可能なすべてのアプリケーションデプロイメントとそれらの状態を表示します。
      1. スタンドアロンサーバーインスタンスでアプリケーションを無効にします

        Deployments の表の Disable ボタンをクリックし、アプリケーションを無効にします。
      2. アプリケーションの無効化を確定します

        confirm ボタンをクリックし、サーバーインスタンスでのアプリケーションの無効化を確定します。
    • 管理対象ドメインからのアンデプロイ

      Deployment Content セクションには Content Repository タブが含まれます。Available Deployment Content は、利用可能なすべてのアプリケーションデプロイメントとそれらの状態を表示します。
      1. 管理対象ドメインでアプリケーションを無効にします

        Server Groups タブをクリックして、サーバーグループとデプロイされたアプリケーションの状態を表示します。
      2. サーバーグループを選択します

        Server Group の表からサーバー名をクリックし、そのサーバーからアプリケーションをアンデプロイします。
      3. 選択したサーバーからアプリケーションを無効にします

        disable ボタンをクリックし、選択したサーバーのアプリケーションを無効にします。
      4. アプリケーションの無効化を確定します

        confirm ボタンをクリックし、サーバーインスタンスでのアプリケーションの無効化を確定します。
      5. 残りのサーバーグループを繰り返しアンデプロイします

        必要に応じて、他のサーバーグループにも同じ手順を繰り返します。Deployments の表にある各サーバーグループに対してアプリケーションの状態が確定されます。
結果

該当のサーバーあるいはサーバーグループからアプリケーションがアンデプロイされます。

9.3. 管理 CLI でのデプロイ

9.3.1. 管理 CLI でのアプリケーションデプロイメントの管理

管理 CLI を使用してアプリケーションをデプロイすると、単一のコマンドラインインターフェースでデプロイメントスクリプトを作成および実行できます。このスクリプト機能を使用して、特定のアプリケーションデプロイメントおよび管理シナリオを設定できます。スタンドアロンインスタンスの場合は単一サーバーのデプロイメント状態を管理でき、管理対象ドメインの場合はサーバーのネットワーク全体を管理できます。

9.3.2. 管理 CLI を使用した管理対象ドメインでのアプリケーションのデプロイ

手順9.3 管理対象ドメインでのアプリケーションのデプロイ

  • deploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントへのパスを指定して deploy コマンドを入力します。すべてのサーバーグループをデプロイするために --all-server-groups パラメーターを追加します。
    [domain@localhost:9999 /] deploy /path/to/test-application.war --all-server-groups
    • または、--server-groups パラメーターを追加して、デプロイメントに固有なサーバーグループを定義します。
      [domain@localhost:9999 /] deploy /path/to/test-application.war --server-groups=server_group_1,server_group_2
    デプロイメントに成功すると、CLI へ出力されません。
結果

指定のアプリケーションが、管理対象ドメインのサーバーグループにデプロイされます。

9.3.3. 管理 CLI を使用した管理対象ドメインでのアプリケーションのアンデプロイ

手順9.4 管理対象ドメインでのアプリケーションのアンデプロイ

  • undeploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントのファイル名を指定して undeploy コマンドを入力します。--all-relevant-server-groups パラメーターを追加すると、アプリケーションがデプロイされたすべてのサーバーグループからアプリケーションをアンデプロイできます。
    [domain@localhost:9999 /]undeploytest-application.war--all-relevant-server-groups
    アンデプロイメントに成功すると、CLI へ出力されません。
結果

指定のアプリケーションがアンデプロイされます。

9.3.4. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのデプロイ

手順9.5 スタンドアロンサーバーでのアプリケーションのデプロイ

  • deploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントへのパスを指定して deploy コマンドを入力します。
    [standalone@localhost:9999 /] deploy /path/to/test-application.war
    デプロイメントに成功すると、CLI へ出力されません。
結果

指定のアプリケーションが、スタンドアロンサーバーにデプロイされます。

9.3.5. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのアンデプロイ

手順9.6 スタンドアロンサーバーでのアプリケーションのアンデプロイ

  • undeploy コマンドの実行

    管理 CLI で、アプリケーションデプロイメントのファイル名を指定して undeploy コマンドを入力します。
    [standalone@localhost:9999 /] undeploy test-application.war
    アンデプロイメントに成功すると、CLI へ出力されません。
結果

指定のアプリケーションがアンデプロイされます。

9.4. デプロイメントスキャナーでのデプロイ

9.4.1. デプロイメントスキャナーでのアプリケーションデプロイメント管理

デプロイメントスキャナーを用いてスタンドアロンサーバーインスタンスにアプリケーションをデプロイすると、迅速なデプロイメントサイクルに適した方法でアプリケーションの構築とテストを行えます。デプロイメントスキャナーは、デプロイメントの頻度や多様なアプリケーションタイプの挙動などの必要性に合わせて設定できます。

9.4.2. デプロイメントスキャナーを使用したスタンドアロンサーバーインスタンスへのアプリケーションのデプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイする方法を説明します。「アプリケーションデプロイメント 」で説明があるとおり、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には、管理コンソールと管理 CLI の方法が推奨されます。

手順9.7 デプロイメントスキャナーを使用したアプリケーションのデプロイ

  1. デプロイメントフォルダーへのコンテンツのコピー

    アプリケーションファイルを、EAP_HOME/standalone/deployments/ にあるデプロイメントフォルダーにコピーします。
  2. デプロイメントスキャンモード

    アプリケーションのデプロイメントは、デプロイメントスキャナーモードが自動または手動であるかによって異なります。
    • 自動デプロイメント

      デプロイメントスキャナーは、フォルダー状態の変更を検出し、「デプロイメントスキャナーマーカーファイルのリファレンス」 で定義されたようにマーカーファイルを作成します。
    • 手動デプロイメント

      デプロイメントスキャナーでは、デプロイメントプロセスをトリガーするマーカーファイルが必要です。以下の例では、Unix の touch コマンドを使用して新しい .dodeploy ファイルを作成します。

      例9.1 touch コマンドを使用したデプロイ

      [user@host bin]$ touch$EAP_HOME/standalone/deployments/example.war.dodeploy
結果

アプリケーションファイルがアプリケーションサーバーにデプロイされます。マーカーファイルがデプロイメントフォルダーで作成され、デプロイメントが正常に終了したことを示します。アプリケーションは、管理コンソールで、Enabled と示されます。

例9.2 デプロイメント後のデプロイメントフォルダーコンテンツ

example.war
example.war.deployed

9.4.3. デプロイメントスキャナーを使用したスタンドアロンサーバーインスタンスのアプリケーションのアンデプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイする方法を説明します。「アプリケーションデプロイメント 」で説明があるとおり、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

注記

デプロイメントスキャナーは、アプリケーション管理の他のデプロイメント方法とともに使用しないでください。管理コンソールによってアプリケーションサーバーから削除されたアプリケーションは、デプロイメントディレクトリーに含まれるマーカーファイルまたはアプリケーションに影響を与えずにランタイムから削除されます。意図しない再デプロイメントや、他のエラーの可能性を最低限にするには、本番稼働環境での管理に管理 CLI および管理コンソールを使用します。

手順9.8 以下の方法の 1 つを用いたアプリケーションのアンデプロイ

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

    アプリケーションをデプロイする方法は 2 つありますが、アプリケーションをデプロイメントフォルダーから削除する場合と、デプロイメントの状態のみを変更する場合によって、使用する方法が異なります。
    • マーカーファイルの削除によるアンデプロイ

      デプロイされたアプリケーションの example.war.deployed マーカーファイルを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをアンデプロイし、example.war.undeployed マーカーファイルを作成します。アプリケーションは、デプロイメントフォルダーに維持されます。
    • アプリケーションの削除によるアンデプロイ

      デプロイメントディレクトリーからアプリケーションを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーは、アプリケーションをアンデプロイし、filename.filetype.undeployed マーカーファイルを作成します。アプリケーションはデプロイメントフォルダーに存在しません。
結果

アプリケーションファイルは、アプリケーションサーバーからアンデプロイされ、管理コンソールの Deployments 画面に表示されません。

9.4.4. デプロイメントスキャナーを使用したスタンドアロンサーバーインスタンスへのアプリケーションの再デプロイ

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスへアプリケーションを再デプロイする方法を説明します。「アプリケーションデプロイメント 」 で説明があるとおり、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順9.9 アプリケーションをスタンドアロンサーバーへ再デプロイ

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

    デプロイメントスキャナーでデプロイされたアプリケーションを再デプロイするには、3 つの方法があります。これらの方法はデプロイメントサイクルを開始するためにデプロイメントスキャナーをトリガーし、個々の設定に応じて選択できます。
結果

アプリケーションファイルが再デプロイされます。

9.4.5. デプロイメントスキャナーマーカーファイルのリファレンス

マーカーファイル

マーカーファイルは、デプロイメントスキャナーサブシステムの一部です。これらのファイルは、スタンドアロンサーバーインスタンスのデプロイメントディレクトリー内にあるアプリケーションの状態をマークします。マーカーファイルは、アプリケーションと同じ名前を持ち、ファイル接尾辞はアプリケーションのデプロイメントの状態を示します。以下の表に、各マーカーファイルのタイプおよび応答の定義を示します。

例9.4 マーカーファイル例

以下の例は、testapplication.war という名前のアプリケーションの正常にデプロイされたインスタンスのマーカーファイルを示します。
testapplication.war.deployed

表9.1 マーカーファイルタイプ定義

ファイル名接尾辞 生成元 説明
.dodeploy ユーザー生成 コンテンツをランタイムにデプロイまたは再デプロイする必要があることを示します。
.skipdeploy ユーザー生成 アプリケーションの自動デプロイを無効にします。展開されたコンテンツの自動デプロイメントを一時的にブロックする方法として役に立ち、不完全なコンテンツ編集がライブでプッシュされることを防ぎます。スキャナーは zip 形式のコンテンツに対する処理中の変更を検出し、完了するまで待機しますが、zip 形式のコンテンツとともに使用できます。
.isdeploying システム生成 デプロイメントの開始を示します。デプロイメントプロセスが完了すると、マーカーファイルが削除されます。
.deployed システム生成 コンテンツがデプロイされたことを示します。このファイルが削除された場合、コンテンツはアンデプロイされます。
.failed システム生成 デプロイメントの失敗を示します。マーカーファイルには、失敗の原因に関する情報が含まれます。マーカーファイルが削除された場合、コンテンツは自動デプロイメントで再び可視状態になります。
.isundeploying システム生成 .deployed ファイルの削除に対する応答を示します。コンテンツはアンデプロイされ、完了時にマーカーは自動的に削除されます。
.undeployed システム生成 コンテンツがアンデプロイされたことを示します。マーカーファイルを削除しても、コンテンツの再デプロイメントには影響ありません。
.pending システム生成 デプロイメントの指示が、検出された問題の解決を待っているサーバーに送信されます。このマーカーは、グローバルデプロイメントロードブロックとして機能します。この状態が存在する場合、スキャナーは他のコンテンツをデプロイまたはデプロイ解除するようサーバーに指示しません。

9.4.6. デプロイメントスキャナー属性のリファレンス

デプロイメントスキャナーには、管理 CLI に公開された以下の属性が含まれ、これらの属性は write-attribute 操作を使用して設定できます。設定オプションの詳細については、トピック 「管理 CLI でのデプロイメントスキャナーの設定」 を参照してください。

表9.2 デプロイメントスキャナー属性

名前 説明 タイプ デフォルト値
auto-deploy-exploded .dodeploy マーカーファイルなしで、展開されたコンテンツの自動デプロイメントを許可します。基本的な開発シナリオに対してのみ推奨され、開発者またはオペレーティングシステムによる変更中に、展開されたアプリケーションデプロイメントが行われないようにします。 ブール値 False
auto-deploy-xml .dodeploy マーカーファイルなしでの XML コンテンツの自動デプロイメントを許可します。 ブール値 True
auto-deploy-zipped .dodeploy マーカーファイルなしでの zip 形式のコンテンツの自動デプロイメントを許可します。 ブール値 True
deployment-timeout デプロイメントスキャナーでデプロイメントをキャンセルするまでのデプロイメント試行許可時間 (秒単位)。 Long 600
path スキャンする実際のファイルシステムパスを定義します。relative-to 属性が指定された場合は、path 値が、そのディレクトリーまたはパスに対する相対追加分として機能します。 文字列 deployments
relative-to サーバー設定 XML ファイルの paths セクションで定義されたファイルシステムパスの参照。 文字列 jboss.server.base.dir
scan-enabled scan-interval により起動時にアプリケーションの自動スキャンを許可します。 ブール値 True
scan-interval リポジトリーのスキャン間の時間 (ミリ秒単位)。値が 1 未満の場合は、スキャナーが起動時にのみ動作します。 Int 5000

9.4.7. デプロイメントスキャナーの設定

デプロイメントスキャナーは、管理コンソールまたは管理 CLI を使用して設定できます。新しいデプロイメントスキャナーを作成したり、既存のスキャナー属性を管理したりできます。これらには、スキャン間隔、デプロイメントフォルダーの場所、およびデプロイメントをトリガーするアプリケーションファイルタイプが含まれます。

9.4.8. 管理 CLI でのデプロイメントスキャナーの設定

概要

デプロイメントスキャナーを設定する方法は複数ありますが、バッチスクリプトの使用やリアルタイムによる属性の公開および変更には、管理 CLI を使用できます。read-attribute および write-attribute グローバルコマンドライン操作を使用すると、デプロイメントスキャナーの挙動を変更できます。デプロイメントスキャナー属性の詳細は、「デプロイメントスキャナー属性のリファレンス」の説明を参照してください。

デプロイメントスキャナーは JBoss EAP 6 のサブシステムで、standalone.xml で確認できます。
<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
</subsystem>

手順9.10 デプロイメントスキャナーの設定

  1. 設定するデプロイメントスキャナー属性を決定

    管理 CLI を使用してデプロイメントスキャナーを設定するには、最初に正しい属性名を公開する必要があります。これには、ルートノードで read-resources 操作を使用するか、cd コマンドを使用してサブシステムの子ノードに移動して行います。また、このレベルで ls コマンドを使用して属性を表示することもできます。
    • read-resource 操作を使用して、デプロイメントスキャナー属性を公開

      read-resource 操作を使用して、デフォルトのデプロイメントスキャナーリソースで定義された属性を公開します。
      [standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource
      {
          "outcome" => "success",
          "result" => {
              "auto-deploy-exploded" => false,
              "auto-deploy-xml" => true,
              "auto-deploy-zipped" => true,
              "deployment-timeout" => 600,
              "path" => "deployments",
              "relative-to" => "jboss.server.base.dir",
              "scan-enabled" => true,
              "scan-interval" => 5000
          }
      }
    • ls コマンドを使用してデプロイメントスキャナー属性を公開

      ls コマンドにオプションの -l 引数を指定して、サブシステムノード属性、値、およびタイプを含む結果の表を表示します。ls コマンドとその引数の詳細を確認するには、ls --help と入力して CLI ヘルプエントリーを表示します。管理 CLI のヘルプメニューの詳細については、トピック「管理 CLI でのヘルプの使用」を参照してください。
      [standalone@localhost:9999 /] ls -l /subsystem=deployment-scanner/scanner=default
      ATTRIBUTE            VALUE                 TYPE    
      auto-deploy-exploded false                 BOOLEAN 
      auto-deploy-xml      true                  BOOLEAN 
      auto-deploy-zipped   true                  BOOLEAN 
      deployment-timeout   600                   LONG    
      path                 deployments           STRING  
      relative-to          jboss.server.base.dir STRING  
      scan-enabled         true                  BOOLEAN 
      scan-interval        5000                  INT
  2. write-attribute 操作を使用してデプロイメントスキャナーを設定

    変更する属性の名前を決定したら、write-attribute を使用して、書き込む属性名と新しい値を指定します。以下の例は、すべて子ノードレベルで実行されます。この例を使用するには、cd コマンドとタブ補完を使用してデフォルトスキャナーノードを表示し、移動します。
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    1. 展開されたコンテンツの自動デプロイメントを有効化

      write-attribute 操作を使用して、展開されたアプリケーションコンテンツの自動デプロイメントを有効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true)
      {"outcome" => "success"}
    2. XML コンテンツの自動デプロイメントを無効化

      write-attribute 操作を使用して XML アプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false)     
      {"outcome" => "success"}
    3. zip 形式のコンテンツの自動デプロイメントを無効化

      write-attribute コマンドを使用して zip 形式のアプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false)
      {"outcome" => "success"}
    4. パス属性の設定

      write-attribute 操作を使用して、パス属性を変更し、例の newpathname 値を監視するデプロイメントスキャナーの新しいパス名に置き換えます。変更を反映するにはサーバーでリロードする必要があります。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname)            
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    5. 相対パス属性の設定

      write-attribute 操作を使用して、設定 XML ファイルのパスセクションで定義されたファイルシステムパスに対する相対参照を変更します。変更を反映するには、サーバーでリロードする必要があります。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
    6. デプロイメントスキャナーの無効化

      write-attribute 操作を使用して、scan-enabled 値を false に設定することにより、デプロイメントスキャナーを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false)        
      {"outcome" => "success"}
    7. スキャン間隔の変更

      write-attribute 操作を使用してスキャン間隔を 5000 ミリ秒から 10000 ミリ秒に変更します。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
結果

設定の変更が、デプロイメントスキャナーに保存されます。

9.5. Maven でのデプロイ

9.5.1. Maven によるアプリケーションデプロイメントの管理

Maven を使用してアプリケーションをデプロイすると、デプロイメントのサイクルを既存の開発ワークフローの一部として取り入れることができます。

9.5.2. Maven によるアプリケーションのデプロイ

概要

このタスクでは、Maven を用いてアプリケーションをデプロイする方法について説明します。ここで使用される例は、JBoss EAP 6 のクイックスタートにある jboss-as-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれています。このプラグインを使用すると、アプリケーションサーバーでアプリケーションを簡単にデプロイおよびアンデプロイできます。

手順9.11 Maven によるアプリケーションのデプロイ

  1. ターミナルウィンドウで Maven デプロイコマンドを実行

    ターミナルセッションを開き、quickstart サンプルが含まれるディレクトリーに移動します。
  2. Maven デプロイコマンドを実行してアプリケーションをデプロイします。アプリケーションがすでに実行されている場合、アプリケーションは再デプロイされます。
    [localhost]$ mvn package jboss-as:deploy
  3. アプリケーションデプロイメントの確認

    • ターミナルウィンドウでの結果の参照

      デプロイメントは、ターミナルウィンドウで操作ログを参照して確認できます。

      例9.5 Maven での helloworld アプリケーションの確認

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 3 seconds
      [INFO] Finished at: Mon Oct 10 17:22:05 EST 2011
      [INFO] Final Memory: 21M/343M
      [INFO] ------------------------------------------------------------------------
      
    • サーバーターミナルウィンドウでの結果の参照

      また、デプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例9.6 アプリケーションサーバーでの helloworld アプリケーションの確認

      17:22:04,922 INFO  [org.jboss.as.server.deployment] (pool-1-thread-3) Content added at location /home/username/EAP_HOME/standalone/data/content/2c/39607b0c8dbc6a36585f72866c1bcfc951f3ff/content
      17:22:04,924 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "jboss-as-helloworld.war"
      17:22:04,954 INFO  [org.jboss.weld] (MSC service thread 1-3) Processing CDI deployment: jboss-as-helloworld.war
      17:22:04,973 INFO  [org.jboss.weld] (MSC service thread 1-2) Starting Services for CDI deployment: jboss-as-helloworld.war
      17:22:04,979 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
      17:22:05,051 INFO  [org.jboss.web] (MSC service thread 1-2) registering web context: /jboss-as-helloworld
      17:22:05,064 INFO  [org.jboss.as.server.controller] (pool-1-thread-3) Deployed "jboss-as-helloworld.war"
結果

アプリケーションが、アプリケーションサーバーにデプロイされます。

9.5.3. Maven によるアプリケーションのアンデプロイ

概要

このタスクでは、Maven を用いてアプリケーションをアンデプロイする方法について説明します。ここで使用される例は、JBoss EAP 6 のクイックスタートにある jboss-as-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれています。このプラグインを使用すると、アプリケーションサーバーでアプリケーションを簡単にデプロイおよびアンデプロイできます。

手順9.12 Maven によるアプリケーションのアンデプロイ

  1. ターミナルウィンドウで Maven デプロイコマンドを実行

    ターミナルセッションを開き、quickstart サンプルが含まれるディレクトリーに移動します。

    例9.7 helloworld アプリケーションディレクトリーへ移動する

    [localhost]$ cd /path/to/EAP_Quickstarts/helloworld
    
  2. Maven アンデプロイコマンドを実行してアプリケーションをアンデプロイします。
    [localhost]$ mvn jboss-as:undeploy
  3. アプリケーションのアンデプロイを確認

    • ターミナルウィンドウでの結果の参照

      アンデプロイメントは、ターミナルウィンドウの操作ログを参照して確認できます。

      例9.8 Maven での helloworld アプリケーションの確認

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] Building JBoss AS Quickstarts: Helloworld
      [INFO]    task-segment: [jboss-as:undeploy]
      [INFO] ------------------------------------------------------------------------
      [INFO] [jboss-as:undeploy {execution: default-cli}]
      [INFO] Executing goal undeploy for /home/username/EAP_Quickstarts/helloworld/target/jboss-as-helloworld.war on server localhost (127.0.0.1) port 9999.
      Oct 10, 2011 5:33:02 PM org.jboss.remoting3.EndpointImpl <clinit>
      INFO: JBoss Remoting version 3.2.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.Xnio <clinit>
      INFO: XNIO Version 3.0.0.Beta2
      Oct 10, 2011 5:33:02 PM org.xnio.nio.NioXnio <clinit>
      INFO: XNIO NIO Implementation Version 3.0.0.Beta2
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011
      [INFO] Final Memory: 11M/212M
      [INFO] ------------------------------------------------------------------------
      
    • サーバーターミナルウィンドウでの結果の参照

      また、アンデプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例9.9 アプリケーションサーバーでの helloworld アプリケーションの確認

           
      17:33:02,334 INFO  [org.jboss.weld] (MSC service thread 1-3) Stopping weld service
      17:33:02,342 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) Stopped deployment jboss-as-helloworld.war in 15ms
      17:33:02,352 INFO  [org.jboss.as.server.controller] (pool-1-thread-5) Undeployed "jboss-as-helloworld.war"
      
結果

アプリケーションが、アプリケーションサーバーからアンデプロイされます。

9.6. JBoss EAP 6 にデプロイされたアプリケーションの順序制御

JBoss EAP 6 では、サーバー起動時にアプリケーションがデプロイされる順序を細かく制御できます。複数の ear ファイルに存在するアプリケーションのデプロイメント順序を徹底することが可能で、再起動後の順序を永続化することも可能です。

手順9.13 EAP 6.0.X におけるデプロイメント順序の制御

  1. サーバーの起動または停止時に、順番にアプリケーションをデプロイおよびアンデプロイする CLI スクリプトを作成します。
  2. CLI はバッチモードの概念をサポートします。バッチモードでは、コマンドや操作をグループ化でき、グループ化したコマンドや操作をアトミックユニットとして一緒に実行できます。1 つ以上のコマンドや操作が失敗すると、正常に実行された他のコマンドや操作はロールバックされます。

手順9.14 EAP 6.1.X におけるデプロイメント順序の制御

Inter Deployment Dependencies (デプロイメント間依存関係) と呼ばれる EAP 6.1.X の新機能を使用すると、トップレベルのデプロイメント間の依存関係を宣言できます。
  1. jboss-all.xml ファイルがない場合は、app.ear/META-INF フォルダーに作成します。app.ear はアプリケーションアーカイブで、このアーカイブの前にデプロイされる他のアプリケーションアーカイブに依存します。
  2. 次のように、このファイルに jboss-deployment-dependencies エントリーを作成します。下記では、framework.ear は依存されるアプリケーションアーカイブで、app.ear アプリケーションアーカイブの前にデプロイする必要があります。
    <jboss umlns="urn:jboss:1.0">
      <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
        <dependency name="framework.ear" />
      </jboss-deployment-dependencies>
    </jboss>

9.7. デプロイメント記述子の上書き

EAP 6.1.x の新機能の 1 つを使用すると、起動時にデプロイメント記述子を上書きできます。デプロイメントオーバーレイ は、アーカイブで上書きされる必要があるファイルのルールセットを表します。また、上書きされるファイルの代わりに使用する必要がある新しいファイルへのリンクも提供します。上書きされたファイルがデプロイメントアーカイブにない場合、デプロイメントへ戻されます。

手順9.15 管理 CLI を使用したデプロイメント記述子の上書き

次の手順は、app.war というデプロイされたアプリケーションが存在し、このアプリケーションの WEB-INF/web.xml ファイルを /home/user/web.xml にある別の web.xml で上書きすることを前提とします。
  1. デプロイメントオーバーレイを追加し、そこにコンテンツを追加します。これを行う方法は 2 つあります。
    • DMR ツリーの使用

      1. /deployment-overlay=myoverlay:add
      2. /deployment-overlay=myoverlay/content=WEB-INF\/web.xml:add(content={url=file:///home/user/web.xml})
        必要な場合は、2 番目のステートメントを使用してコンテンツルールを追加できます。
    • 便利メソッドの使用

      deployment-overlay add --name=myoverlay --content=WEB-INF/web.xml=/home/user/web.xml
  2. オーバーレイをデプロイメントアーカイブへ追加

    • deployment-overlay link --name=myoverlay --deployments=app.war
      複数のアーカイブ名を指定するには、コンマで区切ります。
    • /deployment-overlay=myoverlay/deployment=app.war:add
      この時点では、デプロイメントアーカイブ名がサーバー上に存在する必要がないことに注意してください。ここで名前を指定しますが、まだ実際のデプロイメントへはリンクしません。
  3. アプリケーションの再デプロイ

    /deployment=app.war:redeploy

第10章 JBoss EAP 6 のセキュア化

10.1. セキュリティーサブシステム

セキュリティーサブシステムは、JBoss EAP ですべてのセキュリティー機能のインフラストラクチャーを提供します。設定要素はほとんど変更する必要がありません。変更が必要となる可能性がある唯一の設定要素は、ディープコピーサブジェクトモード を使用するかどうかです。また、システム全体のセキュリティープロパティーを設定できます。ほとんどの設定はセキュリティードメインに関連します。
ディープコピーモード

ディープコピーサブジェクトモードが無効化されている場合 (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体をコピーするのではなく、オリジナルが参照されます。この動作はより効率的ですが、フラッシュまたはログアウトの操作によって同一 ID の複数のスレッドが件名を消去すると、データの破損が発生する傾向にあります。

ディープコピーサブジェクトモードでは、クローン可能と指定されていると、データ構造およびデータ構造に関連するデータの完全コピーが作成されます。このモードはよりスレッドセーフですが、効率は悪くなります。
システム全体のセキュリティープロパティー

java.security.Security クラスに適用するシステム全体のセキュリティプロパティーを設定できます。

セキュリティードメイン

セキュリティードメインとは、認証、承認、監査、およびマッピングを制御するために単一または複数のアプリケーションが使用する Java Authentication and Authorization Service (JAAS) 宣言型セキュリティー設定のセットです。デフォルトでは、jboss-ejb-policyjboss-web-policy、および other の 3 つのセキュリティードメインが含まれています。アプリケーションの必要性に対応するため、セキュリティードメインは必要に応じていくつでも作成できます。

10.2. セキュリティーサブシステムの構造

セキュリティーサブシステムは、管理対象ドメインまたはスタンドアロン設定ファイルに設定されます。設定要素のほとんどは、Web ベースの管理コンソールまたはコンソールベースの管理 CLI を使用して設定することが可能です。以下の XML はセキュリティーサブシステムの例を表しています。

例10.1 セキュリティーサブシステムの設定例

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>		

<security-management><subject-factory>、および <security-properties> 要素はデフォルト設定では存在しません。<subject-factory> および <security-properties> 要素は JBoss EAP 6.1 およびそれ以降のバージョンで廃止になりました。

10.3. セキュリティーサブシステムの設定

セキュリティーサブシステムの設定には、管理 CLI または Web ベースの管理コンソールを使用できます。
セキュリティーサブシステム内の各トップレベル要素には、セキュリティー設定の異なる情報が含まれています。セキュリティーサブシステムの設定例は 「セキュリティーサブシステムの構造」 を参照してください。
<security-management>
このセクションはセキュリティーサブシステムのハイレベルの挙動を上書きします。各設定は任意です。ディープコピーサブジェクトモード以外で、これらの設定を変更することはほとんどありません。
オプション 説明
deep-copy-subject-mode
スレッドの安全性を高めるため、セキュリティートークンへコピーまたはリンクするかどうかを指定します。
authentication-manager-class-name
使用する代替の AuthenticationManager 実装クラス名を指定します。
authorization-manager-class-name
使用する代替の AuthorizationManager 実装クラス名を指定します。
audit-manager-class-name
使用する代替の AuditManager 実装クラス名を指定します。
identity-trust-manager-class-name
使用する代替の IdentityTrustManager 実装クラス名を指定します。
mapping-manager-class-name
使用する MappingManager 実装クラス名を指定します。
<subject-factory>
サブジェクトファクトリーはサブジェクトインスタンスの作成を制御します。呼び出し元を検証するため、認証マネージャーを使用することがあります。サブジェクトファクトリーは、主に JCA コンポーネントがサブジェクトを確立するために使用されます。サブジェクトファクトリーを変更する必要はあまりありません。
<security-domains>
複数のセキュリティードメインを保持するコンテナ要素です。セキュリティードメインには認証、承認、マッピング、監査モジュール、JASPI 認証、および JSSE 設定の情報が含まれることがあります。アプリケーションはセキュリティードメインを指定してセキュリティー情報を管理します。
<security-properties>
java.security.Security クラスに設定されるプロパティーの名前と値が含まれます。

10.4. ディープコピーサブジェクトモード

ディープコピーサブジェクトモード が無効であるときに (デフォルト)、セキュリティーデータ構造をコピーすると、データ構造全体がコピーされずに、元のデータ構造への参照が作成されます。この挙動は効率的ですが、同一 ID の複数のスレッドがフラッシュまたはログアウトの操作によってサブジェクトを消去すると、データが破損しやすくなります。
ディープコピーサブジェクトモードでは、クローン可能と指定されていると、データ構造およびデータ構造に関連するデータの完全コピーが作成されます。このモードはよりスレッドセーフですが、効率は悪くなります。
ディープコピーサブジェクトモードは、セキュリティーサブシステムの一部として設定されます。

10.5. ディープコピーサブジェクトモードの有効化

Web ベースの管理コンソールまたは管理 CLI より、ディープコピーセキュリティーモードを有効にできます。

手順10.1 管理コンソールからディープコピーセキュリティーモードを有効化

  1. 管理コンソールにログインします。

    通常、管理コンソールは http://127.0.0.1:9990/ のような URL で使用できます。環境に合わせて適切な URL を使用してください。
  2. 管理対象ドメイン: 適切なプロファイルを選択します。

    管理対象ドメインではプロファイルごとにセキュリティーサブシステムが設定されているため、各プロファイルに対して個別にディープコピーセキュリティーモードを有効または無効にできます。
    プロファイルを選択するには、コンソール表示の右上にある Profiles ラベルをクリックし、左上にある Profiles 選択ボックスより変更したいプロファイルを選択します。
  3. Security Subsystem 設定メニューを開きます。

    管理コンソールの右にある Security メニュー項目を展開し、Security Subsystem リンクをクリックします。
  4. deep-copy-subject-mode の値を変更します。

    Edit ボタンをクリックします。Deep Copy Subjects: の横にあるボックスにチェックを入れ、ディープコピーサブジェクトモードを有効にします。
管理 CLI を使用したディープコピーサブジェクトモードの有効化

管理 CLI を使用してこのオプションを有効にしたい場合、以下のコマンドの 1 つを使用します。

例10.2 管理対象ドメイン

/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

例10.3 スタンドアロンサーバー

/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

10.6. セキュリティードメイン

10.6.1. セキュリティードメイン

セキュリティードメインは JBoss EAP 6 のセキュリティーサブシステムの一部になります。すべてのセキュリティー設定は、管理対象ドメインのドメインコントローラーまたはスタンドアローンサーバーによって集中管理されるようになりました。
セキュリティードメインは認証、承認、セキュリティーマッピング、監査の設定によって構成されます。セキュリティードメインは Java Authentication and Authorization Service (JAAS) の宣言的セキュリティーを実装します。
認証とはユーザーアイデンティティーを検証することを言います。セキュリティー用語では、このユーザーをプリンシパルと呼びます。認証と承認は異なりますが、含まれている認証モジュールの多くは承認の処理も行います。
承認は、システムまたは操作の特定の特権またはリソースへアクセスできるパーミッションを認証されたユーザーが持っているかどうかをサーバーが判断するセキュリティーポリシーです。セキュリティー用語では、ロールとも呼ばれます。
セキュリティーマッピングとは、情報をアプリケーションに渡す前にプリンシパル、ロール、または属性から情報を追加、編集、削除する機能のことです。
監査マネージャーは、プロバイダーモジュールを設定して、セキュリティーイベントの報告方法を制御できるようにします。
セキュリティードメインを使用する場合、アプリケーション自体から特定のセキュリティー設定をすべて削除することが可能です。これにより、一元的にセキュリティーパラメーターを変更できるようにします。このような設定構造が有効な一般的な例には、アプリケーションをテスト環境と実稼動環境間で移動するプロセスがあります。

10.6.2. Picketbox

Picketbox は、認証、許可、監査、およびマッピング機能を、JBoss EAP 6 で実行されている Java アプリケーションに提供する基礎的なセキュリティーフレームワークです。単一構成の単一フレームワークで、次の機能を提供します。

10.6.3. 認証

認証とは、サブジェクトを識別し、身分が本物であるかを検証することを言います。最も一般的な認証メカニズムはユーザー名とパスワードの組み合わせです。その他の一般的な認証メカニズムは共有キー、スマートカード、または指紋などを使用します。Java Enterprise Edition の宣言的セキュリティーでは、成功した認証の結果のことをプリンシパルと呼びます。
JBoss EAP 6 は認証モジュールのプラグ可能なシステムを使用して、組織ですでに使用されている認証システムへ柔軟に対応し、統合を実現します。各セキュリティードメインには 1 つ以上の設定された認証モジュールが含まれます。各モジュールには、挙動をカスタマイズするための追加の設定パラメーターが含まれています。Web ベースの管理コンソール内に認証サブシステムを設定するのが最も簡単な方法です。
認証と承認が関連している場合も多くありますが、認証と承認は同じではありません。含まれている多くの認証モジュールは承認も処理します。

10.6.4. セキュリティードメインでの認証の設定

セキュリティードメインの認証を設定するには、管理コンソールにログインして以下の手順を実行します。

手順10.2 セキュリティードメインの認証設定

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 認証サブシステム設定に移動します。

    ビューの最上部の Authentication ラベルをクリックします (選択済みでない場合)。
    設定領域が Login ModulesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数のログインモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. 認証モジュールを追加します。

    Add ボタンをクリックして JAAS 認証モジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の認証モジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、このドキュメントを参照してください。

    フラグ 詳細
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み認証が続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み認証が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。
    sufficient
    LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、認証が続行されません)。失敗すると、LoginModule リストの下方向に進み認証が続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストの下方向に進み認証が続行されます。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を指定します。Remove ボタンを使用してオプションを削除します。
結果

認証モジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

jboss.security.security_domain モジュールのオプション

デフォルトでは、セキュリティードメインに定義された各ログインモジュールには jboss.security.security_domain モジュールオプションが自動的に追加されます。既知のオプションのみが定義されるようチェックを行うログインモジュールでは、このオプションが問題が発生する原因となります。このようなログインモジュールの 1 つが IBM Kerberos ログインモジュールの com.ibm.security.auth.module.Krb5LoginModule です。

このモジュールオプションを追加する挙動を無効にするには、JBoss EAP 6 の起動時にシステムプロパティーを true に設定します。以下を起動パラメーターに追加します。
-Djboss.security.disable.secdomain.option=true
Web ベースの管理コンソールを使用してこのプロパティーを設定することも可能です。スタンドアロンサーバーでは、システムプロパティーを設定の Profile セクションに設定できます。管理対象ドメインでは、各サーバーグループのシステムプロパティーを設定できます。

10.6.5. 承認

承認とはアイデンティティーを基にリソースへのアクセスを許可または拒否するメカニズムのことです。プリンシパルに提供できる宣言的セキュリティーロールのセットとして実装されます。
JBoss EAP 6 はモジュラーシステムを使用して承認を設定します。各セキュリティードメインに 1 つ以上の承認ポリシーが含まれるようにすることができます。各ポリシーには動作を定義する基本モジュールがあり、特定のフラグや属性より設定されます。Web ベースの管理コンソールを使用すると承認サブシステムを最も簡単に設定できます。
承認は認証とは異なり、通常は認証後に承認が行われます。認証モジュールの多くは承認も処理します。

10.6.6. セキュリティードメインにおける承認の設定

セキュリティードメインの承認を設定するには、管理コンソールにログインして以下の手順を実行します。

手順10.3 セキュリティードメインの承認設定

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。管理対象ドメインで、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 承認サブシステム設定に移動します。

    ビューの最上部にある Authorization ラベルをクリックします (選択済みでない場合)。
    設定領域が PoliciesDetails の 2 つの領域に分割されます。ログインモジュールは、設定の基本単位です。セキュリティードメインには複数の承認ポリシーを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. ポリシーを追加します。

    Add ボタンをクリックして JAAS 承認ポリシーモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Flags は、モジュールが同じセキュリティードメイン内で他の承認ポリシーモジュールにどのように関係するかを制御します。
    フラグの説明

    Java Enterprise Edition 6 の仕様では、セキュリティーモジュールの次の説明が提供されます。次のリストは、http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixA に記載されています。詳細については、このドキュメントを参照してください。

    フラグ 詳細
    required
    LoginModule は成功する必要があります。成功または失敗すると、LoginModule リストを下方向に進み承認が続行されます。
    requisite
    LoginModule は成功する必要があります。成功すると、LoginModule リストの下方向に進み承認が続行されます。失敗すると、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。
    sufficient
    LoginModule は成功する必要はありません。成功した場合は、即座に制御がアプリケーションに戻されます (LoginModule リストの下方向に進まず、承認が続行されません)。失敗すると、LoginModule リストの下方向に進み承認が続行されます。
    optional
    LoginModule は成功する必要がありません。成功または失敗した場合、LoginModule リストを下方向に進み承認が続行されます。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Flags を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Login Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、キーをクリックするか、変更します。Remove ボタンを使用してオプションを削除します。
結果

承認ポリシーモジュールが、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

10.6.7. セキュリティー監査

セキュリティー監査とは、セキュリティーサブシステム内で発生したイベントに応答するため、ログへの書き込みなどのイベントをトリガーすることです。監査のメカニズムは、認証、承認、およびセキュリティーマッピングの詳細と共に、セキュリティードメインの一部として設定されます。
監査にはプロバイダーモジュールが使用されます。含まれているプロバイダーモジュールを使用するか、独自のモジュールを実装することができます。

10.6.8. セキュリティー監査の設定

セキュリティードメインのセキュリティー監査を設定するには、管理コンソールにログインして以下の手順を実行します。

手順10.4 セキュリティードメインのセキュリティー監査の設定

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。スタンドアロンサーバーでは、タブに Profile ラベルがあります。管理対象ドメインでは、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. 監査サブシステム設定に移動します。

    ビューの最上部の Audit ラベルをクリックします (選択済みでない場合)。
    設定領域が Provider ModulesDetails の 2 つの領域に分割されます。プロバイダーモジュールは、設定の基本単位です。セキュリティードメインには複数のプロバイダーモジュールを含めることができ、各ログインモジュールには属性とオプションを含めることができます。
  3. プロバイダーモジュールを追加します。

    Add ボタンをクリックしてプロアクティブモジュールを追加します。Code セクションに、プロバイダーモジュールのクラス名を入力します。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールの挙動を確認します。

    監査モジュールの目的は、セキュリティーサブシステムのイベントを監視する方法を提供することです。ログファイルの記述、メールによる通知、またはその他の監査メカニズムによって監視を行うことが可能です。
    たとえば、JBoss EAP 6 にはデフォルトで LogAuditProvider モジュールが含まれています。この監査モジュールを前述の手順に従って有効にすると、EAP_HOME ディレクトリー内の log サブフォルダーにある audit.log ファイルにセキュリティー通知を書き込みます。
    前述の手順が LogAuditProvider のコンテキスト内で動作するかを確認するには、通知が発生するようなアクションを実行した後、監査ログファイルをチェックします。
    含まれるセキュリティー監査プロバイダーモジュールの完全一覧は 「含まれるセキュリティー監査プロバイダーモジュール」 を参照してください。
  5. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルをクリックして削除するか、Add ボタンをクリックして正しいオプションで再び追加します。
結果

セキュリティー監査モジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

10.6.9. セキュリティーマッピング

セキュリティーマッピングを使用すると、認証または承認が実行された後、情報がアプリケーションに渡される前に認証情報と承認情報を組み合わせることができます。この例の 1 つが、認証に X509 証明書を使用した後、証明書のプリンシパルをアプリケーションが表示できる論理名へ変換することです。
プリンシパル (認証)、ロール (承認)、またはクレデンシャル (プリンシパルやロールでない属性) をマッピングすることが可能です。
ロールマッピングは、認証後にサブジェクトへロールを追加、置換、または削除するために使用されます。
プリンシパルマッピングは、認証後にプリンシパルを変更するために使用されます。
属性マッピングは、外部システムからの属性値をアプリケーションで使用するために変換したり、逆にそのような外部システムへ属性を変換したりするために使用されます。

10.6.10. セキュリティードメインでのセキュリティーマッピングの設定

セキュリティードメインのセキュリティーマッピングを設定するには、管理コンソールにログインして以下の手順を実行します。

手順10.5 セキュリティードメインでのセキュリティーマッピングの設定

  1. セキュリティードメインの詳細ビューを開きます。

    管理コンソールの右上にある Profiles ラベルをクリックします。スタンドアロンサーバーでは、タブに Profile ラベルがあります。管理対象ドメインでは、Profile ビューの左上にある Profile 選択ボックスから変更するプロファイルを選択します。左側の Security メニュー項目をクリックし、展開されたメニューで Security Domains をクリックします。編集するセキュリティードメインの View リンクをクリックします。
  2. マッピングサブシステム設定に移動します。

    ビューの最上部の Mapping ラベルをクリックします (選択済みでない場合)。
    設定領域が ModulesDetails の 2 つの領域に分割されます。マッピングモジュールは、設定の基本単位です。セキュリティードメインには複数のマッピングモジュールを含めることができ、各ログインモジュールには複数の属性とオプションを含めることができます。
  3. モジュールを追加します。

    Add ボタンをクリックしてセキュリティーマッピングモジュールを追加します。モジュールの詳細を記入します。Code がモジュールのクラス名です。Type フィールドは、このモジュールが実行するマッピングのタイプを示します。許可される値は principal、role、attribute、または credential です。
    モジュールを追加したら、画面の Details セクションで Edit をクリックすることにより、Code または Type を変更できます。Attributes タブが選択されていることを確認します。
  4. モジュールオプションを追加、編集、または削除します (任意)。

    モジュールにオプションを追加する必要がある場合は、Modules リストのエントリーをクリックし、ページの Details セクションの Module Options タブを選択します。Add ボタンをクリックし、オプションのキーと値を提供します。すでに存在するオプションを編集するには、Remove ラベルキーをクリックして削除するか、新しい値で再び追加します。Remove ボタンを使用してオプションを削除します。
結果

セキュリティーマッピングモジュールは、セキュリティードメインに追加され、セキュリティードメインを使用するアプリケーションですぐに利用できます。

10.6.11. アプリケーションでのセキュリティードメインの使用

概要

アプリケーションでセキュリティードメインを使用するには、最初にサーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかにドメインを設定する必要があります。その後、使用する EJB に必要なアノテーションを追加する必要があります。ここでは、アプリケーションでセキュリティードメインを使用するために必要な手順について取り上げます。

警告

アプリケーションが、認証キャッシュを使用するセキュリティードメインの一部である場合、セキュリティードメインの他のアプリケーションもそのアプリケーションのユーザー認証を使用できます。

手順10.6 セキュリティードメインを使用するようアプリケーションを設定

  1. セキュリティードメインの定義

    セキュリティードメインは、サーバーの設定ファイルまたはアプリケーションの記述子ファイルのいずれかに定義できます。
    • サーバーの設定ファイルへセキュリティードメインを設定

      セキュリティードメインは、サーバーの設定ファイルの security サブシステムに設定されます。JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合、domain/configuration/domain.xml ファイルになります。JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合は standalone/configuration/standalone.xml ファイルになります。
      otherjboss-web-policy、および jboss-ejb-policy セキュリティードメインはデフォルトとして JBoss EAP 6 に提供されます。次の XML の例は、サーバーの設定ファイルの security サブシステムよりコピーされました。
      <subsystem xmlns="urn:jboss:domain:security:1.2">
          <security-domains>
              <security-domain name="other" cache-type="default">
                  <authentication>
                      <login-module code="Remoting" flag="optional">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                      <login-module code="RealmDirect" flag="required">
                          <module-option name="password-stacking" value="useFirstPass"/>
                      </login-module>
                  </authentication>
              </security-domain>
              <security-domain name="jboss-web-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
              <security-domain name="jboss-ejb-policy" cache-type="default">
                  <authorization>
                      <policy-module code="Delegating" flag="required"/>
                  </authorization>
              </security-domain>
          </security-domains>
      </subsystem>
      管理コンソールまたは CLI を使用して、追加のセキュリティードメインを必要に応じて設定できます。
    • アプリケーションの記述子ファイルにセキュリティードメインを設定

      セキュリティードメインはアプリケーションの WEB-INF/web.xml ファイルにある <jboss-web> 要素の <security-domain> 子要素に指定されます。次の例は my-domain という名前のセキュリティードメインを設定します。
      <jboss-web>
          <security-domain>my-domain</security-domain>
      </jboss-web>
      これが WEB-INF/jboss-web.xml 記述子に指定できる多くの設定の 1 つになります。
  2. EJB への必要なアノテーションの追加

    @SecurityDomain および @RolesAllowed アノテーションを使用してセキュリティーを EJB に設定します。次の EJB コードの例は、guest ロールのユーザーによる other セキュリティードメインへのアクセスを制限します。
    package example.ejb3;
    
    import java.security.Principal;
    
    import javax.annotation.Resource;
    import javax.annotation.security.RolesAllowed;
    import javax.ejb.SessionContext;
    import javax.ejb.Stateless;
    
    import org.jboss.ejb3.annotation.SecurityDomain;
    
    /**
     * Simple secured EJB using EJB security annotations
     * Allow access to "other" security domain by users in a "guest" role.
     */
    @Stateless
    @RolesAllowed({ "guest" })
    @SecurityDomain("other")
    public class SecuredEJB {
    
       // Inject the Session Context
       @Resource
       private SessionContext ctx;
    
       /**
        * Secured EJB method using security annotations
        */
       public String getSecurityInfo() {
          // Session context injected using the resource annotation
          Principal principal = ctx.getCallerPrincipal();
          return principal.toString();
       }
    }
    その他のコード例は、Red Hat カスタマーポータルより入手できる JBoss EAP 6 Quickstarts バンドルの ejb-security クイックスタートを参照してください。

10.6.12. JACC (Java Authorization Contract for Containers)

10.6.12.1. JACC (Java Authorization Contract for Containers)

JACC (Java Authorization Contract for Containers) はコンテナと承認サービスプロバイダー間のインターフェースを定義する規格で、これによりコンテナによって使用されるプロバイダーの実装が可能になります。JACC は JSR-115 に定義されており、http://jcp.org/en/jsr/detail?id=115 の Java Community Process Web サイトで確認できます。Java EE バージョン 1.3 より、コアの Java Enterprise Edition (Java EE) 仕様の一部となっています。
JBoss EAP 6 はセキュリティーサブシステムのセキュリティー機能内に JACC のサポートを実装します。

10.6.12.2. JACC (Java Authorization Contract for Containers) のセキュリティーの設定

JACC (Java Authorization Contract for Containers) を設定するには、適切なモジュールでセキュリティードメインを設定し、適切なパラメーターが含まれるよう jboss-web.xml を編集する必要があります。
セキュリティードメインへの JACC サポートの追加

セキュリティードメインに JACC サポートを追加するには、required フラグセットで JACC 承認ポリシーをセキュリティードメインの承認スタックへ追加します。以下は JACC サポートを持つセキュリティードメインの例になりますが、セキュリティードメインは 直接 XML には設定されず、管理コンソールまたは管理 CLI で設定されます。

<security-domain name="jacc" cache-type="default">
    <authentication>
        <login-module code="UsersRoles" flag="required">
        </login-module>
    </authentication>
    <authorization>
        <policy-module code="JACC" flag="required"/>
    </authorization>
</security-domain>
JACC を使用するよう Web アプリケーションを設定

jboss-web.xml は デプロイメントの META-INF/ または WEB-INF/ ディレクトリーに存在し、Web コンテナに対する追加の JBoss 固有の設定を格納し、上書きします。JACC が有効になっているセキュリティードメインを使用するには、<security-domain> 要素が含まれるようにし、 さらに <use-jboss-authorization> 要素を true に設定する必要があります。以下は、上記の JACC セキュリティードメインを使用するよう適切に設定されているアプリケーションになります。

<jboss-web>
    <security-domain>jacc</security-domain>
    <use-jboss-authorization>true</use-jboss-authorization>
</jboss-web>
JACC を使用するよう EJB アプリケーションを設定

セキュリティードメインと JACC を使用するよう EJB を設定する方法は Web アプリケーションの場合とは異なります。EJB の場合、ejb-jar.xml 記述子にてメソッドまたはメソッドのグループ上でメソッドパーミッションを宣言できます。<ejb-jar> 要素内では、すべての子 <method-permission> 要素に JACC ロールに関する情報が含まれます。詳細は設定例を参照してください。EJBMethodPermission クラスは Java Enterprise Edition 6 API の一部で、http://docs.oracle.com/javaee/6/api/javax/security/jacc/EJBMethodPermission.html で説明されています。

例10.4 EJB の JACC メソッドパーミッション例

<ejb-jar>
  <method-permission>
    <description>The employee and temp-employee roles may access any method of the EmployeeService bean </description>
    <role-name>employee</role-name>
    <role-name>temp-employee</role-name>
    <method>
      <ejb-name>EmployeeService</ejb-name>
      <method-name>*</method-name>
    </method>
  </method-permission>
</ejb-jar>

Web アプリケーションと同様にセキュリティードメインを使用して EJB の認証および承認メカニズムを指定することも可能です。セキュリティードメインは <security> 子要素の jboss-ejb3.xml 記述子に宣言されます。セキュリティードメインの他に、EJB が実行されるプリンシパルを変更する run-as プリンシパル を指定することもできます。

例10.5 EJB におけるセキュリティードメイン宣言の例


<security>
  <ejb-name>*</ejb-name>
  <security-domain>myDomain</security-domain>
  <run-as-principal>myPrincipal</run-as-principal>
</security>

10.6.13. JASPI (Java Authentication SPI for Containers)

10.6.13.1. JASPI (Java Authentication SPI for Containers) のセキュリティー

Java Application SPI for Containers (JASPI または JASPIC) は Java アプリケーションのプラグ可能なインターフェースです。Java Community Process の JSR-196 に定義されています。この仕様の詳細は http://www.jcp.org/en/jsr/detail?id=196 を参照してください。

10.6.13.2. JASPI (Java Authentication SPI for Containers) のセキュリティーの設定

JASPI プロバイダーに対して認証するには、<authentication-jaspi> 要素をセキュリティードメインに追加します。設定は標準的な認証モジュールと似ていますが、ログインモジュール要素は <login-module-stack> 要素で囲まれています。設定の構成は次のとおりです。

例10.6 authentication-jaspi 要素の構成

<authentication-jaspi>
	<login-module-stack name="...">
	  <login-module code="..." flag="...">
	    <module-option name="..." value="..."/>
	  </login-module>
	</login-module-stack>
	<auth-module code="..." login-module-stack-ref="...">
	  <module-option name="..." value="..."/>
	</auth-module>
</authentication-jaspi>

ログインモジュール自体は標準的な認証モジュールと全く同じように設定されます。
Web ベースの管理コンソールは JASPI 認証モジュールの設定を公開しないため、JBoss EAP 6 を完全に停止してから、設定を EAP_HOME/domain/configuration/domain.xml または EAP_HOME/standalone/configuration/standalone.xml へ直接追加する必要があります。

10.7. 管理インターフェースセキュリティー

10.7.1. デフォルトのユーザーセキュリティー設定

はじめに

JBoss EAP 6 のすべての管理インターフェースはデフォルトで保護されます。このセキュリティーには、2 つの形式があります。

  • ローカルインターフェースは、ローカルクライアントとローカルクライアントが接続するサーバーとの間の SASL コントラクトによって保護されます。このセキュリティーメカニズムは、ローカルファイルシステムにアクセスするクライアントの機能に基づきます。ローカルシステムへアクセスできるとクライアントによるユーザーの追加が可能で、他のセキュリティーメカニズムを無効にするよう設定を変更できるからです。これにより、ファイルシステムへ物理的にアクセスできると、他のセキュリティーメカニズムが不要になるという原則が厳守されます。このメカニズムは 4 つの手順で実現されます。

    注記

    HTTP を使用してローカルホストへ接続する場合でも、HTTP のアクセスはリモートと見なされます。
    1. ローカル SASL メカニズムを用いて認証する要求が含まれるメッセージをクライアントがサーバーに送信します。
    2. サーバーはワンタイムトークンを生成し、固有のファイルに書き込み、ファイルのフルパスが含まれるメッセージをクライアントへ送信します。
    3. クライアントはファイルよりトークンを読み取り、サーバーへ送信し、ファイルシステムへローカルアクセスできるかを検証します。
    4. サーバーはトークンを検証し、ファイルを削除します。
  • ローカル HTTP クライアントを含むリモートクライアントはレルムベースのセキュリティーを使用します。管理インターフェースを使用して JBoss EAP 6 をリモートで設定するパーミッションを持つデフォルトのレルムは ManagementRealm です。このレルム (またはユーザーが作成したレルム) にユーザーを追加できるスクリプトが提供されます。ユーザーごとに、ユーザー名、ハッシュ化されたパスワード、およびレルムがファイルに格納されます。
    管理対象ドメイン
    EAP_HOME/domain/configuration/mgmt-users.properties
    スタンドアロンサーバー
    EAP_HOME/standalone/configuration/mgmt-users.properties
    mgmt-users.properties の内容はマスクされていますが、機密ファイルとして扱う必要があります。ファイルモードを、ファイル所有者による読み書きのみが許可される 600 に設定することが推奨されます。

10.7.2. 管理インターフェースの詳細設定の概要

EAP_HOME/domain/configuration/host.xml または EAP_HOME/standalone/configuration/standalone.xml の管理インターフェース設定は、ホストコントローラープロセスのバインド先となるネットワークインターフェース、利用可能な管理インターフェースのタイプ、各インターフェースでユーザー認証に使用する認証システムのタイプを制御します。本トピックでは、ご使用の環境に合わせて管理インターフェースを設定する方法について説明します。
管理サブシステムは、複数の設定可能な属性が含まれる <management> 要素と、以下の 3 つの設定可能な子要素で構成されます。セキュリティーレルムと送信接続はそれぞれ最初に定義されてから、管理インターフェースに属性として適用されます。
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
セキュリティーレルム

セキュリティーレルムは、管理 API、管理 CLI、または Web ベースの管理コンソールを介して JBoss EAP 6 の管理を許可されているユーザーの認証と認証を行います。

デフォルトのインストールに含まれる 2 つの異なるファイルベースのセキュリティーレルムは ManagementRealmApplicationRealm です。これらのセキュリティーレルムはそれぞれ -users.properties ファイルを使用してユーザーおよびハッシュ化されたパスワードを保存し、-roles.properties を使用してユーザーとロール間のマッピングを保存します。サポートは LDAP 対応のセキュリティーレルムにも含まれています

注記

独自のアプリケーションにセキュリティーレルムを使用することも可能です。このトピックで説明するセキュリティーレルムは管理インターフェース固有のものです。
送信接続

一部のセキュリティーレルムは、LDAP サーバーなどの外部インターフェースに接続します。送信接続は、この接続の確立方法を定義します。 事前に定義された接続タイプ ldap-connection は、LDAP サーバーに接続して資格情報を検証するための必須およびオプションの属性をすべて設定します。

管理インターフェース

管理インターフェースには、JBoss EAP の接続および設定方法に関するプロパティーが含まれています。この情報には、名前付きのネットワークインターフェース、ポート、セキュリティーレルム、およびインターフェースに関するその他の設定可能な情報が含まれます。デフォルトのインストールには 2 つのインターフェースが含まれています。

  • http-interface は Web ベースの管理コンソールの設定です。
  • native-interface はコマンドライン管理 CLI および REST ライクな管理 API の設定です。
ホスト管理サブシステムの 3 つの主要な設定可能要素はそれぞれ相関しています。セキュリティーレルムは送信接続を参照し、管理インターフェースはセキュリティーレルムを参照します。
関連情報は 「管理インターフェースのセキュア化」 を参照してください。

10.7.3. LDAP

LDAP (Lightweight Directory Access Protocol) はディレクトリーの情報をネットワーク全体で保存し分散するプロトコルです。ディレクトリーの情報にはユーザー、ハードウェアデバイス、アクセスロール、制限などの情報が含まれます。
LDAP の一般的な実装には OpenLDAP、Microsoft Active Directory、IBM Tivoli Directory Server、Oracle Internet Directory などがあります。
JBoss EAP 6 には、Web アプリケーションや EJB アプリケーションの認証承認権限として LDAP サーバーを使用できるようにする複数の認証および承認モジュールがあります。

10.7.4. 管理インターフェースに対する LDAP を使用した認証

管理コンソール、管理 CLI、管理 API の認証ソースとして LDAP ディレクトリーサーバーを使用するには、以下の手順を実行する必要があります。
  1. LDAP サーバーへの送信接続を作成します。
  2. LDAP 対応のセキュリティーレルムを作成します。
  3. 管理インターフェースの新規セキュリティードメインを参照します。
LDAP サーバーへの送信接続の作成

LDAP 送信接続には、以下の属性を使用することができます。

表10.1 LDAP 送信接続の属性

属性 必要性 説明
url 必要
ディレクトリーサーバーの URL アドレス。
search-dn 必要
検索の実行を許可されているユーザーの完全識別名 (DN)
search-credentials 必要
検索の実行を許可されているユーザーのパスワード。
initial-context-factory 不要
接続を確立する際に使用する初期コンテキストファクトリー。デフォルトでは com.sun.jndi.ldap.LdapCtxFactory に設定されています。
security-realm 不要
接続を確立するときに、使用する設定済みの SSLContext を取得するために参照するセキュリティーレルム。

例10.7 LDAP 送信接続の追加

この例では、以下のプロパティーセットを使用して送信接続を追加します。
  • DN の検索: cn=search,dc=acme,dc=com
  • 証明情報の検索: myPass
  • URL: ldap://127.0.0.1:389
最初のコマンドによってセキュリティーレルムが追加されます。
/host=master/core-service=management/security-realm=ldap_security_realm:add
2 つ目のコマンドによって、LDAP 接続が追加されます。
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")
LDAP 対応セキュリティーレルムの作成

管理インターフェースは、デフォルトで設定されているプロパティーファイルをベースとするセキュリティーレルムの代わりに LDAP サーバーに対して認証を行うことができます。LDAP のオーセンティケーターは、最初にリモートディレクトリーサーバーへの接続を確立します。次に、LDAP レコードの完全修飾識別名 (DN) を探すため、ユーザーが認証システムに渡したユーザー名を使用して検索を実行します。クレデンシャルとしてユーザーの DN とユーザー提供のパスワードを使用して、新規接続が確立されます。 この LDAP サーバーに対するこの検証に成功すると、DN が有効であることが検証されます。

LDAP のセキュリティーレルムが機能するには、以下の属性と要素が必要です。
connection
<outbound-connections> に定義されている接続の名前。LDAP ディレクトリーへの接続に使用します。
base-dn
ユーザー検索を開始するためのコンテキストの識別名
recursive
LDAP ディレクトリーツリー全体にわたって再帰的に検索を行うか、指定のコンテキストのみを検索するかを指定します。デフォルトでは false に設定されています。
user-dn
識別名を保持するユーザーの属性。これは、後で認証のテストに使用されます。デフォルトでは dn に設定されています。
子要素として username-filter または advanced-filter のいずれか
username-filterattribute という単一の属性を取り、値は userNamesambaAccountName などのユーザー名を持つ LDAP 属性の名前です。
advanced-filterfilter と呼ばれる単一の属性を取ります。この属性には、標準的な LDAP 構文のフィルタークエリが含まれています。& 文字を &amp; に変更し、エスケープすることに注意してください。フィルターの例は次のとおりです。
(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
アンパサンド文字をエスケープすると、フィルターは次のようになります。
(&amp;(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))

例10.8 LDAP 対応のセキュリティーレルムを示す XML

この例には、以下のパラメーターを使用します。
  • connection - ldap_connection
  • base-dn - cn=users,dc=acme,dc=com.
  • username-filter - attribute="sambaAccountName"
<security-realm name="ldap_security_realm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
         <username-filter attribute="sambaAccountName" />
      </ldap>
  </authentication>
</security-realm>	

警告

空の LDAP パスワードを許可しないようにすることが重要になります。ご使用の環境で具体的に空の LDAP パスワードを許可したい場合を除き、深刻なセキュリティー上の問題となります。
EAP 6.1 には CVE-2012-5629 のパッチが含まれています。このパッチは、LDAP ログインモジュールの allowEmptyPasswords オプションが設定されていない場合にこのオプションを False に設定します。6.1 以前のバージョンでは、このオプションを手作業で設定する必要があります。

例10.9 LDAP セキュリティーレルムの追加

次のコマンドはセキュリティーレルムを追加し、スタンドアロンサーバーの属性を設定します。
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
管理インターフェースへの新規セキュリティーレルムの適用

セキュリティーレルムの作成が完了したら、管理インターフェースの設定でそのドメインを参照する必要があります。管理インターフェースは、HTTP ダイジェスト認証用のセキュリティーレルムを使用します。

例10.10 HTTP インターフェースへのセキュリティーレルムの適用

この設定が有効になり、ホストコントローラーを再起動した後、Web ベースの管理コンソールは LDAP を使用してユーザーの認証を行います。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap-security-realm)
Microsoft Active Directory を使用して認証する管理対象ドメインメンバーを設定

管理対象ドメイン内のホストを設定して、Microsoft Active Directory に対して認証を行うには、次の手順に従います。この手順では JAAS 認証を使用し、セキュリティードメインを作成して、ロールを Active Directory グループへマップします。Microsoft Active Directory では空のパスワードでバインディングできるため、この作業が必要になります。これにより、アプリケーションプラットフォーム内で空のパスワードが使用されないようにします。

この手順を実行する前に、ホストコントローラーの名前を確認する必要があります。この例では、ホストコントローラーの名前が master であることを仮定します。
  1. ldap_security_realm という名前の新しい <security-realm> を追加し、JAAS を使用するように設定します。

    以下の管理 CLI コマンドは、新しいセキュリティーレルムを追加し、認証メカニズムを設定します。必要な場合はホスト名を変更してください。
    /host=master/core-service=management/security-realm=ldap_security_realm/:add
    /host=master/core-service=management/security-realm=ldap_security_realm/authentication=jaas/:add(name=managementLDAPDomain)
  2. 新しいセキュリティーレルムを使用するように <http-interface> を設定します。

    以下の管理 CLI コマンドは HTTP インターフェースを設定します。
    /host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)
  3. JBoss EAP を設定し、カスタム JAAS 設定を起動パラメーターに追加します。

    EAP_HOME/bin/domain.conf ファイルを編集します。HOST_CONTROLLER_JAVA_OPTS 変数を探します。ここに、JBoss EAP が起動する前に必要となる JVM のディレクティブを追加します。以下に、このパラメーターのデフォルトコンテンツの例を示します。
    HOST_CONTROLLER_JAVA_OPTS="$JAVA_OPTS"
    
    以下のディレクティブを -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf" に追加します。
    編集後、この行は次のようになります。
    -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf"
    
  4. ログインモジュールをモジュールオプションに追加します。

    同じファイル内で、以下が含まれる行を見つけます。
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
    その行を次のように変更します。余分な空白を挿入しないようにしてください。
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,com.sun.security.auth.login"
    domain.conf ファイルを保存し、閉じます。
  5. クラスパスに追加される JAAS 設定を作成します。

    新しいファイルを EAP_HOME/domain/configuration/jaas.conf に作成します。
    このファイルには以下の内容が含まれている必要があります。環境に合わせてパラメーターを編集します。
    managementLDAPDomain {
        org.jboss.security.auth.spi.LdapExtLoginModule required
            java.naming.factory.initial="com.sun.jndi.ldap.LdapCtxFactory"
            java.naming.provider.url="ldap://your_active_directory_host:389"
            java.naming.security.authentication="simple"
            bindDN="cn=Administrator,cn=users,dc=domain,dc=your_company,dc=com"
            bindCredential="password"
            baseCtxDN="cn=users,dc=domain,dc=redhat,dc=com"
            baseFilter="(&(sAMAccountName={0})(|(memberOf=cn=Domain Guests,cn=Users,dc=domain,dc=acme,dc=com)(memberOf=cn=Domain Admins,cn=Users,dc=domain,dc=acme,dc=com)))"
            allowEmptyPasswords="false"
            rolesCtxDN="cn=users,dc=domain,dc=acme,dc=com"
            roleFilter="(cn=no such group)"
            searchScope="SUBTREE_SCOPE";
    };
    
  6. JBoss EAP を再起動すると、HTTP インターフェースは認証に LDAP サーバーを使用するようになります。

10.7.5. HTTP 管理インターフェースの無効化

管理対象ドメインでは、ドメインメンバーのサーバーではなく、ドメインコントローラー上の HTTP インターフェースへのアクセスのみが必要です。また、実稼働サーバー上では、Web ベースの管理コンソールを完全に無効化することが可能です。

注記

JBoss Operations Network などの他のクライアントも HTTP インターフェースを使用して稼働します。これらのサービスを使用したり、管理コンソール自体を無効にしたい場合は、インターフェースを完全に無効化する代わりに HTTP インターフェースの console-enabled 属性 を false に設定できます。
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
HTTP インターフェースへのアクセスを無効にすると、Web ベースの管理コンソールへのアクセスも無効になるため、HTTP インターフェースを完全に削除して無効化できます。
次の JBoss CLI コマンドを使用すると、再度追加する場合に備えて HTTP インターフェースの現在の内容を読み込むことができます。

例10.11 HTTP インターフェースの設定の読み込み

/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}
HTTP インターフェースを削除するには、次のコマンドを実行します。

例10.12 HTTP インターフェースの削除

/host=master/core-service=management/management-interface=http-interface/:remove
アクセスを再度有効化するには、以下のコマンドを実行し、デフォルト値を使用して HTTP インターフェースを再作成します。

例10.13 HTTP インターフェースの再作成

/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)

10.7.6. デフォルトセキュリティーレルムからのサイレント認証の削除

概要

JBoss EAP 6 には、ローカル管理 CLI ユーザーに対するサイレント認証方法が含まれます。これにより、ローカルユーザーは、ユーザー名またはパスワード認証なしで管理 CLI にアクセスできるようになります。この機能は、利便性のために有効であり、ローカルユーザーが認証なしで管理 CLI スクリプトを実行する場合に役に立ちます。この機能は、ローカル設定へのアクセスにより、ユーザーが独自のユーザー詳細を追加できる (または、セキュリティーチェックを無効にする) ため、役に立つ機能です。

ローカルユーザーのサイレント認証は便利ですが、さらに強力なセキュリティー制御が必要な場合に無効にできます。これは、設定ファイルの security-realm セクション内で local 要素を削除することにより、実現できます。これは、スタンドアロンサーバーインスタンス用の standalone.xml と管理対象ドメイン用の host.xml の両方に適用されます。特定のサーバー設定への影響について理解している場合のみ、local 要素の削除を考慮するようにしてください。
推奨されるサイレント認証の削除方法は、管理 CLI を使用して、次の例に示された local 要素を直接削除することです。

例10.14 security-realmlocal 要素の例

<security-realms>
    <security-realm name="ManagementRealm">
        <authentication>
            <local default-user="$local"/>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
    </security-realm>
    <security-realm name="ApplicationRealm">
        <authentication>
            <local default-user="$local" allowed-users="*"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
        <authorization>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
        </authorization>
    </security-realm>
</security-realms>

手順10.7 デフォルトセキュリティーレルムからのサイレント認証の削除

  • 管理 CLI でのサイレント認証の削除

    必要に応じて、管理レルムとアプリケーションレルムから local 要素を削除します。
    1. 管理レルムから local 要素を削除します。
      • スタンドアロンの場合

        /core-service=management/security-realm=ManagementRealm/authentication=local:remove
      • 管理対象ドメインの場合

        /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
    2. アプリケーションレルムから local 要素を削除します。
      • スタンドアロンの場合

        /core-service=management/security-realm=ApplicationRealm/authentication=local:remove
      • 管理対象ドメインの場合

        /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
結果

サイレント認証モードが、ManagementRealmApplicationRealm から削除されます。

10.7.7. JMX サブシステムへのリモートアクセスの無効化

リモート JMX 接続により JDK およびアプリケーション管理操作のトリガーが可能となります。インストールをセキュアにするには、この機能を無効にしてください。無効にするには、リモート接続の設定を削除するか、JMX サブシステムを完全に削除します。JBoss CLI コマンドは管理対象ドメイン設定内のデフォルトのプロファイルを参照します。異なるプロファイルを修正するには、コマンドの /profile=default の部分を変更します。スタンドアロンサーバーの場合には、この部分を完全に削除してください。

注記

管理対象ドメインでは、リモート処理コネクターはデフォルトで JMX サブシステムから削除されています。以下のコマンドは、開発中にリモート処理コネクターを追加した場合に備えて、参考のために記載します。

例10.15 JMX サブシステムからのリモートコネクターの削除

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove

例10.16 JMX サブシステムの削除

管理対象ドメインを使用している場合には、使用しているプロファイルごとにこのコマンドを実行してください。
/profile=default/subsystem=jmx/:remove

10.7.8. 管理インターフェースのセキュリティーレルムの設定

管理インターフェースはセキュリティーレルムを使用して JBoss EAP 6 の認証および設定メカニズムへのアクセスを制御します。 本トピックでは、セキュリティーレルムの読み込みと設定について説明します。以下に記載するコマンドには管理 CLI を使用します。
セキュリティーレルムの設定の読み込み

以下の例は、ManagementRealm セキュリティーレルムのデフォルト設定を示しています。mgmt-users.properties というファイルを使用して設定情報を保管します。

例10.17 デフォルトの ManagementRealm

	/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "authorization" => undefined,
        "server-identity" => undefined,
        "authentication" => {"properties" => {
            "path" => "mgmt-users.properties",
            "plain-text" => false,
            "relative-to" => "jboss.domain.config.dir"
        }}
    }
}
セキュリティーレルムの書き込み

以下のコマンドは TestRealm というセキュリティレルムを作成し、関連するプロパティーファイルのディレクトリーを設定します。

例10.18 セキュリティーレルムの書き込み

/host=master/core-service=management/security-realm=TestRealm/:add/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)

管理インターフェースへのセキュリティーレルムの適用

セキュリティーレルムを追加したら、管理インターフェースへの参照として指定します。

例10.19 管理インターフェースへのセキュリティーレルムの追加

/host=master/core-service=management/management-interface=http-interface/:write-attribute(security-realm=TestRealm)

10.8. ロールベースアクセス制御を用いた管理インターフェースのセキュア化

10.8.1. ロールベースアクセス制御 (RBAC)

ロールベースアクセスコントロール (RBAC) は、管理ユーザーのパーミッションセットを指定するメカニズムです。これにより、無制限のアクセスを必要とせずに複数のユーザーが JBoss EAP 6.2 の管理業務を共有できます。JBoss EAP 6.2 は管理ユーザーの「職務の分離」を実現することで、不必要な特権を与えずに組織における個人またはグループの業務分散を容易にします。これにより、設定、デプロイメント、および管理の柔軟性を維持しながらサーバーやデータのセキュリティーを可能な限り強化できます。

JBoss EAP 6.2 のロールベースアクセス制御は、ロールパーミッションと制約の組み合わせにより動作します。

異なる固定パーミッションを持つ 7 つのロールが事前定義されています。事前定義されたロールは Monitor、Operator、Maintainer、Deployer、Auditor、Administrator、および SuperUser です。各管理ユーザーに 1 つ以上のロールが割り当てられ、サーバー管理時にユーザーが許可される項目は、割り当てられたロールによって指定されます。

10.8.2. GUI および CLI でのロールベースアクセス制御

ロールベースアクセス制御 (RBAC) が有効になっている場合、ユーザーに割り当てられたロールによっては、ユーザーが操作の一部を実行できなかったり、リソースの一部を読み取りできなかったりすることがあります。また、管理モデルの一部を全く閲覧できないこともあります。
管理コンソール

管理コンソールでは、割り当てられたロールのパーミッションによっては、制御およびビューの一部が無効化 (灰色で表示) されたり、全く表示されないことがあります。

リソース属性に対する読み取りパーミッションがない場合、その属性は管理コンソールでは空白で表示されます。たとえば、ほとんどのロールは、データソースのユーザー名およびパスワードフィールドを読み取りできません。

リソース属性に対する書き込みパーミッションがない場合、その属性はリソースの編集フォームで無効化 (灰色で表示) されます。リソースに対する書き込みパーミッションが何もない場合、リソースの編集ボタンは表示されません。

リソースまたは属性へアクセスするパーミッションが全くない場合 (ルールに「アドレス不可能」な場合)、コンソールには何も表示されません。アクセス制御システム自体がこの例で、デフォルトでは少数のロールのみに対して表示されます。
管理 API

jboss-cli.sh ツールを使用したり、API を直接使用する場合、RBAC が有効になっていると API の挙動が若干異なります。

読み取りできないリソースや属性は結果からフィルターされます。フィルターされた項目がロールによってアドレス可能である場合、結果の response-headers セクションにこれらの名前が filtered-attributes としてリストされます。リソースまたは属性がロールによってアドレス可能でない場合は、リストされません。

アドレス不可能なリソースにアクセスしようとすると、「resource not found (リソースが見つかりません)」というエラーが発生します。

適切な読み書きパーミッションのないユーザーが、アドレス可能なリソースを読み取りまたは書き込みしようとすると、「Permission Denied (パーミッション拒否)」というエラーが返されます。

10.8.3. サポートされる認証スキーム

ロールベースアクセス制御は、JBoss EAP 6.2 に含まれる標準の認証プロバイダーと動作します。標準の認証プロバイダーは username/passwordclient certificate、および local user です。
Username/Password

ユーザーはユーザー名とパスワードの組み合わせを使用して認証されます。この組み合わせは、mgmt-users.properties ファイルまたは LDAP サーバーに対して検証されます。
Client Certificate

トラストストアを使用します。
Local User

同じマシン上で実行されているサーバーの場合、jboss-cli.sh は自動的に Local User として認証します。デフォルトでは、Local User は SuperUser グループのメンバーになります。
使用されるプロバイダーに関係なく、JBoss EAP はロールをユーザーに割り当てます。しかし、mgmt-users.properties ファイルまたは LDAP サーバーで認証する場合、これらのシステムはユーザーグループ情報を提供できます。ユーザーグループ情報は、ロールをユーザーに割り当てるために JBoss EAP が使用することも可能です。

10.8.4. 標準のロール

JBoss EAP 6 は、Monitor、Operator、Maintainer、Deployer、Auditor、Administrator、および SuperUser の 7 つの事前定義されたユーザーロールを提供します。各ロールは特定のユースケース向けに設定されており、異なるパーミッションセットを持ちます。Monitor、Operator、Maintainer、Administrator、および SuperUser ロールは、それぞれ前のレベルのロールから継承したパーミッションと追加のパーミッションを持ちます。Auditor および Deployer ロールはそれぞれ Monitor および Maintainer ロールに似ていますが、特別なパーミッションおよび制限が追加されています。
Monitor

Monitor ロールのユーザーは、最も少ないパーミッションを持ち、現在の設定およびサーバーの状態のみを読み取りできます。これは、サーバーのパフォーマンスを追跡し、報告する必要があるユーザー向けのロールです。

Monitor はサーバー設定を変更したり、機密データおよび操作にアクセスしたりできません。
Operator

Operator ロールは、サーバーのランタイム状態を変更する機能を追加して、Monitor ロールを拡張します。これにより、Operator はサーバーをリロードおよびシャットダウンでき、JMS 宛先を一時停止および再開できます。Operator ロールは、アプリケーションサーバーの物理または仮想ホストを管理するユーザーに向いており、必要時にサーバーが正しくシャットダウンおよび再起動されるようにします。

Operator はサーバー設定を変更したり、機密データおよび操作にアクセスしたりできません。
Maintainer

Maintainer ロールは、機密データおよび操作以外のすべての設定と、ランタイム状態を表示および変更できます。Maintainer ロールは、機密データおよび操作へアクセスできない汎用のロールです。Maintainer ロールは、パスワードやその他の機密情報へのアクセス権限を付与せずに、ユーザーがサーバーをほぼ完全に管理できるようにします。

Maintainer は機密データまたは操作へアクセスできません。
Administrator

Administrator ロールは、監査ロギングシステムを除くサーバー上のすべてのリソースおよび操作へ無制限にアクセスできます。Administrator は、機密データおよび操作へアクセスできるロールです。このロールはアクセス制御システムを設定することも可能です。Administrator ロールは、機密データを処理する場合や、ユーザーとロールを設定する場合のみ必要です。

Administrator は監査ロギングシステムへアクセスできず、Administrator 自身を Auditor または SuperUser ロールへ変更できません。
SuperUser

SuperUser ロールには制限がなく、監査ロギングシステムを含むサーバーのすべてのリソースおよび操作へ完全にアクセスできます。このロールは、以前のバージョンの JBoss EAP 6 (6.0 および 6.1) での管理者ユーザーと同等です。RBAC が無効である場合、すべての管理ユーザーは SuperUser ロールと同等のパーミッションを持ちます。
Deployer

Deployer ロールは Monitor と同じパーミッションを持ちますが、デプロイメントの設定や状態を変更でき、アプリケーションリソースとして有効になっている他のリソースタイプも変更できます。
Auditor

Auditor ロールは Monitor ロールと同じパーミッションを持ちますが、機密データを表示でき (変更はできません)、監査ロギングシステムへ完全にアクセスできます。Auditor ロールは SuperUser ロール以外で唯一監査ログインシステムへアクセスできるロールです。

Auditor は機密データやリソースを変更できません。読み取りアクセスのみ許可されます。

10.8.5. ロールパーミッション

各ロールの権限は、各ロールのパーミッションによって定義されます。すべてのロールにすべてのパーミッションがあるわけではありません。SuperUser はすべてのパーミッションを持ちますが、Monitor のパーミッションは最も少なくなります。
各パーミッションは、リソースの単一のカテゴリーに対して読み書きのアクセスを付与します。
カテゴリーは、ランタイム状態、サーバー設定、機密データ、監査ログ、およびアクセス制御システムです。
表10.2「ロールパーミッション」 は各ロールのパーミッションを示しています。

表10.2 ロールパーミッション

 

Monitor

Operator

Maintainer

Deployer

Auditor

Administrator

SuperUser

設定と状態の読み取り

機密データの読み取り [2]
    

機密データの変更 [2]
     

監査ログの読み取り/変更
    

 

ランタイム状態の変更
 

○[1]
 

永続化設定の変更
  

○[1]
 

アクセス制御の読み取り/変更
     

[1] パーミッションはアプリケーションリソースに制限されます。
[2] 機密性制約 (Sensitivity Constraint) を使用して「機密データ」として考慮されるリソースを設定します。

10.8.6. 制約

制約は、指定のリソースリストに対するアクセス制御設定の名前付きセットです。RBAC システムは制約とロールパーミッションの組み合わせを使用し、特定ユーザーが管理アクションを実行できるかどうかを判断します。

制約は、アプリケーション、機密性、および Vault 式の 3 つに分類されます。
アプリケーション制約

アプリケーション制約は、Deployer ロールのユーザーがアクセスできるリソースおよび属性のセットを定義します。デフォルトでは、有効になっているアプリケーション制約は、デプロイメントやデプロイメントオーバーレイが含まれるコアのみです。また、アプリケーション制約はデータソース、ロギング、メール、メッセージング、ネーミング、リソースアダプター、およびセキュリティーに対しても含まれますが、デフォルトでは有効になっていません。これらの制約により、Deployer ユーザーはアプリケーションをデプロイできるだけでなく、これらのアプリケーションが必要とするリソースを設定および維持できます。

アプリケーション制約の設定は、管理 API の /core-service=management/access=authorization/constraint=application-classification にあります。
機密性制約

機密性制約は、「機密」とされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密のリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバー操作に深刻な影響を与えるリソースのことを言います。アクセス制御システム自体も機密であるとみなされます。

機密リソースへの書き込みを許可されるロールは、Administrator と SuperUser のみです。Auditor ロールは、機密リソースの読み取りのみ可能です。他のロールは機密リソースへアクセスできません。

機密制約設定は、管理 API の /core-service=management/access=authorization/constraint=sensitivity-classification にあります。
Vault 式の制約

vault 式制約は、vault 式の読み取りまたは書き込みが機密操作としてみなされるかどうかを定義します。デフォルトでは、vault 式の読み書き両方が機密操作とみなされます。

vault 式制約の設定は、管理 API の /core-service=management/access=authorization/constraint=vault-expression にあります。

制約は管理コンソールでは設定できません。

10.8.7. JMX およびロールベースアクセス制御

ロールベースアクセス制御は、次の 3 つの方法で JMX に適用されます。
  1. JBoss EAP 6 の管理 API は JXM 管理 Bean として公開されます。これらの管理 Bean は「コア MBean」と呼ばれ、コア MBean へのアクセスは基盤の管理 API と全く同じように制御およびフィルターされます。
  2. JMX サブシステムは、書き込みパーミッションが「機密」で設定されます。そのため、Administrator および SuperUser ロールのユーザーのみがそのサブシステムに変更を追加できます。Auditor ロールのユーザーはこのサブシステムの設定を読み取りできます。
  3. デフォルトでは、デプロイされたアプリケーションおよびサービスによって登録された管理 Bean (コアでない MBean) へすべての管理ユーザーがアクセスできますが、Maintainer、Operator、Administrator、および SuperUser ロールのユーザーのみが書き込み可能です。

10.8.8. ロールベースアクセス制御の設定

10.8.8.1. RBAC 設定タスクの概要

RBAC が有効になっている場合、Administration および SuperUser ロールのユーザーのみがアクセス制御システムを表示し、変更を追加できます。
管理コンソールは、以下の一般的な RBAC タスクに対してインターフェースを提供します。
  • 各ユーザーへ割り当てられた (または除外された) ロールの表示および設定
  • 各グループへ割り当てられた (または除外された) ロールの表示および設定。
  • ロールごとのグループおよびユーザーメンバーシップの表示。
  • ロールごとのデフォルトメンバーシップの設定。
  • スコープ指定されたロールの作成。
CLI は完全なアクセス制御システムへのアクセスを提供します。そのため、管理コンソールで行えることはすべてアクセス制御システムでも行えますが、アクセス制御システムでは実行できない複数の追加タスクを CLI で実行できます。
CLI で実行できる追加タスクは次のとおりです。
  • RBAC の有効化および無効化
  • パーミッション組み合わせポリシーの変更
  • アプリケーションリソースおよびリソース機密性の制約の設定

10.8.8.2. ロールベースアクセス制御の有効化

デフォルトでは、ロールベースアクセス制御 (RABC) システムは無効になっています。有効にするには、プロバイダー属性を simple から rbac に変更します。この変更を行うには jboss-cli.sh ツールを使用しますが、サーバーがオフラインの場合はサーバー設定 XML ファイルを編集して変更できます。RBAC が稼働中のサーバー上で無効または有効になっている場合は、サーバー設定をリロードして変更を反映する必要があります。
RBAC を有効にすると、無効にできるのは Administrator または SuperUser ロールのユーザーのみです。デフォルトでは、jboss-cli.sh がサーバーと同じマシン上で実行されていると SuperUser ロールとして実行されます。

手順10.8 RBAC の有効化

  • jboss-cli.sh を用いて RBAC を有効にするには、アクセス承認リソースの write-attribute 操作を使用して、プロバイダー属性を rbac に設定します。
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }
    [standalone@localhost:9999 /] /:reload
    {
        "outcome" => "success",
        "result" => undefined
    }
    [standalone@localhost:9999 /]

手順10.9 RBAC の無効化

  • jboss-cli.sh を用いて RBAC を無効にするには、アクセス承認リソースの write-attribute 操作を使用して、プロバイダー属性を simple に設定します。
    /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    {
        "outcome" => "success",
        "response-headers" => {
            "operation-requires-reload" => true,
            "process-state" => "reload-required"
        }
    }
    [standalone@localhost:9999 /] /:reload
    {
        "outcome" => "success",
        "result" => undefined
    }
    [standalone@localhost:9999 /]
サーバーがオフラインの場合は、XML 設定を編集して RBAC を有効または無効にできます。これを行うには、管理要素のアクセス制御要素にある provider 属性を編集します。有効にする場合は値を rbac に設定し、無効にする場合は simple に設定します。
<management>

        <access-control provider="rbac">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>

    </management>