I am using Azure DevOps Pipeline to deploy ARM Templates for Alerts and Workbooks in Azure Monitoring. The problem is, every time the pipeline is running, many resources are mentioned is Pipeline. The status of them is 'ignored', so they are not getting changed, but they are mentioned every time. I do not understand why they are mentioned and what if one day they will be changed, which will break the whole infrastructure?
I am using Subscription scope to deploy ARM Templates.
This is how it looks like:
Resource and property changes are indicated with these symbols:
= Nochange
* Ignore
The deployment will update the following scope:
Scope: /subscriptions/***/resourceGroups/***
= microsoft.insights/metricalerts/***
* Microsoft.Compute/diskEncryptionSets/***
* Microsoft.Compute/sshPublicKeys/***
* Microsoft.ContainerService/managedClusters/***
* Microsoft.Insights/scheduledqueryrules/***
* Microsoft.ManagedIdentity/userAssignedIdentities/***
* Microsoft.Network/privateDnsZones/***
* Microsoft.Network/privateDnsZones/***/virtualNetworkLinks/***
* Microsoft.Network/privateDnsZones/***/virtualNetworkLinks/***
* Microsoft.OperationalInsights/workspaces/***
* Microsoft.OperationsManagement/solutions/ContainerInsights(***)
* microsoft.insights/metricalerts/***
...
* microsoft.insights/scheduledqueryrules/***
* microsoft.insights/scheduledqueryrules/***
* microsoft.insights/workbooks/***
* microsoft.insights/workbooks/***
Resource changes: 1 no change, 21 to ignore.
Finishing: ARM deployment plan
Thank you!
I am especially confused about mentioned diskEncryptionSets, sshPublicKeys and privateDnsZones. What does it have to do with Alerts and Workbooks?
The ignored resources represent resources that are present within the scope of the deployment (in this case within the target subscription) but are not defined within the current ARM template.
See the manual page on what-if deployments for reference.
Resource that are defined within the template but are in compliance with the template will show as NoChange.
Related
I am new to using Azure bicep. I am trying to deploy a simple app service plan/app service with the following bicep file:
resource azBicepAsp1 'Microsoft.Web/serverfarms#2020-12-01' = {
name: 'test-dev-aue-asp1'
location: resourceGroup().location
kind: ''
sku: {
name: 'F1'
capacity: 1
}
}
resource azbicepas 'Microsoft.Web/sites#2021-01-15' = {
name: 'test-dev-aue-wapp1'
location: resourceGroup().location
properties: {
serverFarmId: resourceId('Microsoft.Web/serverfarms', 'test-dev-aue-asp1')
}
dependsOn:[
azBicepAsp1
]
}
using:
az deployment group create -g azbbicepad-dev-au-rg1 -f 2.AppServicePlan.bicep --confirm-with-what-if
It deploys sucesfully, however if I deploy it again with the exact same deployment it says the following changes will be made:
- Delete
+ Create
~ Modify
The deployment will update the following scope:
Scope: /subscriptions/71913b63-cacf-41bf-9da1-e3a1db24e62c/resourceGroups/azbbicepad-dev-au-rg1
~ Microsoft.Web/serverfarms/test-dev-aue-asp1 [2020-12-01]
- kind: "app"
~ sku.capacity: 0 => 1
~ Microsoft.Web/sites/test-dev-aue-wapp1 [2021-01-15]
+ properties.siteConfig.localMySqlEnabled: false
+ properties.siteConfig.netFrameworkVersion: "v4.6"
I don't quite understand why this occurs - could someone please point me in the right direction?
Thanks,
Regarding the app service plan:
if you specify Free tier, the capacity is always 0. When you deploy your template the first time, the capacity specified is ignored and set to 0. When you redeploy, there is a mismatch between what's defined in the template and the target resource.
If you dont specify the kind, the default is app. Same here, there is a mismatch between the template and the target resource.
There is a good explanation on this post.:
Noise
One issue you may see when using this command is noise, where the results show that a resource is being changed when no change will occur. This is usually down to the fact that the information you provide to the ARM API to create or update a resource is less than the data returned when querying it, or that defaults are being used. An example seen early in the preview was when deploying a storage account, if you did not specify the encryption settings in the template (so using the defaults), then What-If showed a change because it thought it was removing these settings.
This is something the ARM team is aware of and are working to remove during the preview. They are asking for everyone using this command to keep an eye out for these issues and log them in this Github issues log. Please do log issues when you see them to help improve this command and get it out of preview as soon as possible.
I need to create Azure resources. ALL Region/ Location like eastus, westus etc.. should be displayed as Parameter in Pipeline so user can Select any one location for creating the Azure resource using Azure Devops Pipeline. Any suggestions please
Are you using yaml to define your pipeline? If so this is possible using runtime parameters. You essentially define a list of values that can be selected on pipeline running, and if a user doesn't it chooses a default value.
Runtime Parameters
Exported Azure ARM template contains a lot's of useless information, let's say snapshots. I would like export actual resource definitions only.
Is it possible to filter unnecessary items out? I would like to convert this template to Bicep (to deploy all the resources into an another subscription) and now I have to clear manually all the unused items from the exported ARM template.
Thank you Gopa. Posting your suggestion as an answer to help other community members.
Exporting an ARM template from the resource group or resource will give you a template that is a snapshot of the current properties so it includes all the properties which were changed after the initial deployment.
You can also try exporting templates from the deployment history too which will give you an option to export your initial version without the changes you made after each deployment.
You can maintain all resources in source control as ARM templates and use CI/CD to deploy, whenever there is a change, so you can have our latest version of ARM templates and use it to build up a new environment when a need comes.
You can export the template that was used to deploy existing resources. The template you get is exactly the one that was used for deployment.
Export template after deployment
Select the resource group you want to export.
Select the link under Deployments.
Select one of the deployments from the deployment history.
Select Template. The template used for this deployment is displayed, and is available for download.
I am currently planning on a type of multi-tenant system, were different resource groups with a set of AppServices are deployed for customers via ARM Templates. Hence, each customer has its own Resource Group and set of AppServices. Currently we use Azure DevOps to deploy to a set of AppServices used for Development and Quality Assurance before it gets to Production. I am now trying to incorporate DevOps into the mix, automating a pipeline creation of some sort... (it would be a copy of an existing pipeline but only changing the Target AppServices). Which is were my question comes from, Is there a way to dynamically create or edit a Release pipeline to add the deployment of those new AppServices, without the need of manually edit or create a pipeline an adding those newly created AppServices, I was thinking something around the lines of being able to copy a yaml file template then replacing the necessary info to point to those AppServices after they have been created, but I am not totally sure where could I store the new yaml file so that it is picked up by Azure DevOps, or how could I would accomplish these, with the main idea being that all of this continues to be part of an automated process (if possible).
Thanks a lot for any help, any suggestion is appreciated.
EDIT:
The question is not about how to Deploy an ARM Template through the DevOps release pipeline (I plan on using a PowerShell Script/REST API to accomplish that), instead, is about when the AppServices Resources are created, I need to deploy code to those newly created AppServices and also update that code when necessary (Hopefully through a Release Pipeline), somehow generate a new release pipeline each time I deploy a new set of Resources. So that, when there is a new update, I could easily have that pipeline triggered and that set if AppServices can be updated (created as part of the automation process "dynamically"). (I Already have a similar pipeline that deploys to a "static" set of AppServices).
This is possible as you eluded to with YAML Pipelines. Based upon the scenario you have subscribed each repository would have it's own pipeline.yml file that will define the trigger, pool etc. It would also reference a repository that will house your yaml template.
The template would accept whichever parameters you may required (resource group, app service name, etc...) The triggering pipeline associated with each repository would pass this information leveraging the teamplate.
By doing this CI/CD can be set up to trigger on the individual pipelines and deploy the appropriate code all while leveraging the same YAML template.
The repository reference would be similar to:
resources:
repositories:
- repository: YAMLTemplates
type: git
name: OrginazationName/YAML Project Name
With the call to the template being similar to:
- template: azure-ARM-template.yml#YAMLTemplate
parameters:
appServiceName: 'AppServiceName'
resourceGroupName: 'ResourceGroupName'
UPDATE
At a high level the YAML pipeline would consist of the following. If all App Services are similar as stated and ARM Templates are similar this how it could be constructed and triggered based on a folder path:
Build necessary artifacts
Publish Pipeline
Deploy Azure Resource Group Task
Deploy App Settings Task (if applicable)
Deploy App Service
Release the deployment pieces for each environment in appropriate stages to help alleviate the amount of copying and pasting each of the above tasks can be part of a template either individually at a task, combination of tasks, or all in one. This would allow for defining the YAML once and referencing it and including app specific components as needed as parameters to the templates.
I have created a CD pipeline in Azure DevOps that will deploy an Azure Automation account and a runbook , shedule , jobshedule through ARM templates.
All working fine except when rerunning the template. My template is a part of a large deployment process that is still under construction so until the total scope is finished the ARM template that creates the runbook, shedule, jobshedule will rerun with every release.
The problem right now is the following: Whenever I rerun the template with a new release pipeline, I receive following error
A job schedule for the specified runbook and schedule already
exists.
At first I tried to be smart so added a GUI before the name of my jobshedule but the shedule itself attaches the runbook with the shedule and the deployment was smart enough to figure it out that the shedule was already connected to the runbook. Is there a way of making this still within the DevOps mindset / process so that I can rerun my templates with no problem.
The workaround solution I have created atm is to delete the shedule at every deployment but that seems like a very bad workaround.
Related feature request from UserVoice / feedback forum is here that's currently in triaged state.
Job Schedule id need to be unique for each deployment as per azure documentation.