Ejercicio: Publicación de un módulo en un registro

  • 5 minutos

En su empresa de juguetes ha estado publicando los módulos de Bicep en un registro. Ha estado ejecutando el proceso de publicación manualmente desde su propio equipo. Ahora quiere crear un flujo de trabajo para controlar el proceso de publicación.

En este ejercicio, aprenderá a:

  • Cree un registro de contenedor para los módulos de Bicep.
  • Agregue un trabajo de lint al flujo de trabajo.
  • Agregue un trabajo de flujo de trabajo para publicar el módulo en el registro.
  • Compruebe que el flujo de trabajo se ejecuta correctamente.
  • Compruebe el módulo publicado en el registro.

Creación de un Registro de contenedor

Para poder publicar los módulos, debe crear un registro para su organización. En este caso, usa el Portal de Azure para crear un registro.

  1. Cree un nuevo registro de contenedor en el Portal de Azure en el explorador.

  2. En la pestaña Aspectos básicos seleccione la suscripción de destino y el grupo de recursos ToyReusable que ha creado anteriormente.

  3. Escriba un nombre para el registro y una ubicación cercana.

    Importante

    El nombre del registro debe ser único dentro de Azure y contener entre 5 y 50 caracteres alfanuméricos. Una marca de verificación junto al nombre del registro indica que el nombre que ha elegido está disponible.

  4. En Plan de precios, seleccione Básico.

    Para las demás opciones de configuración, deje los valores predeterminados.

  5. Seleccione Revisar + crear.

    Captura de pantalla de Azure Portal que muestra la página de creación del registro de contenedor.

  6. Cuando aparezca el mensaje Validación superada, seleccione Crear.

    Espere a que finalice la implementación, lo que normalmente tarda entre 1 y 2 minutos.

  7. Cuando aparezca el mensaje Implementación correcta, seleccione Ir al recurso para abrir el registro de contenedor.

    Captura de pantalla de Azure Portal que muestra la implementación del registro de contenedor, con el botón para ir a un recurso resaltado.

  8. En el área Información general del registro de contenedor, anote el valor de la configuración del servidor de inicio de sesión. El nombre es similar a yourregistryname.azurecr.io.

    Captura de pantalla de Azure Portal que muestra los detalles del registro de contenedor, con el servidor de inicio de sesión resaltado.

    Necesitará este valor más adelante.

Agregación de un archivo de metadatos de módulo

En la unidad anterior ha aprendido la importancia de tener una estrategia de control de versiones para los módulos. También ha aprendido a usar los archivos de metadatos del módulo para especificar el número de versión principal y secundaria del módulo dentro de un flujo de trabajo. Ahora agregará un archivo de metadatos para el módulo de la cuenta de almacenamiento.

  1. En Visual Studio Code, expanda la carpeta modules/storage-account en la raíz del repositorio.

  2. Cree un nuevo archivo denominado metadata.json.

    Captura de pantalla de Visual Studio Code que muestra la ubicación del archivo JSON de metadatos.

  3. Agregue el siguiente contenido al archivo:

    {
  "version": {
    "major": 1,
    "minor": 2
  }
}

    En el archivo de metadatos, se definen por separado los números de versión principal y secundaria. Cada vez que se ejecuta el flujo de trabajo, el flujo de trabajo combina estos números junto con el número de ejecución del flujo de trabajo para formar un número de versión completo.

  4. Guarde los cambios en el archivo.

Actualización de la definición del flujo de trabajo y agregación de un trabajo de lint

El repositorio contiene un borrador de un flujo de trabajo que puede usar como punto de partida.

  1. En Visual Studio Code expanda la carpeta .github/workflows en la raíz del repositorio.

  2. Abra el archivo module-storage-account.yml.

    Captura de pantalla de Visual Studio Code que muestra la ubicación del archivo de definición de flujo de trabajo.

  3. Actualice el valor de la variable de entorno MODULE_REGISTRY_SERVER al nombre del servidor del registro de contenedor. Ese es el nombre que ha copiado anteriormente en este ejercicio.

    Por ejemplo, si el servidor de inicio de sesión del registro es yourregistryname.azurecr.io, el código será como el de este ejemplo:

    env:
  MODULE_NAME: storage-account
  MODULE_REGISTRY_SERVER: yourregistryname.azurecr.io
  MODULE_FILE_PATH: modules/storage-account/main.bicep
  MODULE_METADATA_FILE_PATH: modules/storage-account/metadata.json

  4. En la parte inferior del archivo, para el comentario # To be added, agregue la siguiente definición de trabajo lint:

    jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.MODULE_FILE_PATH }}

Agregación de un trabajo de publicación al flujo de trabajo

Ahora puede agregar un segundo trabajo para publicar el módulo en el registro de contenedor.

  1. En la parte inferior del archivo module-storage-account.yml, agregue la primera parte de la definición del trabajo de publicación.

    publish:
  runs-on: ubuntu-latest
  needs: [ lint ]
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

    Los dos pasos iniciales de esta definición son consultar el código del repositorio e iniciar sesión en Azure.

  2. Debajo del código que acaba de agregar, agregue otro paso que lea el número de versión del archivo metadata.json del módulo y lo establezca como una variable de entorno.

    - name: Get module version number
  run: |
    majorMinorVersionNumber=$(jq '(.version.major | tostring) + "." + (.version.minor | tostring)' ${{ env.MODULE_METADATA_FILE_PATH }} -r )
    versionNumber="$majorMinorVersionNumber.${{ github.run_number }}"
    echo "MODULE_VERSION=$versionNumber" >> $GITHUB_ENV

    El paso ejecuta un script que usa la aplicación de línea de comandos jq para analizar el archivo JSON.

  3. Después del paso que ha creado, agregue un paso final para publicar el módulo en el Registro.

    - uses: azure/cli@v1
  name: Publish module
  with:
    inlineScript: |
      az bicep publish \
        --target 'br:${{ env.MODULE_REGISTRY_SERVER }}/${{ env.MODULE_NAME }}:${{ env.MODULE_VERSION }}' \
        --file ${{ env.MODULE_FILE_PATH }}

    Este paso construye el valor del argumento --target dinámicamente. Combina el valor del servidor del registro, el nombre del módulo y el número de versión.

  4. Guarde los cambios en el archivo.

Comprobación y confirmación de la definición de flujo de trabajo

  1. Compruebe que el archivo module-storage-account.yml es similar al del ejemplo siguiente:

    name: module-storage-account
concurrency: module-storage-account

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - 'modules/storage-account/**'

permissions:
  id-token: write
  contents: read

env:
  MODULE_NAME: storage-account
  MODULE_REGISTRY_SERVER: yourregistryname.azurecr.io
  MODULE_FILE_PATH: modules/storage-account/main.bicep
  MODULE_METADATA_FILE_PATH: modules/storage-account/metadata.json

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Run Bicep linter
      run: az bicep build --file ${{ env.MODULE_FILE_PATH }}

  publish:
    runs-on: ubuntu-latest
    needs: [ lint ]
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      name: Sign in to Azure
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - name: Get module version number
      run: |
        majorMinorVersionNumber=$(jq '(.version.major | tostring) + "." + (.version.minor | tostring)' ${{ env.MODULE_METADATA_FILE_PATH }} -r )
        versionNumber="$majorMinorVersionNumber.${{ github.run_number }}"
        echo "MODULE_VERSION=$versionNumber" >> $GITHUB_ENV
    - uses: azure/cli@v1
      name: Publish module
      with:
        inlineScript: |
          az bicep publish \
            --target 'br:${{ env.MODULE_REGISTRY_SERVER }}/${{ env.MODULE_NAME }}:${{ env.MODULE_VERSION }}' \
            --file ${{ env.MODULE_FILE_PATH }}

    Si el contenido del archivo es diferente, actualícelo para que coincida con este ejemplo y a continuación, guarde el archivo.

  2. Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:

    git add .
git commit -m "Add lint and publish jobs to storage account module workflow"
git push

Desencadenador del flujo de trabajo

  1. En el explorador vaya al repositorio de GitHub y seleccione la pestaña Acciones.

  2. Seleccione el flujo de trabajo cuenta de almacenamiento de módulos.

    Observe que una ejecución de flujo de trabajo ya está en curso. El desencadenador de inserción se ha activado porque ha modificado el archivo metadata.json dentro de la carpeta del módulo.

  3. Seleccione la última ejecución de la lista.

    Captura de pantalla de GitHub que resalta la ejecución más reciente del flujo de trabajo del módulo.

    Espere a que finalice la ejecución del flujo de trabajo. El módulo de Bicep está publicado en el registro de contenedor.

    Observe el número de ejecución del flujo de trabajo, que probablemente sea 3.

Revisión del módulo en el registro

También puede visualizar el módulo publicado en el Portal de Azure.

  1. En el explorador, vaya a Azure Portal.

  2. Vaya al grupo de recursos ToyReusable.

  3. En Recursos, seleccione el registro de contenedor que ha creado anteriormente.

  4. Seleccione Repositorios de>servicios en el menú. A continuación, seleccione el repositorio módulos\cuenta de almacenamiento, que representa el módulo que ha publicado el flujo de trabajo.

    Captura de pantalla de Azure Portal que muestra un módulo de Bicep en el registro de contenedor.

    Observe que hay una sola etiqueta, que coincide con el número de versión del módulo que ha publicado el flujo de trabajo. La versión principal (1) y la versión secundaria (2) coinciden con los números de versión que ha definido en el archivo metadata.json. El número de revisión (3) coincide con el número de ejecución del flujo de trabajo.

Limpiar los recursos

Ahora que ha completado el ejercicio, puede quitar los recursos para que no se le facturen.

En el terminal de Visual Studio Code, ejecute el comando siguiente:

az group delete --resource-group ToyReusable --yes --no-wait

El grupo de recursos se elimina en segundo plano.

Remove-AzResourceGroup -Name ToyReusable -Force

También puede quitar los secretos y el repositorio de GitHub y las identidades de carga de trabajo de Azure.

  • Secretos de GitHub

    1. En el repositorio de GitHub, vaya a Configuración>Secretos y variables>Acciones.
    2. Para cada secreto de GitHub guardado, seleccione el icono Eliminar <nombre de secreto> y siga las indicaciones.

  • Repositorio de GitHub

    1. Vaya a Configuración>General.
    2. Seleccione Eliminar este repositorio y siga las indicaciones.

  • Credenciales federadas y entidad de servicio del registro de Aplicación de Azure.

    1. En la página principal del portal, busque Microsoft Entra ID y selecciónelo en la lista de Servicios.
    2. Vaya a Administrar>Registros de aplicaciones.
    3. En la pestaña Aplicaciones de propiedad, seleccione toy-reusable.
    4. Seleccione Eliminar y siga las indicaciones.
    5. Seleccione la pestaña Aplicaciones eliminadas.
    6. Seleccione toy-reutilizable, seleccione Eliminar permanentemente, y a continuación, seleccione Sí para eliminar permanentemente el registro de la aplicación.

    Importante

    Es posible tener nombres de entidad de seguridad de servicio y registro de aplicaciones duplicados. Se recomienda comprobar el identificador de aplicación para asegurarse de que está eliminando el recurso correcto.