Tutorial de NGINX: cómo usar GitHub Actions para automatizar despliegues canary de microservicios

NGINX | 21 de marzo de 2023

Este artículo forma parte de una serie de cuatro tutoriales que le ayudarán a poner en práctica los conceptos de «Marzo de los microservicios de 2023: empiece a implementar microservicios»:

Cómo implementar y configurar microservicios
Cómo gestionar secretos de forma segura en contenedores
Cómo usar GitHub Actions para automatizar despliegues canary de microservicios (este artículo)
Cómo usar el rastreo de OpenTelemetry para comprender tus microservicios

Automatizar los despliegues es fundamental para el éxito de la mayoría de los proyectos. Sin embargo, no basta con desplegar el código. También hay que garantizar que el tiempo de inactividad sea limitado (o inexistente) y poder revertir rápidamente los cambios en caso de fallo. Combinar el despliegue canario y el despliegue azul-verde es un enfoque habitual para garantizar que el código nuevo sea viable. Esta estrategia consta de dos pasos:

Paso 1: Despliegue canario para realizar pruebas de forma aislada – Despliega el código en un nodo, servidor o contenedor aislado fuera de tu entorno y realiza pruebas para asegurarte de que funciona según lo previsto.
Paso 2: Despliegue azul-verde para realizar pruebas en producción – Si el código funciona correctamente en el despliegue canario, impleméntelo en servidores (o nodos o contenedores) recién creados en su entorno de producción, junto con los servidores de la versión actual. A continuación, redirija una parte del tráfico de producción a la nueva versión para comprobar si sigue funcionando correctamente con una carga mayor. Lo más habitual es empezar dirigiendo un pequeño porcentaje (por ejemplo, un 10 %) a la nueva versión e incrementarlo gradualmente hasta que esta reciba todo el tráfico. El tamaño de los incrementos depende de la confianza que tenga en que la nueva versión pueda gestionar el tráfico; incluso puede cambiar por completo a la nueva versión en un solo paso.

Si no conoce los distintos casos de uso para distribuir el tráfico entre diferentes versiones de una aplicación o un sitio web (división del tráfico), lea Cómo mejorar la resiliencia en Kubernetes con una gestión avanzada del tráfico en nuestro blog para comprender los conceptos de los despliegues azul-verde, las versiones canary, las pruebas A/B, la limitación de velocidad, los disyuntores y mucho más. Aunque el artículo se centra específicamente en Kubernetes, estos conceptos son aplicables en términos generales a las aplicaciones de microservicios.

Descripción general del tutorial

En este tutorial, mostramos cómo automatizar el primer paso de una implementación azul-verde de tipo canary mediante GitHub Actions. En los cuatro retos del tutorial, utilizarás Azure Container Apps de Microsoft para implementar una nueva versión de tu aplicación y, a continuación, Azure Traffic Manager para redirigir el tráfico del entorno antiguo al nuevo:

Crear e implementar una aplicación de contenedor NGINX
Configurar permisos para automatizar las implementaciones de Azure Container Apps
Crear una implementación blue-green de tipo canary con una acción de GitHub
Probar el flujo de trabajo de GitHub Actions

Nota: Aunque este tutorial utiliza Azure Container Apps, los conceptos y las técnicas se pueden aplicar a cualquier servicio de alojamiento en la nube.

Requisitos previos y configuración

Requisitos previos

Si quieres seguir este tutorial en tu propio entorno, necesitas:

Una cuenta de Azure. Le recomendamos que utilice una cuenta que no esté vinculada a su organización, ya que podría tener problemas con los permisos al utilizar una cuenta de la organización.
La CLI de Azure.
La CLI de GitHub, si quieres utilizarla en lugar de la interfaz gráfica de GitHub para navegadores (o además de ella).

Configuración

Crea y configura los recursos básicos necesarios. Haz un fork y clona el repositorio del tutorial, inicia sesión en la CLI de Azure e instala la extensión para Azure Container Apps.

En su directorio personal, cree el directorio microservices-march. (También puede usar otro nombre de directorio y adaptar las instrucciones en consecuencia). Nota: A lo largo del tutorial se omite el indicador de la línea de comandos de Linux para facilitar que pueda copiar y pegar los comandos en su terminal.

mkdir ~/microservices-marchcd ~/microservices-march

Haz un fork y clona el repositorio de la plataforma Microservices March en tu cuenta personal de GitHub mediante la CLI o la interfaz gráfica de GitHub.
- Si utilizas la interfaz gráfica de GitHub:
  1. Haz clic en «Fork» en la esquina superior derecha de la ventana y selecciona tu cuenta personal de GitHub en el menú «Owner».
  2. Clona el repositorio en tu equipo, sustituyendo tu nombre de cuenta por <your_GitHub_account>:

git clone https://github.com/<your_GitHub_account>/platform.gitcd platform

Si utilizas la CLI de GitHub, ejecuta:

gh repo fork microservices-march/platform -–clone

Inicia sesión en la CLI de Azure. Sigue las indicaciones para iniciar sesión mediante un navegador:

az login
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e",
    "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

Instala la extensión containerapp:

az extension add --name containerapp -upgradeThe installed extension 'containerapp' is in preview.

Desafío 1: Crear e implementar una aplicación de contenedor NGINX

En este reto inicial, creará una aplicación de contenedor de Azure con NGINX como versión inicial de la aplicación, que se utilizará como referencia para la implementación canary azul-verde. Azure Container Apps es un servicio de Microsoft Azure que permite ejecutar fácilmente código de aplicaciones empaquetado en un contenedor dentro de un entorno de contenedores listo para producción.

Cree un grupo de recursos de Azure para la aplicación de contenedor:

az group create --name my-container-app-rg --location westus{
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg",
  "location: "westus",
  "managedBy": null,
  "name": "my-container-app-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

Implementa el contenedor en Azure Container Apps (este paso puede tardar un poco):

az containerapp up --resource-group my-container-app-rg --name my-container-app --source ./ingress --ingress external --target-port 80 --location westus
... 
- image:
    registry: cac085021b77acr.azurecr.io
    repository: my-container-app
    tag: "20230315212413756768"
    digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451...
  runtime-dependency:
    registry: registry.hub.docker.com
    repository: library/nginx
    tag: "1.23"
    digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce...
  git: {} 
Run ID: cf1 was successful after 27s
Creating Containerapp my-container-app in resource group my-container-app-rg
Adding registry password as a secret with name "ca2ffbce7810acrazurecrio-cac085021b77acr" 
Container app created. Access your app at https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/
...

En la salida del paso 2, busca el nombre y la URL de la aplicación de contenedor que has creado en Azure Container Registry (ACR). Aparecen resaltados en naranja en la salida de ejemplo. A lo largo del tutorial, sustituirás las variables indicadas en los comandos por los valores de tu salida (que serán diferentes de los de la salida de ejemplo del paso 2):
- Nombre de la aplicación de contenedor : en la clave image.registry, la cadena de caracteres situada antes de .azurecr.io. En la salida de ejemplo del paso 2, es cac085021b77acr. Sustituya <ACR_name> por esta cadena de caracteres en los comandos posteriores.
- URL de la aplicación de contenedor – La URL de la línea que comienza por Container app created. En la salida de ejemplo del paso 2, es https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/. Sustituya <ACR_URL> por esta URL en los comandos posteriores.
Habilite las revisiones de la aplicación de contenedor según sea necesario para una implementación azul-verde:

az containerapp revision set-mode --name my-container-app --resource-group my-container-app-rg --mode multiple
"Multiple"

(Opcional) Comprueba que el despliegue funciona consultando el endpoint /health del contenedor:

curl <ACR_URL>/healthOK

Desafío 2: Configurar permisos para automatizar las implementaciones de Azure Container Apps

En este reto, obtendrá el token JSON que le permitirá automatizar las implementaciones de aplicaciones de contenedor de Azure.

Empieza por obtener el identificador de Azure Container Registry (ACR) y, a continuación, el identificador de entidad de seguridad de su identidad administrada. Después, asigne el rol integrado de Azure para ACR a la identidad administrada y configure la aplicación de contenedor para que utilice dicha identidad. Por último, obtenga las credenciales JSON de la identidad administrada, que GitHub Actions utilizará para autenticarse en Azure.

Aunque este conjunto de pasos pueda parecer tedioso, solo tendrá que realizarlos una vez al crear una nueva aplicación y podrá automatizar por completo el proceso mediante scripts. En el tutorial, realizará los pasos manualmente para familiarizarse con ellos.

Nota: Este proceso para crear credenciales de implementación es específico de Azure.

Busca el identificador de entidad de seguridad de tu identidad administrada. Aparece en la columna PrincipalID de la salida (que se divide en dos líneas para facilitar su lectura). Sustituirás <managed_identity_principal_ID> por este valor en el paso 3:

az containerapp identity assign --name my-container-app --resource-group my-container-app-rg --system-assigned --output table
PrincipalId                          ...                           
------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ...
 
    ... TenantId
    ... ------------------------------------
        ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

Busca el identificador de recurso de la aplicación de contenedor en ACR y sustituye <ACR_name> por el nombre que anotaste en el paso 3 del Reto 1. En el siguiente paso, sustituirás <ACR_resource_ID> por este valor:

az acr show --name <ACR_name> --query id --output tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

Asigne el rol integrado de Azure para ACR a la identidad administrada de la aplicación de contenedor, sustituyendo <managed_identity_principal_ID> por la identidad administrada obtenida en el paso 1 y <ACR_resource_ID> por el identificador de recurso obtenido en el paso 2:

az role assignment create --assignee <managed_identity_principal_ID> --role AcrPull --scope <ACR_resource_ID>
{
  "condition": null,
  "conditionVersion": null,
  "createdBy": null,
  "createdOn": "2023-03-15T20:28:40.831224+00:00",
  "delegatedManagedIdentityResourceId": null,
  "description": null,
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed16007ff249",
  "name": "f0773943-8769-44c6-a820-ed16007ff249",
  "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f",
  "principalType": "ServicePrincipal",
  "resourceGroup": "my-container-app-rg",
  "roleDefinitionId": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d",
  "scope": "/subscriptions/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr",
  "type": "Microsoft.Authorization/roleAssignments",
  "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d",
  "updatedOn": "2023-03-15T20:28:41.127243+00:00"
}

Configure la aplicación de contenedor para que use la identidad administrada al extraer imágenes de ACR, sustituyendo <ACR_name> por el nombre de la aplicación de contenedor que anotó en el paso 3 del Reto 1 (y que también utilizó en el paso 2 anterior):

az containerapp registry set --name my-container-app --resource-group my-container-app-rg --server <ACR_name>.azurecr.io --identity system
[
  {
    "identity": "system",
    "passwordSecretRef": "",
    "server": "cac085021b77acr.azurecr.io",
    "username": ""
  }
]

Busca tu ID de suscripción de Azure.

az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97c

Crea un token JSON que contenga las credenciales que utilizará la acción de GitHub, sustituyendo <subscription_ID> por el identificador de tu suscripción de Azure. Guarda el resultado para pegarlo como valor del secreto denominado AZURE_CREDENTIALS en Añadir secretos a tu repositorio de GitHub. Puedes ignorar sin problema la advertencia que indica que --sdk-auth está obsoleto; se trata de un problema conocido:

az ad sp create-for-rbac --name my-container-app-rbac --role contributor --scopes /subscriptions/<subscription_ID>/resourceGroups/my-container-app-rg --sdk-auth --output json
Option '--sdk-auth' has been deprecated and will be removed in a future release.
...
{
  "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er",
  "clientSecret": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe",
  "subscriptionId": "0efafl2-38ad-41w8-g49a-0ecc6723l97c",
  "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Desafío 3: Crear una acción de GitHub para un despliegue canary blue-green

En este reto, añadirás secretos a tu repositorio de GitHub (que se utilizan para gestionar datos confidenciales en tus flujos de trabajo de GitHub Actions), crearás un archivo de flujo de trabajo de GitHub Actions y ejecutarás el flujo de trabajo de GitHub Actions.

Para obtener una introducción detallada a la gestión de secretos, consulta el segundo tutorial de Microservices March 23, «Cómo gestionar secretos de forma segura en contenedores», en nuestro blog.

Añade secretos a tu repositorio de GitHub

Para implementar una nueva versión de la aplicación, debes crear una serie de secretos en el repositorio de GitHub que bifurcaste en Configuración. Los secretos son las credenciales JSON de la identidad administrada creada en el Reto 2, así como algunos parámetros confidenciales específicos de la implementación necesarios para implementar nuevas versiones de la imagen de NGINX en Azure. En la siguiente sección usarás estos secretos en una acción de GitHub para automatizar la implementación azul-verde de tipo canario.

Si utiliza la interfaz gráfica de GitHub:
1. Ve a tu repositorio bifurcado de GitHub.
2. Selecciona «Settings > Secrets and variables > Actions».
3. Haz clic en «Nuevo secreto del repositorio».
4. Introduce los siguientes valores en los campos indicados:
  - Nombre – AZURE_CREDENTIALS
  - Secreto – Las credenciales JSON del paso 6 de Reto 2
5. Haz clic en «Añadir secreto».
6. Repita los pasos 3–5 tres veces para crear los secretos que aparecen en la tabla. Introduzca los valores de las columnas «Nombre del secreto» y «Valor del secreto» en los campos «Nombre» y «Secreto» de la interfaz gráfica, respectivamente. Para el tercer secreto, sustituya «<ACR_name>» por el nombre asignado a la aplicación de contenedor que anotó en el paso 3 del Reto 1. Nombre del secreto Valor del secretoCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>
7. Continúe con «Crear un archivo de flujo de trabajo de GitHub Actions».
Si utilizas la CLI de GitHub:
1. En la raíz de tu repositorio, crea un archivo temporal.

touch ~/creds.json

Con el editor de texto que prefieras, abre creds.json y pega las credenciales JSON que creaste en el paso 6 del Reto 2.
Crea el secreto:

gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.json

Elimina creds.json:

rm ~/creds.json

Repite este comando para crear tres secretos más:

gh secret set <secret_name> --repo <your_GitHub_account>/platform

En cada repetición, sustituya <secret_name> por uno de los valores de la columna Nombre del secreto de la tabla. Cuando se le solicite, pegue el valor correspondiente de la columna Valor del secreto. Para el tercer secreto, sustituya <ACR_name> por el nombre asignado a la aplicación de contenedor que anotó en el paso 3 del Reto 1. Nombre del secreto Valor del secretoCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>

Crear un archivo de flujo de trabajo de GitHub Actions

Una vez configurados la identidad administrada y los secretos, puede crear un archivo de flujo de trabajo para una acción de GitHub que automatice la implementación blue-green de tipo canary.

Nota: Los archivos de flujo de trabajo se definen en formato YAML, en el que los espacios en blanco son significativos. Asegúrese de conservar la sangría que se muestra en los pasos siguientes.

Crea un archivo para el flujo de trabajo de la acción.
- Si utilizas la interfaz gráfica de GitHub:
  1. Ve a tu repositorio de GitHub.
  2. Selecciona «Actions > New workflow > Skip this and set up a workflow yourself».
- Si utilizas la CLI de GitHub, crea el directorio .github/workflows y crea un archivo nuevo llamado main.yml:

mkdir .github/workflowstouch .github/workflows/main.yml

Con el editor de texto que prefiera, añada el texto del flujo de trabajo a main.yml. La forma más sencilla es copiar el texto que aparece en Archivo completo del flujo de trabajo. También puede crear el archivo manualmente añadiendo el conjunto de fragmentos indicados en este paso. Nota: Los archivos de flujo de trabajo se definen en formato YAML, donde los espacios en blanco son significativos. Si copia los fragmentos, asegúrese de conservar la sangría (y, para mayor seguridad, compare su archivo con el Archivo completo del flujo de trabajo.
- Define el nombre del flujo de trabajo:

name: Deploy to Azure

Configura el flujo de trabajo para que se ejecute cuando se realice un push o una solicitud de incorporación de cambios en la rama principal:

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

En la sección jobs, define el trabajo build-deploy, que obtiene el código, inicia sesión en Azure e implementa la aplicación en Azure Container App:

jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Build and deploy Container App
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }}
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io

Define el trabajo test-deployment, que obtiene la URL del entorno de ensayo de la revisión recién implementada y utiliza una acción de GitHub para hacer ping al punto de conexión de la API /health y comprobar que la nueva revisión responde. Si la comprobación de estado se realiza correctamente, Azure Traffic Manager se actualiza en la aplicación de contenedor para dirigir todo el tráfico al contenedor recién implementado. Nota: Asegúrese de aplicar a la clave test-deployment el mismo nivel de sangría que a la clave build-deploy que definió en el punto anterior:

  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade

          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Archivo completo del flujo de trabajo

Este es el texto completo del archivo de flujo de trabajo de la acción.

name: Deploy to Azure
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
     
      - name: Build and deploy Container 
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp -upgrade
       
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }} 
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io
  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Install the containerapp extension for the Azure CLI
          az extension add --name containerapp --upgrade
          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Ejecutar el flujo de trabajo de la acción

Si utilizas la interfaz gráfica de GitHub:
1. Haz clic en «Iniciar confirmación», añade un mensaje de confirmación si lo deseas y, en el cuadro de diálogo, selecciona «Confirmar archivo nuevo». El nuevo archivo de flujo de trabajo se fusiona con la rama principal y comienza a ejecutarse.
2. Haz clic en Actions para supervisar el progreso del flujo de trabajo.
Si utiliza la CLI de GitHub:
1. Añade main.yml al área de preparación de Git:

git add .github/workflows/main.yml

Confirma el archivo:

git commit -m "feat: create GitHub Actions workflow"

Sube tus cambios a GitHub:

git push

Supervisa el progreso del flujo de trabajo:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Desafío 4: Probar el flujo de trabajo de GitHub Actions

En este reto, probará el flujo de trabajo. Primero, simulará una actualización correcta del equilibrador de carga de Ingress y confirmará que la aplicación se ha actualizado. A continuación, simulará una actualización fallida (que provoca un error interno del servidor) y confirmará que la aplicación publicada permanece sin cambios.

Realizar una actualización correctamente

Crea una actualización correcta y observa cómo el flujo de trabajo se completa con éxito.

Si utilizas la interfaz gráfica de GitHub:
1. Selecciona «Code > ingress > default.conf.template».
2. Abre «default.conf.template» para editarlo seleccionando el icono del lápiz con la información sobre herramientas «Editar este archivo».
3. En el bloque location /health situado cerca del final del archivo, cambie la directiva return como se indica:

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

En el cuadro de diálogo, selecciona «Crear una rama nueva para esta confirmación e iniciar una solicitud de incorporación de cambios» y, a continuación, «Proponer cambios».
Haz clic en «Crear solicitud de incorporación de cambios» para acceder a la plantilla de solicitud de incorporación de cambios.
Haz clic en Crear solicitud de incorporación de cambios de nuevo para crear la solicitud de incorporación de cambios.
Haz clic en «Acciones» para supervisar el progreso del flujo de trabajo.
Cuando se complete el flujo de trabajo, acceda a la aplicación de contenedor en el punto de conexión <ACR_URL>/health, donde <ACR_URL> es la URL que anotó en el paso 3 del Reto 1. Observe el mensaje Actualización correcta.
Puede confirmar el mensaje iniciando una sesión de terminal y enviando una solicitud de comprobación de estado a la aplicación. De nuevo, sustituya <ACR_URL> por el valor que anotó en el paso 3 del Reto 1:

curl <ACR_URL>/healthSuccessful Update!

Continúe con «Realizar una actualización fallida».

Si utilizas la CLI de GitHub:
1. Crea una nueva rama llamada patch-1:

git checkout -b patch-1

En su editor de texto preferido, abra ingress/default.conf.template y, en el bloque location /health situado cerca del final del archivo, cambie la directiva return como se indica:

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

Añade default.conf.template al área de preparación de Git:

git add ingress/default.conf.template

Confirma el archivo:

git commit -m "feat: update NGINX ingress"

Sube tus cambios a GitHub:

git push --set-upstream origin patch-1

Crea una solicitud de incorporación de cambios (PR):

gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platform

Supervisa el progreso del flujo de trabajo:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Cuando finalice el flujo de trabajo, envía una solicitud de comprobación de estado a la aplicación, sustituyendo <ACR_URL> por el valor que anotaste en el paso 3 del Reto 1:

curl <ACR_URL>/health
Successful Update!

Realizar una actualización fallida

Ahora crea una actualización fallida y observa cómo falla el flujo de trabajo. Básicamente, esto implica repetir los pasos de «Realizar una actualización correcta», pero con un valor diferente para la directiva «return».

Si utiliza la interfaz gráfica de GitHub:
1. Selecciona «Code > ingress > default.conf.template».
2. En la esquina superior izquierda, selecciona «main» y, a continuación, el nombre de la rama que termina en «patch-1», que creaste en la sección anterior.
3. Abre default.conf.template para editarlo seleccionando el icono del lápiz con la información sobre herramientas Editar este archivo.
4. Cambie la directiva return como se indica:

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

Selecciona «Confirmar directamente en la rama -patch-1» y, a continuación, «Confirmar cambios».
Selecciona «Acciones» para supervisar el progreso del flujo de trabajo. Ten en cuenta que el flujo de trabajo vuelve a ejecutarse cuando se actualizan los archivos de la solicitud de incorporación de cambios.
Cuando se complete el flujo de trabajo, ve a la aplicación de contenedor en el punto de conexión <ACR_URL>/health, donde <ACR_URL> es la URL que anotaste en el paso 3 del Desafío 1. Observa que el mensaje es Successful Update! (el mismo que después de la actualización correcta anterior). Aunque pueda parecer paradójico, en realidad confirma que esta actualización ha fallado: el intento de actualización ha dado como resultado el estado 500 (que significa Error interno del servidor) y no se ha aplicado.
Puede confirmar el mensaje iniciando una sesión de terminal y enviando una solicitud de comprobación de estado a la aplicación. De nuevo, sustituya <ACR_URL> por el valor que anotó en el paso 3 del Reto 1:

curl <ACR_URL>/healthSuccessful Update!

Si utilizas la CLI de GitHub:
1. Cambia a la rama patch-1 que creaste en la sección anterior:

git checkout patch-1

En el editor de texto que prefiera, abra ingress/default.conf.template y vuelva a modificar la directiva return como se indica:

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

Añade default.conf.template al área de preparación de Git:

git add ingress/default.conf.template

Confirma el archivo:

git commit -m "feat: update NGINX ingress again"

Sube tus cambios a GitHub:

git push

Supervisa el progreso del flujo de trabajo:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Cuando finalice el flujo de trabajo, envía una solicitud de comprobación de estado a la aplicación, sustituyendo <ACR_URL> por el valor que anotaste en el paso 3 del Reto 1:

curl <ACR_URL>/healthSuccessful Update!

Puede parecer paradójico que el mensaje sea Successful Update! (el mismo que tras la actualización anterior, que se realizó correctamente). Aunque pueda parecer paradójico, en realidad confirma que esta actualización ha fallado: el intento de actualización dio como resultado el estado 500 (que significa Internal Server Error) y no se aplicó.

Limpieza de recursos

Probablemente querrás eliminar los recursos de Azure que implementaste en el tutorial para evitar posibles cargos en el futuro:

az group delete -n my-container-app-rg -y

También puedes eliminar el fork que has creado si lo deseas.

Si utilizas la interfaz gráfica de GitHub:
1. Haz clic en Configuración.
2. Desplázate hasta el final de la página.
3. Haz clic en «Eliminar este repositorio».
4. Escribe <your_GitHub_account>/platform y selecciona Entiendo las consecuencias, eliminar este repositorio.
Si utiliza la CLI de GitHub:

gh repo delete <your_GitHub_account>/platform -yes

Próximos pasos

¡Enhorabuena! Has aprendido a usar GitHub Actions para realizar una implementación azul-verde de tipo canary de una aplicación de microservicios. Consulta estos artículos de la documentación de GitHub para seguir explorando y ampliando tus conocimientos sobre DevOps:

Si ya está listo para probar el segundo paso de una implementación canary (las pruebas en producción), consulte el tutorial de Microservices March 2022, Mejore la disponibilidad y la resiliencia con una implementación canary en nuestro blog. En él se utiliza NGINX Service Mesh para realizar una transición gradual a una nueva versión de la aplicación. Aunque sus implementaciones aún no sean lo suficientemente complejas como para necesitar una malla de servicios, o no utilice Kubernetes, estos principios también se aplican a implementaciones más sencillas que solo utilizan un controlador de Ingress o un balanceador de carga.

Para seguir ampliando tus conocimientos sobre microservicios, consulta Microservices March 2023. En la Unidad 3: Acelera las implementaciones de microservicios mediante la automatización aprenderás más sobre cómo automatizar las implementaciones.