Software Defined Networking met PowerShell en de VMware NSX REST API – Deel 4

Deze blogserie bestaat uit meerdere delen, die in de komende maanden uitkomen. De volgende delen zijn op dit moment uitgebracht of gepland:

  1. Wat is de VMware NSX REST API
  2. Aanroepen van de VMware NSX REST API met PowerShell
  3. Met PowerShell aanmaken van een eenvoudig 3-tier netwerk in VMware NSX
  4. PowerNSX (deze blogpost)
  5. Van virtueel naar visueel: Genereer een netwerkdiagram met PowerNSX
  6. Kloon uw netwerk: van productie naar test met REST

Deel 4: PowerNSX

Nadat we in de delen 1 t/m 3 de NSX REST API hebben gebruikt om routers en switches te configureren, gaan we in deel 4 aan de slag met PowerNSX.

De volledige code van deze blogserie is hier te vinden:
https://bitbucket.org/metisit/powershellnsxrestapi/src

De code van dit deel staat in de folder ‘Part 4’ en bestaat uit 4 bestanden, namelijk:

Demo-NSXTier.jsonDe configuratie van het te maken netwerk in JSON-formaat.
Demo-NSXTier.pdfSchema van het te maken netwerk in PDF-formaat.
Create-NSXTier.ps1Het PowerShell-script om het netwerk aan te maken.
Remove-NSXTier.ps1Het PowerShell-script om het netwerk te verwijderen.

PowerNSX is een PowerShell-module gemaakt door Nick Bradford van VMware, met als doel de complexiteit van het aansturen van NSX met PowerShell te verminderen. Alle REST-aanroepen zijn vervangen door cmdlet’s en de gebruiker hoeft zich niet meer druk te maken over de REST API en de XML-berichten die daarbij gebruikt worden.

Instructies om PowerNSX te installeren en te gebruiken vindt je hier: https://powernsx.github.io/. PowerNSX is open source en wordt daarom niet “officieel” ondersteund door VMware.

Een groot verschil tussen PowerNSX en PowerCLI is dat PowerNSX geen eigen objecten definieert en gebruikt, maar (arrays van) System.Xml.XmlElement objecten. Feitelijk wordt dus nog steeds XML gebruikt. Dit heeft als consequentie dat je soms een andere cmdlet nodig hebt om een argument mee te geven aan de cmdlet die je wilt gebruiken. Een voorbeeld is de cmdlet Get-NsxLogicalRouterInterface, die alle interfaces van een Logical Router (DLR) toont. Als je deze cmdlet direct aanroept, dan vraagt deze om ‘LogicalRouter`. Dit lijkt de naam te zijn van de DLR, maar dat is niet zo:

Deze functie verwacht niet de naam van de DLR, maar een XmlElement met daarin de omschrijving (in XML) van de DLR. Deze is op te halen met Get-NSXLogicalRouter:

Deze uitvoer lijkt niet op XML, maar dat komt door de standaard formattering van PowerShell. PowerNSX komt ook met de cmdlet Format-XML, die de XML-inhoud op een mooie manier formatteert:

Handig om de XML die wordt gegeneerd leesbaar voor ons te maken, maar de output hiervan kan je niet meer gebruiken als input voor andere PowerNSX cmdlets.

De juiste aanroep van Get-NsxLogicalRouterInterface is:

Maar als je de output van Get-NsxLogicalRouter meerdere keren gebruikt dan is het wellicht handiger om de output in een variabele op te slaan:

Of, meer traditioneel:

Ik heb de code van deel 3 voor deel 4 volledig omgezet in PowerNSX (zie link aan het begin van deze blog).

Let op: Ik heb gebruik gemaakt van mijn eigen Get-StoredCredential cmdlet uit de blog “Securely Storing Credentials with PowerShell” (zie: Securely Storing Credentials with PowerShell). Wil je deze niet gebruiken, vervang dan regel 67 en 74 door de standaard Get-Credential cmdlet.

In de nieuwe code van Part 4 zijn een aantal zaken totaal anders:

1. De C#-class om foutmeldingen te voorkomen bij ongeldige (self-signed) certificaten (SSLValidator) is weggehaald. Deze is standaard ingebouwd in PowerNSX.
2. De code om de interne namen van VMware objecten op te halen (moref’s) is ook vervallen. PowerNSX gebruikt de namen zoals deze te zien zijn in vCenter.
3. Geen gedoe meer met XML in je code, die daardoor gelijk veel beter leesbaar wordt.
4. Niet elke keer een herhaling van bijna dezelfde code rondom de HTTPS-aanroepen.
5. De grootte van de broncode is spectaculair veel kleiner.

Kortom: PowerNSX werkt toch echt veel prettiger dan zelf stoeien met de REST API, en is veel minder foutgevoelig.

In de volgende deel gaan we onze netwerkconfiguratie omzetten in een tekening, uiteraard ook met PowerNSX.

6 maart 2017
Theo Hardendood