We are using an ARM json template which has this:
"outputs": {
"gatewayurl": {
"type": "string",
"value": "[reference('Microsoft.ApiManagement/service/uat1api'), '2018-01-01', 'Full').properties.gatewayUrl]"
}
What exactly is Microsoft.ApiManagement/service/uat1api ?
How can I go into Microsoft.ApiManagement/service/uat1api and view the properties?
I can see that the value ends up being https://uat1api.azure-api.net/, but I'd like to go in and see where that value is coming from.
Microsoft.ApiManagement/service is the resource type while uat1api is the name of the resource (in your case, in API Management Service).
Properties are specific to each resource type and defined in a template reference (link below for API Management Service).
Another great resource is the Azure resource explorer. Not all properties are documented in template reference while the resource explorer seems to provide a more accurate visibility on properties available on each resources.
Microsoft.ApiManagement service template reference
Azure Resource Explorer
Related
How to set legal hold on Azure storage account container in ARM template?
When setting immutable blob storage policy Azure portal allows you to choose from legal hold and Time-base retention. According to doc arm template supports immutable blob storage. However only requests with immutabilityPeriodSinceCreationInDays are accepted. When trying without setting it, I am getting:
Missing at least one of the following properties 'immutabilityPeriodSinceCreationInDays,allowProtectedAppendWrites'
Or:
immutabilityPeriodSinceCreationInDays must be set before setting allowProtectedAppendWrites
Weirdest - without properties block in immutabilityPolicies (as below) request fails with InternalServerError:
{
"status": "Failed",
"error": {
"code": "UnexpectedException",
"message": "The server was unable to complete your request."
}
}
{
"name": "testsa/default/testcontainer/default",
"type": "Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies",
"apiVersion": "2019-06-01"
// ,
// "properties": {
// // "immutabilityPeriodSinceCreationInDays" : 10,
// // "allowProtectedAppendWrites": false
// }
}
According to my research, the resource type Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies just can be used to create time-based retention policies. Meanwhile, when creating time-based retention policies, the parameter immutabilityPeriodSinceCreationInDays is required. For more details, please refer to here and here.
Besides, at the moment, Azure ARM template does not provide any resource type to create set legal hold policy. For more details, please refer to here and here. So I suggest you use deployment scripts in template to implement tit.
I am trying to deploy my logic app to multiple environments using CI/CD pipeline. I am getting an error -The client 'guid' with object id ''guid' ' has permission to perform action 'Microsoft.Logic/workflows/write' on scope 'Test Resource group'; however, it does not have permission to perform action 'Microsoft.Logic/integrationAccounts/join/action' on the linked scope(s) 'Development Resource group integration account' or the linked scope(s) are invalid.
Creating another integration account for test resource group doesnt come under free tier. Is there a way to share integration account across multiple resource groups
Not sure what the permissions issue is but you might need to give more information around this.
But try the below first in your pipeline. Works for us with 3 different resource groups and two integration accounts
"parameters": {
"IntegrationAccountName": {
"type": "string",
"minLength": 1,
"defaultValue": "inter-account-name"
},
"Environment": {
"type": "string",
"minLength": 1,
"defaultValue": "dev"
}
},
"variables": {
"resourceGroupName": "[if(equals(parameters('Environment'), 'prd'),'rg-resources-production','rg-resources-staging')]",
"LogicAppIntegrationAccount": "[concat('/subscriptions/3fxxx4de-xxxx-xxxx-xxxx-88ccxxxfbab4/resourceGroups/',variables('resourceGroupName'),'/providers/Microsoft.Logic/integrationAccounts/',parameters('IntegrationAccount'))]",
},
In the above sample, we had two different integration accounts one for testing and one for production. This is why I have set the integration account name as a parameter as it changes between environments.
I have created a variable "resourceGroupName" this is important because this url is setting up a direct link to the integration account which is stored in a known resource group. In this sample I have included an if statement using the value set at the "environment" parameter. This helps select which resource group is going to be used.
I then create another variable which stores the new URL. Replace the subscription guid with your own: 3fxxx4de-xxxx-xxxx-xxxx-88ccxxxfbab4.
Once that is created you need to change the ARM template to use the variable you just created. To set it,place in the properties object.
"properties": {
"state": "Enabled",
"integrationAccount": {
"id": "[variables('LogicAppIntegrationAccount')]"
},
So for you pipeline it should just be a normal arm template but with these two parameters above being set.
Let me know if you have more questions around this.
Assume we have a Checkpoint Firewall Template created on Azure Portal. Is there a way to test the Template within Azure? Also if the Template is modified, is there a way to Test that new modified Template within Azure?
You can test an ARM Template by using it in a deployment. You can also use the what-if setting to produce hypothetical output without actually deploying anything.
Microsoft Azure Docs for What-If
To create a What-If deployment you can proceed a number of ways; Azure CLI, PowerShell, REST, etc. Here is an example using REST (Postman).
Use the endpoint
POST https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Resources/deployments/{deploymentName}/whatIf?api-version=2020-06-01
Provide a body payload:
{
"location": "westus2",
"properties": {
"mode": "Incremental",
"parameters": {},
"template": {}
}
}
Add your template and parameters. Supply a bearer token for authentication and deploy.
You can check the Azure What-If REST API docs here.
I have an Azure Resource Manager template to spin up a storage account, and its name is being set using a parameter, like this:
"resources": [
{
"name": "[parameters('storageAccountName')]",
"type": "Microsoft.Storage/storageAccounts",
I want to output details of the resource, but can't see a way of referencing the storage account, as most examples I can find reference the resource by name.
I've tried this:
"outputs": {
"storageKey": {
"type": "string",
"value": "[reference([parameters('storageAccountName')])]"
}
}
But get the error message:
The template output 'storageKey' at line '49' and column '23' is not valid:
Unable to parse language expression 'reference([parameters('storageAccountName')])': expected token 'Identifier' and actual 'LeftSquareBracket'
So how do I reference the resource if its name is set using a parameters.json file?
just to add to existing answer (which is fine, but incomplete). a better way of doing this is using the resourceId() function:
reference(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), 'api-version-goes-here')
there are several reason for that.
this is a universal way of referencing a resource. you can reference a resource in another resource group\another subscription using this method (and not only resources in the same deployment). you can drop 'api-version-goes-here' for resources in the same deployment
the existing answer will fail if you have 2 or more resources of different type but having the same name (say storage account and virtual machine), because it wont be able to determine which resource you are targeting
ps. same goes for dependsOn, you can get away with just the name, but I find its always better\more reliable to use resourceId(), especially in big\complicated templates.
I figured it out. The internal square brackets were unnecessary:
"storageKey": {
"type": "Object",
"value": "[reference(parameters('storageAccountName'))]"
}
works.
Use of resourceId() is recommended.
Check MS documentation:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-functions-resource#resourceid
It returns the unique identifier of a resource. You use this function when the resource name is ambiguous or not provisioned within the same template.
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.