Azure bicep - App Service Plans names and tiers - azure

When working with, for example, Azure Function and bicep, the fuction needs an App Service Plan and this plan needs a sku:
resource MyHostingPlan 'Microsoft.Web/serverfarms#2021-02-01' = {
name: MyAppPlanName
location: location
sku: {
name: ?
tier: ?
}
}
resource MyFunction1 'Microsoft.Web/sites#2021-02-01' = {
name: MyAppPlanName
location: location
kind: 'functionapp'
properties: {
httpsOnly: true
serverFarmId: MyHostingPlan.id
...
There doesn't seem to be a 1 to 1 mapping between what's in https://azure.microsoft.com/en-au/pricing/details/app-service/linux/#pricing and the names of the tier and SKUs for bicep scripts. For example:
The consumption plan is "Y1"/"Dynamic"
P1v2 seem to be "sku": { "name": "P1v2", "tier": "PremiumV2" }
Neither of these two are explicitly stated in the pricing table and while for P1v2 maybe one could guess, for the consumption plan this is not obvious at all.
Q: What is correct process of finding out the strings for the name and *tier` for an App Service Plan to use in a bicep script?

Consumption is Y1,
Pxv2 is the App Service Plan (https://azure.microsoft.com/en-us/pricing/details/app-service/windows/#pricing)
EPx are the Function Premium Plans (https://azure.microsoft.com/en-us/pricing/details/functions/#pricing)
*x defines the scale of a single instance.
Best place to look this up is the Azure Portal in the Scaling Section of the Function/App Service Plan
Note: All those plans are different. While the consumption plan
provides event based auto-scale at pay-what-you-use rates, the
function premium plan offers the same but at fixed per instance prices
with additional features (e.g. network integration, no-warmup time,
etc). The App Service Plan is different than those two plans. No
event-based autoscaling but is great if you have functions and unused
capacity at an existing plan.

Related

Why does my BICEP template, fail to create authorization rules consistently?

I've created a bicep template for deploying the Azure Service Bus which includes creation of multiple topics, subscriptions, filters, and authorisation rules.
I'm attempting to deploy 24 authorisation rules in a serial for loop after the rest of the servicebus has been created. The first time deployment will always fail with one or two authorisation rules returning with the error MessagingGatewayTooManyRequests or AuthorizationRuleNotFound. A subsequent deployment will always work as expected.
I have tried only using a template that only deploys authorisation rules, and have run into the same problem. The first 18 rules were created almost instantly, then after that they start to show as duplicated in the azure portal and fail.
I have found that I can get closer to my goal by splitting up the policies into multiple dependent deployments, which does slow down the request speed due to the physical overhead from creating a new deployment. I'd rather create a pure solution that is low effort, easy to maintain, and doesn't abuse the limitations of ARM deployments in order to succeed.
Please see the cut down version of my module below;
#description('The namespace of the servicebus resource')
param namespace string = 'myservicebus'
#description('An array of shared access policy configurations for service bus topics')
param sharedAccessPolicies array = [
{
topicName: 'mytopic'
policyName: 'listen-policy'
policyRights: ['Listen']
secretName: 'sb-mytopic-listen'
}
{
topicName: 'mytopic'
policyName: 'send-policy'
policyRights: ['Send']
secretName: 'sb-mytopic-send'
}
]
#batchSize(1)
resource topic_auth_rule 'Microsoft.ServiceBus/namespaces/topics/authorizationRules#2021-11-01' = [for policy in sharedAccessPolicies: {
name: '${namespace}/${policy.topicName}/${policy.policyName}'
properties: {
rights: policy.policyRights
}
}]
I've found a similar post around this issue which is what lead to my current solution. Although I don't understand why this single API endpoint is so aggressively rate limited.
Any advice on this would be much appreciated.
The above code in my question now works as expected. I spent the past month talking to multiple levels of Microsoft support, I managed to get in touch with the ARM team who looked into and resolved the problem.
The alternative solution which I was suggested was to individually register each resource and create a huge dependency chain, see example below.
resource topic_auth_rule_listen 'Microsoft.ServiceBus/namespaces/topics/authorizationRules#2021-11-01' = {
name: '${namespace}/mytopic/listen-policy'
properties: {
rights: [ 'Listen' ]
}
}
resource topic_auth_rule_send 'Microsoft.ServiceBus/namespaces/topics/authorizationRules#2021-11-01' = {
name: '${namespace}/mytopic/send-policy'
properties: {
rights: [ 'Send' ]
}
dependsOn: [ topic_auth_rule_listen ]
}
...

How to change OS disk SKU for Virtual Machine Scale Set (VMSS)?

I create Azure Kubernetes Service by Bicep like below.
param clusterName string = 'kubernetes'
param location string = resourceGroup().location
resource aksCluster 'Microsoft.ContainerService/managedClusters#2022-02-01' = {
name: clusterName
location: location
sku: {
name: 'Basic'
tier: 'Free'
}
identity: {
type: 'SystemAssigned'
}
properties: {
kubernetesVersion: '1.23.5'
enableRBAC: true
agentPoolProfiles: [
{
name: 'agentpool'
mode: 'System'
type:'VirtualMachineScaleSets'
orchestratorVersion: '1.23.5'
enableAutoScaling: false
enableFIPS: false
maxPods: 110
count: 1
vmSize: 'Standard_B2s'
osType:'Linux'
osSKU:'Ubuntu'
osDiskType: 'Managed'
osDiskSizeGB: 0
enableUltraSSD: false
enableNodePublicIP: false
}
]
dnsPrefix: 'kubernetes-cluster-dns'
networkProfile: {
loadBalancerSku: 'basic'
networkPlugin: 'kubenet'
}
}
}
Azure Kubernetes Service (AKS) create Virtual Machine Scale Set like below.
I do not want to use Premium SSD LRS OS disk. It is too expensive for me while learning kubernetes. I want to change it to Standard SSD LRS.
What should I do?
2022.05.30 Update
I create an issue at Azure/bicep.
• Once an Azure resource is deployed, you cannot change its inherent hardware, i.e., disk storage, compute, and memory. Thus, as you have already deployed an AKS cluster with Linux VMs in ‘Standard_B2S’ format and not mentioned any configuration related to the type of disk storage to be used along with it, it usually goes with the default/top option available according to the Azure portal and underlying service fabric infrastructure.
Also, even if you check while creating a VM or VMSS in Azure, the first option for selecting the type of OS disk storage is always ‘Premium SSD (locally redundant storage)’ in the portal as shown below. Thus, due to which, you should have mentioned the ‘DiskSku: StandardSSD_LRS’ in your bicep template for you to deploy the AKS cluster VMs with standard HDDs.
Thus, now if you want to change the disk type after deploying the resources, it is not possible and you would need to redeploy the AKS cluster VMs for the disk type to be changed.
For more information, kindly refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/templates/microsoft.compute/disks?tabs=bicep#disksku

Set Retention Period for App Service logs in Azure WebApp Deployment

I am deploying a Azure WebService (Linux Container) with az CLI and Biceps files. Below is an excerpt from my logging configuration.
resource appConfigLogs 'Microsoft.Web/sites/config#2021-02-01' = {
name: 'logs'
parent: app
properties: {
detailedErrorMessages: {
enabled: true
}
failedRequestsTracing: {
enabled: true
}
httpLogs: {
fileSystem: {
enabled: true
retentionInDays: 7
retentionInMb: 50
}
}
}
}
To my understanding the setting "retentionInDays" corresponds to "Retention Period (Days)" which can be found in the Azure Portal in the WebApp Resource > "Monitoring" > "App Service logs".
When setting via Portal, the App Services Configuration gets updated with an Application setting called "WEBSEITE_HTTPLOGGING_RETENTION_DAYS" set to the respective value.
When setting via ARM Deplyment (see Biceps above), there is no Configuration value set. Is this a bug or do these two settings "retentionInDays" / "Retention Period (Days)" simply not correlate with each other?
When setting via ARM Deployment (see Biceps above), there is no Configuration value set. Is this a bug or do these two settings "retentionInDays" / "Retention Period (Days)" simply not correlate with each other?
This is not a bug."retentionInDays" / "Retention Period (Days)" are not two individual settings. In ARM template configuration in order to use retention period to store logs for a period of time we use this parameter retentionInDays same parameter will be displayed in the portal as RententionPeriod(Days)
We have written an ARM template & tested in our local environment which is working fine.This template will create web app, storage account, enabling app service logs & the application setting WEBSEITE_HTTPLOGGING_RETENTION_DAYS as well as shown below.
You can refer this blogpost for more information about configuring app server logs to a storage account using ARM template.

Azure Service Plan - Convert Consumption App to Premium App

Title basically says it all. I have a function app on a consumption plan that I need to put onto a P2V2. Is it possible to convert the consumption plan or do I need to just redeploy to a new resource group?
Try this:
Create new AppService plan
Open CloudShell (PowerShell)
Run commands
Select-AzureRmSubscription -SubscriptionId "[id]"
Set-AzureRmWebApp -Name "[function name]" -ResourceGroupName "[resource group]" -AppServicePlan "[new app service plan name]"
source: https://github.com/Azure/Azure-Functions/issues/155#issuecomment-619980271
To do vice-versa, move functions from App Service plan to a Consumption Plan, Use the Azure Resource Explorer:
Source: https://www.gitmemory.com/issue/Azure/Azure-Functions/155/747559677
I was able to move back my Function from App Service Plan to Consumption plan by using the https://resources.azure.com/ website.
Enter edit mode, find your Function App and change the following:
{
serverFarmId: "..../<your-consumption-app-service-name>"
...
// Scroll a bit down
sku: "Dynamic"
}
Update the resource and you are done.
Make sure that you turn Always On off in the App Service Plan settings before the resource update to make this work.
Great question MrRobot. Unfortunately, there is no official way to move your consumption based Function App into a dedicated App Service Plan (Basic, Standard, P2v2, etc.). You will have to redeploy your settings into a new Function App that was created using the dedicated hardware.
Please let me know if you have any further questions or concerns.
Edit: To add additional clarity, I'd suggest looking at this for information on how to easily copy your Function App.
Also, switching is available to some customers but the number of customer is so small due to the requirement that your app was deployed to a web space that supports P2v2, which again is a small group. For an example on switching, check here. If you're unable to create a P2v2 Function App in the resource group of your consumption based Function App, you are not likely eligible to use this solution and would need to manually deploy to a dedicated function app.

Move to another subscription: Cannot move resources because some site(s) are hosted by other resource group(s) but located in resource group 'XXX'

I have resource group "MyResources", that contains 4 resources:
AppService - myserver,
AppServicePlan - MyServerWestEuFarm,
ApplicationInsights - myserver-insights,
StoregeAccount - myserverstorage
When I try to move them to another subscription, I get error message:
Cannot move resources because some site(s) are hosted by other resource group(s) but located in resource group 'MyResources'. The list of sites and corresponding hosting resource groups: myserver:vyvojari.sk'. This may be a result of prior move operations. Move the site(s) back to respective hosting resource groups and try again. (Code: BadRequest, Target: Microsoft.Web/serverFarms)
What does that mean? Especially myserver:vyvojari.sk is confusing.
"vyvojari.sk" is another resource group and it may be possible that I've created myserver appservice in that resource group in the past and moved. So what?
In the resource explorer for the myserver AppService I see:
{
"id": "/subscriptions/xxxxxxxx-d9e0-4769-8440-8cd7968bf94d/resourceGroups/MyResources/providers/Microsoft.Web/sites/myserver",
"name": "myserver",
"type": "Microsoft.Web/sites",
"kind": "app",
"location": "West Europe",
"properties": {
"name": "myserver",
"state": "Running",
"hostNames": [
"myserver.azurewebsites.net"
],
"webSpace": "vyvojari.sk-WestEuropewebspace",
"selfLink": "https://waws-prod-am2-071.api.azurewebsites.windows.net/subscriptions/xxxxxxxx-d9e0-4769-8440-8cd7968bf94d/webspaces/vyvojari.sk-WestEuropewebspace/site/myserver",
"repositorySiteName": "myserver",
But what is webspace and selflink? How can I change it?
This may be too obvious but I think, they want you to move back the 'myserver' resource to the 'vyvojari.sk' resource group. Once that is done, do the subscription operation.
It is possible that although, myserver is in the current resource (you have said that you may have moved it here) is still 'hosted' in that vyvojari resource group despite being part of the current group. By this logic, looks like moving it back to vyvojari should allow you do your subscription related task.
You need to consider the following limitations when moving the App Services to another Resource Group/Subscription.
When working with App Service apps, you cannot move only an App Service plan. To move App Service apps, your options are:
Move the App Service plan and all other App Service resources in that
resource group to a new resource group that does not already have App
Service resources. This requirement means you must move even the App
Service resources that are not associated with the App Service plan.
Move the apps to a different resource group, but keep all App Service
plans in the original resource group.
The App Service plan does not need to reside in the same resource group as the app for the app to function correctly.
For more details about limitations, refer to this documentation. You will be able to move the resources only if all the requirements/conditions are met.
You should have moved the resources back to original resource group (as per the error, myResources), migrate to different subscription, and than re-segment them into respected resource groups, as needed.

Resources