Publicación de código de Bicep desde un flujo de trabajo de implementación

Completado

Cuando automatiza el proceso de publicación de una especificación de plantilla o un módulo de Bicep, debe asegurarse de que todo lo que normalmente haría por sí mismo se puede automatizar y ejecutar dentro del flujo de trabajo. En esta unidad aprenderá a aplicar algunos de los principios que ha aprendido anteriormente al publicar especificaciones de plantilla y módulos de Bicep desde un flujo de trabajo de implementación.

Especificaciones de plantilla y módulos

Bicep le permite reutilizar fácilmente el código. Dos enfoques comunes para reutilizar el código de Bicep entre implementaciones son:

• Especificaciones de plantilla, que están optimizadas para la implementación de soluciones completas. Por ejemplo, supongamos que ha definido un conjunto de recursos protegidos por seguridad para implementar una máquina virtual completa según las especificaciones de la empresa. Podría publicar este código como una especificación de plantilla. A continuación, los compañeros podrían usar la especificación de plantilla para implementar una máquina virtual completa, incluso desde Azure Portal.
• Módulos, que están diseñados para ser componentes de otras implementaciones. Por ejemplo, supongamos que ha creado un archivo de Bicep que crea una cuenta de almacenamiento. Es probable que necesite cuentas de almacenamiento en muchas otras implementaciones, por lo que podría publicar el archivo de Bicep en un registro y usarlo como módulo en todas las implementaciones de la organización.

Al decidir entre el uso de las especificaciones de plantilla y los módulos de Bicep, una buena regla general es: si la plantilla se va a implementar tal y como está en toda la organización, es probable que las especificaciones de plantilla sean una buena opción. Pero si es probable que reutilice esta plantilla dentro de varias plantillas primarias, los módulos de Bicep pueden satisfacer mejor sus necesidades.

Validación del código reutilizable en un flujo de trabajo

A diferencia de las implementaciones normales de Bicep, cuando crea una especificación de plantilla o un módulo, los recursos no se implementan directamente en Azure. En su lugar, se publica la especificación de plantilla o el módulo. Después podrá usar la especificación de plantilla o el módulo en otra implementación. Esa implementación implementará los recursos que ha definido. Debido a esta diferencia, las formas en que valida y prueba las especificaciones de plantilla y los módulos de Bicep pueden ser diferentes del proceso que se usa para las implementaciones normales de Bicep.

Realizar un linting de código de Bicep es recomendable. El linter detecta problemas sintácticos y le advierte si no sigue los procedimientos recomendados.

Además de linting, es posible que quiera considerar la posibilidad de probar las especificaciones de plantilla y los módulos mediante la validación preparatoria. Incluso puede considerar la posibilidad de implementar las especificaciones de plantilla y los módulos en Azure y probar que los recursos que crean se comportan según lo previsto. Sin embargo, puede resultar difícil ejecutar estos tipos de pruebas desde un flujo de trabajo de implementación por dos motivos:

• La validación y las implementaciones preparatorias requieren un entorno de Azure en el que implementar los recursos. Es posible que tenga que mantener una suscripción de Azure dedicada o un grupo de recursos para implementar y probar los módulos.
• Muchas especificaciones de plantilla y módulos requieren que especifique un conjunto de parámetros. Es posible que tenga que crear un conjunto de parámetros de prueba para las especificaciones de plantilla o los módulos que se van a usar cuando se implementan.

Debe elegir si desea incluir pasos de flujo de trabajo que implementen y prueben las especificaciones de plantilla y los módulos. En este módulo de formación de Microsoft Learn se realiza un linting del código de Bicep, pero no se incluyen otras formas de pruebas. Si quiere probar las especificaciones de plantilla y los módulos, tenga en cuenta cómo los implementará en Azure. Tenga en cuenta también si va a usar suscripciones dedicadas o grupos de recursos para implementar los recursos.

Sugerencia

Se recomienda que revise Probar el código de Bicep mediante Acciones de GitHub para obtener más información sobre cómo probar los archivos de Bicep en un flujo de trabajo automatizado.

Autenticación y autorización

Cuando publica las especificaciones de plantilla en Azure usted mismo, el usuario de Microsoft Entra debe concederse acceso al grupo de recursos que contiene el recurso de especificación de plantilla. Del mismo modo, cuando publica un módulo de Bicep en un registro, el usuario de Microsoft Entra debe tener permiso para escribir en la instancia de Azure Container Registry que usa su organización para sus módulos de Bicep.

Cuando trabaja con un flujo de trabajo de implementación automatizado, se aplican los mismos principios. Sin embargo, dado que no es la persona que ejecuta la implementación, debe asegurarse de que la identidad del flujo de trabajo tenga el acceso adecuado al grupo de recursos para publicar la especificación de plantilla o al registro de contenedor para publicar módulos.

Sugerencia

Cuando publica un módulo en un registro, la identidad de carga de trabajo que ejecuta la implementación probablemente no necesite muchos permisos. Cuando el registro usa la autorización de Microsoft Entra, la identidad de carga de trabajo solo necesita el permiso AcrPush en el registro.

Considere la posibilidad de usar el principio de privilegios mínimos de seguridad. Proporcione a la identidad de carga de trabajo del flujo de trabajo acceso solo al registro de contenedor y no a un grupo de recursos ni a una suscripción.

Publicación de especificaciones de plantilla y módulos desde un flujo de trabajo

Cuando publique una especificación de plantilla desde su propio equipo mediante la CLI de Azure, use un comando como el siguiente:

az ts create \
  --name StorageWithoutSAS \
  --location westus3 \
  --display-name "Storage account with SAS disabled" \
  --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
  --version 1 \
  --template-file main.bicep

Puede convertir este comando de la CLI de Azure en un paso de Acciones de GitHub:

- name: Publish template spec
  uses: azure/cli@v1
  with:
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --location westus3 \
        --display-name "Storage account with SAS disabled" \
        --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
        --version 1 \
        --template-file main.bicep

El flujo de trabajo usa el mismo proceso que usaría usted mismo para publicar la especificación de plantilla.

De forma similar, cuando publique un módulo de Bicep desde su propio equipo mediante la CLI de Azure, use un comando como el siguiente:

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

También puede convertir este comando de la CLI de Azure en un paso de Acciones de GitHub:

- name: Publish Bicep module
  uses: azure/cli@v1
  with:
    inlineScript: |
      az bicep publish \
        --file module.bicep \
        --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Sugerencia

En este ejemplo, el nombre de host del registro de Bicep (toycompany.azurecr.io) está insertado en la definición del paso de flujo de trabajo. Este no es un procedimiento recomendado. Puede usar variables de entorno para establecer opciones de configuración como esta. Verá cómo funciona más adelante en este módulo de formación de Microsoft Learn.

En breve verá cómo puede publicar una especificación de plantilla desde un flujo de trabajo mediante los pasos descritos en esta unidad.

Uso de un módulo o una especificación de plantilla

En los módulos de formación anteriores de Microsoft Learn ha aprendido a implementar los recursos definidos en especificaciones de plantilla y a usar módulos de Bicep almacenados en registros. Tanto si publica las especificaciones de plantilla como los módulos manualmente o desde un flujo de trabajo de implementación, los usará e implementará de la misma manera.

Por ejemplo, implementa una especificación de plantilla o un archivo de Bicep en un grupo de recursos mediante el comando az deployment group create de la CLI de Azure o el cmdlet New-AzResourceGroupDeployment con Azure PowerShell.