Azure ARM Template: limitation on feature, how to detect?

0
votes

Still learning how to do InfraAsCode with ARM Template. From what I read with MS Documentation, I understand that ARM cannot do all stuff that I usually do with Powershell and I found difficulty to detect ARM limitation in this case.

Let me explain what I understand and if someone can confirm, it would be helpful.

  1. From Portal, I set up my desired resources and configure as needed
  2. Then from my resource, I click on Automation>export template
  3. now i can see how ARM deploy my resource.

I noticed that some configuration did on Step1 is not listed on step3. Does it mean that I find an ARM limitation and consequently remaining items MUST be done with Powershell (or Azure CLI) ?

Concrete example:

  • With App Service, i can configure Authentication/Authorization from Azure Portal
  • when I click on Export template, there is no nothing related to my Authentication/Authorization

Consequently: after I deployed my ARM template, i need to do extra-stuff to complete the Authentication/Authorization. Am I right ?

Thx

1
azureazure-resource-managerarm-template
The arm tag is for the ARM processor architecture. I've changed it to azure-resource-manager. Please be more careful with the use of tags. – Codo

1 Answers

1
votes

The short answer is "it depends". There are 2 api surfaces in Azure one is the "control plane" and the other is the "data plane". Very short, but the control plane lets you CRUD resources (vms, storage, sites) and the data plane let's you CRUD data (blobs, files, keyVault, appConfig, sql data).

Anything in the control plane can be done via an ARM template. Most things in portal are done with ARM templates behind the scenes, but this is not the same template you see when you do "Export".

The export in portal does an API GET on the current state of the resource and does it's best to create a template. This is not always possible because of missing/incomplete schemas, secrets, write-only properties (that are not returned via GET). So it's a best effort.

To see the template that was used (if one was used) you can look at the deployments that were done to the resourceGroup and in each deployment you can see the actually template that was used. It won't have secrets in it, but it may have extra settings that you need to provide secrets for (authn in this case).

So the path here would be to see if the portal used a template when you created your resources and use that as a reference for re-creating them. It may not be a single template like export gives you (and it will be the original state, not current state) but should fill in the gaps.

That help?