BLOG | NGINX

Tutorial de NGINX: Cómo usar GitHub Actions para automatizar implementaciones Canary de microservicios

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Christopher Harrison
Christopher Harrison
Publicado el 21 de marzo de 2023

Esta publicación es uno de los cuatro tutoriales que te ayudan a poner en práctica los conceptos de Microservicios de marzo de 2023: Comience a entregar microservicios :

 

La automatización de las implementaciones es fundamental para el éxito de la mayoría de los proyectos. Sin embargo, no basta con simplemente implementar el código. También es necesario asegurarse de que el tiempo de inactividad sea limitado (o eliminado) y necesita la capacidad de volver atrás rápidamente en caso de una falla. La combinación de la implementación canaria y la implementación azul-verde es un enfoque común para garantizar que el nuevo código sea viable. Esta estrategia incluye dos pasos:

  • Paso 1: Implementación canaria para realizar pruebas de forma aislada : implemente su código en un nodo, servidor o contenedor aislado fuera de su entorno y realice pruebas para asegurarse de que el código funcione según lo previsto.
  • Paso 2: Implementación azul-verde para probar en producción : suponiendo que el código funciona en la implementación canaria, transfiera el código a servidores recién creados (o nodos o contenedores) en su entorno de producción junto con los servidores de la versión actual. Luego, redirija una parte del tráfico de producción a la nueva versión para probar si continúa funcionando bien bajo una carga mayor. Lo más frecuente es que comiences dirigiendo un pequeño porcentaje (digamos un 10%) a la nueva versión y vayas aumentándolo gradualmente hasta que la nueva versión reciba todo el tráfico. El tamaño de los incrementos depende de qué tan seguro esté de que la nueva versión puede manejar el tráfico; incluso puede cambiar completamente a la nueva versión en un solo paso.

Si no está familiarizado con los diferentes casos de uso para distribuir el tráfico entre diferentes versiones de una aplicación o sitio web ( división de tráfico ), lea Cómo mejorar la resiliencia en Kubernetes con la gestión avanzada del tráfico en nuestro blog para obtener una comprensión conceptual de las implementaciones azul-verde, los lanzamientos canarios, las pruebas A/B, la limitación de velocidad, la interrupción de circuitos y más. Si bien el blog es específico de Kubernetes, los conceptos son ampliamente aplicables 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 canaria usando GitHub Actions . En los cuatro desafíos del tutorial, utiliza Microsoft Azure Container Apps para implementar una nueva versión de su aplicação y, luego, utiliza Azure Traffic Manager para cambiar el tráfico del entorno anterior al nuevo:

Nota:  Si bien este tutorial utiliza Azure Container Apps, los conceptos y técnicas se pueden aplicar a cualquier host basado en la nube.

Prerrequisitos y configuración

Requisitos previos

Si quieres realizar 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 desea utilizarla en lugar de (o además de) la GUI de GitHub basada en navegador.

Configuración

Cree y configure los recursos base necesarios. Bifurque y clone el repositorio para el tutorial, inicie sesión en la CLI de Azure e instale la extensión para Azure Container Apps.

  1. En su directorio de inicio, cree el directorio microservices-march . (También puede utilizar un nombre de directorio diferente y adaptar las instrucciones en consecuencia).

    Nota:  A lo largo del tutorial se omite el aviso en la línea de comandos de Linux para que sea más fácil copiar y pegar los comandos en su terminal.

    mkdir ~/microservicios-marchcd ~/microservicios-march

  2. Bifurque y clone el repositorio de la plataforma Microservices March en su cuenta personal de GitHub, usando la CLI o la GUI de GitHub.

    • Si utiliza la GUI de GitHub:

      1. Haga clic en Bifurcar en la esquina superior derecha de la ventana y seleccione su cuenta personal de GitHub en el menú Propietario .

        Captura de pantalla de la GUI de GitHub que muestra la bifurcación del repositorio para este tutorial

      2. Clone el repositorio localmente, sustituyendo el nombre de su cuenta por <tu_cuenta_de_GitHub>:

        clon de git https://github.com/<tu_cuenta_de_GitHub>/platform.gitcd plataforma

    • Si usa la CLI de GitHub, ejecute:

      Repositorio gh bifurcación microservicios-marzo/plataforma -–clon

  3. Inicie sesión en la CLI de Azure. Siga las instrucciones para iniciar sesión con un navegador:

    inicio de sesión az [ { "cloudName": "AzureCloud", "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e", "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c", "isDefault": verdadero, "managedByTenants": [], "nombre": "Suscripción de Azure 1", "estado": "Habilitado", "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde", "usuario": { "nombre": "usuario@ejemplo.com", "tipo": "usuario" } } ]

  4. Instalar la extensión containerapp :

    az extension add --name containerapp -upgrade La extensión instalada 'containerapp' está en vista previa.

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

En este desafío inicial, creará una aplicación de contenedor de Azure NGINX como versión inicial de la aplicação utilizada como línea base para la implementación azul-verde canaria. Azure Container Apps es un servicio de Microsoft Azure que se utiliza para ejecutar fácilmente el código de aplicação empaquetado en un contenedor en un entorno de contenedores listo para producción.

  1. 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": "Éxito" }, "etiquetas": null, "tipo": "Microsoft.Resources/resourceGroups"

  2. Implemente el contenedor en Azure Container Apps (este paso puede tardar un tiempo):

    az containerapp up \ --resource-group my-container-app-rg \ --name my-container-app \ --source ./ingress \ --ingress external \ --target-port 80 \ --location westus ... - imagen: registro: cac085021b77acr .azurecr.io repositorio: my-container-app etiqueta: "20230315212413756768" resumen: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451... dependencia de ejecución: registro: registry.hub.docker.com repositorio: library/nginx etiqueta: "1.23" resumen: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce... git: {} ID de ejecución: cf1 se realizó correctamente después de 27 s Creando Containerapp my-container-app en el grupo de recursos my-container-app-rg Agregando la contraseña de registro como un secreto con el nombre "ca2ffbce7810acrazurecrio-cac085021b77acr" Aplicación de contenedor creada. Acceda a su aplicación en https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ ...

  3. En la salida del paso 2, busque el nombre y la URL de la aplicación de contenedor que ha creado en Azure Container Registry (ACR). Están resaltados en naranja en la salida de muestra. Sustituirás los valores de tu salida (que serán diferentes de la salida de muestra en el Paso 2) por las variables indicadas en los comandos a lo largo del tutorial:

    • Nombre de la aplicación contenedora : en la clave image.registry , la cadena de caracteres antes de .azurecr.io . En la salida de muestra del paso 2, es cac085021b77acr .

      Sustituya esta cadena de caracteres por <Nombre_ACR> en comandos posteriores.

    • URL de la aplicación contenedora : la URL en la línea que comienza con Aplicación contenedora creada . En la salida de muestra del paso 2, es https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ .

      Sustituya esta URL por <URL_ACR> en comandos posteriores.

  4. Habilite las revisiones para la aplicación contenedora según lo requiera una implementación azul-verde:

    az containerapp revision set-mode \ --name mi-aplicación-contenedor \ --resource-group mi-aplicación-contenedor-rg \ --mode multiple "Múltiple"

  5. (Opcional) Pruebe que la implementación esté funcionando consultando el punto final /health en el contenedor:

    rizo <URL_ACR>/saludDE ACUERDO

Desafío 2: Configurar permisos para automatizar las implementaciones de aplicaciones de contenedores de Azure

En este desafío, obtendrá el token JSON que le permite automatizar las implementaciones de aplicaciones de contenedores de Azure.

Comience por obtener el identificador del Registro de contenedores de Azure (ACR) y, luego, el identificador principal de su identidad administrada de Azure. Luego, asigna el rol de Azure integrado para ACR a la identidad administrada y configura la aplicación de contenedor para usar la identidad administrada. Finalmente, obtendrás las credenciales JSON para la identidad administrada, que GitHub Actions usará para autenticarse en Azure.

Si bien este conjunto de pasos puede parecer tedioso, solo es necesario realizarlos una vez al crear una nueva aplicação y puede programar todo el proceso. El tutorial le pide que realice los pasos manualmente para familiarizarse con ellos.

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

  1. Busque el ID principal de su identidad administrada. Aparece en la columna PrincipalID de la salida (que está dividida en dos líneas para facilitar la legibilidad). Sustituirás este valor por <ID principal de identidad administrada> en el paso 3:

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

  2. Busque el ID de recurso de la aplicación contenedora en ACR, reemplazando <Nombre_ACR> con el nombre que registraste en el Paso 3 de Desafío 1. Sustituirás este valor por <ID de recurso ACR> en el siguiente paso:

    az acr show --nombre <Nombre_ACR> --id de consulta --tsv de salida/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

  3. Asigne el rol de Azure integrado para ACR a la identidad administrada de la aplicación de contenedor, reemplazando <ID principal de identidad administrada> con la identidad administrada obtenida en el Paso 1, y <ID de recurso ACR> con el ID de recurso obtenido en el Paso 2:

    Asignación de roles az crear \ --assignee <ID principal de identidad administrada> --role AcrPull
--scope <ID de recurso ACR>
{
"condición": nulo,
"VersiónCondición": nulo,
"creadoPor": nulo,
"creadoEl": "2023-03-15T20:28:40.831224+00:00", "delegatedManagedIdentityResourceId": nulo, "description": nulo, "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", "ID principal": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f", "tipo principal": "Principal de Servicio", "Grupo de Recursos": "mi-registro-de-aplicaciones-de-contenedores", "IdDeDefiniciónDeRol": "/suscripciones/60e32142-384b-43r8-9329-0ecc67dca94c/proveedores/Microsoft.Authorization/definicionesderoles/7fd21dda-4fd3-4610-a1ca-43po272d538d", "ámbito": "/suscripciones/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/gruposderecursos/mi-registro-de-aplicaciones-de-contenedores/proveedores/Microsoft.RegistroDeContenedores/registros/cac085021b77acr", "tipo": "Microsoft.Autorización/Asignaciones de roles", "actualizado por": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d", "actualizado el": "2023-03-15T20:28:41.127243+00:00" }

  4. Configure la aplicación contenedora para usar la identidad administrada al extraer imágenes de ACR, reemplazando <Nombre_ACR> con el nombre de la aplicación contenedora que registró en el Paso 3 en Desafío 1 (y también se utiliza en el paso 2 anterior):

    conjunto de registro de az containerapp \ --name mi-aplicación-de-contenedor \
--grupo-de-recursos mi-aplicación-de-contenedor-rg \
--servidor <Nombre_ACR>.azurecr.io \ --sistema de identidad
[
{
"identidad": "sistema",
"ReferenciaSecretaDeContraseña": "",
"servidor": "cac085021b77acr.azurecr.io",
"nombreDeUsuario": ""
}
]

  5. Busque su identificador de suscripción de Azure .

    Mostrar cuenta az --ID de consulta --salida tsv 0efafl2-38ad-41w8-g49a-0ecc6723l97c

  6. Cree un token JSON que contenga las credenciales que utilizará la acción de GitHub, reemplazando <ID de suscripción> con su identificador de suscripción de Azure. Guarde el resultado para pegarlo como el valor del secreto llamado CREDENCIALES AZURE en Agregue secretos a su repositorio de GitHub. Puede ignorar con seguridad la advertencia sobre que --sdk-auth está obsoleto; es un problema conocido :

    La opción '--sdk-auth' ha quedado obsoleta y se eliminará en una versión futura. ... { "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er", "secreto del cliente": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe", "ID de suscripción": "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 de implementación azul-verde de Canary

En este desafío, agrega secretos a tu repositorio de GitHub (usado para administrar datos confidenciales en tus flujos de trabajo de Acción de GitHub), crea un archivo de flujo de trabajo de Acción y ejecuta el flujo de trabajo de Acción .

Para obtener una introducción detallada sobre la gestión de secretos, consulte el segundo tutorial para microservicios del 23 de marzo, Cómo administrar secretos en contenedores de forma segura en nuestro blog.

Agregue secretos a su repositorio de GitHub

Para implementar una nueva versión de la aplicação, debes crear una serie de secretos en el repositorio de GitHub que bifurcaste en Configuración . Los secretos son las credenciales JSON para la identidad administrada creada en el Desafío 2 y algunos parámetros confidenciales específicos de la implementación necesarios para implementar nuevas versiones de la imagen NGINX en Azure. En la siguiente sección, utilizará estos secretos en una acción de GitHub para automatizar la implementación azul-verde canaria.

  • Si utiliza la GUI de GitHub:

    1. Navega hasta tu repositorio de GitHub bifurcado.
    2. Seleccione Configuración > Secretos y variables > Acciones .
    3. Haga clic en Nuevo secreto de repositorio .

    4. Escriba los siguientes valores en los campos indicados:

      • Nombre – AZURE_CREDENTIALS
      • Secreto : Las credenciales JSON del paso 6 del desafío 2
    5. Haga clic en Agregar secreto .

    6. Repita los pasos 3 a 5 tres veces para crear los secretos enumerados en la tabla. Escriba los valores de las columnas Nombre secreto y Valor secreto en los campos Nombre y Secreto de la GUI respectivamente. Para el tercer secreto, reemplace <Nombre_ACR> con el nombre asignado a la aplicación contenedora que registró en el Paso 3 de Desafío 1.

      Nombre secreto Valor secreto
      NOMBRE DE LA APLICACIÓN DEL CONTENEDOR mi-aplicación-contenedor
      GRUPO DE RECURSOS mi-contenedor-app-rg
      NOMBRE_ACR <Nombre_ACR>
    7. Proceda a crear un archivo de flujo de trabajo de acción de GitHub .

  • Si utiliza la CLI de GitHub:

    1. En la raíz de su repositorio, cree un archivo temporal.

      toque ~/creds.json
    2. Usando su editor de texto preferido, abra creds.json y copie las credenciales JSON que creó en el Paso 6 del Desafío 2 .

    3. Crea el secreto:

      conjunto secreto gh AZURE_CREDENTIALS --repo <tu_cuenta_de_GitHub>/plataforma < ~/creds.json

    4. Eliminar creds.json :

      rm ~/creds.json

    5. Repita este comando para crear tres secretos más:

      conjunto secreto de gh <nombre_secreto> --repositorio <tu_cuenta_de_GitHub>/plataforma

      Para cada repetición, reemplace <nombre_secreto> con uno de los valores en el Nombre secreto columna en la tabla. Cuando se le solicite, pegue el valor asociado de la columna Valor secreto . Para el tercer secreto, reemplace <Nombre_ACR> con el nombre asignado a la aplicación contenedora que registró en el Paso 3 de Desafío 1.

      Nombre secreto Valor secreto
      NOMBRE DE LA APLICACIÓN DEL CONTENEDOR mi-aplicación-contenedor
      GRUPO DE RECURSOS mi-contenedor-app-rg
      NOMBRE_ACR <Nombre_ACR>

Crear un archivo de flujo de trabajo de acción de GitHub

Con la identidad administrada y los secretos en su lugar, puede crear un archivo de flujo de trabajo para una acción de GitHub que automatice la implementación azul-verde canaria.

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

  1. Cree un archivo para el flujo de trabajo de Acción.

    • Si utiliza la GUI de GitHub:

      1. Navega a tu repositorio de GitHub.
      2. Seleccione Acciones > Nuevo flujo de trabajo > Omitir esto y configurar un flujo de trabajo usted mismo .

    • Si usa la CLI de GitHub, cree el directorio .github/workflows y cree un nuevo archivo llamado main.yml :

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

  2. Usando su editor de texto preferido, agregue el texto del flujo de trabajo a main.yml . El método más fácil es copiar el texto que aparece en el Archivo de flujo de trabajo completo . Alternativamente, puede crear el archivo manualmente agregando el conjunto de fragmentos anotados 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 estar más seguro, compare su archivo con el Archivo de flujo de trabajo completo ).

    • Define el nombre del flujo de trabajo:

      nombre: Implementar en Azure

    • Configure el flujo de trabajo para que se ejecute cuando se realiza una solicitud de inserción o extracción a la rama principal:

      activado:
insertar:
ramas:
- principal
solicitud_de_extracción:
ramas:
- principal

    • En la sección de trabajos , defina el trabajo de compilación e implementación , que extrae el código, inicia sesión en Azure e implementa la aplicação en Azure Container App:

      trabajos: compilación-implementación: se ejecuta en: ubuntu-22.04 pasos: - nombre: Consulte los usos de la base de código: acciones/checkout@v3 - nombre: Inicie sesión en Azure usando: azure/login@v1 con: credenciales:${{ secrets.AZURE_CREDENTIALS } } - nombre: Construya e implemente la aplicación contenedora run: | # Agregue la extensión containerapp manualmente az extension add --name containerapp --upgrade # Use la CLI de Azure para implementar update az containerapp up -n${{ secrets.CONTAINER_APP_NAME } }\ -g${{ secrets.RESOURCE_GROUP } } \ --fuente${{ github.workspace } }/ingress \ --servidor de registro${{ secrets.ACR_NAME } }.azurecr.io

    • Define el trabajo de implementación de prueba , que obtiene la URL de prueba de la revisión recién implementada y utiliza una acción de GitHub para hacer ping al punto final /health de la API para garantizar que la nueva revisión esté respondiendo. Si la comprobación de estado es exitosa, Azure Traffic Manager en la aplicación de contenedor se actualiza para apuntar todo el tráfico al contenedor recién implementado.

      Nota:  Asegúrese de sangrar la clave de implementación de prueba al mismo nivel que la clave de implementación de compilación que definió en el punto anterior:

        prueba-implementación: necesita: compilación-implementación se ejecuta en: ubuntu-22.04 pasos: - nombre: Inicie sesión en Azure usando: azure/login@v1 con: credenciales:${{ secrets.AZURE_CREDENTIALS } } - nombre: Obtener el nuevo nombre del contenedor ejecutar: | # Agregar la extensión containerapp manualmente az extension add --name containerapp --upgrade # Obtener el nombre de la última revisión implementada REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # Obtener el fqdn de la última revisión implementada REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # Almacenar valores en variables de entorno echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - nombre: Id. de implementación de prueba: test-deployment usos: jtalk/url-health-check-action@v3 # Acción de Marketplace para tocar el punto final con: url: "https://${{ env.REVISION_FQDN } }/health" # Punto final de ensayo - nombre: Implementación exitosa ejecutar: | echo "¡Implementación exitosa! Habilitando nueva revisión "az containerapp ingress Traffic Set -n"${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision-weight "${{ env.REVISION_NAME } }=100"

Archivo de flujo de trabajo completo

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

nombre: Implementar en Azure en: push: ramas: - main pull_request: ramas: - main trabajos: build-deploy: se ejecuta en: ubuntu-22.04 pasos: - nombre: Consulte los usos de la base de código: acciones/checkout@v3 - nombre: Inicie sesión en Azure usando: azure/login@v1 con: credenciales:${{ secrets.AZURE_CREDENTIALS } } - nombre: Construir e implementar Container run: | # Agregar la extensión containerapp manualmente az extension add --name containerapp -upgrade # Usar la CLI de Azure para implementar update az containerapp up -n${{ secrets.CONTAINER_APP_NAME } } \ -g${{ secrets.RESOURCE_GROUP } } \ --fuente${{ github.workspace } }/ingress \ --servidor de registro${{ secrets.ACR_NAME } }.azurecr.io test-deployment: necesita: build-deploy se ejecuta en: ubuntu-22.04 pasos: - nombre: Inicie sesión en Azure usando: azure/login@v1 con: credenciales:${{ secrets.AZURE_CREDENTIALS } } - nombre: Obtener el nuevo nombre del contenedor ejecutar: | # Instalar la extensión containerapp para la CLI de Azure az extension add --name containerapp --upgrade # Obtener el nombre de la última revisión implementada REVISION_NAME=`az containerapp revision list -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --query "[].name" -o tsv | tail -1` # Obtener el fqdn de la última revisión implementada REVISION_FQDN=`az containerapp revision show -n${{ secrets.CONTAINER_APP_NAME } } -g${{ secrets.RESOURCE_GROUP } } --revision "$REVISION_NAME" --query properties.fqdn -o tsv` # Almacenar valores en variables de entorno echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV - nombre: Id. de implementación de prueba: test-deployment usos: jtalk/url-health-check-action@v3 # Acción de Marketplace para tocar el punto final con: url: "https://${{ env.REVISION_FQDN } }/health" # Punto final de ensayo - nombre: Implementación exitosa ejecutar: | echo "¡Implementación exitosa! Habilitando nueva revisión "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 acción

  • Si utiliza la GUI de GitHub:

    1. Haga clic en Iniciar confirmación , agregue un mensaje de confirmación si lo desea y en el cuadro de diálogo seleccione Confirmar nuevo archivo . El nuevo archivo de flujo de trabajo se fusiona con la rama principal y comienza a ejecutarse.
    2. Haga clic en Acciones para supervisar el progreso del flujo de trabajo.

  • Si utiliza la CLI de GitHub:

    1. Agregue main.yml al área de preparación de Git:

      git add .github/workflows/main.yml

    2. Confirmar el archivo:

      git commit -m "feat: crear flujo de trabajo de Acciones de GitHub"

    3. Envía tus cambios a GitHub:

      git push

    4. Supervisar el progreso del flujo de trabajo:

      vista de flujo de trabajo de gh main.yml --repo <tu_cuenta_de_GitHub>/plataforma

Desafío 4: Pruebe el flujo de trabajo de acciones de GitHub

En este desafío, prueba el flujo de trabajo. Primero simula una actualización exitosa de tu balanceador de carga Ingress y confirma que la aplicação se ha actualizado. Luego simula una actualización fallida (que genera un error interno del servidor) y confirma que la aplicação publicada permanece sin cambios.

Realizar una actualización exitosa

Cree una actualización exitosa y observe cómo el flujo de trabajo se realiza correctamente.

  • Si utiliza la GUI de GitHub:

    1. Seleccione Código > ingreso > default.conf.template .
    2. Abra default.conf.template para editarlo seleccionando el ícono de lápiz con la información sobre herramientas Editar este archivo .

    3. En el bloque de ubicación /salud cerca del final del archivo, cambie la directiva de retorno como se indica:

      ubicación/salud {
acceso_cerrar sesión;
devolver 200 "¡Actualización exitosa!\n";
}
    4. En el cuadro de diálogo, seleccione Crear una nueva rama para esta confirmación e iniciar una solicitud de extracción y luego Proponer cambios .
    5. Haga clic en Crear solicitud de extracción para acceder a la plantilla de solicitud de extracción.
    6. Haga clic en Crear solicitud de extracción nuevamente para crear la solicitud de extracción.
    7. Haga clic en Acciones para supervisar el progreso del flujo de trabajo.
    8. Cuando se complete el flujo de trabajo, navegue hasta su aplicación contenedora en la <URL_ACR>/salud punto final, donde el <URL_ACR> es la URL que anotó en el paso 3 de Desafío 1. ¡Observe el mensaje "Actualización exitosa" !

    9. Puede confirmar el mensaje iniciando una sesión de terminal y enviando una solicitud de verificación de estado a la aplicación, reemplazando nuevamente <URL_ACR> con el valor que registró en el Paso 3 de Desafío 1:

      rizo <URL_ACR>/salud¡Actualización exitosa!
    10. Proceder a realizar una actualización fallida .

  • Si utiliza la CLI de GitHub:

    1. Crea una nueva rama llamada patch-1 :

      git checkout -b parche-1

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

      ubicación/salud {
acceso_cerrar sesión;
devolver 200 "¡Actualización exitosa!\n";
}

    3. Agregue default.conf.template al área de preparación de Git:

      git add ingress/default.conf.template

    4. Confirmar el archivo:

      git commit -m "feat: actualizar la entrada de NGINX"

    5. Envía tus cambios a GitHub:

      git push --set-upstream origen parche-1

    6. Crear una solicitud de extracción (PR):

      gh pr create --head parche-1 --fill --repo <tu_cuenta_de_GitHub>/plataforma

    7. Supervisar el progreso del flujo de trabajo:

      vista de flujo de trabajo de gh main.yml --repo <tu_cuenta_de_GitHub>/plataforma

    8. Cuando se complete el flujo de trabajo, envíe una solicitud de verificación de estado a la aplicación, reemplazando <URL_ACR> con el valor que registró en el Paso 3 de Desafío 1:

      rizo <URL_ACR>/salud
¡Actualización exitosa!

Realizar una actualización fallida

Ahora cree una actualización fallida y observe cómo falla el flujo de trabajo. Básicamente, esto implica repetir los pasos de Realizar una actualización exitosa pero con un valor diferente para la directiva de retorno .

  • Si utiliza la GUI de GitHub:

    1. Seleccione Código > ingreso > default.conf.template .
    2. En la parte superior izquierda, selecciona main y luego el nombre de la rama que termina con patch-1 , que creaste en la sección anterior .
    3. Abra default.conf.template para editarlo seleccionando el ícono de lápiz con la información sobre herramientas Editar este archivo .

    4. Cambie la directiva de retorno como se indica:

      ubicación/salud {
acceso_cerrar sesión;
devuelve 500 "¡Actualización fallida!\n";
}
    5. Seleccione Confirmar directamente en la rama -patch-1 y luego Confirmar cambios .
    6. Seleccione Acciones para supervisar el progreso del flujo de trabajo. Observe que el flujo de trabajo se ejecuta nuevamente cuando se actualizan los archivos en el PR.

    7. Cuando se complete el flujo de trabajo, navegue hasta su aplicación contenedora en la <URL_ACR>/salud punto final, donde el <URL_ACR> es la URL que registraste en el paso 3 de Desafío 1.

       

      Tenga en cuenta que el mensaje es ¡Actualización exitosa ! (el mismo que después de la actualización exitosa anterior). Aunque esto pueda parecer paradójico, de hecho confirma que esta actualización falló: el intento de actualización resultó en el estado500 (que significa error interno del servidor ) y no se aplicó.

    8. Puede confirmar el mensaje iniciando una sesión de terminal y enviando una solicitud de verificación de estado a la aplicación, reemplazando nuevamente <URL_ACR> con el valor que registró en el Paso 3 de Desafío 1:

      rizo <URL_ACR>/salud¡Actualización exitosa!

  • Si utiliza la CLI de GitHub:

    1. Consulta la rama patch-1 que creaste en la sección anterior :

      parche git checkout-1

    2. En su editor de texto preferido, abra ingress/default.conf.template y nuevamente cambie la directiva de retorno como se indica:

      ubicación/salud {
acceso_cerrar sesión;
devuelve 500 "¡Actualización fallida!\n";
}

    3. Agregue default.conf.template al área de preparación de Git:

      git add ingress/default.conf.template

    4. Confirmar el archivo:

      git commit -m "feat: actualizar el ingreso de NGINX nuevamente"

    5. Envía tus cambios a GitHub:

      git push

    6. Supervisar el progreso del flujo de trabajo:

      vista de flujo de trabajo de gh main.yml --repo <tu_cuenta_de_GitHub>/plataforma

    7. Cuando se complete el flujo de trabajo, envíe una solicitud de verificación de estado a la aplicación, reemplazando <URL_ACR> con el valor que registró en el Paso 3 de Desafío 1:

      rizo <URL_ACR>/salud¡Actualización exitosa!

      Puede parecer paradójico que el mensaje sea ¡Actualización exitosa ! (el mismo que después de la actualización exitosa anterior). Aunque esto pueda parecer paradójico, de hecho confirma que esta actualización falló: el intento de actualización resultó en el estado500 (que significa error interno del servidor ) y no se aplicó.

Limpieza de recursos

Probablemente desee eliminar los recursos de Azure que implementó en el tutorial para evitar posibles cargos en el futuro:

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

También puedes eliminar la bifurcación que creaste si lo deseas.

  • Si utiliza la GUI de GitHub:

    1. Haga clic en Configuración .
    2. Desplácese hasta la parte inferior de la página.
    3. Haga clic en Eliminar este repositorio .
    4. Tipo <tu_cuenta_de_GitHub>/plataforma y seleccione Entiendo las consecuencias, elimine este repositorio.

  • Si utiliza la CLI de GitHub:

    eliminar repositorio gh <tu_cuenta_de_GitHub>/plataforma -sí

Próximos pasos

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

Si está listo para probar el segundo paso de una implementación canaria (prueba en producción), consulte el tutorial de Microservices de marzo de 2022, Mejore el tiempo de actividad y la resiliencia con una implementación canaria en nuestro blog. Utiliza NGINX Service Mesh para realizar la transición gradual a una nueva versión de la aplicación. Incluso si sus implementaciones aún no son lo suficientemente complejas como para necesitar una malla de servicios, o no está usando Kubernetes, los principios aún se aplican a implementaciones más simples que solo usan un controlador de Ingress o un balanceador de carga.

Para continuar su educación sobre microservicios, consulte Microservicios de marzo de 2023. En la Unidad 3, Acelerar las implementaciones de microservicios con automatización , aprenderá más sobre cómo automatizar las implementaciones.

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.