第6章 アプリケーションライフサイクルの作成

ここまで見てきたように、アプリケーションライフサイクルはあるステージでシステムがどのように表示されるかを定義します。しかし、実際のライフサイクルは、組織と、組織が特定の実稼働チェーンを構成する方法によって異なります。

たとえば、メールサーバーの場合は、実際の使用における実稼働レベルのサーバーと、最新のメールサーバーパッケージをテストするテストサーバーという、単純なアプリケーションライフサイクルのみを必要とします。テストサーバーが初期段階をパスすれば、実稼働レベルのサーバーで新パッケージを使用するように設定できます。

別の例としては、ソフトウェア製品の開発ライフサイクルがあります。開発環境でソフトウェアの新しい部分を開発し、品質保証環境でこれをテストしてベータ版としてプレリリースした後、実稼働レベルのアプリケーションとしてリリースします。

各アプリケーションライフサイクルでは、環境 と呼ばれる段階を使用します。各環境は、システムに対して特定の状態として機能します。各環境は前の環境に続くもので、アプリケーションライフサイクルを構成することになる環境チェーンを作り出します。アプリケーションライフサイクルはそれぞれ、初期の ライブラリー が備わった状態で開始し、これは Definitive Media Library (DML) 内の中央ソースとして機能します。ライブラリー環境には、ここまでの章で同期した全コンテンツが含まれています。ここからは、ライブラリー環境からリンクされる新たな環境を作成します。

本書のシナリオでは、ACME の Exampleware を開発してリリースする単純なアプリケーションライフサイクルを作成します。初期環境にライブラリー環境を使用し、その後 開発、テスト、および 実稼働 の 3 つの環境をこの順に続けます。

新規環境パス をクリックして、新規のアプリケーションライフサイクルを起動します。ライブラリーに新規環境を追加するフォームが表示されます。名前 に Development と入力すると、ラベル が自動的に完了します。説明 に Environment for ACME’s Development Team と入力します。保存 をクリックします。

環境一覧に戻ります。開発環境の新たなテーブルが表示されます。このテーブルは、新規のアプリケーションライフサイクルを示します。これで残りの環境をアプリケーションライフサイクルに追加できます。

新規テーブルの上にある 新規環境の追加 をクリックします。名前 に Testing、説明 に Environment for ACME’s Quality Engineering Team と入力して、保存 をクリックします。

再度 新規環境の追加 をクリックします。名前 に Production、説明 に Environment for ACME's Product Releases と入力して、保存 をクリックします。

これで Development、Testing、および Production という 3 つの環境が揃ったテーブルのアプリケーションライフサイクルが表示されます。

# hammer lifecycle-environment create \
--name "Development" \
--description "Environment for ACME's Development Team" \
--prior "Library" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Testing" \
--description "Environment for ACME's Quality Engineering Team" \
--prior "Development" \
--organization "ACME"
# hammer lifecycle-environment create \
--name "Production" \
--description "Environment for ACME's Product Releases" \
--prior "Testing" \
--organization "ACME"

hammer lifecycle-environment paths コマンドでチェーンを確認できます。

# hammer lifecycle-environment paths --organization "ACME"
-----------------------------------------------
LIFECYCLE PATH
-----------------------------------------------
Library >> Development >> Testing >> Production
-----------------------------------------------

以下の手順は、Capsule Server を使用してコンテンツをプロビジョニングする環境に対するオプションです。

Capsule Server でコンテンツ機能が有効な場合は、環境を追加する必要があります。環境を追加すると、Capsule Server で Satellite Server のコンテンツを同期し、コンテンツをホストシステムに提供できます。

Capsule Server は、Satellite Server の Hammer CLI、または Web UI を使用して設定できます。

編集 をクリックします。

ライフサイクル環境タブで Env を選択します。

カプセルのコンテンツを同期するには、概要タブの 同期 ボタンをクリックします。

以下のいずれかのオプションを選択します。

# hammer capsule list

その ID を使用して、Capsule Server の詳細を確認します。

# hammer capsule info --id capsule_id_number

利用可能なライフサイクル環境を確認し、環境 ID を書き留めます。

# hammer capsule content available-lifecycle-environments \
--id capsule_id_number

利用可能なライフサイクル環境は Capsule Server に対して利用可能ですが、現在接続されていません。

ライフサイクル環境を Capsule Server に追加します。

# hammer capsule content add-lifecycle-environment \
--id capsule_id_number --environment-id environment_id_number

Capsule Server に追加する各ライフサイクル環境に対して手順を繰り返します。

Satellite Server 環境のすべてのコンテンツを Capsule Server に同期するには、以下のコマンドを実行します。

# hammer capsule content synchronize --id capsule_id_number

Satellite Server 環境の特定のライフサイクル環境を Capsule Server と同期するには、以下のコマンドを実行します。

# hammer capsule content synchronize --id external_capsule_id_number \
--environment-id environment_id_number

ライフサイクル環境への作業は『アーキテクチャーガイド』の「ライフサイクル環境」を参照してください。

アプリケーションライフサイクルのチェーンでは、コンテンツはある環境から次の環境に移動します。このプロセスは プロモーション と呼ばれます。プロモーションはアプリケーションライフサイクルでコンテンツを管理する基礎となるもので、これを理解することは重要です。

本ガイドのシナリオでは、ACME の Exampleware の開発が完了しており、実稼働しているとします。ACME は Exampleware コンテンツを RPM ファイルにパッケージ化し、これは別製品の一部となります。この状態では、ACME は Exampleware のバージョン 1.0 をリリースしており、このため exampleware-1.0-0.noarch.rpm が実稼働環境にあることになります。

ACME では、Exampleware のパッチをリリースするために、Exampleware バージョン 1.1 の開発を開始します。この例では、アプリケーションライフサイクルの環境に以下の Exampleware のバージョンが含まれます。

ACME では、パッチ開発の完了後、RPM をテスト環境にプロモートして、ACME の品質保証エンジニアチームがレビューできるようにします。この時点では、アプリケーションライフサイクルに以下のバージョンが含まれます。

品質保証エンジニアチームがレビューを行う間、開発チームは Exampleware 2.0 の作業に着手します。このため、アプリケーションライフサイクルは以下のようになります。

品質保証エンジニアチームがパッチのレビューを完了し、Exampleware 1.1 をリリースする準備が完了しました。ACME は 1.1 を実稼働環境にプロモートします。

開発チームが Exampleware 2.0 の作業を完了し、これをテスト環境にプロモートします。

最後に品質保証エンジニアチームがこのパッケージのレビューを行います。レビューが完了したら、パッケージを実稼働環境にプロモートします。

この例では、ACME の開発プロセスを Red Hat Satellite 6 アプリケーションライフサイクルにマッピングする手順を説明します。各環境には、Red Hat Satellite 6 に登録したシステムが含まれ、そのシステムがアクセスできるのは、各環境に関連するリポジトリーに限られます。ある環境から次の環境にパッケージをプロモートすると、プロモート先のリポジトリーはパッケージの新バージョンを受け取ります。この結果、プロモート先の環境にあるシステムはパッケージを新バージョンに更新することができます。

次章では、コンテンツビュー という概念を説明します。これは、ライブラリーから収集されフィルタリングされたコンテンツのコレクションで、リポジトリーに公開されたものです。Red Hat のリポジトリーとこれまでに同期したカスタムリポジトリーはソースコンテンツとして機能しますが、コンテンツビューは作成したリポジトリーがどのように表示されるかをカスタマイズするものです。コンテンツビューにはパッケージが含まれ、Satellite Server はアプリケーションライフサイクルの各環境にコンテンツビューをプロモートします。ある環境でコンテンツビュー (バージョン 1.0) を使用していても、次に新バージョン (バージョン 1.1) のコンテンツビューを受け取ります。この場合、バージョン 1.0 のリポジトリーは、Exampleware RPM の新バージョンが含まれているバージョン 1.1 のリポジトリーに置き換えられます。

新たに作成した Red Hat Satellite Capsule Server でコンテンツ機能が有効な場合は、Capsule Server に、Satellite Server からコンテンツを同期し、ホストシステムにコンテンツを同期するために有効にする環境を追加する必要があります。

コンテンツビューと、2 つ以上のライフサイクル環境から構成される環境パスを作成したら、必要に応じてコンテンツビューを次の環境にプロモートできます。つまり、指定された環境に存在するコンテンツビューの最新バージョンが、ライフサイクル環境パスの次の環境にプロモート (つまり、コピー) されます。

コンテンツビューは、そのバージョンが存在しない環境にプロモートできます。ライフサイクル環境パスの次の環境が自動的に提示されますが、この値は上書きでき、必要に応じて別の環境にプロモートできます。

以下の手順では、Red Hat Satellite からライフサイクル環境を削除する方法を説明します。

ライフサイクル環境を Capsule Server から削除する理由は複数あります。以下のような理由があります。

本章では、アプリケーションライフサイクルの概念と、それが Red Hat Satellite 6 のコンテンツ管理にどのように適用されるかを説明しました。また、Red Hat Satellite 6 がアプリケーションライフサイクルの各環境にコンテンツをプロモートする方法も説明しました。

次章では、コンテンツビューと、コンテンツビューを使用して、既存の DML からリポジトリーをフィルタリングする方法を説明します。