Introduction

Nexus-as-code allows for complete separation of data (defining variables) from logic (infrastructure declaration). With little to no knowledge about automation, users can instantiate Application Centric Infrastructure (ACI) Fabrics in minutes, following the menu structure of the Application Policy Infrastructure Controller (APIC). This is achieved by separating the *.yaml files which contain the desired ACI state from the Terraform Modules which map the definition of the desired state to Terraform modules and resources. The datamodel and modules used in Nexus-as-Code are open-source and available as-is. For support and or customization it is required to engage with Cisco Professional Services. The native resources in the Terraform Provider are fully supported by Cisco TAC.

The tree output below shows an example of a datamodel where the *.yaml files compose logical groups that map to constructs that ACI users are very familiar with.

$ tree -L 2
.
├── data
│   ├── apic.yaml
│   ├── access_policies.yaml
│   ├── fabric_policies.yaml
│   ├── node_policies.yaml
│   ├── pod_policies.yaml
│   ├── node_1101.yaml
│   ├── node_1102.yaml
│   ├── node_2201.yaml
│   ├── node_2202.yaml
│   ├── tenant_PROD.yaml
│   ├── tenant_FINANCE.yaml
│   └── defaults.yaml
└── main.tf

Configuration for Tenant Prod can simply be managed via the tenant_PROD.yaml:

---
apic:
  tenants:
    - name: PROD

      vrfs:
        - name: PROD

      bridge_domains:
        - name: BD_VLAN100
          vrf: PROD

        - name: BD_VLAN101
          vrf: PROD

        - name: BD_VLAN102
          vrf: PROD

      application_profiles:
        - name: PROD
          endpoint_groups:
            - name: EPG_VLAN100
              bridge_domain: BD_VLAN100
              physical_domains:
                - PHYSICAL1
              static_ports:
                - node_id: 101
                  port: 1
                  vlan: 100

            - name: EPG_VLAN101
              bridge_domain: BD_VLAN101
              physical_domains:
                - PHYSICAL1

            - name: EPG_VLAN102
              bridge_domain: BD_VLAN102
              physical_domains:
                - PHYSICAL1

ACI Provider

The Terraform provider for ACI includes an aci_rest_managed resource which can be used to manage any ACI object. A simple example of how to use the resource can be found below:

resource "aci_rest_managed" "fvTenant" {
  dn         = "uni/tn-EXAMPLE_TENANT"
  class_name = "fvTenant"
  content = {
    name  = "EXAMPLE_TENANT"
    descr = "Example description"
  }
}

The aci_rest_managed resource is not only capable of pushing a configuration but also reading its state and reconcile configuration drift. This resource is used to push the configuration to ACI.

ACI Modules

A Terraform module is a container for multiple resources that are used together. Modules can be used to create lightweight abstractions. While a Terraform resource represents a single API object (single Managed Object (MO) in case of ACI), a Terraform Module consists of multiple resources (a branch of MOs in case of ACI).

A simple example of using one of the modules can be found below:

module "aci_contract" {
  source  = "netascode/contract/aci"
  version = ">= 0.0.1"

  tenant      = "ABC"
  name        = "CONTRACT1"
  subjects = [{
    name          = "SUBJECT1"
    filters = [{
      filter   = "HTTP"
    }]
  }]
}

Nexus-as-Code for ACI Module

The Nexus-as-Code Terraform module for ACI is responsible for mapping the data to the corresponding ACI modules. This module supports an inventory driven approach, where a complete ACI configuration or parts of it are either modeled in one or more YAML files or natively using Terraform variables.

There are six configuration sections which can be selectively enabled or disabled using module flags:

• fabric_policies: Configurations applied at the fabric level (e.g., fabric BGP route reflectors)
• access_policies: Configurations applied to external facing (downlink) interfaces (e.g., VLAN pools)
• pod_policies: Configurations applied at the pod level (e.g., TEP pool addresses)
• node_policies: Configurations applied at the node level (e.g., OOB node management address)
• interface_policies: Configurations applied at the interface level (e.g., assigning interface policy groups to physical ports)
• tenants: Configurations applied at the tenant level (e.g., VRFs and Bridge Domains)

The module ships with default values for certain objects. These values are documented in the Data Model section on this page. a single file defaults.yaml can be used to define specific requirements in a central location. This will overwrite any default values that come with the main modules.

This file is typically customized to reflect the specific customer requirements and reduces the overall size of input files as optional parameters with a default value can be omitted. As some customers prefer to append suffixes to object names, such suffixes can be defined once in defaults.yaml and then consistently appended to all objects of a specific type including its references.

The Nexus-as-Code for ACI section includes a simple and comprehensive example to get started with Nexus-as-Code for ACI deployments. It also includes an example of how to set up your own CI/CD pipeline to drive automation through GitLab. For more experienced users, this page also offers guidance on topics such as scaling, distributing state and validations.