The need I went into some troubles when I wanted to implement NSXT rules. My aim was to keep the order of the rules as intended by the user when he wrote his data without asking him to enter a rule ID manually. If the order is kept then it’s easy to prioritize the rules according to their placement. With the NSX-T Terraform provider the rules are in the form below :
The chicken and egg problem I write a lot on Terraform because I like the tool very much. This time I thought it would be good to show a situation where Terraform is not necessarily the best tool for the job. The diagram below illustrates the problem.
A needs B and B needs A. If the relationship is mandatory it will be impossible to provision these resources because we have a chicken and egg problem.
The context This blog is to explains the scalability issue I have faced while trying to use Terraform to deploy Cisco ACI Fabric. Terraform has been developed initially to deploy Cloud infrastructure. As everything is virtual in a Cloud environment, it’s more or less easy to organize your Terraform infrastructure per application to keep the environment small enough. As a best practice it’s recommended to keep the workspaces as small as possible to avoid performance issues.
This blog is in two parts. The first part explains what is needed to start with Terraform. This second part is to go one step further but still targets beginners.
You can find more in depth articles on Gruntwork blog and the Terraform documentation is also very good.
Table of contents Terraform Bare minimum Terraform one step further
What happens in the background ?
What happens if we modify the object on GUI ?
This blog is in two parts. This first part explains what is needed to start with Terraform, the second part is to go one step further but still targets beginners.
Table of content Terraform bare minimum
Terraform, what is it ?
What do I need to provision something with Terraform ?
How do I know what to create ? The configuration is made of 3 blocks
The big picture This blog post is a memo for the ACI Terraform policy model. I have struggled to find equivalences between ACI REST API Call / Classes and Terraform resources. Below you can find the full diagram. The diagram is not exhaustive but I think I have reached a point where I can published something. I will probably modify or add things if I use more resources or if people correct me but I think it is a good start.
Context Can we ping the ENI of an AWS Lambda function within the VPC ? While the answer can be obvious the path to get it was insightful for me and has helped me to be more comfortable with :
AWS IAM.
AWS Lambdas function.
AWS Static IP addresses and AWS default subnets.
This test can be performed with the AWS free tier. You will find the Terraform scripts here : Lambda Ping
An IAM role is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.
TL;DR The principal is WHO will be able to access a resource.
The policy is WHAT the principals associated with the role will be able to do.
The role links the principals thanks to the assume_role_policy with the inline policy argument. The attachement links the role to a managed policies instead of the inline policy.
This article is to show an example of how to manage NSX-T firewall rules as a code through Terraform. You can find the project on my github account : nsxt-frac-tf-cm and nsxt-frac-tf-rm
I will describe the structure of the project, how it works, the data model, the Terraform code explanation and finish with an example.
Structure of the project The diagram below shows a summary of how I organized the project in order to fully use infrastructre as code.