Anterior

Siguientes

Agrupación de recursos relacionados mediante módulos

Completado

Empezó a usar plantillas de Bicep en algunos lanzamientos recientes de productos y han funcionado bien. Dado que ha declarado los recursos en un archivo de plantilla, puede implementar rápidamente los recursos para nuevos lanzamientos de juguetes sin necesidad de configurarlos manualmente en Azure Portal.

El administrador de TI puede ver que el código de Bicep es cada vez más complejo y tiene un número creciente de recursos definidos, por lo que le han pedido que haga el código más modular. Puede crear archivos de Bicep individuales, denominados módulos, para diferentes partes de la implementación. La plantilla principal de Bicep puede hacer referencia a estos módulos. En segundo plano, los módulos se transpilan en una sola plantilla JSON para la implementación.

Los módulos también son una manera de que el código de Bicep sea aún más reutilizable. Puede tener un solo módulo de Bicep que usen muchas otras plantillas de Bicep.

Con frecuencia también tendrá que emitir salidas de los módulos y las plantillas de Bicep. Las salidas son una manera de que el código de Bicep reenvíe datos a quien sea, o lo que sea, que haya iniciado la implementación. Echemos un vistazo primero a las salidas.

Nota:

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

Salidas

Las plantillas de Bicep las puede implementar manualmente una persona, o bien se pueden implementar mediante algún tipo de proceso de lanzamiento automatizado. En cualquier caso, es habitual tener algunos datos de la plantilla que necesita reenviar a quien esté ejecutando la implementación de la plantilla.

Estos son algunos escenarios de ejemplo en los que es posible que necesite obtener información de la implementación de la plantilla:

• Ud. crea una plantilla de Bicep que implementa una máquina virtual, y necesita obtener la dirección IP pública para poder conectarse a la máquina mediante SSH.
• Crea una plantilla de Bicep que acepta un conjunto de parámetros, como un nombre de entorno y un nombre de aplicación. La plantilla usa una expresión para nombrar una aplicación de Azure App Service que se implementa. Debe generar el nombre de la aplicación que la plantilla ha implementado para que puede usar dentro de una canalización de implementación para publicar los binarios de la aplicación.

Puede usar salidas en estos escenarios: Para definir una salida en una plantilla de Bicep, use la palabra clave output, como aquí:

output appServiceAppName string = appServiceAppName

La definición de salida incluye algunas partes principales:

• La palabra clave output indica a Bicep que Ud. está definiendo una salida.
• appServiceAppName es el nombre de la salida. Cuando alguien implemente la plantilla correctamente, los valores de salida incluirán el nombre que Ud. ha especificado para que esa persona pueda acceder a los valores que espera.
• string es el tipo de salida. Las salidas de Bicep admiten los mismos tipos que los parámetros.
• Se debe especificar un valor para cada salida. A diferencia de los parámetros, las salidas siempre deben tener valores. Los valores de salida pueden ser expresiones, referencias a parámetros o variables, o también propiedades de recursos que se implementan en el archivo.

Sugerencia

Las salidas pueden usar los mismos nombres que las variables y los parámetros. Esta convención puede ser útil si construye una expresión compleja dentro de una variable para usarla dentro de los recursos de la plantilla, pero también necesita exponer el valor de la variable como salida.

Este es otro ejemplo de una salida. Esta tendrá su valor establecido en el nombre de dominio completo (FQDN) de un recurso de dirección IP pública.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Sugerencia

Pruebe a usar las propiedades de recursos como salidas, en lugar de realizar suposiciones sobre cómo se comportarán los recursos. Por ejemplo, si necesita tener una salida para la dirección URL de una aplicación de App Service, use la propiedad defaultHostName en lugar de crear una cadena para la dirección URL por su cuenta. A veces, estas suposiciones no son válidas en otros entornos, o cambia el funcionamiento de los recursos, por lo que es más seguro que el recurso le indique sus propias propiedades.

Precaución

No cree salidas para valores secretos, como cadenas de conexión o claves. Cualquier persona con acceso al grupo de recursos puede leer las salidas de las plantillas. Hay otras estrategias que puede usar para obtener acceso a las propiedades de los recursos secretos, y que se tratarán en un módulo posterior.

Definición de un módulo

Los módulos de Bicep permiten organizar y reutilizar el código de Bicep mediante la creación de unidades más pequeñas que se pueden combinar en una plantilla. Cualquier plantilla de Bicep se puede usar como módulo por otra plantilla. A lo largo de este módulo de aprendizaje, creó plantillas de Bicep. Esto significa que ya ha creado archivos que se pueden usar como módulos de Bicep.

Imagine que tiene una plantilla de Bicep que implementa recursos de aplicación, base de datos y red para la solución A. Puede dividir esta plantilla en tres módulos, cada uno de los cuales se centra en su propio conjunto de recursos. Además, ahora puede reutilizar los módulos en otras plantillas para otras soluciones también; por tanto, al desarrollar una plantilla para la solución B, que tiene requisitos de red similares a la solución A, puede reutilizar el módulo de red.

Si quiere que la plantilla incluya una referencia a un archivo de módulo, use la palabra clave module. Una definición de módulo es similar a una declaración de recurso, pero en lugar de incluir un tipo de recurso y una versión de API, se usa el nombre de archivo del módulo:

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    location: location
  }
}

Echemos un vistazo más de cerca a algunas de las partes principales de esta definición de módulo:

• La palabra clave module indica a Bicep que está a punto de usar otro archivo de Bicep como módulo.
• Al igual que ocurre con los recursos, los módulos necesitan un nombre simbólico, como myModule. El nombre simbólico se usa cuando se hace referencia a las salidas del módulo en otras partes de la plantilla.
• modules/mymodule.bicep es la ruta de acceso al archivo de módulo, relativa al archivo de plantilla. Recuerde que un archivo de módulo es simplemente un archivo de Bicep normal.
• Al igual que con los recursos, la propiedad name es obligatoria. Azure usa el nombre del módulo porque crea una implementación independiente para cada módulo dentro del archivo de plantilla. Esas implementaciones tienen nombres que puede usar para identificarlas.
• Puede especificar cualquier parámetro del módulo mediante la palabra clave params. Al establecer los valores de cada parámetro dentro de la plantilla, puede usar expresiones, parámetros de plantilla, variables, propiedades de los recursos implementados dentro de la plantilla y salidas de otros módulos. Bicep comprenderá automáticamente las dependencias entre los recursos.

Módulos y salidas

Al igual que las plantillas, los módulos de Bicep pueden definir salidas. Es habitual encadenar módulos dentro de una plantilla. En ese caso, la salida de un módulo puede ser un parámetro de otro. Mediante el uso combinado de módulos y salidas, puede crear archivos de Bicep eficaces y reutilizables.

Diseño de los módulos

Un buen módulo de Bicep sigue algunos principios clave:

• Un módulo debe tener un propósito claro. Puede usar módulos para definir todos los recursos relacionados con una parte específica de la solución. Por ejemplo, Ud. podría crear un módulo que contenga todos los recursos que se usan para supervisar la aplicación. También podría usar un módulo para definir un conjunto de recursos que son inseparables, como todas las bases de datos y todos los servidores de bases de datos.

• No coloque todos los recursos en su propio módulo. No debe crear un módulo distinto para cada recurso que implemente. Si tiene un recurso que tiene muchas propiedades complejas, puede tener sentido colocar ese recurso en su propio módulo, pero, en general, es mejor que los módulos combinen varios recursos.

• Un módulo debe tener parámetros y salidas claros que tengan sentido. Considere la finalidad del módulo. Piense en si el módulo debe manipular los valores de los parámetros o si la plantilla primaria debe controlar este aspecto y pasar un solo valor al módulo. Del mismo modo, piense en las salidas que debe devolver un módulo y asegúrese de que sean útiles para las plantillas que usarán el módulo.

• Un módulo debe ser lo más independiente posible. Si un módulo necesita usar una variable para definir una de sus partes, la variable generalmente debe incluirse en el archivo de módulo en lugar de en la plantilla primaria.

• Un módulo no debe generar secretos. Al igual que con las plantillas, no cree salidas de módulo para valores secretos como cadenas de conexión o claves.

Continuar