Introduction

This project was born out of an attempt to build a generic Terraform dpeloyment frameworks and modules for use in production/test deployment environments.

As a consultant,i would have to spend substantial time designing a framework for my customers to use ( who would for the most part were new to Azure-TF and were struggling with getting started on a stable , clean and expandable code base ). I used the learnings from many such projects and created a framework that i could carry as a generic guidance and help customers integrate their requirments into it, rather than building something from scratch. This approach also allowed my customers to simply fetch an updated code base from Github and keep their code base updated with the learnings and fixes I integrate my learnings into this framework.

This framework follows a specific set of naming convention more closely aligned with Hashicorp's standard for resource definition. This code base attempts to keep the code as dry as possible (without using 3rd party solutions ), while allowing input parameters fed purely via the means of variable files (Variable files can be hand written or generated by a configuration management system of choice). As someone told me some time back "A Dry code means a cleaner statefile !!!". And never underestiame the importance of a clean state file.

Salient features

1. "Lego Block" approach. Each module is built around a single or dependent resources ( like Virtual network or Virtual network + subnet + subnet configuration )
2. Modular - You can add and remove modules as per your requirments. Complex modules can call "Lego" modules and build complex scenarios.
3. Deploy single foundational resources or build complex structures. Each Lego module covers almost all configuration properties exposed by Provider (at the time of writing )
4. Directory based versioning, modules can be versioned locally to preserve state file data and code integrity if required ( by using old modules to maintain compatibility )
5. Modules are designed to either operate independently or can work with output of different modules to allow easy resource look up. ( example : module for subnet using output of module Virtual network, or module for subnet using name and resourcegroup to automatically fetch resource data object )
6. Provision for multi provider. Currently framework is built for Azure, but allows additional Providers to be plugged in with minimal changes.

Current Limitations

1. In case of Azure , currently only supports single Subscription deployment at a time. This will change in future release with added planned functionality.
2. Since all code for individual resource definitions is encapsulated as modules, you cannot run them under multiple provider definition.
3. Partner ID and backend has to be written in manually at the time of deployment.
4. From time to time, the code may throw errors/warnings about deprecated parameters and even resource properties missing/deprecated ( when upgrading terraform binary version and/or terraform AzureRM provider version). This is expected due to the rapidly updating Terraform engine and provider codebase.

TODO:

1. Add proper readme for each module.
2. Add detailed documentation within each module.
3. Figure out a way for automated documentation generation using embedded comments.

Getting Started

To get started

1. Clone the repository
2. Create a TFVars file or use a sample file given in "workloads" directory.
3. modify provider.tf and backend.tf file in Workloads\Infrastructure\1.0 directory
4. Run Terraform Init, Plan & Apply
5. Grab a coffee, sit back, relax and enjoy the various lines of successful deployment confirmations.

Build and Test

TODO: Describe and show how to build your code and run the tests.

Contribute

Due to the ludicrous speed at which cloud provider extensions are updated and additional configuration properties are exposed, there will come a time when the module code base becomes out dated (example : AzureRM provider did not supported Manual QOS configuration for Azure NetApp volumes at the time of first PR, but this may changed very soon ). In this case, please open an issue. You are also welcome to submit a pull request with your own changes that can enhance this tool chain for the entire community to use.

If you want to learn more about creating good readme files then refer the following guidelines. You can also seek inspiration from the below readme files:

• ASP.NET Core
• Visual Studio Code
• Chakra Core

Change Log

• Released for AzureRM provider 3.7.0 : https://github.com/hashicorp/terraform-provider-azurerm/blob/main/CHANGELOG.md#370-may-19-2022