Generación de plantillas de Bicep con GitHub Copilot

  • 12 minutos

Tip

Consulte la pestaña Texto e imágenes para obtener más detalles.

Bicep es el lenguaje específico de dominio de Microsoft para implementar recursos de Azure. Se compila a plantillas JSON de Azure Resource Manager, pero es más legible y concisa. Bicep elimina el código repetitivo de Azure Resource Manager sin dejar de mantener el modelo declarativo.

Una definición de recurso de Bicep básica tiene este aspecto:

param location string = 'eastus'
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

Tres cosas que se deben tener en cuenta: el @ símbolo separa el tipo de recurso de la versión de api, los parámetros se declaran en la parte superior y las referencias de recursos usan nombres simbólicos en lugar de identificadores de recursos. Estos patrones son importantes al revisar la salida de Copilot.

Esta unidad se centra en el uso de Copilot para generar, ampliar y optimizar plantillas de Bicep. Para ver una introducción completa a Bicep, consulte Introducción a Bicep.

Generación de plantillas a partir de mensajes de lenguaje natural

De forma predeterminada, Copilot genera Bicep a partir de sus datos de entrenamiento. No hay herramientas externas ni datos de esquema dinámico implicados. Para los tipos de recursos comunes con requisitos específicos, esto ya genera una salida confiable.

Generación de una plantilla sencilla

Empiece con una solicitud centrada en un único recurso para ver qué genera Copilot. Un aviso bien restringido como este proporciona Copilot todo lo que necesita:

Generate a Bicep template for an Azure Storage Account with these requirements:
- Standard_LRS SKU
- StorageV2 kind
- HTTPS-only access enforced
- Minimum TLS version: TLS 1.2
- Blob soft delete enabled with 7-day retention
- Public blob access disabled
- Parameters for: storageAccountName, location (default: eastus),
  environment, owner, costCenter
- Apply tags using a tags object built from the environment, owner,
  and costCenter parameters
- Output the storage account's primary blob endpoint

Deberías obtener un archivo de Bicep completo con parámetros, un bloque de recursos y una salida. Valide inmediatamente con az bicep build antes de hacer nada más.

Generación de una plantilla de varios recursos

La complejidad aumenta cuando varios recursos dependen entre sí. Las referencias de recursos, donde el nombre simbólico de un recurso aparece dentro de las propiedades de otro recurso, son donde a veces Copilot necesita corrección.

Pruebe esta instrucción para generar un conjunto interconectado de recursos:

Generate a Bicep template that deploys the following resources:
- An App Service Plan (Standard S1 SKU) on Linux
- An App Service (Web App) using Node 20 on the App Service Plan
- A Key Vault with RBAC authorization enabled and soft delete (90 days)
- A Role Assignment giving the Web App's system-assigned managed identity
  the "Key Vault Secrets User" role on the Key Vault
- Application settings on the Web App pointing to the Key Vault URI

Parameters: appName, location, environment, owner, costCenter
Use symbolic name references for all cross-resource dependencies.
Do not use hardcoded resource IDs.

Revise la salida para detectar tres problemas comunes en este nivel:

  • Dependencias circulares: si dos recursos se referencian entre sí, Bicep no compila. Compruebe el gráfico de dependencias.
  • Ámbito de asignación de roles: el recurso roleAssignment debe tener Key Vault como ámbito, no el grupo de recursos. Compruebe la scope: propiedad .
  • Referencia de identidad: webApp.identity.principalId es la manera correcta de hacer referencia a la identidad administrada. Confirme que Copilot usa el nombre simbólico, no un valor codificado de forma dura.

Modularización de una plantilla

A medida que crecen las plantillas, son más difíciles de mantener. Los módulos de Bicep permiten dividir una plantilla grande en componentes reutilizables. Copilot puede hacer esta división por usted.

Refactor this Bicep template into modules. Create:
- A module for the App Service Plan and Web App (modules/webapp.bicep)
- A module for the Key Vault and Role Assignment (modules/keyvault.bicep)
- A main.bicep that calls both modules and passes parameters between them

Show me the content of all three files. Ensure the output of the Key Vault
module (the Key Vault URI) is passed to the Web App module as an input.

Copilot genera los archivos de módulo y el archivo de orquestación principal. Lo principal que hay que verificar es que los valores output de un módulo se conecten correctamente como entradas param a otro. Esa conexión entre módulos es el error más común al dividir plantillas.

Bicep MCP: generación basada en el contexto

¿Qué es MCP?

El Protocolo de contexto de modelo (MCP) es un estándar abierto que permite a los modelos de IA conectarse a herramientas y API externas. En lugar de confiar únicamente en los datos de entrenamiento, un Copilot habilitado para MCP puede consultar orígenes de datos activos en tiempo real.

El servidor MCP de Bicep conecta GitHub Copilot con el registro de tipos de Bicep en tiempo real. Gracias a esta conexión, GitHub Copilot obtiene acceso a:

  • Versiones de API actuales para cada tipo de recurso de Azure
  • Esquema de propiedades completo para cada tipo de recurso
  • Reglas de validación que marcan errores de configuración antes de ejecutar bicep build
  • Avisos de desuso cuando se retira una versión de API

Sin MCP, Copilot genera Bicep en función de los patrones de sus datos de entrenamiento. Esos datos tienen una fecha límite de conocimiento y las versiones de API de Azure evolucionan continuamente. El resultado puede ser plantillas que usan versiones de API obsoletas, no se han agregado recientemente propiedades necesarias o que incluyen parámetros en desuso. Con MCP activo, Copilot consulta el registro activo antes de generar cada bloque de recursos.

Habilitación del servidor MCP de Bicep

  1. En VS Code, abra la paleta de comandos (Ctrl+Shift+P).
  2. Busque MCP: habilitar servidor Bicep.
  3. Confirme que el servidor se muestra como activo en la barra de estado Copilot.

Una vez habilitado, Copilot Chat usa automáticamente el servidor MCP de Bicep cuando trabajas con archivos .bicep o haces preguntas sobre recursos de Bicep.

Cambios con MCP activo

Al ejecutar el mismo prompt con y sin MCP, se produce una salida notablemente diferente en tres áreas.

Versiones de API

Sin MCP, es posible que Copilot genere lo siguiente:

resource firewall 'Microsoft.Network/azureFirewalls@2022-07-01' = {

Con MCP, Copilot consulta el registro y genera la versión estable actual:

resource firewall 'Microsoft.Network/azureFirewalls@2024-03-01' = {

Las versiones más recientes de api suelen incluir mejoras de seguridad, nuevas propiedades necesarias y correcciones de errores.

Propiedades necesarias

Algunos tipos de recursos obtuvieron propiedades necesarias en versiones de API más recientes. Sin MCP, Copilot puede generar una plantilla que se compila localmente, pero produce errores durante la implementación cuando Azure valida la solicitud. Con MCP, Copilot conoce esos requisitos y los incluye.

Validación durante la generación

Con MCP activo, Copilot puede marcar problemas antes de ejecutar bicep build. Si escribe un nombre de propiedad que no existe en el esquema, Copilot puede identificarlo inmediatamente, similar a IntelliSense para un lenguaje con tipo.

Ejemplo: red de tipo hub-and-spoke con MCP

Utilice esta solicitud con MCP activo para generar una topología de red en estrella tipo hub-and-spoke completa:

Generate a Bicep template for a hub-spoke VNet topology:
- Hub VNet: 10.0.0.0/16 with AzureFirewallSubnet (/26) and GatewaySubnet (/27)
- Spoke VNet: 10.1.0.0/16 with an application subnet (/24)
- VNet peering between hub and spoke (both directions)
- Azure Firewall Standard tier in the hub
- Azure Firewall Policy linked to the firewall
- Public IP for the firewall
- NSG on the application subnet blocking inbound SSH and RDP from internet
- Log Analytics Workspace for diagnostic logging
- Diagnostic settings on the firewall sending logs to the workspace
Parameters: location, environment, owner, costCenter
Use latest stable API versions.

Con MCP activo, Copilot usa versiones de API actuales, vincula correctamente el firewallPolicy al recurso AzureFirewall, genera el recurso diagnosticSettings con el logs y metrics formato de matriz y usa dependsOn solo cuando las referencias simbólicas no son suficientes.

Validación y procedimientos recomendados

Ejecutar siempre az bicep build

Después de cada generación de Copilot, ejecute:

az bicep build --file main.bicep

Este comando compila Bicep para Azure Resource Manager JSON y detecta errores de sintaxis, propiedades necesarias que faltan y referencias no válidas. Es un paso de validación rápido que detecta muchos problemas antes de la implementación.

Uso what-if antes de cada implementación

El comando what-if muestra exactamente qué Azure crea, modifica o elimina, sin realizar ningún cambio:

az deployment group what-if \
  --resource-group rg-iaclab \
  --template-file main.bicep \
  --parameters @params.json

Revise la salida antes de cada implementación. Busque los recursos que se eliminan que no tenía intención de quitar, las modificaciones que parecen inesperadas y un recuento de recursos que coincida con el diseño.

Uso de archivos de parámetros para valores específicos del entorno

Copilot puede generar archivos de parámetros a partir de las plantillas:

Generate a Bicep parameters file (bicepparam format) for the template above.
Create values appropriate for a staging environment.
Include comments explaining what each parameter controls.

Este tipo de instrucción genera un archivo .bicepparam que puedes versionar junto con la plantilla, con un archivo para cada entorno.

Pide a Copilot que documente su salida

Add @description() decorators to every parameter and output in this template.
The descriptions should be clear enough for someone who has never seen the template
to understand what each parameter controls and what constraints apply.

Este ejemplo de prompt hace que la plantilla se autodocumente y mejora la salida de what-if, que muestra descripciones de parámetros.

Corrección de problemas comunes con Copilot

Referencia de recursos no válida

Síntoma: bicep build se produce un error con "The referenced resource could not be found."

This Bicep template has an invalid resource reference at line [X].
The resource [name] references [other resource] but uses a hardcoded string
instead of the symbolic name. Fix all cross-resource references to use
symbolic names.

Dependencia circular

Síntoma: bicep build se produce un error con "A cycle was detected in the template."

This Bicep template has a circular dependency between [resource A] and
[resource B]. Restructure the template to break the cycle. One approach
is to use an existing() reference for one of the resources.

Versión obsoleta de la API

Síntoma: Se produce un error en la implementación "The resource type [X] was not found in the namespace."

The resource type [Microsoft.Network/azureFirewalls@2021-02-01] appears to
use an outdated API version. Update it to the current stable API version
and adjust any properties that have changed.