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

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

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

上に戻る

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 を入力した場合にユーザーに表示される画面を示しています。

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

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

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

<field name="hostname" type="string" label="Hostname" knownPattern="host" 
 patternErrorMessage="Invalid hostname format"/>

同様に、以下のように knownPattern に IpAddress を設定すると、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 に示す基本的なプロパティーを含んでいます。

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

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_Characters、English_Lowercase_Characters、Digits、Non_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 ファイルに誤りがある場合、例えば field を fild と誤っている場合には、以下のエラー・メッセージが表示されます。
   
   表示されるメッセージ
   
   
   

上に戻る

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 にナビゲートする
   
   
   
2. カスタマイズ対象のイメージ・アセットを選択します。アセットは「My assets (私のアセット)」タブで容易に見つかるはずです。
   
   変更が必要なアセットを見つける
   
   
   
3. ページ右上隅にある「Modify (変更)」アイコンをクリックして編集を開始します。
   
   「Modify (変更)」をクリックしてアセットを編集する
   
   
   
4. 編集ページで「Browse... (ブラウズ...)」をクリックし、ローカル・ドライブ上の parameters.xml ファイルの場所を指定します。
   
   ローカル・ドライブ上の parameters.xml の場所を指定する
   
   
   
5. 最後に、「Update (更新)」をクリックし、更新のコメントを入力し、再度「Update (更新)」をクリックします。

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

上に戻る

ダウンロード

ダウンロード形式について

参考文献

学ぶために

• IBM Cloud でタスクを実行するための方法に関して、他にも以下のようなリソースがあります。
  • 「IBM Cloud リリース 1.2 を使うためのヒント: Windows インスタンスとの間でのファイルのアップロードとダウンロード」
  • 「IBM Cloud リリース 1.2 を使うためのヒント: Windows Server 2008 R2 に IIS Web サーバーをインストールする」
  • 「Linux のコマンド・ラインを使用して IBM Cloud にインスタンスを作成する」
  • 「Create an IBM Cloud instance with the Windows command line」
  • 「Extend your corporate network with the IBM Cloud」
  • 「IBM Cloud での高可用性アプリケーション」
  • 「カスタム・インスタンスのクラウド・イメージをオンザフライでパラメーター化する」
  • 「Windows-targeted approaches to IBM Cloud provisioning」
  • 「IBM SmartCloud Enterprise についてのヒント: Rapid Deployment Service を使用して製品をデプロイする」
  • 「Integrate your authentication policy using a proxy」
  • 「IBM SmartCloud Enterprise についてのヒント: Linux Logical Volume Manager を構成する」
  • 「IBM SmartCloud Enterprise についてのヒント: 複雑なトポロジーをデプロイする」
  • 「別々の VLAN にまたがる: パブリック VLAN とプライベート VLAN にまたがるインスタンスをプロビジョニングし、構成する」
  • 「IBM SmartCloud Enterprise についてのヒント: Android 機器からセキュアにアクセスする」
  • 「Data recovery in IBM SmartCloud Enterprise」
  
  
• developerWorks でクラウド開発者のためのリソースを調べてください。クラウドにデプロイするためにプロジェクトを構築しているアプリケーション開発者やサービス開発者の知識や経験を発見し、共有することができます。
  
  
• 「IBM SmartCloud Enterprise」にアクセスする方法を学んでください。
  
  

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

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

議論するために

• developerWorks のクラウド・コンピューティング・グループに参加してください。
  
  
• developerWorks でクラウドに関する優れたブログを読んでください。
  
  
• developerWorks コミュニティーに加わってください。developerWorks コミュニティーは専門家のネットワークであり、接続、共有、および協力のための一連のコミュニティー・ツールを豊富に提供しています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• parameters.xml で定義される UI ウィジェット
• UI ウィジェットに適用可能な検証ルール
• parameters.xml の検証をする
• parameters.xml を Rational Asset Manager にデプロイする
• ダウンロード
• 参考文献
• 著者について
• コメント