Red Hat Training

A Red Hat training course is available for Red Hat JBoss Operations Network

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

Web アプリケーションは、固有のリソースタイプです。これらはサーバーの子リソースとして追加されるため、独自のエントリー、独自の子リソース、監視、アラート、および操作の独立した設定を持つインベントリー内に場所があります。ただし、Web アプリケーションは コンテンツベースのリソース です。最終的に、これらのパッケージは、実際のサーバーやサービスではなく、ソフトウェアパッケージになります。
コンテンツベースのリソースを管理するには、最初のデプロイメント（デプロイメントを子リソースとして作成）およびパッチおよび更新（コンテンツ更新）のパスも行う必要があります。
重要
コンテンツベースのリソースをデプロイすると、ディスク領域の要件に大きく影響する可能性があります。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース（Oracle または PostgreSQL）をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。
バグを報告します。

32.5.1. ランタイム情報およびデプロイメントリソース

32.5.1.1. デプロイメントの表示

EAP 6 と JBoss ON の両方で、Web アプリケーションを中央コンテンツリポジトリーに追加し、そのコンテンツをサーバーグループに関連付けるための明確なワークフローが提供されます。ただし、それらが提供する観点は非常に異なります。そのため、使用するコンソールの定義は、その特定の時点で達成する必要があるものによって異なります。
EAP 6 コンソールは、直ちにコンテンツをサーバーグループに関連付けることに重点が置かれます。EAP 6 コンソールでは、デプロイメントは JVM 定義のように共有設定と同様に処理されます。コンテンツパッケージはドメインコントローラーまたはサーバーグループにデプロイされ、管理サーバーに関連付けられます。

図32.13 ランタイムページでのデプロイメント

ランタイムページでのデプロイメント
JBoss ON は、履歴および変化するパースペクティブである web アプリケーションのライフサイクル管理に重点を置いています。JBoss ON が Web アプリケーションを定義する方法には、基本的な違いがいくつかあります。
  • Web アプリケーションは、個別のエンティティーとして、内およびそれ自体として扱われます。インベントリーには独自の場所があり、ドメインおよびサーバーグループとの関連性は、それらのリソースの子であるため反映されます。
    JBoss ON は、ファイルサイズや特定 SHA256 ハッシュなどのパッケージの詳細も記録します。
  • Web アプリケーションには履歴があります。パッケージの更新が changelog に記録されるため、アプリケーションの維持方法を追跡できます。
  • Web アプリケーションは監視できます。応答時間メトリックは、特に基盤のサーバーのパフォーマンスやモニタリング以外に、Web アプリケーションのパフォーマンスを追跡します。

図32.14 JBoss ON の Deployment Resource Details

JBoss ON の Deployment Resource Details
リソースとしてのこの Web アプリケーションは、コンテンツをサーバーにデプロイする簡単なタスクではないことです。EAP 6 コンソールは、非常に単純かつクリーンに実行できます。JBoss ON 管理の目的は、Web アプリケーションのコンテンツを管理することです。
  • パッチおよび更新を格納するコンテンツリポジトリーの作成
  • 複数バージョンのコンテンツの追跡
  • ソフトウェアパッケージを以前のバージョンに戻す（特にスタンドアロンサーバーの場合）
  • 複数のドメインおよびスタンドアロンサーバーを含む、複数の EAP インスタンスに同じコンテンツリポジトリーを使用
  • コンテンツの変更の追跡（および監査）
バグを報告します。

32.5.1.2. スタンドアロンサーバーおよびドメインのデプロイメントパス

スタンドアロンサーバーとドメインには、非常に異なる構造があり、Web アプリケーションをデプロイするためのコンテンツフローに影響します。
スタンドアロンサーバーの Web アプリケーションデプロイメントは EAP 5 と似ており、デプロイメントに使用されるローカルファイルシステムディレクトリーがあります。ローカルでは、アプリケーションをデプロイメントディレクトリーに追加し、ホットデプロイできます。JBoss ON を使用すると、Web アプリケーションをデプロイするためのパスは 2 つあります。
  • 子リソースとしてデプロイメントを作成します。
  • バンドルを使用してデプロイメントディレクトリーにアプリケーションをプロビジョニングします。
バンドルシステムには、複数のバージョンを保存したり、更新をロールバックしたり、更新のバージョンをスキップしたり、デプロイメントを 1 つのボタンと共にパージする機能があるため、バンドルの使用は多用途で実用的な管理方法です。
ただし、バンドルシステムは実際のファイルシステムの場所でのみ機能します。JBoss EAP 6 ドメインの分散構造およびモジュール構造は、バンドルがオプションではないことを意味します。
EAP 6 ドメインの場合、コンテンツは子リソースとしてドメインにデプロイされ、管理者によってサーバーグループに伝播されます。
バンドルシステムの柔軟性と細かな機能はありませんが、通常のコンテンツシステムを使用すると、コンテンツのバージョンと更新を制御する方法が提供されています。コンテンツベースのリソースは、JBoss ON のコンテンツリポジトリーに関連付けることができます。これらのリポジトリーは、さまざまなコンテンツソースから、さまざまな種類のソフトウェアパッケージを保存できます。リポジトリーのパッケージは、リソースに選択的にインストールできます。さらに、リソースを複数のリポジトリーに関連付けることもできます。JBoss ON のコンテンツリポジトリーは、バンドルでの変更の更新や元に戻す際にフラッシュされませんが、個別のパッチファイルを web アプリケーションに適用したり、完全な更新をロールアウトするためのパスルートを提供します。
コンテンツ管理全般は、を参照してください 28章リソースレベルのコンテンツ更新の管理。ここでは、コンテンツリポジトリーの設定、リソースのサブスクライブ、および更新のプッシュについて説明します。
バグを報告します。

32.5.2. ドメインへの Web アプリケーションのデプロイメント

32.5.2.1. ドメインへの Web アプリケーションを帰リソースとしてデプロイ

注記
他の子リソースを作成する場合と同様に、新しいデプロイメントが JBoss ON インベントリーに追加され、表示されるまで数分かかることがあります。これは、ローカルシステムで新しいリソースを作成し、エージェントが検出する必要があるためです。リソースの作成時に検出スキャンが実行されている場合は、次の検出スキャンが 15 分以上検出されるまでかかることがあります。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 ドメインコントローラーを選択します。
  3. ドメインコントローラーエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し DomainDeploymentます。
  5. バージョン番号を入力します。
  6. EAR、WAR、または JAR ファイルをアップロードします。
  7. オプションで、デプロイメントのランタイム名を入力します。
  8. ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。
    注記
    タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。
    特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
  9. をクリックし Finishます。
パッケージがアップロードされると、ドメインの DomainDeployments ディレクトリーに新しいリソースエントリーが追加されます。

図32.15 ドメインデプロイメントディレクトリー

ドメインデプロイメントディレクトリー
バグを報告します。

32.5.2.2. バンドルを介したドメインへの Web アプリケーションのデプロイ

アプリケーションは、ant バンドルレシピを使用して rhq:handover 要素とともに JBoss Enterprise Application Platform 6 ドメインにデプロイできます。一般的な ant バンドルレシピの詳細は、を参照してください 27章バンドルへのコンテンツおよびアプリケーションのデプロイ。
以下の ant バンドルのサンプルにより、「website.war」が「main-server-group-01」 JBoss Enterprise Application Platform 6 ドメインサーバーグループにデプロイされます。 
<project name="handover-test-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle">
 <rhq:bundle name="example.com (EAP 6)" version="1.0" description="example.com corporate website hosted on EAP 6">

  <rhq:input-property name="myapp.runtime.name" defaultValue="website.war" required="true"/>
  <rhq:input-property name="myapp.serverGroup.name" defaultValue="main-server-group-01" required="true"/>

  <rhq:deployment-unit name="example.com deployment unit" compliance="filesAndDirectories">
   
   <rhq:file name="prepareDatasource.cli" replace="true">
    <rhq:handover action="execute-script"/>
   </rhq:file>
   <rhq:archive name="website.war">
    <rhq:handover action="deployment">
     <rhq:handover-param name="runtimeName" value="${myapp.runtime.name}"/>
     <rhq:handover-param name="serverGroup" value="${myapp.serverGroup.name}"/>
    </rhq:handover>
   </rhq:archive>
  </rhq:deployment-unit>
 </rhq:bundle>
 <target name="main"/>
</project>
特定のハンドオーバーアクション、ハンドオーバーパラメーター、およびレシピの例については、にナビゲートして見つかった JBoss Enterprise Application Platform 6 プラグインドキュメントを参照してください Administration > Configuration > Agent Plugins > JBoss Application Server 7.x。
Ant Bundle を JBoss Enterprise Application Platform ドメインにデプロイするには、以下を実行します。
  1. トップメニューで、Bundles タブをクリックします。
  2. Bundle セクションの New ボタンをクリックします。
  3. を選択 Upload し Choose てクリックし、目的のディストリビューションファイルに移動して選択します。
  4. をクリックし Nextます。
  5. 必要なバンドルグループを選択し、をクリックし Nextます。
  6. をクリックし Finishた後 Next、をクリックします。
  7. 新たにアップロードしたバンドルの Bundle セクションをクリックします。
  8. バンドルの詳細の Deploy ボタンをクリックします。
  9. 宛先情報を入力し、ウィザードに進みます。
注記
バンドルの宛先情報を指定する場合は、ドメインコントローラーのリソースグループを基にする必要があります。
ant バンドルで server group パラメーターを指定する場合、これはアプリケーションがデプロイされる JBoss Enterprise Application Platform ドメインのサーバーグループになります。
バグを報告します。

32.5.3. サーバーグループへの Web アプリケーションの割り当て

さまざまなグループに Web アプリケーションを手動で割り当てると、管理者は、で拡張されたようにアプリケーションのライフサイクルを制御でき 「拡張例： Web アプリケーションの割り当てと更新の管理」 ます。異なるオペレーティング環境で同じコンテンツが使用されます。
注記
Web アプリケーションは、ドメインにデプロイするプロセスと同様に、サーバーグループに直接デプロイでき 「ドメインへの Web アプリケーションのデプロイメント」 ます。
ドメインのデプロイメントパスは、コンテンツをドメインコントローラーにアップロードしてからそのコンテンツをサーバーグループに分散することです。サーバーグループへのデプロイメントの作成は同じプロセスに従います。ドメインにデプロイしてサーバーグループに送信します。ショートカットのみを提供します。
ドメインコントローラーにコンテンツがすでに存在する場合は、ここで説明するドメインコントローラー操作でコンテンツをデプロイする必要があります。
コンテンツをドメインにデプロイすると、最初にドメインが種類のリポジトリーとして使用されます。ドメインから、同じパッケージを複数のグループにデプロイできます。また、ドメインにデプロイすると、管理者は、同時に複数のパッケージをグループまたは指定した順序で、同じ操作で複数のパッケージをデプロイできます。これにより、サーバーへのコンテンツストリームを制御するのに役立ちます。
重要
サーバーグループの新たにデプロイされたコンテンツは、正常に作成された場合でも 24 時間限り JBoss ON インベントリーに表示されない場合があります。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。新しいコンテンツベースのリソースを表示するには、エージェントの検出スキャンを実行し、手動で検出します。
注記
デプロイメントはドメインで子リソースとして作成され、操作としてサーバーグループに割り当てられ、最後にドメインの Content タブで更新されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 ドメインコントローラーを選択します。
  3. DomainDeployments フォルダーを展開します。
    デプロイメントフォルダーにすべての Web アプリケーションをデプロイするには、デプロイメントフォルダー自体を選択して操作を実行します。
    単一の Web アプリケーションをデプロイするには、特定の Web アプリケーションを選択します。
  4. サーバーの Operations タブを開きます。
  5. ページ下部の New ボタンをクリックします。
  6. ドロップダウンメニューから Assign to Server-Group オプションを選択します。
  7. アプリケーションをデプロイするグループ（またはすべてのグループ）を選択します。
  8. 操作の実行時やタイムアウト期間のスケジュールなど、操作の標準情報を入力します。
    注記
    タイムアウト期間は、操作がタイムアウトして失敗したことを想定するまでのサーバーが待機する時間を設定します。これは、操作の実行に失敗したり、停止したりすることを意味するわけではありません。
  9. 複数の Web アプリケーションをデプロイしている場合は、パッケージがデプロイされる順序を設定する方法に Execute ラジオボタンを設定します。すべてのパッケージは一度にデプロイすることも、特定の順序でデプロイすることもできます。
  10. Schedule ボタンをクリックします。
  11. 必要に応じて、エージェントで検出スキャンを実行して、新しいコンテンツリソースを検出します。デフォルトでは、サービスの検出スキャンは 24 時間ごとに実行されるため、新規コンテンツの検出に時間がかかる可能性があります。
    1. UI でエージェントエントリーを開きます。
    2. Operations タブを開き、execute prompt command 操作を選択します。
    3. discovery コマンドを操作 rgument として入力します。これで検出スキャンが実行されます。
    4. Schedule ボタンをクリックします。
バグを報告します。

32.5.4. 拡張例： Web アプリケーションの割り当てと更新の管理

設定

Tim the IT Guy は、開発からステージングおよび実稼働環境まで、Web アプリケーションの進捗を明確にしたいと考えています。EAP 6 のネイティブ構造では、異なるサーバーグループを作成し、各ステージでテストを渡す際に、中央ドメインコントローラーから適切なサーバーグループにコンテンツをデプロイできます。

IT Guy が希望する Tiim はそのパスの上にレイヤーを追加し、適用パッチおよび更新の作成を可能にします。メンテナンススケジュールの一部として、修正を管理し、監査できるようにする必要があります。

The Plan

  1. Tim は、まず維持する必要のあるサーバーグループの概要を示します。シンプルな環境では、3 つのグループ（testing、staging、および production）が必要です。
  2. 2 つのコンテンツリポジトリーを作成します。1 つはパッチ用で、もう 1 つは Web アプリケーションの新しいバージョン用です。
  3. ドメインデプロイメントを作成し、web アプリケーションを testing サーバーグループにプロモートします。
  4. Tim は、Web アプリケーションの応答時間監視を設定します。テストエリアで必要なパフォーマンスパラメーターを満たすと、Tim はデプロイメントをステージング環境にプロモートし、次に実稼働サーバーグループにプロモートします。

結果

各デプロイメントのパッケージ履歴により、Web アプリケーションがデプロイされた時点、バージョン、およびそのコンテンツを追跡できます。

Tim は、コンテンツをリポジトリーにデプロイし、サブスクライブしているすべてのリソースにインストールすることで、パッチまたは完全なアップデートを適用できます。コンテンツの新しいバージョン番号など、このパッケージの変更はパッケージ履歴に含まれています。
パッチおよび更新リポジトリーは特定の JBoss Enterprise Application Platform 6 ドメインではなく、JBoss ON 自体に設定されているため、必要に応じて他のドメインおよびスタンドアロンサーバーと使用するパッケージを使用できます。
バグを報告します。

32.5.5. ドメインサーバーグループでの Web アプリケーションの有効化および無効化

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 ドメインコントローラーを選択します。
  3. インベントリーツリーでフォルダーを展開し、web アプリケーションを選択 DomainDeployments して一覧から有効または無効にします。
  4. Web アプリケーションの Configuration タブを開きます。
  5. Assigned to セクションで、Web アプリを有効または無効にするサーバーグループに対応する Server Group 行の青の鉛筆をクリックします。
  6. Enabled 行で Yes または No を選択し、OK をクリックします。
  7. Save ボタンをクリックします。
バグを報告します。

32.5.6. デプロイメントコンテンツの更新

  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss Enterprise Application Platform 6 サーバーを選択します。
  3. DomainDeployments フォルダーを開きます（スタンドアロンサーバーでは Deployment フォルダーを使用）、更新する Web アプリケーションを選択します。
  4. Web アプリケーションの詳細ページで Content タブを開き、New サブタブをクリックします。
  5. UPLOAD NEW PACKAGE ボタンをクリックします。
  6. UPLOAD FILE ボタンをクリックします。
  7. ポップアップウィンドウで Add ボタンをクリックし、ローカルファイルシステムをアップロードする更新されたコンテンツファイルを参照します。
  8. UPLOAD ボタンをクリックします。
  9. Web アプリケーションパッケージを保存するリポジトリーを選択します。これは不要ですが、更新されたパッケージを JBoss ON に保存して、他の JBoss EAP 6 デプロイメントで使用できるようにすることが推奨されます。
  10. バージョン情報を入力します。
  11. 新しいパッケージの詳細を確認してから、をクリックし CONTINUEます。
パッケージが正常にアップロードされると、UI は Content タブの履歴ページにリダイレクトします。

図32.16 リソースのデプロイメント履歴

リソースのデプロイメント履歴
バグを報告します。

32.5.7. Web アプリケーションのスタンドアロンサーバーへのデプロイ

スタンドアロンサーバーは、特定のファイルシステムディレクトリーをデプロイメントディレクトリーとして使用します。ドメインのデプロイメントと同様に、子リソースを作成してコンテンツをデプロイすることができます。ただし、スタンドアロンサーバーの構造がシンプルであるため、コンテンツはコンテンツバンドルを使用してデプロイすることもできます。バンドルは、単純化された更新およびパスの元に戻すだけでなく、より詳細なバージョン管理システムを提供します。
バグを報告します。

32.5.7.1. Web アプリケーションの クライアントリソースとしてのデプロイ

重要
新しいデプロイメントは、正常に作成された場合でも数分または 24 時間間 JBoss ON インベントリーに表示されない場合があります。これは、作成後にエージェントがインベントリーに追加するために新しいリソースを検出する必要があるためです。デフォルトでは、サービスの検出スキャンは 24 時間ごとにのみ行われます。
即座に表示するには、エージェントで 実行プロンプトのコマンド 操作を実行し、discovery コマンドを入力します。これで検出スキャンが実行されます。
  1. トップメニューの Inventory タブをクリックします。
  2. 左側 Servers - Top Level Imports の Resources メニューテーブルで選択します。JBoss EAP 6 スタンドアロンサーバーを選択します。
  3. ナビゲーションツリーのスタンドアロンサーバーエントリーを右クリックします。
  4. Create New メニューで、の項目を選択し Deploymentます。
  5. バージョン番号を入力します。
  6. EAR、WAR、または JAR ファイルをアップロードします。
  7. オプションで、デプロイメントのランタイム名を入力します。
  8. ウィザードの最後に、タイムアウト期間を設定します。これは、デプロイメントプロセス中に JBoss ON サーバーが待機してからデプロイメントに失敗したかどうかを判断するまでの時間です。
    注記
    タイムアウト期間は、サーバーのレポート結果にのみ適用されます。操作の実行が続行されると、Web アプリケーションは正常に完了し、Web アプリケーションがデプロイされます。
    特に大規模なアプリケーションファイルの場合、タイムアウト時間が短縮されず、サーバーがデプロイメントに失敗とマークします。デプロイメントが後で完了すると、Web アプリケーションを手作業でインベントリーにインポートする必要があります。エージェントは検出されません。
  9. をクリックし Finishます。
バグを報告します。

32.5.7.2. バンドルへの Web アプリケーションのデプロイ

バンドルアーカイブとレシピの作成、宛先の定義、およびバンドルバージョンの管理については、を参照してください 27章バンドルへのコンテンツおよびアプリケーションのデプロイ。
  1. トップメニューで、Bundles タブをクリックします。
  2. ディストリビューションファイルをアップロードし、デプロイメントウィザードにアクセスしてバンドルバージョンを作成します。
  3. ウィンドウの下部までスクロールし、Deploy ボタンをクリックします。
  4. デプロイするバンドルを選択します。
  5. JBoss スタンドアロンサーバーの宛先情報を定義します。宛先は、互換性のあるグループ（JBoss リソースを含む）とバンドルをデプロイするディレクトリーの組み合わせです。
  6. デプロイメントウィザードを完了し、必要なプロパティーを設定します。
バグを報告します。

32.5.8. コンテンツ履歴の追跡および変更の取り消し

デプロイメント履歴ページでは、コンテンツベースのリソースへの変更を追跡します。つまり、更新の試行、タイムスタンプ、およびバージョン番号が一覧表示されます。

図32.17 リソースのデプロイメント履歴

リソースのデプロイメント履歴
バンドルプロビジョニングシステムを介してスタンドアロンサーバーにデプロイされた Web アプリケーションには、変更を元に戻すための簡単なパスがあります。詳細ページには、デプロイしたバージョンに最新のデプロイメントに戻る Revert ボタンがあります。
ただし、サーバーグループまたはドメインへのデプロイメントは、同一のクリアパスを持ちません。コンテンツデプロイメントを元に戻す場合は、最終的にそれを別のバージョンに置き換えることになります。
直接のバージョンを変更できない場合には、パッケージを変更する方法があります。
  • ドメインデプロイメントまたはサーバーグループのデプロイメントがコンテンツリポジトリーに関連付けられている場合は、更新されたパッケージをコンテンツリポジトリーにアップロードし、変更を関連するリソースに同期します。
  • 更新されたパッケージをドメインデプロイメントにアップロードし、deploy を使用して操作をグループ 化して、更新されたパッケージをサーバーグループに送信します。
バグを報告します。

32.5.9. バージョン管理されたデプロイメントおよびサブデプロイメント

JBoss ON 3.3 および JBoss ON JBoss Enterprise Application Platform 6 プラグインは、JBoss Enterprise Application Platform 6 の管理対象デプロイメントとスタンドアロンデプロイメントの両方（WAR、SAR、JAR、EJB など）および Subdeployments（WAR、SAR、JAR、EJB など）をサポートします。Versioned Deployment（または Subdeployment）は、アーティファクトのバージョンがその名前（例： myapp-1.0.war、myapp-1.1.war、myapp-2.0.war）に組み込む際に存在します。デフォルトでは、アーティファクトが Versioned Deployment（または Subdeployment）として認識されると、そのバージョン番号が削除され、インベントリー内のその名前に一致するリソースが指定のバージョン番号で更新または作成されます。
たとえば、アーティファクト「myapp-1.1.war」がデプロイされている場合、JBoss ON JBoss Enterprise Application Platform 6 プラグインはインベントリーで「myapp.war」という名前のリソースを探し、バージョン番号を「1.1」にリセットします。そうでない場合は、「myapp.war」という名前の新しいリソースが作成され、バージョン番号が「1.1」になります。このアプローチの利点は、JBoss ON が複数の個別のリソース（例： myapp-1.0.war や myapp-1.1.war）ではなく、バージョン管理されたアーティファクトを単一のリソースとして追跡できることです。これにより、リソースの過去のデータをすべてそのまま維持でき、以前のバージョンのリソースが「DOWN」状態で永続的に表示されるのを回避できます。
JBoss ON はデフォルトでアーティファクトに「Maven-style」バージョンを使用します。これには、バージョンのタイムスタンプをダッシュで区切って区切り、少なくともメジャーバージョンとマイナーバージョンをピリオドで区切る必要があります。
JBoss ON では、デフォルトで以下の正規表現が使用されます。 
^(.*?)-([0-9]+\\.[0-9].*)(\\..*)$
注記
バージョン管理スキームと一致しないアーティファクトは個別のリソースとして表示されます。たとえば、myapp-1.war、myapp-2.war、myapp1.war、および myapp2.war は 4 つの異なるリソースとして表示されます。
注記
Versioned Deployments および Subdeployments を無効にするには、JBoss ON JBoss Enterprise Application Platform 6 プラグインで versionedSubsystemDiscovery パラメーターを無効にすることができます。このプロパティーが更新されるには、起動前に適用可能なエージェントごとに更新する必要があります。
バグを報告します。

32.5.9.1. 既存のリソース

初回起動時に、エージェントはバージョンスキームに一致する既存のリソースを変換しようとします。さらに、同じリソースの複数のバージョンが同時にデプロイされた場合（例： myapp-1.1.war および myapp-2.0.war）、JBoss ON は、同じ論理リソース(myapp.war)の両方へのアップグレードを試みます。このような場合に問題を解決するには、アップグレードの前に不必要なリソースを無効にするか、またはバージョン管理のデプロイメントを無効にする必要があります。
注記
Versioned Deployments を使用する場合は、MISSING ポリシーを DOWN（デフォルト）として設定する必要があります。この設定を変更すると、更新ウィンドウでリソースが削除されたり、無視されてしまう可能性があります。
バグを報告します。

32.5.10. デプロイメントのトラブルシューティング

問：
デプロイメントでは失敗と示唆されますが、パッケージの再デプロイを試みると、リソースがすでに存在することを示すため、失敗します。
答：
考えられる原因の 1 つが、パッケージのデプロイ時のタイムアウト設定です。タイムアウト時間は、デプロイ操作が失敗した場合に JBoss ON サーバーが待機する時間を設定します。これは、実際にデプロイ操作自体を停止したり、制限したりしません。操作がタイムアウトの制限に達する場合でも、操作は正常に完了し、Web アプリケーションが正常にデプロイされます。
操作がタイムアウトすると、エージェントは新しいリソースを自動的に検出しません。Web アプリケーションは手動でインベントリーにインポートする必要があります。
問：
サーバーグループにパッケージをデプロイしようとしましたが、デプロイメントが一覧に表示されません。
答：
考えられる原因は以下のとおりです。
  • エージェント検出スキャンが実行されていません。検出の実行には数時間かかる可能性があるため、アプリケーションが検出キューに表示されるまで時間がかかる場合があります。これを回避するには、エージェントで検出スキャンを実行します。
  • パッケージが ドメイン にすでにデプロイされている。サーバーグループでデプロイメント子を作成すると、実際に（コンテンツが保存される）ドメインにデプロイメントを作成し、そのデプロイメントをサーバーグループにデプロイします。パッケージがドメインにすでに存在する場合は、サーバーグループでデプロイメントを複製として再度作成しようとすると失敗します。
    この場合は、デプロイを使用してドメインコントローラーでサーバーグループ 操作を行い、アプリケーションをデプロイします。
バグを報告します。