この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
Cisco UCS Director Open Automation ツールを使用すると、独自の Cisco UCS Director 機能をモジュールとして開発し統合できます。独自のニーズを満たすようにモジュールをカスタマイズできます。
モジュールを使用すると、次の機能を実行できます。
独自の Cisco UCS Director レポートおよびレポート アクションの開発
デバイスのインベントリ作成
モジュールを介して行うシステム変更のトラッキング
ワークフローに使用できるタスクの開発
繰り返し使用可能なタスクの開発およびスケジュール設定
新しいリソース制限の設定
Open Automation SDK バンドルには、モデル、サンプル、コメントを提供するコード サンプルが含まれています。SDK バンドルとサンプル コードを Cisco DevNet からダウンロードできます。
次のツールを使用することをお勧めします。
Java Runtime Environment(JRE)1.8 が必要です。
Cisco UCS DirectorSDK のバイナリはソフトウェア ダウンロード エリア、または DevNet サイトから入手できます。また、admin ユーザは、SDK のバイナリを Cisco UCS Director からダウンロードできます。
次の手順は、Eclipse に Open Automation SDK バンドルをインポートする方法について説明します。Eclipse を使用しない場合は、ご自身の開発環境に提供されている手順に従ってください。
ステップ 1 | Open Automation SDK バンドルは、Cisco.com ダウンロード サイトまたは Cisco DevNet から入手できます。SDK バンドルを抽出し、ファイル システムにサンプル SDK プロジェクトの zip ファイルを保存します。 |
ステップ 2 | Eclipse を起動します。 |
ステップ 3 | を選択します。 |
ステップ 4 | [インポート(Import)] ダイアログボックスで、 を選択します。 |
ステップ 5 | [次へ(Next)] をクリックします。 |
ステップ 6 | [ルートディレクトリの選択(Select root directory)] を選択し、プロジェクトを抽出した場所を参照します。 |
ステップ 7 | [終了(Finish)] をクリックします。
プロジェクトが自動的に作成されます。 |
Eclipse の Git(EGit)は、分散バージョン制御システムの Git を使用するための Eclipse プラグインです。EGit によって IDE にコネクタ プラグインが作成され、これを使用して IDE に Open Automation SDK バンドルをインポートします。
www.Eclipse.org のサイトからダウンロードされたほとんどの Eclipse IDE には、デフォルト設定で Git のサポートが含まれています。使用している Eclipse IDE インストール環境に Git の機能がない場合、Eclipse の Installation Manager を通じてインストールできます。EGit プラグインのインストール方法の詳細については、Eclipse に EGit プラグインをインストールを参照してください。
Open Automation SDK バンドルを Git リポジトリから Eclipse にインポートして、SDK バンドルを実行します。
Git アカウントを所有していることを確認します。Git アカウントがない場合、GitLab.com で新しいアカウントをサインアップします。
アップグレードの詳細については、『Cisco UCS Director Upgrade Guide』を参照してください。
モジュールは、Cisco UCS Director への最上位の論理エントリ ポイントです。
モジュールには、次のコンポーネントを含めることができます。
コンポーネント |
説明 |
---|---|
タスク |
ワークフローを定義する際に使用できるワークフロー タスク。 |
レポート |
Cisco UCS Director UI に表示されるレポート。レポートには、アクション ボタンを含めることも含めないことも可能です。 |
トリガー |
満たされたときに何らかのアクションに関連付けできる条件。例:VM のシャットダウン、VM の起動など。 |
これらのすべてのデバイスをサポートするモジュールが 1 つだけになるように、デバイス ファミリ用のモジュールを開発します。
ネットワーク スイッチとストレージ コントローラの両方をサポートするモジュールは開発しないでください。代わりにそれらを 2 つのモジュールに分割してください。理想的には、1 つのモジュールがコンピューティング デバイス、ネットワーク デバイス、またはストレージ デバイスのみを処理できるように、1 つのモジュールは同じカテゴリに属するデバイスのみをサポートする必要があります。
同じモジュールでサポートされるデバイスは類似している必要があります。
同じデバイスでも、特別な目的に適した様々なモデルが使用されることがあります。そういったケースでは、異なるモジュールでサポートする方が適切な場合があります。
Open Automation SDK バンドルのサンプル プロジェクトで FooModule を参照してください。
ステップ 1 | AbstractCloupiaModule クラスを拡張し、このクラスのすべてのカスタム コンポーネントを登録します。 | ||
ステップ 2 | 依存 jar およびモジュール クラスを指定する .feature ファイルを作成します。 このファイルは、拡張子 .feature で終わる必要があります。foo.feature を参考にしてください。ベスト プラクティスは、モジュール ID でこのファイルの名前を付けることです。.feature ファイルの詳細については、モジュールのパッケージ化 を参照してください。 | ||
ステップ 3 | lib フォルダに必要なカスタム jar ファイルを追加します。 | ||
ステップ 4 | プロパティ ファイルは、モジュール jar のルート レベルでパッケージ化します。 Cisco UCS Director は、検証用に properties ファイルを提供します。SDK のサンプルに、パッケージ化プロセスを処理するビルド ファイルが用意されています。
| ||
ステップ 5 | module.properties ファイルで、moduleID をカスタム モジュールの ID に書き換えます。 | ||
ステップ 6 | Eclipse IDE パッケージ エクスプローラから、build.xml ファイルを右クリックして、ANT ターゲット ビルドを実行します。これにより、モジュールの Zip ファイルが生成され、プロジェクトのベース ディレクトリに保存されます。 |
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
次の表で内容について説明します。
名前 | 説明 | ||
---|---|---|---|
moduleID |
モジュールの一意の識別子。このプロパティは必須です。 例:
|
||
version |
モジュールの現在のバージョン。このプロパティは必須です。 例: |
||
ucsdVersion |
モジュールをサポートする(モジュールが最適に動作する)ように設計された Cisco UCS Director のバージョン。このプロパティは必須です。 例: |
||
category |
すべてのタスクが配置されるパス(/location)。このプロパティは必須です。 例:
|
||
format |
このモジュールの形式のバージョン。このプロパティは必須です。デフォルトでは、カスタム モジュールにはバージョン 1.0 が設定されます。 例: Cisco UCS Director リリース 5.0.0.0 現在、「1.0」が唯一の許容値です。 |
||
name |
Open Automation レポート内のモジュールの識別に使用されるわかりやすい文字列。 例: name=Foo Module |
||
description |
モジュールの機能に関するわかりやすいテキスト。 例: |
||
description |
モジュールのユーザがサポートを依頼するための電子メール アドレス。 例: |
||
key |
Cisco UCS Director Open Automation グループがモジュールを検証する目的で提供する暗号化キー。 例: |
(注) | 必須プロパティを変更しようとすると、更新によってモジュールが無効になります。必須プロパティのいずれかを変更した場合は、再度、検証を依頼する必要があります。対照的に、必須ではない name、description、および contact の値は、再検証しなくても、変更または省略できます。 |
モジュールには、必要なすべての依存 JAR ファイル、クラス、および module.properties ファイルが、.feature ファイルとともにパッケージ化されます。.feature(発音は「ドット フィーチャー」)ファイルは、プロジェクトのルートと同じフォルダに配置されます。このファイルには、このモジュールに関連付けられている JAR と、依存 JAR ファイルへのパスが示されます。.feature ファイルの名前は <moduleID>-module.feature です。
シスコは、Eclipse に付属している Apache ANT™ の構成ツールを使用することを推奨します。別のビルド ツールを使用することも、ご自身でビルドを作成することもできますが、ANT でビルドした場合と同じ特性のパッケージを提供する必要があります。
次の例に、.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 に依存している場合、jar を build.xml ファイルに含めることで zip ファイルに入れてください。
次の例は、サードパーティの JAR を含むモジュール レイアウトを示しています。
feature-oabc feature oabc.jar oabc lib flex flex-messaging-common.jar oabc.feature
モジュール jar と .feature が zip ファイルのトップ レベルに置かれています。/moduleID/lib/ フォルダのパスの下にサードパーティ JAR を配置します。必須ではありませんが、ベスト プラクティスはサードパーティ jar を /moduleID/lib フォルダ パスの下に置いてから、その他のサブ ディレクトリを必要に応じて追加することです。
{ jars: [ 'features/feature-oabc.jar", features/oabc/lib/flex-messaging-common.jar ], features: [ "com.cloupia.feature.oabc.OABCModule" ] }
jar ファイルへの参照は、必ず features/ で始めます。jar を .feature ファイルにリストするときに、jar が features/ から始まっていることを確認してください。これにより、jar へのパスを含めることができます。各 jar のパスは、zip ファイルで使用しているパスと同じパスにする必要があります。ベスト プラクティスは、先頭にモジュール jar を置き、その後に依存性を追加して、モジュールが確実にロードされるようにすることです。
Cisco UCS Director ユーザ インターフェイスには [オープンオートメーション(Open Automation)] コントロールが用意されており、これを使用してモジュールのアップロードや管理を行うことができます。これらのコントロールを使用して、モジュールの Zip ファイルを Cisco UCS Director にアップロードします。
(注) | アップロードでは、Zip ファイル形式のみがサポートされます。 |
モジュールを有効化またはアクティブ化するには Cisco UCS Director サービスを再起動する必要がありますが、そのためには shell admin アクセス権が必要です。このアクセス権は、システム管理者から取得します。[Cisco UCS Director シェル メニュー(Cisco UCS Director Shell Menu)] をシェル管理者として使用するには、ログイン shelladmin と管理者が支給するパスワードを使用して、SSH で Cisco UCS Director にアクセスする必要があります。Windows システムでの SSH アクセスには PuTTY(http://www.putty.org/ を参照)を使用し、Mac ではビルトインの SSH ユーティリティを使用します。