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 post is to show an example of using CI/CD with Terraform Cloud and Github Actions in order to have a better NetDevOps approach by doing NSX-T Network Infrastructure as code (IaC). It’s almost a bingo, I think I have most of the buzz words of these last years :)
I will describe the structure of the project, the project components, the project workflow and finish with how to test this project.
This post is to explain one of the pain point I have encountered while trying to do Github Actions with Terraform Cloud for CI/CD of NSX-T. The difficulty is to chain workflow/pipeline automatically. In my case, I wanted to launch a workflow base of a PR create by another workflow. When you use Github Actions to interface with Github, you need to authenticate your Github Actions script against Github. You can then use the GITHUB_TOKEN that has been made for this purpose.
This blog post is to explain how I did to automatically change Terraform Cloud workspace from Github Actions. As explained in the documentation remote workspace, you can use different remote workspace by specifying the prefix of you workspace in the Terraform backend configuration.
backend "remote" { organization = "netmemo" workspaces { prefix = "netmemo-" } } After that, you only need to select the proper workspace by entering the terraform workspace select [suffix] command.
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.
Along my different jobs, one of the things that led to L2 extension and then brought risks and slew down or even blocked projects was big heterogeneous subnets.
Often the initial rational of big heterogeneous subnets was to avoid too much vlans on physical infrastructure. Historically physical infrastructure had vlans and spanning tree limits. The problem is that when migration time is coming nobody wants to change IP addresses. Even after arguing, this is the network that bears the risk to break the entire company by stretching L2.