CI/CD Pipelines para aplicaciones de procesamiento de datos en Azure Parte 1 Instancias de contenedor

Pipelines de CI/CD para aplicaciones de procesamiento de datos en Azure - Parte 1 Instancias de contenedor

Una guía paso a paso para implementar contenedores Docker con GitHub Actions

Introducción

Crear y implementar recursos manualmente en Azure y otros proveedores de nube es relativamente fácil y, en algunos casos, puede ser suficiente. Sin embargo, con frecuencia, los recursos implementados necesitarán cambiar con el tiempo, lo que a su vez requiere mucho trabajo adicional para mantener y volver a implementar los recursos. Para automatizar estas tareas, los desarrolladores y profesionales de datos pueden utilizar un enfoque de infraestructura como código (IaC) y crear canalizaciones para integración y implementación continuas (CI/CD). Este enfoque permite a los desarrolladores escribir código que define y vuelve a implementar automáticamente los recursos cada vez que se realizan cambios.

En esta guía paso a paso, construiremos canalizaciones para una aplicación de procesamiento de datos que realiza las siguientes tareas:

• Provisionar un registro de contenedores
• Crear y enviar una imagen de Docker al registro
• Crear una instancia de contenedor que ejecute la carga de trabajo de procesamiento de datos
• Habilitar el acceso de ‘identidad administrada’ a Azure Key Vault, lo que permite que nuestra aplicación recupere claves de acceso a otros recursos, como cuentas de almacenamiento
• Implementar los recursos anteriores en un entorno de prueba y un entorno de producción usando disparadores diferentes para ejecutar las canalizaciones

Primeros pasos

Para fines de demostración, la aplicación en sí consiste en un script R muy simple que carga un conjunto de datos, muestra las primeras filas y devuelve el conjunto de datos a una cuenta de almacenamiento. Tenga en cuenta que el código de la aplicación no es importante para el resto de la canalización y fácilmente se puede sustituir por su propio código.

Para comenzar, necesitará una cuenta de Azure. Es posible que también desee instalar el CLI de Azure en su sistema local. Sin embargo, también puede optar por ejecutar comandos de Azure CLI a través de Cloud Shell que se encuentra en el portal de Azure.

• Falso profeta un modelo de regresión de series temporales casero
• DLSS 3.5 con reconstrucción de rayos ahora disponible en NVIDIA Omniverse
• Cabalgando los Rayos Sunswift Racing Brilla en la Carrera del Desafío Solar Mundial

Dado que nuestra aplicación transfiere datos desde y hacia Azure Blob Storage y devuelve los datos procesados, puede resultar útil instalar Azure Storage Explorer, que facilita un poco la carga de archivos y la verificación de que la aplicación se ejecute correctamente y devuelva los datos procesados.

Paso 1: Clonar el repositorio y configurar recursos estáticos

Primero deberá clonar este repositorio. El archivo README detalla cómo hacer esto usando RStudio, pero puede usar su IDE preferido.

A continuación, utilizando el Portal de Azure, cree los siguientes recursos:

• un grupo de recursos que contendrá todos los demás recursos.
• una cuenta de almacenamiento con un contenedor de blob con dos carpetas: una para los archivos de entrada y otra para los archivos de salida. En nuestro caso, deberían llamarse ‘input’ y ‘output’, respectivamente. Guarde un conjunto de datos pequeño como archivo CSV llamado ‘input_data.csv’ dentro del contenedor de entrada.
• un almacén de claves en el que deberá almacenar la clave de acceso principal de su cuenta de almacenamiento como un secreto.

En el paso 3, necesitará el nombre de su almacén de claves y el nombre de su secreto que contiene la clave de acceso principal.

Paso 2: Vincular GitHub a Azure

Para poder actualizar los recursos de Azure, debemos otorgar permisos a GitHub para hacerlo.

Primero, inicie sesión en su cuenta de Azure usando Azure CLI.

az login

A continuación, copie el valor id de la salida JSON, que es el ID de suscripción. Pegue el ID de suscripción en el siguiente comando y ejecútelo. Esto crea un ‘principal de servicio’ con control de acceso basado en roles, que se puede considerar como un usuario que actúa en su nombre al implementar o actualizar recursos con el flujo de trabajo de GitHub Actions.

az ad sp create-for-rbac \ --name "your-app-name" \ --role Owner \ --scopes /subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group-name> \ --sdk-auth

Copia el resultado JSON completo y ve a tu repositorio de GitHub y haz clic en Configuración > Secretos y variables > Acciones.

Crea un nuevo secreto del repositorio y nómbralo AZURE_CREDENTIALS. Pega el resultado JSON del comando anterior y guárdalo.

Paso 3: modificar los scripts

En este escenario, estamos implementando un R-script simple que no hace mucho. Como tal, el Dockerfile también se mantiene muy simple. Ambos archivos obviamente deberán modificarse según tus requisitos y lenguaje de programación preferido. Sin embargo, si eres nuevo en esto, puede ser útil poner en marcha tu canalización con el código tal como está antes de aplicar tu propio código.

Si decides continuar con el R-script actual (script.R), solo necesitarás modificar los valores {nombre-keyvault}, {nombre-clave-de-acceso} y {nombre-de-cuenta-de-almacenamiento} (omitir los corchetes).

A continuación, modifica los siguientes valores en env: en los dos archivos de flujo de trabajo llamados workflow.yml y workflow_release_prod.yml en el directorio .github/workflows/:

env:  RESOURCEGROUP_NAME: mi-rg  REGISTRY_NAME: mi-cr  SHORT_NAME: micr  ACI_NAME: mi-ci-test  KV_NAME: mi-kv  ENVIRONMENT: prueba  CPU: 1  MEMORY: 1.5

Paso 4: ejecutar la pipeline y la instancia del contenedor

Cuando se hayan realizado todos los cambios relevantes y se hayan enviado ala rama ‘main’, verás tu pipeline ejecutándose en el panel de Acciones. Esto se debe a que el flujo de trabajo está configurado con un disparador de rama para que se ejecute cuando se actualice la rama principal.

Si no encuentras errores, tu instancia del contenedor debería estar lista para ejecutarse en unos diez minutos aproximadamente. Ve al portal de Azure, encuentra tu nueva instancia del contenedor y haz clic en Iniciar. En el panel de Registros, es posible que veas tu script ejecutándose en la consola. Después de completar, verifica que se haya agregado un nuevo archivo cv llamado output_data.csv en la carpeta ‘output’ de tu contenedor de blobs.

¡Y eso es todo! Si lo deseas, ahora puedes ejecutar manualmente el segundo flujo de trabajo que crea una instancia del contenedor idéntica destinada a cargas de trabajo de producción.

Para comprender lo que sucede en el flujo de trabajo de CI / CD, lee la sección a continuación.

Comprensión de la lógica del flujo de trabajo

El archivo workflow.yml define cinco pasos, o trabajos, en nuestra canalización que implementa recursos en un entorno de prueba.

Primero pasamos las variables de entorno previamente establecidas requeridas para los pasos restantes como outputs.

vars:  runs-on: ubuntu-latest  outputs:    resource_group: ${{ env.RESOURCEGROUP_NAME }}    acr_name: ${{ env.REGISTRY_NAME }}    short_name: ${{ env.SHORT_NAME }}    aci_name: ${{ env.ACI_NAME }}    kv_name: ${{ env.KV_NAME }}    environment: ${{ env.ENVIRONMENT }}    cpu: ${{ env.CPU }}    memory: ${{ env.MEMORY }}  steps:    - run: echo "Exponiendo variables de entorno"

En el segundo paso, creamos o actualizamos un registro de contenedor existente. Ten en cuenta que la clave needs indica que este paso debe esperar a que se complete el paso anterior. La clave uses nos indica que se utiliza otro archivo para este paso, mientras que la clave with se utiliza para pasar los valores requeridos. También necesitamos pasar nuestro secreto del repositorio.

  deploy-acr:  needs: vars  uses: ./.github/workflows/deploy_acr.yml  if: github.ref == 'refs/heads/main'  with:    environment: ${{ needs.vars.outputs.environment }}    resource_group: ${{ needs.vars.outputs.resource_group }}    acr_name: ${{ needs.vars.outputs.acr_name }}  secrets:    azure_credentials: ${{ secrets.AZURE_CREDENTIALS }}

En la parte superior del archivo deploy_acr.yml utilizado en este paso, vemos que el script se ejecuta cada vez que se llama en el flujo de trabajo, así como las entradas requeridas que proporcionamos en el archivo workflow.yml.

on:   workflow_call:    inputs:      environment:        required: true        type: string      resource_group:        required: true        type: string      acr_name:        required: true        type: string    secrets:      azure_credentials:        required: true

En la parte inferior de deploy_acr.yml, tenemos un proceso de múltiples pasos que ejecuta tres acciones predefinidas. La primera acción verifica el repositorio, luego iniciamos sesión en Azure utilizando las credenciales del servicio principal que creamos y almacenamos. Finalmente, utilizamos la acción llamada azure/arm-deploy@v1 para implementar el registro de contenedores. Tenga en cuenta que este paso utiliza Bicep, que es un lenguaje popular para configurar e implementar recursos de Azure. En la parte inferior de este artículo, puedes encontrar algunos recursos excelentes para aprender más sobre Bicep.

jobs:  deploy-acr:    name: Implementar ACR    runs-on: ubuntu-latest    environment: ${{ inputs.environment }}    steps:      - uses: actions/checkout@v2      - uses: azure/login@v1        with:          creds: ${{ secrets.azure_credentials }}      - name: Implementar bicep        uses: azure/arm-deploy@v1        with:          resourceGroupName: ${{ inputs.resource_group }}          template: bicep/acr.bicep          parameters:            acrName=${{ inputs.acr_name }}            acrSku=Basic          failOnStdErr: false

Luego, en el paso tres, se crea y se envía una imagen de Docker al registro utilizando el archivo llamado build_push_container.yml, que ejecuta comandos de Azure CLI para recuperar las credenciales para el registro de contenedores, así como comandos de Docker para crear y enviar la imagen de Docker.

En el paso cuatro, se realiza la aprovisionamiento de la instancia de contenedor basada en nuestra imagen de Docker. Este paso se lleva a cabo mediante el archivo llamado deploy_aci.yml, que a su vez utiliza la acción predefinida llamada ‘azure/aci-deploy@v1’.

En el último paso, utilizando el archivo kv_access.yml, concedemos a la instancia de contenedor el permiso para acceder al almacén de claves a través de una ‘identidad administrada’, lo que significa que el contenedor puede recuperar secretos del almacén de claves directamente sin usar una clave de acceso. Para lograr esto, necesitamos actualizar la instancia de contenedor implementada utilizando el comando de Azure CLI az container create y proporcionar los diversos parámetros que utilizamos anteriormente. Además, proporcionamos la siguiente configuración:

— assign-identity — scope ${{ steps.rg_id_step.outputs.rg_id }}

Como nota final, es posible que haya notado las siguientes líneas en workflow.yml:

on:   push:    branches:       - main  workflow_dispatch:

Estas líneas indican cuándo y bajo qué condiciones se debe ejecutar nuestro flujo de trabajo. En nuestro escenario, queremos que el flujo de trabajo se ejecute cuando se realicen cambios en la rama ‘main’. Además, queremos poder ejecutarlo manualmente. Esto se habilita al agregar workflow_dispatch:. En el flujo de trabajo de producción definido en workflow_prod_release.yml, verás que la implementación en producción solo tiene un desencadenador manual. Hay muchas otras formas de configurar cómo se desencadenan las ejecuciones del flujo de trabajo. Por ejemplo, puedes ignorar cambios en archivos o carpetas específicas, de modo que solo los cambios en el código de la aplicación desencadenarán nuevas implementaciones.

Lectura adicional

Si deseas obtener más información sobre las Acciones de GitHub y Bicep, te recomiendo encarecidamente los siguientes recursos de la plataforma MS Learn:

Acciones de GitHub

https://learn.microsoft.com/en-us/training/modules/introduction-to-github-actions/

https://learn.microsoft.com/en-us/training/modules/learn-continuous-integration-github-actions/

https://learn.microsoft.com/en-us/training/modules/github-actions-automate-tasks/

https://learn.microsoft.com/en-us/training/modules/github-actions-ci/

https://learn.microsoft.com/en-us/training/modules/github-actions-cd/

Bicep:

https://learn.microsoft.com/en-us/training/paths/fundamentals-bicep/

https://learn.microsoft.com/en-us/training/paths/bicep-github-actions/

We will continue to update Zepes; if you have any questions or suggestions, please contact us!