ライフサイクル環境の理解

ライフサイクル環境は、選択したバージョン管理されたコンテンツを順番に配信するためのユーザー定義のパイプラインです。

ライフサイクル環境に最適なインスタンスはアプライアンスのようなもので、インストールされているソフトウェアの変動に対する耐性は最小限です。更新は、バージョン管理されたカスタム・ソフトウェア・ソース内で定義するコンテンツの固定バージョンとしてインスタンスに提供します。コンテンツが変更されるのは、新しいバージョンが作成され、ステージに昇格されるときのみです。

最大5つのステージでライフサイクル環境を作成し、各ステージにインスタンスを割り当てることができます。次に、特定のパッケージ更新を使用してバージョン管理されたカスタム・ソフトウェア・ソースを作成し、ステージをプロモートします。プロモーションでは、バージョン設定されたソースのすべてのコンテンツがステージ内のインスタンスにインストールされます

ノート

OS管理ハブでは、ライフサイクル環境はOracle Linux Managerなどの他の製品とは異なります。作成後は、バージョン管理されたソースを更新または変更できません。ライフサイクル環境内のインスタンスはアプライアンスに似ており、バージョン管理されたソースからすべてのコンテンツを受信します。更新の柔軟性を高める必要がある場合は、グループおよびカスタム・ソフトウェア・ソースを使用します。

FAQ

ライフサイクル環境はどのように使用するのですか。

ライフサイクル環境を使用するには:

ライフサイクル環境に関するチュートリアルは、ビデオ: ライフサイクルを使用したOS更新の管理を参照してください。

バージョニング済カスタム・ソフトウェア・ソースとは何ですか。

バージョニング済カスタム・ソフトウェア・ソースは、ライフサイクル環境で特に使用されるカスタム・ソフトウェア・ソースです。「バージョン管理されたカスタム・ソフトウェア・ソースの作成」を参照してください。

バージョン管理されたカスタム・ソフトウェア・ソースには、いくつかの個別の属性があります。

  • バージョン指定子: 作成時に、ソフトウェア・ソースにバージョンを割り当てます。
  • 特定のパッケージ・コンテンツ: 作成時に、フィルタまたはパッケージ・リストを使用してコンテンツを制限します。バージョン管理されたカスタム・ソフトウェア・ソースには、ターゲット・インスタンスにインストールするパッケージおよびモジュールのみを含める必要があります。フィルタを使用してバージョン管理されたカスタムソフトウェアソースを作成する場合、latest-onlyオプションが必要です。
  • 不変: 作成後は、ソフトウェア・ソースまたはそのバージョン内のパッケージおよびモジュールを変更できません。

バージョン管理されたカスタム・ソフトウェア・ソース内のパッケージおよびモジュールを慎重に選択します。ライフサイクル・ステージに昇格すると、サービスはバージョニングされたソースのすべてのコンテンツをターゲット・インスタンスにインストールします。

コンテンツをステージにプロモートするとどうなりますか。

バージョニングされたソースをライフサイクル・ステージに昇格する場合、サービスは次のことを行います。

  • バージョニング済カスタム・ソフトウェア・ソースをライフサイクル・ステージに関連付けます。
  • 以前にアタッチされたソフトウェア・ソースをインスタンスからデタッチします。
  • ライフサイクル・ステージに関連付けられたバージョン管理されたカスタム・ソフトウェア・ソースをインスタンスにアタッチします。
  • アタッチされたバージョン管理されたカスタム・ソフトウェア・ソースのすべてのパッケージおよびモジュールをインスタンスにインストールします

関連項目: ライフサイクル・ステージを介したコンテンツの促進の例

インスタンスをステージにアタッチするとどうなりますか。

インスタンスは1つのステージのメンバーです。次のいずれかの方法を使用して、ライフサイクル環境のステージにインスタンスを割り当てることができます。

インスタンスをライフサイクル・ステージにアタッチする場合、サービスは次のことを行います。

  • 以前にアタッチされたソフトウェア・ソースをインスタンスからデタッチします。
  • ライフサイクル・ステージに関連付けられたバージョン管理されたカスタム・ソフトウェア・ソースをインスタンスにアタッチします。
  • アタッチされたバージョン管理されたカスタム・ソフトウェア・ソースのすべてのパッケージおよびモジュールをインスタンスにインストールします

ライフサイクル・ステージにバージョン管理されたカスタム・ソフトウェア・ソースがまだプロモートされていない場合、インスタンスは変更されません。ただし、インスタンスはスタンドアロンとして管理できなくなりました(スタンドアロン・インスタンスの更新など)。バージョン管理されたソースの次のプロモーションでは、サービスはそれをステージのすべてのメンバーに添付し、すべてのコンテンツをインストールします。

ステージからインスタンスをデタッチするとどうなりますか。

ライフサイクル・ステージからインスタンスをデタッチする場合、サービスは次のことを行います。

  • ライフサイクル・ステージからインスタンスを削除します。
  • バージョン管理されたカスタム・ソフトウェア・ソースをデタッチします(インスタンスにソフトウェア・ソースはアタッチされません)。
重要

インスタンスをデタッチすると、関連付けられたソフトウェア・ソースがなくなり、更新は受信されません。スタンドアロン・インスタンスとして管理することも、インスタンスをグループまたは別のライフサイクルに割り当てることもできます。

ライフサイクル・ステージを介したコンテンツの促進の例

次の例では、3つのステージ(開発、テストおよび本番)を持つライフサイクル環境を示し、ライフサイクル・ステージを使用して月次パッチ・リリースを管理する方法について説明します。

開発における新しい月次リリース

フリートがすでにパッチ・リリースMonthly-2024.05を実行しているとします。運用スタッフは、次の月次リリースの準備を開始します。新しいバージョン管理されたカスタム・ソフトウェア・ソース(Monthly-2024.06)を作成し、それをプロモートします。サービスは、開発ステージのインスタンスに対してMonthly-2024.06すべてのコンテンツをインストールします。


2つのソフトウェアソースを示すライフサイクルの例。最新のソースは開発ステージに昇格されます。
テストに昇格されたリリース

Monthly-2024.06で開発が完了すると、運用チームは、品質保証(QA)チームがテストを開始するテスト・ステージにコンテンツをプロモートします。サービスは、テスト・ステージのインスタンスに対してMonthly-2024.06すべてのコンテンツをインストールします。


2つのソフトウェアソースを示すライフサイクルの例。最新のソースは、「開発」から「テスト」ステージに昇格されます。
開発における次の月次リリース

QAチームがMonthly-2024.06のテストと検証を続行すると、運用チームは次の月次リリースの作業アセンブルを開始します。操作によって、新しいバージョン管理されたカスタム・ソフトウェア・ソース(Monthly-2024.07)が作成され、開発ステージに昇格されます。サービスは、開発ステージのインスタンスに対してMonthly-2024.07すべてのコンテンツをインストールします。


3つのソフトウェアソースを示すライフサイクル例。最新のソースは開発ステージに昇格されます。