Set Retention Period for App Service logs in Azure WebApp Deployment - azure

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.

Related

appsettings.json files or App Service - App Settings in Azure Portal?

I have so far used the appsettings.{environment}.json files to keep application level configuration settings. Now I encounter this tab in Azure Portal for an App Service.
What is the difference between using the appsettings.json files and "Application Settings" Tab in the Azure Portal? And which one to use When?
difference between using the appsettings.json files and "Application Settings" Tab in the Azure Portal? And which one to use When?
If you are using more than one environment like Production, Staging and Development for your application. You need specific Environment appsettings i.e., appsettings.{environment}.json.
Or if you don't want to use any specific environment. In this case you are using only production (Default) Environment you can use appsettings.json file.
Few reasons to use Azure Application Settings -
1st - Let's assume that in order to avoid leaking configurations in appsettings.json, you aren't committing it to your repo. But you also deploy your web app on Azure AppServices. In this situation Application Settings tab can help you to configure your configurations directly and then Azure will auto create appsettings.json by reading those values.
2nd - This time we are committing appsettings.json and deployed web app on Azure. We also have a property as
{
"Users": {
"CanAccessApp": [ "abc#gmail.com", "test#gmail.com" ],
"CanAccessHangfire": [ "abc#gmail.com", "test#gmail.com" ],
"CanAccessLog": [ "abc#gmail.com", "test#gmail.com" ]
}
}
Now, I also want one more user to be able to access logs. How you will do it? Generally, update in your appsettings.json and redeploy.
Or you can create similar property in Application Settings by
Users:CanAccessLog:0 -> vic#gmail.com
Users:CanAccessLog:1 -> abc#gmail.com
Users:CanAccessLog:2 -> test#gmail.com
and so on where 0,1,2 are indexes of the array (Azure style). This one will help us to test quickly without redeploying or modifying appsettings.json.

Can't deploy Azure Function app settings because fileshare returns 403

In my primary Azure region, East US 2, I have FrontDoor, a virtual network, and 4 premium function apps. These work perfectly fine but I am trying to set up the functions in a secondary region, Central US according to this diagram.
My thoughts were that I would have a second App Service Plan (EP1), a second virtual network, and a second premium function app for each of my functions. I was able to get this to mostly work but my pipeline fails when deploying the first functions app settings. The error I get is: Creation of storage file share failed with: 'The remote server returned an error: (403) Forbidden.'. Please check if the storage account is accessible.
In my main bicep file I have:
var appSettings = {
APPINSIGHTS_INSTRUMENTATIONKEY: appInsights.properties.InstrumentationKey
APPLICATIONINSIGHTS_CONNECTION_STRING: appInsights.properties.ConnectionString
WEBSITE_RUN_FROM_PACKAGE: '1'
AzureWebJobsStorage__accountName: '${storageAccount.name}'
BuyingDBCosmosURL: 'https://${cosmosAccountName}.documents.azure.com:443/'
FUNCTIONS_EXTENSION_VERSION: '~3'
FUNCTIONS_WORKER_RUNTIME: 'dotnet'
AzureWebJobsStorage: <connection string>
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: <connection string>
}
#batchSize(1)
module appServiceFunction '../modules/applications/app-service.bicep' = [for (item, i) in config.functionApps: if (deployFN || rebuildEnvironment) {
name: '${prefixAppServices}-${item.name}-fn'
params: {
appServiceKind: 'functionapp'
appServiceName: '${prefixAppServices}-${item.name}-fn'
appServicePlanId: (deployFN) ? appServicePlan.outputs.appServicePlanId : (rebuildEnvironment) ? appServicePlan.outputs.appServicePlanId : ''
appServiceAuth: item.appAuth
appServiceSiteConfig: {
healthCheckPath: '/api/${item.name}/healthCheck'
}
appServiceSettings: union({
WEBSITE_CONTENTSHARE: '${prefixAppServices}-${item.name}-fn'
}, appSettings)
ipSecurityRestrictions: fnIpSecurityRestrictions
virtualNetworkSubnetId: subnetFunction.id
location: location
tags: appTags
logAnalyticsRetention: logAnalyticsRetention
actionGroupId: (deployFN) ? actionGroup.outputs.actionGroupId : (rebuildEnvironment) ? actionGroup.outputs.actionGroupId : ''
}
dependsOn: [
cosmos
]
}]
And in a separate file where I create the resource, we use a config resource to define the app settings in key/value pairs (I also tried passing the app settings in directly to the function and received the same error):
resource appSettings 'Microsoft.Web/sites/config#2021-01-15' = if (!empty(appServiceSettings)) {
name: 'appsettings'
parent: appService
properties: appServiceSettings
}
I'm not exactly sure where the issue is as high availability and disaster recovery is new to me so I added some pictures of the configuration. Please let me know if I can add anything to this question!!
Edit: If I navigate to the storage account networking tab and change "Allow access from Selected Networks" to "Allow access from All Networks", then I am able to deploy the function apps and their app settings no problem.
Add WEBSITE_CONTENTOVERVNET=1 setting in azure function app settings and then try. This worked for me.
Few things need to check:
Storage account should be on selected network.
You should have blob, file private endpoints in the same VNET where azure function is deployed.
check DNS zone and a record for storage account pe.

Azure Bicep - Connect Azure API Management (API) to Azure Function App

I can see within the Azure Management Console, specifically within the Azure API Management Service, via the GUI you are able to use Azure Functions to form an API.
I am trying to implement the same via Azure Bicep, but I do not see any options in the Bicep documentation for API Management - API Service.
In the GUI, I see something like this:
This allows me to specify my Function App:
However, within the Bicep Documentation, I don't see anything where I would expect to: Microsoft.ApiManagement service/apis
I have instead tried using the Microsoft.ApiManagement service/backends but that doesn't give the same experience and I haven't managed to get that to work.
So my question is, how do I connect my Azure API Management service to an Azure Site (app) which is set as a suite of Azure Functions?
You need to create backend and all api definitions manually. The portal gives you a nice creator and does all those REST calls for you. With bicep (and ARM) which is operating directly on the REST endpoints of each resource provider you need to build own solution.
Perhaps there’re somewhere some existing templates that can do this but personally I didn’t see any yet.
I added OpenAPI specifications to my functionApps to produce the sawgger \ -openAPI link (or file). Then leveraged the OpenAPI file to build the APIs.
// Create APIM Service
resource apimServiceRes 'Microsoft.ApiManagement/service#2021-08-01' = {
name: 'apim service name'
location: resourceGroup().location
sku:{
capacity: 0
name: 'select a sku'
}
identity:{
type: 'SystemAssigned'
}
properties:{
publisherName: 'your info'
publisherEmail: 'your info'
}
}
// Create the API Operations with:
resource apimApisRes 'Microsoft.ApiManagement/service/apis#2021-08-01' = {
name: '${apimServiceRes.name}/name-to-represent-your-api-set'
properties: {
format: 'openapi-link'
value: 'https://link to your swagger file'
path: ''
}
}

How to associate an Azure app service with an application insights resource (new or existing) using terraform?

I looked at the documentation of both azurerm_app_service and azurerm_application_insights and I just do not see a way to tie them.
Yet on the App Service page in the portal there is a link to Application Insights, currently grayed out:
So, how do I enable it with terraform?
You need numerous app settings to get this to work properly as intended. The ones I had to add to get it all working were:
"APPINSIGHTS_INSTRUMENTATIONKEY"
"APPINSIGHTS_PROFILERFEATURE_VERSION"
"APPINSIGHTS_SNAPSHOTFEATURE_VERSION"
"APPLICATIONINSIGHTS_CONNECTION_STRING"
"ApplicationInsightsAgent_EXTENSION_VERSION"
"DiagnosticServices_EXTENSION_VERSION"
"InstrumentationEngine_EXTENSION_VERSION"
"SnapshotDebugger_EXTENSION_VERSION"
"XDT_MicrosoftApplicationInsights_BaseExtensions"
"XDT_MicrosoftApplicationInsights_Mode"
It seems that enabling application insights using Terraform is not working yet currently. There is a Feature Request: Attach azurerm_application_insights to a azurerm_app_service in Github.
It might be possible to set a tag on the azurerm_application_insights resource,
resource "azurerm_application_insights" "test" {
tags {
"hidden-link:/subscriptions/<subscription id>/resourceGroups/<rg name>/providers/Microsoft.Web/sites/<site name>": "Resource"
}
}
Usually, if you need to enable application insights component in your app service, you need to add APPINSIGHTS_* environment variables to the app_settings of your web app.
For example,
app_settings {
"APPINSIGHTS_INSTRUMENTATIONKEY" = "${azurerm_application_insights.test.instrumentation_key}"
}
See argument reference even it's about Azure function.
ref:
https://www.olivercoding.com/2018-06-24-terraform/
https://github.com/terraform-providers/terraform-provider-azurerm/issues/2457

How is secrets resolved when using environment variable reference in a Azure WebApp

I have an environment variable that references a secret in Azure KeyVault:
{
"name": "SECRET",
"value": "#Microsoft.KeyVault(SecretUri=https://keyvault_name.vault.azure.net/secrets/secret_name/)",
"slotSetting": false
}
This is loaded when on Startup.cs in my web api solution:
public void ConfigureServices(IServiceCollection services)
{
services.AddOptions<Secret>().Configure(o => o.ClearText = Configuration["SECRET"]);
services.AddControllers();
}
How is the secret resolved? Is it resolved on every option call? Eg everytime it gets injected into my constructor, or is it resolved when the environment variable is resoved and loaded into the Configuration object?
Reason why I ask is that every call to the vault costs a tiny bit, but it all adds up.
UPDATE
I have added this as an issue on github: https://github.com/MicrosoftDocs/azure-docs/issues/44064#event-2855607916
Based on my testing, Azure web app will load data from Azure key vault in two scenarios :
You submitted a Application settings modify request to Azure.
You restart your Azure Web app.
Your secret will be cached in Azure app service. You can try this scenario : After you add an environment variable that references a secret in Azure KeyVault , create a new version with different value in Azure key vault , you will found that the value in Azure web app will not change : still the old version.
It will not change until you restart your web app or modify your Application settings on portal again.
I also checked metrics of my Azure key vault, I called my Azure web app to retrieve the secret I configed in app settings for about 10 times , but the access metrics of my Azure key vault at that time point is 0. But when I restart my web app , the access metrics of Azure key vault will increase .
Hope it helps .

Resources