Cisco UCS Director Open Automation 開始ガイド、リリース 5.4
Open Automation の開始
Open Automation の開始

Open Automation の開始

Cisco UCS Director Open Automation

Cisco UCS Director Open Automation ツールを使用すると、独自の Cisco UCS Director 機能をモジュールとして開発し統合できます。独自のニーズを満たすようにモジュールをカスタマイズできます。

モジュールを使用すると、次の機能を実行できます。

  • 独自の Cisco UCS Director レポートおよびレポート アクションの開発

  • デバイスのインベントリ作成

  • モジュールを介して行うシステム変更のトラッキング

  • ワークフローに使用できるタスクの開発

  • 繰り返し使用可能なタスクの開発およびスケジュール設定

  • 新しいリソース制限の設定

サンプル コードを Cisco DevNet からダウンロードできます。

推奨ツール

シスコは次のツールを使用することを推奨します。

  • Java バージョン 1.8

  • Eclipse

Eclipse IDE への Cisco UCS Director Open Automation SDK プロジェクトのインポート

Open Automation SDK は、Cisco.com download site または Cisco DevNet から入手できます。Cisco UCS Director SDK リンクをクリックします。サンプル SDK プロジェクトの zip ファイルをファイル システムに解凍します。

次の手順は、Eclipse に SDK バンドルをインポートする方法について説明します。Eclipse を使用しない場合は、ご自身の開発環境に提供されている手順に従ってください。

手順
     コマンドまたはアクション目的
    ステップ 1SDK バンドルを取得し、そのコンテンツを適切なフォルダに抽出します。   
    ステップ 2Eclipse を起動します。   
    ステップ 3[ファイル(File)] > [インポート(Import)] を選択します。   
    ステップ 4[インポート(Import)] ダイアログボックスで、[一般(General)] > [既存プロジェクトをワークスペースへ(Existing Projects into Workspace)] を選択します。   
    ステップ 5[次へ(Next)] をクリックします。   
    ステップ 6[ルートディレクトリの選択(Select root directory)] を選択し、プロジェクトを抽出した場所を参照します。   
    ステップ 7[終了(Finish)] をクリックします。 

    プロジェクトが自動的にコンパイルします。

     

    Eclipse の設定

    Cisco UCS Director チームは、www.eclipse.org にある Eclipse IDE を開発に使用することを推奨しています。

    はじめる前に

    Java Runtime Environment(JRE)1.8 が必要です。

    手順
      ステップ 1   Eclipse で、Cisco UCS Director Open Automation SDK のプロパティに移動します。
      ステップ 2   [Javaコンパイラー(Java Compiler)] を 1.8 に対するコンパイルに設定し、[OK] をクリックします。
      (注)     

      Cisco UCS Director Open Automation SDK の jar ファイルをクラスパスに含めます。また、プロジェクトの設定が、Open Automation SDK のサンプルで提供されている設定をミラー化している必要があります。


      コネクタのリリース 5.4 へのアップグレード

      アップグレードの詳細については、『Cisco UCS Director Upgrade Guide, Release 5.4』を参照してください。

      モジュール

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

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

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

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

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

      モジュール開発のガイドライン

      新しいデバイスをサポートする新しいモジュールを開発する場合は、以下を確認する必要があります。
      • これらのすべてのデバイスをサポートするモジュールが 1 つだけになるように、デバイス ファミリ用のモジュールを開発します。

      • ネットワーク スイッチとストレージ コントローラの両方をサポートするモジュールは開発すべきではなく、代わりにそれらを 2 つのモジュールに分割する必要があります。理想的には、1 つのモジュールがコンピューティング デバイス、ネットワーク デバイス、またはストレージ デバイスのみを処理できるように、1 つのモジュールは同じカテゴリに属するデバイスのみをサポートする必要があります。

      • 同じモジュールでサポートされるデバイスは類似している必要があります。

      • 別々の目的に適した異なるモデルに同じデバイスが使用されることがあります。そういったケースでは、異なるモデルは異なるモジュールでサポートする方が適切な場合があります。

      モジュールの作成

      カスタム モジュールが機能するためには次の項目を準備する必要があります。
      • 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)] 表が開いて、次の列が表示されます。

          カラム

          説明

          [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)] の順に移動して、モジュールのステータスがアクティブであることを確認します。