Cómo crear y usar un módulo en Bicep: paso a paso

Repetir el mismo bloque de código para cada Storage Account, red virtual o base de datos hace que los archivos Bicep sean largos y difíciles de mantener. Un módulo en Bicep resuelve esto: encapsula uno o varios recursos en un archivo separado que pasa a ser reutilizable, más fácil de leer y de probar de forma independiente. Es la misma idea que una función en programación: lo escribes una vez y lo reutilizas donde lo necesites. A continuación crearás un módulo, le pasarás parámetros y leerás sus outputs desde un archivo principal.

Requisitos previos

• Una suscripción de Azure y un Resource Group ya creado (por ejemplo, rg-demo).
• Azure CLI instalado y sesión iniciada con az login.
• Visual Studio Code con la extensión Bicep (recomendado, pero opcional).
• Conocimientos básicos de parámetros y recursos en Bicep.

Paso 1: Crear el módulo

Un módulo es simplemente un archivo Bicep normal. Crea un archivo llamado storageAccount.bicep con los recursos que quieres reutilizar. Presta atención a los param de entrada y a los output de salida: son el contrato del módulo con quien lo utiliza. Los decoradores @description() y @allowed() documentan y restringen los valores aceptados, haciendo el módulo más seguro.

@description('Prefixo para o nome da Storage Account')
param storagePrefix string

@description('Localização dos recursos')
param location string = resourceGroup().location

@allowed([
  'Standard_LRS'
  'Standard_GRS'
])
param sku string = 'Standard_LRS'

var storageName = '${storagePrefix}${uniqueString(resourceGroup().id)}'

resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageName
  location: location
  sku: {
    name: sku
  }
  kind: 'StorageV2'
}

output storageName string = storage.name
output storageId string = storage.id

La función uniqueString() genera un sufijo determinista que garantiza un nombre único y válido: las Storage Accounts exigen nombres globales en minúsculas, y esto evita el error de nombre ya existente.

Consejo: mantén cada módulo centrado en un único objetivo (una Storage Account, una red, una base de datos). Los módulos pequeños y específicos se reutilizan mucho mejor que un módulo gigante que lo hace todo.

Paso 2: Consumir el módulo en el archivo principal

Crea ahora el archivo main.bicep. Para llamar al módulo usas la palabra clave module, seguida de un nombre simbólico y de la ruta al archivo. Los valores de params se corresponden con los param declarados en el módulo.

@description('Localização dos recursos')
param location string = resourceGroup().location

module stg 'storageAccount.bicep' = {
  name: 'storageDeploy'
  params: {
    storagePrefix: 'dados'
    location: location
    sku: 'Standard_LRS'
  }
}

El nombre simbólico (stg) sirve para referenciar el módulo dentro del archivo. La propiedad name es el nombre del deployment anidado que aparece en Azure: es opcional, pero ayuda a identificar cada implementación. Fíjate en que no necesitas pasar todos los parámetros: los que tienen un valor por defecto en el módulo pueden omitirse cuando ese valor sirve.

Paso 3: Leer los outputs del módulo

Un módulo puede devolver valores al archivo principal a través de sus output. Para leerlos, usa el nombre simbólico del módulo seguido de .outputs y del nombre del output. Añade esto al final de main.bicep:

output storageAccountName string = stg.outputs.storageName

De esta forma, el nombre real de la Storage Account creada por el módulo queda disponible para reutilizar en otros recursos o para consultar al final del deployment.

Paso 4: Validar y desplegar

Antes de desplegar, compila el archivo para confirmar que no hay errores de sintaxis:

az bicep build --file main.bicep

Si no hay errores, despliega en tu Resource Group:

az deployment group create --resource-group rg-demo --template-file main.bicep

Verificar el resultado

Cuando el comando termine, confirma que el módulo se ejecutó correctamente consultando los outputs del deployment:

az deployment group show --resource-group rg-demo --name main --query properties.outputs

Deberías ver el valor storageAccountName con el nombre de la Storage Account. En el portal de Azure, dentro del Resource Group, encontrarás también un deployment llamado storageDeploy: es la ejecución de tu módulo registrada como deployment anidado.

Conclusión

Con un módulo, un recurso se convierte en un bloque reutilizable que puedes llamar tantas veces como necesites, cambiando solo los parámetros. El siguiente paso natural es usar un bucle for sobre el módulo para crear varios entornos (dev, test y producción) desde el mismo archivo. ¿Qué recurso de tu infraestructura sería el primero en convertirse en módulo?