7.6. デプロイメントの動作のカスタマイズ
7.6.1. デプロイメントコンテンツのカスタムディレクトリーの定義
JBoss EAP では、デプロイされたコンテンツを格納する場所をカスタマイズし、定義できます。
スタンドアロンサーバーでのカスタムディレクトリーの定義
デフォルトでは、スタンドアロンサーバーのデプロイされたコンテンツは EAP_HOME/standalone/data/content
ディレクトリーに格納されます。この場所を変更するには、サーバーの起動時に -Djboss.server.deploy.dir
引数を渡します。
$ EAP_HOME/bin/standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content
選択する場所は JBoss EAP インスタンスすべてで一意になる必要があります。
jboss.server.deploy.dir
プロパティーは、管理コンソールまたは管理 CLI を使用してデプロイされたコンテンツの格納に使用されるディレクトリーを指定します。デプロイメントスキャナーによって監視されるカスタムデプロイメントディレクトリーを定義する場合は、デプロイメントスキャナーの設定 を参照してください。
管理対象ドメインでのカスタムディレクトリーの定義
デフォルトでは、管理対象ドメインのデプロイされたコンテンツは EAP_HOME/standalone/data/content
ディレクトリーに格納されます。この場所を変更するには、ドメインの起動時に -Djboss.domain.deployment.dir
引数を渡します。
$ EAP_HOME/bin/domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content
選択する場所は JBoss EAP インスタンスすべてで一意になる必要があります。
7.6.2. デプロイメント順序の制御
JBoss EAP では、サーバー起動時にアプリケーションがデプロイされる順序を細かく制御できます。複数の EAR ファイルに存在するアプリケーションのデプロイメント順序を徹底することができ、再起動後の順序を永続化することもできます。
jboss-all.xml
デプロイメント記述子を使用してトップレベルのデプロイメント間で依存関係を宣言できます。
たとえば、最初にデプロイされた framework.ear
に依存する app.ear
がある場合、以下のように app.ear/META-INF/jboss-all.xml
ファイルを作成できます。
<jboss xmlns="urn:jboss:1.0"> <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0"> <dependency name="framework.ear" /> </jboss-deployment-dependencies> </jboss>
デプロイメントのランタイム名を jboss-all.xml
ファイルの依存名として使用することができます。
これにより、app.ear
の前に framework.ear
がデプロイされます。
app.ear
で jboss-all.xml
ファイルを作成し、framework.ear
をデプロイしない場合、サーバーは app.ear
のデプロイを試行して失敗します。
7.6.3. デプロイメントコンテンツのオーバーライド
デプロイメントオーバーレイ を使用すると、デプロイメントアーカイブのコンテンツを物理的に変更せずに既存デプロイメントにコンテンツをオーバーレイすることができます。これにより、アーカイブを再構築せずに実行時にデプロイメント記述子、ライブラリー JAR ファイル、クラス、JSP ページ、およびその他のファイルをオーバーライドできます。
これは、異なる設定が必要な異なる環境にデプロイメントを適応する必要がある場合に便利です。たとえば、アプリケーションのライフサイクルに従って開発からテスト、ステージ、および実稼働とデプロイメントを移動する場合、目的の環境に応じてデプロイメント記述子の交換、アプリケーションのブランディングを変更するための静的 Web リソースの変更、JAR ライブラリーの別バージョンへの置き換えなどを行う可能性があります。また、方針やセキュリティーの制限によりアーカイブを変更できない、設定変更が必要なインストールにも便利な機能です。
デプロイメントオーバーレイを定義する場合、デプロイメントアーカイブのファイルを置き換える、ファイルシステム上のファイルを定義します。さらに、デプロイメントオーバーレイの影響を受けるデプロイメントを指定する必要もあります。変更を有効にするには、影響を受けるデプロイメントを再デプロイする必要があります。
パラメーター
以下のパラメーターのいずれかを使用して、デプロイメントオーバーレイを設定できます。
-
name
: デプロイメントオーバーレイの名前。 -
content
: ファイルシステム上のファイルをアーカイブの置き換えるファイルにマップするコンマ区切りリスト。各エントリーの形式はARCHIVE_PATH=FILESYSTEM_PATH
です。 -
deployments
: このオーバーレイがリンクされるデプロイメントのコンマ区切りリスト。 -
redeploy-affected
: 影響を受けるデプロイメントをすべて再デプロイします。
使用方法の詳細を表示するには deployment-overlay --help
を実行してください。
手順
deployment-overlay add
管理 CLI コマンドを使用してデプロイメントオーバーレイを追加します。deployment-overlay add --name=new-deployment-overlay --content=WEB-INF/web.xml=/path/to/other/web.xml --deployments=test-application.war --redeploy-affected
注記管理対象ドメインでは、
--server-groups
を使用して該当するサーバーグループを指定するか、--all-server-groups
を使用してすべてのサーバーグループを指定します。- デプロイメントオーバーレイの作成後、既存のオーバーレイへのコンテンツの追加、オーバーレイのデプロイメントへのリンク、またはオーバーレイの削除を行うことができます。
オプション: オーバーレイ設定を指定して、
<overlay>
の HTML、イメージ、またはビデオなどの静的 Web リソースが含まれる外部ディレクトリーにリンクできます。<overlay>
要素はアプリケーションのjboss-web.xml
ファイルにあります。この設定では、アプリケーションを再パッケージ化する必要はありません。以下の例は、
<overlay>
要素のシステムプロパティーの置換を示しています。${example.path.to.overlay} は /PATH/TO/STATIC/WEB/CONTENT の場所を定義します。例:
jboss-web.xml
ファイルの<overlay>
要素<jboss-web> <overlay>${example.path.to.overlay}</overlay> </jboss-web>
jboss-descriptor-property-replacement
がtrue
に設定されている場合、<overlay>要素
にシステムプロパティーを指定できます。jboss-descriptor-property-replacement
を設定するには、以下の管理 CLI コマンドを使用します。/subsystem=ee:write-attribute(name=jboss-descriptor-property-replacement,value=true)
このコマンドは、以下の XML コンテンツを JBoss EAP 設定の
ee
サブシステムに追加します。<subsystem xmlns="urn:jboss:domain:ee:4.0"> <jboss-descriptor-property-replacement>true</jboss-descriptor-property-replacement> </subsystem>
7.6.4. ロールアウト計画の使用
ロールアウト計画
管理対象ドメインでは、ドメインまたはホストレベルのリソースで目的となる操作は複数のサーバーに影響する可能性があります。このような操作には、サーバーに適用される操作の順序を説明するロールアウト計画や、一部のサーバーで実行に失敗した場合に操作を元に戻すかどうかを指示するポリシーなどが含まれます。指定されたロールアウト計画がない場合、デフォルトのロールアウト計画 が使用されます。
以下は 5 つのサーバーグループが関係するロールアウト計画の例になります。操作は順次 (in-series
) または同時 (concurrent-groups
) にサーバーグループへ適用することができます。構文の詳細は ロールアウト計画の構文 を参照してください。
{"my-rollout-plan" => {"rollout-plan" => { "in-series" => [ {"concurrent-groups" => { "group-A" => { "max-failure-percentage" => "20", "rolling-to-servers" => "true" }, "group-B" => undefined }}, {"server-group" => {"group-C" => { "rolling-to-servers" => "false", "max-failed-servers" => "1" }}}, {"concurrent-groups" => { "group-D" => { "max-failure-percentage" => "20", "rolling-to-servers" => "true" }, "group-E" => undefined }} ], "rollback-across-groups" => "true" }}}
上記の例を見ると、3 つの段階を経てドメインのサーバーに操作が適用されることが分かります。あるサーバーグループのポリシーによってサーバーグループ全体で操作のロールバックが引き起こされると、他のサーバーグループもすべてロールバックされます。
- サーバーグループ group-A と group-B には同時に操作が適用されます。group-A のサーバーには操作が順次適用され、group-B のすべてのサーバーは操作を同時に処理します。group-A で操作の適用に失敗したサーバーが 20 % を超えると、グループ全体でロールバックが実行されます。group-B で操作を適用できなかったサーバーがあると、このグループ全体でロールバックが実行されます。
- group-A と group-B のすべてのサーバーが完了すると、group-C のサーバーに操作が適用されます。これらのサーバーは操作を同時に処理します。group-C では操作を適用できなかったサーバーが 2 台以上あると、グループ全体でロールバックが実行されます。
- group-C のすべてのサーバーが完了すると、操作が group-D と group-E に同時に適用されます。group-D のサーバーには操作が順次適用され、group-E のすべてのサーバーは操作を同時に処理します。group-D で操作の適用に失敗したサーバーが 20 % を超えると、グループ全体でロールバックが実行されます。group-E で操作を適用できなかったサーバーがあると、このグループ全体でロールバックが実行されます。
ロールアウト計画の構文
ロールアウト計画は以下のいずれかの方法で指定できます。
-
deploy
コマンド操作ヘッダーでロールアウト計画を定義します。詳細は ロールアウト計画を使用したデプロイ を参照してください。 -
rollout-plan
コマンドを使用してロールアウト計画を保存し、deploy
コマンド操作ヘッダーでプラン名を参照します。詳細は 保存したロールアウト計画を使用したデプロイ を参照してください。
上記の方法で最初に使用するコマンドは異なりますが、どちらも rollout
操作ヘッダーを使用してロールアウト計画を定義します。以下の構文を使用します。
rollout (id=PLAN_NAME | SERVER_GROUP_LIST) [rollback-across-groups]
-
PLAN_NAME
は、rollout-plan
コマンドを使用して保存されたロールアウト計画の名前です。 SERVER_GROUP_LIST
はサーバーグループのリストです。各サーバーグループで操作を順次実行する場合はコンマ (,
) を使用して複数のサーバーグループを区切ります。各サーバーグループで同時に操作を実行する場合はキャレット (^
) を区切り文字として使用します。各サーバーグループでは、以下のポリシーをかっこで囲んで設定します。複数のポリシーはコンマで区切ります。
-
rolling-to-servers
: ブール値。true
に設定すると、操作はグループの各サーバーに順次適用されます。false
に設定した場合、または指定がない場合は、操作はグループのサーバーに同時に適用されます。 -
max-failed-servers
: 整数値。グループにおける操作の適用に失敗したサーバー合計数の最大率 (パーセント) で、失敗したサーバーの率がこの値を超えるとグループのすべてのサーバーが元に戻されます。指定がない場合のデフォルト値は0
で、操作の適用に失敗したサーバーが 1 台でもあるとグループ全体でロールバックが引き起こされます。 max-failed-servers
:0
から100
までの整数値。グループにおける操作の適用に失敗したサーバー合計数の最大率 (パーセント) で、失敗したサーバーの率がこの値を超えるとグループのすべてのサーバーが元に戻されます。指定がない場合のデフォルト値は0
で、操作の適用に失敗したサーバーが 1 台でもあるとグループ全体でロールバックが引き起こされます。注記max-failed-servers
とmax-failure-percentage
の両方がゼロ以外の値に設定された場合、max-failure-percentage
が優先されます。
-
-
rollback-across-groups
: ブール値。1 つのサーバーグループのサーバーすべてで操作をロールバックする必要があると、すべてのサーバーグループでロールバックの実行を引き起こすかどうかを指定します。デフォルトはfalse
です。
ロールアウト計画を使用したデプロイ
ロールアウト計画の完全詳細を直接 deploy
コマンドに提供するには、rollout
設定を headers
引数に渡します。形式の詳細は ロールアウト計画の構文 を参照してください。
以下の管理 CLI コマンドは、順次のデプロイメントに rolling-to-servers=true
を指定するデプロイメント計画を使用して、アプリケーションを main-server-group
サーバーグループにデプロイします。
deploy /path/to/test-application.war --server-groups=main-server-group --headers={rollout main-server-group(rolling-to-servers=true)}
保存したロールアウト計画を使用したデプロイ
ロールアウト計画は複雑になることがあるため、ロールアウト計画の詳細を保存するオプションがあります。これにより、毎回ロールアウト計画の完全詳細を必要とせずに、ロールアウト計画を使用するときにロールアウト計画の名前を参照することができます。
rollout-plan
管理 CLI コマンドを使用してロールアウト計画を保存します。形式の詳細は ロールアウト計画の構文 を参照してください。rollout-plan add --name=my-rollout-plan --content={rollout main-server-group(rolling-to-servers=false,max-failed-servers=1),other-server-group(rolling-to-servers=true,max-failure-percentage=20) rollback-across-groups=true}
これにより、以下のデプロイメント計画が作成されます。
"rollout-plan" => { "in-series" => [ {"server-group" => {"main-server-group" => { "rolling-to-servers" => false, "max-failed-servers" => 1 }}}, {"server-group" => {"other-server-group" => { "rolling-to-servers" => true, "max-failure-percentage" => 20 }}} ], "rollback-across-groups" => true }
アプリケーションのデプロイ時に保存されたロールアウト計画名を指定します。
以下の管理 CLI コマンドは、保存されたロールアウト計画
my-rollout-plan
を使用してすべてのサーバーグループにアプリケーションをデプロイします。deploy /path/to/test-application.war --all-server-groups --headers={rollout id=my-rollout-plan}
保存されたロールアウト計画の削除
削除するロールアウト計画の名前を指定して rollout-plan
管理 CLI コマンドを使用すると、保存されたロールアウト計画を削除できます。
rollout-plan remove --name=my-rollout-plan
デフォルトのロールアウト計画
複数のサーバーに影響する操作はすべてロールアウト計画を使用して実行されます。操作リクエストにロールアウト計画が指定されていない場合は、デフォルトのロールアウト計画が生成されます。計画には以下の特徴があります。
- ハイレベルなフェーズは 1 つのみです。操作に影響するすべてのサーバーグループには同時に操作が適用されます。
- 各サーバーグループ内では、操作がすべてのサーバーに同時に適用されます。
- サーバーグループのいずれかのサーバーに操作を適用できないと、グループ全体でロールバックが実行されます。
- あるサーバーグループに操作を適用できないと、他のすべてのサーバーグループでロールバックが実行されます。