test

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

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

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

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

コンポーネントの概念

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

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

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

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

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

注 –

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

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

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

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

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

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

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

コンポーネントの特性

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

コンポーネント手続き

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

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

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

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

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

コンポーネントの継承

Component inheritanceとは、コンポーネントが別のコンポーネントから属性や動作を取得する手段です。作成したコンポーネントは、関連付けられるコンポーネントタイプからvariables、snapshots、およびproceduresを継承します。

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

コンポーネント変数

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

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

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

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

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

変数設定値

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

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

変数の優先指定

変数のオーバーライドによって、複合コンポーネントの変数のデフォルト値を無効にできます。単純コンポーネントでこの機能を使用することはできません。

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

ステップ

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

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

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

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

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

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

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

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

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

システムサービスの概念

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

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

プランの概念

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

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

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

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

プランの種類

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

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

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

ステップの概要

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

コンポーネントの参照

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

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

セッション変数の概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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