I'm having a heck of a time trying to deploy a simple Azure BlobFS linked service into an ADF using Bicep (which I have only really started to learn).
The bicep I have thus far is:
//---Data Factory
resource datafactory 'Microsoft.DataFactory/factories#2018-06-01' = {
name: adf_name
location: loc_name
identity: {
type: 'SystemAssigned'
}
properties: {
globalParameters: {}
publicNetworkAccess: 'Enabled'
}
}
//--- Data Factory Linked Service
resource adls_linked_service 'Microsoft.DataFactory/factories/linkedservices#2018-06-01' = {
name: 'ls_adf_to_adls'
parent: datafactory
properties: {
annotations: []
connectVia: {
parameters: {}
referenceName: 'AutoResolveIntegrationRuntime'
type: 'IntegrationRuntimeReference'
}
description: 'linked_service_for_adls'
parameters: {}
type: 'AzureBlobFS'
typeProperties: {
accountKey: datafactory.identity.principalId
azureCloudType: 'AzurePublic'
credential: {
referenceName: 'string'
type: 'CredentialReference'
}
servicePrincipalCredentialType: 'SecureString'
servicePrincipalId: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
servicePrincipalKey: {
type: 'SecureString'
value: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
}
tenant: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
url: bicepstorage.properties.primaryEndpoints.blob
}
}
}
The ADF resource deploys fine by itself as does the ADLS (symbolic name is: bicepstorage). The issue is when I added the linkedservice resource block. I get:
New-AzResourceGroupDeployment: /home/vsts/work/1/s/psh/deploy_main.ps1:12
Line |
12 | New-AzResourceGroupDeployment `
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 22:46:27 - The deployment 'main' failed with error(s). Showing 1 out of
| 1 error(s). Status Message: Input is malformed. Reason: Could not get
| integration runtime details for AutoResolveIntegrationRuntime
| (Code:InputIsMalformedDetailed) CorrelationId:
| f77ef878-5314-46ea-9de6-65807845a104
The only integration runtime in the ADF is the 'AutoResolveIntegrationRuntime'. When I inspect it in the portal it's green, running and healthy.
I'm using task: AzurePowerShell#5 on ubuntu-latest in ADF, but I get the same error when I try to deploy the template directly from vscode.
I'm out of ideas and would really appreciate some assistance. I found the documentation for the 'connectVia' block (actually all the documentation on bicep linked services!) to be really confusing; if anyone could tell me exactly what is supposed to go in there, I'd really appreciate it.
Thanks.
As mentioned in this documentation, If you want to create a linked service to adls(blobfs) with default Azure IR (autoresolveintegrationruntime) then you can remove the ConnectionVia property in linked service block in your bicep template.
To test this I have created a bicep template which will deploy adlsgen2 storage account, data factory and a linked service to it using the service principal based authentication.
Here is the sample template for your reference:
param location string='westus'
//---Data Factory
resource storage 'Microsoft.Storage/storageAccounts#2022-09-01'={
name:'<storageAccountName>'
location:location
kind:'StorageV2'
sku:{
name:'Standard_GRS'
}
properties:{
accessTier:'Hot'
supportsHttpsTrafficOnly:true
isHnsEnabled:true
}
}
resource datafactory 'Microsoft.DataFactory/factories#2018-06-01' = {
name: '<AdfName>'
location: location
identity: {
type: 'SystemAssigned'
}
properties: {
globalParameters: {}
publicNetworkAccess: 'Enabled'
}
}
//--- Data Factory Linked Service
resource adls_linked_service 'Microsoft.DataFactory/factories/linkedservices#2018-06-01' = {
name: '<linkedserviceName>'
parent: datafactory
properties: {
annotations: []
description: 'linked_service_for_adls'
parameters: {}
type: 'AzureBlobFS'
typeProperties: {
url: storage.properties.primaryEndpoints.dfs
//encryptedCredential:storage.listKeys(storage.id).keys[0].value
servicePrincipalCredential: {
type: 'SecureString'
value: '<serviceprincipalKey>'
}
servicePrincipalId:'<serviceprincipalappId>'
servicePrincipalCredentialType:'ServicePrincipalKey'
azureCloudType:'AzurePublic'
servicePrincipalKey: {
type: 'SecureString'
value: '<serviceprincipalKey>'
}
tenant: '<tenantId>'
}
}
}
I'm a contractor working on an existing Azure project. Currently, my client is manually configuring all their Azure resources for each environment (Dev, QA, Prod). I know this is shocking to people, but their subscriptions are a mess. I'm trying to setup IaC deployments using bicep.
For the Azure App Services, they have an IP Access Restriction setup to only allow traffic from their APIM instance. When I look at the access restrictions for the app service (under networking) for the main site, I can see it listed.
However, when I deploy using --what-if, it comes back saying it will create the access restriction rule. I'm not expecting this because it should already exist. I've searched high and low but can't find the answer.
apiAppService.bicep
#description('The name of the target app service without any prefix or suffix. i.e. Contoso')
param apiName string
#description('The abbreviation of the target environment. i.e. dev')
#allowed([
'dev'
'qa'
'prod'
])
param environment string
#description('The Azure region the resource group is to be created in.')
param region string
#description('The abbreviation of the Azure region included as part of the resource group name. i.e. NCUS')
param regionAbbreviation string
#description('The properties of the SKU for the app service plan.')
param appServicePlanSku object
#description('The runtime stack of the target app service. i.e. DOTNETCORE|6.0')
param runtimeStack string
#description('The values required to setup the IP access restriction')
param ipRestriction object
var appServicePlanName = 'ASP-${apiName}-${regionAbbreviation}-${environment}'
var appServiceName = 'productname-${apiName}-api-${environment}'
resource appServicePlan 'Microsoft.Web/serverfarms#2022-03-01' = {
name: appServicePlanName
location: region
sku: {
name: appServicePlanSku.name
tier: appServicePlanSku.tier
}
kind: 'linux'
properties: {
reserved: true
}
}
resource appService 'Microsoft.Web/sites#2022-03-01' = {
name: appServiceName
location: region
identity: {
type: 'SystemAssigned'
}
properties: {
serverFarmId: appServicePlan.id
httpsOnly: true
siteConfig: {
linuxFxVersion: runtimeStack
ipSecurityRestrictions: [
{
name: ipRestriction.name
action: ipRestriction.action
priority: ipRestriction.priority
ipAddress: ipRestriction.ipAddress
}
]
}
}
}
The results of the --what-if deployment
~ Microsoft.Web/sites/productname-apiname-api-dev [2022-03-01]
+ properties.siteConfig.ipSecurityRestrictions: [
0:
action: "allow"
ipAddress: "a.b.c.d/32"
name: "Allow ONLY APIM"
priority: 300
]
+ properties.siteConfig.localMySqlEnabled: false
~ properties.httpsOnly: false => true
Am I trying to configure different things? What am I doing wrong?
Using Azure Resource Explorer proved to be very helpful. Check it out if you haven't and you're building bicep files. The IP restrictions are actually in a resource with a path 'config/web' off the app service resource. Essentially the definition looks like
resource webConfig 'Microsoft.Web/sites/config#2022-03-01' = {
name: 'web'
parent: appService
properties: {
linuxFxVersion: runtimeStack
ipSecurityRestrictions: [
{
name: ipRestriction.name
action: ipRestriction.action
priority: ipRestriction.priority
ipAddress: ipRestriction.ipAddress
}
{
name: 'Deny all'
description: 'Deny all access'
action: 'Deny'
priority: 2147483647
ipAddress: 'Any'
}
]
}
}
The name: 'web' and parent: appService is very important as is the default deny all rule at the end.
I'm trying to create a simple App Service Plan with the below code.
param Location string = 'eastus'
resource appServicePlan1 'Microsoft.Web/serverfarms#2020-12-01' = {
name: 'myasp'
location: Location
sku: {
name: 'S1'
capacity: 1
}
}
Below is the Azure CLI command that I'm using to execute the above Bicep script
az deployment group create --name deploy1 --resource-group az-devops-eus-dev-rg1 --template-file main.bicep
Below is the screenshot
All this was working earlier. I'm using the latest version of Bicep (v0.9.1) which is available as of today.
Any pointers on why this is occurring now would be much appreciated.
Just had this issue in a MS workshop. We solved it by adding a empty properties-element to the appServicePlan. Ex.
param Location string = 'eastus'
resource appServicePlan1 'Microsoft.Web/serverfarms#2020-12-01' = {
name: 'myasp'
location: Location
properties: {}
sku: {
name: 'S1'
capacity: 1
}
}
I'm trying to create App Service Plan using Bicep. I've created a full blown bicep script for the development infra and it is working fine. But for production when I'm executing the app Service plan module, I'm receiving the below error. I've almost spent a day for troubleshooting this issue. The module was also having bicep for deploying and configuring App Services. But for troubleshooting I've removed it. Kindly help me in identifying this issue.
Main file
#allowed([
'aladdin'
])
#description('Environment Name')
param environmentPrefix string
#allowed([
'uat'
'prod'
])
#description('Environment Type')
param environmentType string
#allowed([
'P1V3'
'P2V3'
])
#description('App Services Plan SKU')
param appServicePlanSku string
var appRgName = 'rg-${environmentPrefix}-${environmentType}-ne-app01'
var appServicePlanName = 'asp-${environmentPrefix}-${environmentType}-ne-app01'
resource appResourceGroup 'Microsoft.Resources/resourceGroups#2021-04-01' = {
name: appRgName
location: location
tags: {
environmentType: environmentType
environmentPrefix: environmentPrefix
role: 'Azure PAAS resources'
}
}
module appServicePlan 'appServicePlan.bicep' = {
scope: appResourceGroup
name: 'appServicePlanModule'
params: {
appServicePlanName: appServicePlanName
appServicePlanSku: appServicePlanSku
location: location
}
}
Module
param appServicePlanSku string
param appServicePlanName string
param location string
resource appServicePlan 'Microsoft.Web/serverfarms#2022-03-01' = {
name: appServicePlanName
location: location
sku: {
name: appServicePlanSku
capacity: 1
}
kind: 'windows'
}
Execucted using PowerShell
New-AzSubscriptionDeployment `
-Name Production `
-Location northeurope `
-TemplateParameterFile "$biceptemplate\main.parameters.json" `
-TemplateFile "$biceptemplate\main.bicep" `
-environmentPrefix 'aladdin' `
-verbose
Error: Code=InvalidTemplateDeployment; Message=The template deployment 'Production' is not valid according to the validation procedure. The tracking id is ....
Try this for your module:
param appServicePlanSku string
param appServicePlanName string
param location string
resource appServicePlan 'Microsoft.Web/serverfarms#2022-03-01' = {
name: appServicePlanName
location: location
sku: {
name: appServicePlanSku
capacity: 1
}
kind: 'windows'
properties: {}
}
Supplying an empty properties object on the resource. It shouldn't be required but seems like it is in this case and bicep didn't flag it. (issue here)
I'm trying to deploy a .NET Core 3.1 Azure App Service on Linux using a Bicep template from Azure CLI. The app service and corresponding app service plan are deployed correctly but the app service stack settings are empty on the Azure portal and I have to set these manually. I tried setting the metadata property on the 'Microsoft.Web/sites' resource and also on the 'Microsoft.Web/sites/config' resource, but the result was the same.
This is my app service plan:
resource appServicePlan 'Microsoft.Web/serverfarms#2021-02-01' = {
name: 'MyAppService'
location: resourceGroup().location
properties: {
reserved: true
}
sku: {
name: 'P1v2'
}
kind: 'linux'
}
Here is my first attempt to set the stack using 'Microsoft.Web/sites' as suggested here:
https://github.com/Azure/bicep/issues/3314
resource appService 'Microsoft.Web/sites#2021-02-01' = {
name: 'MyApp'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
kind: 'app'
properties: {
enabled: true
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: 'dotnet|3.1'
appCommandLine: 'dotnet MyApp.dll'
metadata: [
{
name: 'CURRENT_STACK'
value: 'dotnetcore'
}
]
}
}
}
Here is my second attempt to set the stack using 'Microsoft.Web/sites/config' as suggested here:
Bicep - How to config Runtime Stack to Azure App Service (Bicep version 0.4)
resource appService 'Microsoft.Web/sites#2021-02-01' = {
name: 'MyApp'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
kind: 'app'
properties: {
enabled: true
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: 'dotnet|3.1'
appCommandLine: 'dotnet MyApp.dll'
}
}
resource webConfig 'config' = {
name: 'web'
properties: {
metadata: [
{
name: 'CURRENT_STACK'
value: 'dotnetcore'
}
]
}
}
}
The result is the same. The deployment is completed with the following warning:
Warning BCP037: The property "metadata" is not allowed on objects of
type "SiteConfig". Permissible properties include
"acrUseManagedIdentityCreds", "acrUserManagedIdentityID", "alwaysOn",
"apiDefinition", "apiManagementConfig", "autoHealEnabled",
"autoHealRules", "autoSwapSlotName", "azureStorageAccounts",
"connectionStrings", "cors", "defaultDocuments",
"detailedErrorLoggingEnabled", "documentRoot", "experiments",
"ftpsState", "functionAppScaleLimit",
"functionsRuntimeScaleMonitoringEnabled", "handlerMappings",
"healthCheckPath", "http20Enabled", "httpLoggingEnabled",
"ipSecurityRestrictions", "javaContainer", "javaContainerVersion",
"javaVersion", "keyVaultReferenceIdentity", "limits", "loadBalancing",
"localMySqlEnabled", "logsDirectorySizeLimit", "managedPipelineMode",
"managedServiceIdentityId", "minimumElasticInstanceCount",
"minTlsVersion", "netFrameworkVersion", "nodeVersion",
"numberOfWorkers", "phpVersion", "powerShellVersion",
"preWarmedInstanceCount", "publicNetworkAccess", "publishingUsername",
"push", "pythonVersion", "remoteDebuggingEnabled",
"remoteDebuggingVersion", "requestTracingEnabled",
"requestTracingExpirationTime", "scmIpSecurityRestrictions",
"scmIpSecurityRestrictionsUseMain", "scmMinTlsVersion", "scmType",
"tracingOptions", "use32BitWorkerProcess", "virtualApplications",
"vnetName", "vnetPrivatePortsCount", "vnetRouteAllEnabled",
"websiteTimeZone", "webSocketsEnabled", "windowsFxVersion",
"xManagedServiceIdentityId". If this is an inaccuracy in the
documentation, please report it to the Bicep Team.
[https://aka.ms/bicep-type-issues]
The resources are deployed, but the app service stack setting is blank and I have to set it manually to make it work.
I know that in the ARM template this is set on the CURRENT_STACK property of the Microsoft.Web/sites/config metadata (as suggested here https://cloudstep.io/2020/11/18/undocumented-arm-oddities-net-core-app-services/). However, this doesn't seem to be supported (yet) in Bicep. If anyone has found a working solution, please post it here.
Thanks.
The Metadata parameter is not available anymore in the SiteConfig. The stack setting can be mentioned LinuxFxVersion.
So, solution will be Instead of using dotnet|3.1 , You should use DOTNETCORE|3.1.The over all code will be as below:
resource appServicePlan 'Microsoft.Web/serverfarms#2021-02-01' = {
name: 'MyAppService'
location: resourceGroup().location
properties: {
reserved: true
}
sku: {
name: 'P1v2'
}
kind: 'linux'
}
resource appService 'Microsoft.Web/sites#2021-02-01' = {
name: 'anumantestapp'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
kind: 'app'
properties: {
enabled: true
serverFarmId: appServicePlan.id
siteConfig: {
linuxFxVersion: 'DOTNETCORE|3.1'
appCommandLine: 'dotnet MyApp.dll'
}
}
}
Ouptut: