Partager via

Préparer le déploiement de la charge de travail de workflow basé sur les événements (EDW) sur Azure

L’exemple de charge de travail AWS est déployé à l’aide de Bash, CloudFormation et AWS CLI. L’application Python consommatrice est déployée en tant que conteneur. Les sections suivantes décrivent en quoi le workflow Azure est différent. Il existe des modifications des scripts Bash utilisés pour déployer le cluster Azure Kubernetes Service (AKS) et l’infrastructure de prise en charge. En outre, les manifestes de déploiement Kubernetes sont modifiés pour configurer KEDA afin d’utiliser un scaler File d’attente Stockage Azure à la place du scaler Amazon Simple Queue Service (SQS).

Le workflow Azure utilise la fonctionnalité Approvisionnement automatique des nœuds (NAP, Node Autoprovisioning) AKS, qui est basée sur Karpenter. Cette fonctionnalité simplifie considérablement le déploiement et l’utilisation de Karpenter sur AKS en éliminant la nécessité d’utiliser Helm pour déployer Karpenter explicitement. Toutefois, si vous avez besoin de déployer Karpenter directement, vous pouvez le faire à l’aide du fournisseur Karpenter AKS sur GitHub.

Configurer le manifeste de déploiement Kubernetes

AWS utilise un manifeste YAML de déploiement Kubernetes pour déployer la charge de travail sur EKS. Le YAML de déploiement AWS contient des références à SQS et DynamoDB pour les scalers KEDA. Nous devons donc les modifier de façon à spécifier des valeurs équivalentes à KEDA qui seront utilisées par les scalers Azure pour se connecter à l’infrastructure Azure. Pour ce faire, configurez le scaler KEDA File d’attente Stockage Azure.

Les extraits de code suivants montrent des exemples de manifestes YAML pour les implémentations AWS et Azure.

Implémentation 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>

Implémentation d’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

Définir des variables d’environnement

Avant d’exécuter toute étape de déploiement, vous devez définir certaines informations de configuration à l’aide des variables d’environnement suivantes :

  • K8sversion : version de Kubernetes déployée sur le cluster AKS.
  • KARPENTER_VERSION : version de Karpenter déployée sur le cluster AKS.
  • SERVICE_ACCOUNT : nom du compte de service associé à l’identité managée.
  • AQS_TARGET_DEPLOYMENT : nom du déploiement du conteneur d’application consommatrice.
  • AQS_TARGET_NAMESPACE : espace de noms dans lequel l’application consommatrice est déployée.
  • AZURE_QUEUE_NAME : nom du compte Stockage Azure.
  • AZURE_TABLE_NAME : nom de la table Stockage Azure qui stocke les messages traités.
  • LOCAL_NAME : racine simple pour les noms de ressources construits dans les scripts de déploiement.
  • LOCATION : région Azure où se trouve le déploiement.
  • TAGS : toutes les étiquettes éventuellement définies par l’utilisateur, ainsi que leurs valeurs associées.
  • STORAGE_ACCOUNT_SKU : référence SKU du compte Stockage Azure.
  • ACR_SKU : référence SKU Azure Container Registry.
  • AKS_NODE_COUNT : nombre de nœuds.

Vous pouvez consulter le script Bash environmentVariables.sh dans le répertoire deployment de notre dépôt GitHub. Ces variables d’environnement ont des valeurs par défaut. Vous n’avez donc pas besoin de mettre à jour le fichier, sauf si vous souhaitez modifier les valeurs par défaut. Les noms des ressources Azure sont créés dynamiquement dans le script deploy.sh, et sont enregistrés dans le fichier deploy.state. Vous pouvez utiliser le fichier deploy.state afin de créer des variables d’environnement pour les noms de ressources Azure.

Étapes suivantes

Déployer la charge de travail EDW sur Azure

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont rédigé sa version d’origine :

  • Ken Kitty | Responsable de programme technique principal
  • Russell de Pina | Responsable de programme technique principal
  • Jenny Hayes | Développeuse de contenu confirmée
  • Carol Smith | Développeuse de contenu confirmée
  • Erin Schaffer | Développeuse de contenu 2
  • Last updated on