6
votes

I have arm template that provisions few resources in a single resource group. Some of those resources are then altered (pricing tiers are being changed for different resource groups).

For example in my arm template Sql Database is initially provisioned for S1 performance and then scaled up to S2 by user. Then I edit my arm template to add Storage account resource for example. When I publish the updated template in to the existing resource group (the one with Sql database scaled up to S2) in order to add Storage account I see that my database is scaled down to S1 (the default value in my arm template).

My question is: is there a way to prevent arm template from modifying properties of existing resources?

2
You could create a resource lock on those resources, but that may just cause the whole deployment to fail.BenV
Can you simply deploy a different template that contains only the storage account? Or do you need to combine them for some reason? If you deploy in Incremental mode (which is the default), then none of the existing resources that are not defined in the template will not be affected.bmoore-msft
@bmoore-msft we have a lot of environments (resource groups) and we need to ensure that after redeployment new resources are added (resource list will continue to grow) and existing resources remain intact. If we have a separate template for each resource we're adding this could easily introduce more complexity to the upgrade process. That's why I wanted to contain everything in one templateMilen

2 Answers

7
votes

The nature of Azure RM Templates is to be a declarative structure that defines how a solution should be deployed. If it finds something that isn't in the template it should, by the nature of what it does, change it to match the template.

You might be better converting your templates to Powershell scripts (or REST API calls) that way you can check the state prior to creating / amending details.

The other alternative would be to modify those parameters in a script before the template is called. So that you adjust the SQL Database to an S2 if that is what exists already.

1
votes

I'd recommend against allowing manual changes via the portal (in prod environments).

Allowing changes to come both from Infrastructure As Code (IaC) and from the Azure portal defeats many of the purposes of IaC. IaC is intended not only to serve as a means of automation, but also documentation and idempotent control of your resources. If you're going to allow manual updates from the portal, your IaC will be constantly outdated and the value of maintaining it will be comparatively small.