Skip navigation

NSX-T を REST API で操作してみます。

今回は、ラボで構成したルーティング/SNAT設定について API で追加設定してみます。

新規作成した Tier-1 論理ルータでのアドバタイズメント設定変更、

そして、Tier-0 論理ルータへのデフォルトルートと SNAT ルールの追加をします。

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.4

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

この投稿は、以前の下記投稿の API 版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.11

 

論理ルータ ID の取得。

今回の設定追加では、Tier-0/Tier-1 論理ルータ ID が必要になります。

論理ルータ ID の取得例はこれまでの投稿でも紹介しましたが、

下記のように NSX Manater の Web UI での表示名(display_name)と ID を一覧することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | {"LR_Name": .display_name, "ID": .id}'

{

  "LR_Name": "t0-router-01",

  "ID": "64f51cf0-bdf8-49d2-8a51-309b97b6ab40"

}

{

  "LR_Name": "t1-router-001",

  "ID": "b8c1e482-a6d0-47eb-aca3-315abf738c8f"

}

 

今回は、URI の一部としてルータ ID を指定したいので、変数に格納しておきます。

たとえば、下記のようなコマンドラインでもルータ ID を取得できます。

 

Tier-0 論理ルータの ID です。

$ T0_LR_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER0" and .display_name=="t0-router-01") | .id'`

$ echo $T0_LR_ID

64f51cf0-bdf8-49d2-8a51-309b97b6ab40

 

Tier-1 論理ルータの ID です。

$ T1_LR_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER1" and .display_name=="t1-router-001") | .id'`

$ echo $T1_LR_ID

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-1 論理ルータのアドバタイズメント設定変更。

API で新規作成した Tier-1 論理ルータの、ルート アドバタイズメントの有効化と、

 

念のため、現在のアドバタイズメント設定の _revision を確認しておきます。

「$T1_LR_ID」には、前の手順で取得した論理ルータ ID が含まれています。

数値がゼロ以外の場合は、JSON ファイルでもその値にあわせます。

 

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers/$T1_LR_ID/routing/advertisement | jq -r '._revision'

0

 

JSON ファイルを作成します。

今回は、アドバタイズの状態と、「すべての接続ルートをアドバタイズ」にあたる

advertise_nsx_connected_routes を有効にします。

 

t1-adv-rule.json

{

  "resource_type" : "AdvertisementConfig",

  "enabled" : true,

  "advertise_nsx_connected_routes" : true,

  "_revision" : 0

}

 

そして、アドバタイズを設定変更します。

$ curl -ks -u $CRED -X PUT -H "Content-type: application/json" -d @./t1-adv-rule.json https://$MGR/api/v1/logical-routers/$T1_LR_ID/routing/advertisement

 

Tier-0 論理ルータへのスタティック ルート追加。

NSX-T のラボ環境で必須というわけではありませんが、Tier-0 ルータへのスタティック ルートを追加します。

 

下記のような、ルーティング情報の JSON ファイルを作成します。

デフォルト ルートとして、「"network": "0.0.0.0/0"」宛のネクスト ホップとして、192.168.1.46 を指定しています。

※宛先の IP アドレスは、前提環境としてNSX-T ネットワークの外部に用意してあるゲートウェイです。

 

t0-default-route-01.json

{

  "display_name": "t0-default-route-01",

  "network": "0.0.0.0/0",

  "next_hops": [

    {

      "ip_address": "192.168.1.1",

      "administrative_distance": 1

    }

  ]

}

 

下記のようなコマンドラインで、スタティックルートを追加できます。

「$T0_LR_ID」には、前の手順で取得した論理ルータ ID が含まれています。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t0-default-route-01.json https://$MGR/api/v1/logical-routers/$T0_LR_ID/routing/static-routes

 

Tier-0 ルータへの SNAT ルール追加。

これも必須ではありませんが、Tier-0 論理ルータへの SNAT ルールを追加しておきます。

SNAT ルールは Tier-0/Tier-1 どちらでも設定できますが、

今回はこの環境のネットワーク構成にあわせて Tier-0 ルータで設定します。

 

今回は、172.16.1.0/24 からのソース アドレスを 192.168.1.46 に変換します。

ルール適用するポートは、論理ルータ ポート ID で指定します。

 

Tier-0 論理ルータ ポートは、下記のように情報取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=$T0_LR_ID

 

下記のような JSON ファイルを用意します。

applied_tos には、適用先の Tier-0 論理ルータ ポートの情報を指定しています。

 

t0-nat-rule-01.json

{

  "action": "SNAT",

  "match_source_network": "172.16.1.0/24",

  "translated_network": "192.168.1.46",

  "enabled": true,

  "applied_tos": [

    {

      "target_id": "ルール適用先の Tier-0 論理ルータ ポート ID",

      "target_display_name": "t0-uplink-port",

      "target_type": "LogicalRouterPort",

      "is_valid": true

    }

  ]

}

 

そして、下記のようなコマンドラインで SNAT ルールを追加します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t0-nat-rule-01.json https://$MGR/api/v1/logical-routers/$T0_LR_ID/nat/rules

 

これで API を利用して、以前に構築した NSX-T のテナントネットワークと同様のラボ環境ができました。

ID の取得や JSON ファイルの生成なども含めて、一連の手順をスクリプトにしておくと、

複数環境の構成を自動化したりできるかなと思います。

 

以上、NSX-T 2.4 を API で操作してみる話でした。

NSX-T を REST API で操作してみます。

今回は NSX-T による DHCP サーバを作成して、オーバーレイ論理スイッチに接続します。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.3

 

この投稿は、以前の下記投稿の API 版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.10

 

NSX-T の DHCP サーバ作成は、下記のような流れです。

  • サーバ プロファイルの作成
  • DHCP サーバの作成
  • DHCP サーバへの IP アドレス プールの作成
  • DHCP サーバを論理スイッチに接続

 

DHCP サーバ プロファイルの作成。

まず、サーバ プロファイルの定義を記載した JSON ファイルを作成します。

NSX Edge クラスタ ID が必要なので、前回まで内容をもとに ID を確認して、

JSON ファイルを完成させます。

 

下記のような JSON を作成します。

 

dhcp-prof-N.json

{

  "display_name": "DHCP プロファイル名",

  "edge_cluster_id": "Edge クラスタ ID"

}

 

DHCP サーバ プロファイルを作成します。

コマンドライン末尾の jq コマンドにより、作成された サーバ プロファイルの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-prof-N.json https://$MGR/api/v1/dhcp/server-profiles | jq -r '.id'

 

DHCP サーバの作成。

JSON ファイルを作成します。おもに赤字部分を、ネットワーク環境にあわせます。

dhcp_server_ip には、未使用の IP アドレスを指定します。

gateway_ip には、DHCP サービスを利用する論理スイッチを接続した

論理ルータ ポートの IP アドレスを指定します。

 

DNS や ドメイン名の設定といった、DHCP オプションも指定できます。

 

dhcp-sv-N.json

{

  "display_name": "DHCP サーバ名",

  "dhcp_profile_id": "DHCP サーバ プロファイルの ID",

  "ipv4_dhcp_server": {

    "dhcp_server_ip": "172.16.1.2/24",

    "dns_nameservers": [

      "192.168.1.101",

      "192.168.1.102"

    ],

    "domain_name": "go-lab.jp",

    "gateway_ip": "172.16.1.1"

  }

}

 

DHCP サーバを作成します。

ここでも、作成した DHCP サーバの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-sv-N.json https://$MGR/api/v1/dhcp/servers | jq -r '.id'

 

DHCP の IP プールの作成。

DHCP サーバには、IP アドレス プールを作成します。

 

JSON ファイルを作成します。赤字の部分を、ネットワークにあわせて修正します。

ここでの gateway_ip は、論理スイッチを接続している Tier-1 論理ルータ ポートの IP アドレスを指定します。

 

dhcp-pool-N.json

{

  "display_name": "DHCP IP アドレス プール名",

  "gateway_ip": "172.16.1.1",

  "allocation_ranges": [

    {

      "start": "172.16.1.10",

      "end": "172.16.1.99"

    }

  ]

}

 

IP アドレス プールを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-pool-N.json https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/ip-pools

 

論理スイッチへの DHCP サーバの接続。

作成した DHCP サーバを、論理スイッチに接続します。

対象の論理スイッチの ID が必要になるため、取得しておきます。

※論理スイッチ「ls-nsxt-001」は、前回に作成したものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-switches | jq -r '.results[] | select(.display_name == "ls-nsxt-001") | .id'

 

これまでの Tier-1/Tier-0 のリンクや、論理ルータ ポート作成とは異なり、

「"attachment_type" : "DHCP_SERVICE"」という DHCP 接続のための指定をします。

 

下記のような JSON ファイルを作成します。

 

dhcp-port-N.json

{

  "display_name": "DHCP サーバを接続する論理スイッチ ポートの名前",

  "logical_switch_id": "論理スイッチ ID",

  "attachment" : {

    "attachment_type" : "DHCP_SERVICE",

    "id" : "DHCP サーバの ID"

  },

  "admin_state": "UP"

}

 

では、DHCP サーバを論理スイッチに接続(ポートを作成)します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-port-N.json https://$MGR/api/v1/logical-ports

 

これで、論理スイッチに接続した VM で、DHCP サービスが利用可能になります。

ここまでの DHCP サービスの簡易的な設定確認には、

論理スイッチ に接続している VM などからの下記のようなものが考えられます。

  • 実際に VM で DHCP によるネットワーク設定がされるか?
  • VM から、DHCP サーバに指定した dhcp_server_ip への疎通確認などが可能か?

 

もうすこし続く。

NSX-T 2.4 を REST API で操作してみる。Part.5

NSX-T を REST API で操作してみます。

今回はオーバーレイ ネットワークの作成として、

論理スイッチと、ゲートウェイになる Tier-1 論理ルータ ポートを作成します。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

前回はこちら。

NSX-T 2.4 を REST API で操作してみる。Part.2

 

前提とする設計について。

サンプルをシンプルにするため、オブジェクト名やアドレスの規則を決めておきます。

「テナント番号」のような感じで、オーバーレイ ネットワーク番号(N)をもうけて、

それをオブジェクト名やアドレスに使用します。

 

これ以降の例では、下記のようにオブジェクト名/アドレスを採番しています。

  • オブジェクト名: ~-N(例: ls-nsxt-001)
  • ネットワークアドレス: 172.16.N.0/24(例: 172.16.1.0/24)
  • デフォルトゲートウェイ: 172.16.N.1(例: 172.16.1.1)

 

オーバーレイ 論理スイッチの作成。

論理スイッチを作成するための JSON ファイルを作成します。

オーバーレイ論理スイッチの作成には、オーバーレイ トランスポート ゾーンの ID が必要です。

※ここで指定するオーバーレイ トランスポート ゾーン「tz-overlay-01」は、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET  https://$MGR/api/v1/transport-zones | jq -r '.results[] | select(.transport_type=="OVERLAY" and .display_name=="tz-overlay-01") | .id'

4a51e97d-f991-407c-ab73-66820a117f70

 

JSON を作成します。赤字の部分は環境にあわせた値にします。

オーバーレイ トランスポート ゾーン ID は、この環境であれば、

「4a51e97d-f991-407c-ab73-66820a117f70」になります。

 

ls-nsxt-N.json

{

  "display_name": "オーバーレイ 論理スイッチの名前",

  "description": "",

  "transport_zone_id": "オーバーレイ トランスポート ゾーン ID",

  "admin_state": "UP",

  "replication_mode": "MTEP",

  "hybrid": false,

  "_revision": 0

}

 

論理スイッチを作成します。

作成と同時に、レスポンス情報から論理スイッチ ID を取得しておきます。

$ curl -ks -u $CRED -H "Content-type: application/json" -X POST -d @./ls-nsxt-N.json https://$MGR/api/v1/logical-switches | jq -r '.id'

144f4777-a514-4351-b88e-5f6a1f6877e5

 

論理スイッチ ポートの作成。

NSX Manager の Web UI から実施する場合は、論理ルータ ポートを作成すると、論理スイッチのポートも自動作成されます。

一方、API の場合は、手動で論理スイッチ ポートを作成しておく必要があります。

 

JSON ファイルを作成します。

ここでは、先ほど作成した論理スイッチの ID が必要となります。

この環境であれば、論理スイッチ ID は「144f4777-a514-4351-b88e-5f6a1f6877e5」です。

 

ls-port-N.json

{

  "display_name": "論理スイッチ ポート名",

  "logical_switch_id": "オーバーレイ 論理スイッチ ID",

  "admin_state": "UP"

}

 

論理スイッチ ポートを作成します。

ここでも、作成した論理スイッチ ポートの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./ls-port-N.json https://$MGR/api/v1/logical-ports | jq -r '.id'

02c7afd1-20cf-4528-8de2-360534960cd6

 

Tier-1 論理ルータ ポートの作成。

論理スイッチを Tier-1 論理ルータに接続し、ゲートウェイとなる IP アドレスを設定します。

 

ここでは、先ほど作成した、論理スイッチ ポートの ID が必要になります。

さらに、Tier-1 論理スイッチの ID が必要となるため、取得しておきます。

※ここでの論理スイッチ名「t1-router-001」は、前回の投稿で作成したものを指定します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.router_type=="TIER1" and .display_name=="t1-router-001") | .id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

t1-port-N.json

{

  "display_name": "論理ルータ ポートの名前",

  "resource_type": "LogicalRouterDownLinkPort",

  "linked_logical_switch_port_id": {

    "target_id": "オーバーレイ 論理スイッチ ポート ID"

  },

  "logical_router_id": "Tier-1 論理ルータ ID",

  "subnets": [

    {

      "ip_addresses": [

        "ゲートウェイの IP アドレス"

      ],

      "prefix_length": 24

    }

  ]

}

 

ここまでの情報により、ここまでの実行例であれば下記のように値を指定します。

  • logical_router_id: "b8c1e482-a6d0-47eb-aca3-315abf738c8f"
  • linked_logical_switch_port_id の target_id: "02c7afd1-20cf-4528-8de2-360534960cd6"
  • logical_router_id 配下の ip_addresses: "172.16.1.1"

 

それでは、JSON ファイルをもとに Tier-1 論理ルータ ポートを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-port-N.json https://$MGR/api/v1/logical-router-ports

 

これで、オーバーレイ ネットワークとそのゲートウェイが作成されます。

今回作成した論理スイッチに VM を接続しネットワーク設定をすれば、

ping などで Tier-1 論理ルータ ポートに設定したアドレスへの疎通がとれるはずです。

 

ただ、今回作成した論理スイッチのネットワークには DHCP サーバがないため

VM には手動でのネットワーク設定が必要になります。

次回は、NSX-T による DHCP サーバを API で作成します。

 

つづく・・・

NSX-T 2.4 を REST API で操作してみる。Part.4

NSX-T を REST API で操作してみます。

今回は、Tier-1 論理ルータの作成です。

 

一連の投稿の前提/想定環境などは下記をどうぞ。

NSX-T 2.4 を REST API で操作してみる。Part.1

 

以前に投稿した下記の、API 操作版です。

自宅ラボで NSX-T 2.4 環境を構築する。Part.9

 

Tier-1 論理ルータの作成。

まず、Tier-1 論理ルータを作成するために、JSON ファイルを用意します。

その前提として、Tier-1 論理ルータを接続する NSX Edge クラスタ の ID を取得する必要があります。

オブジェクトの ID については、殆どのものが NSX Manager の Web UI からでも確認できます。

しかし、今回はあえて ID も API で取得してみます。

 

Edge クラスタ「edge-cluster-01」の ID を取得してみます。

なお、この Edge クラスタは、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/edge-clusters | jq -r '.results[] | select(.display_name == "edge-cluster-01") | .id'

7228228c-6d93-46be-bb7a-f5e367cf1390

 

ここで用意する JSON ファイルは、下記のような内容です。

赤字の部分は、環境固有の値となります。

※これ以降の JSON も含め、わかりやすいサンプルにするため、あえてオプション指定を少なくしています。

{

  "display_name": "Tier-1 論理ルータの名前",

  "router_type": "TIER1",

  "edge_cluster_id": "Edge クラスタ ID",

  "edge_cluster_member_indices": [

    0

  ],

  "high_availability_mode": "ACTIVE_STANDBY"

}

 

display_name と edge_cluster_id に、具体的な値を指定した JSON を作成しました。

 

t1-router-001.json

{

  "display_name": "t1-router-001",

  "router_type": "TIER1",

  "edge_cluster_id": "7228228c-6d93-46be-bb7a-f5e367cf1390",

  "edge_cluster_member_indices": [

    0

  ],

  "high_availability_mode": "ACTIVE_STANDBY"

}

 

それでは、論理ルータを作成します。

作成と同時に、レスポンス情報から作成された論理ルータの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001.json https://$MGR/api/v1/logical-routers | jq -r '.id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

作成ずみの論理ルータの ID は、下記のように取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.display_name == "t1-router-001") | .id'

b8c1e482-a6d0-47eb-aca3-315abf738c8f

 

Tier-0 論理ルータとの接続。

Tier-1 論理ルータを Tier-0 論理ルータを接続(リンク)させるために、

それぞれの論理ルータにポートを作成する必要があります。

 

Tier-0 論理ルータ側のルータ ポート作成。

まず、Tier-0 論理ルータ側でポートを作成します。

このとき、Tier-0 論理ルータのルータ ID が必要になります。

ここで指定する Tier-0 論理ルータ「t0-router-01」は、前提として作成ずみのものです。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-routers | jq -r '.results[] | select(.display_name == "t0-router-01") | .id'

64f51cf0-bdf8-49d2-8a51-309b97b6ab40

 

オーバーレイ論理スイッチの論理ルータ ポート作成とは異なり、

resource_type には「LogicalRouterLinkPortOnTIER0」を指定します。

 

t1-router-001_t0-link-port.json

{

  "display_name": "作成する Tier-0 論理ルータ側のポート名",

  "resource_type": "LogicalRouterLinkPortOnTIER0",

  "logical_router_id": "Tier-0 論理ルータの ID"

}

 

それでは、ポートを作成します。

作成と同時に、レスポンス情報から作成されたポートの ID を取得しておきます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001_t0-link-port.json  https://$MGR/api/v1/logical-router-ports | jq -r '.id'

 

Tier-1 論理ルータ側のルータポート作成。

Tier-0 論理ルータ側のポートを作成した後に、Tier-1 論理ルータ側でポートを作成します。

こちらでは、下記のような指定をします。

  • logical_router_id には、この投稿の最初に作成した Tier-1 論理ルータのルータ ID を指定します。
  • resource_type では「LogicalRouterLinkPortOnTIER1」を指定します。
  • linked_logical_router_port_id では、ひとつ前の手順で作成した Tier-0 論理ルータのポート ID を指定します。

 

t1-router-001_t1-link-port.json

{

  "display_name": "作成する Tier-1 論理ルータ側のポート名",

  "resource_type": "LogicalRouterLinkPortOnTIER1",

  "logical_router_id": "Tier-1 論理ルータの ID",

  "edge_cluster_member_index": [

    0

  ],

  "linked_logical_router_port_id": {

    "target_id": "Tier-0 論理ルータ ポートの ID",

    "target_type": "LogicalRouterLinkPortOnTIER0",

    "is_valid": true

  }

}

 

作成した JSON ファイルで、論理ルータ ポートを作成します。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./t1-router-001_t1-link-port.json https://$MGR/api/v1/logical-router-ports

 

これで、Tier-1 論理ルータが作成され、Tier-0 論理ルータと接続された状態になりました。

NSX Manager の Web UI でも、Tier-0 ルータが接続されたことが確認できます。

nsxt-api-p02-01.png

 

つづく。

NSX-T 2.4 を REST API で操作してみる。Part.3

NSX-T の特徴のひとつである、REST API での操作を試してみます。

REST API を利用する場合の主な目的は、作業の自動化だと思います。

そこで、ここではいわゆる「テナント」を複数作成するようなケースを想定して、

Tier-1 論理ルータの作成から、オーバーレイ ネットワークの作成を REST API で実行してみます。

 

今回の一連の投稿です。

NSX-T 2.4 を REST API で操作してみる。Part.1 (この投稿自身)

NSX-T 2.4 を REST API で操作してみる。Part.2

NSX-T 2.4 を REST API で操作してみる。Part.3

NSX-T 2.4 を REST API で操作してみる。Part.4

NSX-T 2.4 を REST API で操作してみる。Part.5

 

それでは、まず利用する環境/ツールについて説明します。

 

利用する環境について。

以前に投稿した、自宅 NSX-T ラボ環境を利用しています。

自宅ラボで NSX-T 2.4 環境を構築する。まとめ

 

上記 URL にある「Part.9」から先の部分(Tier-1 ルータの作成から)を、REST API で構築してみます。

イメージ図の、赤枠の部分です。

NSX-T_Lab-2019_API-Part-01.png

 

NSX-T Data Center REST API について。

NSX-T Data Center REST API は、下記のサイトにドキュメントが公開されています。

NSX-T Data Center REST API - VMware API Explorer - VMware {code}

 

NSX Manager が展開されている環境であれば、NSX Manager ログイン後の

「?」→「API ドキュメント」でも確認できます。

nsxt-api-p01-01.png

 

API Guide のドキュメントが参照できます。

nsxt-api-p01-02.png

 

利用するツールについて。

今回は、Linux OS を実行元としています。

root@photon-machine [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=5e45dc9

 

REST API にアクセスする場合に一般的に利用される下記のコマンドライン ツールを利用しています。

  • curl
  • jq

 

curl と jq は、yum / tdnf などでインストールしておきます。

VMware Photon OS 3.0 を利用する場合は、デフォルトでは jq がインストールされていないので、

下記のように tdnf コマンドでインストールしておきます。

# tdnf install -y jq

 

REST API へのアクセス方法について。

REST API へのアクセスには curl コマンドを使用しますが、OS root ユーザである必要はなく一般ユーザで実行可能です。

そこで、bash のプロンプトは「$」とだけ表記しています。

今回は、コマンドライン例の見ための都合により、ユーザ:パスワード を変数に格納しています。

※ちなみに例示のパスワードは VMware のデモ/ハンズオンなどで一般的に利用されるものです。

$ CRED='admin:VMware1!VMware1!'

 

また、NSX Manager のアドレスは、変数「MGR」に格納して、

コマンドラインでも「$MGR」と表記しています。

※これは、うちの自宅 NSX Manager (ローカル)のアドレスです。

$ MGR=lab-nsxt-mgr-01.go-lab.jp

 

curl コマンドによるアクセス確認として、NSX-T のバージョンを確認してみます。

NSX-T の REST API では、JSON 形式のデータを扱います。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/node/version

{

  "node_version": "2.4.1.0.0.13716579",

  "product_version": "2.4.1.0.0.13716575"

}

 

必要に応じて、jq コマンドで JSON をフィルタ/成形します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/node/version | jq -r '.product_version'

2.4.1.0.0.13716575

 

それでは、NSX-T 環境を API で操作していきます。

つづく!

NSX-T 2.4 を REST API で操作してみる。Part.2