I have used terragrunt but only with AWS. Didn’t realize it tackled the state management aspect. I wasn’t a huge fan of terragrunt because it seemed to add additional complexity (additional custom tools) that needed to be learned which made it difficult to recruit and retain an even more niche skill set. 🤣
Hello Sir, I'm happy to find your channel and I can tell you that you're doing a great job. However, if there's any advice that I can give it to you to make your videos more productive is to add sections to separate topics as you're addressing more than one thing in a single video and your audience may need to go back to a specific topic and that will make your videos extremely useful. Good luck!!
At 9:05 you are very specific to clear the double quotes wrapping the resource block labels. I also noticed quote-less labelling while reading your code from the markti/azure-terraformer repository. Curiously, the official Terraform documentation wraps labels with double quotes. Could you elaborate on rationale behind your convention to avoid the quoting?
Quotes and no-quotes work. Terraform fmt will put the quotes in. I have given up my quest to remove quotes and let Terraform fmt do it's thing. Install the extension in vs code and set it to format on save. 😊
Hi again, you're clear about backend bootstrapping is a one-shot deployment, but what about storing the state of the configuration implemented in the backend/ directory in the storage account too? Since you create the resource group, storage account and storage container using the Terraform, wouldn't it make sense to push the corresponding state files to that backend too? If the backend/ directory state is not cached, then why use Terraform? Why not create the backend-related resources with Azure CLI or even the portal, as you mentioned?
Couple of questions in here... Question 1: storing the state for the state backend is a bit of a catch 22. how can you hope to manage the environment long term with a Terraform workspace whose state resides on that backend? I suppose you could provision initially with local state and then do a state migration but that creates a circular dependency. It just won't be stable.
Question 2: we can't manage the terraform state backend using terraform long-term so why provision it in terraform? Why not CLI? You're right, we don't have to use terraform, we could use CLI. It is but a matter of preference. I prefer maintaining HCL code, I find it more readable over Bash. So I prefer to keep infrastructure code in HCL instead of Bash. You know I love me some Bash (I use it ALL the time on my channel) but every tool has its own strengths and performs its job appropriately. HCL has its job just as Bash has its own.
@@azure-terraformer Yes. I meanwhile have experimented and the migration is inevitable. First `terraform init` etc. to perform initial provisioning of resources used by remote backend, and generate e.g. .tfbackend file as Terraform output. Second, do `terraform init --backend-config=path/to/x.tfbackend` etc. to migrate the state from local to remote backend. This actually works fine, IMHO :)
Interesting idea! Maybe it's my old "separation of concerns" hat as an app Dev that makes me so worried on this one. I'll have to put some more thought into this one!
Do you have any experience with Terragrunt as an alternative to workspaces?
I have used terragrunt but only with AWS. Didn’t realize it tackled the state management aspect. I wasn’t a huge fan of terragrunt because it seemed to add additional complexity (additional custom tools) that needed to be learned which made it difficult to recruit and retain an even more niche skill set. 🤣
Hello Sir,
I'm happy to find your channel and I can tell you that you're doing a great job. However, if there's any advice that I can give it to you to make your videos more productive is to add sections to separate topics as you're addressing more than one thing in a single video and your audience may need to go back to a specific topic and that will make your videos extremely useful. Good luck!!
thanks so much for your thoughtful feedback!
At 9:05 you are very specific to clear the double quotes wrapping the resource block labels. I also noticed quote-less labelling while reading your code from the markti/azure-terraformer repository.
Curiously, the official Terraform documentation wraps labels with double quotes.
Could you elaborate on rationale behind your convention to avoid the quoting?
Quotes and no-quotes work. Terraform fmt will put the quotes in. I have given up my quest to remove quotes and let Terraform fmt do it's thing. Install the extension in vs code and set it to format on save. 😊
Hi again, you're clear about backend bootstrapping is a one-shot deployment, but what about storing the state of the configuration implemented in the backend/ directory in the storage account too? Since you create the resource group, storage account and storage container using the Terraform, wouldn't it make sense to push the corresponding state files to that backend too?
If the backend/ directory state is not cached, then why use Terraform? Why not create the backend-related resources with Azure CLI or even the portal, as you mentioned?
Couple of questions in here... Question 1: storing the state for the state backend is a bit of a catch 22. how can you hope to manage the environment long term with a Terraform workspace whose state resides on that backend? I suppose you could provision initially with local state and then do a state migration but that creates a circular dependency. It just won't be stable.
Question 2: we can't manage the terraform state backend using terraform long-term so why provision it in terraform? Why not CLI? You're right, we don't have to use terraform, we could use CLI. It is but a matter of preference. I prefer maintaining HCL code, I find it more readable over Bash. So I prefer to keep infrastructure code in HCL instead of Bash. You know I love me some Bash (I use it ALL the time on my channel) but every tool has its own strengths and performs its job appropriately. HCL has its job just as Bash has its own.
@@azure-terraformer Yes. I meanwhile have experimented and the migration is inevitable. First `terraform init` etc. to perform initial provisioning of resources used by remote backend, and generate e.g. .tfbackend file as Terraform output.
Second, do `terraform init --backend-config=path/to/x.tfbackend` etc. to migrate the state from local to remote backend.
This actually works fine, IMHO :)
Interesting idea! Maybe it's my old "separation of concerns" hat as an app Dev that makes me so worried on this one. I'll have to put some more thought into this one!