I am using the following command to create an azure batch pool. Please note I am using a custom image. Also please note that I have authenticated batch with Active Directory:
az batch pool create --json-file pool.json
The pool.json file looks like the following
{
"id": "WEPool004",
"vmSize": "Standard_NC6",
"virtualMachineConfiguration": {
"imageReference": {
"virtual_machine_image_id": "/subscriptions/{sub id}/resourceGroups/{resource group name}/providers/Microsoft.Compute/images/{image definition name}",
"publisher": null,
"offer": null,
"sku": null
},
"nodeAgentSKUId": "batch.node.ubuntu 18.04"
},
"targetDedicatedNodes": 1
}
Azure CLI complains with the error:
Reason: The specified resource id must be of the format /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}/versions/{galleryImageVersionName} or /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/galleries/{galleryName}/images/{galleryImageName}
Now this means that this page is outdated, since I have followed their format.
If I follow the format specified in the error, I need to make an image gallery and subsequently an image definition. If I do make those two and then replace the virtual_machine_image_id, it complains NOT on the azure CLI, but on the pools page of the azure portal, it displays the following error message:
Message:
Desired number of dedicated nodes could not be allocated
Values:
Reason - The specified image is not found
So either I encounter the error that virtual_machine_image_id is of invalid format, or it is simply not found. Hence, I can hypothesize that I am making an error while I make the image definition and image gallery. Please can anyone point to me to the correct direction.
Please note that I followed this tutorial for Azure CLI for batch.
The error I made was that I did not create a snapshot. I used the URL from the image definition created using that snapshot as specified in this tutorial. Now its working.
I have a simple ARM template that deploys two Azure Functions, an App Service Plan and a Storage Account:
The only "special" thing is, that the function function-key-issue-two adds the default host key from the function function-key-issue-one as an app setting:
"FunctionOneKey": "[listkeys(concat(variables('functionTwoAppId'), '/host/default/'),'2016-08-01').functionKeys.default]",
If I deploy this template to a new resource group, it works the first time. Every subsequent deployment fails with a Bad Request Error on the Resource function-key-issue-one/default:
This is how the operation details looks like:
{
"Code": "BadRequest",
"Message": "Encountered an error (ServiceUnavailable) from host runtime.",
"Target": null,
"Details": [
{
"Message": "Encountered an error (ServiceUnavailable) from host runtime."
},
{
"Code": "BadRequest"
},
{
"ErrorEntity": {
"Code": "BadRequest",
"Message": "Encountered an error (ServiceUnavailable) from host runtime."
}
}
],
"Innererror": null
}
If I remove the FunctionOneKey App Setting, the deployment works. Also If I don't specify the App Setting WEBSITE_RUN_FROM_PACKAGE, the deployment also works.
The function code is deployed later using the AzureFunctionApp#1 Azure DevOps Task as a Zip package (that is why I set WEBSITE_RUN_FROM_PACKAGE to 1).
How to reproduce:
The ARM template I am using is available here.
You can deploy it using. e. g. the New-AzResourceGroupDeployment cmdlet:
New-AzResourceGroupDeployment -ResourceGroupName 'function-key-issue-rg' -TemplateFile "D:\sources\issues\functionDeployment\azuredeploy.json" -name "azuredeploy-$(New-Guid)"
Update 1:
The reason for the ServiceUnavailable error is probably because Kudu adds a web.config with a rewrite rule (because I use WEBSITE_RUN_FROM_PACKAGE but don't have deployed the function):
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name = "Site Unavailable" stopProcessing = "true">
<match url = ".*" />
<action type = "CustomResponse" statusCode = "503" subStatusCode = "0" statusReason = "Site Unavailable" statusDescription = "Could not download zip" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
My next attempt was to prevent Kudu from doing this by setting
SCM_TOUCH_WEBCONFIG_AFTER_DEPLOYMENT to 0 (See: Don't touch web.config at the end of the deployment). And now it looks like, subsequent deployments sometimes succeed:
But still not a reliable solution :-/.
Update 2:
Same issue with the Azure Function Runtime ~2.
Switching the Azure Function to Linux also doesn't solve the issue.
Update 3:
I opend a GitHub issue regarding this topic.
Any idea what is wrong here? Any workarounds?
I too have had this problem deploying Function Apps and app settings with ARM templates.
After a back-and-forth with Azure support, we realised that the persistence of the app settings causes a restart of the Function App during deployment, which results in a 503 Service Unavailable while it spins back up. This happens while the deployment is still in progress, which then causes intermittent failures of the Microsoft.Web/sites/host. This is also despite the ARM deployment mode being set to incremental, which seems to be ignored completely for function app settings.
The Diagnostics Settings of the Function App will list the hard restarts for you and might give some insight into the app setting that caused it.
A suggestion was made from Azure support to separate the app settings into their own Microsoft.Web/sites/config section in the ARM template, which dependsOn the Function App having finished deployment. I've not tried this yet, and this also goes against what's in the Function App ARM examples, where they are a child config resource of a Microsoft.Web/sites.
I think you can change the way you are establishing communication between your functions, and you will also fix your issue. I would recommend you to use Azure Managed Identity to configure the communication between your functions, instead of using the function keys. Please have a look at this article to get more details of what I am saying.
first of all, i would suggest to use Azure KeyVault as a default storage for your keys, like described here.
But it seems, that this is related also some issues regarding Appservice and Package Deployments.
Take a look here: https://github.com/microsoft/azure-pipelines-tasks/issues/10961 and here: https://github.com/microsoft/azure-pipelines-tasks/issues/11444.
The documentation also says something like this:
https://learn.microsoft.com/de-de/azure/azure-functions/run-functions-from-deployment-package
Hope this is helpfull.
I had, sort of, the same problem in a template, that deployed EventGrid Topic subscribers to a Topic. Precense of the the listkey() function in the json template resulted in the same, very non-descriptive error message.
I've made it work, by updating the ARM template schema to the newest schema supported on Azure: 2019-08-01
Like this:
Top line in the file:
"$schema": "https://schema.management.azure.com/schemas/2019-08-01/deploymentParameters.json#",
and inline, in the listkeys function:
listkeys(concat(resourceId('Microsoft.Web/sites', parameters('functionAppName')), '/host/default'), '2019-08-01').functionKeys.default)
Now, several, subsequent deployments work again, at least for me.
I have had this problem recently and contacted the Azure Functions team, and what I understood from them is this: (I am using ARM Template should be same logic to all with different approaches)
1- using WEBSITE_RUN_FROM_PACKAGE = 1 must be set before deploying the Zip File, meaning adding dependency between the ZipDeploy with deploying AppSettings.
why?
if this flag is not set at first, the function would take the ZipFile and extract it to wwroot folder, leading to empty SitePackage folder and breaking the deployment and function. this flag makes the function upload a zip file to a folder in the function shared file system under data/SitePackage, with also a package.txt that has the name of the related Zip.
this flag aren't supposed to be changed back and forth, because it would break the deployment due to confusing whether it should upload the zip to SitePackages or Extract it to wwroot.
an answer i was given if turning your flag for the first time, it could happen that the first deployment fail, and you need to try again.
2- when using WEBSITE_RUN_FROM_PACAKAGE the function go through a sort of restart, that is written on the docs here you see that after deployment a restart is done.
so the step of "listKeys" could fall on a restart and leading to failure, what you need to do is Add a "wait" step for 1-2 minutes after the function deployed to be sure that everything is done.
Good Luck
I have faced pretty much the same issue. I need to feed the Azure Function which its own host key. After several different test scenarios my conclusion is that there is some delay between the Azure Function App deployment finish and the moment the Host keys are available.
My current workaround is to create previously a key in the KeyVault a use this key in two different places:
To create a new host key in the Azure Function
To feed the Azure Function appsettings
Some sample codes:
Generating Key in the KeyVault from PS
$secureSecret = ConvertTo-SecureString New-Guid.ToString() -AsPlainText -Force
Set-AzureKeyVaultSecret -VaultName $keyVaultName -Name "azure-function-key" -SecretValue $secureSecret
Create the host key and passing it to the function
Note that parameters('internalKey') would be fed from the KeyVault reference
"apiVersion": "2019-08-01",
"type": "Microsoft.Web/sites",
"kind": "functionapp",
"name": "[variables('functionAppName')]",
"location": "[variables('location')]",
"resources": [{
"dependsOn": ["[resourceId(resourceGroup().name, 'Microsoft.Web/sites', variables('functionAppName'))]"],
"type": "Microsoft.Web/sites/host/functionKeys",
"apiVersion": "2018-11-01",
"name": "[concat(variables('functionAppName'), '/default/internalkey')]",
"properties": {
"name": "internalkey",
"value": "[parameters('internalKey')]"
}
},
{
"apiVersion": "2019-08-01",
"name": "appsettings",
"type": "config",
"dependsOn": [
"[resourceId(resourceGroup().name, 'Microsoft.Web/sites', variables('functionAppName'))]"
],
"properties": {
"FUNCTIONS_EXTENSION_VERSION": "~3",
"HostFunctionKey": "[parameters('internalKey')]"
}
}]
Even in you try the listKeys approach with your new host key it won't get the value. First time it will fail and successive times it will get the previous value if it has changed.
I have an application in its own resource group in Azure that was provisioned using Azure Resource Management templates.
When I try to replace the SSL certficate by changing the pfxBlob to the base64 string of the renewed certificate .PFX file and then deploy the template everything appears to work correctly.
{
"type": "Microsoft.Web/certificates",
"name": "[variables('appService_name')]",
"apiVersion": "2016-03-01",
"location": "[parameters('resourceLocation')]",
"properties": {
"pfxBlob": "[parameters('sslCertificateData')]",
"password": "[parameters('sslCertificatePassword')]"
}
}
There are no errors, but when I check in the Azure portal, the certificate has not been updated and continues to show the details of the old certificate.
I can manually upload the certificate through the Azure portal (although it appears as a second certificate), so I'm certain there is no issue with the certificate.
Is it possible to overwrite an existing certificate using ARM templates?
I'm looking for a simple solution to Authenticate and use the WebSiteManagementClient. The examples I've seen utilize an Azure AD Application to create the SubscriptionCloudCredentials required. I would prefer to create the SubscriptionCloudCredentials without the use of an AD Application.
If at all possible, I would prefer to just use the Web Deploy un/pw credentials found in the Publish Profile Settings XML (as I already have code that uses these to interact with the kudu api with basic auth)
I found this potential solution that instead uses a management certificate (more info). But again, if at all possible, I would prefer to just use the Web Deploy un/pw.
(I understand the management cert is at a subscription level, and the Web Deploy un/pw are at a App Service/WebSite instance level. I'm just stating what my desired solution would look like.)
Management certificates allow you to authenticate only with the classic deployment (Azure Service Management) model and not the Azure Resource Management deployment model.
If your web app is not created using the classic deployment model, you'll need a TokenCloudCredential instead of the CertificateCloudCredential.
Technically, you can still create Certificate-based SubscriptionCloudCredentials but it will only work with Azure web app created with the classic deployment model.
I would prefer to just use the Web Deploy un/pw.
If you want to upload certificate to Azure WebApp during Web Deploy then we can use ARM template , more details please refer to the document.
{
"name": "[parameters('certificateName')]",
"apiVersion": "2014-04-01",
"type": "Microsoft.Web/certificates",
"location": "[resourceGroup().location]",
"properties": {
"pfxBlob": "pfx base64 blob",
"password": "some pass"
}
}
About how to create subscriptionCloudCredentials with certificate and how to create customized cert, I did a demo for it. More details please refer to another SO thread.
If we try to run the project on the Azure. Please refer to document Using Certificates in Azure Websites Applications. Adding an app setting named WEBSITE_LOAD_CERTIFICATES with its value set to the thumbprint of the certificate will make it accessible to your web application
So we also need to add the AppSetting in the ARM template, more detail info please refer to the document.
{
"name": "appsettings",
"type": "config",
"apiVersion": "2015-08-01",
"dependsOn": [
"[concat('Microsoft.Web/sites/', variables('webSiteName'))]"
],
"tags": {
"displayName": "WebAppSettings"
},
"properties": {
" WEBSITE_LOAD_CERTIFICATES ": "thumbprint "
}
I exported an Azure Resource Manager JSON template from my resource group on Azure. I see a bunch of tags in the generated file like:
"tags": {
"hidden-link:/subscriptions/[my-subscription-id-here]/resourceGroups/[my-resource-group]/providers/Microsoft.Sql/servers/[my-database-server-name]/databases/[my-database-name]": "Resource"
},
The only documentation I can find on it is from Using tags to organize your Azure resources, which says:
You may see tags that start with "hidden-" and "link:". These are internal tags, which you should ignore and avoid changing.
The problem is that I'm going to be deploying this resource template to a completely different subscription than the one whose ID is hard-coded into the tag. Any meaning that the hard-coded subscription id has in this tag will be lost. Can I safely remove this tag? What does it mean, and how is it used once deployed?
Just to help stop anyone else from wasting a couple of hours in frustration:
Don't remove these tags from your generated ARM template for web tests in Application Insights.
I was wondering if I really needed these tags since they were very specific to the resource that I used to create the template from. Reading this answer I figured that it wasn't necessary so I removed them and promptly forgot about removing them.
The deployment then started failing with the very descriptive error:
{
"code": "BadRequest",
"message": "{
"code": "BadRequest",
"message": "Bad Request\",
"innererror":
{
"diagnosticcontext": "d657bd3b-6b5f-4b24-8963-c2e9ac76a65b\",
"time": "2019-02-05T13:37:23.6473698Z"
}
}
Putting the "hidden-links" back in seems to fix the issue.
An alternative that makes the script a bit more reusable is specifying the "hidden-link" as follows:
"tags": { "[concat('hidden-link:', resourceId('Microsoft.Insights/components', parameters('appInsightsName')))]": "Resource" }
Where applicationInsightName is a variable containing the name of the ApplicationInsight instance
These tags are used to associate related resources. They are used to populate the Linked Resources section. Removing the tags will prevent resources from displaying as Linked Resources but will not impact any functionality.
Azure Resource Manager (ARM) tag is optional to an Azure Resource or an Azure Resource Group.
You can safely remove any tag without affecting your ARM deployment.