Leer en inglés

Compartir a través de


Preparación para implementar la carga de trabajo de flujo de trabajo controlada por eventos (EDW) en Azure

El ejemplo de carga de trabajo de AWS se implementa mediante Bash, CloudFormation y la CLI de AWS. La aplicación de Python del consumidor se implementa como un contenedor. En las secciones siguientes se describe cómo es diferente el flujo de trabajo de Azure. Hay cambios en los scripts de Bash que se usan para implementar el clúster de Azure Kubernetes Service (AKS) y la infraestructura auxiliar. Además, los manifiestos de implementación de Kubernetes se modifican para configurar KEDA para que usen un escalador de colas de Azure Storage en lugar del escalador de Amazon Simple Queue Service (SQS).

El flujo de trabajo de Azure usa la característica de Aprovisionamiento automático de nodos de AKS (NAP), que se basa en Karpenter. Esta característica simplifica considerablemente la implementación y el uso de Karpenter en AKS eliminando la necesidad de usar Helm para implementar Karpenter explícitamente. Sin embargo, si tiene que implementar Karpenter directamente, puede hacerlo mediante el proveedor de AKS Karpenter en GitHub.

Configuración del manifiesto de implementación de Kubernetes

AWS usa un manifiesto YAML de implementación de Kubernetes para implementar la carga de trabajo en EKS. El YAML de implementación de AWS tiene referencias a SQS y DynamoDB para escaladores KEDA, por lo que es necesario cambiarlos para especificar valores equivalentes de KEDA para que los escaladores de Azure se usen para conectarse a la infraestructura de Azure. Para ello, configure el escalador Azure Storage Queue KEDA.

Los fragmentos de código siguientes muestran manifiestos YAML de ejemplo para las implementaciones de AWS y Azure.

Implementación de AWS

    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: <sqs app name>
        image: <name of Python app container>
        imagePullPolicy: Always
        env:
        - name: SQS_QUEUE_URL
          value: https://<Url To SQS>/<region>/<QueueName>.fifo
        - name: DYNAMODB_TABLE
          value: <table name>
        - name: AWS_REGION
          value: <region>

Implementación en Azure

    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: keda-queue-reader
        image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
        imagePullPolicy: Always
        env:
        - name: AZURE_QUEUE_NAME
          value: $AZURE_QUEUE_NAME
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: $AZURE_STORAGE_ACCOUNT_NAME
        - name: AZURE_TABLE_NAME
          value: $AZURE_TABLE_NAME

Establecimiento de variables de entorno

Antes de ejecutar cualquiera de los pasos de implementación, debe establecer información de configuración mediante las siguientes variables de entorno:

  • K8sversion: la versión de Kubernetes implementada en el clúster de AKS.
  • KARPENTER_VERSION: la versión de Karpenter implementada en el clúster de AKS.
  • SERVICE_ACCOUNT: el nombre de la cuenta de servicio asociada a la identidad administrada.
  • AQS_TARGET_DEPLOYMENT: el nombre de la implementación del contenedor de aplicaciones de consumidor.
  • AQS_TARGET_NAMESPACE: espacio de nombres en el que se implementa la aplicación de consumidor.
  • AZURE_QUEUE_NAME: nombre de la cola de Azure Storage.
  • AZURE_TABLE_NAME: nombre de la tabla de Azure Storage que almacena los mensajes procesados.
  • LOCAL_NAME: una raíz simple para los nombres de recursos construidos en los scripts de implementación.
  • LOCATION: región de Azure donde se encuentra la implementación.
  • TAGS: cualquier etiqueta definida por el usuario junto con sus valores asociados.
  • STORAGE_ACCOUNT_SKU: El SKU de la cuenta Azure Storage.
  • ACR_SKU: la SKU de Azure Container Registry.
  • AKS_NODE_COUNT: El número de nodos.

Puede revisar el script de environmentVariables.sh Bash en el deployment directorio de nuestro repositoriode GitHub. Estas variables de entorno tienen los valores predeterminados establecidos, por lo que no es necesario actualizar el archivo a menos que desee cambiar los valores predeterminados. Los nombres de los recursos de Azure se crean dinámicamente en el deploy.sh script y se guardan en el deploy.state archivo. Puede usar el deploy.state archivo para crear variables de entorno para los nombres de recursos de Azure.

Pasos siguientes

Colaboradores

Microsoft se encarga del mantenimiento de este artículo. Los siguientes colaboradores lo escribieron originalmente:

  • Ken Kilty | TPM de entidad de seguridad
  • Russell de Pina | TPM de entidad de seguridad
  • Jenny Hayes | Desarrollador de contenido sénior
  • Carol Smith | Desarrollador de contenido sénior
  • Erin Schaffer | Desarrollador de contenido 2