Cisco UCS Director Open Automation の手順書、リリース 5.4
モジュールの管理
モジュールの管理

モジュールの管理

この章は、次の項で構成されています。

モジュール

モジュールは、Cisco UCS Director への最上位の論理エントリ ポイントです。

モジュールには、次のコンポーネントを含めることができます。

  • タスク:ワークフローを定義する際に使用できるワークフロー タスク。

  • レポート:UCS Director UI に表示されるレポート。レポートには、アクション ボタンを含めることも含めないことも可能です。

  • トリガー:満たされたときに何らかのアクションに関連付けできる条件。例:VM のシャットダウン、VM の起動など。

モジュールの作成

カスタム モジュールが機能するためには次の項目を準備する必要があります。
  • AbstractCloupiaModule を拡張するクラス。

  • AbstractCloupiaModule を拡張するモジュール クラスの OnStart メソッドをオーバーライドします。

  • 依存 jar およびモジュール クラスを指定する .feature ファイル。
  • カスタム モジュールでは、module.properties ファイルが必須です。




はじめる前に

SDK のサンプル プロジェクトで FooModule を参照してください。

手順
    ステップ 1   AbstractCloupiaModule を拡張します。

    AbstractCloupiaModule を拡張する際、このクラスのすべてのカスタム コンポーネントを登録する必要があります。

    ステップ 2   依存 jar およびモジュール クラスを指定する .feature ファイルを指定します。 このファイルは、拡張子 .feature で終わる必要があります。foo.feature を参考にしてください。ベスト プラクティスは、モジュール ID でこのファイルの名前を付けることです。.feature ファイルの詳細については、モジュールのパッケージ化 を参照してください。
    ステップ 3   lib フォルダに必要なカスタム jar ファイルを追加します。
    ステップ 4   プロパティ ファイルは、モジュール jar のルート レベルでパッケージ化します。 Cisco UCS Director は、検証用に properties ファイルを提供します。SDK のサンプルに、パッケージ化プロセスを処理するビルド ファイルが用意されています。
    (注)     

    module.properties ファイルについては、module.properties ファイル で説明します。

    ステップ 5   moduleID ファイルから moduleID プロパティを検索します。
    ステップ 6   moduleIdmodule.properties ファイルで指定した moduleID に置き換えます。
    ステップ 7   Eclipse IDE パッケージ エクスプローラから [build.xml] --> [選択した権限で実行(run as)] --> [Antビルド(Ant Build)] の順に選択してモジュール zip ファイルを作成します。

    module.properties ファイル

    module.properties ファイルはプラットフォームのランタイムにモジュールを公開します。このファイルは、モジュール自体の特定のプロパティを定義します。

    サンプルの module.properties ファイルを次に示します。

    moduleID=foo
    version=1.0
    ucsdVersion=5.4.0.0
    category=/foo
    format=1.0
    name=Foo Module
    description=UCSD Open Automation Sample Module
    contact=support@cisco.com
    key=5591befd056dd39c8f5d578d39c24172
    

    次の表で内容について説明します。

    表 1 新しい Module.Properties(module.properties)
    名前 説明

    moduleID

    モジュールの一意の識別子。このプロパティは必須です。

    例:
    moduleID=foo
    ヒント   

    推奨されているベスト プラクティスは、この ID を 3 ~ 5 文字の小文字の ASCII アルファベット文字列に限定することです。

    version

    モジュールの現在のバージョン。このプロパティは必須です。

    例:
    version=1.0

    ucsdVersion

    モジュールをサポートする(モジュールが最適に動作する)ように設計された Cisco UCS Director のバージョン。このプロパティは必須です。

    例:
    ucsdVersion=5.4.0.0

    category

    すべてのタスクが配置されるパス(/location)。このプロパティは必須です。

    例:
    category=/foo
    (注)     

    カテゴリは、タスクが配置される場所へのフル パスです。タスク モジュールが検証されていない場合は、Open Automation Community Tasks/Experimental の下にパスを作成しています。一方、タスク モジュールが検証されている場合は、ルート相対で任意の場所に配置できます。たとえば、/Physical Storage Tasks/foo を使用する場合は、このフォルダーの下に配置されます。または、/Open Automation Community Tasks/Validated/foo や /foo にも配置できます。この最後のケースでは、理論上、foo という名前のフォルダーがルート レベルに存在することになります。この変更により、開発者は open automation の直下または、open automation のカテゴリの下にないカテゴリにタスクを配置することができます。

    format

    このモジュールの形式のバージョン。「1.0」が本書執筆時点で唯一の許容値です。このプロパティは必須です。

    例:
    format=1.0
    制約事項:

    Cisco UCS Director リリース 5.0.0.0 現在、「1.0」が唯一の許容値です。

    name

    Open Automation レポート内のモジュールの識別に使用されるわかりやすい文字列。

    例:

    name=Foo Module

    description

    モジュールの機能に関するわかりやすいテキスト。

    例:
    description=UCSD Open Automation Sample Module

    contact

    モジュールのユーザがサポートを依頼するための電子メール アドレス。

    例:
    contact=support@cisco.com

    key

    モジュールが検証済みであることを指定するために含めることが可能なシスコ発行キー。

    例:
    key=5591befd056dd39c8f5d578d39c24172
    (注)     

    キーは、Cisco UCS Director Open Automation グループがモジュールを検証する目的で提供する暗号化キーです。


    (注)  


    必須プロパティを変更しようとすると、更新によってモジュールが無効になります。必須プロパティのいずれかを変更した場合は、再度、検証を依頼する必要があります。対照的に、必須ではない name、description、および contact の値は、再検証を依頼しなくても、変更または省略できます。


    モジュールのパッケージ化

    モジュールには、必要なすべての依存 JAR ファイル、クラス、および module.properties ファイルが、.feature ファイルとともにパッケージ化されます。.feature(発音は「ドット フィーチャー」)ファイルは、プロジェクトのルートと同じフォルダに配置されます。このファイルには、このモジュールに関連付けられている JAR と、依存 JAR ファイルへのパスが示されます。

    シスコは、Eclipse に付属している Apache ANT™ ビルド ツールを使用することを推奨します。別のビルド ツールを使用することも、ご自身でビルドを作成することもできますが、ANT でビルドした場合と同じ特性のパッケージを提供する必要があります。

    次の例は .feature ファイルを示しています。ファイルの名前は、<moduleID>-module.feature になります。

    {
          jars:  [ "features/feature-chargeback.jar", 
          "features/chargeback/activation-1.1.jar", 
          "features/chargeback/axis2-jaxbri-1.5.6.jar", 
          "features/chargeback/bcel-5.1.jar", 
          "features/chargeback/jalopy-1.5rc3.jar", 
          "features/chargeback/neethi-2.0.5.jar", 
          "features/chargeback/antlr-2.7.7.jar", 
          "features/chargeback/axis2-jaxws-1.5.6.jar",]
          features: [ "com.cloupia.feature.oabc.OABCModule" ]
    }
    

    build.xml から ANT ターゲットのビルドを実行します。これにより、必要な Zip ファイルが生成され、プロジェクトのベース ディレクトリに保存されます。(これは、サンプル プロジェクトをプロジェクトのベースとして使用していることを前提とします。サンプル プロジェクトをこのように使用することは推奨されませんが、このデモでは基礎としています)。

    モジュールが、サンプル ソース コードで提供されていない JAR に依存する場合、必ず build.xml に追加して、Zip ファイルに含まれるようにします。次の例は、サードパーティの JAR を含むモジュール レイアウトを示しています。

    feature-oabc
        feature oabc.jar
        oabc
          lib
            flex
              flex-messaging-common.jar
        oabc.feature

    モジュール jar と .feature が zip ファイルのトップ レベルに置かれています。その後、サードパーティ jar を /moduleID/lib/ の下に配置します。 必須ではありませんが、ベスト プラクティスはサードパーティ jar を /moduleID/lib の下に置いてから、その他のサブ ディレクトリを必要に応じて追加することです。

    {
          jars:  [ 'features/feature-oabc.jar", features/oabc/lib/flex-messaging-common.jar ],
          features: [ "com.cloupia.feature.oabc.OABCModule" ]
    }

    jar ファイルへの参照は、必ず features/ で始めます。これは必須です。.feature ファイルに jar を列挙する際は、先頭に features/ を付けます。これにより、目的の jar へのパスを含めることができます。各 jar のパスは、zip ファイルで使用しているパスと同じパスにする必要があります。ベスト プラクティスは、先頭にモジュール jar を置き、その後に依存性を追加して、モジュールが確実にロードされるようにすることです。

    Cisco UCS Director でのモジュールの展開

    Cisco UCS Director ユーザ インターフェイスには [オープンオートメーション(Open Automation)] コントロールが用意されており、これを使用してモジュールのアップロードや管理を行うことができます。これらのコントロールを使用して、モジュールの Zip ファイルを Cisco UCS Director にアップロードします。


    (注)  


    アップロードでは、Zip ファイル形式のみがサポートされます。


    はじめる前に

    モジュールを有効化またはアクティブ化するには Cisco UCS Director サービスを再起動する必要がありますが、そのためには shell admin アクセスが必要です。このアクセスは、システム管理者の許可を受けて行います。[Cisco UCS Directorシェル(Cisco UCS Director Shell)] メニューをシェル管理者として使用するには、ログイン shelladmin と管理者が支給するパスワードを使用して、SSH で Cisco UCS Director にアクセスする必要があります。Windows システムでの SSH アクセスには PuTTY(http:/​/​www.putty.org/​ を参照)を使用し、Mac ではビルトインの SSH ユーティリティを使用します。

    手順
      ステップ 1   Cisco UCS Director で、[管理(Administration)] > [オープンオートメーション(Open Automation)] を選択します。
      [モジュール(Modules)] 表が開いて、次の列が表示されます。

      カラム(Column)

      説明

      {ID]

      モジュールの ID。

      [名前(Name)]

      モジュールの名前。

      [説明(Description)]

      モジュールの説明。

      [バージョン(Version)]

      モジュールの現在のバージョン。モジュール開発者は、モジュールのバージョンの管理方法を決定する必要があります。

      [互換性あり(Compatible)]

      このモジュールに最も適切な Cisco UCS Director のバージョンを表示します。

      [連絡先(Contact)]

      モジュールのテクニカル サポート担当者の連絡先情報。

      [アップロード時間(Upload Time)]

      モジュールがアップロードされる時間。

      [ステータス(Status)]

      モジュールのステータス。ステータスには、有効、無効、アクティブ、および非アクティブが含まれます。

      ユーザは、モジュールを有効にするか、無効にするかを制御できます。有効になっている場合は、Cisco UCS Director がモジュールの初期化を試みます。無効になっている場合は、Cisco UCS Director がモジュールを完全に無視します。Cisco UCS Director がモジュールを例外なしで正常に初期化できる場合、そのモジュールはアクティブです。
      (注)     

      アクティブは、必ずしも、モジュール内のすべてが正しく機能していることを意味しているわけではなく、単に、モジュールが起動したことを示しているに過ぎません。非アクティブは、Cisco UCS Director がモジュールの初期化を試みたときに、重大なエラーが発生して初期化ができなかったことを意味します。非アクティブ フラグの一般的な原因:モジュールが誤ったバージョンの Java でコンパイルされたか、モジュールにクラスが含まれていなかった。

      検証済み(Validated)

      モジュールが検証済みかどうかを示します。

      ステップ 2   [追加(Add)] を選択して新規モジュールを追加します。

      [モジュールの追加(Add Modules)] ダイアログボックスが表示されます。ここでは、アップロードする Zip ファイルを指定することができます。

      ステップ 3   モジュールの zip ファイルをローカル ファイルから選択し、[アップロード(Upload)] をクリックしてモジュールの zip ファイルをアップロードします。
      ステップ 4   [モジュール(Modules)] 表でモジュールを選択してから、[有効(Enable)] をクリックして、モジュールを有効にします。
      ステップ 5   Cisco UCS Director を再起動してモジュールをアクティブにします。
      ステップ 6   Cisco UCS Director で、[管理(Administration)] --> [オープンオートメーション(Open Automation)] の順に移動して、モジュールのステータスがアクティブであることを確認します。

      モジュールの非アクティブ化

      モジュールを非アクティブ化するには、変更が有効になるように Cisco UCS Director サービスを停止して再起動する必要があります。

      手順
        ステップ 1   非アクティブ化する必要のあるモジュールを [モジュール(Modules)] テーブルで選択し、続いて [非アクティブ化(Deactivate)] コントロールをクリックします。
        ステップ 2   Cisco UCS Director サービスを停止して再起動します。モジュールのアクティブ化の後と同じ手順に従います。