Publicación de un módulo en un registro privado

Completado

Ahora comprende qué son los registros de Bicep y cómo pueden ser útiles al compartir módulos en su organización. En esta unidad, aprenderá a publicar un módulo en un registro privado.

Rutas de acceso del módulo

Cuando ha trabajado con módulos en el pasado, probablemente haya usado la ruta del archivo del módulo para hacer referencia a este en las plantillas. Al trabajar con módulos y registros privados, debe usar una ruta de acceso del módulo diferente para que Bicep sepa cómo localizar el módulo en el registro.

Esta es una ruta de acceso de ejemplo para un módulo de un registro de contenedor de Azure privado:

La ruta de acceso contiene cuatro segmentos:

• Esquema: Bicep admite varios tipos de módulo, que se denominan esquemas. Cuando se trabaja con registros de Bicep, el esquema es br.
• Registro: nombre del registro que contiene el módulo que desea usar. En el ejemplo anterior, el nombre del registro es toycompany.azurecr.io, que es el nombre del registro de contenedor.
• Identificador de módulo: ruta de acceso completa al módulo que se incluye en el registro.
• Etiqueta: las etiquetas suelen representar versiones de módulos, ya que un solo módulo puede tener varias versiones publicadas. En la sección siguiente obtendrá más información sobre las etiquetas y las versiones.

Cuando publique su propio identificador de módulo, use un identificador significativo que indique el propósito del módulo. Opcionalmente, se pueden usar espacios de nombres, donde se usan barras diagonales (/) para distinguir entre las partes de un nombre. Sin embargo, Azure Container Registry y Bicep no comprenden una jerarquía. Tratan el identificador del módulo como un valor único.

Etiquetas y versiones

Una etiqueta representa la versión de un módulo. Un solo módulo de un registro puede tener varias versiones. Todas las versiones comparten un identificador de módulo, pero tienen etiquetas diferentes. Cuando se usa un módulo, es necesario utilizar una etiqueta para especificar la versión que desea usar, de modo que Bicep sepa qué archivo de módulo recuperar.

Es una buena idea planear cuidadosamente cómo va a crear las versiones de los módulos. Dos decisiones clave que debe 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. O bien, puede agregar un prefijo a cada número de versión, como v1 y v2.
• Las fechas también son adecuadas como números de versión. Por ejemplo, si publica la primera versión del módulo el 16 de enero de 2022, podría asignar el nombre 2022-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 2022-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. Los números y las fechas suelen ser buenas opciones.

Nota:

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

Directivas de control de versiones

Los módulos 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 el módulo, simplemente actualice esa versión. Aunque esta directiva funciona, no es un procedimiento recomendado.

Por el contrario, si realiza un pequeño cambio en un módulo existente que no afecta a cómo se usa, 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 el módulo.

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

• Cada vez que realice cambios significativos en un módulo, cree una nueva versión. Entre los cambios significativos se incluye cualquier cosa que pueda marcar la diferencia para alguien que use el módulo. Entre los ejemplos se incluye agregar otro recurso al módulo o cambiar las propiedades de un recurso.
• Cada vez que realice pequeños cambios en un módulo, lo que a veces se llama revisión, actualice la versión del módulo 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 del módulo y asegúrese de pensar en lo que esperan que suceda. Si alguien usa el módulo varias veces y obtiene un resultado y, a continuación, lo usa de nuevo después de una revisión y obtiene un resultado diferente, es probable que se sorprenda. Intente evitar que los usuarios se sorprendan.

Publicación del módulo

Al crear un módulo de Bicep que desee compartir, cree el archivo de Bicep de la forma habitual. A continuación, publique el archivo en un registro mediante el comando bicep publish. Al publicar, debe especificar la ruta de acceso del módulo para guardar el módulo en:

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

bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

La operación de publicación realiza los mismos pasos de validación que se siguen al compilar o implementar un archivo de Bicep. Estos pasos incluyen:

• Comprobar que el código no tiene ningún error sintáctico.
• Comprobar que especifica definiciones de recursos válidas.
• Ejecutar el linter de Bicep para comprobar que el código pasa una serie de comprobaciones de calidad.

Si se pasan los pasos de validación, el módulo se publicará en el registro.