In Part 1 we looked at deploying an azure sql database and logical server via some very primitive terraform. This post looks at different methods of structuring terraform with an aim to have a terraform project containing modularization and logical separation of resources with one example. The importance of project structure can not be understated, trust me, poor design at the start results in serious pain later on.
Also bear in mind project layouts are subjective to a degree, the example below is an improvement on Part 1’s but there are yet further developments of this one that introduce complexity’s that i feel are outside the scope of this series.
Recap
In part 1 we had a flat file structure with multiple resources in one main.tf.
|
1 2 3 4 5 6 7 8 9 10 |
TF_DEMO_1 ├── .terraform ├── terraform.lock.hcl ├── main.tf ├── main.tfplan ├── outputs.tf ├── providers.tf ├── terraform.tfstate ├── terraform.tfstate.backup └── variables.tf |
- main.tf – contained the resource blocks for a resource group, random password, a local variable, logical server and database.
- variables.tf – containing the variable declarations used in the resource blocks, which were all not set in a tfvars so defaults were used.
- provider.tf – containing the terraform block, provider configurations, and aliases.
- output.tf – containing the defined outputs of logical sql server and database for re-use.
- *.tfvars – not used.
Although this is easy to work with, it doesn’t scale well and can lead to serious pain down the line.
Pros
- Simplicity
- Quick setup
Cons
- Lack of modularity: Are you using the same versions of resources other teams are using ? How will you share them ?
- Reduced Readability: Harder to navigate and manage as the infrastructure grows. Thousands of lines of different resources sound fun ?
- Difficult Maintenance: Troubleshooting and updating resources becomes challenging.
- Poor Reusability: Makes it difficult to reuse configurations across different projects or environments.
- Poor Scalability – each new resource would have to go into the only main.tf
Alternate Project Structures
The aim is to have a solution avoiding the pitfalls that come with the basic pattern shown above. This commonly involves splitting your single main.tf via the following :
- By Service – you might want to break up each business vertical into their own main.tf so all components for them are in one file.
- By Components – every database could be managed through its own main.tf, so could networks and virtual machines.
- When I began I placed every resource required for a managed instance/sql database in a single main.tf as a method of enforcing standards. Solutionising the IaC.
One other common strategy is to break up environments into the own variables.tf. This allows easy environment separation whilst keeping to the same project source and reduces the risk of accidentally applying changes meant for one environment to another.
- terraform.np.uks.tfvars
- terraform.pr.uks.tfvars
With this you initiate a different backend config depending on environment, parse in the required tfvars as a variable to terraform plan and generate output thats environment specific.
Example
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
| .terraform.lock.hcl | main.tf | terraform.np.tfvars | terraform.pr.tfvars | terraform.tfstate | terraform.tfstate.backup | tf.tfplan | variables.tf | \—–Resource_Modules +—–azurerm_mssql_database | main.tf | outputs.tf | variables.tf | +—–azurerm_mssql_server | main.tf | outputs.tf | variables.tf | \—–azurerm_resource_group main.tf variables.tf |
The example above is a 2 layered nested structre where the top main.tf calls child resources in the Resources_Modules folder.
Below are the steps to get this working:
- Create your project structure
- Create separate backend configs
- Initialise terraform pointing to the non-prod backend config
- terraform init -reconfigure -backend-config=”path=C:\TFState\NP\backend.np”
- Plan against non-prod tfvars
- terraform plan -out tf.tfplan –var-file=terraform.np.tfvars -detailed-exitcode
- You will notice a state file/lock info be created in the directory of the backend config
- Apply
- terraform apply tf.tfplan
You can also see the entry’s into the state file:
Now lets create a prod server and db..
|
1 |
PS C:\GitHub\DBA_Demo_2> terraform init –reconfigure –backend–config=“path=C:\TFState\PR\backend.pr” |
Prod backend in use:
Plan against pr.tfvars
|
1 |
terraform plan –out tf.tfplan —var–file=terraform.pr.tfvars –detailed–exitcode |
The crucial thing here is the fact we are using two different sets of tfvars to create changes without impacting each others state. This separation of resources per environment is key.
Clean up
Remove all the entry’s from the respective tfvars:
source code can be found here
Closing Thoughts
We have barely scratched the surface when it comes to good project structure and best practices, however we have have looked at a different approach that is a huge leap forward by introducing modularization and environment separation.
Ultimately the choice of project structure is slightly subjective, but proper planning at the start can prevent serious headaches down the line.
In the next part of this series we will look at applying some Azure SQL best practices.