Azure Verified Modules
Glossary GitHub GitHub Issues Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage

Last updated: 19 Apr 2024

Composition

While this page describes and summarizes important aspects of the composition of AVM modules, it may not reference All of the shared and language specific requirements.

Therefore, this guide MUST be used in conjunction with the Shared Specification and the Bicep specific specifications. ALL AVM modules (Resource and Pattern modules) MUST meet the respective requirements described in these specifications!

Composition

Before jumping on implementing your contribution, please review the AVM Module specifications, in particular the Shared and the Bicep specific pages, to make sure your contribution complies with the AVM module’s design and principles.

Directory and File Structure

Each Bicep AVM module that lives within the Azure/bicep-registry-modules repository in the avm directory will have the following directories and files:

  • tests/ - (for unit tests and additional E2E/integration if required - e.g. Pester etc.)
    • e2e/ - (all examples must deploy successfully - these will be used to automatically generate the examples in the README.md for the module)
  • modules/ - (for sub-modules only if used and NOT children of the primary resource. e.g. RBAC role assignments)
  • /... - (Module files that live in the root of module directory)
    • main.bicep (AVM Module main .bicep file and entry point/orchestration module)
    • main.json (auto generated and what is published to the MCR via BRM)
    • version.json (BRM requirement)
    • README.md (auto generated AVM Module documentation)

Example Directory and File Structure within Azure/bicep-registry-modules Repository

/ Root of Azure/bicep-registry-modules
├───avm
│   ├───ptn
│   │   └───apptiervmss
│   │       │   main.bicep
│   │       │   main.json
│   │       │   README.md
│   │       │   version.json
│   │       │
│   │       ├───modules
│   │       └───tests
│   │           ├───unit (optional)
│   │           └───e2e
│   │               ├───defaults
│   │               ├───waf-aligned
│   │               └───max
│   │
│   └───res
│       └───compute
│           └───virtual-machine
│               │   main.bicep
│               │   main.json
│               │   README.md
│               │   version.json
│               │
│               ├───modules
│               └───tests
│                   ├───unit (optional)
│                   └───e2e
│                       ├───defaults
│                       ├───waf-aligned
│                       └───max
├───other repo dirs...
└───other repo files...

Code Styling

This section points to conventions to be followed when developing a Bicep template.


Casing

Use camelCasing as per BCPNFR8.


Input Parameters and Variables

Make sure to review all specifications of Category: Inputs within both the Shared and the Bicep specific pages.

See examples in specifications SNFR14 and BCPNFR1.

Resources

Resources are primarily leveraged by resource modules to declare the primary resource of the main resource type deployed by the AVM module.

Make sure to review all specifications covering resource properties and usage.

See examples in specifications SFR1 and RMFR1.

Modules

Modules enable you to reuse code from a Bicep file in other Bicep files. As such, for resource modules they’re normally leveraged for deploying child resources (e.g., file services in a storage account), cross referenced resources (e.g., network interface in a virtual machine) or extension resources (e.g., role assignments in a key vault). Pattern modules, normally reuse resource modules combined together.

Make sure to review all specifications covering module properties and usage.

See examples in specifications BCPFR1 for resource modules and PMNFR2 for pattern modules.

Outputs

Make sure to review all specifications of Category: Outputs within both the Shared and the Bicep specific pages.

See examples in specification RMFR7.


Interfaces

This section is only relevant for contributions to resource modules.

To meet RMFR4 and RMFR5 AVM resource modules must leverage consistent interfaces for all the optional features/extension resources supported by the AVM module primary resource.

Please refer to the Shared Interfaces page. If the primary resource of the AVM resource module you are developing supports any of the listed features/extension resources, please follow the corresponding provided Bicep schema to develop them.