Creating an Azure Function host key using ARM doesn't work on a new deployment

Question

I try to create an Azure Function host key inside an ARM template where I first create the function, and then I create the key:

{
  "type": "Microsoft.Web/sites/host/functionKeys",
  "apiVersion": "2018-11-01",
  "name": "[concat(parameters('FUNCTIONNAME'), '/default/test-key')]",
  "properties": {
    "name": "test-key",
    "value": "test-value"
  },
  "dependsOn": [
    "[resourceId('Microsoft.Web/sites', parameters('FUNCTIONNAME'))]"
  ]
}

It looks like, that the deployment will add the host key test-key when the function is already deployed. If I deploy the template to a new resource group, the host key is not created. If I run the deployment a second time, it is.

Is there anything wrong with my dependsOn declaration? Any other ideas?

Answer 1

There are several issues with the deployment of functionkeys within ARM templates. Your code is correct and as you said, it successfully deploys sometimes. Without having deep knowledge of what really happens under the hood, here some of my (painful) learnings:

• Keys are not created before the function's content is somehow materialized (maybe it has to look if there are functions with HttpTrigger). So the behavior depends on the way the code is provided - with linked sourcecontrol (eg Github) I had the biggest problems vs. WEBSITE_RUN_FROM_PACKAGE works pretty well. When you setup sourcecontrol in ARM template too, you can add a dependsOn for the functionKeys resource like "[resourceId('Microsoft.Web/sites/sourcecontrols', 'name of function', 'web')]" . With that, I achieved that the functionkeys are deployed also on complete initial deployments

• You may have race conditions when you try to read the deployed functionKeys in the same ARM template (eg for usage in API Management). You can and should set up a dependsOn with "[resourceId('Microsoft.Web/sites/host/functionKeys', 'name of function', 'default', 'name of key')]" which may help in some situations. But I also had the situation where the key wasn't yet ready to be read and I ended up with a subsequent deployment run for this. What you can try is to chain it with some "dependsOn" settings so that it is executed as late as possible (well, this is rather a hack).

• When you don't specify a value for the function key (like test-value in your snippet), a new value is generated on every deployment. So it is not really 'incremental' as it should be IMHO. In combination with a delayed availability of the key as described above, I had the problem that I always got an old version of the key-value on subsequent deployments which was a bit painful to find out.

• If you think why not use the predefined master or default key to avoid these troubles: I often encountered the strange situation that the master and default key changed during the deployment. So again the referencing component in the ARM template got served with an obsolete value of the key.

Hope these experiences help.