ライフサイクル環境の理解
ライフサイクル環境は、選択したバージョン管理されたコンテンツを順番に配信するためのユーザー定義のパイプラインです。
ライフサイクル環境に最適なインスタンスはアプライアンスのようなもので、インストールされているソフトウェアの変動に対する耐性は最小限です。更新は、バージョン管理されたカスタム・ソフトウェア・ソース内で定義するコンテンツの固定バージョンとしてインスタンスに提供します。コンテンツが変更されるのは、新しいバージョンが作成され、ステージに昇格されるときのみです。
最大5つのステージでライフサイクル環境を作成し、各ステージにインスタンスを割り当てることができます。次に、特定のパッケージ更新を使用してバージョン管理されたカスタム・ソフトウェア・ソースを作成し、ステージをプロモートします。プロモーションでは、バージョン設定されたソースのすべてのコンテンツがステージ内のインスタンスにインストールされます。
OS管理ハブでは、ライフサイクル環境はOracle Linux Managerなどの他の製品とは異なります。作成後は、バージョン管理されたソースを更新または変更できません。ライフサイクル環境内のインスタンスはアプライアンスに似ており、バージョン管理されたソースからすべてのコンテンツを受信します。更新の柔軟性を高める必要がある場合は、グループおよびカスタム・ソフトウェア・ソースを使用します。
FAQ
- ライフサイクル環境はどのように使用するのですか。
- バージョニング済カスタム・ソフトウェア・ソースとは何ですか。
- コンテンツをステージにプロモートするとどうなりますか。
- インスタンスをステージにアタッチするとどうなりますか。
- ステージからインスタンスをデタッチするとどうなりますか。
ライフサイクル環境はどのように使用するのですか。
ライフサイクル環境を使用するには:
- 必要なステージ(開発、テスト、本番など)でライフサイクル環境を作成します。少なくとも2つのステージが必要です。最大は5ステージです。
- ライフサイクル環境のステージにインスタンスを割り当てます。インスタンスは1つのステージにのみ存在できます。
- バージョン管理されたカスタム・ソフトウェア・ソースを作成して、インスタンスにデプロイするパッケージおよびモジュールを指定します。
- あるライフサイクル・ステージから次のステージ(開発からテスト、最後に本番など)へのパイプラインを介してバージョン管理されたソースを昇格します。プロモーションでは、ステージ内のインスタンスのバージョニングされたソースにすべてのコンテンツがインストールされます。コンテンツをステージにプロモートするとどうなりますか。を参照してください。
ライフサイクル環境に関するチュートリアルは、ビデオ: ライフサイクルを使用したOS更新の管理を参照してください。
バージョニング済カスタム・ソフトウェア・ソースとは何ですか。
バージョニング済カスタム・ソフトウェア・ソースは、ライフサイクル環境で特に使用されるカスタム・ソフトウェア・ソースです。「バージョン管理されたカスタム・ソフトウェア・ソースの作成」を参照してください。
バージョン管理されたカスタム・ソフトウェア・ソースには、いくつかの個別の属性があります。
- バージョン指定子: 作成時に、ソフトウェア・ソースにバージョンを割り当てます。
- 特定のパッケージ・コンテンツ: 作成時に、フィルタまたはパッケージ・リストを使用してコンテンツを制限します。バージョン管理されたカスタム・ソフトウェア・ソースには、ターゲット・インスタンスにインストールするパッケージおよびモジュールのみを含める必要があります。フィルタを使用してバージョン管理されたカスタムソフトウェアソースを作成する場合、latest-onlyオプションが必要です。
- 不変: 作成後は、ソフトウェア・ソースまたはそのバージョン内のパッケージおよびモジュールを変更できません。
バージョン管理されたカスタム・ソフトウェア・ソース内のパッケージおよびモジュールを慎重に選択します。ライフサイクル・ステージに昇格すると、サービスはバージョニングされたソースのすべてのコンテンツをターゲット・インスタンスにインストールします。
コンテンツをステージにプロモートするとどうなりますか。
バージョニングされたソースをライフサイクル・ステージに昇格する場合、サービスは次のことを行います。
- バージョニング済カスタム・ソフトウェア・ソースをライフサイクル・ステージに関連付けます。
- 以前にアタッチされたソフトウェア・ソースをインスタンスからデタッチします。
- ライフサイクル・ステージに関連付けられたバージョン管理されたカスタム・ソフトウェア・ソースをインスタンスにアタッチします。
- アタッチされたバージョン管理されたカスタム・ソフトウェア・ソースのすべてのパッケージおよびモジュールをインスタンスにインストールします。
インスタンスをステージにアタッチするとどうなりますか。
インスタンスは1つのステージのメンバーです。次のいずれかの方法を使用して、ライフサイクル環境のステージにインスタンスを割り当てることができます。
インスタンスをライフサイクル・ステージにアタッチする場合、サービスは次のことを行います。
- 以前にアタッチされたソフトウェア・ソースをインスタンスからデタッチします。
- ライフサイクル・ステージに関連付けられたバージョン管理されたカスタム・ソフトウェア・ソースをインスタンスにアタッチします。
- アタッチされたバージョン管理されたカスタム・ソフトウェア・ソースのすべてのパッケージおよびモジュールをインスタンスにインストールします。
ライフサイクル・ステージにバージョン管理されたカスタム・ソフトウェア・ソースがまだプロモートされていない場合、インスタンスは変更されません。ただし、インスタンスはスタンドアロンとして管理できなくなりました(スタンドアロン・インスタンスの更新など)。バージョン管理されたソースの次のプロモーションでは、サービスはそれをステージのすべてのメンバーに添付し、すべてのコンテンツをインストールします。
ステージからインスタンスをデタッチするとどうなりますか。
ライフサイクル・ステージからインスタンスをデタッチする場合、サービスは次のことを行います。
- ライフサイクル・ステージからインスタンスを削除します。
- バージョン管理されたカスタム・ソフトウェア・ソースをデタッチします(インスタンスにソフトウェア・ソースはアタッチされません)。
インスタンスをデタッチすると、関連付けられたソフトウェア・ソースがなくなり、更新は受信されません。スタンドアロン・インスタンスとして管理することも、インスタンスをグループまたは別のライフサイクルに割り当てることもできます。
ライフサイクル・ステージを介したコンテンツの促進の例
次の例では、3つのステージ(開発、テストおよび本番)を持つライフサイクル環境を示し、ライフサイクル・ステージを使用して月次パッチ・リリースを管理する方法について説明します。
- 開発における新しい月次リリース
-
フリートがすでにパッチ・リリース
Monthly-2024.05
を実行しているとします。運用スタッフは、次の月次リリースの準備を開始します。新しいバージョン管理されたカスタム・ソフトウェア・ソース(Monthly-2024.06
)を作成し、それをプロモートします。サービスは、開発ステージのインスタンスに対してMonthly-2024.06
のすべてのコンテンツをインストールします。
- テストに昇格されたリリース
-
Monthly-2024.06
で開発が完了すると、運用チームは、品質保証(QA)チームがテストを開始するテスト・ステージにコンテンツをプロモートします。サービスは、テスト・ステージのインスタンスに対してMonthly-2024.06
のすべてのコンテンツをインストールします。
- 開発における次の月次リリース
-
QAチームが
Monthly-2024.06
のテストと検証を続行すると、運用チームは次の月次リリースの作業アセンブルを開始します。操作によって、新しいバージョン管理されたカスタム・ソフトウェア・ソース(Monthly-2024.07
)が作成され、開発ステージに昇格されます。サービスは、開発ステージのインスタンスに対してMonthly-2024.07
のすべてのコンテンツをインストールします。