第28章 リソースレベルのコンテンツ更新の管理

パッケージ は、プラットフォームまたはサーバーやアプリケーションにインストールされているものです。これは、JAR ファイルまたは設定ファイルになります。パッケージは、リソースに何らかの形式のコンテンツを提供します。パッケージは JBoss ON-recognized リポジトリーを介してリソースに送信することも、JBoss ON サーバーにパッケージをアップロードしてからリソースに送信することもできます。

リソースは、リソースプラグインが利用可能なコンテンツと、サポートされるコンテンツの種類を認識している場合にのみ、コンテンツの関連付けまたは管理できます。たとえば、JBoss AS/EAP や Tomcat などのアプリケーションサーバーや Tomcat は EAR、WAR、JAR ファイルをコンテンツとしてサポートしますが、PostgreSQL などのデータベースではコンテンツタイプはサポートされません。

つまり、コンテンツは、リソースに関連するソフトウェアビット、スクリプト、設定ファイル、およびリソース自体の両方になります。コンテンツがリソースに追加されると、JBoss ON 階層の子リソースになりますが、新しいソフトウェアビットをアップロードすることで管理、元に戻す、更新、置き換えが可能です。親リソース（アプリケーションサーバーなど）はコンテンツをサポートします。子リソースは コンテンツバッキングリソースです。

コンテンツは、子リソースを手動で作成し（パッケージをアップロード）、またはパッケージをコンテンツソースに追加して親リソースにデプロイすると、リソースに追加できます。また、エージェントは、検出スキャンの一部として新規コンテンツをアクティブに チェック し、検出されたコンテンツをインベントリーに追加します。エージェントの繰り返しパッケージ検出スキャンには、サービススキャンのようにデフォルトの 24 時間間隔があります。

コンテンツソース は、開発者およびコンテンツの配布元です。ソースは、外部のサードパーティーのソフトウェア開発者またはカスタムコンテンツを作成する内部開発チームになります。ソースから利用できるコンテンツのタイプには、ソフトウェアパッケージ（設定スクリプトなど）と更新（バージョンアップグレード、パッチ、エラータ）の両方が含まれます。

リポジトリー は、ユーザー定義のソフトウェアパッケージのコレクションで、1 つまたは複数のコンテンツソースから取得できます。リポジトリーには、アプリケーションやアプリケーションファミリーのパッケージや、ノートパソコン設定用リポジトリーや Web サーバーのインストールリポジトリーなど、特定の目的でパッケージが含まれる場合があります。

リポジトリーは、パッケージ用のコンテナーを別々に分離したものではありません。基本的には、利用可能なパッケージのサブセットを示すビューです。すべてのパッケージは JBoss ON データベースに保存されます。JBoss ON リポジトリーは、これらのパッケージをグループ化して、リソースを使用した管理を容易にし、ユーザー(「リポジトリーおよびパッケージの認可」)のアクセス制御のメカニズムを提供する方法です。

リソースを JBoss ON に設定したコンテンツリポジトリーにサブスクライブできます。これにより、一貫性のある管理者が設定されたコンテンツをリソースに配信するためのスムーズで信頼できるメカニズムが提供されます。

パッケージは JBoss ON 内でバージョン管理され ます。パッケージがリソースまたはコンテンツソースに追加されると、インストーラーはバージョン番号の入力を求められます。これは UI のディスプレイ番号として使用されます。

この表示バージョン番号は必要ありません。指定されていない場合、JBoss ON サーバーは、パッケージの計算された SHA-256 チェックサム、および META-INF/MANIFEST.MF ファイル内の仕様バージョンおよび実装バージョン（EAR および WAR 用）を基に番号を取得します。

SPEC(IMPLEMENTATION)[sha256=abcd1234]

たとえば、バージョン番号が記載された META-INF/MANIFEST.MF ファイルの場合：

Manifest-Version: 1.0
Created-By: Apache Maven
Specification-Title: My Example App
Specification-Version: 1.0.0-GA
Specification-Vendor: Example, Corp.
Implementation-Title: My Example App
Implementation-Version: 1.x
Implementation-Vendor-Id: org.example
Implementation-Vendor: Example, Corp.
...

これにより、次のようなパッケージのバージョン番号が作成されます。

1.0.0-GA(1.x)[sha256=abcd1234]

この META-INF/MANIFEST.MF ファイルに仕様バージョンまたは実装バージョンのいずれかが含まれていない場合には、その 1 つのバージョンのみが使用されます。たとえば、実装バージョンのみが指定される場合：

(1.x)[sha256=abcd1234]

バージョン番号が指定されていない場合、SHA が識別子として使用されます。SHA は内部的に識別子として使用されます。

[sha256=abcd1234]

展開形式の WAR および EAR の場合、計算された SHA-256 チェックサムが MANIFEST.MF ファイルに追加されます。これにより、エージェントは検出スキャン中にファイルを確認して、パッケージのバージョンを迅速に検証できます。

Manifest-Version: 1.0
Created-By: Apache Maven
RHQ-Sha256: 570f196c4a1025a717269d16d11d6f37
...

アーカイブされていないコンテンツの場合、チェックサムはすべてのパッケージ検出スキャンで再計算され、インベントリー内のチェックサムと比較されます。

明確なバージョン管理システムでは、パッケージライフサイクルを明確かつ効果的な方法で処理できます。更新されたコンテンツはデプロイ時に追跡でき、更新は一貫して適用でき、パッケージを以前のバージョンに戻すことができます。同じリポジトリーに同じパッケージの異なるバージョンを含めることもできます。そのため、異なるリソースに異なるバージョンを適用することが可能です。

リソースにパッケージがインストールされると、そのリソースおよびパッケージのコンテンツ履歴に記録されます。1 つのパッケージに関連するファイルが複数あるため、コンテンツ履歴に複数のファイルが記録され、そのパッケージバージョンに関連付けられます。

ユーザーがリポジトリーのコンテンツにアクセスできるようにする必要がある理由は多くあります。最も一般的なのは、リソース上のパッケージを管理することですが、リポジトリーでサーバー CLI スクリプトを使用してアラートに応答するなど、その他の理由があります。

JBoss ON では、プライベート情報や機密情報を保護する必要性を考慮して、コンテンツへのクリアかつ簡単なアクセスの必要性をバランスを取ることができます。JBoss ON は、コンテンツリポジトリーの明確な 承認 ルールを定義します。

すべてのユーザーは、そのユーザーのパーミッションに関係なく、リポジトリーを作成し、パッケージをそのユーザーにアップロードする機能があります。

リポジトリーの作成時に、リポジトリーへのアクセスを制御する設定があります。

リポジトリーマネージャー（リポジトリーの管理権限を持つユーザー）は、リポジトリーの所有権およびプライバシー設定を変更できます。リポジトリーの管理権限を持たないユーザーはプライバシー設定を変更できますが、所有権を変更することはできません。リポジトリーは常に所有するか、リポジトリーマネージャーによって管理されます。

JBoss ON は リポジトリー のアクセス制御パーミッションを使用して、リポジトリーへの管理者アクセス権限を定義します。このパーミッションを持つユーザーは、リポジトリーの所有者に関係なく、設定されたリポジトリーを管理できます。所有者のないリポジトリーは、リポジトリーパーミッションを持つユーザーのみが管理できます。最後に、このパーミッションを持つユーザーのみがコンテンツソースをリポジトリーに関連付けることができます。他のすべてのユーザーは、パッケージをリポジトリーに手動で追加する必要があります。

コンテンツは、ディスク領域の要件に大きく影響する可能性があります。

JBoss ON はコンテンツのすべてのバージョンを保存します。これはバージョン管理の一部で、コンテンツベースのリソースを元に戻し、管理し、異なるバージョンを異なるタイミングにデプロイすることができます。

したがって、バックエンドデータベース（Oracle または PostgreSQL）をホストするシステムには、全バンドルのバージョンを保管するのに十分なディスク領域が必要です。また、データベース自体にコンテンツに適したテーブル空間が必要です。

必要な領域を算出する際に、すべてのアーティファクトのサイズを見積もり、次に各アーティファクトのバージョン数を計算します。少なくとも 2 倍の領域が利用可能です。PostgreSQL と Oracle の 両方で、vacuum、圧縮、およびバックアップおよび復元などのクリーンアップ操作を実行するには、PostgreSQL と Oracle の両方に 2 倍のデータベースサイズが必要です。