Compartir vía


Implementación de recursos con Bicep y Azure PowerShell

En este artículo, se explica el uso de Azure PowerShell con archivos de Bicep para implementar recursos en Azure. Si no conoce los conceptos de implementación y administración de las soluciones de Azure, consulte Introducción a Bicep.

Requisitos previos

Necesita un archivo de Bicep para implementarlo. El archivo debe ser local.

Necesita Azure PowerShell y estar conectado a Azure:

Si no tiene instalado PowerShell, puede usar Azure Cloud Shell. Para más información, consulte Implementación de archivos Bicep desde Azure Cloud Shell.

Permisos necesarios

Para implementar un archivo de Bicep o una plantilla de ARM, se necesita acceso de escritura en los recursos que implementa y acceso a todas las operaciones del tipo de recurso Microsoft.Resources/deployments. Por ejemplo, para implementar una máquina virtual, necesita los permisos Microsoft.Compute/virtualMachines/write y Microsoft.Resources/deployments/*. La operación what-if tiene los mismos requisitos de permisos.

Para obtener una lista de roles y permisos, consulte Roles integrados de Azure.

Ámbito de la implementación

La implementación puede tener como destino un grupo de recursos, una suscripción, un grupo de administración o un inquilino. Según el ámbito de la implementación, usará comandos diferentes.

Para cada ámbito, el usuario que implementa la plantilla debe tener permisos para crear recursos.

Implementación de un archivo Bicep local

Puede implementar un archivo Bicep desde la máquina local o una que esté almacenada externamente. En esta sección se describe la implementación de un archivo Bicep local.

Si va a realizar la implementación en un grupo de recursos que no existe, cree el grupo de recursos. El nombre del grupo de recursos solo puede incluir caracteres alfanuméricos, puntos, guiones bajos, guiones y paréntesis. Puede tener hasta 90 caracteres. El nombre no puede terminar con un punto.

New-AzResourceGroup -Name ExampleGroup -Location "Central US"

Para implementar un archivo Bicep, use el conmutador -TemplateFile en el comando de implementación.

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleGroup `
  -TemplateFile <path-to-bicep>

La implementación puede tardar unos minutos en finalizar.

Implementación de un archivo Bicep remoto

Actualmente, Azure PowerShell no admite la implementación de archivos Bicep remotos. Use la CLI de Bicep para compilar el archivo de Bicep en una plantilla JSON y luego cargue el archivo JSON en la ubicación remota.

Parámetros

Para pasar valores de parámetros, puede usar parámetros en línea o un archivo de parámetros. El archivo de parámetros puede ser un archivo de parámetros de Bicep o un archivo de parámetros JSON.

Parámetros en línea

Para pasar parámetros en línea, proporcione los nombres de parámetro con el comando New-AzResourceGroupDeployment. Por ejemplo, para pasar una cadena y una matriz a un archivo de Bicep, use:

$arrayParam = "value1", "value2"
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -exampleString "inline string" `
  -exampleArray $arrayParam

Puede usar el parámetro TemplateParameterObject para pasar a través de una tabla hash que contenga los parámetros de la plantilla.

$params = @{
  exampleString = "inline string"
  exampleArray = "value1", "value2"
}

New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -TemplateParameterObject $params

También puede obtener el contenido del archivo y proporcionar ese contenido como un parámetro en línea.

$arrayParam = "value1", "value2"
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -exampleString $(Get-Content -Path c:\MyTemplates\stringcontent.txt -Raw) `
  -exampleArray $arrayParam

Obtener un valor de parámetro de un archivo es útil cuando se necesita proporcionar valores de configuración. Por ejemplo, puede proporcionar valores de cloud-init para una máquina virtual Linux.

Si necesita pasar una matriz de objetos, cree las tablas hash en PowerShell y agréguelas a una matriz. Pase esa matriz como un parámetro durante la implementación.

$hash1 = @{ Name = "firstSubnet"; AddressPrefix = "10.0.0.0/24"}
$hash2 = @{ Name = "secondSubnet"; AddressPrefix = "10.0.1.0/24"}
$subnetArray = $hash1, $hash2
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -exampleArray $subnetArray

Archivos de parámetros de Bicep

En lugar de pasar parámetros como valores insertados en el script, puede resultarle más fácil usar un archivo de parámetros, ya sea un archivo de .bicepparam o un archivo de parámetros JSON, que contenga los valores de los parámetros. El archivo de parámetros Bicep debe ser un archivo local.

Con la versión 10.4.0 o posterior de Azure PowerShell yversión 0.22.X o posterior de la CLI de Bicep, puede implementar un archivo de Bicep mediante el uso de un archivo de parámetros de Bicep. Con la instrucción using en el archivo de parámetros de Bicep, no es necesario proporcionar el modificador -TemplateFile al especificar un archivo de parámetros de Bicep para el modificador -TemplateParameterFile.

En el ejemplo siguiente, se muestra un archivo de parámetros denominado storage.bicepparam. El archivo está ubicado en el mismo directorio donde se ejecuta el comando.

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateParameterFile storage.bicepparam

Para más información sobre el archivo de parámetros, consulte Creación de un archivo de parámetros de Resource Manager.

Archivo de parámetros JSON

El archivo de parámetros JSON puede ser un archivo local o un archivo externo con un identificador URI accesible. Para más información sobre el archivo de parámetros, consulte Creación de un archivo de parámetros de Resource Manager.

Para pasar un archivo de parámetros local, use el modificador TemplateParameterFile con un archivo de parámetros JSON:

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateFile c:\BicepFiles\storage.bicep `
  -TemplateParameterFile c:\BicepFiles\storage.parameters.json

Para pasar un archivo de parámetros externo, use el parámetro TemplateParameterUri:

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateFile c:\BicepFiles\storage.bicep `
  -TemplateParameterUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.parameters.json

El parámetro TemplateParameterUri no admite archivos .bicepparam; solo admite archivos de parámetros JSON.

Puede usar parámetros en línea y un archivo de parámetros de ubicación en la misma operación de implementación. Para obtener más información, consulte Precedencia de parámetros.

Vista previa de los cambios

Antes de implementar el archivo Bicep, puede obtener una vista previa de los cambios que el archivo Bicep realizará en su entorno. Use la operación "what-if" para comprobar que la plantilla realiza los cambios esperados. La operación "what-if" también valida que el archivo Bicep no tenga errores.

Especificaciones de la implementación de la plantilla

Actualmente, Azure PowerShell no admite la creación de especificaciones de plantilla mediante archivos Bicep. Pero puede crear un archivo de Bicep con el recurso Microsoft.Resources/templateSpecs para implementar una especificación de plantilla. En el ejemplo Creación de una especificación de plantilla se muestra cómo crear una especificación de plantilla en un archivo de Bicep. También puede compilar el archivo Bicep en JSON mediante la CLI de Bicep y luego crear una especificación de plantilla con la plantilla JSON.

Nombre de implementación

Al implementar un archivo Bicep, puede asignarle un nombre a la implementación. Este nombre puede ayudarle a recuperar la implementación del historial de implementaciones. Si no especifica un nombre para la implementación, se utilizará el nombre del archivo Bicep. Por ejemplo, si implementa un archivo de Bicep llamado main.bicep y no especifica ningún nombre para la implementación, se le asignará el nombre main.

Cada vez que se ejecuta una implementación, se agrega una entrada al historial de implementación del grupo de recursos con el nombre de la implementación. Si ejecuta otra implementación y le asigna el mismo nombre, la entrada anterior se reemplazará por la implementación actual. Si desea que todas las entradas del historial de implementaciones sean diferentes, asigne un nombre único a cada implementación.

Para crear un nombre único, puede asignar un número aleatorio.

$suffix = Get-Random -Maximum 1000
$deploymentName = "ExampleDeployment" + $suffix

También puede agregar un valor de fecha.

$today=Get-Date -Format "MM-dd-yyyy"
$deploymentName="ExampleDeployment"+"$today"

Si ejecuta implementaciones simultáneas en el mismo grupo de recursos utilizando el mismo nombre de implementación, solo se completará la última implementación. Aquellas implementaciones que tengan el mismo nombre y no hayan finalizado se sustituirán por la última implementación. Por ejemplo, si ejecuta una implementación llamada newStorage que implementa la cuenta de almacenamiento storage1 y, al mismo tiempo, ejecuta otra implementación llamada newStorage que implementa la cuenta de almacenamiento storage2, solo se implementará una única cuenta de almacenamiento. La cuenta de almacenamiento resultante será storage2.

Sin embargo, si ejecuta una implementación llamada newStorage que implementa la cuenta de almacenamiento storage1 e inmediatamente después ejecuta otra implementación llamada newStorage que implementa la cuenta de almacenamiento storage2, tendrá dos cuentas de almacenamiento. Una se llamará storage1 y la otra, storage2. Sin embargo, solo tendrá una entrada en el historial de implementaciones.

Si especifica un nombre único para cada implementación, podrá ejecutarlas simultáneamente sin conflictos. Si ejecuta una implementación llamada newStorage1 que implementa la cuenta de almacenamiento storage1 y, al mismo tiempo, ejecuta otra implementación llamada newStorage2 que implementa la cuenta de almacenamiento storage2, tendrá dos cuentas de almacenamiento y dos entradas en el historial de implementación.

Para evitar conflictos con las implementaciones simultáneas y garantizar que las entradas del historial de implementaciones sean únicas, asigne un nombre diferente a cada implementación.

Pasos siguientes