GitHub Terraform Repo

This pattern shows how I structure my GitHub repositories for storing Terraform code for Azure and AWS

Keeping track of Terraform code can be tricky, especially when using it from different systems, in VSCode, or through online services like Terraform Cloud. My preference is to keep all my code in the same place and reference it from different systems when running the code as needed. This ensures a uniform result when building infrastructure, as I use the same Terraform module code. Additionally, I can take advantage of versioning my code, use automation with GitHub Actions to manage my code, produce new version tags, scan the code for security issues, and even create documentation.


Repository structure

I store Terraform code for Azure and AWS in its own GitHub account, as I find it easier to manage the repositories if they’re the next level down from the account rather than having lots of sub-folders. Each reusable module is stored in its own repository on a per-resource basis. For example, an Azure resource group, Linux VM, and load balancer each have their own repository. Each repository is named terraform-{cloud}-{resource}, following the naming convention required when importing modules into the Terraform Cloud registry. For Azure, it’s terraform-azurerm-{resource}, and for AWS, it’s terraform-aws-{resource}.

Example Repository Structure

  • terraform-azurerm-resource-group
    • .gitignore: Specifies files and directories to be ignored by Git.
    • .terraform.local.hcl: Local Terraform configuration file.
    • locals.tf: Defines local variables.
    • main.tf: Contains the main Terraform configuration.
    • outputs.tf: Defines the outputs of the module.
    • variables.tf: Defines the input variables for the module.
    • CHANGELOG.md: Tracks changes and updates to the module.
    • LICENSE: Specifies the license for the module.
    • README.md: Provides documentation and usage instructions for the module.
  • github/workflows/
    • ci-terraform.yaml: GitHub Actions workflow for continuous integration.
  • ExampleConfiguration: Contains example configuration files to demonstrate how to use the module.
    • locals.tf
    • main.tf
    • outputs.tf
    • providers.tf
    • terraform.tfvars
    • variables.tf
  • checkov-security-scan/
    • results_cli.txt: Stores the results of security scans performed by Checkov.
grinntec-terraform-azure
|-- terraform-azurerm-resource_group
|   |-- .gitignore
|   |-- .terraform.local.hcl
|   |-- locals.tf
|   |-- main.tf
|   |-- outputs.tf
|   |-- variables.tf
|   |-- CHANGELOG.md
|   |-- LICENSE
|   |-- README.md
|   |-- .github
|   |   |-- workflows
|   |       |-- ci-terraform.yaml
|   |-- ExampleConfiguration
|   |   |-- locals.tf
|   |   |-- main.tf
|   |   |-- outputs.tf
|   |   |-- providers.tf
|   |   |-- terraform.tfvars
|   |   |-- variables.tf
|   |-- checkov-security-scan
|       |-- results_cli.txt

GitHub Actions

I use GitHub Actions to automate various tasks, such as producing new version tags, scanning the code for security issues, and creating documentation. This helps maintain the quality and security of the Terraform code.

Best Practices

  • Consistent Naming Conventions: Follow a consistent naming convention for repositories and modules to make it easier to manage and import them.
  • Version Control: Use version control to track changes and maintain different versions of the code.
  • Automation: Leverage automation tools like GitHub Actions to streamline tasks and ensure code quality.
  • Security Scanning: Regularly scan the code for security issues to identify and fix vulnerabilities.
Alt Text
The GitHub Action map

Last modified January 16, 2025: Update docker-swarm.md (1519d6d)