Preparación para la Certificación Microsoft AZ-104
Plantillas de ARM: estructura JSON, parámetros, salidas e implementación
Infraestructura como código, orquestación de Azure Resource Manager, secciones JSON, proveedores, implementaciones locales y vinculadas, parámetros seguros, salidas, idempotencia y ejercicio guiado con una cuenta de almacenamiento.
Tiempo de estudio sugerido: 35 minutos • Nivel intermedio • Reescritura original basada en el módulo proporcionado de Microsoft Learn
Por João Ricardo Dutra••Contenido original completo
1. Introducción, escenario y objetivos de aprendizaje
Las plantillas de , normalmente llamadas plantillas de ARM, describen la infraestructura y la configuración de en archivos reutilizables. La plantilla puede guardarse en el mismo repositorio de código fuente que la aplicación, de modo que los cambios de infraestructura se revisen, versionen y publiquen con el software.
Imagine un equipo que desarrolla una plataforma de inventario para varias empresas asociadas. Cada empresa necesita una implementación independiente en y las directivas de almacenamiento pueden variar. Las instrucciones manuales harían que los entornos divergieran. Una plantilla de versionada ofrece una base coherente, mientras que los parámetros conservan la flexibilidad de cada implementación.
Objetivos de aprendizaje
Implementar una plantilla de con .
Explicar la infraestructura como código declarativa y la estructura de una plantilla.
Implementar una plantilla local mediante la CLI de o .
Declarar recursos con proveedores, tipos, versiones de y propiedades.
Hacer reutilizable la plantilla con parámetros, restricciones de validación y salidas.
Completar el ejercicio de la cuenta de almacenamiento, revisar el historial e interpretar la validación.
Requisitos previos
Familiaridad con , Microsoft Azure Portal, suscripciones, grupos de recursos y definiciones de recursos.
Una cuenta de con permisos para crear los recursos del ejercicio.
instalado localmente.
La versión más reciente de la CLI de o instalada localmente.
Microsoft recomienda a quienes comienzan con infraestructura como código en porque ofrece las capacidades de las plantillas de con una experiencia de creación más concisa. Este capítulo estudia porque conocer la estructura generada sigue siendo valioso para la administración y la solución de problemas de AZ-104.
La infraestructura como código mantiene aplicación y entorno versionados juntos; una plantilla crea implementaciones coherentes de desarrollo, prueba y producción.
2. Infraestructura como código y plantillas declarativas
La infraestructura como código, o IaC, representa mediante código la infraestructura que necesita una aplicación, en vez de depender de una secuencia de acciones manuales en el portal. Los archivos de aplicación y las definiciones de implementación comparten repositorio, revisión e historial.
Ventajas destacadas por el módulo proporcionado.
Ventaja
Efecto operativo
Configuraciones coherentes
La misma definición revisada crea o actualiza cada entorno.
Mejor escalabilidad
La automatización repite la implementación para cada empresa o entorno.
Implementaciones más rápidas
Resource Manager ordena dependencias y crea recursos independientes en paralelo.
Mejor rastreabilidad
El repositorio y el historial de muestran la definición y los valores usados.
Una plantilla de es un archivo , JavaScript Object Notation. La sintaxis declarativa indica qué recursos y propiedades deben existir sin especificar cada paso de control necesario. Un script imperativo, en cambio, se centra en la secuencia de comandos que debe ejecutar el equipo.
convierte el estado deseado en operaciones de implementación. El autor se concentra en el resultado y la plataforma se ocupa de validación, dependencias, orden y paralelismo.
3. Por qué las plantillas de ARM son repetibles
Automatización: la plantilla forma parte del proyecto, no de una lista externa de pasos.
Control de versiones: los archivos pueden almacenarse, compararse, revisarse y etiquetarse como el código de aplicación.
Idempotencia: repetir la misma definición con las mismas entradas conserva el estado deseado y no crea duplicados.
Orquestación de dependencias: Resource Manager respeta el orden necesario y ejecuta trabajo independiente en paralelo.
Validación previa: las comprobaciones estructurales y de implementación pueden fallar antes de crear recursos.
Modularidad: las soluciones grandes pueden usar plantillas vinculadas más pequeñas o plantillas anidadas.
Auditoría: Microsoft Azure Portal muestra estado, plantilla, parámetros y salidas.
Integración de CI/CD: , GitHub Actions y pueden publicar aplicación e infraestructura juntos.
Una plantilla vinculada se almacena por separado y la invoca una plantilla principal. Si el contenido privado está en , una firma de acceso compartido, o SAS, puede protegerlo. La implementación principal activa las plantillas vinculadas.
Resource Manager valida la declaración, resuelve dependencias, llama a los proveedores y registra el resultado.
4. Estructura del archivo de plantilla de
Una plantilla de se organiza en secciones de nivel superior. Algunas son obligatorias para una plantilla habitual con ámbito de grupo de recursos; otras solo se incluyen cuando la solución las necesita.
Secciones representadas en el material proporcionado.
Elemento
¿Obligatorio?
Finalidad
$
Sí
del esquema que describe la estructura; depende del ámbito y del editor.
contentVersion
Sí
Versión asignada por el autor, como 1.0.0.0, para documentar cambios importantes.
apiProfile
No
Colección de versiones de que puede evitar declarar una versión por cada tipo compatible.
parameters
No
Valores proporcionados por archivo de parámetros, línea de comandos o Microsoft Azure Portal.
variables
No
Valores reutilizables que simplifican expresiones del lenguaje de plantilla.
functions
No
Funciones definidas por el usuario para sustituir expresiones repetidas o complejas.
resources
Sí
Recursos que se crearán o actualizarán en el grupo, la suscripción u otro ámbito.
outputs
No
Valores devueltos tras la implementación. La tabla exportada usa output, pero la propiedad real es outputs.
contentVersion pertenece al autor; no lo incrementa automáticamente. Las versiones de de los recursos son distintas: cada declaración elige el contrato del proveedor correspondiente.
La estructura separa entradas, expresiones reutilizables, declaraciones de recursos y valores devueltos.
5. Formas de implementar una plantilla en
El módulo presenta tres rutas: plantilla local, plantilla vinculada y canalización de implementación continua. La práctica se centra en el archivo local, que requiere la CLI de o .
Preparar el grupo de recursos con la CLI de
az login
az account list-locations --output table
az group create --name rg-contoso-inventario --location eastus
La CLI de puede guardar una región predeterminada mediante az configure --defaults location=<ubicación>. enumera las regiones con -AzLocation. Después, use el comando actual para el ámbito de grupo:
templateFile="azuredeploy.json"
az deployment group create --name almacenamiento-inventario-v1 --resource-group rg-contoso-inventario --template-file $templateFile
La forma antigua az group create está en desuso; use az group create. El cmdlet equivalente de es New-AzResourceGroupDeployment.
Las plantillas vinculadas dividen la solución entre una plantilla principal y plantillas secundarias reutilizables; un SAS puede proteger archivos privados. y GitHub Actions pueden validar e implementar la plantilla dentro del flujo de la aplicación.
Use nombres descriptivos, porque cada ejecución crea una entrada en el historial. Las herramientas necesitan el grupo de destino y algunos ámbitos también exigen ubicación. El portal muestra estado, parámetros y salidas.
La plantilla puede comenzar en el equipo, en una dirección protegida o en CI/CD; Resource Manager sigue siendo el motor.
6. Declarar recursos con proveedores, tipos y propiedades
Cada tipo de recurso de pertenece a un proveedor. La plantilla combina el y el tipo como proveedor/tipo. Para una cuenta de almacenamiento, Microsoft. y storageAccounts forman Microsoft./storageAccounts.
Después de elegir el tipo, consulte la referencia de plantillas de ARM para ver las propiedades de la versión de . Una declaración suele incluir type, apiVersion, name, location y valores específicos como sku, kind y properties.
Fijar nombre, región y SKU facilita la lectura inicial, pero limita la reutilización. Los parámetros y las funciones eliminan esas suposiciones.
7. Parámetros, restricciones y protección de secretos
La sección parameters define entradas resueltas antes de las operaciones. Los valores distintos permiten usar una plantilla en desarrollo, prueba, producción o para varias empresas. Una plantilla admite hasta 256 parámetros y puede usar la mayoría de las funciones en sus definiciones.
Propiedades de parámetros cubiertas por el material.
Propiedad
Finalidad
type
Tipo de dato obligatorio.
defaultValue
Valor usado cuando la implementación no proporciona otro.
allowedValues
Lista explícita de valores aceptados.
minValue / maxValue
Límites numéricos inclusivos para enteros.
minLength / maxLength
Límites inclusivos de longitud para cadenas o matrices.
.description
Orientación legible para el usuario de la plantilla.
Los tipos clásicos mostrados son string, secureString, int, bool, object, secureObject y array. Use parámetros para SKU, capacidad, tamaño, región y nombres sujetos a convenciones. Proporcione descripciones y valores predeterminados seguros cuando correspondan.
Nunca codifique nombres de usuario, contraseñas o secretos ni les asigne valores predeterminados. Use secureString para cadenas secretas y secureObject para objetos sensibles. No se guardan en historial ni registros. Para reutilizarlos, almacénelos en y haga referencia desde un archivo de parámetros.
"parameters": {
"storageName": {
"type": "string",
"minLength": 3,
"maxLength": 24,
"metadata": { "description": "Nombre único global de la cuenta de almacenamiento" }
},
"storageSku": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS", "Standard_GRS", "Standard_RAGRS", "Standard_ZRS",
"Premium_LRS", "Premium_ZRS", "Standard_GZRS", "Standard_RAGZRS"
]
}
}
8. Usar parámetros en la plantilla de almacenamiento
La función parameters accede a una entrada. El nombre y la etiqueta displayName usan storageName, la SKU usa storageSku y resourceGroup().location conserva el recurso en la región del grupo de destino.
Los valores pueden proceder de la línea de comandos, un archivo de parámetros o Microsoft Azure Portal. La CLI de puede reemplazar la SKU predeterminada:
az deployment group create --name almacenamiento-inventario-prueba --resource-group rg-contoso-inventario --template-file azuredeploy.json --parameters storageName=contosoinventario001 storageSku=Standard_GRS
Un valor predeterminado reduce repetición; allowedValues impide que el usuario envíe opciones que el recurso no debe aceptar.
Los parámetros separan entradas del entorno; las salidas ofrecen información para pasos posteriores.
9. Salidas e implementación repetida segura
La sección outputs devuelve valores después de una implementación correcta. Resulta útil cuando otra etapa, script o configuración necesita información del recurso creado.
Elementos de una salida.
Elemento
¿Obligatorio?
Significado
output-name
Sí
Identificador JavaScript válido que nombra la salida.
type
Sí
Tipo de dato del valor devuelto.
condition
No
Expresión booleana que decide si se devuelve; el valor predeterminado es true.
value
No
Expresión del lenguaje evaluada y devuelta.
copy
No
Definición de iteración para devolver varios valores.
reference lee el estado de ejecución de la cuenta y devuelve puntos de conexión primarios como blob, archivo, cola, tabla, DFS y web cuando corresponda. El límite actual es de 64 salidas.
La idempotencia permite repetir de forma segura: sin cambios en plantilla o entradas, los recursos permanecen iguales. Si cambia una propiedad, Resource Manager aplica la actualización necesaria y solo crea lo que no existe.
10. Ejercicio guiado: parámetros, validación y salidas
El ejercicio modifica azuredeploy. en pasos observables. Alt+Mayús+F da formato al en ; guarde después de cada cambio y use IntelliSense.
Paso 1 - Parametrizar el nombre
Agregue storageName como string con minLength 3, maxLength 24 y descripción.
Use el parámetro en el nombre del recurso y en la etiqueta displayName.
Elija un nombre único global. La regla actual solo permite letras minúsculas y números; la mención de guiones del PDF está desactualizada.
Reutilice el mismo nombre válido para actualizar la cuenta existente.
Agregue storageSku con Standard_LRS y los ocho valores del ejercicio: Standard_LRS, Standard_GRS, Standard_RAGRS, Standard_ZRS, Premium_LRS, Premium_ZRS, Standard_GZRS y Standard_RAGZRS. Las plantillas admiten comentarios // y /* ... */, por lo que puede documentar la lista en el archivo.
La ejecución con un valor permitido finaliza correctamente. Repita con -storageSku "Basic" para ver que allowedValues rechaza el valor durante la validación.
Paso 3 - Devolver e inspeccionar los puntos de conexión
Agregue storageEndpoints a outputs mediante reference(parameters('storageName')).primaryEndpoints. Implemente con una SKU permitida. imprime el objeto y Microsoft Azure Portal también lo muestra.
Abra el grupo de recursos y seleccione el vínculo de implementaciones correctas.
Compare las entradas de la plantilla base, el parámetro de nombre, la validación de SKU y las salidas.
Abra la implementación de salidas y revise Entradas, Salidas y la plantilla.
Confirme que el contiene los puntos de conexión expuestos por la cuenta.
Una SKU permitida funciona, una no permitida falla, las salidas revelan puntos de conexión y repetir sin cambios conserva el recurso.
11. Comprobación de conocimientos explicada
Evaluación reformulada a partir del módulo.
Pregunta
Mejor respuesta
Justificación
¿Qué es una plantilla de ?
Un archivo que define infraestructura y configuración de una implementación.
Es una definición declarativa, no una serie de comandos ni un script exclusivo de almacenamiento.
¿Qué opción no es un elemento: idempotent, o parameters?
idempotent
La idempotencia es un comportamiento; y parameters son secciones.
¿Qué ocurre al repetir sin cambios una plantilla idempotente?
Resource Manager no modifica recursos que ya coinciden con el estado deseado.
No crea copias ni elimina y vuelve a implementar sin un cambio declarado.
12. Resumen del capítulo
Las plantillas de expresan infraestructura declarativa, reutilizable y versionable.
Resource Manager valida, resuelve dependencias, llama a proveedores y registra el historial.
La estructura separa esquema, versión, parámetros, variables, funciones, recursos y salidas.
Las plantillas locales usan la CLI de o ; las vinculadas y CI/CD cubren escenarios modulares o automáticos.
Los parámetros validan valores de cada entorno y los tipos seguros protegen secretos.
Las salidas devuelven información y la idempotencia permite repetir el estado deseado.
El ejercicio parametriza una cuenta, restringe la SKU, prueba un valor no válido y devuelve sus puntos de conexión.
