コンテンツライフサイクル管理
コンテンツライフサイクル管理により、プロダクションクライアントを更新する前にパッケージをカスタマイズおよびテストできます。 これは、限られたメンテナンスウィンドウ中に更新を適用する必要がある場合に特に便利です。
コンテンツライフサイクル管理では、ソフトウェアチャンネルをソースとして選択し、必要に応じて環境に合わせて調整して、運用クライアントにインストールする前に徹底的にテストすることがでます。
ベンダーチャンネルを直接変更することはできませんが、それらをクローンし、パッケージやカスタムパッチを追加または削除することでクローンを変更できます。 これらのクローンチャンネルをテストクライアントに割り当てて、期待通りに機能することを確認できます。
|
デフォルトでは、クローンされたベンダーチャンネルは元のベンダーチャンネルと一致し、自動的に依存関係を選択します。 クローンチャンネルの自動選択を無効にするには、`/etc/rhn/rhn.conf`に次のオプションを追加します。 java.cloned_channel_auto_selection = false |
次に、すべてのテストに合格すると、クローンチャンネルを運用サーバにプロモートできます。
これは、ソフトウェアチャンネルがライフサイクルの中で移動できる一連の環境を通じて実現されます。 ほとんどの環境ライフサイクルには、少なくともテスト環境とプロダクション環境が含まれますが、必要に応じて環境をいくつでも持つことができます。
このセクションでは、基本的なコンテンツライフサイクル手順と利用可能なフィルターについて説明します。 より具体的な例については、コンテンツライフサイクル管理の例を参照してください。
1. コンテンツライフサイクルプロジェクトの作成
コンテンツライフサイクルを設定するには、プロジェクトから始める必要があります。 プロジェクトは、ソフトウェアチャンネルのソース、パッケージを見つけるために使用されるフィルター、およびビルド環境を定義します。
SUSE Multi-Linux Manager Web UIで、に移動し、プロジェクトの作成をクリックします。
`Label`フィールドに、プロジェクトのラベルを入力します。 `Label`フィールドには、小文字、数字、ピリオド、ハイフン、およびアンダースコアのみを入力できます。
`Name`フィールドに、プロジェクトのわかりやすい名前を入力します。
作成ボタンをクリックして、プロジェクトを作成し、プロジェクトページに戻ります。
ソースの割り当て/取り外しをクリックします。
`Sources`ダイアログで、ソースタイプを選択し、プロジェクトのベースチャンネルを選択します。 チャンネルが必須か推奨されるかに関する情報を含め、選択したベースチャンネルで使用可能な子チャンネルが表示されます。
必要な子チャンネルをオンにし、保存をクリックして、プロジェクトページに戻ります。 選択したソフトウェアチャンネルが表示されているはずです。
フィルターのアタッチ／デタッチをクリックします。
`Filters`ダイアログで、プロジェクトに割り当てるフィルタを選択します。 新しいフィルタを作成するには、新しいフィルタの作成をクリックします。
環境の追加をクリックします。
`Environment Lifecycle`ダイアログで、最初の環境に名前、ラベル、および説明を付けて、保存をクリックします。 `Label`フィールドには、小文字、数字、ピリオド、ハイフン、およびアンダースコアのみを入力できます。
ライフサイクルのすべての環境が完了するまで、環境の作成を続行します。 作成時に`Insert before`フィールドで環境を選択することで、ライフサイクルの環境の順序を選択できます。
2. フィルタタイプ
SUSE Multi-Linux Managerを使用すると、プロジェクトのビルドに使用するコンテンツを制御するためのさまざまなタイプのフィルタを作成できます。 フィルタを使用すると、ビルドに含めるパッケージや除外するパッケージを選択できます。 たとえば、すべてのカーネルパッケージを除外したり、特定のリリースのパッケージのみを含めたりできます。
サポートされているフィルタは次のとおりです。
-
パッケージのフィルタリング
-
by name（名前別）
-
by name, epoch, version, release, and architecture（名前、エポック、バージョン、リリース、およびアーキテクチャ別）
-
by provided name（指定された名前別）
-
-
パッチフィルタリング
-
by advisory name（アドバイザリ名別）
-
by advisory type（アドバイザリタイプ別）
-
by synopsis（概要別）
-
by keyword（キーワード別）
-
by date（日付別）
-
by affected package（影響を受けるパッケージ別）
-
-
モジュール
-
by stream（ストリーム別）
-
|
パッケージの依存は、コンテンツのフィルタリング中には解決されません。 |
フィルタで使用できるマッチャーは複数あります。 どのマッチャーが利用可能かは、選択したフィルタタイプによって異なります。
使用できるマッチャーは次のとおりです。
-
含む
-
一致（正規表現の形式を取る必要があります）
-
等しい
-
新しい
-
新しいか等しい
-
古いか等しい
-
古い
-
新しいか等しい
2.1. フィルタの`rule`パラメータ
各フィルタには、`Allow`または`Deny`に設定できる`rule`パラメータがあります。 フィルタは次のように処理されます：
-
パッケージまたはパッチが`Deny`フィルタを満たす場合は、結果から除外されます。
-
パッケージまたはパッチが`Allow`フィルタを満たす場合は、結果に含まれます（たとえ`Deny`フィルタによって除外されていたとしても）。`Allow`フィルタはパッケージフィルタにのみ作用し、`Allow`フィルタはパッチフィルタにのみ作用します。これは、パッケージフィルタを使用してフィルタリングされたパッケージをパッチフィルタを通じて再追加することができないことを意味します。また、その逆も同様です。
この動作は、一般的な`Deny`フィルタを使用して多数のパッケージまたはパッチを除外し、特定の`Allow`フィルタで特定のパッケージまたはパッチを「チェリーピック」する場合に役立ちます。
|
コンテンツフィルタは組織内でグローバルなものであり、プロジェクト間で共有できます。 |
|
プロジェクトにすでにビルドされたソースが含まれている場合、環境を追加すると自動的に既存のコンテンツで満たされます。 コンテンツは、サイクルの前の環境から引き出されます。 前の環境がない場合、プロジェクトソースが再度ビルドされるまで空のままにされます。 |
3. フィルタテンプレート
一般的なシナリオのフィルタを作成するのを助けるために、SUSE Multi-Linux Manager はフィルタテンプレートを提供します。 適用されると、これらのテンプレートは特定の使用ケースに合わせたフィルタのセットを事前に作成するのに役立ちます。
このセクションでは、使用可能なテンプレートとその使用方法について説明します。
3.1. SUSE 製品に基づくライブパッチを適用する
ライブパッチを適用するプロジェクトでは、クライアントに提供される更新としてライブパッチパッケージのみが提供されるように、通常の将来のカーネルパッケージは除外する必要があります。一方、すでにインストールされている通常のカーネルパッケージは、システムの整合性を保つために含める必要があります。
このテンプレートを適用すると、この動作を実現するために必要な3つのフィルタが作成されます。
-
ベースカーネルバージョンと同じ`kernel-default`パッケージを含むパッチを許可する
-
`reboot_suggested`キーワードを含むパッチを拒否する
-
`installhint(reboot-needed)`という名前を提供するパッケージを含むパッチを拒否する
ライブパッチを適用するプロジェクトの設定方法についての詳細は、administration:content-lifecycle-examples.adoc#exclude-higher-kernel-version を参照してください。
SUSE Multi-Linux Manager Web UI で、 に移動し、フィルタの作成 をクリックします。
ダイアログで、テンプレートを使用 をクリックします。入力はそれに応じて変更されます。
`Prefix`フィールドに、名前のプレフィックスを入力します。この値は、テンプレートによって作成されたすべての個々のフィルタの名前の前に付加されます。テンプレートがプロジェクトのコンテキストで適用されている場合、このフィールドはプロジェクトラベルで事前に入力されます。
`Template`フィールドで、`Live patching based on a SUSE product`を選択します。
`Product`フィールドで、ライブパッチを適用する製品を選択します。
`Kernel`フィールドで、選択した製品の利用可能なバージョンのリストからカーネルバージョンを選択します。後の通常のカーネルパッチを拒否するためのフィルタは、このバージョンに基づいています。
保存をクリックして、フィルタを作成します。
に移動して、プロジェクトを選択します。
フィルタの割り当て／取り外しをクリックします。
指定したプレフィックスを持つフィルタを3つ選択し、保存をクリックします。
3.2. システムに基づくライブパッチ処理
特定の登録済みシステムにインストールされているカーネルバージョンに基づいてライブパッチ処理プロジェクトを設定する場合、「システムに基づくライブパッチ処理」テンプレートを使用できます。
このテンプレートを適用すると、この動作を実現するために必要な3つのフィルタが作成されます。
-
ベースカーネルバージョンと同じ`kernel-default`パッケージを含むパッチを許可する
-
`reboot_suggested`キーワードを含むパッチを拒否する
-
`installhint(reboot-needed)`という名前を提供するパッケージを含むパッチを拒否する
ライブパッチを適用するプロジェクトの設定方法についての詳細は、administration:content-lifecycle-examples.adoc#exclude-higher-kernel-version を参照してください。
SUSE Multi-Linux Manager Web UI で、 に移動し、フィルタの作成 をクリックします。
ダイアログで、テンプレートを使用 をクリックします。 入力はそれに応じて変更されます。
`Prefix`フィールドに、名前のプレフィックスを入力します。 この値は、テンプレートによって作成されたすべてのフィルタの名前の前に付加されます。 テンプレートがプロジェクトのコンテキストで適用されている場合、このフィールドはプロジェクトラベルで事前に入力されます。
`Template`フィールドで、`Live patching based on a specific system`を選択します。
`System`フィールドで、リストからシステムを選択するか、システム名の入力を開始してオプションを絞り込みます。
`Kernel`フィールドで、選択したシステムにインストールされているバージョンのリストからカーネルバージョンを選択します。 後の通常のカーネルパッチを拒否するためのフィルタは、このバージョンに基づいています。
保存をクリックして、フィルタを作成します。
に移動して、プロジェクトを選択します。
フィルタの割り当て／取り外しをクリックします。
指定したプレフィックスを持つフィルタを3つ選択し、保存をクリックします。
3.3. デフォルトのAppStreamモジュール
プロジェクトに含まれているモジュラーリポジトリですべてのモジュールを使用できるようにする場合は、このフィルタテンプレートを使用してモジュールを自動的に追加できます。
このテンプレートを適用すると、モジュールごとにAppStreamフィルタとそのデフォルトストリームが作成されます。
このプロセスがプロジェクトのページから行われる場合、フィルタは自動的にプロジェクトに追加されます。そうでない場合、作成されたフィルタはにリストされ、必要に応じて任意のプロジェクトに追加できます。
個々のフィルタを編集して別のモジュールストリームを選択したり、ターゲットリポジトリからそのモジュールを除外するために完全に削除したりできます。
|
すべてのモジュールストリームが互換性があるわけではないため、個々のストリームを変更すると、モジュール依存関係の解決が成功しない可能性があります。このような場合、プロジェクト詳細ページのフィルタペインには問題を説明するエラーが表示され、すべてのモジュール選択が互換性があるまでビルドボタンは無効になります。 |
|
Red Hat Enterprise Linux 9以降、モジュールには定義されたデフォルトストリームがありません。 したがって、Red Hat Enterprise Linux 9ソースを使用しても、このテンプレートは効果がありません。 |
コンテンツライフサイクル管理でAppStreamリポジトリを設定する方法についての詳細は、administration:content-lifecycle-examples.adoc#appstream-filtersを参照してください。
SUSE Multi-Linux Manager Web UIで、に移動して、プロジェクトを選択します。
`Filters`セクションで、Attach/Detach Filtersをクリックし、次にCreate New Filterをクリックします。
ダイアログで、テンプレートを使用 をクリックします。 入力はそれに応じて変更されます。
`Prefix`フィールドに、名前のプレフィックスを入力します。 この値は、テンプレートによって作成されたすべてのフィルタの名前の前に付加されます。 テンプレートがプロジェクトのコンテキストで適用されている場合、このフィールドはプロジェクトラベルで事前に入力されます。
`Template`フィールドで、`AppStream modules with defaults`を選択します。
`Channel`フィールドで、モジュールを取得するモジュラーチャンネルを選択します。このドロップダウンには、モジュラー チャンネルのみが表示されます。
保存をクリックして、フィルタを作成します。
`Filters`セクションまでスクロールして、新しく割り当てられたAppStreamフィルタを確認します。
個々のフィルタを編集/削除して、ニーズに合わせてプロジェクトを調整できます。
4. コンテンツライフサイクルプロジェクトの構築
プロジェクトを作成し、環境を定義し、ソースとフィルタを割り当てたら、初めてプロジェクトを構築できます。
構築によって、割り当てられたソースにフィルタが適用され、プロジェクトの最初の環境にそれらが複製されます。
同じベンダーチャンネルを複数のコンテンツプロジェクトのソースとして使用できます。 この場合、SUSE Multi-Linux Manager は各クローン チャンネルの新しいパッチ クローンを作成しません。 代わりに、すべてのクローン チャンネル間で単一のパッチ クローンが共有されます。 ベンダーがパッチを変更した場合、問題が発生する可能性があります。たとえば、パッチが取り消されたり、パッチ内のパッケージが変更された場合などです。 コンテンツプロジェクトのいずれかをビルドすると、クローンされたパッチを共有するすべてのチャンネルは、たとえそれらのチャンネルが他の環境や組織内の他のコンテンツプロジェクトのチャンネルであっても、デフォルトで元のパッチと同期されます。 組織設定で自動パッチ同期をオフにすることで、この動作を変更できます。 パッチを共有するすべてのチャンネルについて後でパッチを手動で同期するには、に移動し、同期したいチャンネルをクリックして、`Sync`サブタブに移動します。 手動のパッチ同期でも、パッチを共有するすべての組織チャンネルに影響します。
SUSE Multi-Linux Manager Web UI で、に移動し、ビルドしたいプロジェクトを選択します。
プロジェクトを構築する前に、利用可能な環境があることを確認してください。
割り当てられたソースとフィルタを確認し、ビルドをクリックします。
このビルドの変更または更新を説明するバージョンメッセージを提供します。
ビルドの進行状況は`Environment Lifecycle`セクションで監視できます。
ビルドが完了すると、環境バージョンが1つ増え、ソフトウェアチャンネルなどのビルドソースをクライアントに割り当てることができます。
5. 環境のプロモート
プロジェクトが構築されると、構築されたソースを順次、環境にプロモートできます。
SUSE Multi-Linux Manager Web UI で、に移動し、作業したいプロジェクトを選択します。
`Environment Lifecycle`セクションで、後継環境にプロモートする環境を見つけ、Promoteをクリックします。
ビルドの進行状況は`Environment Lifecycle`セクションで監視できます。
6. 環境にクライアントを割り当てる
コンテンツライフサイクルプロジェクトを構築し、促進する際に、SUSE Multi-Linux Managerはソフトウェアチャネルのツリーを作成します。 クライアントを環境に追加するには、クライアントの`System Details`ページでを使用して、ベースおよび子ソフトウェアチャネルをクライアントに割り当てます。
|
新しく追加されたクローンチャネルは、自動的にクライアントに割り当てられません。 ソースを追加または促進する場合は、チャネルの割り当てを手動で確認し、更新する必要があります。 自動割り当ては、今後のバージョンでSUSE Multi-Linux Managerに追加される予定です。 |