test

Sun N1 Service Provisioning System 5.2 プランとコンポーネントの開発者ガイド

第 1 章 プランおよびコンポーネント開発の概念

この章では、Sun N1 Service Provisioning System ソフトウェア (これ以降、プロビジョニングシステム) に関連するプランとコンポーネントの概念について説明します。

この章の内容は次のとおりです。

コンポーネントの概念

コンポーネントは、アプリケーションを定義するリソースの論理的なグループです。アプリケーションを構成するリソースの扱い方を規定した一連の命令も含まれます。コンポーネントは、以下のように分けることができます。

プロビジョニングシステムを使用して、データセンター内のアプリケーションを管理できます。この製品でアプリケーションを管理するには、先にアプリケーションをコンポーネントとしてモデル化しておく必要があります。プロビジョニングシステムを使用すると、次の作業を行えます。

プロビジョニングシステムがサポートするコンポーネントの基本タイプは、次の 2 種類です。

複合コンポーネントには、コンポーネントの参照が含まれます。参照先のコンポーネントを包含コンポーネント (子コンポーネント) といいます。参照する側のコンポーネントをコンテナコンポーネント (親コンポーネント) といいます。

複合コンポーネントは、各包含コンポーネントについて、上位レベルコンポーネントとしてインストールするのか、それとも入れ子のコンポーネントとしてインストールするのかを宣言します。上位レベルとしてインストールされた包含コンポーネントは、プランによって直接インストールされた場合と同様、どのコンポーネントでも使用されます。ただし、包含コンポーネントが入れ子としてインストールされた場合、そのサービスを利用できるのはコンテナコンポーネントに限られます。入れ子の包含コンポーネントは、コンテナコンポーネントが必要とする、よりきめの細かい機能単位を定義します。ただし、ほかのコンポーネントにとっては有用ではありません。一方、上位レベルの包含コンポーネントでは、コンテナコンポーネントが使用するサービスを定義しますが、定義されたサービスはほかのコンポーネントも使用できます。

注 –

複合コンポーネントにはコンポーネントそのものではなく、ほかのコンポーネントの参照が含まれます。参照コンポーネントは、別の既存コンポーネントであり、コンテナコンポーネントとは別に更新され管理されます。1 つのコンポーネントを、任意の数の複合コンポーネントが参照できます。ほかの複合コンポーネントから参照されるかどうかで、コンポーネント名が変わることはありません。名前の衝突はパスを使用して解決されます。

プロビジョニングシステムは、コンポーネントに関連付けられる物理リソースを管理します。これには事前に定義された一連のコンポーネントも含まれます。このようなコンポーネントは直接使用することも、ほかのコンポーネントを作成するためのサンプルとして使用することもできます。

コンポーネントには手続きも組み込まれます。手続きは、コンポーネントに格納され、コンポーネントの配置を制御するプログラムです。コンポーネント手続きは通常、インストール、アンインストール、およびキャプチャのスナップショットとして定義します。その他の手続きは制御ブロックで定義できます。制御とは、コンポーネントに組み込まれた一連の命令であり、配備されたアプリケーションを管理する目的で使用できます。たとえばアプリケーションの起動や停止などを制御できます。コンポーネントには、ほかのコンポーネントへの依存を検査したり、特定のプロセスが動作しているかどうかを検証したりする命令を組み込むことができます。

コンポーネントでは置換変数も宣言できます。置換変数は、コンポーネント内で使用することも、コンポーネントに含まれる任意のリソースに使用することもできます。置換変数は、プランの実行時に置換する値のプレースホルダとして使用できます。

コンポーネントのモデル化

プロビジョニングシステムでは、非常に柔軟にコンポーネントをモデル化できます。モデル化するアプリケーションによって、次のどの方式を使用するかが決まります。

コンポーネントをチェックインすると、コンポーネントがビルドされ、特定のバージョンのリソースが割り当てられます。ビルドによりコンポーネントにもバージョン番号が割り当てられるため、そのコンポーネントの適切なバージョンが、コンポーネントリソースの特定のバージョンと常に関連付けられるようになります。

コンポーネントの特性

コンポーネントはさまざまな特性に基づいて識別されます。次に、代表的なコンポーネント特性について説明します。

コンポーネント手続き

コンポーネント手続き (または手続き) は、コンポーネントに組み込まれ、コンポーネントを管理するプログラムです。コンポーネント手続きはコンポーネントのインストール、アンインストール、または制御を行います。手続きはコンポーネントのビルド時に作成されます。

手続きの実行方法は次のとおりです。

コンポーネントには複数の手続きを指定できます。たとえば、制御手続きをコンポーネントに組み込むことで、そのコンポーネントがモデル化するアプリケーションの起動と停止を行います。

コンポーネントタイプの拡張により作成されたコンポーネントは、そのコンポーネントタイプによって定義された手続きを継承します。

複合コンポーネントを作成した場合は、デフォルトのインストールおよびアンインストール手続きを継承します。通常、コンポーネントは関連付けられるコンポーネントタイプから手続きを継承します。

コンポーネントの継承

コンポーネントの継承とは、コンポーネントが別のコンポーネントから属性や動作を取得する手段です。作成したコンポーネントは、関連付けられているコンポーネントタイプの変数、スナップショット、および手続きを継承します。

継承を用いることによって、強力かつ柔軟性の高いコンポーネントモデルになります。たとえば、IIS Aplication コンポーネントタイプに基づくコンポーネントが 1000 個あるとします。これらのコンポーネントに機能を追加するとします。IIS Application コンポーネントタイプに機能を追加することで、そのコンポーネントタイプに属する 1000 個のコンポーネントが新しい機能を継承することになります。

コンポーネント変数

コンポーネントでは 変数を使用できます。変数は値を格納するユーザー定義のコンテナであり、配備時に使用されます。

コンポーネント変数は、コンポーネントの外部にあるオブジェクトからコンポーネントの一部にアクセスして設定できるようにするために使用します。たとえば、コンポーネントにホスト単位で変更される installPath という変数を設定できます。この変数では、各コンポーネントのインストール先を定義します。

コンポーネント変数の値を別のコンポーネント変数への参照にすることができます。これには、コンポーネントのコンテナによって定義された変数が含まれます。コンテナコンポーネントに入れ子のコンポーネントを追加すると、ブラウザインタフェースは、参照変数がコンテナで定義されているかどうかを検証します。その変数がコンテナコンポーネントで定義されていない場合、ブラウザインタフェースは自動的に参照変数をコンテナの変数リストに追加します。

たとえば、単純コンポーネントは通常、installPath 変数がコンテナコンポーネントの installPath 変数の値を持つように定義します。この場合、参照変数の構文は :[container:installPath] です。変数置換についての詳細は、第 6 章「構成の生成」を参照してください。

コンポーネント変数は、コンポーネントの配備時に評価されて値が割り当てられます。コンポーネント変数を使用して、配備の実装に必要な情報 (ホスト名、IP アドレス、パスなど) を指定します。

変数設定値

変数設定値は、変数の値の集まりであり、1 つ以上のコンポーネント変数について、デフォルト値を変更する目的で使用できます。使用する変数設定値に基づいて、コンポーネント変数にさまざまな値を指定できます。どの変数設定値を使用するかは、プランの実行時に指定します。

たとえば、コンポーネントを運用環境および開発環境など、異なる環境に配備します。定義したコンポーネント変数が、環境間の相違を認識するように設定されている場合、変数設定値を使用することによって、各環境に合わせてコンポーネントを設定できます。たとえば、あるセットを使用して運用環境を設定し、別のセットで開発環境用にコンポーネントを設定することが可能です。

変数の優先指定

変数の優先指定によって、複合コンポーネントの変数のデフォルト値を上書きできます。単純コンポーネントでこの機能を使用することはできません。

コンポーネントにほかのコンポーネント (子コンポーネント) が含まれている場合、変数設定値が有効なのは上位レベルの親コンポーネントに限られます。すべての子コンポーネントは、デフォルトの変数値を使用します。子コンポーネントは、次の 2 通りの方法で、親コンポーネントから変数値を取得できます。

ステップ

ステップは、プランとコンポーネントの両方に組み込むことのできる単純な命令です。

ステップについては、「ステップの概要」 を参照してください。

コンポーネントタイプの概念

コンポーネントタイプとは、動作をカプセル化してほかのコンポーネントで再利用できるように設計されたコンポーネントです。コンポーネントタイプは通常、特定のアプリケーションタイプに固有の動作を意味します。たとえば、Enterprise JavaBeansTM (EJBTM) コンポーネントタイプには、アプリケーションサーバーとの間で相互に EJB アーカイブを配備したり配備を解除したりするために使用できる、汎用手続きが組み込まれます。コンポーネントをコンポーネントタイプから拡張すると、そのコンポーネントタイプで定義されている動作が自動的に継承されます。

コンポーネントは通常、コンポーネントタイプと関連付けられます。ブラウザインタフェースから untyped を選択した場合は、コンポーネントがほかのコンポーネントタイプから拡張されることはありません。プロビジョニングシステムには組み込みコンポーネントタイプがいくつかあります。第 3 章「組み込みコンポーネントタイプ」を参照してください。

単純コンポーネントが参照するファイル、ディレクトリ、およびその他のツリー構造は、コンポーネントに含まれる別々の単位として管理されます。

たとえば、プロビジョニングシステムが IIS アプリケーションを参照リソースとして管理する場合、IIS アプリケーションには下記が含まれます。

ファイル、ディレクトリなど、コンポーネントが参照するリソースの一部は、ゴールドサーバーまたは別のデータソースからコピーできます。IIS Web サイトの設定値、Microsoft Windows のレジストリ設定値など、その他については、独立した管理可能な要素として扱えるように、特殊な方法でデータソースから抽出する必要があります。

組み込みコンポーネントタイプに関して、プロビジョニングシステムは JavaTM 2 プラットフォーム、Enterprise Edition (J2EE プラットフォーム)、および Microsoft Windows アプリケーションに使用する、一般的なソースアイテムを認識できます。これらのコンポーネントタイプでは、コンポーネントリソースとして使用するデータを正確に抽出し、リポジトリにコンポーネントリソースを格納して、指定された場所にリソースを正しくインストールすることができます。

システムサービスの概念

システムサービスは、ホストを準備するときに、該当するすべてのホストに自動的に配備されるコンポーネントです。システムサービスは、コンポーネントのインストールと管理で、ほかのコンポーネントによって使用されるユーティリティ制御とリソースを定義します。

システムサービスによって、プランの実行時に利用できるサービスセットが充実します。

プランの概念

プランは実行プランともいい、特定のホスト上で 1 つ以上のコンポーネントを管理するために使用する命令のシーケンスです。たとえば、実行プランで 3 つのコンポーネントをインストールして、別のコンポーネントの「起動」制御を開始することができます。

プランは、ほかのプランのシーケンスを含むことができます。これにより、共通の命令シーケンスをプランとして作成し、複数のプラン間で共有できます。たとえば、3 つのコンポーネントをインストールし、別のコンポーネントに対して起動を開始するように、プランでプロビジョニングシステムに指示します。

プロビジョニングシステムは、XML スキーマで表すオブジェクトのメモリー内表現を提供します。この表現は、これらのオブジェクトの妥当性検査、持続性、バージョン管理のプロセスも定義します。

プロビジョニングシステムがプランを実行するときに、コンポーネントで宣言された置換変数が実際の値に置き換えられます。プロビジョニングシステムは通知機能もサポートするので、プランの実行に関連したイベントに対して電子メールを送信できます。

プランの種類

プロビジョニングシステムがサポートするプランは、次の 2 種類です。

XML スキーマで 2 種類のプランを区別します。したがって、ほかのサブプランの呼び出しを含んでいる最上位のプランを使用することも、単純なステップからなり、サブプランの呼び出しは含まれていない単純プランを使用することもできます。

単純プランのステップの実行が同一ターゲットホストセット上に限定されるのに対して、複合プランのステップは複数の異なるターゲットホストセット上で実行できるので、この区別は重要です。複合プランでは、含まれる単純プランごとに、ターゲットホストセットを 1 つずつ使用できます。

ステップの概要

ステップは、プランとコンポーネントの両方に組み込むことのできる単純な命令です。プロビジョニングシステムがサポートするステップの種類は、次のとおりです。

コンポーネントの参照

各種ステップは、次の状況でコンポーネントを参照できます。

例 1–1 コンポーネント参照の使い方

「Apache」コンポーネントが次の属性値とともに、ホストにインストールされているものとします。

コンポーネントインスタンス 

installPath

version

installDate

A 

/opt

1.3 

6/1/01 6:00 p.m. 

B 

/usr/local

1.4 

6/1/01 5:00 p.m. 

C 

/opt

1.2 

6/2/01 5:00 p.m. 

D 

/usr/local/bin

1.4 

6/3/01 5:00 p.m. 

E 

/export

1.1 

6/4/01 5:00 p.m. 

installPath 属性と version 属性の組み合わせに応じて値が指定されたときに、どのインストール済みコンポーネントが参照されるかを以下に示します。

installPath

version

versionOp

結果 

説明 

なし 

なし 

なし 

E 

version および installPath の値に関係なく、ターゲットホストに最後にインストールされたコンポーネントが使用されます。

/opt

なし 

なし 

C 

version の値に関係なく、指定のインストールパスに最後にインストールされたコンポーネントが使用されます。

/usr/bin

なし 

なし 

エラー 

指定のパスにコンポーネントはインストールされていません。 

なし 

1.4 

=

D 

installPath の値に関係なく、指定のバージョンが含まれているコンポーネントのうち、最後にインストールされたものが選択されます。

なし 

1.5 

任意 

エラー 

指定されたバージョンのコンポーネントはインストールされていません。 

/usr/local

1.4 

=, >=

B 

指定の installPath 属性値および version 属性値と一致するコンポーネントが選択されます。

/usr/local

1.2 

=

エラー 

指定のインストール パスにこのバージョンはインストールされていません。 

/usr/local

1.2 

>, >=

B 

installPath、version、および versionOp の値と一致したもの。

/opt

3 

任意 

エラー 

2 つ以上のコンポーネントが同じパスにインストールされ、なおかつ名前が同じ場合は、事実上、最後にインストールされたコンポーネントがインストール済みコンポーネントを上書きします。それまでにインストールされていたコンポーネントは、直接指定してもアクセスできません。 

リソース記述子ファイルの概念

リソース記述子ファイルは、単純コンポーネントのリソースを構成するファイルとディレクトリに使用する、所有者、グループ、およびアクセス許可の設定を指定します。このリソース記述子は XML ファイルです。このファイルの XML スキーマの詳細については 『Sun N1 Service Provisioning System 5.2 XML スキーマリファレンスガイド』の第 5 章「リソース記述子スキーマ」 を参照してください。リソース記述子ファイルを使用することで、コンポーネントのチェックイン時に決定されるアクセス許可を上書きできます。

リソース記述子ファイルを使用しない場合、リソースはチェックイン時の所有者、グループ、およびアクセス許可の設定を使用します。これは、UNIX システムでチェックインを実行する場合のデフォルトです。Windows システムでコンポーネントをチェックインする場合、デフォルト設定は、リソース記述子ファイルの各設定に :NONE: 値を使用したかのようになります。

リソース記述子ファイルを使用する場合、リソースは、リソース記述子により指定される所有者、グループ、およびアクセス許可の設定を使用します。リソースに対して <entry> 要素が指定されている場合、設定はそのエントリから取得されます。そのエントリが設定の一部を指定していない場合、存在しない設定値は <defaultEntry> から取得されます (存在する場合)。これらの設定値が <defaultEntry> で指定されていない場合、リソースではチェックイン時の設定を使用します。

リソースに対して <entry> 要素が指定されていない場合、リソースは <defaultEntry> で指定されてる設定を使用します (存在する場合)。<defaultEntry> が存在しない場合、リソースはチェックイン時の設定を使用します。

コンポーネントが配備されるファイルシステムのデフォルト設定を使用するようプロビジョニングシステムに通知するには、:NONE: 値を使用します。リソースの <defaultEntry> ブロックまたは <entry> で指定されている設定には :NONE: 値を指定できます。

リソース記述子ファイルが使用されるのは、UNIX システムにコンポーネントを配備する場合のみです。コンポーネントを Windows システムに配備する場合、リソース記述子ファイルは無視されます。そのため、Windows システムにだけコンポーネントを適用する場合には、リソース記述子ファイルを作成しないでください。

リソース記述子ファイルは、system#file および system#directory コンポーネントタイプを拡張する単純コンポーネントで使用できます。またリソース記述子ファイルは、Linux プラグインの一部である com.sun.linux#rpm コンポーネントタイプを拡張するコンポーネントで使用することもできます。

コンポーネントをチェックインすると同時に、リソース記述ファイルもチェックインします。最後のチェックインにリソース記述子ファイルを使用したコンポーネントに対して checkin-current を試みる場合、プロビジョニングシステムは、元のチェックイン場所でリソース記述子が見つかると想定します。そのため、そのファイルを別の場所に移動し、コンポーネントに対して checkin-current を試みると、チェックイン処理は失敗します。

チェックインされた単純コンポーネントのリソース記述子をダウンロードすると、コンポーネントのリソースの一部であるあらゆるファイルの設定を確認できます。

このダウンロード機能を使用すると、ファイルを更新し、コンポーネントの更新バージョンをチェックインできます。まず、リソース記述子ファイルをダウンロードしてから、関連付けられたコンポーネントのリソースをチェックアウトします。続いて、リソース記述子ファイルを変更し、それを使用してコンポーネントの新しいバージョンをチェックインします。

ダウンロードするリソース記述子は、コンポーネントのチェックインに使用したリソース記述子とは異なる場合があります。違いが生じるのは、コンポーネントのチェックインに使用する記述子には、リソース内のあらゆるファイルに関する情報を持つ必要がなく、またあらゆるエントリに関する完全な情報を持つ必要がないためです。ダウンロードしたリソース記述子ファイルには <defaultEntry> ブロックが出現しないことに注意してください。その代わりに、どのファイルもそのファイルの <entry> 内で記述されています。

セッション変数の概念

セッションが開始されるのは、ブラウザインタフェースにログインしたとき、または CLI を使用したときです。セッションは、ユーザーがログアウトするまで、または非アクティブな状態によりセッションが終了するまで続きます。論理上、セッションは、特定のユーザーの認証済みの資格情報を表します。セッションにより、再認証されなくても、一連の関連要求を通してユーザーが識別されます。

各セッションは、ログイン時にデータベースから初期化される、一式のセッション変数を持つことができます。セッション変数を使用して、ユーザー認証やその他の資格など、セッション関連の情報を維持できます。現在のセッションのセッション変数は、データベースに保存されているセッション変数に影響を及ぼすことなく変更できます。セッション変数とその値を変更した場合、それらをデータベースに保存できます。保存する場合は、すべての変数とその値が保存され、以降のセッションで使用できるようになります。プランや比較の実行時に、セッション変数を参照できます。

複数のセッションを開始していて、セッション変数を同時に保存しようとした場合、最初のセッションの変数のみが保存されます。最初のセッションのセッション変数が保存されたあと、ほかのセッションのセッション変数の変更を保存しようとしても保存できません。このような場合に変更を保存する方法は、次のとおりです。

  1. すべてのセッションからログアウトします。

  2. もう一度ログインしてセッションを開始します。

    正常に完了した最後の保存に基づいて、データベースからセッション変数と値の新しいセットを取得します。

  3. セッション変数を適切に変更します。

  4. 変更したセッション変数を保存します。

セッション変数は大域名前空間に存在するので、宣言したセッション変数名をすべてのユーザーセッションで使用できます。たとえば、セッション変数名として passwd を定義したとします。passwd セッション変数を要求するプランは、いずれも同じ変数を参照します。セッション変数名の有効範囲は現在のプラン、コンポーネント、ブロック、またはホストに限定されません。したがって、セッション変数名が一意になるように配慮する必要があります。たとえば、自分のイニシャルと生年月日、またはその他の識別情報を使用して、セッション変数の一意性を確保してください。

セキュリティー保護されたセッション変数

セッション変数は名前、値、および secure フラグで構成されます。セッション変数名に関する制約は、ホストタイプ変数名の場合と同じです。secure フラグは、セキュリティーを保護して値を格納するかどうかを指定します。

値のセキュリティーを確保して格納するには、secure フラグを true に設定します。この場合、セッション変数の値は *** で表示され、保存時には変数が暗号化されます。プランの実行時にこの値が使用された場合、この変数の値はプランの履歴に反映されません。この secure フラグは、パスワードなど、変数値が機密データの場合に使用します。セッション変数はデフォルトで、secure フラグを true に設定して作成されます。

セキュリティー保護された変数をデータベースに保存する場合は、暗号鍵として使用されている自分のパスワードを入力する必要があります。パスワードを間違って指定すると、パスワードの再入力が求められます。

入力したパスワードが認識されないと、エラーが発生します。システム管理者によってパスワードまたはログイン構成が変更されている場合などに、このよう状況が発生します。次の 2 つのオプションがあります。