Description

Clean up comments in param files. Make sure that the examples that the commented params are shown in the readme file rather than in the param file it self.

Description

We need to have a method for reading the latest published API versions from Azure resources and find a smart way to creating GitHub issues where it makes sense so that we don't constantly populate issues that makes it hard to track or maintain.

Some customers may not want to use bicep e.g. because it is not on version 1.0 yet.

To enable those, we should provide a utility script that is capable of translation all bicep files to ARM

Description

virtualNetworkPeerings needs to be moved from /arm/Microsoft.Network/virtualNetwork/virtualNetworkPeerings to /arm/Microsoft.Network/virtualNetwork/virtualNetworkResources/virtualNetworkPeerings if I'm correct.

Description

For a solid library base concrete file and folder structures must be defined.

• Modules

  • Folder structure
    • Modules/
      ┣ ModuleName/
      ┣ deploy.bicep
      ┣ deploy.json
      ┣ parameters.json
      ┗ readme.md
  • Basic elements (templates, parameters, pipelines, workflows, ...)
  • Readme (deploy to Azure button, readme structure, ...)
  • Naming convention (deploy.json/deploy.bicep/...)

• Repository

  • Folder structure (Resource provider based)
    • Modules/
      ┣ Microsoft.Compute/
      ┃ ┣ VirtualMachines/
      ┃ ┃ ┣ deploy.bicep
      ┃ ┃ ┣ deploy.json
      ┃ ┃ ┣ parameters.json
      ┃ ┃ ┗ readme.md
      ┃ ┗ VirtualMachineScaleSets/
      ┃ ┣ deploy.bicep
      ┃ ┣ deploy.json
      ┃ ┣ linux.parameters.json
      ┃ ┣ readme.md
      ┃ ┗ windows.parameters.json
      ┣ Microsoft.Storage/
      ┃ ┗ StorageAccounts/
      ┃ ┣ deploy.bicep
      ┃ ┣ deploy.json
      ┃ ┣ parameters.json
      ┃ ┗ readme.md

Enable the user to define the logs on a case-by-case basis with 'all' as the default
Ref https://github.com/Azure/ResourceModules/blob/main/arm/Microsoft.Insights/diagnosticSettings/deploy.bicep

Create a table that provides a flat overview of the modules available in this repository.

Description

In general the question is if it makes sense to develop Azure Modules and templates in this repository or if it's just better to use/develop these under Azure Quickstart Templates or ESLZ Workload Templates

Description

• Microsoft.ContainerRegistry/registries @Msanzdelrio
• Microsoft.DataFactory/factories @segraef
• Microsoft.EventHub/namespaces/eventhubs @SomilGanguly
• Microsoft.ServiceFabric @SomilGanguly
• Microsoft.Compute/virtualMachines @eriqua
• Microsoft.DocumentDB (CosmosDB) @Msanzdelrio

Description

Document Dependency Services & High Cost Services as pre-stage for module deployments and unit tests.

Description

Add/Develop additional compliant Modules for Azure resources/services

Prioritized resources:

• App Services
• Storage Account
• SQL Server and Databases
• CosmosDb
• Event Hub
• Event Grid
• AKS
• Virtual Machines (Linux, Windows)
• Virtual Machine Scale Sets (Linux, Windows)
• Service Fabric

References

• Azure/Enterprise-Scale#708
• https://github.com/Azure/Enterprise-Scale/tree/main/workloads
• Work in Progress library at [Azure/Modules]
• #168

Just the way we did it in IaCS we should trigger pipelines/workflows automatically on a change in main.

Description

Do we have requirements to use

• Releases
• Tags
• GitHub Packages

to further enable development of components without affecting already existing reference to older versions.
Especially if people are going to and want to reference raw content URLs without having an impact if the repository gets updated with never versions of improved code.

Description

• be conscious about naming and avoid creating too many repositories
• make use of GitHub packages
• make use of Tags/Releases
• Sanitization Check
• Migrate Global Module Unit Test workflows
• Deploy to Azure Button
• Auto-Readme creation workflow
• remain linkage between ES and Modules @SomilGanguly

References

https://github.com/equinor/AzModules/blob/bicepifi/docs/Module-Guidelines.md#module-outputsreturns

Description

After converting the managementGroup module, it only deploys a single management group. To retain the functionality of being able to deploy an entire management group structure, a construct using this singular managementGroup module should be created.

Description

When reviewing PRs containing some markdown files, some of the files show as binary.
An assumed cause is that the encoding of files are UTF16-LE. The files that can be reviewed in a PR (working as expected) are mostly UTF8.

Change the encoding of all MD files to UTF8 to see if they work as indented again in PRs.

References

UI Definition Sandbox: https://portal.azure.com/?feature.customPortal=false&#blade/Microsoft_Azure_CreateUIDef/SandboxBlade

createUiDefinition Overview

createUiDefinition UI elements reference

testing createUiDefinition

Both modules have almost the same content with one major difference:

• The AppService module deploys a serverfarm (appServicePlan) directly and references its ID in the subsequent site deployment
• The WebApp module deploys no serverfarm but only requires you to provide its ID in the site deployment

Ideally we merge both together and provide an experience where the ID can be provided as an optional parameter. If provided it is used, if it is not provided, but a name for an AppServicePlan is, an AppServicePlan is deployed and its ID used

Now that we have the module table & script available it might be worth thinking about auto-generating / updating the list.

While the implementation should be relatively straight forward as the main script is already available, working around the branching policies may be the trickier part.

Description

Test Deployment of Bicep Modules in Azure US Gov and Azure China.

Acceptance Criteria

Manual deployment validation via Test-AzResourceGroupDeployment and New-AzResourceGroupDeployment is required and must be successful.
Optionally you can make use of the already existing Module Test Pipelines (https://github.com/Azure/ResourceModules/.github/workflows). You just have to set your ARM credentials to test in your environment.

Modules to validate

References

• https://docs.microsoft.com/en-us/azure/azure-government/compare-azure-government-global-azure

Right now, most modules have 'all' available RBAC roles as a variable in the template even though only a subset can be applied to the given service.
Where possible we should update these modules and reduce the roles to the once that are actually available.

This will in most instances also drastically reduce the template's size.

The NSG Flow Logs Module resources are of type Microsoft.Network/networkWatchers/flowLogs and should be merged into the network watcher module.

They are also implemented in the NSG module itself which however seems to be fine to reduce the number of deployments in case somebody wants to do both.

However, it does not make sense to have the NetworkWatcher module + NSGFlowLogsModule + NSG Module (wirh NSG Flow Logs)

Description

There are two approaches to enable locks in modules. The module which is set up different is Microsoft.Insights/privateLinkScopes and Microsoft.Resources/resourceGroups . They have the different lock modes you can enable as a parameter lock while for the other modules, they just take a boolean for lockForDeletion, which only exposes the ability to deploy a CanNotDelete lock.

Align on one approach and make that the default for the modules which support locks.

The following modules need another look:

• AzureSecurityCenter: Ambiguous provider
• appService: overlapping provider with appServicePlan
• appServicePlan: overlapping provider with appService
• webApp: overlapping provider with siteFunctions
• sitesFunction: overlapping provider with webApp
• OpenSystemsNVA: Ambiguous provider

Description

To ease the search for Modules, a Modules list needs to be developed in https://github.com/Azure/Modules/tree/main/arm to have an overview of all current Modules with direct links to their respective folders they're sitting in. It would be also nice to have an overview like this: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-services-resource-providers

We're currently exposing subscription IDs in the repository to enable testing.

To hide them going forward we should implement a logic that replaces placeholders in parameter files during test & deployment (e.g. ) with the correponding secret stored in GitHub

Error: [-] [galleries] parameters section should contain all parameters from the deploy.json file 62ms (60ms|2ms)

Error: [-] [accounts] Output section should contain all outputs defined in the deploy.json file 104ms (101ms|3ms)

Description

arm\.global\global.module.tests.ps1 is still referencing lockForDeletion. This would need to be fixed with the replaced lock parameter which takes its place.

Description

A common set of FAQs and Wiki needs to be set up.
General documentation is required for

• What is a Module?
• Module Dependencies?
• What is a Module used for?
• How to deploy a Module (with PS, CLI, AzOps, TF, ...)?
• What is a Workload?
• How have Modules to do with Azure Landing Zones?
• How does this fit into CAF?
• What collaboration platform is recommended (GitHub/ADO)?
• What is IaC?
• Azure Resource Manager Reference?
• What are GitHub Actions and Workflows?
• Are Azure Pipelines supported?
• How to contribute a Module?
• How to structure a Module (ARM Template) according to an ARM Template syntax?
• How to structure a Module (Bicep Module) according to an ARM Template syntax?
• What are Constructs?

Other

• naming in general for parameters in modules to remain consistent naming structure within templates and files (input parameter as well as output parameters, camelcasing)

References

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/file
https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/syntax
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/plan/workloads#what-is-a-workload
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/extension-resource-types
https://docs.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/infrastructure-as-code
https://docs.microsoft.com/en-us/azure/architecture/framework/devops/automation-infrastructure

Description

Kind property in Deployment Script modules is hardcoded as it can't be parameterized because of PG bug

Steps to reproduce

1. NA
2. NA

Screenshots

Description

Setup Branch policy and Security Scanning.

Description

Linting for ARM (ARM-TTK) and JSON is currently disabled since it throws errors due to non-compliance with some parts of the ARM templates.

Steps to reproduce

https://github.com/Azure/Modules/blob/fba751cac154a4d07dbe285077a20bb664b0298f/.github/workflows/linter.yml#L19-L20
Workflow run: https://github.com/Azure/Modules/actions/runs/1141463824

Screenshots

To improve readability and avoid confusion we should add the 'primary resource' (e.g. Microsoft.KeyVault/vaults) to the title of the module's readme.

Underneath we have the 'ResourceTypes' table that just lists all resources in the template. That may cause confusion as to what resource we aim at with the template. Hence the intended 'highlighting'

For most if not all modules we have support for the CuaID to track consumption & usage of templates.

We could use that concept, generate a custom GuaID and set it as a default value.

Description

There are two approaches to enable logs in modules. The module which is set up different is Microsoft.Insights/diagnosticLogs. It has the different logs you can enable as a parameter logsToEnable while for the others, what logs to enable is "hardcoded" into vars.

Align on one approach and make that the default for the modules which support diagnosticSettings

Add support for the 'public bicep registry' to the publish actions (GitHub) and pipeline (Azure DevOps) to enable the modules consumption by other bicep resources

Description

Today the builtInRoleNames variable is in the deploy.bicep files for many of the resources. They should be moved into the module, as it is here they are used.

Description

Create Issue Forms

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms

Description

Move all modules which support easy deployments of multiple instances into constructs and create variants/constructs.

virtualMachines
roleAssignments
virtualNetworkpeerings

Description

Some ARM templates still have non-Bicep compliant decompilation errors which need to be fixed.

Steps to reproduce

bicep decompile .\deploy.json

Example

Code

[![Deploy to Azure](/docs/media/deploytoazure.svg?sanitize=true)](<https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FModules%2Fmain%2Farm%2FMicrosoft.AnalysisServices%2Fservers%2Fdeploy.json>)

[![Deploy To Azure US Gov](/docs/media/deploytoazuregov.svg?sanitize=true)](<https://portal.azure.us/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FModules%2Fmain%2Farm%2FMicrosoft.AnalysisServices%2Fservers%2Fdeploy.json>)

[![Visualize](/docs/media/visualizebutton.svg?sanitize=true)](<http://armviz.io/#/?load=https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2FModules%2Fmain%2Farm%2FMicrosoft.AnalysisServices%2Fservers%2Fdeploy.json>)

References

https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/deploy-to-azure-button
https://devblogs.microsoft.com/cse/2017/01/17/the-deploy-to-azure-button/
https://medium.com/@codeprincess/get-your-own-azure-button-now-8d79b1811061

Error: [-] In [activityLogAlerts] used resource type [activityLogAlerts] should use on of the recent API version(s). Currently using [2020-10-01] 152ms (120ms|32ms)

Set up the intial set of pipelines required to run the platform on AzureDevOps

• Create V1 of unit-testing pipelines for Azure DevOps
• Create V1 of test-deployment pipelines for Azure Devops
• Create V1 of publish pipelines for Azure Devops
• Create V1 of removal pipelines for AzureDevOps

Description

Based on the decision in #10 we also have to consider the naming of this repository

• ResourceModules
• Modules
• Service Modules / ServiceModules
• Units

Description

Allowed location policy deployed by the PolicyAssignment module prevents resources to be created in locations different than westus and westus2.

Steps to reproduce

1. Deploy any resource in westus as per default workflows

Screenshots

E.g. storage account

https://github.com/Azure/ResourceModules/runs/3707436376?check_suite_focus=true#step:4:124