Searching for advice regarding structuring & managing Azure/AKS TF scripts

[Thinnesen]

Hi guys,

I hope a friendly soul is able to clear up some of my concerns/questions regarding my TF script, provisioning an AKS cluster. I’ll list the “challenges” I’ve run into below in numbered order !

To give a quick insight on the structure itself (Not very pretty & any tips are welcome)
Root folder for the project includes the main.tf, that is sourcing to ./modules/tf-azurerm-aks
All this main.tf file contains is the actual “customized” values that’ll need to be changed from cluster to cluster. Node pools, cluster name, subnets, helm template values etc.

Besides that it includes the backend.tf pointing to azurerm & the RG, SA, Container name etc. as hardcoded values (Leading to the first issue)

in the above mentioned folder ‘./modules/tf-azurerm-aks’ all the azurerm resources are used to provision the whole cluster, including resource group, networks, AKS cluster and so on. No hard-coded values are defined here, only in the variables.tf file, which is then filled out by the root-folders’ main.tf as mentioned. So the whole module is DRY

Hope this gives a quick insight.
Regarding the issues:

1. What’s the proper way to handle backend.tf variables? Right now It’s quite a hassle that all the values have to be filled out manually, since variables are not allowed in this file. I know projects like Terragrunt can solve this, but isn’t there any “proper” native way to do it?

2. Currently I have an issue with provisioning the Storage-Account & Resource-Group “properly” with Terraform, due to the fact that the backend.tf file is dependent on these, therefore the script won’t run unless these are created manually, so that the state file can be assigned there at runtime.

What’s the “proper” solution to this issue? I’ve thought about creating a sort of ‘enabler’ module, which will create the RG & Storage Account with local-state (Through my pipeline), which will then trigger the rest of the script to execute, including the new backend.tf file, that can use the created RG & SA to store itself in Azure. My concern with this is the state file for the RG & SA itself would be local, and most likely poof or get corrupt. Is this an issue? The RG & SA itself won’t need to be managed with Terraform after the inital setup, as long as all the resources ontop of them, are able to be managed properly- with the state being in the cloud.
(Hope it explains the issue somewhat)

I hope someone can clear some of these concerns up somewhat !
I’ve attached an “overview” of the folder-structure, just for good measure. Ignore the ‘Enabler’ folder, was just playing with the thought.

Thanks a lot in advance!
Have a great day

[apparentlymart]

Hi @Thinnesen,

The storage for your state is part of the small set of objects that Terraform expects should already exist before you use it, along with the account(s) you intend to use in the remote system and the credentials needed to access those accounts.

If you want to manage those objects with Terraform then you will typically need to have a separate Terraform configuration that is only used to manage those objects, and then use a more manual process for managing the small state of just that initial configuration, such as manually copying the local state file into some persistent storage. This small “bootstrapping” configuration should not need to be changed often and so this is often a reasonable compromise.

On the other hand, the fact that these objects tend to need to be set up only once and never touched again also leads many folks to just keep it simple and create this small number of objects manually. For something that only needs to happen in exceptional circumstances it’s often okay to rely on some documented manual steps rather than forcing automation, and there will always be at least a few manual steps such as signing up for your account on the target platform anyway.

[Thinnesen]

Thank you @apparentlymart!

So “best-practice”, or rather ease-of-use is to simply create the subscription, resource group & storage account. Then from there let Terraform control the resources ontop utilizing these pre-made resources?

Regarding the “structure” of the above itself, do you reckon this is an alright way to structure it? Or should this be reconsidered.

[apparentlymart]

Yes, with the caveat that I’m not an expert with Azure in particular (so my advice was more general), what you’ve described sounds like a reasonable way to interpret that suggestion for Azure in particular.