Administración de una especificación de plantilla

Completado

Las especificaciones de plantilla proporcionan una manera cómoda de publicar y compartir plantillas dentro de la organización. A medida que se usan más las especificaciones de plantilla, es importante comprender cómo administrarlas.

En esta unidad, aprenderá sobre el control de versiones, cómo modificar y eliminar especificaciones de plantilla y cómo controlar el acceso a las especificaciones de plantilla.

Nota:

Los comandos de esta unidad se muestran para ilustrar conceptos. No los ejecute todavía. Pronto va a practicar lo que aprenderá aquí.

Adición de versiones

Ha aprendido que una única especificación de plantilla puede tener varias versiones. Una especificación de plantilla actúa como un contenedor para una o varias versiones, y cada versión está asociada a un archivo de plantilla. Al implementar una especificación de plantilla, debe especificar la versión que desea usar para que Azure Resource Manager sepa el archivo de plantilla que se va a recuperar.

Las CLI de Azure y Azure PowerShell facilitan el trabajo con varias versiones. De hecho, ya ha trabajado con versiones cuando implementó la especificación de plantilla en el ejercicio anterior.

Es una buena idea planear cuidadosamente cómo va a crear las versiones de las especificaciones de plantilla. Dos decisiones clave que se deben tomar son el esquema de control de versiones y la directiva de control de versiones que se van a usar.

Esquemas de control de versiones

El esquema de control de versiones determina cómo se generan los números de versión. Entre los esquemas de control de versiones comunes, se encuentran:

• Los enteros básicos se pueden usar como números de versión. Por ejemplo, la primera versión podría llamarse 1, la segunda versión 2, etc.
• Las fechas también son adecuadas como números de versión. Por ejemplo, si publica la primera versión de la especificación de plantilla el 16 de enero de 2021, podría asignar el nombre 2021-01-16 a la versión (con el formato aaaa-mm-dd). Al publicar otra versión el 3 de marzo, podría asignar el nombre 2021-03-03.
• El versionamiento semántico es un sistema de control de versiones que se usa a menudo en software, en el que un único número de versión contiene varias partes. Cada parte indica información diferente sobre la naturaleza del cambio.

Aunque puede usar el esquema de control de versiones que quiera, es recomendable elegir algo que se pueda clasificar con un orden significativo, como números y fechas.

Nota:

Azure almacena la fecha en que se crea cada versión. Incluso si no usa un control de versiones basado en fechas, todavía puede ver esta información.

Directivas de control de versiones

Las especificaciones de plantilla ofrecen la flexibilidad de elegir cuándo crear nuevas versiones o actualizar una versión existente. Por ejemplo, puede optar por no utilizar el control de versiones de forma eficaz mediante la creación y publicación de una única versión llamada latest. Siempre que tenga que cambiar la especificación de plantilla, simplemente actualice esa versión. Aunque esta directiva funciona, no es un procedimiento recomendado.

Por el contrario, si realiza un pequeño cambio en una plantilla existente que no afecta a su uso, es posible que la creación de una nueva versión no sea una buena idea. Tendría que comunicar el nuevo número de versión a cualquier persona que use la especificación de plantilla.

Esta es una directiva de control de versiones que a menudo funciona bien:

• Cada vez que realice cambios significativos en una especificación de plantilla, cree una nueva versión. Los cambios significativos en la especificación de plantilla incluyen cualquier cosa que pueda marcar la diferencia con el usuario que la implementa. Entre los ejemplos se incluye agregar otro recurso a la plantilla o cambiar las propiedades de un recurso.
• Cada vez que realice pequeños cambios en una especificación de plantilla, lo que a veces se llama revisión, actualice la versión de la especificación de plantilla existente.
• Elimine las versiones anteriores cuando ya no sean pertinentes o cuando no desee que nadie las use.

Sugerencia

Tenga en cuenta a los usuarios de la especificación de plantilla y asegúrese de pensar en lo que esperan que suceda. Si un usuario implementa la especificación de plantilla varias veces y obtiene un resultado y, a continuación, la implementa de nuevo después de una revisión y obtiene un resultado diferente, es probable que se sorprenda. Intente minimizar la probabilidad de que los usuarios obtengan un resultado que no esperan.

Descripciones de la versión

Al crear una nueva versión de una especificación de plantilla, puede asignar opcionalmente una descripción de la versión. Proporcionar una descripción de la versión es un procedimiento recomendado, incluso si no es necesario. La descripción de la versión resume los cambios realizados para ayudar a cualquier persona que use la especificación de plantilla a seleccionar la versión que mejor se adapte a sus necesidades.

Realización de cambios en una especificación de plantilla

Las especificaciones de plantilla son recursos de Azure, por lo que puede administrarlas como cualquier otro recurso. Esto significa que puede ver los detalles de una especificación de plantilla, actualizarla y eliminarla, como de costumbre.

Por ejemplo, para enumerar las versiones de una especificación de plantilla, use el cmdlet Get-AzTemplateSpec:

Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec

El mismo cmdlet se usa para ver una versión de una especificación de plantilla. Agregue el parámetro -Version para obtener los detalles de una versión:

Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0

Para acceder a la plantilla JSON, lea la propiedad MainTemplate desde dentro de la matriz Versions:

(Get-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
).Versions[0].MainTemplate

Por ejemplo, para enumerar las versiones de una especificación de plantilla, use el comando az ts show:

az ts show \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec

El mismo comando se usa para ver una versión de una especificación de plantilla. Agregue el argumento --version para obtener los detalles de una versión:

az ts show \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0

La plantilla JSON se incluye en la salida.

Nota:

Al publicar un archivo de Bicep en una especificación de plantilla, se convierte a formato JSON. No puede ver el archivo de Bicep original, por lo que es una buena idea conservarlo en otro lugar.

Para actualizar una especificación de plantilla existente, use el cmdlet Set-AzTemplateSpec. Por ejemplo, puede usar este cmdlet para aplicar una revisión a una versión que ya ha publicado:

Set-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
  -TemplateFile azuredeploy.json

Y puede eliminar una versión de la especificación de plantilla mediante el cmdlet Remove-AzTemplateSpec:

Remove-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0

Para actualizar una especificación de plantilla existente, use el comando az ts update. Por ejemplo, puede usar este comando para aplicar una revisión a una versión que ya ha publicado:

az ts update \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0 \
  --template-file azuredeploy.json

Y puede eliminar una versión de la especificación de plantilla mediante el comando az ts delete:

az ts delete \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0

Exportación de una especificación de plantilla

Después de publicar una plantilla como una especificación de plantilla, puede exportarla. Al exportar una especificación de plantilla, se descarga el archivo de plantilla en el equipo local. Una vez allí, puede editar el archivo de plantilla o simplemente inspeccionarlo para entender lo que hace.

Sugerencia

Si la especificación de plantilla incluye plantillas vinculadas, la exportación de una especificación de plantilla también descargará las plantillas vinculadas. Incluso se mantiene la estructura de carpetas.

Importante

Al publicar un archivo de Bicep como especificación de plantilla, el código de Bicep se convierte en una plantilla JSON. El proceso de conversión del código de Bicep a JSON quita parte de la información del archivo de Bicep. Por ejemplo, los comentarios, los nombres simbólicos de los recursos y el orden en que se definen los recursos podrían faltar o ser diferentes en formato JSON. Esto significa que no puede publicar fácilmente un archivo de Bicep como especificación de plantilla y, a continuación, obtener el archivo de Bicep original (también llamado ida y vuelta). Es una buena idea mantener una copia del código de Bicep original en un repositorio de código como Git, especialmente cuando se trabaja con especificaciones de plantilla.

Para exportar una especificación de plantilla, use el cmdlet Export-AzTemplateSpec. Use el valor -OutputFolder para especificar dónde desea guardar los archivos de plantilla:

Export-AzTemplateSpec `
  -ResourceGroupName MyResourceGroup `
  -Name MyTemplateSpec `
  -Version 1.0 `
  -OutputFolder ./mytemplate

Para exportar una especificación de plantilla, use el comando az ts export. Use el valor --output-folder para especificar dónde desea guardar los archivos de plantilla:

az ts export \
  --resource-group MyResourceGroup \
  --name MyTemplateSpec \
  --version 1.0 \
  --output-folder ./mytemplate

Control del acceso a una especificación de plantilla

Dado que las especificaciones de plantilla son recursos de Azure, usan la Administración de identidad y acceso (IAM) de Azure. Cuando un usuario implementa una especificación de plantilla, Azure comprueba primero que el usuario tenga acceso para leer la especificación de plantilla.

Nota:

Para implementar una especificación de plantilla, un usuario necesita:

• Acceso para leer la especificación de plantilla.
• Acceso para implementar en el grupo de recursos u otro ámbito en el que se solicite la implementación.

Azure comprueba ambas condiciones antes de que se inicie la implementación.