Ejercicio: Creación de entornos efímeros para solicitudes de incorporación de cambios

  • 7 minutos

Algunos miembros del equipo le han dicho que agradecen recibir los comentarios automatizados de Bicep linter sobre los cambios en el código antes de enviarlos a otros miembros del equipo para que los revisen. Ahora, has decidido ofrecer a tus colaboradores y revisores la capacidad de implementar y revisar su código en un entorno efímero.

En este ejercicio, actualizarás el flujo de trabajo de la solicitud de incorporación de cambios para implementar un entorno efímero cada vez que se abra una solicitud y lo volverás a implementar cuando se inserte el código en la rama de la solicitud. También crearás otro flujo de trabajo para eliminar automáticamente el entorno cuando se cierra la solicitud de incorporación de cambios. Puedes probar los cambios mediante la creación de una solicitud de incorporación de cambios para que el sitio web use una imagen de contenedor Docker.

Durante el proceso, hará lo siguiente:

  • Actualiza el flujo de trabajo de la solicitud de incorporación de cambios para implementar un entorno efímero.
  • Crea un flujo de trabajo de eliminación de solicitudes de incorporación de cambios para eliminar el entorno efímero.
  • Crea una solicitud de incorporación de cambios e inspecciona cómo se crea el entorno efímero.
  • Apruebe la solicitud de incorporación de cambios e inspeccione cómo se elimina el entorno efímero.

Actualiza el flujo de trabajo de solicitud de incorporación de cambios para implementar un entorno efímero

Como primer paso, tiene que actualizar el flujo de trabajo pr-validation para crear un entorno efímero.

  1. En el terminal Visual Studio Code, comprueba la rama principal del repositorio.

    git checkout main

  2. Extraiga la última versión del código de GitHub, que incluye los cambios que ha combinado en un ejercicio anterior.

    git pull

  3. Abre el archivo .github/workflows/pr-validation.yml en Visual Studio Code.

  4. Cerca de la parte superior del archivo, debajo de la name configuración, agrega una concurrency configuración:

    name: pr-validation
concurrency: ${{ github.event.number }}

    Esta configuración evita que varios flujos de trabajo de la misma solicitud de incorporación de cambios se ejecuten al mismo tiempo, ya que podría provocar resultados impredecibles al implementar recursos en Azure.

  5. Cerca de la parte superior del archivo, en la sección on que define el desencadenador, defina la sección permissions:

    name: pr-validation
concurrency: ${{ github.event.number }}

on: pull_request

permissions:
  id-token: write
  contents: read

  6. Debajo de la sección permissions, agregue dos nuevas variables de entorno:

    name: pr-validation
concurrency: ${{ github.event.number }}

on: pull_request

permissions:
  id-token: write
  contents: read

env:
  resourceGroupName: pr_${{ github.event.number }}
  resourceGroupLocation: westus3

    La resourceGroupName variable de entorno especifica el nombre del grupo de recursos que se debe usar para cada entorno efímero. Cada grupo de recursos denominará pr_123 donde 123 está el número de solicitud de incorporación de cambios único.

    La resourceGroupLocation variable de entorno especifica que los entornos efímeros deben implementarse en la región de Azure Oeste de EE. UU. 3.

  7. Define un nuevo trabajo denominado deploy, debajo del lint trabajo:

    jobs:
  lint:
    uses: ./.github/workflows/lint.yml

  deploy:
    runs-on: ubuntu-latest
    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 }}

    El trabajo primero comprueba todo el código en el ejecutor de GitHub y después inicia sesión en el entorno de Azure.

    Sugerencia

    Los archivos YAML son sensibles a la sangría. Tanto si escribe o pega este código, asegúrese de que la sangría es correcta. Más adelante en este ejercicio, verá la definición de flujo de trabajo de YAML completa para que pueda comprobar que el archivo coincide.

  8. Agrega un paso para crear el grupo de recursos con el nombre definido en la variable de entorno:

    - uses: Azure/cli@v1
  name: Create resource group
  with:
    inlineScript: |
      az group create \
        --name ${{ env.resourceGroupName }} \
        --location ${{ env.resourceGroupLocation }}

  9. Después del paso de creación del grupo de recursos, agrega un paso para implementar el archivo Bicep en el grupo de recursos:

    - uses: azure/arm-deploy@v1
  id: deploy
  name: Deploy Bicep file
  with:
    failOnStdErr: false
    deploymentName: ${{ github.run_number }}
    resourceGroupName: ${{ env.resourceGroupName }}
    template: ./deploy/main.bicep
    parameters: >
      environmentType=Test

  10. Después del paso de implementación, agrega un paso para mostrar la dirección del sitio web del entorno efímero en el registro de flujo de trabajo:

    - name: Show website hostname
  run: |
    echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"

  11. Guarde los cambios.

  12. Comprueba que el archivo pr-validation.yml es similar al siguiente:

    name: pr-validation
concurrency: ${{ github.event.number }}

on: pull_request

permissions:
  id-token: write
  contents: read

env:
  resourceGroupName: pr_${{ github.event.number }}
  resourceGroupLocation: westus3

jobs:
  lint:
    uses: ./.github/workflows/lint.yml

  deploy:
    runs-on: ubuntu-latest
    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 }}
      - uses: Azure/cli@v1
        name: Create resource group
        with:
          inlineScript: |
            az group create \
              --name ${{ env.resourceGroupName }} \
              --location ${{ env.resourceGroupLocation }}
      - uses: azure/arm-deploy@v1
        id: deploy
        name: Deploy Bicep file
        with:
          failOnStdErr: false
          deploymentName: ${{ github.run_number }}
          resourceGroupName: ${{ env.resourceGroupName }}
          template: ./deploy/main.bicep
          parameters: >
            environmentType=Test
      - name: Show website hostname
        run: |
          echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"

    Si no es así, actualícelo para que coincida con este ejemplo y después guárdelo.

  13. En el terminal de Visual Studio Code, confirma los cambios e insértalos. Aún no los insertará en el repositorio remoto.

    git add .
git commit -m "Update pull request validation workflow to deploy an ephemeral environment"

Agrega un flujo de trabajo de eliminación de solicitudes de incorporación de cambios

Has creado un flujo de trabajo que implementa automáticamente los cambios de cada solicitud de incorporación de cambios en un grupo de recursos efímero. Ahora, configura un segundo flujo de trabajo para eliminar los entornos efímeros cuando ya no se necesiten.

  1. Crea un nombre de archivo nuevo pr-closed.ymlen la .github/workflows carpeta.

    Captura de pantalla de Visual Studio Code que muestra el archivo PRclosed.YML dentro de la carpeta de flujos de trabajo.

  2. En la parte superior del archivo, asigna un nombre al flujo de trabajo y configura la misma clave de simultaneidad que se ha utilizado en el flujo de trabajo de validación de solicitudes de incorporación de cambios. Después, configura el flujo de trabajo para que se ejecute siempre que se cierre una solicitud de incorporación de cambios y permite al flujo de trabajo obtener un token de acceso:

    name: pr-closed
concurrency: ${{ github.event.number }}

on:
  pull_request:
    types: [closed]

permissions:
  id-token: write
  contents: read

  3. Debajo del código que acaba de especificar, defina una variable de entorno para el nombre del grupo de recursos que está asociado al entorno efímero de la solicitud de incorporación de cambios:

    env:
  resourceGroupName: pr_${{ github.event.number }}

    El nombre del grupo de recursos es el mismo que el que se ha usado para el flujo de trabajo de validación de las solicitudes de incorporación de cambios.

  4. Debajo del código que has agregado, define un nuevo trabajo denominado removey configúralo para iniciar sesión en Azure:

    jobs:
  remove:
    runs-on: ubuntu-latest
    steps:
      - 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 }}

  5. Dentro del remove trabajo, define un paso para eliminar el grupo de recursos mediante el CLI de Azure y confirma la eliminación mediante el --yes argumento:

    - uses: Azure/cli@v1
  name: Delete resource group
  with:
    inlineScript: |
      az group delete \
        --name ${{ env.resourceGroupName }} \
        --yes

  6. Guarde los cambios.

  7. Comprueba que el archivo pr-closed.yml es similar al siguiente:

    name: pr-closed
concurrency: ${{ github.event.number }}

on:
  pull_request:
    types: [closed]

permissions:
  id-token: write
  contents: read

env:
  resourceGroupName: pr_${{ github.event.number }}

jobs:
  remove:
    runs-on: ubuntu-latest
    steps:
      - 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 }}
      - uses: Azure/cli@v1
        name: Delete resource group
        with:
          inlineScript: |
            az group delete \
              --name ${{ env.resourceGroupName }} \
              --yes

    Si no es así, actualícelo para que coincida con este ejemplo y después guárdelo.

  8. En el terminal de Visual Studio Code, confirma los cambios e insértalos en el repositorio remoto:

    git add .
git commit -m 'Add pull request closed workflow'
git push

Actualización del archivo de Bicep

A continuación, actualice el archivo Bicep a fin de usar una imagen de contenedor de Docker para la aplicación de su sitio web.

  1. En el terminal de Visual Studio Code, cree una rama para los cambios ejecutando el comando siguiente:

    git checkout -b feature/container-app

  2. Abra el archivo main.bicep en la carpeta deploy.

  3. Actualiza el valor de la appServiceAppLinuxFrameworkVersion variable:

    var appServiceAppLinuxFrameworkVersion = 'DOCKER|dockersamples/static-site:latest'

  4. Guarde los cambios.

  5. 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 "Use container image for website"
git push origin feature/container-app

Crear una solicitud de incorporación de cambios

Has definido flujos de trabajo para crear y administrar entornos efímeros automáticamente en las solicitudes de incorporación de cambios. Ahora, crea otra solicitud de incorporación de cambios para los cambios de Bicep.

  1. En el explorador, seleccione Código y, a continuación, 3 ramas.

    Captura de pantalla de GitHub que muestra la lista de ramas del repositorio.

  2. En sus ramas, junto a feature/container-app, seleccione Nueva solicitud de incorporación de cambios.

    Captura de pantalla de GitHub que muestra el vínculo para crear una solicitud de incorporación de cambios para la rama de aplicación de contenedor de barra diagonal de características.

  3. Seleccione Crear solicitud de incorporación de cambios.

Ver cómo se crea el entorno efímero

  1. En la página de detalles de la solicitud de incorporación de cambios, espere a que aparezcan los elementos de comprobación de estado.

  2. En la lista, junto al trabajo de implementación, seleccione Detalles.

    Captura de pantalla de la solicitud de incorporación de cambios de GitHub que muestra los elementos de comprobación de estado. El vínculo

    Espere a que finalice la implementación.

  3. Selecciona Mostrar nombre de host del sitio web.

  4. Selecciona la dirección URL en el registro.

    Captura de pantalla del registro de implementación de Acciones de GitHub. La dirección URL del sitio web del paso

    El sitio web carga y muestra el mensaje ¡Hola, Docker!, lo que indica que el sitio web se ejecuta desde la imagen de contenedor definida en el cambio de la solicitud de incorporación de cambios.

    Captura de pantalla de la página principal del sitio web después de que la implementación se complete.

  5. Opcionalmente, abra Azure Portal y vaya al grupo de recursos del entorno efímero.

    Revise los recursos que se implementaron: cuenta de almacenamiento, servicio de aplicaciones y plan de servicio de aplicaciones.

Combinación de la solicitud de incorporación de cambios

Ahora que has probado la solicitud de incorporación de cambios, puedes combinarla en la rama principal.

  1. Selecciona Solicitudes de incorporación de cambios y, después, Usar la imagen de contenedor para la solicitud de incorporación de cambios del sitio web.

    Captura de pantalla de GitHub que muestra la lista de solicitudes de incorporación de cambios abiertas en el repositorio.

    Se han superado las comprobaciones de estado.

    Captura de pantalla de la solicitud de incorporación de cambios de GitHub que muestra que se han superado las dos comprobaciones de estado.

  2. Selecciona Combinar solicitud de incorporación de cambios.

  3. Selecciona Confirmar combinación.

Revisión de la eliminación del grupo de recursos

  1. En el explorador, seleccione Acciones y, a continuación, en el panel izquierdo, el flujo de trabajo pr-closed.

    Puede ver que el flujo de trabajo se ha invocado automáticamente porque se ha cerrado una solicitud de incorporación de cambios.

    Captura de pantalla del panel Acciones de GitHub que muestra que el flujo de trabajo cerrado de PR se está ejecutando.

  2. Selecciona el flujo de trabajo para revisar el registro.

    El flujo de trabajo puede tardar unos minutos en acabar de eliminar el grupo de recursos en Azure.

    Importante

    No es necesario esperar a que finalice la ejecución del flujo de trabajo. Sin embargo, no se olvide de abrir Azure Portal más tarde, tanto para verificar que el grupo de recursos del entorno efímero se haya eliminado correctamente como para evitar incurrir en costos por los recursos de Azure.

Limpieza de recursos

Una vez que haya terminado con el módulo, puede eliminar los recursos que ha creado:

  • Secretos de GitHub

    1. En el repositorio de GitHub, vaya a Configuración>Secretos y variables>Acciones.
    2. Seleccione el botón Eliminar para cada secreto de repositorio y siga las indicaciones.

  • Repositorio de GitHub

    1. Vaya a Configuración>General
    2. Desplácese hasta la parte inferior de la pantalla, 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 Aplicaciones de propiedad, seleccione toy-website-auto-review.
    4. Seleccione Eliminar y siga las indicaciones.
    5. Seleccione Aplicaciones eliminadas 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 id. de la aplicación para asegurarse de eliminar el recurso correcto.