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.
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.
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.
Hashicorp 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.
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 provides customers 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.
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.
(Note: This is not a complete policy configuration on APIC)
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.
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.
Additional learning resources:
- Additional information about Terraform
- ACI programmability learning labs
- Visit DevNet Network Automation Exchange
- Learn more about Cisco DevNet certifications
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
I think you’ve missed including the hyper-link for “Here are the steps to started with Terraform”.
Really interesting that you are now supporting Terraform.
Hi, from which aci version Is terraform supported?
Non-Cloud resources and datasources have been validated against 3.2 onwards. Cloud resources are supported from 4.2
great blog Ranga. Just happened to read it in detail. So simple and lucid and illustration
Comments are closed.