c9300aee67
fix deploy.json |
||
---|---|---|
.. | ||
APIManagement/2.0 | ||
ActiveDirectory/2.0 | ||
ActiveDirectoryDomainServices/2.0 | ||
AnalysisServices/2.0 | ||
AppServiceEnvironments/2.0 | ||
AppServicePlan/2.0 | ||
AppServiceWebApp/2.0 | ||
ApplicationGateway | ||
ApplicationInsights/2.0 | ||
ApplicationSecurityGroups/2.0 | ||
AutomationAccounts/2.0 | ||
AzureBastion/2.0 | ||
AzureDatabricks/2.0 | ||
AzureFirewall/2.0 | ||
AzureKubernetesServices/2.0 | ||
AzureSecurityCenter/2.0 | ||
CognitiveServices/2.0 | ||
ContainerRegistries/2.0 | ||
CosmosDB/2.0 | ||
DNS/2.0 | ||
DataFactories/2.0 | ||
EventGrid/2.0 | ||
EventHub/2.0 | ||
FunctionApps/2.0 | ||
InternetInformationServices/2.0 | ||
KeyVault/2.0 | ||
LoadBalancers/2.0 | ||
LogAnalytics/2.0 | ||
LogicApps/2.0 | ||
MachineLearning/2.0 | ||
MachineLearningServices/2.0 | ||
MySQL/2.0 | ||
NISTControls/2.0 | ||
NetworkSecurityGroups/2.0 | ||
NotificationHub/2.0 | ||
ProximityPlacementGroups/2.0 | ||
RecoveryServicesVaults/2.0 | ||
RedisCache/2.0 | ||
RouteTables/2.0 | ||
SQLDBServer/2.0 | ||
SQLDatabase/2.0 | ||
SQLManagedInstances/2.0 | ||
SQLServerAlwaysOn/2.0 | ||
SearchServices/2.0 | ||
ServiceBus/2.0 | ||
StorageAccounts/2.0 | ||
StreamAnalytics/2.0 | ||
UpdateAzureFirewall/2.0 | ||
VirtualMachineKeyEncryptionKey/2.0 | ||
VirtualMachineScaleSets/2.0 | ||
VirtualMachines/2.0 | ||
VirtualNetwork/2.0 | ||
VirtualNetworkGateway/2.0 | ||
VirtualNetworkGatewayConnection/2.0 | ||
VirtualNetworkPeering/2.0 | ||
deploying-modules.md | ||
module-readme-template.md | ||
readme.md | ||
testing-modules.md |
readme.md
Modules 2.0
A module is a reusable set of artifacts that can be composed into an archetype. The modules can be deployed by anything that can deploy ARM templates. There is no need for a proprietary tool for deploying a single module. This document is about the 2.0 format for modules.
At a minimum, a module must have:
- deployment and parameters files (e.g
deploy.json
andparameters.json
) - a
readme.md
file - tests (e.g.
module.tests.ps1
) - located in the Tests subfolder
In addition, a module may include the following (each in a subfolder named after the asset type):
- Policy (ARM template) definition + assignment
- RBAC (ARM template) definition + assignment
- Scripts (bash scripts, powershell, batch files, etc.)
Guidelines
A module usually represents a single resource or a set of closely related resources. For example, a storage account and the associated lock or virtual machine and network interfaces.
- Don't use hyphens in file names, folder names, parameters, or variables.
- Module names should use PascalCase and are derived from the names in the Azure Portal
- Parameters and variables in ARM template should use camelCase
- Don't use nested deployments pointing to different subscription and or resource group
- There are situations where nested deployments are okay (i.e., BitLocker – to encrypt the OS drive you’ll need to run a nested deployment)
Testing
Tests rely on Powershell and Pester and on ARM validation.
There are two test files:
module.tests.ps1
is required.output.tests.ps1
is optional. The optional file is for debugging purposes. It writes deployment input parameters to the console.
The module test verifies that required parameters are defined in the parameters file and verifies that the template file has the following parameters:
$expectedProperties = '$schema',
'contentVersion',
'parameters',
'variables',
'resources',
'outputs' | Sort-Object
Once all Pester test passes, proceed to run any of the following commands:
- Powershell:
Test-AzResourceGroupDeployment
- Azure CLI:
az group deployment validate
Before creating a PR, make sure that these two type of tests pass.