Terraform module to build a ACI Tenant in entirety from single HCL/JSON nested object variable file. This should simplify tenant configuration and allow for easier configuration changes and rollbacks.
Please also see the related module terraform-aci-fabric-object for building and managing physical ACI Fabric configuration (in entirety) from a single HCL/JSON/YAML object variable file.
This module supports re-using existing configuration through an optional use_existing
parameter at most levels. This allows Terraform to manage child objects without fully managing the parent object (i.e. Terraform can add VRFs to the common tenant without disturbing existing configuration).
Where appropriate, the module will also allow re-using configuration from other tenants though this assumes the configuraiton is already present in that tenant (i.e. common filters or shared L3outs can be leveraged from the common tenant).
This module is used in the DevNet example ACI Day 2 Terraform Examples where the same tenant configuration can evolve over time from a simple "network centric" deployment to a full "application centric" deployment including Layer 4 contracts with optional policy-based redirect (PBR) service graph, by slowing changing the tenant configuration code.
Please see this link for examples of how this module is used. ACI Day 2 Automation with Terraform
The input variable object for this module is structured on the ACI Tenant tab (ACI 5.2+). The following configuration items are supported:
- Applications Profiles (aps)
- End Point Groups (epgs)
- Static with physical path
- Dynamic with VMM domain support
- Endpoint Security Groups (esgs)
- EPG to ESG support
- End Point Groups (epgs)
- Contracts
- Standard Contracts
- Filters
- Networking
- Bridge Domains
- optional Layer 3 Subnet support
- L3 Outs (one or more)
- External EPGs
- Routed, Sub-interface, SVI and Floating SVI support
- OSPF, BGP peering support
- VRFs
- Optional Preferred Group support
- Bridge Domains
- Policies
- L4-7 Policy Based Redirection
- Services
- L4-7 Policy Based Routing Support
For any additonal requests, please raise an enhancement request within the GitHub repository.
While care has been taken to reduce the number of cross-references, it may be possible to refer to an object that does not exist yet. Examples identified currently are:
- Creating L3Out External Endpoint Group(ExtEPGs) with Contract Master ExtEPG in the same tenant. It is possible that referenced ExtEPG maynot be created when the ExtEPG with the Control Master configuration is created. The only workaround for this is to ensure the Contract Master ExtEPG is created first by running the configuration plan twice.
- Creating a L4-7 Service Graph Template instance on a Contract Subject using a Bridge Domain between the Device and the ACI fabric. It is possible the Bridge Domain will not be built before the L4-7 Service Graph instance is created. Again, the work around is to build the necessary Bridge Domains, L4-7 Devices and PBR policies in one plan, then apply the service graph template to the contrct subject in a later plan.
Name | Version |
---|---|
aci | >=2.0.0 |
Name | Version |
---|---|
aci | >=2.0.0 |
Name | Source | Version |
---|---|---|
aps | ./modules/aps | n/a |
contracts | ./modules/contracts | n/a |
networking | ./modules/networking | n/a |
policies | ./modules/policies | n/a |
services | ./modules/services | n/a |
Name | Type |
---|---|
aci_tenant.tenant | resource |
aci_tenant.tenant | data source |
Name | Description | Type | Default | Required |
---|---|---|---|---|
tenant | # New Single-Object Tenant Model ## | object({ |
n/a | yes |
Name | Description |
---|---|
ap_id_list | n/a |
bd_map | n/a |
contract_map | n/a |
epg_map | n/a |
internal_testing | n/a |
l3out_map | n/a |
vrf_map | n/a |