8.5. コンテンツのライフサイクル
Satellite には、コンテンツライフサイクルを詳細に管理する各種機能が含まれています。ライフサイクル環境 は、コンテンツライフサイクルのステージを表し、コンテンツビュー は、フィルター機能があるコンテンツセットであり、コンテンツの定義済みのサブセットとみなすことができます。コンテンツビューをライフサイクル環境に関連付けることにより、定義された方法でホストがコンテンツを利用できるようにします。プロセスの視覚化については、図1.2「Red Hat Satellite のコンテンツライフサイクル」 を参照してください。コンテンツ管理プロセスの詳細な概要は、コンテンツの管理 の カスタムコンテンツのインポート を参照してください。以下のセクションでは、ライフサイクル環境と共にコンテンツビューをデプロイする一般的なシナリオを説明します。
ライブラリー と呼ばれるデフォルトのライフサイクル環境は、接続したすべてのソースからコンテンツを収集します。ホストをライブラリーに直接関連付けることは、ホストが利用できる前にコンテンツをテストできなくなるため推奨されていません。その代わりに、コンテンツのワークフローに適したライフサイクル環境パスを作成します。よくあるシナリオは以下のようになります。
単一ライフサイクル環境: ライブラリーのコンテンツは、実稼働ステージに直接プロモートされます。このアプローチでは、複雑さの面で制限がありますが、ホストで利用可能にする前に、ライブラリー内でコンテンツをテストできます。
単一ライフサイクル環境パス: オペレーティングシステムとアプリケーションコンテンツの両方が同じパスを通じてプロモートされます。パスは複数のステージ (開発、QA、実稼働 など) で構成できます。これにより、詳細なテストが可能になりますが、追加の作業が必要になります。
アプリケーション固有のライフサイクル環境パス: 各アプリケーションには異なるパスがあるため、アプリケーション別のリリースサイクルが可能になります。特定のコンピュートリソースをアプリケーションライフサイクルのステージに関連付けて、テストを容易にすることができます。しかしながら、このシナリオではメンテナンスが複雑になります。
以下はよくあるコンテンツビューのシナリオです。
- オールインワンコンテンツビュー: 大半のホストに必要なすべてのコンテンツが含まれるコンテンツビューです。コンテンツビューの数を減らすことは、リソース (時間、保存スペース) に制限のあるデプロイメントや、ホストタイプが同一のデプロイメントの場合に利点があります。ただし、このシナリオでは、時間ベースのスナップショットやインテリジェントなフィルタリングなどのコンテンツビューの各種機能が制限されます。コンテンツソースを変更すると、一部のホストに影響を及ぼします。
- ホスト固有のコンテンツビュー: 各ホストタイプの専用コンテンツビューです。このアプローチは、ホストタイプの数が少ない (最高 30) デプロイメントで役立ちます。ただし、この場合はホストタイプ間のコンテンツの共有や、ホストタイプ以外の基準に基づく分離 (オペレーティングシステムとアプリケーション間など) を防ぎます。重要な更新があった場合は、すべてのコンテンツビューを更新する必要があり、これによりメンテナンスの作業が増加します。
- ホスト固有の複合コンテンツビュー: 各ホストタイプ専用のコンテンツビューの組み合わせです。このアプローチにより、ホスト固有のコンテンツと共有コンテンツの分離が可能になります。たとえば、オペレーティングシステムやアプリケーションコンテンツ専用のコンテンツビューを使用できます。複合を使用すると、オペレーティングシステムとアプリケーションをさまざまな頻度で別々に管理できます。
- コンポーネントベースのコンテンツビュー: 特定のアプリケーションの専用コンテンツビューです。たとえば、データベースコンテンツビューはいくつかの複合コンテンツビューに組み込むことができます。このアプローチにより標準化のレベルが上がりますが、コンテンツビューの数が増えることにもなります。
最適なソリューションはホスト環境の性質によって異なります。コンテンツビューを作成しすぎないようにする必要がありますが、コンテンツビューのサイズも関連する操作 (公開、プロモート) の速度に影響を及ぼすことに注意してください。また、コンテンツビューのパッケージのサブセットを作成する際には、依存関係もすべて含まれていることを確認してください。キックスタートリポジトリーは、ホストのプロビジョニングにのみ使用されるため、コンテンツビューに追加できないことに注意してください。
