Compartir a través de

Configurar una canalización e insertar actualizaciones

  • Artículo

En este artículo, aprenderá a usar la CLI para desarrolladores de Azure (azd) para insertar cambios de plantilla a través de una canalización de CI/CD, como Acciones de GitHub o Azure DevOps. En este ejemplo, usará la plantilla Aplicación web de React con la API Node.js y MongoDB en Azure, pero puede aplicar los principios que se recogen en este artículo a cualquiera de las plantillas de la CLI para desarrolladores de Azure.

Nota:

El comando azd pipeline config todavía está en versión beta. Consulte más información sobre la compatibilidad con características alfa y beta en la página de estrategias de versiones y control de versiones de características.

Requisitos previos

Es posible que las plantillas de azd incluyan o no un archivo de configuración de las canalizaciones Acciones de GitHub y/o Azure DevOps, llamado azure-dev.yml, que es necesario con configurar los procedimientos CI/CD. Este archivo de configuración aprovisiona los recursos de Azure e implementa el código en la rama principal. Puede encontrar azure-dev.yml:

  • Acciones de GitHub: en el directorio .github/workflows.
  • Azure DevOps: en el directorio .azdo/pipelines.

Puede utilizar el archivo de configuración tal cual o modificarlo para adaptarlo a sus necesidades.

Nota:

Compruebe que la plantilla tiene una definición de canalización (azure-dev.yaml) antes de llamar a azd pipeline config. azd no crea automáticamente este archivo. Consulte Creación de una definición de canalización para azd más adelante.

Para configurar una canalización de CI/CD, use el comando azd pipeline config, que se encarga de las siguientes tareas:

  • Creará y configurará una entidad de servicio para la aplicación en la suscripción de Azure. El usuario debe tener el rol Owner o los roles Contributor + User Access Administrator en la suscripción de Azure, para permitir que azd cree y asigne roles a la entidad de servicio.
  • Se le guiará a través de un flujo de trabajo para crear y configurar un repositorio de GitHub o Azure DevOps y confirmarle el código del proyecto. También puede optar por utilizar un repositorio existente.
  • Permite crear una conexión segura entre Azure y el repositorio.
  • Ejecuta la acción de GitHub al proteger el archivo del flujo de trabajo.

Para tener un control más granular sobre este proceso o si el usuario no tiene los roles correspondientes, puede configurar manualmente una canalización.

Seleccione el proveedor de canalización deseado para continuar:

Autorizar a GitHub para la implementación en Azure

Para configurar el flujo de trabajo, debe autorizar a una entidad de servicio para que se implemente en Azure en su nombre, a través de una acción de GitHub. azd crea la entidad de servicio y una credencial federada para ella.

  1. Ejecute el comando siguiente para crear una entidad de servicio de Azure y configurar la canalización:

    azd pipeline config

    Opcionalmente, este comando crea un repositorio de GitHub e inserta código en el nuevo repositorio.

    Nota:

    De forma predeterminada, azd pipeline config utiliza OpenID Connect (OIDC), conocido como credenciales federadas. Si prefiere no usar OIDC, ejecute azd pipeline config --auth-type client-credentials.

    OIDC o las credenciales federadas no son compatibles con Terraform.

    Obtenga más información la compatibilidad de OIDC en azd.

  2. Indique la información de GitHub solicitada.

  3. Cuando se le pida que confirme e inserte los cambios locales para iniciar una nueva ejecución de Acciones de GitHub, indique y.

  4. En la ventana del terminal, vea los resultados del comando azd pipeline config. El comando azd pipeline config generará el nombre del repositorio de GitHub para el proyecto.

  5. En el explorador, abra el repositorio de GitHub del proyecto.

  6. Seleccione Acciones para ver cómo se ejecuta el flujo de trabajo.

    Captura de pantalla del flujo de trabajo de GitHub ejecutándose.

Realizar e insertar un cambio de código

  1. En el directorio /src/web/src/layout del proyecto, abra header.tsx.

  2. Busque la línea <Text variant="xLarge">ToDo</Text>.

  3. Cambie el literal ToDo por myTodo.

  4. Guarde el archivo.

  5. Confirme el cambio. Si se confirmar el cambio, se iniciará la canalización de la acción de GitHub para implementar la modificación.

    Captura de pantalla del proceso necesario para realizar y confirmar los cambios en el archivo de prueba.

  6. En el explorador, abra el repositorio de GitHub del proyecto para ver lo siguiente:

    • La aplicación de los cambios
    • La confirmación aplicada de Acciones de GitHub.

    Captura de pantalla del cambio confirmado en GitHub.

  7. Seleccione Acciones para ver el cambio de prueba reflejado en el flujo de trabajo.

    Captura de pantalla del flujo de trabajo de GitHub que se ejecuta después del cambio de prueba.

  8. Visite la URL web del front-end para inspeccionar la modificación.

azd como una acción de GitHub

Agregue azd como una acción de GitHub. Al hacer esto, se instalará azd. Para usarlo, puede agregar lo siguiente a .github\workflows\azure-dev.yml:

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - name: Install azd
         uses: Azure/setup-azd@v0.1.0

Limpieza de recursos

Cuando ya no necesite los recursos de Azure creados en este artículo, ejecute el comando siguiente:

azd down

Características avanzadas

Puede ampliar el uso del comando azd pipeline config según los usos o requisitos de plantillas específicos, tal como se describe en las secciones siguientes.

Secretos o variables adicionales

De forma predeterminada, azd crea las variables y los secretos para la canalización. Por ejemplo, el comando azd pipeline config crea la subscription id, el environment name y la region como variables de la canalización cada vez que se ejecuta. La definición de canalización hace referencia a esas variables:

env:
   AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
   AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
   AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
   AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
   AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}

Cuando se ejecuta la canalización, azd obtiene los valores del entorno, que se asigna a las variables y secretos. En función de la plantilla, puede haber configuraciones que se pueden controlar mediante variables de entorno. Por ejemplo, podría crearse una variable de entorno denominada KEY_VAULT_NAME para definir el nombre de un recurso de almacén de secretos dentro de la infraestructura de la plantilla. En estos casos, la plantilla puede definir la lista de variables y secretos mediante azure.yaml. Por ejemplo, imagine que usa la siguiente configuración de azure.yaml:

pipeline:
  variables:
    - KEY_VAULT_NAME
    - STORAGE_NAME
  secrets:
    - CONNECTION_STRING

Con esta configuración, azd comprueba si alguna de las variables o secretos tiene un valor no vacío en el entorno. Luego, azd crea una variable o un secreto para la canalización con el nombre de la clave en la configuración como el nombre de la variable o el secreto, así como el valor que no sea cadena del entorno para el valor.

Después, la definición de canalización azure-dev.yaml puede hacer referencia a las variables o secretos:

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      KEY_VAULT_NAME: ${{ variables.KEY_VAULT_NAME }}
      STORAGE_NAME: ${{ variables.STORAGE_NAME }}
      CONNECTION_STRING: ${{ secrets.CONNECTION_STRING }}

Nota:

Debe ejecutar azd pipeline config después de actualizar la lista de secretos o variables en azure.yaml para que azd restablezca los valores de la canalización.

Parámetros de infraestructura

Parta del ejemplo siguiente de Bicep:

@secure()
param BlobStorageConnection string

El parámetro BlobStorageConnection no tiene ningún valor predeterminado asignado, por lo que azd solicita al usuario que escriba un valor. Sin embargo, no hay ninguna solicitud interactiva durante la canalización de CI/CD. azd debe solicitar el valor del parámetro al ejecutar azd pipeline config, guardar el valor en la canalización y finalmente recuperar el valor de nuevo cuando se ejecute la canalización.

azd usa un secreto de canalización llamado AZD_INITIAL_ENVIRONMENT_CONFIG para guardar y aplicar automáticamente el valor de todos los parámetros necesarios en la canalización. Solo debe hacer referencia a este secreto en la canalización:

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}

Cuando se ejecuta la canalización, azd toma los valores de los parámetros del secreto, lo que no hace necesario realizar una solicitud interactiva.

Nota:

Si agrega un nuevo parámetro, debe volver a ejecutar azd pipeline config.

Creación de una definición de canalización

Si la plantilla azd aún no tiene un archivo de definición de canalización de CI/CD, puede crear uno. Una definición de canalización de CI/CD suele tener 4 secciones principales:

  • desencadenador
  • permisos
  • sistema operativo o grupo
  • pasos que se van a realizar

En los ejemplos siguientes se muestra cómo crear un archivo de definición y las configuraciones relacionadas para Acciones de GitHub y Azure Pipelines.

Para ejecutar azd en Acciones de GitHub se necesitan las siguientes configuraciones:

  • Conceda los niveles de acceso id-token: write y contents: read.
  • Instale la acción azd, a menos que use una imagen de Docker donde azd ya está instalado.

Puede usar la plantilla siguiente como punto de partida para su propia definición de canalización:

on:
  workflow_dispatch:
  push:
    # Run when commits are pushed to mainline branch (main or master)
    # Set this to the mainline branch you are using
    branches:
      - main
      - master

# Set this permission if you are using a Federated Credential.
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    # azd build-in variables.
    # This variables are always set by `azd pipeline config`
    # You can set them as global env (apply to all steps) or you can add them to individual steps' environment
    env:
      AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
      AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
      ## Define the additional variables or secrets that are required globally (provision and deploy)
      # ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
      # ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}      
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # using the install-azd action
      - name: Install azd
        uses: Azure/setup-azd@v1.0.0

      # # If you want to use azd-daily build, or install it from a PR, you can remove previous step and
      # # use the next one:
      # - name: Install azd - daily or from PR
      #  # Update this scrip based on the OS - pool of your pipeline. This example is for a linux pipeline installing daily build
      #  run: curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --version daily
      #  shell: pwsh

      # azd set up Federated Credential by default. You can remove this step if you are using Client Credentials
      - name: Log in with Azure (Federated Credentials)
        if: ${{ env.AZURE_CLIENT_ID != '' }}
        run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "github" `
            --tenant-id "$Env:AZURE_TENANT_ID"
        shell: pwsh

      ## If you set up your pipeline with Client Credentials, remove previous step and uncomment this one
      # - name: Log in with Azure (Client Credentials)
      #   if: ${{ env.AZURE_CREDENTIALS != '' }}
      #   run: |
      #     $info = $Env:AZURE_CREDENTIALS | ConvertFrom-Json -AsHashtable;
      #     Write-Host "::add-mask::$($info.clientSecret)"

      #     azd auth login `
      #       --client-id "$($info.clientId)" `
      #       --client-secret "$($info.clientSecret)" `
      #       --tenant-id "$($info.tenantId)"
      #   shell: pwsh
      #   env:
      #     AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Provision Infrastructure
        run: azd provision --no-prompt
        env:
         #  # uncomment this if you are using infrastructure parameters
         #  AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}
         ## Define the additional variables or secrets that are required only for provision 
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}

      - name: Deploy Application
        run: azd deploy --no-prompt
        env:
         ## Define the additional variables or secrets that are required only for deploy
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}