YAML-Driven NSX-T Infrastructure as Code: Real Examples for Modern Ops

Table of Contents

  1. Introduction: Why YAML-Driven IaC for NSX-T?
  2. Foundation: NSX-T 4.x Automation Landscape
  3. Core Concepts: Structuring Advanced YAML for NSX-T
  4. Practical Examples:
    • a. Greenfield: Automated VPC Creation
    • b. Brownfield: Microsegmentation with Inheritance
    • c. Multi-Tenant Edge Blueprints
    • d. Hybrid Cloud Integration
  5. End-to-End Workflow: From YAML to Deployed NSX-T
  6. Toolchains: Ansible, Terraform, and Direct API Approaches
  7. Integration: vSphere, Kubernetes (Tanzu/Openshift), Cloud
  8. Diagrams
  9. Pro Tips & Pitfalls
  10. Conclusion

1. Introduction: Why YAML-Driven IaC for NSX-T?

Modern IT organizations demand agility, repeatability, and compliance. Infrastructure as Code (IaC) using YAML allows network engineers, architects, and platform teams to design, provision, and version entire NSX-T network topologies with source-controlled, human-readable files.

Benefits:

  • Versioned network blueprints
  • Rapid, auditable changes
  • Integration with CI/CD pipelines
  • Team collaboration, peer review, rollback

2. Foundation: NSX-T 4.x Automation Landscape

NSX-T 4.x unlocks API-first networking and robust automation capabilities. You can build NSX objects (segments, routers, firewall policies) using:

  • Direct NSX-T API: POST/PUT calls with JSON or YAML payloads.
  • Terraform Provider: Write infrastructure state as code, then terraform apply.
  • Ansible Modules: Playbooks orchestrate workflows using YAML tasks.
  • Custom Python Scripts: Leverage PyNSXv/requests for flexible logic.
  • CI/CD Pipelines: Integrate YAML into GitHub Actions, Jenkins, or GitLab CI.

3. Core Concepts: Structuring Advanced YAML for NSX-T

Key Principles

  • Separation of Concerns: Group resources (e.g., segments, gateways, security policies) into logical files or templates.
  • Templating & Variables: Use Jinja2 (Ansible), Terraform variables, or native YAML anchors/aliases for DRY (Don’t Repeat Yourself) patterns.
  • Idempotency: Ensure code can be re-run safely.

Example YAML Patterns

With Anchors/Aliases:

defaults: &segment_defaults
transport_zone: "Overlay-TZ"
replication_mode: "MTEP"
admin_state: "UP"

segments:
- name: "Prod-App"
<<: *segment_defaults
- name: "Prod-DB"
<<: *segment_defaults

4. Practical Examples

a. Greenfield: Automated VPC Creation

Example YAML (Ansible Playbook Snippet)

- name: Deploy VPC Segments in NSX-T
hosts: localhost
vars_files:
- vpc_segments.yaml
tasks:
- name: Create segment
vmware.nsxt.nsxt_logical_switch:
hostname: "{{ nsx_manager }}"
username: "{{ nsx_user }}"
password: "{{ nsx_pass }}"
validate_certs: no
transport_zone_id: "{{ item.transport_zone }}"
display_name: "{{ item.name }}"
admin_state: "{{ item.admin_state }}"
loop: "{{ segments }}"

Supporting YAML (vpc_segments.yaml):

segments:
- name: "Tenant1-Web"
transport_zone: "Overlay-TZ"
admin_state: "UP"
- name: "Tenant1-App"
transport_zone: "Overlay-TZ"
admin_state: "UP"

b. Brownfield: Microsegmentation with Inheritance

YAML with Inheritance

defaults: &rule_defaults
action: ALLOW
logged: true

security_policies:
- name: "Prod-DB-Access"
rules:
- name: "Web-to-DB"
source_groups: ["Prod-Web"]
destination_groups: ["Prod-DB"]
service_entries: ["MYSQL"]
<<: *rule_defaults

Terraform Equivalent

variable "segment_names" {
type = list(string)
default = ["Prod-Web", "Prod-App", "Prod-DB"]
}

resource "nsxt_policy_segment" "prod_segments" {
for_each = toset(var.segment_names)
display_name = each.key
transport_zone_path = data.nsxt_policy_transport_zone.overlay.path
}

c. Multi-Tenant Edge Blueprints

YAML Example (Ansible + Jinja2):

tenants:
- name: "TenantA"
edge_cluster: "Edge-Cluster-1"
segments:
- "TenantA-Web"
- "TenantA-DB"
- name: "TenantB"
edge_cluster: "Edge-Cluster-2"
segments:
- "TenantB-Web"
- "TenantB-DB"

Jinja2 Template:

{% for tenant in tenants %}
- name: "Create segments for {{ tenant.name }}"
vmware.nsxt.nsxt_logical_switch:
hostname: "{{ nsx_manager }}"
username: "{{ nsx_user }}"
password: "{{ nsx_pass }}"
transport_zone_id: "Overlay-TZ"
display_name: "{{ item }}"
loop: "{{ tenant.segments }}"
{% endfor %}

d. Hybrid Cloud Integration

Example: Creating NSX Segments for Kubernetes Namespaces via Terraform

resource "nsxt_policy_segment" "k8s_ns_segments" {
for_each = toset(["dev", "staging", "prod"])
display_name = "k8s-{{ each.key }}"
transport_zone_path = data.nsxt_policy_transport_zone.overlay.path
}

5. End-to-End Workflow: From YAML to Deployed NSX-T

  1. Define resources in YAML/Terraform/Ansible.
  2. Lint/Validate files for syntax and policy.
  3. Commit to source control (Git).
  4. Run pipeline: CI/CD triggers provisioning.
  5. APIs/Modules execute changes against NSX-T.
  6. Verify: Automated tests, compliance scans.

6. Toolchains: Ansible, Terraform, and Direct API Approaches

Ansible

  • Modular playbooks for all NSX-T objects
  • Dynamic inventory and templating

Terraform

  • State tracking for drift detection
  • Supports all major NSX-T objects, with provider improvements in 2024-2025

Direct API

  • Use Python/Go for custom workflows or unsupported features
  • API Explorer in NSX-T GUI helps generate request samples

Python Example:

import requests
import yaml

with open('segments.yaml') as f:
segments = yaml.safe_load(f)

for segment in segments['segments']:
# Build and send API call for each segment (sample only)
response = requests.post(
"https://nsx-manager/api/v1/segments",
json=segment,
verify=False,
auth=('admin', 'password')
)
print(response.status_code)

7. Integration: vSphere, Kubernetes (Tanzu/Openshift), Cloud

  • vSphere: Map segments to vDS port groups, automate VM attachment
  • Kubernetes: NSX Container Plugin supports YAML-based network policies, automates pod network security
  • Cloud: Integrate with VMC on AWS, Azure VMware Solution—manage via same YAML/CI workflows

8. Diagrams:

Example 1: Basic NSX-T Topology


Example 2: Multi-Tenant Microsegmentation


9. Pro Tips & Pitfalls

  • Tip: Use yamllint and pre-commit hooks for error-free code
  • Tip: Store secrets outside YAML (vault, env variables)
  • Tip: Annotate YAML with business context for audit/readability
  • Pitfall: Avoid hardcoding IDs—reference by name or variable
  • Pitfall: Validate with a lab before pushing to production

10. Conclusion

YAML-driven Infrastructure as Code for NSX-T 4.x transforms static network operations into dynamic, reliable, and scalable automation. Whether greenfield or brownfield, leveraging YAML with Terraform, Ansible, or APIs accelerates deployment, reduces risk, and empowers modern IT teams. With advanced patterns, deep integration, and clear documentation (including diagrams for immediate use), your NSX-T networks are ready for any challenge.


Disclaimer:
The views expressed in this article are those of the author and do not represent the opinions of VMware, my employer or any affiliated organization. Always refer to the official VMware documentation before production deployment.

Leave a Reply

Discover more from Digital Thought Disruption

Subscribe now to keep reading and get access to the full archive.

Continue reading