オブジェクト モデルの包括的な概要はこのドキュメントの対象ではありませんが、プログラム可能性という観点から、ACI 機能のあらゆる側面がオブジェクト モデルに含まれていることに注意することが重要です。つまり、ファブリックで行えるすべての構成は、REST API　を使用してプログラムで行えるということです。これには、内部ファブリックのネットワーキング、外部のネットワーキング、仮想化統合、計算統合、およびその他すべての製品の側面が含まれています。

このデータは、管理情報ツリー内に、プロパティ、アイデンティティ、および適用する一貫性のルールによるプログラマチック オブジェクトとして表現されたモデルのあらゆる部分とともに保存されます。これにより、モデルの構成済みの状態が、古いノードやエントリによって収拾がつかなくなったりすることなく、あらゆる側面の検査や操作ができ、ユーザのニーズに応えられるようにすることができます。

APIC は、構成を許可し、管理および運用可能な状態を提供するだけでなく、その構成を従属コンポーネントにまで拡張するという点で、柔軟性にかなり優れています。これらの機能を促進するインターフェイスのカテゴリは主に 2 つあります。ノースバウンド REST API とサウスバウンド プログラマチック インターフェイスです。

ノースバウンド REST API は構成を許可するとともに、コントローラに管理機能へのアクセスを提供します。このインターフェイスは、GUI や CLI の重要なコンポーネントであり、また、自動化ツール、プロビジョニング スクリプト、およびサード パーティのモニタリング ツールや管理ツールへのアクセス ポイントにもなっています。REST API は、構成変更を行うためのファブリックへの唯一のエントリ ポイントであり、一貫したプログラミングを行えるようにするための、アーキテクチャの重要な側面となっています。

APIC のサウスバウンド インターフェイスは、ファブリックを越えて従属するデバイスまでの拡張を目的とする宣言型モデルを考慮しています。つまり、ACI ファブリックの開放性における重要な側面であり、そのポリシーにおいては、APIC を通じてプログラミングすれば、ハイパーバイザ、L4-7 デバイス、将来的にはその他にもプッシュすることができつため、それらのデバイスを個々に構成する必要はありません。このサウスバウンドの拡張機能は、L4-7 デバイス パッケージと OpFlex という 2 つのモデルを通じて実現されます。

L4-7 デバイス パッケージ インターフェイスでは、ACI ポリシーについての暗黙の知識を持たない既存の L4-7 デバイスに ACI がポリシーを適用できます。IP 経由でアクセス可能な何らかの形式のインターフェイスがデバイスにある限り、これらのデバイスはどのベンダーのものであってもかまいません。デバイス パッケージの実際の実装は、固有の構成インターフェイス、つまり、REST、CLI、SOAP などを介してデバイスに到達可能な、含まれている実行環境内の APIC 上で実行する、Python スクリプトで行われます。ユーザがサービス グラフや EPG ポリシーの変更を加えると、デバイス パッケージが APIC ポリシーを L4-7 デバイスの API コールに変換します。

OpFlex は、情報モデルの一部として定義された管理対象オブジェクトのデータ交換を可能にするように設計されています。OpFlex 自体は、情報モデルを管理せず、ツリーの各ノードに関連付けられたユニバーサル リソース識別子（URI）を持つツリー ベースの抽象モデルと一緒に使用できます。プロトコルは、XML および JSON（および一部のシナリオで使用されているバイナリ符号化）をサポートし、JSON-RPC over TCP などの標準的なリモート プロシージャ コール（RPC）メカニズムを使用するように設計されています。現在、ACI では、ポリシーをアプリケーション仮想スイッチに拡張したり、OpenStack にグループ ベースのポリシーを拡張するために、OpFlexが使用されています。

Application Policy Infrastructure Controller (APIC) REST API は、REST アーキテクチャを使用するプログラム的なインターフェイスです。API は JavaScript オブジェクトの表記（JSON）または拡張マークアップ言語（XML）のドキュメントを含む HTTP（デフォルトでは無効）または HTTPS のメッセージを受け入れ、返します。プログラミング言語を使用して、API メソッドまたは MO の説明を含むメッセージや JSON または XML ドキュメントを生成できます。

REST API は、MIT へのインターフェイスであり、オブジェクト モデルの状態を操作できます。APIC コマンドライン インターフェイス（CLI）、GUI、および SDK は同じ REST インターフェイスを使用するため、情報を表示する場合は常に、REST API を介して読み込まれ、構成変更が行われた場合は REST API を通じて書き込まれます。また、REST API は、統計情報、フォールト、監査イベントなど、他の情報を取得できるインターフェイスも提供し、さらにプッシュベースのイベント通知をサブスクライブする手段も提供するため、MIT 内で変更が発生した場合はイベントを Web ソケットを通じて送信できます。

API では、HTTP を通じた POST 操作、GET 操作、DELETE 操作など、標準的な REST メソッドがサポートされています。POST メソッドと DELETE メソッドは、同じ入力パラメータで複数回呼び出されても、それ以上の効果を持たないべき等です。GET メソッドはべきゼロで、何らの変更も行うことなく（つまり、読み取り専用操作）ゼロ回または複数回呼び出すことができます。

REST インターフェイスに出入りするペイロードは、XML エンコーディングまたは JSON エンコーディングによりカプセル化できます。XML の場合、エンコーディング操作は簡単です。要素タグはパッケージとクラスの名前で、そのオブジェクトのプロパティはその要素の属性として指定します。含有は、子要素を作成して定義します。

JSON の場合、エンコーディングにはツリーベースの階層を反映する特定のエントリの定義が必要です。ただし、その定義はツリーのすべてのレベルで繰り返されるため、最初に理解していれば実装はかなり簡単です。

• すべてのオブジェクトを JSON ディクショナリとして記述します。この場合、キーはパッケージとクラスの名前で、値は、属性と子という 2 つのキーを持つ別のネストされたディクショナリになります。

• 属性キーには、オブジェクト上の属性を定義するキー値ペアを記述する、さらにネストされたディクショナリが含まれています。

• 子キーには、すべての子オブジェクトを定義するリストが含まれています。このリストの子オブジェクトは、ここで説明したように定義された、ネストされたオブジェクトを含むディクショナリです。

読み取り操作

オブジェクト ペイロードは、XML または JSON として適切に符号化された後は、REST API での作成、読み取り、更新、削除の操作に使用できます。次の図に、REST API からの読み取り操作の構文を示します。

REST API は、HTTP ベースであるため、特定のリソース タイプにアクセスするようにユニバーサル リソース識別子（URI）を定義することが重要です。要求 URI の最初の 2 つのセクションでは、APIC のプロトコルとアクセスの詳細を単に定義します。要求 URI の次のセクションは、API の呼び出しを指示するリテラル文字列 /api です。先に説明したように、読み取り操作は一般に、オブジェクトまたはクラスに対するものであるため、URI の次の部分で操作が MO に対してか、クラスに対してかを指定します。次のコンポーネントで、オブジェクトベースのクエリに対して照会する完全修飾 Dn か、クラスベースのクエリに対するパッケージとクラス名のいずれかを定義します。要求 URI の最後の必須部分はエンコーディング形式で、.xml か .json のいずれかです。これはペイロード形式を定義する唯一の方法です（APIC は Content-Type やその他のヘッダーを無視します）。

書き込み操作

REST API の作成操作と更新操作は両方とも POST メソッドを使用して実装されます。そのため、まだない場合はオブジェクトが作成され、既に存在する場合は、既存の状態と必要な状態との間の変化を反映するように更新されます。

作成操作と更新操作の両方に複合オブジェクト階層が含まれていることがあります。そのため、すべてのオブジェクトが同じコンテキスト ルートにあり、REST API のデータ ペイロードの 1 MB の制限を超えていない限り、1 つのコマンドで完全なツリーを定義することができます。この制限は、パフォーマンスを保証し、高負荷時にシステムを保護するために設定されています。

コンテキスト ルートは、APIC が複数のコントローラに情報を配信する方法を定義するのに便利で、一貫性の確保に役立ちます。ほとんどの場合、構成はユーザに透過的である必要があります。ただし、かなり大規模な構成で、それが分散トランザクションになる場合は、小さく分割する必要がある場合があります。

作成操作と更新操作は、オブジェクト レベルで常に対象となること以外は、読み取り操作と同じ構文を使用します。これは、特定のクラスのあらゆるオブジェクトに変更を加えることができないからです（その必要もありません）。作成操作または更新操作は、特定の管理対象オブジェクトを対象とする必要があります。そのため、リテラル文字列 /mo で管理対象オブジェクトの Dn が提供されることを示し、その次に実際の Dn を示します。フィルタ文字列を POST 操作に適用できます。たとえば、POST 操作の結果を応答で取得する場合は、rsp-subtree=modified クエリ文字列を渡し、POST 操作によって変更されたオブジェクトを応答に含めるように指示します。

POST 操作のペイロードには、Cisco API コマンド本文を定義する管理対象オブジェクトを表す XML または JSON の符号化データが含まれます。

Filters

REST API は、柔軟性のあるさまざまなフィルタをサポートしており、検索範囲を絞り込み、よりすばやく情報を見つけるのに役立ちます。フィルタ自体は、クエリの URI オプションとして付加され、疑問符（?）で始まり、アンパサンド（&）で連結されます。複数の条件をまとめて連結して複雑なフィルタを形成できます。

次のクエリ フィルタを使用できます。

Cobra を使用するコードでは、まず、ログイン セッションを確立します。現在、Cobra はユーザ名とパスワードベースの認証と、証明書ベースの認証をサポートしています。次に、ユーザ名とパスワード名をベースにした認証を使用する例を示します。

import cobra.mit.access
import cobra.mit.session
apicUri = 'https://10.0.0.2'
apicUser = 'username'
apicPassword = 'password'
ls = cobra.mit.session.LoginSession(apicUri, apicUser, apicPassword)
md = cobra.mit.access.MoDirectory(ls)
md.login()

この例では、Cisco APIC にログインし、認証される md という MoDirectory オブジェクトを実装します。何らかの理由で認証が失敗した場合、Cobra は cobra.mit.request.CommitError 例外メッセージを表示します。セッションにログインしたら、続行できます。

Cobra SDK を使用して、このワークフローに概ね従っている MIT を操作します。

1. 操作するオブジェクトを特定します。
2. 属性を変更する、あるいは子オブジェクトを追加または削除する要求を構築します。
3. オブジェクトに加えた変更をコミットします。

たとえば、新しいテナントを作成する場合は、まず、MIT のどこにテナントが配置されるか、この場合は、policy Universe の監視対象オブジェクトの子オブジェクト（polUniMo）を特定します。

import cobra.model.pol
polUniMo = cobra.model.pol.Uni('')

polUniMo オブジェクトを定義すると、テナント オブジェクトを polUniMo の子として作成できます。

import cobra.model.fv
tenantMo = cobra.model.fv.Tenant(polUniMo, 'cisco')

これらのすべての操作によって作成されるのは、Python オブジェクトだけです。構成を適用するには、その構成をコミットする必要があります。これを行うには、ConfigRequest というオブジェクトを使用します。ConfigRequest は、単一コンテキストに分類される MO ベースのクラスのコンテナとして機能し、単一のアトミック POST 操作にすべてコミットできます。

import cobra.mit.request
config = cobra.mit.request.ConfigRequest()
config.addMo(tenantMo)
md.commit(config)

ConfigRequest オブジェクトが作成された後、tenantMo オブジェクトが要求に追加されたら、その構成を MoDirectory オブジェクトを使用してコミットします。

先の例では、最初のステップで polUni オブジェクトのローカル コピーを構築します。命名プロパティがないため（二重の空の単一引用符によって反映されている）、MIT でルックアップしてオブジェクトの完全な Dn を把握する必要がありません。常に uni として知られています。

MIT により詳細なものをポストする場合で、オブジェクトに命名プロパティがあるときは、そのオブジェクトのルックアップを実行する必要があります。たとえば、構成を既存のテナントにポストする場合は、そのテナントを照会し、その下にオブジェクトを作成します。

tenantMo = md.lookupByClass('fvTenant', propFilter='eq(fvTenant.name, "cisco")')
tenantMo = tenantMo[0] if tenantMo else None

その結果の tenantMo オブジェクトのクラスは cobra.model.fv.Tenant となり、.dn、.status、.name など、オブジェクト自体をすべて説明するプロパティが含まれます。lookupByClass() エントリはアレイを返します。これは、複数のオブジェクトを返すことができるためです。この場合、コマンドは限定的であり、特定の名前を使用して fvTenant オブジェクトでフィルタリングします。テナントの場合、name 属性は命名属性と呼ばれる特殊なタイプの属性です。命名属性は、ローカルの名前空間で一意である必要がある相対名の構築に使用されます。その結果、名前に関するフィルタを使用した fvTenant での lookupByClass は、長さ 1 または None のアレイ、つまり何も検出されなかったことを返します。

ルックアップを全面的に避けるには、Dn オブジェクトを構築し、その Dn の子オブジェクトを作成できます。この方法は、親オブジェクトが存在する場合にだけ有効です。

topDn = cobra.mit.naming.Dn.fromString('uni/tn-cisco')
fvAp = cobra.model.fv.Ap(topMo, name='AppProfile')

Cobra と対話するためのこのような基本的な方法によって、ネットワーク構成の自動化、トラブルシューティングの実行、およびネットワークの管理に役立てることができる、より複雑なワークフローの作成に必要な構成要素が提供されます。

要求の構築プロセスには時間がかかります。これは、オブジェクト データのペイロードを、加えたいオブジェクト変更を反映した Python コードとして表す必要があるためです。Cobra SDK が Cisco ACI オブジェクトで直接モデル化されるため、オブジェクト モデルに存在するものから直接コードを生成できる必要があります。当然、これは、シスコ アドバンスド サービスが開発したツールを使用して実行できます。ツールは Arya と呼ばれる Python アダプタへの Cisco APIC REST です。

上の図には、API インスペクタ、Visore からの可能性がある入力や、REST クエリの出力が Cobra SDK コードにいかに迅速に変換され、トークン化され、より高度な方法で再利用されるかが明確に示されています。

Arya のインストールは比較的簡単で、ツールには外部依存関係がほとんどありません。Arya をインストールするには、Python 2.7.5 と Git がインストールされている必要があります。次のクイック インストール ステップを使用して Arya をインストールし、システムの Python に配置します。

git clone https://github.com/datacenter/ACI.git
cd ACI/arya
sudo python setup.py install

Arya をインストールしたら、Cisco ACI モデル化オブジェクトを表す XML または JSON を取得すると、Python コードにすばやく変換できます。たとえば、次のように入力します。

arya.py -f /home/palesiak/simpletenant.xml

このエントリによって次の Python コードが得られます。

#!/usr/bin/env python
'''
Autogenerated code using arya.py
Original Object Document Input:
<fvTenant name='bob'/>
''' raise RuntimeError('Please review the auto generated code before ' +
	'executing the output. Some placeholders will ' +
	'need to be changed')
# list of packages that should be imported for this code to work
import cobra.mit.access
import cobra.mit.session
import cobra.mit.request
import cobra.model.fv
import cobra.model.pol
from cobra.internal.codec.xmlcodec import toXMLStr
# log into an APIC and create a directory object
ls = cobra.mit.session.LoginSession('https://1.1.1.1', 'admin', 'password')
md = cobra.mit.access.MoDirectory(ls)
md.login()
# the top level object on which operations will be made
topMo = cobra.model.pol.Uni('')
# build the request using cobra syntax
fvTenant = cobra.model.fv.Tenant(topMo, name='bob')
# commit the generated code to APIC
print toXMLStr(topMo)
c = cobra.mit.request.ConfigRequest()
c.addMo(topMo)
md.commit(c)

このコードを実行する前に、まず、ランタイム エラーが発生しているプレースホルダを削除する必要があります。これは、更新する必要がある他のトークン化された値が正しいことを確認するために、意図的に配置されています。たとえば、Cisco APIC の IP アドレスはデフォルトでは 1.1.1.1 ですが、これを実際の Cisco APIC の IP アドレスを反映するように更新する必要があります。クレデンシャルやその他のプレースホルダも同様です。

完全修飾階層を持たない入力 XML または JSON を提供すると、Arya はヒューリスティックからそれを特定できない場合があることを注意してください。この場合、プレースホルダにはテキストの REPLACEME が読み込まれるため、これを正しい Dn に置き換える必要があります。この Dn は、Visore のオブジェクトを照会するか、API インスペクタに表示されたオブジェクトの要求 URI を検査することによって見つけることができます。

エンドポイント トラッカー アプリケーションは、エンドポイント クラス（fvCEp）のサブスクリプションを作成し、ファブリック（サーバ、ファイアウォール、ロード バランサ、およびその他のデバイスなど）の各エンドポイントの関連詳細情報を MySQL データベースに読み込みます。MySQL のインストールはこのドキュメントの対象外であるため、MySQL　サーバに新しいデータベースを作成するためのアクセス権がユーザにあると想定します。エンドポイント トラッカー アプリケーションには主要コンポーネントが 2 つあり、どちらも　Python スクリプトです。

• aci-endpoint-tracker.py：このスクリプトは、エンドポイント クラスのサブスクリプションを作成し、MySQL データベースに読み込みます。
• aci-endpoint-tracker-gui.py：このスクリプトは、データベースのコンテンツをオペレータに表示する方法を提供する Web インターフェイスを作成します。次に例を示します。

エンドポイント トラッカーを起動するには、次の Python スクリプトを実行します。最初のスクリプトの aci-endpoint-tracker.py は、APIC に実際に接続し、データベースに読み込みます。2 番目のスクリプトは、理解可能な Web UI でコンテンツを表示できるようにします。

user@linuxhost:~/acitoolkit/applications/endpointtracker$ ./aci-endpoint-tracker.py
MySQL IP address: 127.0.0.1
MySQL login username: root
MySQL Password:
user@linuxhost::~/acitoolkit/applications/endpointtracker$ python aci-endpointtracker-
gui.py
MySQL IP address: 127.0.0.1
MySQL login username: root
MySQL Password:
* Running on http://127.0.0.1:5000/
* Restarting with reloader

これらの Python スクリプトを実行した後で、ブラウザを起動して、Web UI に進むことができます。ACI エンドポイント トラッカーの使用は、IP や　MAC アドレスを検索フィールドに入力するようなもので、テーブルはそれに応じてフィルタリングされます。次の例では、IP アドレス 192.168.5.20 が検索フィールドに入力され、一致する結果が表示されています。

エンドポイント トラッカー アプリケーションの興味深い使い方の 1 つに、テナント、アプリケーション、EPG など、他のファブリック構造にさまざまなエンドポイントがどのようにマッピングされているかを表示できる一連の可視化があります。

次に、いくつかのスクリンショットの例を示します。これらは、エンドポイントが ACI ファブリック内のどこにあり、それらが環境内の他のオブジェクトにどのように関係または依存しているかを示しています。

コンピュータ プログラミングでは、リントは不一致の識別、または一般的なエラーの単純なデバッグ ツールを参照する用語です。ACI がインフラストラクチャをコードとして提供するという意味では、ACI がリント アプリケーションを備えているのは妥当と言えます。ACI ツールキットにはそれが備わっています。ACI Lint は、次の 2 つの主要機能の構成エラーを確認し、オペレータに通知するアプリケーションです。

セキュリティの問題：セキュアかセキュアでないかのいずれかとして EPG にタグを設定する機能をサポートし、セキュリティ境界を越えてコントラクトが使用されていないことを検証します。

構成の問題：共通する構成エラーを確認し、ユーザに報告します。

参考のため、出力例を以下に示します。

user@linuxhost:~/acitoolkit/applications/lint$ ./acilint.py
Getting configuration from APIC....
Processing configuration....
Critical 001: EPG 'default' in tenant 'infra' app 'access' is not assigned security
clearance
Critical 001: EPG 'x' in tenant 'common' app 'default' is not assigned security
clearance
Warning 001: Tenant 'Cisco' has no Application Profile.
Warning 001: Tenant 'Books' has no Application Profile.
Warning 001: Tenant '3tierapp' has no Application Profile.
Warning 001: Tenant 'mgmt' has no Application Profile.
Warning 002: Tenant 'Books' has no Context.
Warning 002: Tenant '3tierapp' has no Context.
Warning 004: Context 'oob' in Tenant 'mgmt' has no BridgeDomains.
Warning 005: BridgeDomain 'CiscoBd' in Tenant 'Cisco' has no EPGs.
Warning 005: BridgeDomain 'inb' in Tenant 'mgmt' has no EPGs.
Warning 006: Contract 'default' in Tenant 'common' is not provided at all.
Warning 006: Contract 'WebServers' in Tenant 'Acme' is not provided at all.
Warning 006: Contract 'External' in Tenant 'Acme' is not provided at all.
Warning 007: Contract 'default' in Tenant 'common' is not consumed at all.
Warning 007: Contract 'WebServers' in Tenant 'Acme' is not consumed at all.
Warning 007: Contract 'External' in Tenant 'Acme' is not consumed at all.
Warning 007: Contract 'outside-to-web' in Tenant 'roberbur' is not consumed at all.

データ センターのサポートにおいて、ケーブルの管理はきわめて重要です。ケーブル配線に問題があると、データ センターで何かを新たに展開するときに数時間の遅延が起きる場合があります。Cable Plan モジュールを使用すると、プログラマは、XML ファイルから既存のケーブル プランを容易にインポートしたり、Application Policy Infrastructure Controller (APIC) コントローラから現在実行中のケーブル プランをインポートできます。また、以前にインポートしたケーブル プランの特定ファイルへのエクスポート、ケーブル プランの比較もできます。上級ユーザであれば、Cable Plan を使用して、ケーブル プランの XML ファイルを容易に作成できます。また、ケーブル プランの問い合わせ、ケーブル プランの変更もできます。

Cisco Application Centric Infrastructure (ACI) には新しい概念が多数採用されているため、最初のうちはそのポリシー主導型アーキテクチャを理解できないユーザもいるかもしれません。このポリシー主導型アーキテクチャと使い慣れた CLI との統合を望むユーザには、ACI CLI エミュレータがその作業を支援します。CLI エミュレータ モジュールを使用すると、ACI に固有のテナント、コンテキスト、および他のポリシーに対し、show コマンドを実行できます。

マルチサイト アプリケーションを使用すると、Cisco Application Centric Infrastructure (ACI) ファブリックを複数のサイトにまたがって拡張できます。各サイトは、ファブリックがそれぞれ独自の Application Policy Infrastructure Controller (APIC) クラスタを持つ独立した ACI ファブリックになります。マルチサイト アプリケーションは、コントラクトを複数サイトに拡張させることで、 ACI のグループ ベースのポリシー モデルを保持します。これにより、異なるサイトのエンドポイント グループ間の通信が可能になります。

Snapback は、Cisco Application Centric Infrastructure (ACI) ファブリックの設定をスナップショットおよびロールバックするためのツールです。具体的には、管理者はこのツールを使用して次のタスクを実行できます。

EventFeeds アプリケーションでは、オブジェクトが更新されている場合に、WebSocket 接続での Application Policy Infrastructure Controller (APIC) 管理対象オブジェクトへの登録と記録を行います。これらの更新は、HTTP で提供されるさまざまな Atom フィードに表示されます。

Atom フィード アプリケーションに対するCisco Application Centric Infrastructure (ACI) イベントの使用例として、次のものがあります。