Search code examples
azuredeploymentazure-resource-managerazure-rm-template

How to find differences between ARM template and actually deployed resources?


Arm templates

ARM templates should allow you to roll back to the declared cloud state. But, let's face it, the templates themselves are quite obscure as to which resources will be deployed, since they're typically long and not very human-readable.

My question

The potential issue is that it's unclear what the specified cloud environment does and does not contain. When people start clicking in the portal, a mismatch exists between declared and actual cloud infra.

The question is: Is there any way to validate which resources will be modified or even deleted when deploying an ARM template?

  • Of course we can az group deployment validate (or the Powershell alternative), but this only validates the template syntactically. What I'm looking for is something terraform plan-ish.
  • I noted that the what-if functionality is in preview. Which guarantee do we have that this would this provides accurate info about to-be-deleted resources too?

Solution

  • What-If

    AS you already found, the What-If is the tool designed to meet that very need, showing a list of which resources are to be:

    • added
    • changed (with property values, mmm)
    • removed
    • ignored.

    .. and allows you to confirm the changes and cancel should anything be amiss.

    ARM templates do support incremental deployment, keeping unscripted resources intact, and the what-if preview feature does not change that.

    Regarding guarantees..

    Yes, the What-if feature itself is still in preview today and little paranoia is justified. Obviously you don't get any guarantees for preview features, but..

    First, it's optional. You still have the ARM template and don't have to rely on What-If alone. Nor are you forced to actually deploy via What-If feature. You can check the report, but reject changes and still deploy via your usual GA-level ARM toolset. No bridges are burned (if you trust the small confirmation-asking sub-feature).

    Secondly, you should test anyway. Usually you know which changes are made in ARM and those same changes should light up in What-If. And you can verify the correctness of changes made to your dev/staging envs with little risk. You will learn early if it will work in your scenarios or not.

    Be informed. In addition to testing you can investigate the known shortcomings and issues and consider if any are important for your cases. See this repo: https://github.com/Azure/arm-template-whatif

    Summary

    What-if is immensely useful feature and seems mature enough, that I'd expect most common scenarios to work as intended. As long as you test, and have recovery plans available, then I wouldn't worry too much.