I am using Bicep to create an Automation Account, Blob storage, uploading a file to Blob, and then creating a Runbook inside my Automation Account. This works the first time, but if i update the file that goes into my blob, this isnt reflected in my runbook.
Here is a copy of my runbook deployment - is it possible the publish link URI gets cached and it doesn't 'refetch' the script content?
resource symbolicname 'Microsoft.Automation/automationAccounts/runbooks#2022-08-08' = {
name: 'Schedule Summary Table Rebuild'
location: automationAccount.location
tags: _tags
dependsOn: [deploymentScript]
parent: automationAcc
properties: {
description: 'Automation to recreate summary tables.'
logActivityTrace: 0
logProgress: true
logVerbose: true
runbookType: 'PowerShell7'
publishContentLink: {
uri:'https://storageacc.blob.core.windows.net/data/ExecuteSQL.txt'
version:'1.0.0.0'
}
}
}```
When you redeploy the template, nothing has changed so I'm guessing the ARM API doesn't even try to resubmit the deployment to the resource provider.
You could add a parameter to try to force the update:
param forceUpdate string = newGuid()
...
resource symbolicname 'Microsoft.Automation/automationAccounts/runbooks#2022-08-08' = {
name: 'Schedule Summary Table Rebuild'
location: automationAccount.location
tags: _tags
dependsOn: [ deploymentScript ]
parent: automationAcc
properties: {
description: 'Automation to recreate summary tables.'
logActivityTrace: 0
logProgress: true
logVerbose: true
runbookType: 'PowerShell7'
publishContentLink: {
uri: 'https://storageacc.blob.core.windows.net/data/ExecuteSQL.txt?forceUpdate=${forceUpdate}'
version: '1.0.0.0'
}
}
}
...
Related
I have tried numerous methods and the workflow is still deployed enabled.
My latest attempt was to use the resource in my bicep:
resource workflow 'Microsoft.Web/sites/workflows#2015-08-01' = {
name: workflowName
dependsOn: [ logicContainer ]
location: location
kind: 'Stateful'
properties: {
flowstate: 2
}
}
However, the workflow never appears in the Logic App function.
I cannot even deploy the container in the 'Stopped' state, since for Microsoft.Web/sites#2022-03-01, state is readonly.
In my yaml I send a the workflows in a pipe separated string e.g. "wf-one|wf-two|wf-three|wf-four"
Then, in my bicep I populate an array of Workflow states app settings:
var wfAppSettingStatuses = [ for wf in split(workflows,'|'): {
name: 'Workflows.${wf}.FlowState'
value: 'Disabled'
}]
To add to the Logic App container configuration settings use the union function:
resource logicContainer 'Microsoft.Web/sites#2022-03-01' = {
name: appName
location: location
kind: 'functionapp,workflowapp'
identity: {
type: 'SystemAssigned'
}
properties: {
httpsOnly: true
siteConfig: {
appSettings: union(wfAppSettingStatuses, [
{
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
value: applicationInsights.properties.InstrumentationKey
}
...
])
use32BitWorkerProcess: true
}
serverFarmId: planId
clientAffinityEnabled: false
vnetRouteAllEnabled: true
storageAccountRequired: false
keyVaultReferenceIdentity: 'SystemAssigned'
}
}
Each workflow in the list is now disabled, therefore if you require one to be enabled on deployment, remove it from the pipe delimited string.
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>'
}
}
}
How to stick app config settings to a slot via bicep?
Here is my bicep file:
var stagingSettings = [
{
name: 'AzureFunctionsJobHost__extensions__durableTask__hubName'
value: 'staging'
slotSetting: true
}
]
resource functionApp 'Microsoft.Web/sites/slots#2018-11-01' = {
name: name
kind: kind
location: location
properties: {
clientAffinityEnabled: true
enabled: true
httpsOnly: true
serverFarmId: resourceId('Microsoft.Web/serverfarms', servicePlanName)
siteConfig: {
use32BitWorkerProcess : false
appSettings: stagingSettings
}
}
identity: {
type: 'SystemAssigned'
}
}
On deploying this code, I don't see app config settings stick to a slot:
checkbox is not checked. What am I missing?
You need to create a slotConfigNames resource:
Names for connection strings, application settings, and external Azure storage account configuration
identifiers to be marked as sticky to the deployment slot and not moved during a swap operation.
This is valid for all deployment slots in an app.
Something like that should work:
param functionAppName string
resource functionApp 'Microsoft.Web/sites#2018-11-01' existing = {
name: functionAppName
}
resource functionApps 'Microsoft.Web/sites/config#2021-03-01' = {
name: 'slotConfigNames'
parent: functionApp
properties: {
// Sticky app settings
appSettingNames: [
'AzureFunctionsJobHost__extensions__durableTask__hubName'
]
}
}
I am working on building an azure bicep file to deploy Azure resources.
Within the same bicep file, I am creating a storage account, a couple of containers, and some management policies. Within the Microsoft documentation:
Before you configure a lifecycle management policy, you can choose to enable blob access time tracking. When access time tracking is enabled, a lifecycle management policy can include an action based on the time that the blob was last accessed with reading or write operation.
Though I am following the documentation in terms of enabling the last access time tracking policy according to the documentation, and running the management policies within the same bicep file, I am still running into this error:
"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details. Last access time based tracking policy must be enabled before using its specific actions in object lifecycle management policy"
Here is my bicep file:
resource storage_account_blob 'Microsoft.Storage/storageAccounts#2019-06-01' = {
name: 'test'
location: 'East US'
sku: {
name: 'Standard_RAGRS'
}
kind: 'StorageV2'
properties: {
networkAcls: {
bypass: 'AzureServices'
virtualNetworkRules: []
ipRules: []
defaultAction: 'Allow'
}
supportsHttpsTrafficOnly: true
encryption: {
services: {
file: {
keyType: 'Account'
enabled: true
}
blob: {
keyType: 'Account'
enabled: true
}
}
keySource: 'Microsoft.Storage'
}
}
}
resource blobStorageService 'Microsoft.Storage/storageAccounts/blobServices#2019-06-01' = {
parent: storage_account_blob
name: 'default'
properties: {
lastAccessTimeTrackingPolicy: {
blobType: [
'string'
]
enable: true
name: 'AccessTimeTracking'
trackingGranularityInDays: 1
}
}
}
resource blobStorage_container_input 'Microsoft.Storage/storageAccounts/blobServices/containers#2019-06-01' = {
name: 'input'
properties: {
defaultEncryptionScope: '$account-encryption-key'
denyEncryptionScopeOverride: false
publicAccess: 'None'
}
parent: blobStorageService
}
resource management_policies 'Microsoft.Storage/storageAccounts/managementPolicies#2019-06-01' = {
name: 'default'
properties: {
policy:{
rules: [
{
definition:{
actions:{
baseBlob:{
delete:{
daysAfterLastAccessTimeGreaterThan: 60
}
tierToArchive:{
daysAfterLastAccessTimeGreaterThan: 30
}
tierToCool:{
daysAfterLastAccessTimeGreaterThan:15
}
}
}
filters:{
blobTypes:[
'blockBlob'
]
}
}
enabled: true
name: 'testRules'
type: 'Lifecycle'
}
]
}
}
parent: storage_account_blob
}
Do I have to initially maybe create the storage account with the blob service prior to creating the life cycle management policies?
I'm not sure, but have you tried to set an "depends on" on the "resource management_policies" and point it on "resource blobStorageService".
I'm using Azure Bicep to create a virtualNetwork with a single subnet and then use that as the input for creating an aks cluster with : vnetSubnetID: virtualNetwork.properties.subnets[0].id
The first time I run the command, it creates the virtual network and cluster just fine, but the second time I run the command it gives this error :
{"error":{"code":"InvalidTemplateDeployment","message":"The template
deployment 'cluster' is not valid according to the validation
procedure. The tracking id is '[REDACTED_JUST_IN_CASE]'. See inner errors for
details.","details":[{"code":"PropertyChangeNotAllowed","message":"Provisioning
of resource(s) for container service playground-cluster0 in resource
group showcase-kevinplayground2 failed. Message: {\n "code":
"PropertyChangeNotAllowed",\n "message": "Changing property
'agentPoolProfile.vnetSubnetID' is not allowed.",\n "target":
"agentPoolProfile.vnetSubnetID"\n }. Details: "}]}}
I double checked and there is just the one subnet inside the virtualNetwork created by the deployment (no other magically appeared or anything).
I repeated the experiment on a second resource group and the same thing happened, so it's reproducible.
Here is the full bicep file (just call az deployment group create --resource-group showcase-kevinplayground2 -f cluster.bicep in the resource group of your choice)
targetScope = 'resourceGroup'
resource virtualNetwork 'Microsoft.Network/virtualNetworks#2021-02-01' = {
name: 'aksVirtualNetwork'
location: resourceGroup().location
properties:{
addressSpace:{
addressPrefixes:[
'10.10.0.0/16'
]
}
subnets:[
{
name: 'aks'
properties:{
addressPrefix: '10.10.5.0/24'
}
}
]
}
}
resource aksManagedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities#2018-11-30' = {
name: 'playgroundIdentity'
location: resourceGroup().location
}
resource aks 'Microsoft.ContainerService/managedClusters#2021-02-01' = {
name: 'playground-cluster0'
location: resourceGroup().location
identity: {
type:'UserAssigned'
userAssignedIdentities: {
'${aksManagedIdentity.id}': {}
}
}
sku: {
name: 'Basic'
tier: 'Free'
}
properties: {
kubernetesVersion: '1.21.2'
dnsPrefix: 'playground'
enableRBAC: true
networkProfile: {
networkPlugin: 'azure'
networkPolicy: 'calico'
}
aadProfile: {
managed: true
enableAzureRBAC: true
}
autoUpgradeProfile: {}
apiServerAccessProfile: {
enablePrivateCluster: false
}
agentPoolProfiles: [
{
name: 'aksnodes'
count: 1
vmSize: 'Standard_B2s'
osDiskSizeGB: 30
osDiskType: 'Managed'
vnetSubnetID: virtualNetwork.properties.subnets[0].id
osType: 'Linux'
maxCount: 1
minCount: 1
enableAutoScaling: true
type: 'VirtualMachineScaleSets'
mode: 'System'
orchestratorVersion: null
}
]
}
}
Looking at this reported github issue, you need to use the resourceId function.
In your case, something like that should work:
vnetSubnetID: resourceId('Microsoft.Network/virtualNetworks/subnets', 'aksVirtualNetwork', 'aks')