snorrea / terragrunt-azure-dependency

0 stars 0 forks source link

Unable to create resources for an environment #1

Open snorrea opened 1 year ago

snorrea commented 1 year ago

Run terragrunt run-all apply from the environments/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.

alxy commented 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

snorrea commented 1 year ago

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.

alxy commented 1 year ago

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...

snorrea commented 1 year ago

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.

alxy commented 1 year ago

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

snorrea commented 1 year ago

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?

alxy commented 1 year ago

Yes, we are running multiple large scale projects with this setup on ADO.

snorrea commented 1 year ago

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.

alxy commented 1 year ago

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.