Red Hat Training
A Red Hat training course is available for Red Hat JBoss Operations Network
第27章 バンドルへのコンテンツおよびアプリケーションのデプロイ
27.1. コンテンツバンドルのプロビジョニングの概要
プロビジョニングは、管理者が開発から実稼働環境までアプリケーションを定義し、制御できる方法です。プロビジョニングシステムの影響は、アプリケーションのデプロイ方法を単純化することです。管理者は、同じアプリケーション定義（ バンドル定義）内で、異なるコンテンツソースから異なるリソースにデプロイされるアプリケーションのバージョンを制御できます。リソースを別のバージョンに戻すことも、デプロイメントを進めることもできます。
プロビジョニング は 1 つのファイルセット（バンドル）を取得し、これをプラットフォームまたはアプリケーションサーバー（宛先）にプッシュします。コンテンツ、宛先、およびデプロイメントのルールを定義するより複雑な方法がありますが、プロビジョニングがコンテンツを処理する際のコアとなる方法は、バージョンが付けられたバンドルを取り、これを指定されたリソースに送信する方法です。
プロビジョニングは、個別のリソースではなく、互換性のあるグループと連携します。管理者は、さまざまな環境に基づいてグループを定義し、すべてのグループメンバーにアプリケーションの変更（アップグレード、新規デプロイメント、または変換）を同時に適用できます。
また、デプロイ可能なコンテンツのタイプは柔軟です。バンドルには、raw 設定ファイル、スクリプト、ZIP アーカイブ、JAR ファイル、または完全なアプリケーションサーバーを含めることができます。コンテンツ の定義は非常に緩やかです。
これは、JBoss ON のリソースレベルのコンテンツ管理とは異なります。コンテンツのタイプは比較的制限されています。パッチまたは設定はリソースごとに適用されます。新しいアプリケーションは、既存リソースの子としてのみデプロイでき、別のリソースタイプである必要があります。
プロビジョニングは、純粋なリソース 管理ではなく、アプリケーション管理 に重点を置いています。
27.1.1. バンドル： コンテンツおよびレシピ
バンドル は、アーカイブにパッケージ化されるコンテンツのセットです。実際、バンドルは通常アプリケーションですが、アプリケーションまたはリソースの設定に必要な設定ファイル、スクリプト、ライブラリー、またはその他のコンテンツを含めることもできます。
バンドルの目的は、定義されたコンテンツのセットを取り、JBoss ON がリモートリソースにコピーすることです。プロビジョニングプロセスは基本的にターゲットリソースでアプリケーションをビルドするため、バンドルはアプリケーションディストリビューションです。各バンドルバージョンには、JBoss ON に、バンドルに存在するファイル、デプロイメントの実際の値を必要とする トークン、およびリモートマシン上のバンドルおよび既存ファイルの処理方法が通知される独自の レシピ があります。
レシピ、設定ファイル、およびコンテンツはすべてバンドルにまとめてパッケージ化されます。これは通常、プロビジョニング中にエージェントが展開する ZIP ファイルです。
JBoss ON で管理される他のコンテンツと同様に、バンドルはバージョン管理されます。異なるバージョンを異なるリソースにデプロイできます。このリソースは、異なる環境でさまざまなアプリケーションストリームを処理するのに適したものです（例： QA および実稼働環境）。また、バージョンバンドルを使用すると、JBoss ON はバンドルを簡単に元に戻すか、またはアップグレードできます。
バンドルにはほぼすべてのコンテンツを含めることができますが、JBoss ON によって適切にデプロイされるように特定の構造に従う必要があります。レシピは呼び出された Ant ビルドファイルです
deploy.xml。これは常にバンドルアーカイブの最上位に置く必要があります。
レシピの配置以降、バンドル内のファイルやディレクトリーはアーカイブのどこにでも配置できます。実際、ファイルは必ずしもバンドルファイルに組み込まれる必要がありません。バンドルの作成時には、バンドルのファイルまたはすべてのファイルを URL からプルできます。これにより、コンテンツが SVN または GIT リポジトリー、FTP サーバー、または Web サイトから取得できるようになります。
図27.1 バンドルレイアウト
バンドルアーカイブには、JAR、WAR、ZIP ファイルなどの他のアーカイブを含めることができます。プロビジョニングは Ant を使用してターゲットマシンにバンドルをビルドするため、Ant がバンドルの一部として処理できるファイルをすべて処理できます。Ant プロビジョニングシステムは WAR、JAR、および ZIP アーカイブファイルを処理できます。
27.1.2. 宛先（およびバンドルデプロイメント）
バンドルを JBoss ON にアップロードしてもバンドルはどこにもプッシュされないため、自動的にリソースまたはグループとは関連付けられません。（コンテンツとは異なり、バンドルはリソースに依存しません。JBoss ON では、インベントリーとは別に独自の定義として存在します。 バンドルが実際にプロビジョニングされる場合、プロビジョニングウィザードにより、管理者が 宛先 を定義するように求められます。
宛先は、バンドルがデプロイされる場所です。宛先は、3 つの要素の組み合わせです。
- 互換性のあるリソースグループ（プラットフォームまたは JBoss サーバーのいずれか）
- ベースの場所。バンドルのデプロイに使用するルートディレクトリー。リソースプラグインは、<bundle-target> 要素内の特定のリソースタイプのベースの場所を定義します。これは、ルートディレクトリーや、プロファイルディレクトリーなどの共通のディレクトリーである JBoss サーバーになります。利用可能なベースの場所が複数ある可能性があります。
- deployment ディレクトリー。バンドルのコンテンツが実際に送信されるベースディレクトリー下のサブディレクトリーです。
たとえば、管理者は
deploy/myApp/ ディレクトリー内の JBoss EAP 5 サーバーに web アプリケーションをデプロイします。JBoss AS5 プラグインは、インストールディレクトリー用と profile ディレクトリー用のベースの場所を 2 つ定義します。アプリケーションは展開形式の JAR ファイルであるため、管理者はプロファイルディレクトリーを選択します。次にエージェントは、これらの 3 つの要素からアプリケーションの実際の絶対パスを取得します。
JBoss AS group + {$PROFILE_DIR} + deploy/myApp/
PROFILE_DIR がの場合
/opt/jbossas/default/server/、宛先は以下のようになります。
/opt/jbossas/default/server/deploy/myApp/
同じリソースグループに Windows サーバーで実行されている JBoss EAP インスタンスが含まれる場合、PROFILE_DIR を持つパスは
C:\jbossas\server\、プラットフォームに適したパスが若干異なります。
C:\jbossas\default\server\deploy\myApp
エージェントは、そのインベントリーのプラットフォームおよびリソース情報に基づいて作成され、バンドルをデプロイする宛先の絶対パスを決定します。
バンドルが実際に宛先にデプロイされると、その関連付け（バンドルバージョンおよび宛先）がバンドルデプロイメントになり ます。
図27.2 バンドル、バージョン、および宛先
27.1.3. プロビジョニング中のファイル処理
デプロイメントにおける動作
バンドルファイルには、リソースにプッシュする必要があるファイルおよびディレクトリーのセットが含まれます。ただし、プロビジョニングプロセスでは、単にファイルをデプロイメントディレクトリーにコピーする訳ではありません。プロビジョニングはバンドルを、基本的にターゲット(root)ディレクトリーのコンテンツ構造全体を定義するテンプレートとして扱います。
たとえば、バンドルには以下のファイルが含まれます。
app.conf lib/myapp.jar
root ディレクトリーがの場合
deploy/myApp/、最終的な設定は以下のようになります。
deploy/myApp/app.conf deploy/myApp/lib/myapp.jar
デフォルトでは、ファイルにファイルがある場合は
deploy/myApp/、バンドルがコピーされる前に削除されます。これにより、デプロイメントディレクトリーはバンドルの設定方法が完全に表示されます。
のようなアプリケーション固有の宛先では、定義されたアプリケーションコンテンツがそのディレクトリーにある唯一のコンテンツであるため
deploy/myApp/、この動作は完全に許可されます。ただし、バンドルにはさまざまなコンテンツを含めることができ、ほぼプラットフォームや JBoss サーバー内にデプロイできます。実際のインフラストラクチャーの多くは、バンドルがデプロイされるディレクトリーには既存のデータを保持する必要がある場合があります。
deployment ディレクトリーはバンドルの ルートディレクトリー です。バンドルのレシピは、プロビジョニングプロセスにそのルートディレクトリー内のデータを処理する方法を指示するパラメーターを定義できます。特に、root ディレクトリー内の既存ファイルおよびサブディレクトリーを無視し(preserve)するか、root ディレクトリーを 管理 してバンドル構造と一致するようにする必要があります。
レシピ の コンプライアンスオプションは、すべてのものを削除して、ディレクトリーがバンドルコンテンツに一致するように強制するかどうかをプロビジョニングシステムに指示します。デフォルトは 満杯 になります。バンドルはルートディレクトリーのコンテンツと構造を定義します。そのディレクトリーのデータを保存する必要がある場合は、compliance オプションを filesAndDirectories に設定できます。つまり 、 プロビジョニングはバンドルを通じてコピーされ、適切なファイルおよびサブディレクトリーを作成しますが、ディレクトリー内の既存のコンテンツを管理（削除）しません。
警告
プラットフォームや、などの重要なディレクトリーにバンドル
/etc をデプロイする場合 deploy/ conf/、そのディレクトリーにある既存ファイルおよびサブディレクトリーがすべて削除されます。これにより、パフォーマンスの問題やデータ損失が発生する可能性があります。
バンドルおよびサブディレクトリー
compliance オプションが filesAndDirectories に設定されていても 、 バンドルに含まれるサブディレクトリーやファイルは、バンドルのデプロイ前に存在していた場合でも常にバンドルによって管理されます。
たとえば、
deploy/ ディレクトリーには、バンドルがデプロイされる前にこのレイアウトがあります。
deploy/ deploy/notes.txt deploy/myApp1/ deploy/myApp2/ deploy/myApp2/first.txt
バンドルは以下のレイアウトで作成されます。
myApp2/ myApp2/foo.txt myApp2/bar.txt
filesAdDirectories に設定する と、そのディレクトリー compliance はバンドルによって定義されるため、
myApp2/ サブディレクトリーに ある 既存ファイルは deploy/ 変更されません。つまり、ディレクトリーの最終的なレイアウトは以下のようになります。
deploy/ (ignored) deploy/notes.txt (ignored) deploy/myApp1/ (ignored) deploy/myApp2/ (managed) myApp2/foo.txt (managed) myApp2/bar.txt (managed)
注記
root ディレクトリー内の既存のコンテンツは削除前にバックアップされるため、後で復元できます。
バックアップディレクトリーは resourceID
/home/.rhqdeployments/です/backup。
バンドルのデプロイ後に追加されたファイル
初回のデプロイメント後に、ログファイルや追加のデータなど、デプロイメントディレクトリーにファイルが追加されるインスタンスが存在する可能性があります。
デプロイメントディレクトリー内では、プロビジョニングプロセスにより、バンドルに関連付けられたファイルを最新バージョンに上書きし、バンドルに含まれていないファイルを削除します。ログファイルおよびその他のデータ - ルートディレクトリーと同様に、アップグレード間で保持する必要があります。既知のファイルとディレクトリーは、<rhq:ignore> 要素を使用してレシピで呼び出すことができます。これにより、デプロイメントディレクトリー 内 のファイルを無視してプロビジョニングプロセスに指示します。
レシピでこれらのオプションを設定する方法は、を参照してください 「警告： 管理対象（ターゲット）のディレクトリーおよび上書き/保存ファイル」。
27.1.4. 要件およびリソースタイプ
デフォルトでは、3 つのリソースタイプがバンドルをサポートします。
- プラットフォーム、全タイプ
- JBoss EAP 6(AS 7)スタンドアロンサーバー [5]
- JBoss AS 5 プラグインを使用する JBoss EAP 5 およびすべてのサーバー
- JBoss EAP 4（非推奨）
バンドルサポートはプラグイン記述子で定義されるため、これらのリソースタイプのバンドルサポートを追加するカスタムプラグインを作成できます。バンドルサポートのあるエージェントプラグインを 『作成する例は、「カスタム JBoss ON プラグイン』 」を参照してください。
27.1.5. Provisioning and Agent User System Permission
バンドルがデプロイされると、エージェントが実行しているシステムユーザーにそのディレクトリーへの書き込み権限がある限り、プロビジョニングプロセスでバンドルファイルをシステム上の任意のディレクトリーに書き込むことができます。
で説明されているように 4章エージェントおよびリソースのシステムユーザーとの対話、エージェントが使用するシステムユーザーは、JBoss ON のパフォーマンス全体において重要です。1 つ目は、システムユーザーが適切なグループに参加し、リソースを効果的に管理するための適切な書き込みアクセスを付与する必要があります。一方、特に、バンドルを使用してシステムコンテンツや設定を処理する場合は、エージェントユーザーに過剰なパーミッションが付与されていないか、またはプロビジョニングプロセス自体が不正に使用されている可能性があることが重要です。
エージェントユーザーが持つ権限に関係なく、プロビジョニングシステムとデプロイされたバンドルは使用できます。デプロイされたバンドルには、エージェントユーザーの全システム権限があります。
エージェントがインストールされている場合は、必要なシステムパーミッションを評価することが重要です。また、デプロイされたアプリケーションまたは設定ファイルが望ましくないシステムの変更や不正使用を防ぐために、エージェントユーザーが持つ権限を評価し、バンドル自体のデプロイメントパスを計画することが重要です。
27.1.6. プロビジョニングおよびロール
バンドルグループレベルおよびグローバルパーミッションのセットは、バンドルのさまざまな管理ポイントに必要です。バンドルを管理し、アプリケーションをデプロイできるように、ユーザーに適切なパーミッションを付与する必要があります。
バンドル管理は、バンドルバージョンの作成およびリソースへのバンドルのデプロイという 2 つのタイプのタスクに分類されます。これらの各プロセスのワークフローは、組織構造、開発プロセス、および実稼働環境のルールで非常に明確に定義されます。たとえば、環境によっては、新しいバンドルを作成および削除したり、アクセス可能なリソースにコンテンツをデプロイしたりすることが許可されている場合があります。他の組織では、バンドル管理を特定のユーザーに制限したり、タスクを分割して、別のユーザーグループがバンドルをデプロイしている間に 1 つのグループがバンドルを作成できるようにする必要がある場合があります。
バンドルパーミッションはに一覧表示されますが 「アクセス制御およびパーミッション」、さまざまなグループのパーミッションを計画する一般的な例はに記載されてい 「拡張例： すべてのリソースの表示、一部のリソースの編集」 ます。
これは、一連のロールを作成して、希望のバンドルデプロイメントワークフローを並行して配置することです。つまり、ワークフローが明確に定義され、理解される必要があることを意味します。プロビジョニングプロセスのさまざまな部分には、主に 2 つの関係があります。バンドルの作成（JBoss ON データベースにアップロード）は、バンドル/ユーザー関係を定義します。バンドルのデプロイ（リソースへのコンテンツのコピー）は、バンドル/リソース関係を定義します。定義されたロールとパーミッションは、これを反映する必要があります。
リソースと同様に、バンドルは最初に バンドルグループのメンバーとしてロールで定義され、グループ 自体がロールに追加されます。デフォルトでは、すべてのバンドルは、作成時に少なくとも 1 つのグループに追加する必要があります。それらのグループは、アクセス権限を持つロールに属するグループに属するまで表示およびデプロイできません。例外として、グローバルビューバンドルパーミッションを付与することができます。これにより、どのグループにも属さない バンドル を作成できます。バンドルは 未割り当て という保持状態のままで、view バンドルパーミッションを持つユーザーのみがそれを確認できます（適切なパーミッションがあることを前提として、グループに追加できる場合のみ）。バンドルグループの作成については、を参照してください 「バンドルグループの管理」。
「拡張例： プロビジョニングプロセスでのバンドルグループおよびアクセス制御の使用」 基本的な権限モデルをいくつか説明し、さまざまな潜在的なバンドル/ユーザーとバンドル/リソース関係を定義します。
27.1.7. バンドルの領域に関する考慮事項
バンドルは、ディスク領域の要件に大きく影響します。
JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部であるため、バンドルへの変更を元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。
したがって、バックエンドデータベース（Oracle または PostgreSQL）をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。
必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。
27.1.8. バンドルおよび JBoss ON Server およびエージェントプラグイン
27.1.8.1. リソースサポートおよびエージェントリソースプラグイン
プロビジョニングがサポートされるかどうかは、リソース種別で定義されます。プロビジョニングを許可するリソースタイプの場合、リソースプラグイン記述子は バンドルターゲット を定義する必要があります。これは、プロビジョニングがサポートされるエージェントへの示唆です。
<bundle-target> 要素は、バンドル定義のベースディレクトリーとして使用できるリソースの許可されるベースディレクトリーを定義します。
<server name="JBossAS:JBossAS Server" ...>
<bundle-target>
<destination-base-dir name="Library Directory" description="Where the jar libraries are">
<value-context>pluginConfiguration</value-context>
<value-name>lib.dir</value-name>
</destination-base-dir>
<destination-base-dir name="Deploy Directory" description="Where the deployments are">
<value-context>pluginConfiguration</value-context>
<value-name>deploy.dir</value-name>
</destination-base-dir>
</bundle-target>
</server>
リソースプラグイン記述子はすべて、プロビジョニング設定とは別に、ベースディレクトリー、すべてのデプロイメントのルートを定義します。プラットフォームの場合は、root ディレクトリーです。サーバーの場合、通常はインストールディレクトリーになります。すでに設定されたベースディレクトリーを使用 <bundle-target> できますが、別のディレクトリーが使用できるように設定できます。この例では、ディレクトリー
deploy/ とディレクトリーの 2 つがサポート対象のベース lib/ ディレクトリーとして提供されます。バンドル定義が作成されると、ウィザードは使用するディレクトリーを選択できます。
27.1.8.2. レシピタイプのサーバー側のプラグインおよびエージェントプラグイン
デフォルトでは、JBoss ON は Ant ビルドファイルという 1 種類のレシピをサポートします。ただし、他のタイプのレシピは、レシピの種別がサーバー用およびエージェント用のプラグインのペアで定義されているためです。
サーバー側のプラグインは、JBoss ON サーバーに、そのタイプのレシピのバンドルと宛先を管理する方法を指示します。
エージェントプラグインは、プラットフォームまたはターゲットリソースでプロビジョニング操作を実行するために使用されるプラットフォームの子リソースを作成します。たとえば、Ant バンドルは、特定の JBoss ON リソースである Ant Bundle Handler によって実際にデプロイされます。このリソースは子リソースとしてプラットフォームに自動的に追加され、Ant ベースのプロビジョニングが有効になります。
注記
レシピタイプのサポートは特別なリソースを介してエージェント側で実装されるため、プロビジョニングを実行するにはそのリソースは JBoss ON インベントリーに存在する必要があります。たとえば、プラットフォームのインベントリーに Ant bundle ハンドラーがないと、JBoss ON はそのプラットフォームでプロビジョニングを実行できません。
管理者は Ant バンドルハンドラーリソースと直接対話する必要はありませんが、Ant プロビジョニングが機能するには、子リソースがプラットフォームのインベントリーに存在する必要があります。
27.1.9. JBoss ON CLI を使用したバンドルの管理およびデプロイ
JBoss ON にバンドルをアップロードし、リソースへのバンドルのデプロイは JBoss ON CLI を使用して実行できます。
新しいアプリケーションサーバーのコンテンツまたは設定の更新を JBoss ON 全体の他のリソースでのアクティビティーに基づいて自動的にデプロイできるため、バンドルデプロイメントをスクリプト化する機能は非常に強力なものです。これは、アラートに対応して JBoss ON CLI スクリプトを使用する場合に特に便利です。
- 既存の JBoss サーバーのパフォーマンスが大きい場合やパフォーマンスが低下すると、新しい JBoss アプリケーションサーバーをデプロイすることができます。
- 選択したスナップショットイメージの設定ファイルは、ドリフトアラートに対応して、プラットフォームまたは JBoss サーバーに即座にデプロイして、設定のドリフトを再処理できます。
- 新しい Web コンテキストは、mod_cluster ドメイン内で別の Web が無効になっている場合にデプロイできます。
スクリプトにより、QE 環境への日次または週ごとの更新のスケジュールなど、スケジュールに更新を適用することもできます。また、ビルドシステムが使用する GIT または SVN リポジトリーからバンドルコンテンツを最初にプルし、その後のテストにデプロイできるために役立ちます。
バンドル API は、の API ガイドを参照してください https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Operations_Network/3.3/index.html。
