Advanced Terraform Techniques

This session covers advanced topics related to Terraform coding and code management that will help you and your organization create, utilize, maintain, manage, and optimize your Terraform codebase.

Learn how to utilize DRY programming concepts in your Terraform code. Through a combination of Terraform HCL constructs and GitHub techniques, your Terraform code can be modularized to support multiple deployments without duplicating code in each project.

Next, we will look at for_each and dynamic block constructs and how to define and dynamically create the data used in these constructs. By creating data-driven code, you will rarely change the foundational blocks of code and focus more on the data that is used by the code.

By utilizing Maps and converting your lists to Maps you can say goodbye the count parameter and benefit by being able to specifically reference an object by its key. Dynamically generating data by combining sets of data enables extreme flexibility in the way modules will consume the data to create and manage objects.

Wrapping up the session will be a focus on how to implement implicit dependencies and eliminate the need for explicit dependencies. These are techniques I use regularly in my Terraform code to generate hundreds of Azure lab and training environments monthly.

Speaker: John McDonough

HashiCorp provides infrastructure automation software for multi-cloud environments, enabling enterprises to unlock a common cloud operating model to provision, secure, connect, and run any application on any infrastructure. HashiCorp open source tools Vagrant, Packer, Terraform, Vault, Consul, Nomad, Boundary, and Waypoint allow organizations to deliver applications faster by helping enterprises transition from manual processes and ITIL practices to self-service automation and DevOps practices.

[stephane]

I was partly on this path with my refactoring.

However I keep asking myself if I’m digging a hole by doing simple wrappers around terraform resources. Eg. Module for a resource group

Seems like it goes against what Hashicorp recommends. Don’t create simple wrappers

Ok any case, I’ve got about 20 or so modules created following this pattern and not looking back.

I find the locals files are getting long in some cases with app gateways and apps etc.

[iuliansurugiu]

I like the modular approach however given through what I've been through the last 5 years, I am highly discouraging the use of git submodules as it creates a lot of complexity when it comes down to versioning and management within medium/large teams

[itquestionswithnige]

You now have Azure Verified modules for both terraform and bicep which is essentially git sub modules but they're maintained by Microsoft and individual contributors which also sit in the TF registry when using TF. Feels like an evolution of whats shown in this video but possibly simpler and ive found them much easier to nest in modules etc.

[greenstevester]

git submodules?? are you kidding me?? worst best practice ever!

[MaxymVlasov]

Example with for loops in locals (not for_each) when speaker convert one structure to another are worth to see.
But all other stuff... Well, at least that combo of bad practices works fine for him.

[GrantDoyle-ne]

This is really great, is there a repo available? What version is this available on? I also wonder how this would work with existing infrastructure and having to pull those into a state file (reverse terraforming)?

[aminniktash]

great advance modular approach and clean structure TF coding:) would you please provide more examples at the repo provisioning a vm and vent-peering along with security group assignment and windows vm extensions?