7.2. コンテンツビューのベストプラクティス
-
Red Hat Enterprise Linux や追加ソフトウェア (
Apache-2.4
やPostgreSQL-16.2
) などのコンテンツをコンテンツビューでバンドルすると、メンテナンスが容易になります。コンテンツビューが小さすぎる場合は、多くのメンテナンスが必要になります。 -
毎日更新されるコンテンツが必要な場合は、
Default Organization View
コンテンツビューを使用します。これは、すべてのリポジトリーからの最新の同期コンテンツを含んでおり、Library ライフサイクル環境で使用できます。 毎週更新するコンテンツビューと、毎月更新するコンテンツビューがある場合など、ホストに複数のコンテンツビューのコンテンツに対するアクセス権を付与するには、次の 2 つのオプションがあります。
- 複数のコンテンツビュー環境をホストに割り当てます。詳細は、「コンテンツビュー環境をホストに割り当てる」 を参照してください。
- 複合コンテンツビューをホストに割り当てます。詳細は、「コンテンツビュー環境と複合コンテンツビューの比較」 を参照してください。
- 複合コンテンツビューを使用する場合は、コンテンツビューを公開してから、複合コンテンツビューを公開します。複合コンテンツビューにバンドルするコンテンツビューの数が増えるほど、コンテンツの変更や更新に必要な労力も増えます。
- コンテンツビューが複合コンテンツビューにのみバンドルされている場合、そのコンテンツビューのライフサイクル環境を設定する必要はありません。
- Hammer スクリプトまたは Ansible Playbook を使用して、複合コンテンツビューとライフサイクル環境の作成と公開を自動化します。cron ジョブ、systemd タイマー、または反復ロジックを使用して可視性を確保します。
- 公開した各コンテンツビューまたは複合コンテンツビューのバージョンの説明に変更と日付を追加します。新しいライフサイクル環境へのコンテンツの移動など、最近のアクティビティーは、コンテンツ自体の最近の変更に関係なく、Satellite Web UI に日付別に表示されます。
- 新しいコンテンツビューまたは複合コンテンツビューを公開すると、新しいメジャーバージョンが作成されます。エラータの増分更新により、マイナーバージョンの番号が増加します。このカウンターを変更またはリセットすることはできないことに注意してください。