今回は、NSX-T の REST API でオブジェクトを削除していきます。

これまでの投稿で、NSX-T のネットワークを REST API で作成してみました。

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

このラボ環境の概要は下記をどうぞ。

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

今回の削除対象も下記イメージ図の赤枠の部分です。

基本的に、これまで API で作成したオブジェクトを、作成時とは逆順に削除することになります。

削除対象オブジェクトの ID 確認。

API によるオブジェクトの削除では、オブジェクトの ID（UUID）を指定します。

そこで、おもな削除対象オブジェクトの ID を先に確認しておきます。

API の利用には、これまでの投稿と同様に curl / jq コマンドを利用しています。

変数「$CRED」では「ユーザ名:パスワード」、変数 $MGR には NSX Manager のアドレスを格納しています。

論理ルータ「t1-router-001」の UUID を取得します。

$ 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

論理スイッチ「ls-nsxt-001」の UUID を取得します。

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

639efb66-79aa-41f2-8c34-a32d4d74a8d5

DHCP サービスの削除。

DHCP サーバと論理スイッチを切断。

論理スイッチから、attachment_type が「DHCP_SERVICE」になっている論理ポートを確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-ports?logical_switch_id=639efb66-79aa-41f2-8c34-a32d4d74a8d5 | jq -r '.results[] | select(.attachment.attachment_type=="DHCP_SERVICE") | .id'

f5cd00bd-143c-4506-950c-9b43112d233a

論理スイッチから、論理ポートを削除します。

DHCP サーバを接続している論理ポートなので、一般的な論理ポート削除とは異なり「detach=true」を指定します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-ports/f5cd00bd-143c-4506-950c-9b43112d233a?detach=true

DHCP サーバの削除。

DHCP サーバ「dhcp-sv-001」の ID を確認します。

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

63ad4619-3749-438e-83e9-90265604174c

DHCP サーバを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/servers/63ad4619-3749-438e-83e9-90265604174c

DHCP サーバ プロファイルの削除。

DHCP サーバ プロファイル「dhcp-prof-001」の ID を確認します。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/server-profiles | jq -r '.results[] | select(.display_name=="dhcp-prof-001") | .id'

488512e2-d953-42ea-95c4-affe4b1dc063

DHCP サーバ プロファイルを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/server-profiles/488512e2-d953-42ea-95c4-affe4b1dc063

オーバーレイ論理スイッチの削除。

論理スイッチを削除します。論理スイッチ ID は、冒頭で確認したものを指定します。

「cascade=true」で、論理スイッチに作成されている論理ポートを一緒に削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-switches/639efb66-79aa-41f2-8c34-a32d4d74a8d5?cascade=true

Tier-1 論理ルータの削除。

Tier-1 論理ルータは、論理ルータ ポートが残っていると削除することができません。

そこで、対象の論理ルータにポートが残っていないか確認してみます。

logical_router_id を指定することで、特定の論理ルータに作成されているポートを取得することができます。

論理ルータの ID は、冒頭で確認したものを指定しています。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=b8c1e482-a6d0-47eb-aca3-315abf738c8f | jq -r '.results[] | {display_name:.display_name, resource_type:.resource_type, logical_router_port_id:.id}'

{

  "display_name": "LinkedPort_t1-router-001",

  "resource_type": "LogicalRouterLinkPortOnTIER1",

  "logical_router_port_id": "d580e2fb-4c10-41ff-ae1d-af2d9bc5659d"

}

{

  "display_name": "t1-port-001",

  "resource_type": "LogicalRouterDownLinkPort",

  "logical_router_port_id": "2b708512-2fab-4fd2-bc83-4ed01d0569e9"

}

上記のように、ルータ ポートが残っている場合は、それぞれ削除しておきます。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-router-ports/d580e2fb-4c10-41ff-ae1d-af2d9bc5659d

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-router-ports/2b708512-2fab-4fd2-bc83-4ed01d0569e9

下記のように、論理ルータ ポートがゼロになっていることを確認することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports?logical_router_id=b8c1e482-a6d0-47eb-aca3-315abf738c8f | jq -r '.result_count'

0

論理ルータを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-routers/b8c1e482-a6d0-47eb-aca3-315abf738c8f

Tier-0 ルータ側の論理ルータ ポートの削除。

Tier-1 論理ルータと Tier-0 論理ルータのリンクの、Tier-0 論理ルータ側の論理ポート

（resource_type は LogicalRouterLinkPortOnTIER0）も削除しておきます。

複数の Tier-1 論理ルータ ポートを作成している場合は、Tier-1 論理ルータ側のポートを削除する前に

対向のポート ID を確認しておくとよいと思います。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/logical-router-ports | jq -r '.results[] | select (.resource_type=="LogicalRouterLinkPortOnTIER0") | {display_name:.display_name, logical_router_id:.logical_router_id, logical_router_port_id:.id}'

{

  "display_name": "LinkedPort_t1-router-001",

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

  "logical_router_port_id": "722849ae-a48a-4684-99e1-d7e06dcc0a23"

}

論理ルータ ポートを削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/logical-routers/722849ae-a48a-4684-99e1-d7e06dcc0a23

API の動作確認やツール開発では、何度も環境を初期化する需要があるはずなので、

このような DELETE メソッドによるオブジェクト削除の自動化ができるようにしておくと便利かなと思います。

以上、NSX-T の REST API でひたすらオブジェクト作成する話でした。

NSX-T による DHCP サービス機能では、一般的な DHCP サーバと同様に

MAC アドレスと IP アドレスの静的な割り当て（static-bindings）が可能です。

ドキュメントだと、下記のあたりに説明がありますが、

あまり詳しくは触れられていないため、設定の様子を残しておこうと思います。

DHCP サーバの作成

環境の説明。

設定は、以前に紹介した環境を利用しています。

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

そして、設定対象の NSX-T の DHCP サーバは、下記のように作成しています。

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

設定対象の（VM の）MAC アドレスは、vSphere Client からだけではなく、

NSX Manager からでも確認できます。

「ネットワークとセキュリティの詳細設定」→「インベントリ」→「仮想マシン」を開くと、

VM と、その vNIC の MAC アドレスを確認することができます。

今回の ゲスト OS（DHCP クライアント）は、Oracle Linux 7 です。

また、この時点ではホスト名をあらわす「コンピュータ名」が「localhost.localdomain」になっています。

※サマリにある「名前」は、ゲスト OS のホスト名ではなく、仮想マシン名です。

DHCP サーバ への IP アドレスの「静的割り当て」設定追加。

今回は、NSX の Manager で設定します。

「ネットワークとセキュリティの詳細設定」→「ネットワーク」→「DHCP」→「サーバ」を開きます。

DHCP サーバ「dhcp-sv-001」を作成ずみです。

サブネットマスク、デフォルトゲートウェイ、DNS サーバといった DHCP オプションは、

DHCP サーバで設定してあるので、静的割り当てでは、IP アドレスとホスト名を設定してみます。

「静的割り当て」にある「追加」をクリックします。

静的割り当ての設定を入力して、「追加」ボタンをクリックします。

今回は、下記だけ追加入力しています。

• IP アドレス： DHCP サービスで割り当てる IP アドレス。
• MAC アドレス： 先ほど確認した vm01 のもの。
• ホスト名： VM のゲスト OS に、DHCP で割り当てるホスト名。

ちなみに、赤い「*」印のあるもの（IP アドレスと MAC アドレス）が必須項目です。

静的割り当ての設定が追加されました。

GUI からの操作では、表示名が MAC アドレスになります。

DHCP によるアドレス設定の確認。

DHCP クライアントとなる VM では、指定した MAC アドレスを持つ vNIC のポートグループとして、

DHCP サーバを接続してある NSX-T 論理スイッチ（今回は ls-nsxt-001）を割り当てます。

※これは NSX Manager ではなく vSphere Client で設定します。

ゲスト OS では、DHCP クライアントによるネットワーク設定のタイミングで、

静的割り当て設定した IP アドレスとホスト名が反映されるはずです。

Oracle Linux 7 では、Red Hat Enterprise Linux 7 や CentOS 7 と同様に

ネットワーク設定で NetworkManager が利用されています。

たとえば VM コンソールなどからアクセスして、

下記のように journalctl コマンドなどで NetworkManager のログから

DHCP によるネットワーク設定の様子を確認することができます。

NSX Manager のインベントリでも、

vm01 の IP アドレスとホスト名が変更されたことが確認できます。

この機能を利用することで、VM デプロイ時などに

IP アドレスを制御しやすくなりそうかなと思います。

つづくつもり・・・

NSX-T による DHCP サービス機能で、MAC アドレスと IP アドレスの静的な割り当て（static-bindings）を設定してみます。

前回の投稿では、NSX Manager の Web インターフェースから設定しました。

NSX-T 2.4 で DHCP の static-bindings を使用してみる。（GUI 編）

今回は、REST API から同様の設定をしてみます。

環境の説明。

以前の投稿と同様に、下記の環境を利用しています。

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

REST API へのアクセスには、下記の投稿のように curl + jq コマンドを利用しています。

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

この投稿でのコマンドライン中にある $CRED には「ユーザ:パスワード」、

$MGR には NSX Manager のアドレスを格納しています。

IP アドレスを割り当てる MAC アドレスの確認。

DHCP の static-bindings では、MAC アドレスに IP アドレスを割り当てます。

今回は、NSX-T を利用している vSphere（ESXi）上の VM がもつ vNIC に IP アドレスを設定します。

そのため、NSX Manager からでも VM ／ vNIC とその MAC アドレスが確認できます。

REST API では、この情報を virtual-machines と vifs の情報を GET することで確認できます。

今回は、例をシンプルにするため下記を前提としています。

• 環境内の VM 名に重複がない。
• VM の vNIC は 1つだけ。

VM の名前（vm01）から MAC アドレスを確認してみます。

vm01 の情報は、下記のように取得できます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/virtual-machines | jq -r '.results[] | select(.display_name == "vm01")'

{

  "host_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

  "source": {

    "target_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

    "target_display_name": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

    "target_type": "HostNode",

    "is_valid": true

  },

  "external_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812",

  "power_state": "VM_RUNNING",

  "local_id_on_host": "1",

  "compute_ids": [

    "moIdOnHost:1",

    "hostLocalId:1",

    "locationId:564d7a4c-fa5e-33bf-1c3e-ca12ebd75f6f",

    "instanceUuid:501f7750-8d29-8c53-2d5e-e5b88b06f812",

    "externalId:501f7750-8d29-8c53-2d5e-e5b88b06f812",

    "biosUuid:421fa276-d1a6-c34a-2dc6-ea0de1d2ace5"

  ],

  "type": "REGULAR",

  "guest_info": {

    "os_name": "Oracle Linux 7 (64-bit)",

    "computer_name": "localhost.localdomain"

  },

  "resource_type": "VirtualMachine",

  "display_name": "vm01",

  "_last_sync_time": 1563839902208

}

ここから、下記のように VM の ID だけを取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/virtual-machines | jq -r '.results[] | select(.display_name == "vm01") | .external_id'

501f7750-8d29-8c53-2d5e-e5b88b06f812

そして、VM ID をもとに、vNIC の MAC アドレスを確認します。

※ちなみにこの VM は、前回の投稿で DHCP による IP アドレス ／ ホスト名が設定がされた状態です。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/vifs | jq -r '.results[] | select(.owner_vm_id == "501f7750-8d29-8c53-2d5e-e5b88b06f812")'

{

  "external_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812-4000",

  "owner_vm_id": "501f7750-8d29-8c53-2d5e-e5b88b06f812",

  "host_id": "c33ad1aa-f3b4-4a24-98da-bc32eeff1f31",

  "vm_local_id_on_host": "1",

  "device_key": "4000",

  "device_name": "Network adapter 1",

  "mac_address": "00:50:56:9f:fa:ac",

  "lport_attachment_id": "5ccf3507-1001-419e-81be-3f197bf583f4",

  "ip_address_info": [

    {

      "source": "VM_TOOLS",

      "ip_addresses": [

        "172.16.1.101",

        "fe80::1b24:4d58:f0b4:bfe8"

      ]

    }

  ],

  "resource_type": "VirtualNetworkInterface",

  "display_name": "Network adapter 1",

  "_last_sync_time": 1563839902211

}

MAC アドレスだけを取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/fabric/vifs | jq -r '.results[] | select(.owner_vm_id == "501f7750-8d29-8c53-2d5e-e5b88b06f812") | .mac_address'

00:50:56:9f:fa:ac

DHCP static-bindings の設定。

IP アドレスの静的割り当て（static-bindings）は、NSX-T による DHCP サーバに対して設定します。

まず、DHCP サーバの ID を確認します。

今回も、DHCP サーバ名は「dhcp-sv-001」にしています。

$ DHCP_SV_ID=`curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers | jq -r '.results[] | select(.display_name=="dhcp-sv-001") | .id'`

$ echo $DHCP_SV_ID

73445136-5ab5-459a-a357-d736e534a467

静的割り当てのための JSON ファイル「dhcp-bind_vm01.json」を作成しておきます。

今回は、下記のパラメータのみ指定しています。

• 表示名（display_name）
• MAC アドレス ※必須
• IP アドレス ※必須
• ホスト名

JSON ファイルのパラメータは、前回の GUI での設定時と同じものです。

同じ静的割り当て設定が存在するとエラーになるので、

すでに設定がある場合は、NSX Manager などから削除しておきます。

$ cat ./dhcp-bind_vm01.json

{

  "display_name": "00:50:56:9f:fa:ac",

  "mac_address": "00:50:56:9f:fa:ac",

  "ip_address": "172.16.1.101",

  "host_name": "vm01"

}

作成した JSON ファイルを指定して POST メソッドを実行すると、DHCP の静的割り当てを作成できます。

curl を実行すると、作成された設定の情報が表示されます。

$ curl -ks -u $CRED -X POST -H "Content-type: application/json" -d @./dhcp-bind_vm01.json https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings

{

  "mac_address" : "00:50:56:9f:fa:ac",

  "ip_address" : "172.16.1.101",

  "host_name" : "vm01",

  "resource_type" : "DhcpStaticBinding",

  "id" : "bb2cd277-20f3-4184-81c5-250f20f71f7a",

  "display_name" : "00:50:56:9f:fa:ac",

  "lease_time" : 86400,

  "_create_user" : "admin",

  "_create_time" : 1564095298669,

  "_last_modified_user" : "admin",

  "_last_modified_time" : 1564095298669,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

これで、対象 MAC アドレスに IP アドレスが設定されるようになります。

DHCP static-bindings の削除。

一方、 静的割り当ての削除は、DELETE メソッドで実施できます。

静的割り当て設定の ID は、作成時にも表示されていましたが、

下記のように VM 名などから取得することもできます。

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings | jq -r '.results[] | select(.host_name == "vm01") | .id'

bb2cd277-20f3-4184-81c5-250f20f71f7a

そして、削除は DELETE メソッドで削除できます。

$ curl -ks -u $CRED -X DELETE https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings/bb2cd277-20f3-4184-81c5-250f20f71f7a

$ curl -ks -u $CRED -X GET https://$MGR/api/v1/dhcp/servers/$DHCP_SV_ID/static-bindings

{

  "results" : [ ],

  "result_count" : 0

}

うまく工夫をすると、NSX-T で IPAM（IP アドレス管理）を実現することもできそうかなと思います。

以上、NSX-T での DHCP static-bindings 設定でした。

vSphere 6.7 U3 / vSAN 6.7 U3 から、VMware Cloud Native Storage と呼ばれるソリューションが提供されました。

これにより、Kubernetes から vSphere Container Storage Interface（CSI）Driver で利用されているボリュームが確認しやすくなります。

さっそく、ドキュメントをもとに試してみます。

About Getting Started with VMware Cloud Native Storage

今回の環境。

Kubernetes のバージョンは、ドキュメントで利用しているものにしましたが、

Kubernetes の Maser / Worker は個人的に使い慣れている Oracle Linux 7 にしています。

• vCenter Server 6.7 U3 / ESXi 6.7 U3 / vSAN 6.7 U3
• Kubenetes Node OS： Oracle Linux 7
  • Master x 1、Worker x3
  • ESXi / vSAN 上の VM として作成。
• Kubernetes 1.14.2

VM の設定。

Cloud Native Storage（CNS）を利用する Kubernetes ノードの VM では、

disk.EnableUUID というパラメータを設定しておきます。

vSphere Client から設定可能ですが、今回は PowerCLI で設定しています。

PowerCLI> Get-Folder -Type VM -Name "ol7-k8s-lab-03" | Get-VM | Get-AdvancedSetting -Name disk.EnableUUID | select Entity,Name,Value | sort Entity

 

Entity   Name            Value

------   ----            -----

k8s-m-31 disk.EnableUUID TRUE

k8s-w-31 disk.EnableUUID TRUE

k8s-w-32 disk.EnableUUID TRUE

k8s-w-33 disk.EnableUUID TRUE

 

また、Kubernetes のセットアップで利用する kubeadm の要件を考慮して

VM あたりのリソースは、2 vCPU、メモリ 4GB 以上にしてあります。

PowerCLI> Get-Folder -Type VM -Name "ol7-k8s-lab-03" | Get-VM | select Name,PowerState,NumCPU,MemoryGB | sort Name | ft -AutoSize

 

 

Name     PowerState NumCpu MemoryGB

----     ---------- ------ --------

k8s-m-31  PoweredOn      2        4

k8s-w-31  PoweredOn      2        4

k8s-w-32  PoweredOn      2        4

k8s-w-33  PoweredOn      2        4

 

Linux OS の準備。

ドキュメントでは Ubuntu を使用していますが、

今回は、あえて Oracle Linux を使用してみました。

ただし Kubernetes にかかわる kubeadm と Docker は、Oracle Linux むけのものではなく

それぞれのプロダクトの Yum リポジトリを追加して、そこからインストールしています。

Linux OS は ISO インストーラからインストールし、ネットワーク設定を済ませた状態です。

今回は、kubernetes のセットアップからを手動で試しやすいように、

下記のような Ansible Playbook を作成して、OS のセットアップとファイル配布をしています。

GitHub - gowatana/vmware-cns-demo

Kubernetes クラスタ（Master）のセットアップ。

まず、kubeadm で Master ノードをセットアップします。

この環境での Master ノードは 1台のみです。

Master ノードにセットアップする OS に root ユーザでログインします。

Ansible で /root/01_kubeadm/kubeadm-init-master.yml ファイルを配置してあるので、

これをもとに kubeadm init コマンドを実行します。

[root@k8s-m-31 ~]# kubeadm init --config 01_kubeadm/kubeadm-init-master.yml

Master ノードがセットアップされました。

まだ NotReady ですが、このまま進めます。

[root@k8s-m-31 ~]# export KUBECONFIG=/etc/kubernetes/admin.conf

[root@k8s-m-31 ~]# kubectl get nodes

NAME       STATUS     ROLES    AGE   VERSION

k8s-m-31   NotReady   master   58s   v1.14.2

今回は root ユーザのみですすめるので、

再ログイン時に環境変数 KUBECONFIG が設定されるように、.bash_profile にも追記しておきます。

[root@k8s-m-31 ~]# echo 'export KUBECONFIG=/etc/kubernetes/admin.conf' >> /root/.bash_profile

Worker ノードのセットアップで利用する discovery.yml を取得しておきます。

[root@k8s-m-31 ~]# kubectl -n kube-public get configmap cluster-info -o jsonpath='{.data.kubeconfig}' > /etc/kubernetes/discovery.yml

discovery.yml ファイルは、これから Worker ノードにする OS の、/etc/kubernetes/ ディレクトリ配下に

scp などでコピーしておきます。

[root@k8s-m-31 ~]# scp /etc/kubernetes/discovery.yml ＜Worker Nodeのアドレス＞:/etc/kubernetes/

Flannel のセットアップ。

Kubernetes のノード間のネットワークを構成する、Flannel をセットアップしておきます。

[root@k8s-m-31 ~]# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml

clusterrole.rbac.authorization.k8s.io/flannel created

clusterrolebinding.rbac.authorization.k8s.io/flannel created

serviceaccount/flannel created

configmap/kube-flannel-cfg created

daemonset.extensions/kube-flannel-ds-amd64 created

daemonset.extensions/kube-flannel-ds-arm64 created

daemonset.extensions/kube-flannel-ds-arm created

daemonset.extensions/kube-flannel-ds-ppc64le created

daemonset.extensions/kube-flannel-ds-s390x created

Kubernetes クラスタ（Worker）のセットアップ。

Worker ノードそれぞれで kubeadm join を実行し、セットアップをすすめます。

Ansible で配置ずみの 01_kubeadm/kubeadm-init-worker.yml ファイルと、

セットアップずみの Master ノードから取得した discovery.yml ファイルを使用しています。

[root@k8s-w-31 ~]# kubeadm join --config 01_kubeadm/kubeadm-init-worker.yml

kubeadm join を実行したノードが追加されたことがわかります。

[root@k8s-m-31 ~]# kubectl get nodes

NAME       STATUS   ROLES    AGE   VERSION

k8s-m-31   Ready    master   16m   v1.14.2

k8s-w-31   Ready    <none>   32s   v1.14.2

今回は、Master 1台、Worker 3台の構成にしました。

[root@k8s-m-31 ~]# kubectl get nodes

NAME       STATUS   ROLES    AGE     VERSION

k8s-m-31   Ready    master   18m     v1.14.2

k8s-w-31   Ready    <none>   2m40s   v1.14.2

k8s-w-32   Ready    <none>   53s     v1.14.2

k8s-w-33   Ready    <none>   31s     v1.14.2

この時点だと、まだ Worker ノードがコンテナを起動しない状態（NoSchedule）ですが、

このまま次に進みます。

[root@k8s-m-31 ~]# kubectl describe nodes | egrep "Taints:|Name:"

Name:               k8s-m-31

Taints:             node-role.kubernetes.io/master:NoSchedule

Name:               k8s-w-31

Taints:             node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

Name:               k8s-w-32

Taints:             node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

Name:               k8s-w-33

Taints:             node.cloudprovider.kubernetes.io/uninitialized=true:NoSchedule

Cloud Provider for vSphere のセットアップ。

Kubernetes と vCenter が連携するための「Kubernetes Cloud Provider for vSphere」をセットアップします。

GitHub - kubernetes/cloud-provider-vsphere: Kubernetes Cloud Provider for vSphere

ここからは、すべて Master ノードで作業します。

今回のデモでは、Cloud Provider で指定する設定ファイルのテンプレートも、Ansible で配布しています。

[root@k8s-m-31 ~]# ls -1 ./02_k8s-csi/

csi-driver-deploy.yaml

csi-driver-rbac.yaml

csi-vsphere.conf

vsphere.conf

このうち、vsphere.conf を環境にあわせて編集します。

• このサンプルファイルは自宅ラボの環境です。
• ユーザー /  パスワードは、デモむけに あえて安直なものにしています。

[root@k8s-m-31 ~]# ls ./02_k8s-csi/vsphere.conf

[Global]

insecure-flag = "true"

 

[VirtualCenter "infra-vc-01.go-lab.jp"]

user = "administrator@vsphere.local"

password = "VMware1!"

port = "443"

datacenters = "infra-dc-01"

 

[Network]

public-network = "vxw-dvs-30-virtualwire-14-sid-10003-ls-lab-k8s-003"

vsphere.conf ファイルをもとに、cloud-config という ConfigMap を作成します。

この名前は、後続の kubectl apply で指定している YAML ファイルの内容に合わせてあります。

[root@k8s-m-31 ~]# kubectl create configmap cloud-config -n kube-system --from-file ./02_k8s-csi/vsphere.conf

configmap/cloud-config created

そして、GitHub にある YAML ファイルをもとにリソースを準備していきます。

ClusterRole・・・

[root@k8s-m-31 ~]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-roles.yaml

clusterrole.rbac.authorization.k8s.io/system:cloud-controller-manager created

RoleBinding、ClusterRoleBinding・・・

[root@k8s-m-31 ~]# kubectl apply -f https://raw.githubusercontent.com/kubernetes/cloud-provider-vsphere/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml

rolebinding.rbac.authorization.k8s.io/servicecatalog.k8s.io:apiserver-authentication-reader created

clusterrolebinding.rbac.authorization.k8s.io/system:cloud-controller-manager created

ServiceAccount、DaemonSet、Service・・・

[root@k8s-m-31 ~]# kubectl apply -f https://github.com/kubernetes/cloud-provider-vsphere/raw/master/manifests/controller-manager/vsphere-cloud-controller-manager-ds.yaml

serviceaccount/cloud-controller-manager created

daemonset.extensions/vsphere-cloud-controller-manager created

service/vsphere-cloud-controller-manager created

これで、下記のような Pod が起動された状態になります。

[root@k8s-m-31 ~]# kubectl get pods -n kube-system -l k8s-app=vsphere-cloud-controller-manager

NAME                                     READY   STATUS    RESTARTS   AGE

vsphere-cloud-controller-manager-275cj   1/1     Running   0          4m27s

各ノードでは、ProviderID が確認できるようになります。

[root@k8s-m-31 ~]# kubectl describe nodes | egrep "Name:|ProviderID:"

Name:               k8s-m-31

ProviderID:                  vsphere://42362f4f-d91b-4747-9d05-18c4b7287d65

Name:               k8s-w-31

ProviderID:                  vsphere://42362124-8759-dab1-e1c2-2478c6ac8450

Name:               k8s-w-32

ProviderID:                  vsphere://4236fbb9-2e70-1fc3-c87b-9dc574e80623

Name:               k8s-w-33

ProviderID:                  vsphere://4236e12c-841e-5b39-04a6-3e6b80cdc93e

また、Worker ノードの「NoSchedule」も解除されます。

[root@k8s-m-31 ~]# kubectl describe nodes | egrep "Taints:|Name:"

Name:               k8s-m-31

Taints:             node-role.kubernetes.io/master:NoSchedule

Name:               k8s-w-31

Taints:             <none>

Name:               k8s-w-32

Taints:             <none>

Name:               k8s-w-33

Taints:             <none>

CSI のセットアップ。

Container Storage Interface（CSI）Driver をデプロイします。

下記の3つのファイルを用意します。

• csi-vsphere.conf ※環境に合わせて編集
• csi-driver-rbac.yaml ※今回はドキュメントのまま
• csi-driver-deploy.yaml ※今回はドキュメントのまま

参考ドキュメント： Install the vSphere Container Storage Interface Driver

csi-vsphere.conf ファイルに、vSphere 環境の情報を記載しておきます。

先ほどのファイルと同様、これは私の自宅ラボのものなので、適宜編集します。

[root@k8s-m-31 ~]# cat ./02_k8s-csi/csi-vsphere.conf

[Global]

cluster-id = "infra-cluster-01"

[VirtualCenter "infra-vc-01.go-lab.jp"]

insecure-flag = "true"

user = "administrator@vsphere.local"

password = "VMware1!"

port = "443"

datacenters = "infra-dc-01"

vCenter の情報をもつ secret を作成します。

[root@k8s-m-31 ~]# kubectl create secret generic vsphere-config-secret -n kube-system --from-file=./02_k8s-csi/csi-vsphere.conf

secret/vsphere-config-secret created

vSphere CSI Driver の依存コンポーネントを準備します。

[root@k8s-m-31 ~]# kubectl create -f ./02_k8s-csi/csi-driver-rbac.yaml

serviceaccount/vsphere-csi-controller created

clusterrole.rbac.authorization.k8s.io/vsphere-csi-controller-role created

clusterrolebinding.rbac.authorization.k8s.io/vsphere-csi-controller-binding created

vSphere CSI Driver をデプロイします。

[root@k8s-m-31 ~]# kubectl create -f ./02_k8s-csi/csi-driver-deploy.yaml

statefulset.apps/vsphere-csi-controller created

csidriver.storage.k8s.io/csi.vsphere.vmware.com created

daemonset.apps/vsphere-csi-node created

少し待つと、CSI Driver の Pod がすべて READY になります。

[root@k8s-m-31 ~]# kubectl get pods -n kube-system | egrep "^NAME|vsphere"

NAME                                     READY   STATUS    RESTARTS   AGE

vsphere-cloud-controller-manager-275cj   1/1     Running   0          37m

vsphere-csi-controller-0                 5/5     Running   0          2m49s

vsphere-csi-node-4s2df                   3/3     Running   0          2m49s

vsphere-csi-node-8sspf                   3/3     Running   0          2m49s

vsphere-csi-node-c68fq                   3/3     Running   0          2m49s

これで、Worker ノードが CSI Node として利用できる状態になります。

[root@k8s-m-31 ~]# kubectl get csinode

NAME       CREATED AT

k8s-w-31   2019-08-27T23:29:37Z

k8s-w-32   2019-08-27T23:29:30Z

k8s-w-33   2019-08-27T23:29:27Z

サンプル アプリケーションのデプロイ。

CSI Driver によるボリュームを使用する、ステートフル アプリケーションをデプロイします。

ここでは、MongoDB をデプロイしますが、これをそのまま何かに利用するということではなく、

ただボリューム（Kubernetes の PVC ／ PV）の様子を見るデモのために利用します・・・

参考ドキュメント： Deploy a Stateful Application

1. vSphere 側の準備。

vCenter で、「仮想マシン ストレージ ポリシー」を作成しておきます。

今回は、vSAN 環境にデフォルトで作成される「vSAN Default Storage Policy」を利用します。

2. Kubernetes でのアプリケーションのデプロイ。

ここでは、下記のファイルを使用します。

今回のデモでは、これらのファイルも Ansible で Master ノードに配布しています。

[root@k8s-m-31 ~]# ls -1 ./03_demo/

mongodb-key.txt

mongodb-service.yaml

mongodb-statefulset.yaml

mongodb-storageclass.yaml

Kubernetes の StorageClass で、下記を指定します。

provisioner として「csi.vsphere.vmware.com」、

仮想マシン ストレージ ポリシー として「vSAN Default Storage Policy」を指定します。

[root@k8s-m-31 ~]# cat ./03_demo/mongodb-storageclass.yaml

---

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

  name: mongodb-sc

  annotations:

    storageclass.kubernetes.io/is-default-class: "false"

provisioner: csi.vsphere.vmware.com

parameters:

  storagepolicyname: "vSAN Default Storage Policy"

  fstype: ext4

StorageClass を作成します。

[root@k8s-m-31 ~]# kubectl create -f ./03_demo/mongodb-storageclass.yaml

storageclass.storage.k8s.io/mongodb-sc created

StorageClassが作成されました。

[root@k8s-m-31 ~]# kubectl get storageclass mongodb-sc

NAME         PROVISIONER              AGE

mongodb-sc   csi.vsphere.vmware.com   51s

Service を作成します。

[root@k8s-m-31 ~]# kubectl create -f ./03_demo/mongodb-service.yaml

service/mongodb-service created

Secret を作成します。

[root@k8s-m-31 ~]# openssl rand -base64 741 > ./03_demo/mongodb-key.txt

[root@k8s-m-31 ~]# kubectl create secret generic shared-bootstrap-data --from-file=internal-auth-mongodb-keyfile=./03_demo/mongodb-key.txt

secret/shared-bootstrap-data created

そして、StatefulSet を作成します。

[root@k8s-m-31 ~]# kubectl create -f ./03_demo/mongodb-statefulset.yaml

statefulset.apps/mongod created

3. vCenter の vSphere Client での確認。

vSphere Client では、クラスタを選択して、

監視 → クラウド ネイティブ ストレージ → コンテナ ボリューム を開くと、Kubernetes のボリュームが確認できます。

アプリケーションのデプロイをまち、

Kubernetes 側で PersistentVolume（PV） ／ PersistentVolumeClaim（PVC） が作成されたことを確認します。

※表示例は横に長いので、スクリーンショットにしてあります。

[root@k8s-m-31 ~]# kubectl get pv

[root@k8s-m-31 ~]# kubectl get pvc

vSphere Client でも、PV が表示されるようになります。

PV の先頭のアイコンをクリックすると、「Kubernetes オブジェクト」タブで

関連する Kubernetes オブジェクトの情報が表示できます。

「基本」タブでは、PV の配置された vSAN データストア、VMDK の仮想マシン ストレージポリシー、

PV が接続している VM など、vSphere 管理者の視点での情報が表示されます。

PV は、vSAN の仮想ディスクとして作成され、VM に接続されています。

上記のコンテナ ボリューム画面で PV のボリューム名をクリックするか、

監視 → vSAN → 仮想オブジェクト の画面をひらくと、VM に PV が接続されている様子がわかります。

実は以前から Kubernetes にボリュームを提供する機能（Project Hatchway と呼ばれていた）はあったのですが、

vSphere 6.7 u3 からは、今回の例のように vSphere Clinet から「クラウド ボリューム」として

Kubernetes でボリュームとして利用している VMDK が見やすくなりました。

以上、vSphere / vSAN 6.7 U3 の Cloud Native Storage でした。

NSX-T 2.4 から、NSX-T の Web UI が大きく変更されました。

特に大きな変更点として、従来の NSX-T の操作／設定は「ネットワークとセキュリティの詳細設定」画面に移動され、

あらたに「ネットワーク」「セキュリティ」といったシンプルな画面が追加されています。

（Simplified UI と呼ばれたりするようです。）

そこで、あらたな UI に慣れるべく NSX-T 2.5 のラボ環境を「ネットワーク」画面から作成してみます。

NSX-T 2.5 の Web UI の様子。

NSX-T の Simplified UI での「ネットワーク」「セキュリティ」の部分です。

新しい「ネットワーク」画面です。

以前とはオブジェクトの名前が変更（例えば「Tier-0 ルータ」が「Tier-0 ゲートウェイ」に）されています。

これらは名前が変更されただけではなく、以前の方法で作成されたオブジェクトとは

別種類のものとして扱われます。

新しい「セキュリティ」画面です。

従来どおりの操作も「ネットワークとセキュリティの詳細設定」画面から可能です。

たとえば「ネットワーク」画面で作成されたオブジェクトは、こちらの画面にも表示されますが、

基本的には設定変更などは不可で、作成された「ネットワーク」画面側で操作することになります。

Simplified UI は、NSX-T の Policy API をベースとしたもので、

今後の NSX-T では、従来からの API ではなく Policy API がおもに使用される想定のようです。

NSX-T Data Center 2.5 の API Guide は、下記の Web サイトで確認することができます。

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

リファレンス見出しの抜粋をもとに説明すると、

おおまかに下記のようなイメージとして捉えるとよさそうです。

• 2 API Methods
  • 2.1 AAA
  • 2.2 Cloud Service Manager
  • 2.3 Management Plane API ★従来の NSX-T UI のベースとなる API（今の「～詳細設定」）
  • 2.4 Nsx-Intelligence
  • 2.5 Policy ★新たな Simplified UI のベースとなる API
  • 2.6 Upgrade

今回のラボ環境構築の流れ。

今回作成する NSX-T の環境は、以前に紹介した  NSX-T 2.4 環境と同様のものです。

環境のイメージについては、下記の投稿にあります。

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

Simplified UI の「ネットワーク」画面から操作するのは、

Tier-0 ルータ / Tier-1 ルータ / 論理スイッチといったコンポーネントです。

その前提となる トランスポート ノード や Edge クラスタのセットアップについては、ここでは省略します。

以前に投稿した内容ですと、下記（Host / Edge トランスポート ノードのセットアップ）までは実施ずみとしています。

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

以前の「VLAN 論理スイッチ」にあたる「VLAN セグメント」と、

「Tier-0 論理ルータ」にあたる「Tier-0 ゲートウェイ」の作成から始めます。

以前の投稿では下記にあたります。

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

それでは、

つづく・・・

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

まず、従来の「VLAN 論理スイッチ」にあたる「VLAN セグメント」を作成します。

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

VLAN セグメントの作成。

さっそくですが、VLAN のセグメントを作成します。

NSX-T の Manager にログインして、「ネットワーク」画面を開きます。

画面左にある「セグメント」→「セグメント」タブにある、「セグメントの追加」をクリックします。

セグメントの設定入力画面が表示されるので、下記を入力して「保存」します。

• セグメント名： seg-vlan-0200。
• トランスポート ゾーン： tz-vlan-01。これは Edge ノードを接続ずみの VLAN トランスポート ゾーンです。
• VLAN： 200。今回は NSX-Tと外部との境界になるネットワークに VLAN ID 200 を使用しています。

セグメントを作成すると、設定を続行するか確認があります。

「はい」を選択すると、作成したオブジェクトでそのまま（ひとつ前の画面で）設定作業を続けられます。

今回は「いいえ」で閉じます。

セグメントが作成されました。

「状態」が稼働中（緑色）になっていない場合は、少し待ってから隣の更新ボタンをクリックすると、

稼働中の状態になるはずです。

VLAN セグメント／VLAN 論理スイッチ は異なるのか？

セグメントを作成した後に、

「ネットワークとセキュリティの詳細設定」→「スイッチング」を開いて、

論理スイッチ（従来のセグメントにあたるもの）を確認してみます。

※この確認は、セグメント／論理スイッチの比較のためなので、通常のセグメント作成では不要です。

今回は、この画面で「ls-vlan-0200」という従来どおりの論理スイッチを作成してあります。

「セグメント」には、従来の論理スイッチとはことなり先頭に丸いマークが表示されています。

この「ネットワークとセキュリティの詳細設定」で論理スイッチとセグメントそれぞれの

設定変更の画面を開くと、おたがいに違うオブジェクトとして扱われていることがわかりやすいと思います。

まず、「ネットワークとセキュリティの詳細設定」で

VLAN 論理スイッチの設定画面を開いてみます。

当然ながら、VLAN ID などの設定変更ができるようになっています。

一方、「ネットワークとセキュリティの詳細設定」で

VLAN セグメントの設定画面を開いてみると、ほぼ設定変更ができなくなっています。

Simplified UI ／ Policy API による NSX-T 環境には、これまでの NSX-T とは明確に差異があるので、

Policy API ならではの定義方法を意識する必要がありそうです。

つづく。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-0 ルータ」にあたる「Tier-0 ゲートウェイ」を作成します。

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.2

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

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

この先の手順で指定するアップリンクの VLAN セグメント「set-vlan-0200」は、前回の投稿で作成したものです。

NSX-T の Manager の「ネットワーク」→ 「Tier-0 ゲートウェイ」画面を開き、

「Tier-0 ゲートウェイの追加」をクリックします。

下記のパラメータを設定して「保存」します。

• Tier-0 ゲートウェイの名前
• HA モード： アクティブ／スタンバイ
• Edge クラスタ： 作成ずみの Edge クラスタを選択します。

Tier-0 には作成後に設定変更するパラメータがあるため、

「Tier-0 ゲートウェイの設定を続行しますか？」では「はい」を選択します。

Tier-0 ルータ作成時に表示されていた入力画面が表示されます。

アップリンクとなるポートを作成するため、

「インターフェース」→「設定」をクリックします。

「インターフェイスの設定」画面が表示されるので、「インターフェイスの追加」をクリックします。

次のパラメータを入力してから「保存」をクリックします。

• 名前： インターフェースの名前を入力します。
• タイプ： 「外部」を選択したままにします。
• IP アドレス/マスク： NSX 外部の VLAN と、NSX-T の VLAN セグメントにあわせた IP アドレスを指定します。
• 接続先（セグメント）： 作成ずみの VLAN セグメント「seg-vlan-0200」を選択しています。
• Edge ノード： 作成ずみの Edge ノードを選択します。

インターフェースが作成されたことを確認して「閉じる」をクリックします。

「状態」が「不明」になっている場合は、更新ボタンをクリックすると「稼働中」になるはずです。

「インターフェイス」に「1」（インターフェースの数）が表示されるようになります。

そのまま画面を下にスクロールして「編集を終了」をクリックします。

「ネットワークとセキュリティの詳細設定」での Tier-0 ゲートウェイ。

作成した Tier-0 ゲートウェイは、「ネットワークとセキュリティの詳細設定」画面では

「Tier-0 ルータ」と同様に表示されます。

「ネットワークとセキュリティの詳細設定」配下の対応する画面には、

「ネットワーク」画面で表示されるオブジェクトの「詳細設定」からでも表示できます。

前回作成した「セグメント」と同様に、Simplified UI で作成した Tier-0 / Tier-1 ゲートウェイの場合も、

先頭に丸いマークが表示されています。

つづく ...

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、従来の「Tier-1 ルータ」にあたる「Tier-1 ゲートウェイ」を作成して、

あわせて従来の「オーバーレイ 論理スイッチ」のかわりになるセグメントを作成／接続します。

前回はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.3

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

さっそくですが、Tier-1 ゲートウェイを作成します。

この先の手順で指定する Tier-0 ゲートウェイ「t0-gw-01」は、前回の投稿で作成したものです。

NSX-T の Manager で、「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

「Tier-1 ゲートウェイの追加」をクリックします。

今回は、最小限のパラメータだけ設定変更しています。

まだ「保存」はせず、このままルート アドバタイズの設定します。

• Tier-1 ゲートウェイの名前
• リンクされた Tier-0 ゲートウェイ： 前回作成した Tier-0 ゲートウェイを選択します。
• Edge クラスタ：  作成ずみの Edge クラスタを選択します。

「ルート アドバタイズ」を開き、「接続されているすべてのセグメントおよびサービス ポート」を

On （緑）にして、「保存」をクリックします。

その後の確認画面は「いいえ」で、Tier-1 ゲートウェイの設定画面はいったん閉じます。

オーバーレイ セグメントの作成。

オーバーレイ セグメントを、Tier-1 ゲートウェイに接続した状態で作成します。

これは VLAN のセグメントの作成と同様に、

NSX-T の Manager で、「ネットワーク」→「セグメント」を開き、「セグメントの追加」をクリックします。

表示されたセグメントの設定入力の画面で、次のパラメータを入力します。

• セグメント名
• 接続されたゲートウェイとタイプ： これは直前に作成した Tier-1 ゲートウェイを選択します。

そうすると、「サブネット」にある「サブネットの設定」リンクがアクティブになるので、クリックします。

「サブネットの追加」をクリックし、ここでは「ゲートウェイ」の IP アドレスだけ入力して、「追加」をクリックします。

ゲートウェイのアドレスが追加されたことを確認して、「適用」をクリックします。

セグメントの設定入力画面に戻ると、サブネットが「1」表示されます。

トランスポートゾーンで、作成ずみのオーバーレイ トランスポート ゾーンを選択して「保存」します。

設定続行の確認画面は「いいえ」で閉じます。

これで、オーバーレイ セグメント 1つ接続してある Tier-1 ゲートウェイが作成されました。

作成されたオーバーレイ セグメントで「詳細設定」をクリックすると・・・

オーバーレイセグメントも、VLAN セグメントと同様に、

「ネットワークとセキュリティの詳細設定」画面でのそのオブジェクトを表示することができます。

オーバーレイ セグメントの VM への接続。

作成したオーバレイ セグメントは、従来の NSX-T のオーバーレイ論理スイッチと同様に、

VM の vNIC にポートグループとして割り当てることができます。

vSphere Client では、VM の「設定の編集」画面にも、セグメントが表示されます。

※この VM は、NSX-T のホスト トランスポート ノードとしてセットアップずみの ESXi に配置されています。

セグメントを割り当てた vNIC です。

VM を起動して、ゲスト OS 内でセグメントにあわせた IP アドレスを設定すれば、

さきほどセグメントの「サブネット」で設定したゲートウェイにアドレスに通信可能となるはずです。

（たとえば ping などで）

続く。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ルータにスタティック ルートを追加します。

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.4

今回の NSX-T ラボのネットワーク セグメント構成。

今回の NSX-T ラボは、下図のようなネットワークを構成しています。

• NSX-T で Tier-0 / Tier-1 ゲートウェイを利用した最小限のネットワークを構成しようと思い、
  あえて Tier-0 ゲートウェイでルーティングプロトコル（BGP）は設定せず、スタティックルートを設定します。
  一方、その観点では図中の「外部ルータ」は不要なのですが、既存の自宅ラボのネットワーク環境で
  Tier-0 ゲートウェイのアップリンクに VLAN ID を設定したかったため、やむなく配置しています。
• 「外部ルータ」というのは、NSX Edge ではない（NSX-T の機能によるものではない）ルータです。
  この投稿では割愛していますが、このルータにも 172.16.0.0/16 宛を 192.168.200.2 にむけるスタティック ルートを設定しています。
• Tier-0 ゲートウェイには、デフォルトルートを外部ルータに向けるスタティックルートを設定します。
  （この設定が、この投稿の主役です）
• Tier-0 / Tier-1 ゲートウェイ間は、Tier-1 ゲートウェイのルート アドバタイズが設定されています。
  （Tier-1 ゲートウェイ作成のときに設定ずみのものです）
• 図では省略していますが、「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、
  vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定しています。

上記のようなルーティング設定をして、図中の「クライアント マシン」と「vm01」が通信できるようにします。

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

NSX-T の Manager で、「ネットワーク」→「Tier-0 ゲートウェイ」を開きます。

この時点では、まだ Tier-0 ゲートウェイのスタティック ルートはゼロ件です。

Tier-0 ゲートウェイの「編集」をクリックします。

「ルーティング」→「スタティック ルート」のとなりの「編集」リンクをクリックします。

「スタティック ロートの追加」をクリックして、名前とネットワークを入力します。

ネットワークには、デフォルト ルートとして 0.0.0.0/0 を入力します。

そして、「ネクスト ホップの設定」リンクをクリックします。

「ネクスト ホップの追加」をクリックして、

IP アドレスとインターフェイスを入力し、「追加」をクリックします。

インターフェイスの「t0-uplink-01｣は、Tier-0 ゲートウェイ作成時に、あわせて作成したものです。

ネクストホップが追加されたことを確認して、「適用」をクリックします。

ネクスト ホップが 1 件となったことを確認して「閉じる」をクリックします。

スタティック ルートが 1件 になったことを確認して、「編集を終了」をクリックします。

これで、Tier-0 ゲートウェイにスタティック ルートが設定されました。

「クライアントマシン」には 172.16.0.0/16 宛を外部ルータに向けるスタティック ルート、

vm01 にはデフォルトゲートウェイとして 172.16.1.1 を設定すれば、相互に通信できるようになるはずです。

まだつづく。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-0 ルータに SNAT ルールを追加します。

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.5

今回の NSX-T ラボでの SNAT。

ラボ環境からラボの外部（別環境のネットワークやインターネットなど）に出る場合、

ラボ環境内のネットワークアドレスがプライベートなためルーティングできず、

対策としてラボの出口になるルータで SNAT を利用することがあります。

この場合、ラボの出口になるルータは（ラボ内のプライベートではない）外部ネットワークのアドレスを付与されていています。

そしてラボ内からの通信について、SNAT ルールによって通信元アドレスをプライベートアドレスからラボの出口になるルータのアドレスに変換します。

今回は、NSX-T のオーバーレイ セグメントに接続された VM が NSX-T より外部のネットワークにアクセスした際の「戻り」のために、

Tier-0 ゲートウェイで SNAT ルールを設定します。

これにより、NSX-T より外部のネットワークにアクセスした

ちなみに、図中の「外部ルータ」は、本来は不要ですが、自宅ラボ環境と今回の SNAT とは関係ない検証の都合により配置されています。

図では省略されていますが「外部ルータ」のデフォルト ゲートウェイは「ルータ（インターネットへ）」に向けてあります。

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

それでは、Tier-0 ゲートウェイに SNAT ルールを追加します。

NSX-T の Manager で、「ネットワーク」→「NAT」を開き、

Tier-0 ゲートウェイ（ここでは t0-gw-01）を選択して「NAT ルールの追加」をクリックします。

つぎのパラメータを入力して「保存」をクリックします。

• 名前： SNAT ルールにつける名前を入力する。
• アクション： SNAT を選択。
• 送信元 IP： SNAT の対象とするアドレスを入力する。
  今回は オーバーレイ セグメントで利用するつもりのネットワークアドレス（172.16.0.0/16）を入力。
• 変換された IP： Tier-0 ゲートウェイの アップリンクにあたる インターフェースの IP アドレスを入力。

これで SNAT ルールが作成されました。

状態が「不明」の場合は、となりの更新マークをクリックすると「稼働中」になるはずです。

これで、オーバーレイ セグメントに接続された VM（vm01）のゲスト OS でネットワーク設定されていれば

SNAT ルールが機能して NSX-T 外部の（Tier-0 ゲートウェイより外部の）ネットワークに出て、戻ってこれるようになるはずです。

まだ続く。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、オーバーレイ セグメントで DHCP サーバを利用できるようにします。

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.6

今回の DHCP サービスの構成。

NSX-T の従来の「ネットワークとセキュリティの詳細設定」画面から

オーバーレイ ネットワークに DHCP サーバを用意する場合、

論理スイッチ（セグメント）ごとに DHCP サーバを作成していました。

一方、Policy API では、 DHCP サーバを Tier-1 ゲートウェイごとに作成して、

各オーバーレイ セグメントでは DHCP リレーで利用します。

DHCP サーバの追加。

まず、DHCP サーバを追加（作成）します。

NSX-T の Manager で「ネットワーク」→「DHCP」を開き、「サーバを追加」をクリックします。

DHCP サーバのパラメータを入力して「保存」をクリックします。

• サーバ タイプ： 「DHCP サーバ」を選択。
• サーバ名： DHCP サーバに設定する名前を入力する。
• サーバの IP アドレス： 「IP アドレス/サブネットマスクの長さ」を入力する。
  これは NSX-T のオーバーレイ ネットワークなどで使用中のネットワーク アドレスと重ならないようにする。
• Edge クラスタ： 作成ずみの Edge クラスタを選択する。

DHCP サーバが作成されました。

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

作成した DHCP サーバを、オーバーレイ セグメントを接続している Tier-1 ゲートウェイに接続します。

「ネットワーク」→「Tier-1 ゲートウェイ」で、以前に作成した Tier-1 ゲートウェイ「t1-gw-01」を表示すると、

まだ「IP アドレス管理」が「未設定」になっています。

Tier-1 ゲートウェイの「編集」をクリックします。

「IP アドレス管理」の隣にある「IP を割り当てない設定」リンクをクリックします。

「IP アドレス管理の設定」画面で、パラメータを入力して「保存」をクリックします。

• タイプ： 「DHCP ローカル サーバ」を選択。
• DHCP サーバ： 直前に作成した「dhcp-sv-01」を選択。

「IP アドレス管理」が「ローカル | サーバ」になったことを確認して、「保存」をクリックします。

Tier-1 ゲートウェイの設定画面は「編集の終了」をクリックして閉じます。

オーバーレイ セグメントでの DHCP 範囲の設定。

オーバーレイ セグメントで DHCP リレーを構成する必要がありますが、

これは「DHCP リレー」のような設定画面はありません。

かわりに、セグメントの「サブネット」で、「DHCP 範囲」を設定します。

「ネットワーク」→「セグメント」→「セグメント」タブを開くと、

以前に作成したオーバーレイ セグメント「seg-overlay-01」があるので、

このセグメントで DHCP を利用できるようにします。

セグメントの「編集」をクリックします。

セグメントが編集可能な状態になるので、サブネット（の数）のリンクをクリックします。

「サブネットの設定」画面が開くので、「編集」をクリックします。

空欄になっていた「DHCP 範囲」に、IP アドレスの範囲を入力して、「追加」をクリックします。

これは入力済みの「ゲートウェイ」と合わせる必要があります。

例では、ゲートウェイが 17.16.1.1/24 と入力ずみなので、

そのネットワーク アドレス内でゲートウェイアドレスと重複しないように

「172.16.1.10-172.16.1.250」と入力しています。

DHCP 範囲が表示されたことを確認して、「適用」をクリックします。

ちなみに、セグメントに「DHCP 範囲」を設定すると UI から削除することはできず、

DHCP 使用をやめる場合には、セグメントをいったん削除することになります。

「保存」をクリックします。

「編集を終了」をクリックして、画面を閉じます。

ゲスト OS でのネットワーク アドレス取得。

オーバーレイ セグメント「seg-overlay-01」を割り当てている仮想マシンでは、

ゲスト OS のネットワーク設定で DHCP を利用するようにしてあります。

ゲスト OS でネットワークを再起動すると、

「DHCP 範囲」で設定した範囲から、IP アドレス（172.16.1.10/24）が設定されます。

そして、デフォルト ゲートウェイには、オーバーレイ セグメントで指定した

ゲートウェイ アドレス（172.16.1.1）が設定されます。

ちなみに、例として使用しているゲスト OS は、VMware Photon OS 3.0 なので、

「systemctl restart systemd-networkd」コマンドでネットワークを再起動しています。

つづく。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、Tier-1 ゲートウェイ配下のオーバーレイ セグメントで DNS フォワーダを利用できるようにします。

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.7

今回の DNS フォワーダの構成。

NSX-T による DNS フォワーダを追加して、Tier-1 ゲートウェイに接続します。

DNS フォワーダから転送先 DNS サーバに到達できるようにしておく必要があるので、

Tier-1 ゲートウェイではルート アドバタイズ設定を追加します。

また、Tier-1 ゲートウェイでは、NSX-T による DHCP サービスを利用可能にしてあります。（前回の投稿にて）

デフォルト ゾーンの追加。

NSX-T の Manager で「ネットワーク」→「DNS」→「DNS ゾーン」を開き、

「DNS ゾーンの追加」→「デフォルト ゾーンの追加」をクリックします。

DNS ゾーンのパラメータを入力して「保存」をクリックします。

• ゾーン名： いわゆる DNS のゾーンの名前ではなく、この設定に付与するオブジェクト名を入力。
• DNS サーバ： クエリを転送する DNS サーバをカンマ区切りで入力。
  実際に DNS フォワーダから到達できる必要あり。
• 転送元 IP： DNS サーバに接続する際の元 IP。
  今回はルート アドバタイズと SNAT だけで到達できる環境なので空欄のまま。

DNS ゾーンが追加されました。

DNS サービスの追加。

DNS サービス（フォワーダ）を追加します。

となりのタブの「DNS サービス」を開き、「DNS サービスの追加」をクリックします。

そしてパラメータを入力して「保存」をクリックします。

• 名前
• Tier-0/Tier-1 ゲートウェイ： 以前に作成した Tier-1 ゲートウェイを選択。
• DNS サービス IP： この DNS フォワーダに設定する IP アドレスを入力する。
  このアドレスは、NSX-T の他のセグメントで使用していない範囲にする必要がある。
• デフォルト DNS ゾーン： 先ほど作成した「DNS ゾーン」を選択する。

DNS サービスが追加されました。

「状態」は、更新マークをクリックすると緑の「稼働中」になるはずです。

この画面で、フォワード先の DNS サーバのアドレスを表示することもできます。

Tier-1 ゲートウェイ。

DNS サービスを接続した Tier-1 ゲートウェイ（今回は t1-gw-01）では、

ルート アドバタイズを追加する必要があります。

「ネットワーク」→「Tier-1 ゲートウェイ」を開き、

対象の Tier-1 ゲートウェイで「編集」をクリックします。

「ルート アドバタイズ」を開き、

「DNS フォワーダのすべてのルート」を ON（緑）にして、「保存」をクリックします。

「編集を終了」をクリックして閉じます。

これで、DNS フォワーダが利用可能になるはずです。

ゲスト OS での確認。

Tier-1 ゲートウェイ配下のセグメントに接続している VM では、

ゲスト OS 内でネットワークを再起動（DHCP でのネットワーク再設定）をすると、

参照先の DNS サーバとして、DNS フォワーダのアドレスが設定されたことがわかります。

ちなみに、ゲスト OS は VMware Photon OS 3.0 なので、DNS サーバのアドレスは

「resolvectl dns」コマンドで確認しています。

もう少し続くつもり。

NSX-T 2.5 の Simplified UI で、NSX-T のラボ環境を作成します。

今回は、ここまでに作成した DHCP サービスを利用するオーバーレイ セグメントを追加作成します。

あわせて、前回までの投稿で追加した DHCP サーバの構成をもう少し掘り下げて確認してみます。

前回の投稿はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.8

今回の環境について。

前回までの投稿で作成した NSX-T ラボ環境に、オーバーレイセグメントを追加して、

Tier-1 ゲートウェイを介してオーバーレイ セグメント同士で通信できる環境を用意します。

すでに作成ずみのオーバーレイ セグメント「seg-overlay-01」は、説明順序の都合から

オーバーレイ セグメントに後から DHCP サーバ範囲を指定しており、手順が前後していました。

今回は、セグメント作成の時点で、あわせて DHCP 範囲を指定します。

オーバーレイ セグメントの作成。（2回目）

それでは、セグメントを作成します。

NSX-T の Manager で、「ネットワーク」→「セグメント」→「セグメント」タブを開いて、

「セグメントの追加」をクリックします。

次のパラメータを入力します。

• セグメント名： セグメントに付与する名前を入力する。
• 接続されたゲートウェイとタイプ： 接続する Tier-1 ゲートウェイを選択する。

そして、「サブネットの設定」リンクをクリックします。

「サブネットの設定」画面で「サブネットの追加」をクリックして、次のパラメータを入力して「追加」をクリックします。

最初に作成したセグメント「seg-overlay-01」とはことなり、この追加作成時点で「DHCP範囲」も指定します。

• ゲートウェイ： サブネットのゲートウェイ IP アドレスを入力する。
• DHCP 範囲： ゲートウェイのアドレスと同じネットワークアドレスで、
  かつゲートウェイアドレスとは重複しないレンジで IP アドレスの範囲を入力する。

パラメータが入力されたことを確認して、「適用」をクリックします。

サブネットが作成され、サブネットの数「1」が表示されています。

トランスポート ゾーンで、作成ずみのオーバーレイ トランスポート ゾーン「tz-overlay-01」を選択して、

「保存」をクリックします。

設定の続行を確認する画面は「いいえ」で閉じます。

これで、Tier-1 ゲートウェイに 2つめのオーバーレイ セグメントが作成されました。

Tier-1 ゲートウェイには DHCP サーバが接続ずみであり、オーバーレイ セグメントで DHCP 範囲が指定されているので、

このセグメントに接続された VM では DHCP サービスが利用可能になっているはずです。

VM へのオーバーレイ セグメントの接続と確認。

作成したオーバーレイセグメント「seg-overlay-02」を VM に接続します。

以前の投稿でも紹介しましたが、NSX-T のセグメントは vSphere Client ではポートグループとして扱えるので、

VM の「設定の編集」で、仮想ネットワーク アダプタに割り当てることができます。

vm03 という VM に、seg-overlay-02 を割り当てました。

ゲスト OS でネットワークを再起動すると、DHCP サーバから IP アドレス（172.16.2.10/24）と、

DNS サーバのアドレス（172.16.253.254）が設定されたことがわかります。

※ゲスト OS には、VMware Photon OS 3.0 を利用しました。

※この DHCP サーバ／DNS サービス の設定は、以前の投稿で設定ずみのものです。

そして、1つ目のセグメント（172.16.1.10）とも疎通確認できます。

これで、最低限の NSX-T ラボ環境が Simplified UI で作成できたかなと思います。

NSX-T Polic API による DHCP サーバの補足。

NSX-T の Policy API 操作による DHCP サービスの構成は、基本的に DHCP リレー構成となるようです。

DHCP を利用するセグメントを2つ作成した状態で、「ネットワークとセキュリティの詳細設定」画面側から確認してみます。

「DHCP」→「サーバ」に、以前の投稿で作成した DHCP サーバ（172.16.254.254）が表示されます。

オーバーレイ セグメントで指定した DHCP 範囲も、「IP プール」に表示されています。

「リレー プロファイル」を開くと、

DHCP サーバ（172.16.254.254）のプロファイルが構成されます。

そして、Tier-1 ゲートウェイの、オーバーレイセグメントを接続しているポートには、

それぞれリレーサービスが構成されていることがわかります。

以上、NSX-T 2.5 ラボ環境を、あえて Simplified UI だけで構築してみる話でした。

ここまでの投稿では、NSX-T 2.5 の Simplified UI で NSX-T のラボ環境を作成してきました。

今回は、ここまで作成したオブジェクトを削除して、元の状態に戻してみます。

一連の投稿（ここで削除していく環境の構築）はこちら。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

ちなみに、Simplified UI （の「ネットワーク」）で作成したオブジェクトのみ削除対象として、

その前提として作成ずみだった Edge や トランスポート ゾーンなどのオブジェクトは、ここでは削除しません。

削除手順もすべて「ネットワーク」画面を利用します。

1. オーバーレイ セグメントの削除。

まず、オーバーレイ セグメントを削除します。

あらかじめ、仮想マシンの vNIC は、標準／分散ポートグループの割り当てに変更しておきます。

「ネットワーク」→「セグメント」→「セグメント」を開くと、

この環境に 2つのオーバーレイ セグメントと、1つの VLAN セグメントが作成されていることがわかります。

ここではオーバーレイ セグメントのみ削除して、VLAN セグメントは最後に削除します。

※この環境では、Tier-1 ゲートウェイに接続されていることでもオーバーレイ セグメントが見分けられます。

まず、1つめのオーバーレイ セグメントを削除します。

セグメントに限らず、オブジェクトの削除では次のような確認画面が表示されます。

「削除」をクリックすると実際に削除されます。

※以降のオブジェクト削除では割愛しますが、同様にこのような確認画面があります。

オブジェクトの削除に成功すると、緑のメッセージが表示されます。

削除直後のオブジェクトはグレーアウト表示になることがありますが、

その場合は少し待って「更新」ボタン（画面の下のほう）をクリックすると消えます。

ちなみに、削除に失敗した場合は、次のような赤いメッセージが表示されます。

（ただし、この例はセグメントではなくDHCP サーバです）

削除対象のオブジェクトが参照されている（別のオブジェクトに接続されている）ような場合は、

先に参照しているオブジェクトを削除しておく必要があります。

同様に 2つめのオーバーレイ セグメントも削除して、VLAN セグメントだけが残った状態です。

2. DNS フォワーダ サービスの削除。

DNS サービス（フォワーダ）を削除してから、DNS ゾーンのオブジェクトを削除します。

「ネットワーク」→「DNS」→「DNS サービス」を開いて、

DNS サービスを削除します。

そして、DNS ゾーンを削除します。

3. Tier-1 ゲートウェイの削除。

環境構築では、DHCP サーバと DNS サービスを続けて作成しました。

DHCP サービスは Tier-1 ゲートウェイから参照されるオブジェクトのため、先に Tier-1 ゲートウェイを削除します。

「ネットワーク」→「Tier-1 ゲートウェイ」で削除します。

4. DHCP サーバの削除。

Tier-1 ゲートウェイを削除したことで、DHCP サーバが削除できるようになります。

「ネットワーク」→「DHCP」で削除します。

5. NAT ルールの削除。

Tier-0 ゲートウェイに作成した SNAT ルールは、Tier-0 ゲートウェイより前に削除します。

「ネットワーク」→「NAT」で Tier-0 ゲートウェイを選択すると表示される、SNAT ルールを削除します。

6. Tier-0 ゲートウェイの削除。

Tier-1 ゲートウェイが削除できたので、そこに接続されていた Tier-0 ゲートウェイを削除します。

Tier-0 ゲートウェイにはスタティック ルートを設定していますが、

Web UI での削除では、同時に自動削除されます。

7. VLAN セグメントの削除。

NSX-T 環境への境界になる Tier-0 ゲートウェイを削除したので、最後に VLAN セグメントを削除します。

「ネットワーク」→「セグメント」→「セグメント」で削除します。

オブジェクトの削除では、NSX-T の Simplified UI でも従来 UI と同様に、

オブジェクト同士の参照関係を考慮して削除する必要があります。

デモやトレーニングなどで何度か環境構築を繰り返す場合は、

REST API などを利用したオブジェクト削除スクリプトなど作成しておくと便利です。

また、ネステッド ESXi 環境の NSX-T であれば、

NSX-T でオブジェクトをひとつずつ削除するよりも、VM スナップショットなどを利用した

環境リセットのほうが現実的かなと思います。

※この場合、vCenter / NSX-T Manager / ESXi VM といった一連の VM で、同時点のスナップショットを取得しておきます。

以上、NSX-T 環境を破壊してみる話でした。

以前に、NSX-T の新しい UI でのラボ環境構築を紹介しました。

この UI は、新しい Policy API にもとづくもので、Simplified UI や Policy UI と呼ばれています。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

ここまでに Simplified UI で作成した NSX-T 環境のオブジェクト情報を、Policy API で取得してみます。

ラボのイメージは下記です。

※Policy API の操作対象外となる Edge クラスタやトランスポート ゾーンなどは省略しています。

※NSX Manager も図からは省略しています。

API へのアクセスには、Linux の curl コマンドを利用します。

$ cat /etc/oracle-release

Oracle Linux Server release 7.7

API エンドポイントは NSX Manager です。

そして情報取得だけなので、ひたすら GET メソッドを利用します。

なお、curl のコマンドラインが長くなるので、一部の情報を変数に格納して利用しています。

• MGR： NSX Manager のアドレス
• CRED： NSX Manager のユーザ:パスワード

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

$ CRED='admin:VMware1!VMware1!'

セグメント。

セグメントは、VLAN／オーバレイのどちらも、次の URL で取得できます。

GET /policy/api/v1/infra/segments

curl コマンドでは、次のように実行します。

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

• -k： SSL 証明書エラーの無視。（ラボ環境なので）
• -s： サイレント モード。進捗表示などを抑止。
• -u： ログイン 情報を指定。
• -X： メソッド指定。今回は GET のみ。（じつは省略可）

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/segments

実際にセグメントの情報を取得すると、次のようになります。

セグメントは 3つ（seg-vlan-0200、seg-overlay-01、seg-overlay-02）作成されています。

従来の NSX の API とは異なり、Simplified UI によるオブジェクト作成では、ID と表示名（display_name）が揃えられています。

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/segments

{

  "results" : [ {

    "type" : "ROUTED",

    "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",

    "advanced_config" : {

      "address_pool_paths" : [ ],

      "hybrid" : false,

      "local_egress" : false,

      "connectivity" : "ON"

    },

    "resource_type" : "Segment",

    "id" : "seg-overlay-01",

    "display_name" : "seg-overlay-01",

    "path" : "/infra/segments/seg-overlay-01",

    "relative_path" : "seg-overlay-01",

    "parent_path" : "/infra/segments/seg-overlay-01",

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572769486202,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572770491070,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 1

  }, {

    "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",

    "advanced_config" : {

      "address_pool_paths" : [ ],

      "hybrid" : false,

      "local_egress" : false,

      "connectivity" : "ON"

    },

    "resource_type" : "Segment",

    "id" : "seg-overlay-02",

    "display_name" : "seg-overlay-02",

    "path" : "/infra/segments/seg-overlay-02",

    "relative_path" : "seg-overlay-02",

    "parent_path" : "/infra/segments/seg-overlay-02",

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572771593680,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572771593680,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  }, {

    "type" : "DISCONNECTED",

    "vlan_ids" : [ "200" ],

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

    "advanced_config" : {

      "address_pool_paths" : [ ],

      "hybrid" : false,

      "local_egress" : false,

      "connectivity" : "ON"

    },

    "resource_type" : "Segment",

    "id" : "seg-vlan-0200",

    "display_name" : "seg-vlan-0200",

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

    "relative_path" : "seg-vlan-0200",

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

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572768517065,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572768517065,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 3,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

個別でセグメント情報を取得するには、URL にセグメントの ID を指定します。

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/segments/seg-overlay-01

{

  "type" : "ROUTED",

  "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",

  "advanced_config" : {

    "address_pool_paths" : [ ],

    "hybrid" : false,

    "local_egress" : false,

    "connectivity" : "ON"

  },

  "resource_type" : "Segment",

  "id" : "seg-overlay-01",

  "display_name" : "seg-overlay-01",

  "path" : "/infra/segments/seg-overlay-01",

  "relative_path" : "seg-overlay-01",

  "parent_path" : "/infra/segments/seg-overlay-01",

  "marked_for_delete" : false,

  "_create_user" : "admin",

  "_create_time" : 1572769486202,

  "_last_modified_user" : "admin",

  "_last_modified_time" : 1572770491070,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 1

}

オーバーレイ セグメント「seg-overlay-01」は、VM の vNIC にポートグループとして割り当ててあります。

そのため、論理ポートも作成されています。

display_name から、接続先 VM が予想できます。

GET /policy/api/v1/infra/segments/セグメント ID/ports

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/segments/seg-overlay-01/ports

{

  "results" : [ {

    "resource_type" : "SegmentPort",

    "id" : "default:4a73adc5-53f4-4e56-9b32-5839d9ae153f",

    "display_name" : "vm01/vm01.vmx@3c436657-571b-4bb3-b617-2dcfdcf2ba59",

    "tags" : [ ],

    "path" : "/infra/segments/seg-overlay-01/ports/default:4a73adc5-53f4-4e56-9b32-5839d9ae153f",

    "relative_path" : "default:4a73adc5-53f4-4e56-9b32-5839d9ae153f",

    "parent_path" : "/infra/segments/seg-overlay-01",

    "marked_for_delete" : false,

    "_create_user" : "system",

    "_create_time" : 1572779101569,

    "_last_modified_user" : "system",

    "_last_modified_time" : 1572779101569,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  }, {

    "resource_type" : "SegmentPort",

    "id" : "default:3a2f6c53-0518-4a70-97db-e0b7af6afa75",

    "display_name" : "vm02/vm02.vmx@92e5beee-20a2-4ba7-8372-ce49aace34fc",

    "tags" : [ ],

    "path" : "/infra/segments/seg-overlay-01/ports/default:3a2f6c53-0518-4a70-97db-e0b7af6afa75",

    "relative_path" : "default:3a2f6c53-0518-4a70-97db-e0b7af6afa75",

    "parent_path" : "/infra/segments/seg-overlay-01",

    "marked_for_delete" : false,

    "_create_user" : "system",

    "_create_time" : 1572779101405,

    "_last_modified_user" : "system",

    "_last_modified_time" : 1572779101405,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 2,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

Tier-0 ゲートウェイ。

Tier-0 ゲートウェイの情報を取得してみます。

UI では特に指定していませんでしたが、トランジット セグメントのネットワーク アドレスなどもわかります。

GET /policy/api/v1/infra/tier-0s

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s

{

  "results" : [ {

    "transit_subnets" : [ "100.64.0.0/16" ],

    "internal_transit_subnets" : [ "169.254.0.0/28" ],

    "ha_mode" : "ACTIVE_STANDBY",

    "failover_mode" : "NON_PREEMPTIVE",

    "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

    "force_whitelisting" : false,

    "default_rule_logging" : false,

    "disable_firewall" : false,

    "resource_type" : "Tier0",

    "id" : "t0-gw-01",

    "display_name" : "t0-gw-01",

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

    "relative_path" : "t0-gw-01",

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

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572768576390,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572768576448,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 1

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

Tier-0 / Tier-1 ゲートウェイには、じつは LocaleServices というオブジェクトがあります。

UI での ゲートウェイ追加時に指定した Edge クラスタや、インターフェースは、

LocaleServices で定義されています。

まず LocaleServices の id を確認し、それをもとにインターフェース情報を取得します。

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

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services

{

  "results" : [ {

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

    "resource_type" : "LocaleServices",

    "id" : "470f1260-fe11-11e9-be6c-bdb62d557eed",

    "display_name" : "470f1260-fe11-11e9-be6c-bdb62d557eed",

    "path" : "/infra/tier-0s/t0-gw-01/locale-services/470f1260-fe11-11e9-be6c-bdb62d557eed",

    "relative_path" : "470f1260-fe11-11e9-be6c-bdb62d557eed",

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

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572768576438,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572768576438,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

確認した LocaleServices の ID をもとに、インターフェースの情報を確認してみます。

Tier-0 ゲートウェイに、VLAN セグメント「seg-vlan-0200」に接続された

インターフェース「t0-uplink-01」が作成されています。

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

$ ID=470f1260-fe11-11e9-be6c-bdb62d557eed

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services/$ID/interfaces

{

  "results" : [ {

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

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

    "type" : "EXTERNAL",

    "resource_type" : "Tier0Interface",

    "id" : "t0-uplink-01",

    "display_name" : "t0-uplink-01",

    "path" : "/infra/tier-0s/t0-gw-01/locale-services/470f1260-fe11-11e9-be6c-bdb62d557eed/interfaces/t0-uplink-01",

    "relative_path" : "t0-uplink-01",

    "parent_path" : "/infra/tier-0s/t0-gw-01/locale-services/470f1260-fe11-11e9-be6c-bdb62d557eed",

    "marked_for_delete" : false,

    "subnets" : [ {

      "ip_addresses" : [ "192.168.200.2" ],

      "prefix_len" : 24

    } ],

    "_create_user" : "admin",

    "_create_time" : 1572768811102,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572768811102,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

Tier-0 ゲートウェイに設定したスタティック ルートも確認できます。

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

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/static-routes/t0-route-01

{

  "network" : "0.0.0.0/0",

  "next_hops" : [ {

    "ip_address" : "192.168.200.1",

    "admin_distance" : 1,

    "scope" : [ "/infra/tier-0s/t0-gw-01/locale-services/470f1260-fe11-11e9-be6c-bdb62d557eed/interfaces/t0-uplink-01" ]

  } ],

  "resource_type" : "StaticRoutes",

  "id" : "t0-route-01",

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

  "path" : "/infra/tier-0s/t0-gw-01/static-routes/t0-route-01",

  "relative_path" : "t0-route-01",

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

  "marked_for_delete" : false,

  "_create_user" : "admin",

  "_create_time" : 1572769868322,

  "_last_modified_user" : "admin",

  "_last_modified_time" : 1572769868322,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

そして、Tier-0 ゲートウェイ に設定した SNAT ルールも確認できます。

手動追加した NAT ルールの種類は「USER」です。

NAT ルールは、ほかのオブジェクトと異なり、Simplified UI で作成しても

ID と display_name が別（ID が UUID）になっています。

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

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/nat/USER/nat-rules

{

  "results" : [ {

    "sequence_number" : 100,

    "action" : "SNAT",

    "source_network" : "172.16.0.0/16",

    "service" : "",

    "translated_network" : "192.168.200.2",

    "scope" : [ ],

    "enabled" : true,

    "logging" : false,

    "resource_type" : "PolicyNatRule",

    "id" : "c149a1a0-fe14-11e9-be6c-bdb62d557eed",

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

    "path" : "/infra/tier-0s/t0-gw-01/nat/USER/nat-rules/c149a1a0-fe14-11e9-be6c-bdb62d557eed",

    "relative_path" : "c149a1a0-fe14-11e9-be6c-bdb62d557eed",

    "parent_path" : "/infra/tier-0s/t0-gw-01/nat/USER",

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572770124388,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572770124388,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

Tier-1 ゲートウェイ。

Tier-1 ゲートウェイの情報を取得してみます。

（以前に NSX-T ラボ環境構築したとおり）DHCP サーバの接続や、

ルート アドバタイズの設定が表示されていることがわかります。

GET /policy/api/v1/infra/tier-1s

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-1s

{

  "results" : [ {

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

    "failover_mode" : "NON_PREEMPTIVE",

    "enable_standby_relocation" : false,

    "dhcp_config_paths" : [ "/infra/dhcp-server-configs/dhcp-sv-01" ],

    "route_advertisement_types" : [ "TIER1_IPSEC_LOCAL_ENDPOINT", "TIER1_DNS_FORWARDER_IP", "TIER1_CONNECTED" ],

    "force_whitelisting" : false,

    "default_rule_logging" : false,

    "disable_firewall" : false,

    "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

    "resource_type" : "Tier1",

    "id" : "t1-gw-01",

    "display_name" : "t1-gw-01",

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

    "relative_path" : "t1-gw-01",

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

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572769273590,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572771267403,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 7

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

Tier-1 ゲートウェイにも、Tier-0 と同様に、

Edge クラスタの割り当てなどを定義する LocaleServices が作成されています。

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

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/locale-services

{

  "results" : [ {

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

    "preferred_edge_paths" : [ ],

    "resource_type" : "LocaleServices",

    "id" : "e69e20e0-fe12-11e9-be6c-bdb62d557eed",

    "display_name" : "e69e20e0-fe12-11e9-be6c-bdb62d557eed",

    "path" : "/infra/tier-1s/t1-gw-01/locale-services/e69e20e0-fe12-11e9-be6c-bdb62d557eed",

    "relative_path" : "e69e20e0-fe12-11e9-be6c-bdb62d557eed",

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

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572769273616,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572769273616,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

DHCP サーバ。

DHCP サーバの情報を取得します。

Tier-1 ゲートウェイに接続されていた DHCP サーバの情報は、ここで取得できます。

GET /policy/api/v1/infra/dhcp-server-configs

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/dhcp-server-configs

{

  "results" : [ {

    "server_address" : "172.16.254.254/24",

    "lease_time" : 86400,

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

    "resource_type" : "DhcpServerConfig",

    "id" : "dhcp-sv-01",

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

    "path" : "/infra/dhcp-server-configs/dhcp-sv-01",

    "relative_path" : "dhcp-sv-01",

    "parent_path" : "/infra/dhcp-server-configs/dhcp-sv-01",

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572770383565,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572770383565,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

DNS フォワーダ。

DNS ゾーンの設定を確認してみます。

API の URL は、UI での表現よりわかりやすく「dns-forwarder-zones」となっています。

GET /policy/api/v1/infra/dns-forwarder-zones

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/dns-forwarder-zones

{

  "results" : [ {

    "dns_domain_names" : [ ],

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

    "resource_type" : "PolicyDnsForwarderZone",

    "id" : "dns-zone-01",

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

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

    "relative_path" : "dns-zone-01",

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

    "marked_for_delete" : false,

    "_create_user" : "admin",

    "_create_time" : 1572771005094,

    "_last_modified_user" : "admin",

    "_last_modified_time" : 1572771005094,

    "_system_owned" : false,

    "_protection" : "NOT_PROTECTED",

    "_revision" : 0

  } ],

  "result_count" : 1,

  "sort_by" : "display_name",

  "sort_ascending" : true

}

DNS フォワーダは、ラボ環境では Tier-1 ゲートウェイに割り当てているので

URL のパスにも Tier-1 ゲートウェイの ID が含まれます。

※Tier-1 ゲートウェイの情報取得の一部とも思いますが、わかりやすさからここで紹介しています。

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

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/dns-forwarder

{

  "listener_ip" : "172.16.253.254",

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

  "log_level" : "INFO",

  "enabled" : true,

  "resource_type" : "PolicyDnsForwarder",

  "id" : "dns-forwarder",

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

  "path" : "/infra/tier-1s/t1-gw-01/dns-forwarder",

  "relative_path" : "dns-forwarder",

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

  "marked_for_delete" : false,

  "_create_user" : "admin",

  "_create_time" : 1572771146293,

  "_last_modified_user" : "admin",

  "_last_modified_time" : 1572771146293,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

ここで取得した情報をもとに、今後の投稿で Policy API での環境構築を紹介しようと思います。

以上、Policy API での情報取得でした。

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

前回ひたすら GET で確認したオブジェクトを・・・

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

ひたすら削除して、下記の投稿の開始時点に環境を戻してみます。

自宅ラボで NSX-T 2.5 環境を構築する。Simplified UI 編。Part.1

今回も、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!'

オーバーレイ セグメントの削除。

オーバーレイ セグメント「seg-overlay-01」と「seg-overlay-01」を削除します。

セグメントの削除は、次の API です。

セグメントの表示名（display_name）ではなく、ID を指定します。

ちなみに、セグメント ID の指定は必須となっており、segments までの指定にしても全件削除はできません。

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

ここでは、VM の vNIC を接続したまま（対応する論理ポートが作成されたまま）でも削除できるように

「force=true」を指定しています。

オーバーレイ セグメント「seg-overlay-01」を削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/segments/seg-overlay-01?force=true

オーバーレイ セグメント「seg-overlay-02」を削除します。

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/segments/seg-overlay-02?force=true

成功した場合は、とくに標準出力はなく処理されます。

エラーが表示されずにうまくいかない場合は、

curl に -v  オプションを付与して実行すると問題がわかる場合があります。

DNS フォワーダの削除。

DNS フォワーダに関連するオブジェクトは、

DNS フォワーダ、DNS フォワーダ ゾーンの順に削除します。

DNS フォワーダ の削除。

DNS フォワーダは、Tier-1 ゲートウェイに接続しているので、

次の API で削除します。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/dns-forwarder

DNS フォワーダ ゾーンの削除。

DNS フォワーダ ゾーンは、特定のゲートウェイに割り当てられないので、次の API で削除できます。

DNS フォワーダ ゾーンの ID（id）は、作成時に指定した DNS フォワーダの名前（display_name）と一致します。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/dns-forwarder-zones/dns-zone-01

Tier-1 ゲートウェイの削除。

LocaleServices の削除。

Tier-1 ゲートウェイを削除する前に、ゲートウェイの Edge クラスタ割り当てなどを指定する

「LocaleServices」を削除しておく必要があります。

これ以降の URL で指定している LocaleServices などの ID は、前回の投稿での GET メソッドなどで確認できます。

UI で自動作成された LocaleServices の ID は、内部的なオブジェクトのためか UUID 形式です。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/locale-services/e69e20e0-fe12-11e9-be6c-bdb62d557eed

jq コマンドなどを利用して JSON をパースして ID を抽出し、

次のようなコマンドラインで削除することもできます。

$ T1_LOC_ID=$(curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/locale-services | jq -r .results[].id)

$ echo $T1_LOC_ID

e69e20e0-fe12-11e9-be6c-bdb62d557eed

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01/locale-services/$T1_LOC_ID

Tier-1 ゲートウェイの削除。

Tier-1 ゲートウェイを削除します。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-1s/t1-gw-01

DHCP サーバの削除。

DHCP を利用するゲートウェイ／セグメントが削除されたので、

DHCP サーバを削除します。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/dhcp-server-configs/dhcp-sv-01

Tier-0 ゲートウェイの削除。

Tier-0 ゲートウェイの削除でも、Tier-1 ゲートウェイと同様で、

先に参照するオブジェクトを削除しておく必要があります。

NAT ルールの削除。

SNAT ルールを削除します。

なぜか NAT ルールの ID は、Simplified UI で作成しても UUID 形式です。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/nat/USER/nat-rules/c149a1a0-fe14-11e9-be6c-bdb62d557eed

jq コマンドなどで工夫すれば、SNAT ルールを作成したときの表示名（今回は t0-snat-01）などから

ID を抽出することもできます。

$ NAT_ID=$(curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/nat/USER/nat-rules | jq -r '.results[] | select(.display_name == "t0-snat-01") | .id')

$ echo $NAT_ID

c149a1a0-fe14-11e9-be6c-bdb62d557eed

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/nat/USER/nat-rules/$NAT_ID

スタティックルートの削除。

Tier-0 ゲートウェイのスタティック ルートを削除します。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/static-routes/t0-route-01

インターフェースの削除。

Tier-0 ゲートウェイのインターフェースを削除します。

インターフェースは、Tier-0 ゲートウェイの LocaleServices の一部として作成されています。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services/470f1260-fe11-11e9-be6c-bdb62d557eed/interfaces/t0-uplink-01

ここまでのオブジェクトと同様、jq コマンドを利用する例です。

LocaleServices の ID は UI 作成時に特定できないので、工夫して取得する必要があります。

$ T0_LOC_ID=$(curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services | jq -r .results[].id)

$ echo $T0_LOC_ID

470f1260-fe11-11e9-be6c-bdb62d557eed

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services/$T0_LOC_ID/interfaces/t0-uplink-01

LocaleServices の削除。

Tier-0 ゲートウェイの LocaleServices を削除します。

インターフェース削除の際に取得した LocaleServices ID を指定しています。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01/locale-services/$T0_LOC_ID

Tier-0 ゲートウェイの削除。

他のオブジェクトからの参照がなくなったので、Tier-0 ゲートウェイを削除します。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/tier-0s/t0-gw-01

VLAN セグメントの削除。

最後に、NSX-T 外部ネットワークとの境界にしていた VLAN セグメントを削除します。

削除の API は、オーバーレイ セグメントと同じものです。

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

$ curl -ks -u $CRED -X DELETE https://$MGR/policy/api/v1/infra/segments/seg-vlan-0200

ひととおり Simplified UI から作成したオブジェクトを削除したので、

次は、Policy API でオブジェクトを作成してみます。

以上、NSX-T Policy API でオブジェクトを削除する話でした。

今回は、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 のオブジェクトを作成してみる話でした。

NSX-T の Policy API には、Hierarchical API とよばれる使用方法があります。

今回は、Hierarchical API で情報取得してみます。

前回の投稿（下記）で作成した環境の情報を GET してみます。

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

以前に、Path 指定での API で情報取得してみました。

この環境も、Part.3 で作成した環境とほとんど同じです。

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

Hierarchical API の特徴。

前回までの投稿では、Policy API の URL でオブジェクトの Path を指定して API コールしていました。

Policy API を Hierarchical で利用する場合は、Infra と Domain という特別なオブジェクトを基準として API をコールします。

URL は、次のようになっていました。

GET /policy/api/v1/infra/segments

一方、Hierarchical API では、エンドポイントの URL が一律で次のものになります。

（今回あつかうオブジェクトでは共通で ～/infra まで）

GET /policy/api/v1/infra

そして、GET メソッドでは、オブジェクト（リソース）の種類によって、フィルタを指定することができます。

セグメントの場合は、つぎのようにフィルタを指定します。

GET /policy/api/v1/infra?filter=Type-Segment

それでは、ひととおり情報取得してみます。

なお、前回までの投稿で紹介したように、API のコールには curl コマンドを利用します。

変数 CREDには「ユーザ名:パスワード」、MGR には NSX Manager のアドレスを格納してあります。

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

$ CRED='admin:VMware1!VMware1!'

セグメントの情報取得。

VLAN／オーバーレイ 両方のセグメントの情報が取得されます。

仮想マシンが接続されたセグメント ポートなども表示されます。

GET /policy/api/v1/infra?filter=Type-Segment

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Segment

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "SegmentSecurityProfile" : {

      "bpdu_filter_enable" : true,

      "bpdu_filter_allow" : [ ],

      "dhcp_server_block_enabled" : true,

      "dhcp_client_block_enabled" : false,

      "non_ip_traffic_block_enabled" : false,

      "dhcp_server_block_v6_enabled" : true,

      "dhcp_client_block_v6_enabled" : false,

      "ra_guard_enabled" : false,

      "rate_limits_enabled" : false,

      "rate_limits" : {

        "rx_broadcast" : 0,

        "tx_broadcast" : 0,

        "rx_multicast" : 0,

        "tx_multicast" : 0

      },

      "resource_type" : "SegmentSecurityProfile",

      "id" : "default-segment-security-profile",

      "display_name" : "default-segment-security-profile",

      "path" : "/infra/segment-security-profiles/default-segment-security-profile",

      "relative_path" : "default-segment-security-profile",

      "parent_path" : "/infra/segment-security-profiles/default-segment-security-profile",

      "children" : [ ],

      "marked_for_delete" : false,

      "_create_user" : "system",

      "_create_time" : 1568904746259,

      "_last_modified_user" : "system",

      "_last_modified_time" : 1568904746259,

      "_system_owned" : true,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 0

    },

    "resource_type" : "ChildSegmentSecurityProfile",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  }, {

    "Segment" : {

      "type" : "DISCONNECTED",

      "vlan_ids" : [ "200" ],

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

      "resource_type" : "Segment",

      "id" : "seg-vlan-0200",

      "display_name" : "seg-vlan-0200",

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

      "relative_path" : "seg-vlan-0200",

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

      "children" : [ ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572972974519,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572972974519,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 0

    },

    "resource_type" : "ChildSegment",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  }, {

    "Segment" : {

      "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",

      "resource_type" : "Segment",

      "id" : "seg-overlay-02",

      "display_name" : "seg-overlay-02",

      "path" : "/infra/segments/seg-overlay-02",

      "relative_path" : "seg-overlay-02",

      "parent_path" : "/infra/segments/seg-overlay-02",

      "children" : [ {

        "SegmentPort" : {

          "resource_type" : "SegmentPort",

          "id" : "default:96e7763f-b5fa-4e8d-830e-dcacdc7bf43a",

          "display_name" : "vm03/vm03.vmx@c1f5e1bd-d787-4ec5-96a4-c20910bd217a",

          "tags" : [ ],

          "path" : "/infra/segments/seg-overlay-02/ports/default:96e7763f-b5fa-4e8d-830e-dcacdc7bf43a",

          "relative_path" : "default:96e7763f-b5fa-4e8d-830e-dcacdc7bf43a",

          "parent_path" : "/infra/segments/seg-overlay-02",

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "system",

          "_create_time" : 1572993602499,

          "_last_modified_user" : "system",

          "_last_modified_time" : 1572993602499,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildSegmentPort",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      }, {

        "SegmentPort" : {

          "resource_type" : "SegmentPort",

          "id" : "default:336fee15-4d0e-4d35-8dc7-cf091038b00e",

          "display_name" : "vm04/vm04.vmx@3c436657-571b-4bb3-b617-2dcfdcf2ba59",

          "tags" : [ ],

          "path" : "/infra/segments/seg-overlay-02/ports/default:336fee15-4d0e-4d35-8dc7-cf091038b00e",

          "relative_path" : "default:336fee15-4d0e-4d35-8dc7-cf091038b00e",

          "parent_path" : "/infra/segments/seg-overlay-02",

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "system",

          "_create_time" : 1572993602424,

          "_last_modified_user" : "system",

          "_last_modified_time" : 1572993602424,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildSegmentPort",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      } ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973676117,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973676117,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 0

    },

    "resource_type" : "ChildSegment",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  }, {

    "Segment" : {

      "type" : "ROUTED",

      "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",

      "resource_type" : "Segment",

      "id" : "seg-overlay-01",

      "display_name" : "seg-overlay-01",

      "path" : "/infra/segments/seg-overlay-01",

      "relative_path" : "seg-overlay-01",

      "parent_path" : "/infra/segments/seg-overlay-01",

      "children" : [ {

        "SegmentPort" : {

          "resource_type" : "SegmentPort",

          "id" : "default:94e29eaa-034c-4df6-a4b1-54fc95a18cba",

          "display_name" : "vm01/vm01.vmx@3c436657-571b-4bb3-b617-2dcfdcf2ba59",

          "tags" : [ ],

          "path" : "/infra/segments/seg-overlay-01/ports/default:94e29eaa-034c-4df6-a4b1-54fc95a18cba",

          "relative_path" : "default:94e29eaa-034c-4df6-a4b1-54fc95a18cba",

          "parent_path" : "/infra/segments/seg-overlay-01",

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "system",

          "_create_time" : 1572993602117,

          "_last_modified_user" : "system",

          "_last_modified_time" : 1572993602117,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildSegmentPort",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      }, {

        "SegmentPort" : {

          "resource_type" : "SegmentPort",

          "id" : "default:e1385e98-f4cf-4dee-bbc6-535584d9b721",

          "display_name" : "vm02/vm02.vmx@92e5beee-20a2-4ba7-8372-ce49aace34fc",

          "tags" : [ ],

          "path" : "/infra/segments/seg-overlay-01/ports/default:e1385e98-f4cf-4dee-bbc6-535584d9b721",

          "relative_path" : "default:e1385e98-f4cf-4dee-bbc6-535584d9b721",

          "parent_path" : "/infra/segments/seg-overlay-01",

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "system",

          "_create_time" : 1572993602249,

          "_last_modified_user" : "system",

          "_last_modified_time" : 1572993602249,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildSegmentPort",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      } ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973665350,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973665350,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 0

    },

    "resource_type" : "ChildSegment",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

Tier-0 ゲートウェイの情報取得。

Tier-0 ゲートウェイ配下のオブジェクトは、Tier-0 と一緒にフィルタに含める必要があります。

Tier-0 ゲートウェイだけを指定した情報取得。

まず、Tier-0 ゲートウェイだけの場合です。

GET /policy/api/v1/infra?filter=Type-Tier0

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier0

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "Tier0" : {

      "transit_subnets" : [ "100.64.0.0/16" ],

      "internal_transit_subnets" : [ "169.254.0.0/28" ],

      "ha_mode" : "ACTIVE_STANDBY",

      "failover_mode" : "NON_PREEMPTIVE",

      "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

      "force_whitelisting" : false,

      "default_rule_logging" : false,

      "disable_firewall" : false,

      "resource_type" : "Tier0",

      "id" : "t0-gw-01",

      "display_name" : "t0-gw-01",

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

      "relative_path" : "t0-gw-01",

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

      "children" : [ ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973048893,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973084322,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 1

    },

    "resource_type" : "ChildTier0",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

LocaleServices を含めた情報取得。

複数種類のリソースを含める場合は、「|」（パイプ）で連結します。

ただし、URL ではパイプ文字が指定できないので、URL エンコーディング（% エンコーディング）にします。

「|」は、「%7C」という文字列に置き換えます。

結果の JSON から、Tier0 → LocaleServices → Tier0Interface が階層構造になっていることがわかります。

ここでは LocaleServices のインターフェースも取得できています。

GET /policy/api/v1/infra?filter=Type-Tier0|LocaleServices

↓

GET /policy/api/v1/infra?filter=Type-Tier0%7CLocaleServices

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier0%7CLocaleServices

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "Tier0" : {

      "transit_subnets" : [ "100.64.0.0/16" ],

      "internal_transit_subnets" : [ "169.254.0.0/28" ],

      "ha_mode" : "ACTIVE_STANDBY",

      "failover_mode" : "NON_PREEMPTIVE",

      "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

      "force_whitelisting" : false,

      "default_rule_logging" : false,

      "disable_firewall" : false,

      "resource_type" : "Tier0",

      "id" : "t0-gw-01",

      "display_name" : "t0-gw-01",

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

      "relative_path" : "t0-gw-01",

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

      "children" : [ {

        "LocaleServices" : {

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

          "resource_type" : "LocaleServices",

          "id" : "24b79e4c-2ef1-4360-ac2c-9454514eada5",

          "display_name" : "24b79e4c-2ef1-4360-ac2c-9454514eada5",

          "path" : "/infra/tier-0s/t0-gw-01/locale-services/24b79e4c-2ef1-4360-ac2c-9454514eada5",

          "relative_path" : "24b79e4c-2ef1-4360-ac2c-9454514eada5",

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

          "children" : [ {

            "Tier0Interface" : {

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

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

              "type" : "EXTERNAL",

              "resource_type" : "Tier0Interface",

              "id" : "t0-uplink-01",

              "display_name" : "t0-uplink-01",

              "path" : "/infra/tier-0s/t0-gw-01/locale-services/24b79e4c-2ef1-4360-ac2c-9454514eada5/interfaces/t0-uplink-01",

              "relative_path" : "t0-uplink-01",

              "parent_path" : "/infra/tier-0s/t0-gw-01/locale-services/24b79e4c-2ef1-4360-ac2c-9454514eada5",

              "children" : [ ],

              "marked_for_delete" : false,

              "subnets" : [ {

                "ip_addresses" : [ "192.168.200.2" ],

                "prefix_len" : 24

              } ],

              "_create_user" : "admin",

              "_create_time" : 1572973121476,

              "_last_modified_user" : "admin",

              "_last_modified_time" : 1572973121476,

              "_system_owned" : false,

              "_protection" : "NOT_PROTECTED",

              "_revision" : 0

            },

            "resource_type" : "ChildTier0Interface",

            "marked_for_delete" : false,

            "_protection" : "NOT_PROTECTED"

          } ],

          "marked_for_delete" : false,

          "_create_user" : "admin",

          "_create_time" : 1572973084293,

          "_last_modified_user" : "admin",

          "_last_modified_time" : 1572973084293,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildLocaleServices",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      } ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973048893,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973084322,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 1

    },

    "resource_type" : "ChildTier0",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

LocaleServices とインターフェースを含めた情報取得。

Tier-0 ゲートウェイのインターフェースを含めた URL 指定は、次のようになります。

※レスポンスについては省略。

GET /policy/api/v1/infra?filter=Type-Tier0|LocaleServices|Tier0Interface

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier0%7CLocaleServices%7CTier0Interface

スタティック ルートの情報取得。

Tier-0 ゲートウェイのスタティック ルートの情報を取得します。

GET /policy/api/v1/infra?filter=Type-Tier0|StaticRoutes

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier0%7CStaticRoutes

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "Tier0" : {

      "transit_subnets" : [ "100.64.0.0/16" ],

      "internal_transit_subnets" : [ "169.254.0.0/28" ],

      "ha_mode" : "ACTIVE_STANDBY",

      "failover_mode" : "NON_PREEMPTIVE",

      "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

      "force_whitelisting" : false,

      "default_rule_logging" : false,

      "disable_firewall" : false,

      "resource_type" : "Tier0",

      "id" : "t0-gw-01",

      "display_name" : "t0-gw-01",

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

      "relative_path" : "t0-gw-01",

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

      "children" : [ {

        "StaticRoutes" : {

          "network" : "0.0.0.0/0",

          "next_hops" : [ {

            "ip_address" : "192.168.200.1",

            "admin_distance" : 1

          } ],

          "resource_type" : "StaticRoutes",

          "id" : "t0-route-01",

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

          "path" : "/infra/tier-0s/t0-gw-01/static-routes/t0-route-01",

          "relative_path" : "t0-route-01",

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

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "admin",

          "_create_time" : 1572973183264,

          "_last_modified_user" : "admin",

          "_last_modified_time" : 1572973183264,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildStaticRoutes",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      } ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973048893,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973084322,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 1

    },

    "resource_type" : "ChildTier0",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

NAT ルールの情報取得。

Tier-0 ゲートウェイの NAT ルールを取得します。

ユーザが手動で作成した「USER」のもの以外に、

自動作成される DEFAULT / INTERNAL の NAT が存在することがわかります。

GET /policy/api/v1/infra?filter=Type-Tier0|PolicyNat

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier0%7CPolicyNat

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "Tier0" : {

      "transit_subnets" : [ "100.64.0.0/16" ],

      "internal_transit_subnets" : [ "169.254.0.0/28" ],

      "ha_mode" : "ACTIVE_STANDBY",

      "failover_mode" : "NON_PREEMPTIVE",

      "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

      "force_whitelisting" : false,

      "default_rule_logging" : false,

      "disable_firewall" : false,

      "resource_type" : "Tier0",

      "id" : "t0-gw-01",

      "display_name" : "t0-gw-01",

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

      "relative_path" : "t0-gw-01",

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

      "children" : [ {

        "PolicyNat" : {

          "nat_type" : "DEFAULT",

          "resource_type" : "PolicyNat",

          "id" : "DEFAULT",

          "display_name" : "DEFAULT",

          "path" : "/infra/tier-0s/t0-gw-01/nat/DEFAULT",

          "relative_path" : "DEFAULT",

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

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "admin",

          "_create_time" : 1569254493062,

          "_last_modified_user" : "admin",

          "_last_modified_time" : 1569254493062,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildPolicyNat",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      }, {

        "PolicyNat" : {

          "nat_type" : "INTERNAL",

          "resource_type" : "PolicyNat",

          "id" : "INTERNAL",

          "display_name" : "INTERNAL",

          "path" : "/infra/tier-0s/t0-gw-01/nat/INTERNAL",

          "relative_path" : "INTERNAL",

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

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "admin",

          "_create_time" : 1569254493059,

          "_last_modified_user" : "admin",

          "_last_modified_time" : 1569254493059,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildPolicyNat",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      }, {

        "PolicyNat" : {

          "nat_type" : "USER",

          "resource_type" : "PolicyNat",

          "id" : "USER",

          "display_name" : "USER",

          "path" : "/infra/tier-0s/t0-gw-01/nat/USER",

          "relative_path" : "USER",

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

          "children" : [ {

            "PolicyNatRule" : {

              "sequence_number" : 100,

              "action" : "SNAT",

              "source_network" : "172.16.0.0/16",

              "service" : "",

              "translated_network" : "192.168.200.2",

              "scope" : [ ],

              "enabled" : true,

              "logging" : false,

              "resource_type" : "PolicyNatRule",

              "id" : "2455c9f8-17b8-4531-8b83-0ce5831eca45",

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

              "path" : "/infra/tier-0s/t0-gw-01/nat/USER/nat-rules/2455c9f8-17b8-4531-8b83-0ce5831eca45",

              "relative_path" : "2455c9f8-17b8-4531-8b83-0ce5831eca45",

              "parent_path" : "/infra/tier-0s/t0-gw-01/nat/USER",

              "children" : [ ],

              "marked_for_delete" : false,

              "_create_user" : "admin",

              "_create_time" : 1572973145927,

              "_last_modified_user" : "admin",

              "_last_modified_time" : 1572973145927,

              "_system_owned" : false,

              "_protection" : "NOT_PROTECTED",

              "_revision" : 0

            },

            "resource_type" : "ChildPolicyNatRule",

            "marked_for_delete" : false,

            "_protection" : "NOT_PROTECTED"

          } ],

          "marked_for_delete" : false,

          "_create_user" : "admin",

          "_create_time" : 1569254493061,

          "_last_modified_user" : "admin",

          "_last_modified_time" : 1569254493061,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildPolicyNat",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      } ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973048893,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973084322,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 1

    },

    "resource_type" : "ChildTier0",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

Tier-1 ゲートウェイの情報取得。

Tier-1 ゲートウェイ／LocaleServices を取得してみます。

※「filter=Type-Tier1」だけの結果は省略します。

GET /policy/api/v1/infra?filter=Type-Tier1

GET /policy/api/v1/infra?filter=Type-Tier1|LocaleServices

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier1%7CLocaleServices

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "Tier1" : {

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

      "failover_mode" : "NON_PREEMPTIVE",

      "enable_standby_relocation" : false,

      "dhcp_config_paths" : [ "/infra/dhcp-server-configs/dhcp-sv-01" ],

      "route_advertisement_types" : [ "TIER1_DNS_FORWARDER_IP", "TIER1_CONNECTED" ],

      "force_whitelisting" : false,

      "default_rule_logging" : false,

      "disable_firewall" : false,

      "ipv6_profile_paths" : [ "/infra/ipv6-ndra-profiles/default", "/infra/ipv6-dad-profiles/default" ],

      "resource_type" : "Tier1",

      "id" : "t1-gw-01",

      "display_name" : "t1-gw-01",

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

      "relative_path" : "t1-gw-01",

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

      "children" : [ {

        "LocaleServices" : {

          "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" ],

          "resource_type" : "LocaleServices",

          "id" : "7fa98167-2565-4869-b223-ffa9913684af",

          "display_name" : "7fa98167-2565-4869-b223-ffa9913684af",

          "path" : "/infra/tier-1s/t1-gw-01/locale-services/7fa98167-2565-4869-b223-ffa9913684af",

          "relative_path" : "7fa98167-2565-4869-b223-ffa9913684af",

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

          "children" : [ ],

          "marked_for_delete" : false,

          "_create_user" : "admin",

          "_create_time" : 1572973260316,

          "_last_modified_user" : "admin",

          "_last_modified_time" : 1572973260316,

          "_system_owned" : false,

          "_protection" : "NOT_PROTECTED",

          "_revision" : 0

        },

        "resource_type" : "ChildLocaleServices",

        "marked_for_delete" : false,

        "_protection" : "NOT_PROTECTED"

      } ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973229372,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973418665,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 2

    },

    "resource_type" : "ChildTier1",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

DHCP サーバの情報取得。

DHCP サーバを取得してみます。

GET /policy/api/v1/infra?filter=Type-Dhcp

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Dhcp

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "DhcpServerConfig" : {

      "server_address" : "172.16.254.254/24",

      "lease_time" : 86400,

      "resource_type" : "DhcpServerConfig",

      "id" : "dhcp-sv-01",

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

      "path" : "/infra/dhcp-server-configs/dhcp-sv-01",

      "relative_path" : "dhcp-sv-01",

      "parent_path" : "/infra/dhcp-server-configs/dhcp-sv-01",

      "children" : [ ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973288751,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973288751,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 0

    },

    "resource_type" : "ChildDhcpServerConfig",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

DNS フォワーダの情報取得。

DNS フォワーダ ゾーンの情報を取得してみます。

GET /policy/api/v1/infra?filter=Type-Dns

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Dns

{

  "resource_type" : "Infra",

  "id" : "infra",

  "display_name" : "infra",

  "path" : "/infra",

  "relative_path" : "infra",

  "children" : [ {

    "PolicyDnsForwarderZone" : {

      "dns_domain_names" : [ ],

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

      "resource_type" : "PolicyDnsForwarderZone",

      "id" : "dns-zone-01",

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

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

      "relative_path" : "dns-zone-01",

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

      "children" : [ ],

      "marked_for_delete" : false,

      "_create_user" : "admin",

      "_create_time" : 1572973350057,

      "_last_modified_user" : "admin",

      "_last_modified_time" : 1572973350057,

      "_system_owned" : false,

      "_protection" : "NOT_PROTECTED",

      "_revision" : 0

    },

    "resource_type" : "ChildPolicyDnsForwarderZone",

    "marked_for_delete" : false,

    "_protection" : "NOT_PROTECTED"

  } ],

  "marked_for_delete" : false,

  "connectivity_strategy" : "BLACKLIST",

  "_create_user" : "system",

  "_create_time" : 1568904745337,

  "_last_modified_user" : "system",

  "_last_modified_time" : 1568904745337,

  "_system_owned" : false,

  "_protection" : "NOT_PROTECTED",

  "_revision" : 0

}

まとめて情報取得。

他にも、関連するコンポーネントをある程度まとめて取得することもできます。

GET /policy/api/v1/infra?filter=Type-Tier0|LocaleServices|Segment|StaticRoutes|PolicyNat

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier0%7CLocaleServices%7CSegment%7CStaticRoutes%7CPolicyNat

GET /policy/api/v1/infra?filter=Type-Tier1|LocaleServices|Segment|Dhcp|Dns

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-Tier1%7CLocaleServices%7CSegment%7CDhcp%7CDns

ちなみに Policy API での設定全体については、つぎのように取得できます。

ただし内容は膨大で、テキスト ベースの JSON ですがデフォルトに近い環境でも 2MB 弱の容量になります。

GET /policy/api/v1/infra?filter=Type-

$ curl -ks -u $CRED -X GET https://$MGR/policy/api/v1/infra?filter=Type-

なお、全体／複数種類をまとめて取得した JSON データは、環境の論理バックアップに近い目的でも利用できます。

しかし、そのままだと PATCH / PUT で変更できないシステム オブジェクトも含まれるので、

設定のリストアに利用する場合は、取得した JSON から不要なデータを削除する必要があります。

次は、今回取得した JSON 情報を参考に、Hierarchical API で環境作成／削除をしてみます。

つづく。

NSX-T の Policy API の「Hierarchical API」で、ネットワークの作成／削除をしてみます。

前回の投稿はこちら。

NSX-T の Policy API をためす。Part.4（Hierarchical API での GET 編）

JSON ファイルの用意。

今回は、これまでの投稿で何度か構築したラボ ネットワーク環境を Hierarchical API  で作成してみます。

つぎの一連の投稿で作成したネットワークと、同様のものです。

前提として、前回までに作成／確認したオブジェクトは、ひととおり削除してあります。

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

NSX-T の Policy API をためす。Part.3（オブジェクト作成編）※Policy API での別方法で作成。

まず、前回に Hierarchical API で GET した情報から、

必要な部分のみを残した JSON ファイルを用意しておきます。

NSX-T の Policy API をためす。Part.4（Hierarchical API での GET 編）

JSON ファイルはある程度あつかいやすいように、3つに分けてみました。

より多く分割、もしくは少ない JSON ファイルにまとめることも可能です。

ext-vlan.json ファイルの内容。

{

  "resource_type": "Infra",

  "id": "infra",

  "children": [

    {

      "Segment": {

        "id": "seg-vlan-0200",

        "display_name": "seg-vlan-0200",

        "type": "DISCONNECTED",

        "vlan_ids": [

          "200"

        ],

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

        "resource_type": "Segment",

        "marked_for_delete": false

      },

      "resource_type": "ChildSegment",

      "marked_for_delete": false

    }

  ]

}

tier0.json ファイルの内容。

{

  "resource_type": "Infra",

  "id": "infra",

  "children": [

    {

      "Tier0": {

        "id": "t0-gw-01",

        "display_name": "t0-gw-01",

        "ha_mode": "ACTIVE_STANDBY",

        "failover_mode": "NON_PREEMPTIVE",

        "transit_subnets": [

          "100.64.0.0/16"

        ],

        "internal_transit_subnets": [

          "169.254.0.0/28"

        ],

        "children": [

          {

            "LocaleServices": {

              "id": "8ad9e401-f41e-4227-8445-36b1092c76a3",

              "display_name": "8ad9e401-f41e-4227-8445-36b1092c76a3",

              "children": [

                {

                  "Tier0Interface": {

                    "id": "t0-uplink-01",

                    "display_name": "t0-uplink-01",

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

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

                    "type": "EXTERNAL",

                    "subnets": [

                      {

                        "ip_addresses": [

                          "192.168.200.2"

                        ],

                        "prefix_len": 24

                      }

                    ],

                    "resource_type": "Tier0Interface",

                    "marked_for_delete": false

                  },

                  "resource_type": "ChildTier0Interface",

                  "marked_for_delete": false

                }

              ],

              "resource_type": "LocaleServices",

              "marked_for_delete": false

            },

            "resource_type": "ChildLocaleServices",

            "marked_for_delete": false

          },

          {

            "PolicyNat": {

              "id": "USER",

              "display_name": "USER",

              "nat_type": "USER",

              "children": [

                {

                  "PolicyNatRule": {

                    "resource_type": "PolicyNatRule",

                    "id": "b1a7aa47-e299-4369-a06b-3d10d48e8c68",

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

                    "sequence_number": 100,

                    "action": "SNAT",

                    "source_network": "172.16.0.0/16",

                    "service": "",

                    "translated_network": "192.168.200.2",

                    "scope": [],

                    "enabled": true,

                    "marked_for_delete": false

                  },

                  "resource_type": "ChildPolicyNatRule",

                  "marked_for_delete": false

                }

              ],

              "resource_type": "PolicyNat",

              "marked_for_delete": false

            },

            "resource_type": "ChildPolicyNat",

            "marked_for_delete": false

          },

          {

            "StaticRoutes": {

              "id": "t0-route-01",

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

              "network": "0.0.0.0/0",

              "next_hops": [

                {

                  "ip_address": "192.168.200.1",

                  "admin_distance": 1

                }

              ],

              "resource_type": "StaticRoutes",

              "marked_for_delete": false

            },

            "resource_type": "ChildStaticRoutes",

            "marked_for_delete": false

          }

        ],

        "resource_type": "Tier0",

        "marked_for_delete": false

      },

      "resource_type": "ChildTier0",

      "marked_for_delete": false

    }

  ]

}

tier1.json ファイルの内容。

{

  "resource_type": "Infra",

  "id": "infra",

  "children": [

    {

      "PolicyDnsForwarderZone": {

        "resource_type": "PolicyDnsForwarderZone",

        "id": "dns-zone-01",

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

        "dns_domain_names": [],

        "upstream_servers": [

          "192.168.1.101",

          "192.168.1.102"

        ],

        "marked_for_delete": false

      },

      "resource_type": "ChildPolicyDnsForwarderZone",

      "marked_for_delete": false

    },

    {

      "DhcpServerConfig": {

        "id": "dhcp-sv-01",

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

        "server_address": "172.16.254.254/24",

        "lease_time": 86400,

        "resource_type": "DhcpServerConfig",

        "marked_for_delete": false

      },

      "resource_type": "ChildDhcpServerConfig",

      "marked_for_delete": false

    },

    {

      "Tier1": {

        "id": "t1-gw-01",

        "display_name": "t1-gw-01",

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

        "failover_mode": "NON_PREEMPTIVE",

        "enable_standby_relocation": false,

        "dhcp_config_paths": [

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

        ],

        "route_advertisement_types": [

          "TIER1_DNS_FORWARDER_IP",

          "TIER1_CONNECTED"

        ],

        "children": [

          {

            "LocaleServices": {

              "id": "96770e38-3e86-4873-bef6-71d60267c957",

              "display_name": "96770e38-3e86-4873-bef6-71d60267c957",

              "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"

              ],

              "resource_type": "LocaleServices",

              "marked_for_delete": false

            },

            "resource_type": "ChildLocaleServices",

            "marked_for_delete": false

          },

          {

            "PolicyDnsForwarder": {

              "id": "dns-forwarder",

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

              "listener_ip": "172.16.253.254",

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

              "resource_type": "PolicyDnsForwarder",

              "marked_for_delete": false

            },

            "resource_type": "ChildPolicyDnsForwarder",

            "marked_for_delete": false

          }

        ],

        "resource_type": "Tier1",

        "marked_for_delete": false

      },

      "resource_type": "ChildTier1",

      "marked_for_delete": false

    },

    {

      "Segment": {

        "id": "seg-overlay-01",

        "display_name": "seg-overlay-01",

        "type": "ROUTED",

        "subnets": [

          {

            "gateway_address": "172.16.1.1/24",

            "dhcp_ranges": [

              "172.16.1.10-172.16.1.250"

            ],

            "network": "172.16.1.0/24"

          }

        ],

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

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

        "resource_type": "Segment",

        "marked_for_delete": false

      },

      "resource_type": "ChildSegment",

      "marked_for_delete": false

    },

    {

      "Segment": {

        "id": "seg-overlay-02",

        "display_name": "seg-overlay-02",

        "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"

          }

        ],

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

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

        "resource_type": "Segment",

        "marked_for_delete": false

      },

      "resource_type": "ChildSegment",

      "marked_for_delete": false

    }

  ]

}

ネットワーク環境の作成。

これまでの投稿で紹介したように、API のコールには、Linux クライアントで curl コマンドを利用します。

変数 CREDには「ユーザ名:パスワード」、MGR には NSX Manager のアドレスを格納してあります。

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

$ CRED='admin:VMware1!VMware1!'

今回コールする API は、一律でつぎのものです。

対象のオブジェクトとその階層、作成／削除などは、リクエストに渡す JSON データで指定しています。

PATCH /policy/api/v1/infra

それでは、ネットワークを作成していきます。

NSX Manager の UI でも、はじめはオブジェクトがない状態です。

API コールのたびに UI を更新すると、JSON に記載したオブジェクトが作成された様子がわかるはずです。

ext-vlan.json を指定して、境界のネットワークになる、VLAN セグメントを作成。

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

tier0.json を指定して、Tier-0 ゲートウェイと一連のオブジェクトを作成。

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./tier0.jsonhttps://$MGR/policy/api/v1/infra

tier1.json を指定して、Tier-1 ゲートウェイと一連のオブジェクトを作成。

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./tier1.jsonhttps://$MGR/policy/api/v1/infra

ここまでの API コールで、NSX Manager でオブジェクトが作成されました。

ネットワーク環境の削除のための JSON ファイル準備。

以前紹介したように、Policy API では、DELETE メソッドでオブジェクトをひとつずつ削除できます。

NSX-T の Policy API をためす。Part.2（DELETE 編）

Policy API を Hierarchical で利用すると、JSON データの marked_for_delete フラグによるオブジェクト削除もできます。

この場合、環境作成時の JSON ファイルで、削除対象だけ「marked_for_delete: true」とフラグを指定します。

「marked_for_delete: true」を親階層のオブジェクトで指定すると、その配下のオブジェクトも一緒に削除します。

ちなみにこのフラグはデフォルトだと false で、省略可能です。

また、ルート階層の「infra」は削除できません。

今回は、オブジェクト作成時に使用した JSON を「marked_for_delete: true」にした、

～_delete.json ファイルを用意して、オブジェクトを削除します。

それぞれの JSON ファイルで

～_delete.json ファイルを用意して、オブジェクトを削除します。

ext-vlan_delete.json をもとにした ext-vlan_delete.json では、

infra 直下のオブジェクトのみ 「marked_for_delete: true」にしてあります。

（infra オブジェクト自体は削除できないため）

例として、編集のあったファイル末尾の内容だけ、tail コマンドで表示します。

$ tail ./ext-vlan_delete.json

        ],

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

        "resource_type": "Segment",

        "marked_for_delete": false

      },

      "resource_type": "ChildSegment",

      "marked_for_delete": true

    }

  ]

}

個人的な JSON ファイル記述方法の工夫として、JSON ファイルでの編集ミス防止箇所のため、

Hierarchical API でオブジェクトの種類を表す「"resource_type": "Child～"」と、

marked_for_delete フラグは、できるだけ各オブジェクトの末尾にセットで記載するようにしています。

tier0.json をもとにした tier0_delete.json も、

Tier0 配下に一連ののオブジェクトが収まる階層構造なので

infra 直下の「ChildTier0」でのみ「marked_for_delete: true」にしてあります。

$ tail ./tier0_delete.json

          }

        ],

        "resource_type": "Tier0",

        "marked_for_delete": false

      },

      "resource_type": "ChildTier0",

      "marked_for_delete": true

    }

  ]

}

tier1_delete.json は、「Tier0」配下の階層に収まっていないオブジェクトがあり、

複数個所で "marked_for_delete": true の指定が必要になる例です。

階層全体でなく、個々のオブジェクトで marked_for_delete を true にしても削除ができるので、

すこし雑な方法ですが 元の tier1.json ファイルを、sed で一括置換してしまいます。

$ cat  ./tier1.json | sed 's/"marked_for_delete": false/"marked_for_delete": true/g' > tier1_delete.json

$ diff ./tier1.json ./tier1_delete.json

15c15

<         "marked_for_delete": false

---

>         "marked_for_delete": true

18c18

<       "marked_for_delete": false

---

>       "marked_for_delete": true

27c27

<         "marked_for_delete": false

---

>         "marked_for_delete": true

30c30

<       "marked_for_delete": false

---

>       "marked_for_delete": true

56c56

<               "marked_for_delete": false

---

>               "marked_for_delete": true

59c59

<             "marked_for_delete": false

---

>             "marked_for_delete": true

68c68

<               "marked_for_delete": false

---

>               "marked_for_delete": true

71c71

<             "marked_for_delete": false

---

>             "marked_for_delete": true

75c75

<         "marked_for_delete": false

---

>         "marked_for_delete": true

78c78

<       "marked_for_delete": false

---

>       "marked_for_delete": true

97c97

<         "marked_for_delete": false

---

>         "marked_for_delete": true

100c100

<       "marked_for_delete": false

---

>       "marked_for_delete": true

119c119

<         "marked_for_delete": false

---

>         "marked_for_delete": true

122c122

<       "marked_for_delete": false

---

>       "marked_for_delete": true

ネットワーク環境の削除。

それではオブジェクトを削除します。

今回は、あらかじめオーバーレイ セグメントは VM の vNIC から外して（別のポートグループを割り当てて）おき、

セグメントのポートがすでにない状態から開始しています。

tier1_delete.json を指定して、Tier-1 ゲートウェイと一連のオブジェクトを削除します。

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./tier1_delete.jsonhttps://$MGR/policy/api/v1/infra

tier0_delete.json を指定して、Tier-0 ゲートウェイと一連のオブジェクトを削除します。

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./tier0_delete.jsonhttps://$MGR/policy/api/v1/infra

ext-vlan_delete.json を指定して、VLAN セグメントを削除します。

$ curl -ks -u $CRED -H "Content-Type: application/json" -X PATCH -d @./ext-vlan_delete.jsonhttps://$MGR/policy/api/v1/infra

これらの API コールによって、（JSON の内容に問題がなければ）さきほど作成したオブジェクトが削除されます。

処理が完了すると、NSX Manager の Web UI でも、今回の手順開始時と同様にオブジェクト件数がゼロ件になります。

（ブラウザの更新や、「更新」ボタンで画面に反映されるはずです）

オブジェクトの指定によっては、対象オブジェクト同士の参照関係によってエラーになることがありますが、

その場合は少し待つと、（おそらく内部でリトライされて）エラーとなっていたオブジェクトでも削除されたりします。

もしくは、エラーになったオブジェクトを含むコールをリトライすることで、オブジェクトを削除できることがあります。

NSX-T の Policy API を利用する場合は、Hierarchical API 形式にすることで、

オブジェクト同士の参照関係を気にする苦労を削減できます。

手順の簡略化や構成管理の面で Hierarchical API 形式のほうが便利かなと思います。

ちなみに、いまのところのおすすめ資料は下記かなと思います。

NSX Policy API: Getting Started Guide

https://images.nsx.techzone.vmware.com/sites/default/files/PolicyAPI-v1.0.pdf

以上、Policy API の Hierarchical API でオブジェクトを作成／削除してみる話でした。

今年も、日本の vExpert 有志による Advent Calendar をやります。

この投稿は、vExperts Advent Calendar 2019 - Adventarの 1日目です。

1日目なので、多くの人が利用しているであろう vCenter Server にかかわる Tips を紹介します。

最近の vCenter Server の「vSphere Client」について。

これまで、vCenter Server（以降は vCenter）で仮想化基盤を管理するツールは何度か刷新されています。

簡単にまとめると、つぎのようになります。

• もともと C#版の「vSphere Client」があった。（vSphere 6.0 まで）
• Flash（FLEX）を利用する「vSphere Web Client」が vSphere 5.1 で登場したが、6.7 より後は廃止予定。
• HTML5 版の「vSphere Client」が vSphere 6.5 で登場。基本的に vCenter 6.5 以降ではこの vSphere Client を利用する。
  これまでの改善の様子： vSphere Client の機能の更新

もう廃止される予定の vSphere Web Client については、

vCenter 6.7 U3 では vSphere Web Client のリンクに赤字で「廃止」と明記されました。

（とはいっても、vCenter 6.7 U3 でも、まだ使用できます）

vCenter 6.7 U3 の vSphere Web Client / vSphere Client のログイン画面です。

この画面は vSphere Web Client / vSphere Client で共通です。

vSphere Web Client にログインすると、

vSphere Client へ誘導するメッセージが表示されています。

一方、HTML5 版の vSphere Client のデプロイ直後の vCenter の画面です。

最近の VMware 製品の Web UI は、Clarityというフレームワークを利用しており、

だいたい統一感のあるデザインになっています。

今回の vCenter 環境について。

前掲のスクリーンショット「ビルド 14792544」と表示されているので、

2019年12月01日の時点で最新バージョンである「vCenter Appliance 6.7 Update 3a (6.7.0.41000)」です。

vCenter のバージョンとビルド番号は、下記 KB の「Client/MOB/vpxd.log」で確認できます。

Build numbers and versions of VMware vCenter Server (2143838)

https://kb.vmware.com/s/article/2143838

ちなみに今回の vCenter は、昨年のアドベントカレンダー投稿とおなじく CLI でデプロイしています。

昨年の Advent Calendar の投稿：

vCenter 6.7 u1 の HTML5 vSphere Client をクリスマス風にしてみる。

今年の JSON： 最近、便利なので "__comments" にデプロイのコマンドラインをメモしています。

lab-vcsa-67u3.json · GitHub

vCenter の「今日のメッセージ」設定。

それでは、今日時点で最新の vSphere Client での Tips です。

vSphere による仮想化基盤では、システム管理者は頻繁に vSphere Client にログインするはずです。

そこで、システム管理者に対してメッセージを贈ってみます。

製品ドキュメント：

他のログイン ユーザーへのメッセージの送信

vCenter のインベントリにて、

vCenter → 「設定」 → 「今日のメッセージ」を開いて、「編集」ボタンをクリックします。

そして、「今日のメッセージの編集」にメッセージを記入して「OK」をクリックします。

vSphere Client から、一度ログアウトします。

vSphere Client にログインしなおすと、画面上部の青帯に、メッセージが表示されています。

（しかし、そんなに目立たない気もします。）

このメッセージは vCenter の「詳細設定」にある vpxd.motd に設定されます。

motd は、message of the day の略です。

ちなみに、このパラメータは PowerCLI / API だと Read Only で設定できなそうです。

あと、etc.motd のほうは vSphere Client ではなくコンソール / SSH のログイン メッセージ設定です。

vCenter Single Sign-on のメッセージ設定。

ただこれでは、メッセージに気づかないユーザもいるかもしれません。

そこで、もうすこしインパクトの強いメッセージ発信をしてみます。

先ほどのメッセージは、「vCenter Server」のもつメッセージ機能でした。

ここからは、vCenter の別コンポーネントである「Platform Services Controller」（PSC）のもつ

vCenter Single Sign-on のメッセージ機能を利用してみます。

製品ドキュメント：

ログイン メッセージの管理

PSC の設定は、vSphere Client の「管理」メニューから実施します。

Single Sign-On 配下の「設定」→「ログイン メッセージ」タブで、

「編集」をクリックします。

「ログイン メッセージの表示」を On にして、

「ログイン メッセージ」と「ログインメッセージの詳細」を記入してから「保存」します。

そして vSphere Client をログアウトすると・・・

vSphere Client の（PSC による）ログイン画面に、メッセージが表示されます。

メッセージのリンクをクリックすると、メッセージの詳細が表示されます。

・・・ただ、これだけだと、先ほどのメッセージより主張が弱いと感じるかたも多いと思います。

さらに、PSC のメッセージ機能では「承諾チェックボックス」を設置できます。

なお、Advent Calendar 紹介メッセージでこの設定を有効にするのはアレなので、ここからはメッセージを変更しています。

検証環境などでありがちな「このラボは2019/12/25に廃止予定です。」といったメッセージを設定しました。

これでログイン画面には、メッセージだけでく、

チェックを On にしないとログインできなくなる「次に同意します」チェック ボックスが表示されます。

チェック ボックスを Off にしたままだと、下記のように追加でメッセージが表示され、ログインできません。

「次に同意します」チェックボックスの隣のメッセージをクリックすると、

さきほどと同様に、メッセージの詳細が表示されます。

チェックを On にすることで、ログインできるようになります。

メッセージを工夫すれば、さまざまな使い道がありそうです。

以上、vCenter の Tips でした・・・

明日の vExperts Advent Calendar 2019 - Adventarは、Kaneda Naoyuki さんです。よろしくお願いします。