Quantcast
Channel: VMware Communities : Blog List - All Communities
Viewing all articles
Browse latest Browse all 3135

NSX-T の Policy API をためす。Part.3(オブジェクト作成編)

$
0
0

今回は、NSX-T のオブジェクトを、ひとつずつ Policy API で作成してみます。

 

作成する環境は、この投稿で紹介した状態に近いものです。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1(Web UI から作成)

NSX-T の Policy API をためす。Part.1(GET 編)

 

今回も、Linux の curl コマンドと、jq コマンドをインストールして利用しています。

$ cat /etc/oracle-release

Oracle Linux Server release 7.7

$ jq -V

jq-1.5

 

前回までと同様の変数も設定しています。

  • MGR: NSX Manager のアドレス
  • CRED: NSX Manager の「ユーザ:パスワード」 ※例はよくあるデモ用パスワード。

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

$ CRED='admin:VMware1!VMware1!'

 

curl コマンドでは、次のように API の URL を指定して実行します。

いくつかオプションも指定しています。

  • -k: SSL 証明書エラーの無視。(ラボ環境なので)
  • -s: サイレント モード。進捗表示などを抑止。
  • -u: ログイン 情報を指定。
  • -H: ヘッダーで JSON データを扱うことを指定。"Content-Type: application/json"
  • -X: メソッド指定。今回は GET のみ。(じつは省略可)

 

VLAN セグメントの作成。

NSX-T の Policy API でオブジェクト作成/更新では、PATCH メソッド、もしくは PUT メソッドです。

今回は、PATCH メソッドを実行していきます。

 

あらかじめ JSON 形式のデータで、オブジェクトのパラメータを用意しておきます。

VLAN セグメントではトランスポート ゾーンを指定する必要があります。

あらためて API でオブジェクトごとの情報を取得することもできますが、

ここでは以前の投稿で GET した情報(一度 UI で作成したオブジェクトの情報)をもとに Path や ID などを特定しておきます。

NSX-T の Policy API をためす。Part.1(GET 編)

 

seg-vlan-0200.json

{

  "transport_zone_path": "/infra/sites/default/enforcement-points/default/transport-zones/4954eeca-decb-487a-8582-b011d60ba19f",

  "vlan_ids": [

    "200"

  ]

}

 

JSON ファイルを指定して PATCH メソッドを実行すると、オブジェクトが作成されます。

オブジェクトの表示名(display_name)は省略しているので、URL で指定した ID と同じものになります。

 

PATCH /policy/api/v1/infra/segments/セグメントの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./seg-vlan-0200.json https://$MGR/policy/api/v1/infra/segments/seg-vlan-0200

 

Tier-0 ゲートウェイの作成。

 

Tier-0 ゲートウェイの作成。

「アクティブ/スタンバイ」モードにするパラメータだけ指定した JSON ファイルを用意しました。

 

t0-gw-01.json

{

  "ha_mode" : "ACTIVE_STANDBY"

}

 

Tier-0 ゲートウェイを作成します。

 

PATCH /policy/api/v1/infra/tier-0s/Tier-0 ゲートウェイの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./t0-gw-01.json https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01

 

Tier-0 ゲートウェイへの LocaleServices の追加。

Tier-0 ゲートウェイに、Edge クラスタを割り当てる LocaleServices を追加します。

Edge クラスタのパスは、以前の投稿での GET メソッドで確認したものです。

Edge トランスポート ノードの指定は、1つしかないので省略しています。

 

t0-gw-01_locale-services.json

{

  "edge_cluster_path": "/infra/sites/default/enforcement-points/default/edge-clusters/a2958967-0579-4cbf-a018-96cfa6553fae"

}

 

LocaleServices では ID が UUID 形式だったので、

今回は Linux の uuidgen コマンドで生成したものを指定します。

UUID は、変数 T0_LOC_ID に格納しました。

$ T0_LOC_ID=$(uuidgen)

 

JSON ファイルを指定して、LocaleServices を追加します。

 

PATCH /policy/api/v1/infra/tier-0s/Tier-0 ゲートウェイの ID/locale-services/LocaleServices の ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./t0-gw-01_locale-services.json https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services/$T0_LOC_ID

 

Tier-0 ゲートウェイへのインターフェース追加。

LocaleServices に、VLAN セグメントに接続するインタフェースを追加します。

Policy API では、インターフェースは LocaleServices の一部として扱われています。

Edge トランスポート ノードのパスは、以前の投稿での GET メソッドで確認したものです。

 

t0-gw-01_t0-uplink-01.json

{

  "segment_path" : "/infra/segments/seg-vlan-0200",

  "type" : "EXTERNAL",

  "subnets" : [ {

    "ip_addresses" : [ "192.168.200.2" ],

    "prefix_len" : 24

  } ],

  "edge_path" : "/infra/sites/default/enforcement-points/default/edge-clusters/a2958967-0579-4cbf-a018-96cfa6553fae/edge-nodes/8e1b5bda-e116-49da-8b4b-bbb2961a7900"

}

 

インターフェースを追加します。

 

PATCH /policy/api/v1/infra/tier-0s/Tier-0 ゲートウェイの ID/locale-services/LocaleServices の ID/interfaces/インターフェースの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./t0-gw-01_t0-uplink-01.json https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services/$T0_LOC_ID/interfaces/t0-uplink-01

 

Tier-0 ゲートウェイへの SNAT ルールの追加。

ここでも、JSON ファイルを用意します。

 

t0-snat-01.json

{

  "action": "SNAT",

  "display_name": "t0-snat-01",

  "enabled": true,

  "sequence_number": 100,

  "source_network": "172.16.0.0/16",

  "translated_network": "192.168.200.2",

  "logging": false

}

 

UI で NAT ルールを作成すると UUID 形式になるため、それに合わせます。

ここでも、さきほどと同様に uuidgen コマンドで UUID を生成します。

$ NAT_ID=$(uuidgen)

 

NAT ルールを追加します。

 

PATCH /policy/api/v1/infra/tier-0s/Tier-0 ゲートウェイの ID/nat/USER/nat-rules/NAT ルールの ID

$ curl -ks -u $CRED -X PATCH -H "Content-type: application/json" -d @./t0-snat-01.json https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/nat/USER/nat-rules/$NAT_ID

 

Tier-0 ゲートウェイへのスタティックルートの追加。

 

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

 

t0-gw-01_static-route.json

{

  "network": "0.0.0.0/0",

  "next_hops": [

    {

      "ip_address": "192.168.200.1",

      "admin_distance": 1

    }

  ]

}

 

PATCH /policy/api/v1/infra/tier-0s/Tier-0 ゲートウェイの ID/static-routes/ルートの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./t0-gw-01_static-route.json https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/static-routes/t0-route-01

 

Tier-1 ゲートウェイの作成。

 

Tier-1 ゲートウェイの作成。

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

今回は後から DHCP サーバを接続するため、この時点の JSON はシンプルです。

 

t1-gw-01.json

{

  "tier0_path": "/infra/tier-0s/t0-gw-01",

  "route_advertisement_types": [

    "TIER1_CONNECTED"

  ]

}

 

Tier-1 ゲートウェイを作成します。

 

PATCH /policy/api/v1/infra/tier-1s/Tier-1 ゲートウェイの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./t1-gw-01.json https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01

 

Tier-1 ゲートウェイへの LocaleServices の追加。

Tier-1 ゲートウェイの Edge 割り当てをする LocaleServices を追加します。

Edge 関連のパスは、以前の投稿での GET メソッドで確認したものを指定しています。

 

t1-gw-01_locale-services.json

{

  "edge_cluster_path": "/infra/sites/default/enforcement-points/default/edge-clusters/a2958967-0579-4cbf-a018-96cfa6553fae",

  "preferred_edge_paths": [

    "/infra/sites/default/enforcement-points/default/edge-clusters/a2958967-0579-4cbf-a018-96cfa6553fae/edge-nodes/8e1b5bda-e116-49da-8b4b-bbb2961a7900"

  ]

}

 

Tier-0 の LocaleServices と同様に、UUID を生成しておきます。

$ T1_LOC_ID=$(uuidgen)

 

LocaleServices を追加します。

 

PATCH /policy/api/v1/infra/tier-1s/Tier-1 ゲートウェイの ID/locale-services/LocaleServices の ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./t1-gw-01_locale-services.json https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/locale-services/$T1_LOC_ID

 

DHCP サーバの追加。

JSON ファイルを用意します。

 

dhcp-sv-01.json

{

  "display_name" : "dhcp-sv-01",

  "server_address" : "172.16.254.254/24",

  "lease_time" : 86400

}

 

DHCP サーバを追加します。

これは、あとで Tier-1 ゲートウェイに接続します。

 

PATCH /policy/api/v1/infra/dhcp-server-configs/DHCP サーバの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./dhcp-sv-01.json https://$MGR/policy/api/v1/infra/dhcp-server-configs/dhcp-sv-01

 

DNS フォワーダ ゾーンの追加。

 

DNS フォワーダ ゾーンの追加。

JSON ファイルを用意します。

 

dns-zone-01.json

{

  "display_name" : "dns-zone-01",

  "upstream_servers" : [ "192.168.1.101", "192.168.1.102" ]

}

 

DNS フォワーダのゾーン(UI での デフォルト ゾーン)を追加します。

 

PATCH /policy/api/v1/infra/dns-forwarder-zones/DNS フォワーダ ゾーンの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./dns-zone-01.json https://$MGR/policy/api/v1/infra/dns-forwarder-zones/dns-zone-01

 

DNS フォワーダの追加。

JSON ファイルを用意します。

直前に作成したデフォルト ゾーンのパスも指定します。

 

dns-forwarder.json

{

  "display_name" : "dns-sv-01",

  "listener_ip" : "172.16.253.254",

  "default_forwarder_zone_path" : "/infra/dns-forwarder-zones/dns-zone-01",

  "enabled" : true

}

 

DNS フォワーダを追加します。

 

PATCH /policy/api/v1/infra/tier-1s/Tier-1 ゲートウェイの ID/dns-forwarder

$ curl -ks -u $CRED -H "Content-type: application/json" -X PATCH -d @./dns-forwarder.json https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/dns-forwarder

 

Tier-1 ゲートウェイへの DHCP サーバ接続。

前の手順で作成した DHCP サーバを、Tier-1 ゲートウェイに接続します。

ここだけは、オブジェクト更新なので PUT メソッドを利用しています。

PUT では _revision の数値をチェックするので、Tier-1 ゲートウェイの現在の _revision を直前に確認する必要があります。

ここでは、作成直後なので「"_revision" : 1」です。

(作成したばかりのオブジェクトはまず 1 になります)

 

Tier-1 ゲートウェイの _revision は、次のように GET メソッドで確認することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01 | jq -r ._revision

1

 

あわせて、DNS フォワーダのために

route_advertisement_types に TIER1_DNS_FORWARDER_IP を追記しています。

 

t1-gw-01_full.json

{

  "tier0_path": "/infra/tier-0s/t0-gw-01",

  "route_advertisement_types": [

    "TIER1_DNS_FORWARDER_IP",

    "TIER1_CONNECTED"

  ],

  "dhcp_config_paths": [

    "/infra/dhcp-server-configs/dhcp-sv-01"

  ],

  "_revision": 1

}

 

ここだけは、作成ずみオブジェクトの更新なので、PUT メソッドです。

PUT /policy/api/v1/infra/tier-1s/Tier-1 ゲートウェイの ID

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PUT -d @./t1-gw-01_full.json https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01

 

オーバーレイ セグメントの作成。(2つ)

最後に、オーバーレイ セグメントを作成します。

API の URL は、最初に作成した VLAN セグメントと同じものです。

JSON ファイルは、それぞれ DHCP での IP アドレス範囲も指定しています。

 

seg-overlay-01.json

{

  "subnets" : [ {

    "gateway_address" : "172.16.1.1/24",

    "dhcp_ranges" : [ "172.16.1.10-172.16.1.250" ],

    "network" : "172.16.1.0/24"

  } ],

  "connectivity_path" : "/infra/tier-1s/t1-gw-01",

  "transport_zone_path" : "/infra/sites/default/enforcement-points/default/transport-zones/4d5e3804-e62c-40ab-af7c-99bab2d5e5e8"

}

 

1つめのオーバーレイ セグメントを作成します。

$ curl -ks -u $CRED -H "Content-type: application/json" -X PATCH -d @./seg-overlay-01.json https://$MGR/policy/api/v1/infra/segments/seg-overlay-01

 

seg-overlay-02.json

{

  "type" : "ROUTED",

  "subnets" : [ {

    "gateway_address" : "172.16.2.1/24",

    "dhcp_ranges" : [ "172.16.2.10-172.16.2.250" ],

    "network" : "172.16.2.0/24"

  } ],

  "connectivity_path" : "/infra/tier-1s/t1-gw-01",

  "transport_zone_path" : "/infra/sites/default/enforcement-points/default/transport-zones/4d5e3804-e62c-40ab-af7c-99bab2d5e5e8"

}

 

2つめのオーバーレイ セグメントを作成します。

$ curl -ks -u $CRED -H "Content-type: application/json" -X PATCH -d @./seg-overlay-02.json https://$MGR/policy/api/v1/infra/segments/seg-overlay-02

 

ここまでに作成したオブジェクトは、NSX Manager の UI、もしくは

Part.1 の投稿で紹介した GET メソッドで確認できるはずです。

NSX-T の Policy API をためす。Part.1(GET 編)

 

以上、Policy API で NSX-T のオブジェクトを作成してみる話でした。


Viewing all articles
Browse latest Browse all 3135

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>