Using Terraform to Provision Cisco ACI

Customers have embraced or are on the path to embrace the DevOps model to accelerate application deployment and achieve higher efficiency in operating their data centers as well as public cloud deployments. This arises from the fact that infrastructure needs to change and respond faster than ever to business needs.

These challenges, along with the ability to interact with “infrastructure” in a programmable way, has made it possible to treat Infrastructure-as-Code. The term Infrastructure-as-Code, defines a comprehensive automation approach.

This is where HashiCorp Terraform comes in. Terraform is a provisioning tool for building, changing, and versioning infrastructure safely and efficiently. Terraform manages both existing, popular services and custom in-house solutions, offering over 100 providers. Terraform can manage low-level components such as compute instances, storage, and networking, as well as high-level components such as DNS entries, SaaS features, etc. All users have to do is describe, in code, the components and resources needed to run a single application or the entire datacenter.

However, the business needs of customers can extend beyond having infrastructure respond faster, they may also require considerations around performance, cost, resiliency and security. This has led to customers adopting multi-cloud architectures. One of the key requirements of multi-cloud architectures is to have network connectivity between application workloads running in different environments. This is where Cisco Application Centric Infrastructure (ACI) comes in.

Cisco ACI allows application requirements to define the network using a common policy-based operational model across the entire ACI-ready infrastructure. This architecture simplifies, automates, optimizes, and accelerates the entire application deployment life cycle across data center, WAN, access, and cloud.

With a vision to address some of the challenges listed above, especially in multi-cloud networking, using Terraform’s plugin based extensibility, Cisco and HashiCorp have worked together to deliver the ACI provider for Terraform.

This integrated solution supports more than 90 resources and datasources, combined, which cover all aspects of bringing up and configuring the ACI infrastructure across on-prem, WAN, access, and cloud. Terraform ACI provider also helps customers optimize network compliance, operations and maintain consistent state across the entire multi-cloud infrastructure. The combined solution also providers customer a path to faster adoption of multi-cloud, automation across their entire infrastructure and support for other ecosystem tools in their environments.

One of the key barriers to entry for network teams to get started with automation is setting up the automation tool and defining the intent of the network through the tool. Terraform addresses these concerns by providing its users a simple workflow to install and get started with. Here are the steps to started with Terraform.

With Terraform installed, let's dive right into it and start creating some configuration intent on Cisco ACI.

If you don’t have an APIC, you can start by installing the cloud APIC (Application Policy Infrastructure Controller) on AWS and Azure or use Cisco DevNet’s always-on Sandbox for ACI.

»Configuration

The set of files used to describe infrastructure in Terraform is simply known as a Terraform configuration. We're going to write our first configuration now to create a Tenant, VRF, BD (Bridge Domain), Subnet, Application Profile and EPG (Endpoint Groups) on APIC.

The configuration is shown below. You can save the contents to a file named example.tf. Verify that there are no other .tf files in your directory, since Terraform loads all of them.

provider "aci" {
	username    = "cisco-automation-user"
	password    = "C1sc0"
	url         = "https://dc1-apic.cisco.com"
	insecure    = true
}

resource "aci_tenant" "cisco_it_tenant" {
	name        = "Internal-IT-Team"
	description = "ACI Tenant for internal IT"
}

resource "aci_vrf" "cisco_it_vrf" {
	tenant_dn   = "${aci_tenant.cisco_it_tenant.id}"
	name        = "internal-it-vrf"
}

resource "aci_bridge_domain" "cisco_it_bd" {
	tenant_dn          = "${aci_tenant.cisco_it_tenant.id}"
	relation_fv_rs_ctx = "${aci_vrf.cisco_it_vrf.name}"
	name               = "workload-bd"
}

resource "aci_subnet" "cisco_it_subnet" {
	bridge_domain_dn   = "${aci_bridge_domain.cisco_it_bd.name}"
	name               = "workload-subnet"
	ip                 = "10.23.239.1/22"
}

resource "aci_application_profile" "cisco_it_app" {
	tenant_dn          = "${aci_tenant.cisco_it_tenant.id}"
	name               = "payroll-application"
}

resource "aci_application_epg" "cisco_it_web_epg" {
application_profile_dn = "${aci_application_profile.cisco_it_app.id}"
name                   = "web"
relation_fv_rs_bd      = "${aci_bridge_domain.cisco_it_bd.name}"
}

(Note: This is not a complete policy configuration on APIC)

»Provider

The provider block is used to configure the named provider, in our case "aci". A provider is responsible for creating and managing resources. A provider is a plugin that Terraform uses to translate the API interactions with the service. A provider is responsible for understanding API interactions and exposing resources. Multiple provider blocks can exist if a Terraform configuration is composed of multiple providers, which is a common situation. Cisco ACI Terraform Provider works for both on-prem and cloud APIC. In addition, it supports both X509 cert based and Password based authentication.

»Resources

The resource block defines a resource that exists within the infrastructure. The resource block has two strings before opening the block: the resource type and the resource name. In our example, the resource type is an ACI object like tenant “aci_tenant” and resource name is “cisco_it_tenant”. Cisco ACI Provider supports more than 90+ resources and datasources. A complete list with examples can be found here.