IBM SmartCloud Enterprise についてのヒント: イメージのパラメーター検証ルールをオンザフライで調整する

クラウド・イメージをパラメーター化する場合にパラメーターの制約を定義する

IBM SmartCloud Enterprise では、クラウド・イメージを動的にカスタマイズすることができます。つまりインスタンス作成プロセスにオンザフライでパラメーターを転送すると、カスタマイズされた最終的なイメージを作成することができます。イメージを 1 つのグループで共有する場合、あるいはさらに進めてイメージを公開する場合、そのイメージのユーザーがパラメーターを提供すると、IBM Cloud のポータルまたは API によってそのユーザー独自のインスタンスを作成することができます。ただし、ユーザーが適切にインスタンスを作成しているかどうかと、適切なパラメーターを入力として提供しているかどうかを確認する必要があります。この記事では、イメージをパラメーター化する場合に適用することができる一連のルールについて説明します。そのなかには、正規表現、既知のパターン、CompoundRules、そして暗黙的な検証も含まれます。

IBM SmartCloud Enterprise についてのヒント」シリーズの他の記事を見る

Yiming Yang, Staff Software Engineer, IBM

Yiming Yang は IBM SmartCloud Enterprise プロジェクトのスタッフ・ソフトウェア・エンジニアです。彼はクラウド・イメージのパラメーターの検証や他の BSS サイドの機能に関する業務を行っています。彼は過去 5 年間、ICSR や WCRE など、多くの国際会議で論文を発表してきました。



Ying Tang, Information Developer, IBM

Ying Tang は IBM SmartCloud Enterprise プロジェクトの情報開発者です。彼女は IBM CDL で IBM Cloud イメージのガイドに関する業務を行っています。



Hao Wu, Software Engineer, IBM

Hao Wu は IBM SmartCloud Enterprise ソフトウェア・エンジニアです。彼は IBM Cloud の BSS サイドの機能に関する業務を行っています。



2011年 11月 18日

IBM SmartCloud Enterprise の Cloud Public Catalog には何百ものパブリック・イメージが用意されており、ユーザーはそれらのイメージから独自のインスタンスを作成することができます。これだけ多くのイメージが用意されていても、多くのユーザーは当然、自分が使用するイメージをカスタマイズすることを望んでいます。イメージをカスタマイズすると、特定のソフトウェア・アプリケーション、構成、セキュリティーにイメージを合わせることができるメリットがあるからです。カスタマイズしたイメージをベースにすれば、インスタンスを作成するのが容易になり、インスタンスを再構成する労力を減らすことができます。また、カスタマイズしたイメージを 1 つのグループの複数ユーザーで共有するのも容易になります。

IBM Cloud では動的にイメージをカスタマイズすることができます。つまりインスタンス作成プロセスにオンザフライでパラメーターを転送すると、カスタマイズされた最終的なイメージを作成することができます。IBM のエキスパートである (そして developerWorks の著者でもある) Dominique Vernier 氏は、彼の寄稿した記事「カスタム・インスタンスのクラウド・イメージをオンザフライでパラメーター化する」の中で、イメージをパラメーター化するためのプロセス全体を説明しています。例えば図 1 で、ユーザー A はカスタマイズしたイメージを作成し、そのイメージをユーザー B と共有しています。

図 1. カスタマイズしたイメージをユーザー A が提供し、ユーザー B と共有する
カスタマイズしたイメージをユーザー A が提供し、ユーザー B と共有する

ユーザー A:

  1. 既存のイメージを複製するか、そのユーザー自身のインスタンスからイメージを取得することで、プライベート・イメージを作成します。
  2. parameters.xml ファイルを更新します。この更新されたファイルを使用して、ユーザー入力 (この例では User ID の値) を収集するための UI ウィジェットを生成します。
  3. プロビジョニング対象の VM でユーザー・パラメーターを処理することができる起動スクリプトを用意します。
  4. parameters.xml ファイルと起動スクリプトをプライベート・イメージのアセット・ファイルとして IBM Rational Asset Catalog に送信します。

ユーザー B;

  1. ユーザー A が作成したイメージを基に、IBM Cloud のポータルにインスタンスを作成します。次にユーザー B は、該当のフィールドに User ID の値を入力する必要があります。parameters.xml ファイルはユーザー入力と共に、そのクラウド・インスタンスにコピーされます。
  2. そのインスタンスを起動します。すると、起動スクリプトによってパラメーターが抽出され、そのパラメーターを使ってインスタンスが構成されます。

parameters.xml ファイルは、ユーザーに入力を促し、その入力からパラメーターを収集するために使用される XML ファイルです。ユーザーが入力するパラメーターとしては、ユーザー名、パスワード、IP アドレス、カスタム・インスタンスの構成に使用される数値などがあります。例えば Vernier 氏が寄稿した記事では、ユーザー名、ユーザーのパスワード、VNC のパスワードの入力を促し、インスタンスの中で VNC によるアクセスを構成するために parameters.xml ファイルが使用されています。また parameters.xml ファイルはローカルのワークステーションからインスタンスにファイルをアップロードするためにも使用されます。

適切な値を入力するようにユーザーに指示し、インスタンスが適切に作成されるようにするために、これらのパラメーターに対し、事前に定義した検証ルールを設定する必要があります。parameters.xml には、正規表現、既知のパターン、CompoundRules、暗黙的な検証など、一連のルールを適用することができます。

parameters.xml で定義される UI ウィジェット

parameters.xml ファイルは基本的に <field> 要素で構成されています。各 <field> 要素は、追加パラメーターのページを構成する際に表示される UI ウィジェットを記述するために使用されます。<field> 要素は name 属性と label 属性を持つ必要があります。name 属性はそのフィールドを一意に定義し、また label 属性は通常、そのフィールドの目的を示すために使用されます。また、フィールドが description 属性を持つこともできます。description 属性はそのフィールドに関する詳細情報を示すために使用されます。

以下に示す Tomcat サーバーのインスタンスでは、ユーザーは UserID を入力するように促されます。UserID フィールドには、name 属性、label 属性、description 属性があります。

<field name="UserID" type="string" label="UserID*" description="UserID of Tomcat Admin"/>

図 2. インスタンスを作成するためのパラメーターを提供する
インスタンスを作成するためのパラメーターを提供する

ユーザー入力のウィジェットを他のタイプで定義したい場合があるかもしれません。例えば、パスワードを (type="password")、数値を (type="number")、日付を (type="date")、コンボ・ボックスを (type="combo") というように定義したい場合があります。これらのタイプには、ユーザー入力に対する定義済みの制約が含まれており、そのため検証ルールを定義するための作業が少なくて済みます。また、ユーザーが独自のファイルをインスタンスにアップロードできるように、フィールドのタイプとしてファイルを指定 (type="file") することもできます。例えば、以下の key フィールドは、インスタンスにファイルを追加することができます。そのファイルはインスタンスの idcuser ディレクトリーにコピーされます。

図 3. parameters.xml を使用してインスタンスにファイルをアップロードする
parameters.xml を使用してインスタンスにファイルをアップロードする

UI ウィジェットに適用可能な検証ルール

ほとんどの場合、ユーザーが入力したパラメーターが適切かどうか (文字列の書式や数値の範囲など) を自動的に検証するメカニズムが必要です。入力の検証はプロビジョニング・リクエストを送信する前に行う必要があります。プロビジョニング前に検証を行うことで、ユーザーが入力したパラメーターのどれが無効であり、なぜ無効なのかを即座にユーザーに通知することができ、インスタンスのプロビジョニングが失敗した後で不適切な部分を通知するよりも優れたユーザー・エクスペリエンスを提供することができます。

IBM SmartCloud Enterprise では、各フィールドのパラメーターに対する制約を parameters.xml ファイルで定義することができます。現在、以下の 4 つのタイプの検証ルールがサポートされています。

  • 正規表現による検証
  • ウィジェット・タイプに基づく暗黙的な検証
  • 既知のパターンに基づく検証
  • CompoundRules を使用したパラメーターの検証

正規表現による検証

先ほど作成した UserID フィールドに対し、ユーザー名が長すぎたり短すぎたりしないように、長さの制約を設定したい場合がよくあります。この場合、正規表現を使用すると、文字列の書式設定を簡潔な方法で行うことができます。フィールドの長さを 8 文字と 10 文字の間に制限したい場合には、正規表現を ^.{8,10}$ のように作成します。

ユーザー入力を検証する際に対象とするパターンとして正規表現を定義することもできます。

次のステップとして、UserID フィールドの pattern 属性に対する正規表現を設定します。長さに関する制約を description 属性の中に明確に記述します。こうすることで、このフィールドにどんな種類の入力が許されるのかをユーザーに知らせることができます。

<field name="UserID" type="string" label="UserID*" description="UserID of Tomcat Admin.
 It must be between 8 and 10 characters." 
 pattern="^.{8,10}$" />

最後に、パターン要件を満たさなかった場合、入力を修正するために何をすればよいかをユーザーが理解できるように、ヒントとなるテキストを指定します。patternErrorMessage 属性を指定すると、ユーザーにエラー・メッセージを表示することができます。

<field name="UserID" type="string" label="UserID*" description="UserID of Tomcat Admin."
 pattern="^.{8,10}$" 
 patternErrorMessage="Length of the field must be between 8 and 10 characters."/>

図 4 は無効なユーザー名 admin を入力した場合にユーザーに表示される画面を示しています。

図 4. 正規表現による検証を UserID に追加する
正規表現による検証を UserID に追加する

ウィジェット・タイプに基づく暗黙的な検証

User ID に対するパスワードをユーザーに設定させ、そのパスワードを確認するために再度入力させたい場合がよくあります。IBM SmartCloud Enterprise では、ウィジェットのタイプに応じてデフォルトで暗黙的な検証を行うことができます。簡単にパスワードの入力を促すには、フィールドのタイプを password に設定します。このタイプを指定することで、ユーザーにパスワードを再入力させること、パスワード・フィールドが空ではないこと、そして 2 つのパスワードの値を同じにすることを確実にすることができます (図 5)。

図 5. ユーザー・パスワードのフィールドにパスワードの暗黙的な検証を追加する
ユーザー・パスワードのフィールドにパスワードの暗黙的な検証を追加する
<field name="User password" type="password" label="User password*" 
 description="User password of Tomcat Admin"/>

同様に、日付タイプ (type="date") を指定してフィールドのフォーマットの制約を設定すると、そのフィールドに日付を入力するようにユーザーに指示することができます。

既知のパターンに基づく検証

正規表現を使用すると、ユーザー入力を容易に検証することができます。しかし経験の浅い人には、正規表現は難しい概念です。検証を容易にするために、IBM SmartCloud Enterprise には定義済みの一連の検証ルール、つまり一般的なシナリオに対する既知のパターンが用意されています。例えば、ユーザー ID とパスワード以外に Tomcat サーバーのホスト名を入力するようにユーザーに促す場合には、^(([^-][a-z0-9A-Z-_]+\.)*)[^-][a-z0-9A-Z-_]+(\.[a-zA-Z]{2,4}){1,2}$ のような正規表現が必要です。この複雑な正規表現は以下のようにルールを定義しています。

  1. ドット (.) で区切られた最後の 2 つのセグメントに対し、どんな種類の文字が許されるか (例えば、英語の大文字または小文字のみが許される、など) を定義しています。
  2. 最後の 2 つのセグメントに対して長さの制限を設定しています (最後のセグメントは 1 文字または 2 文字、最後から 2 番目のセグメントは 2 文字から 4 文字)。
  3. ホスト名の前をドット (.) で区切ることで任意の数のセグメントを使用できるようにしています。これらのセグメントは英語の文字または数字 (0-9) で構成されます。

幸いなことに、hostknownPattern 属性を設定するだけで、この正規表現を置き換えることができます (図 6)。

図 6. Hostname に対し、既知のパターンによる検証を追加する
Hostname に対し、既知のパターンによる検証を追加する
<field name="hostname" type="string" label="Hostname" knownPattern="host" 
 patternErrorMessage="Invalid hostname format"/>

同様に、以下のように knownPatternIpAddress を設定すると、IP アドレス・フィールドを定義することができます。

<field name="ipAddress" type="string" label="IP Address" knownPattern="IpAddress" 
 patternErrorMessage="Invalid IP Address format"/>

CompoundRules を使用したパラメーターの検証

一部のシナリオでは、既知のパターンでも不十分な場合があります。例えば、ユーザーがパスワードにユーザー名を含めることが許されない場合があります。他にも、ユーザーが特別な文字列 (「admin」など) をパスワードの一部に含めることが許されない場合があります。さらに、セキュリティー・ポリシーにより、ユーザーは強力なパスワードを使用するように要求される場合がよくあります (例えば、小文字と大文字と数字の組み合わせ、など)。

1 つのルールでは対応できない場合には、複合ルールによる検証を使用します。他の既知のパターンの場合とは異なり、フィールドに対して knownPattern="compoundRules" を宣言した後、そのフィールドの子のタグとして複合ルールの詳細を記述する必要があります。

以下に示す例では、Tomcat サーバーのパスワードに対する複合ルールを作成しています。パスワード・フィールドは以下の要件を満たす必要があります。

  • ユーザー名を含むことはできません。
  • 「guest」または「administrator」であってはなりません。
  • 長さは 8 文字から 20 文字の間でなければなりません。
  • 英語の大文字、英語の小文字、数字、アルファベット以外の文字という 4 つのタイプの文字のうち、少なくとも 3 つのタイプの文字を含む必要があります。
  • admin、Administrator という文字列に含まれる連続した文字を 2 文字を超えて使用することはできません。

個々のルールを作成した後、それらのルールのすべてをフィールドに適用します。すべての複合ルールは JSON オブジェクトであり、表 1 に示す基本的なプロパティーを含んでいます。

複合ルールの基本的なプロパティー
プロパティー説明
nameルールの名前
descriptionルールの説明
typeルールのタイプ

どの複合ルールをどこに使用するのかを以下の例で説明します。

  1. フィールドの一部として UserID を含めることはできないことを notContainRestriction 複合ルールを使用して制限します。value フィールドにより、パスワード・フィールドの比較対象となるパラメーター $UserID を導入します。
    {
    "name": "Password restriction",
    "description": "The field cannot contain the user ID.",
    "type": "notContainRestriction",
    "value":"$UserID"
    },
  2. 許可されない文字列を配列に入れ、その配列の中にある文字列はフィールドに使用できないことを isNotRestriction 複合ルールを使用して要求します。以下のコード・スニペットでは caseSensitive 属性が false に設定され、この比較では大文字と小文字を区別しないことを示しています。つまり ”guest”、”Guest”、”administrator”、”Administrator” は許されません。
    {
    "name": "Password restriction",
    "description": "User cannot be Guest or
    Administrator (not case sensitive)",
    "type": "isNotRestriction",
    "caseSensitive":false,
    "array":["Guest", "Administrator"]
    }
  3. RegularExpression 複合ルールを使用してフィールドの長さ制限を設定し、value 要素の中で正規表現 ^.{8,20}$ を指定します。
    {
    "name":"Password length restriction",
    "description": "Password's length must more than 8 chars and less than 20 chars",
    "type": "RegularExpression",
    "value":"^.{8,20}$"
    },
  4. 異なるタイプの文字を混合して使用するようにパスワードを制限します。以下のコード・スニペットでは charactersRestriction ルールを使用して、4 つのタイプの文字のうち 3 つのタイプの文字をフィールドに含むように要求しています。value 要素で指定される数値 3 は、パスワードがどの程度複雑でなければならないかを決定する構成可能な変数です。charactersPattern 属性の中で指定されている English_Uppercase_CharactersEnglish_Lowercase_CharactersDigitsNon_Alphabetic_Characters は、パスワード・フィールドに使用できるすべての文字を要約しています。
    {
    "name": "Characters restriction",
    "description": "Passwords must contain characters from three of the following 
    four categories",
    "type": "charactersRestriction",
    "value":"3",
    "charactersPatterns":["English_Uppercase_Characters",
    "English_Lowercase_Characters","Digits",
    "Non_Alphabetic_Characters"]
    }
  5. notInArrayRestriction 複合ルールを使用して、指定された文字列配列に含まれる連続した文字を n 個 (この数字は変更可能です) までしかフィールドに含めることができないように制限します。例えば以下のコード・スニペットでは、指定されたフィールドには配列 [admin, Administrator, idcadmin] に含まれる連続した文字が 2 つまでしか含まれないようにすることを要求しています。
    {
    "name":"User full name restriction",
    "description": "The field cannot contain user's full name for more than two 
     consecutive characters",
    "type": "notInArrayRestriction",
    "value":"2",
    "array":["admin", "Administrator", "idcadmin"]
    },

すべての複合ルールを作成したら、パーサーで無視される CDATA セクションにそれらのルールを追加し、その CDATA セクションを <field> の中の <compoundRules> 要素に挿入します。そのフィールドでは、knownPattern 属性を compoundRules に設定する必要があります。parameters.xml ファイルが有効になると、ユーザーは CDATA セクションに定義されたすべての複合ルールに従う必要があります。

<field name="User password" label="User password" type="password" 
 knownPattern="compoundRules" patternErrorMessage="Invalid User Password.">
<compoundRules>
<![CDATA[
... rules text ... 
]]>
</compoundRules>
</field>

parameters.xml の検証をする

parameters.xml が適切にフォーマット設定されていることを確認するために、このファイルを XML スキーマ parameters.xsd (「ダウンロード」を参照) に対して検証します。この検証を実行するためには、UNIX/Linux オペレーティング・システムに組み込まれているコマンドライン・ツール xmllint を使用します。

xmllint をインストールして使用するためには以下の手順に従います。

  1. xmlint をインストールします。まだ xmlint をインストールしていない場合には、最初に xmlint を含むパッケージ libxml2-utils をインストールする必要があります。
    # aptitude install libxml2-utils
  2. parameters.xsd に対して parameters.xml の検証を行います。
    $ xmllint --noout --schema parameters.xsd parameters.xml

    parameters.xml ファイルのフォーマットが適切な場合には、以下のメッセージが表示されます。
    表示されるメッセージ
    parameters.xml ファイルのフォーマットが適切であることを示すメッセージ
    parameters.xml ファイルに誤りがある場合、例えば fieldfild と誤っている場合には、以下のエラー・メッセージが表示されます。
    表示されるメッセージ
    parameters.xml ファイルのフォーマットが不適切であることを示すエラー・メッセージ

parameters.xml を Rational Asset Manager にデプロイする

parameters.xml ファイルはイメージに関連付けられた RAM (Rational Asset Manager) アセットにアップロードされるまで有効になりません。parameters.xml を RAM にデプロイするためには以下の手順に従います。

  1. アセット所有者として IBM SmartCloud Enterprise にログインした後、「Support (サポート)」タブに進み、「View asset catalog (アセット・カタログを表示)」をクリックして RAM にナビゲートします。
    「View asset catalog (アセット・カタログを表示)」をクリックして RAM にナビゲートする
    「View asset catalog (アセット・カタログを表示)」をクリックして RAM にナビゲートする
  2. カスタマイズ対象のイメージ・アセットを選択します。アセットは「My assets (私のアセット)」タブで容易に見つかるはずです。
    変更が必要なアセットを見つける
    変更が必要なアセットを見つける
  3. ページ右上隅にある「Modify (変更)」アイコンをクリックして編集を開始します。
    「Modify (変更)」をクリックしてアセットを編集する
    「Modify (変更)」をクリックしてアセットを編集する
  4. 編集ページで「Browse... (ブラウズ...)」をクリックし、ローカル・ドライブ上の parameters.xml ファイルの場所を指定します。
    ローカル・ドライブ上の parameters.xml の場所を指定する
    ローカル・ドライブ上の parameters.xml の場所を指定する
  5. 最後に、「Update (更新)」をクリックし、更新のコメントを入力し、再度「Update (更新)」をクリックします。

このイメージが次回プロビジョニングされる時には、この新しい parameters.xml が使用されます。


ダウンロード

内容ファイル名サイズ
parameters.xml and parameters.xsdparameters.zip2KB

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmartCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=773500
ArticleTitle=IBM SmartCloud Enterprise についてのヒント: イメージのパラメーター検証ルールをオンザフライで調整する
publish-date=11182011