Open snorrea opened 1 year ago
So I personally use run-all very rarely If ever. Does it Work if you Run regular applys first in the resource group module and then in the storage account?
If you are in an automation emvironment I would rather use this to run terragrunt in correct order in Different directories
It gives the same result if I apply them individually. The resource group is created okay, even the plan for the storage account is correct (given that it uses a mock output). However, on the apply step, it decides to delete the resource group. This is quite mysterious to me; it's as if the outputs of the first steps are not known to the second.
I had hoped the dependencies would be enough to build the "deployment graph" and handle it nicely; having to "hardcode" the run order in the CI/CD we'll be setting up.
I see the problem: https://github.com/snorrea/terragrunt-azure-dependency/blob/e85e292ea87dfaa6984613ee2a4249f5360e2d68/environments/dev/terragrunt.hcl#L13
This means your state file will be the same for both modules. You need two different state keys for the two modules. Common practice is to use a helper method that returns the relative directory path for this. Can send some code tomorrow, bow only on my mobile...
That does make sense the more I think about it, particularly once this grows beyond the toy example I have here. I'll check it tomorrow; cheers! Will let you know how it goes. Let me know if you see something else that strikes you as odd.
Here is by the way a good example how the backend/state can be set up: https://github.com/gruntwork-io/terragrunt-infrastructure-live-example/blob/ad8f30f23442247ad9a3ff85be000c7f10701535/terragrunt.hcl#L43
Thanks, setting a different state for each module actually solved it! Now it works as it should. Cheers!
Have you had any success setting up TerraGrunt in Azure DevOps Pipelines?
Yes, we are running multiple large scale projects with this setup on ADO.
If you wouldn't mind, I added the pipeline I tried to get working to the repo, which is the result of several iterations. With this setup, the backend initialisation is pending for a very long without resolving, which I take is the symptom of an issue. I reckon it's tied to using the AzureCLI task. I'm trying to force it to authenticate for the service connection I've configured (pulling its credentials from the variable group), but it's apparently not working; not setting the environment variables like I do yields only an error that I am trying to authenticate the AzureCLI as a service connection instead of a user.
I'm sure you will manage it. Debugging pipelines is pain sometimes, but you get better at it. I cannot tell what is wrong from just looking at the YAML, but I guess you are moving in the right direction :) Consider that your service principal of the service connection needs access to both, the backend (an Azure storage account) and the real Azure subscription. You might even try this out locally by setting the environment variables and see if the service principal works correctly.
/edit
Ok, one thing I do see. You are missing an addSpnToEnvironment: true
on your AzureCLI task. Only this will make the environment variables available, otherwise variables will be empty. Also note that the name of the variables is fixed and you cannot chose it.
Run
terragrunt run-all apply
from theenvironments/dev
folder.Expected: Both resources are deployed to the dev subscription.
Actual: Second apply step deletes resource group before attempting to create storage account, failing the job.