07-28-2023 06:43 AM
First of all, from tooling perspective, I selected Terraform Cloud and Github to keep thing simple.
I understand the workflow within Git/Github, Terraform and the way team could collaborate on the code. However, I am not certain about how would Terraform be used smartly to maintain/update a ACI.
For example, once I started using Terraform to manage ACI fabric, what would be the recommended process to add new configuration into this ACI, such as new EGP/BD, VLANs, port binding etc...
Do I just keep adding new configuration resources into the existing main.tf file or corresponding module files to have terraform apply OR there are smarter ways to accomplish these tasks. I could definitely just keep using the main.tf or module files for any new configuration for the ACI but I concern about scalability once the fabric is getting bigger and more complicated.
Suggestions?
Solved! Go to Solution.
08-16-2023 12:37 AM
You are correct that scaling a Terraform implementation might pose challenges in the future. The main 'culprit' in this is the state which is kept by Terraform (which is also its biggest benefit in my opinion). It's reasonable to consider multiple state files for Terraform, based on logical separations. For example, a state per Tenant, or a state per VRF etc.
The following link discusses some considerations for handing ACI with Terraform and scaling the deployment: https://developer.cisco.com/docs/nexus-as-code/#!scaling/scaling-terraform
There's a lot more on that webpage about managing ACI using Terraform, but without using HCL. I don't know whether you were already familiar with the nexus as code concept, but in my opinion it's an awesome way to manage a fabric using Terraform. Give it a read if it's new to you.
08-14-2023 04:34 AM
Hi,
Variable files would be best option. Because once we made one template - main.tf - we just need care about the data. If you wanna add more EPG, just copy sample EPG data block from tfvars file - change name, APN name.. etc.
If you find my reply solved your question or issue, kindly click the 'Accept as Solution' button and vote it as helpful.
You can also learn more about Cisco ACI through our live Ask the Experts (ATXs) session. Check out the ATXs Resources [https://community.cisco.com/t5/data-center-and-cloud-knowledge/cisco-aci-ask-the-experts-resources/ta-p/4394491] to view the latest schedule for upcoming sessions, as well as the useful references, e.g. online guides, FAQs.
Tarakesh Jetti,
Customer Success Specialist - CX Team.
08-16-2023 12:37 AM
You are correct that scaling a Terraform implementation might pose challenges in the future. The main 'culprit' in this is the state which is kept by Terraform (which is also its biggest benefit in my opinion). It's reasonable to consider multiple state files for Terraform, based on logical separations. For example, a state per Tenant, or a state per VRF etc.
The following link discusses some considerations for handing ACI with Terraform and scaling the deployment: https://developer.cisco.com/docs/nexus-as-code/#!scaling/scaling-terraform
There's a lot more on that webpage about managing ACI using Terraform, but without using HCL. I don't know whether you were already familiar with the nexus as code concept, but in my opinion it's an awesome way to manage a fabric using Terraform. Give it a read if it's new to you.
08-17-2023 07:32 AM
NAC is a greate resource for non-developer like me...Having been experiencing it since I created this post last month...
03-26-2025 05:28 AM
If you're managing an existing Azure Container Instance (ACI) with Terraform setting up a solid DevOps workflow is crucial for automation and consistency. A common approach is to store Terraform configurations in a version controlled repository like Git, ensuring changes are trackable.
For automation, CI/CD pipelines—using tools like GitHub Actions, GitLab CI or Azure DevOps—handle Terraform execution. Terraform state should be securely stored in Azure Storage to maintain consistency across deployments. When changes are introduced, the pipeline runs terraform plan to preview them before applying updates with terraform apply.
Security is another key factor—sensitive credentials (like service principal secrets) should be stored in Azure Key Vault to prevent exposure. For monitoring and observability, Azure Monitor and Log Analytics provide insights into ACI performance, helping with proactive issue detection.
In case of failures rollback strategies rely on Terraform state versioning, making it easier to revert to a stable state if needed. If you’re looking for expert guidance, companies like CONTUS Tech, Apptha, ValueCoders, Pixel Cryons, and Apphitect specialize in DevOps services and can help streamline the process.
Has anyone here implemented a similar setup? Would love to hear your experiences or any additional best practices you follow!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide