Mettre à jour le code d’application de la charge de travail de workflow basé sur les événements (EDW)

Cet article décrit les principales mises à jour de code d’application nécessaires pour répliquer la charge de travail EDW dans Azure à l’aide de kits de développement logiciel (SDK) Azure pour fonctionner avec les services Azure.

Code d’accès aux données

Implémentation AWS

La charge de travail AWS s’appuie sur les services AWS et leurs kits SDK AWS d’accès aux données associés. Nous avons déjà mappé les services AWS aux services Azure équivalents. Nous pouvons donc maintenant créer le code afin d’accéder aux données pour la file d’attente du producteur et la table de base de données de résultats du consommateur dans Python à l’aide de kits SDK Azure.

Implémentation d’Azure

Pour le plan de données, le corps du message du producteur (charge utile) est au format JSON, et il n’a pas besoin de modifications de schéma pour Azure. L’application consommatrice d’origine enregistre les messages traités dans une table DynamoDB. Avec des modifications mineures apportées au code de l’application consommatrice, nous pouvons stocker les messages traités dans une table Stockage Azure.

Code d’authentification

Implémentation AWS

La charge de travail AWS utilise une stratégie de rôle IAM qui définit l’accès complet à une ressource Amazon Simple Queue Service (SQS) :

{
  "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sqs:*",
            "Resource": "*"
        }
    ]
}

La charge de travail AWS utilise une stratégie de rôle IAM qui définit l’accès complet à une ressource Amazon DynamoDB :

{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Effect": "Allow",
        "Action": "dynamodb:*",
        "Resource": "*"
    }
  ]
}

Dans la charge de travail AWS, vous affectez ces stratégies à l’aide de l’interface de ligne de commande AWS :

aws iam create-policy --policy-name sqs-sample-policy --policy-document <filepath/filename>.json
aws iam create-policy --policy-name dynamodb-sample-policy --policy-document <filepath/filename>.json
aws iam create-role --role-name keda-sample-iam-role  --assume-role-policy-document <filepath/filename>.json

aws iam attach-role-policy --role-name keda-sample-iam-role --policy-arn=arn:aws:iam::${<AWSAccountID>}:policy/sqs-sample-policy
aws iam attach-role-policy --role-name keda-sample-iam-role --policy-arn=arn:aws:iam::${<AWSAccountID>}:policy/dynamodb-sample-policy

# Set up trust relationship Kubernetes federated identity credential and map IAM role via kubectl annotate serviceaccount

Implémentation d’Azure

Examinons comment effectuer une logique de communication de service AWS similaire dans l’environnement Azure à l’aide d’AKS.

Vous appliquez deux définitions de rôle RBAC Azure pour contrôler l’accès du plan de données à la file d’attente Stockage Azure et à la table Stockage Azure. Ces rôles sont similaires aux stratégies de rôle IAM que AWS utilise pour contrôler l’accès à SQS et DynamoDB. Les rôles RBAC Azure ne sont pas regroupés avec la ressource. Au lieu de cela, vous affectez les rôles à un principal de service associé à une ressource donnée.

Dans l’implémentation Azure de la charge de travail EDW, vous attribuez les rôles à une identité managée affectée par l’utilisateur liée à une identité de charge de travail dans un pod AKS. Les kits SDK Azure Python pour les services Stockage File d’attente Azure et Stockage Table Azure utilisent automatiquement le contexte du principal de sécurité pour accéder aux données dans les deux ressources.

Vous utilisez le rôle Contributeur aux données en file d’attente du stockage pour permettre au bénéficiaire de lire, d’écrire ou de supprimer des données dans la file d’attente Stockage Azure, et le rôle Contributeur de données de table de stockage pour permettre au bénéficiaire de lire, d’écrire ou de supprimer des données dans une table Stockage Azure.

Les étapes suivantes montrent comment créer une identité managée et attribuer les rôles Contributeur aux données en file d’attente du stockage et Contributeur de données de table de stockage à l’aide d’Azure CLI :

Créez une identité managée à l’aide de la commande az identity create.

managedIdentity=$(az identity create \
    --resource-group $resourceGroup \
    --name $managedIdentityName

Attribuez le rôle Contributeur aux données en file d’attente du stockage à l’identité managée à l’aide de la commande az role assignment create.

principalId=$(echo $managedIdentity | jq -r `.principalId`)

az role assignment create \
    --assignee-object-id $principalId \
    --assignee-principal-type ServicePrincipal
    --role "Storage Queue Data Contributor" \
    --scope $resourceId

Attribuez le rôle Contributeur de données de table de stockage à l’identité managée à l’aide de la commande az role assignment create.

az role assignment create \
    --assignee-object-id $principalId \
    --assignee-principal-type ServicePrincipal
    --role "Storage Table Data Contributor" \
    --scope $resourceId

Pour voir un exemple opérationnel, consultez le script deploy.sh dans notre dépôt GitHub.

Code du producteur

Implémentation AWS

La charge de travail AWS utilise la bibliothèque Python AWS boto3 pour interagir avec les files d’attente Amazon SQS afin de configurer l’accès à la file d’attente de stockage. La fonctionnalité AWS IAM AssumeRole s’authentifie auprès du point de terminaison SQS à l’aide de l’identité IAM associée au pod EKS hébergeant l’application.

import boto3
# other imports removed for brevity
sqs_queue_url = "https://<region>.amazonaws.com/<queueid>/source-queue.fifo"
sqs_queue_client = boto3.client("sqs", region_name="<region>")    
response = sqs_client.send_message(
    QueueUrl = sqs_queue_url,
    MessageBody = 'messageBody1',
    MessageGroupId='messageGroup1')

Implémentation d’Azure

L’implémentation Azure utilise le kit SDK Azure pour Python et l’authentification OAuth sans mot de passe pour interagir avec les services de file d’attente Stockage Azure. La classe Python DefaultAzureCredential est consciente de l’identité de charge de travail, et utilise l’identité managée associée à l’identité de charge de travail pour procéder à l’authentification auprès de la file d’attente de stockage.

L’exemple suivant montre comment s’authentifier auprès d’une file d’attente Stockage Azure à l’aide de la classe DefaultAzureCredential :

from azure.identity import DefaultAzureCredential
from azure.storage.queue import QueueClient
# other imports removed for brevity

# authenticate to the storage queue.
account_url = "https://<storageaccountname>.queue.core.windows.net"
default_credential = DefaultAzureCredential()
aqs_queue_client = QueueClient(account_url, queue_name=queue_name ,credential=default_credential)

aqs_queue_client.create_queue()
aqs_queue_client.send_message('messageBody1')

Vous pouvez consulter le code du producteur de file d’attente (aqs-producer.py) dans notre dépôt GitHub.

Code du consommateur

Implémentation AWS

Le code AWS d’origine pour l’accès DynamoDB utilise la bibliothèque Python AWS boto3 pour interagir avec les files d’attente Amazon SQS. La partie consommateur de la charge de travail utilise le même code que le producteur pour la connexion à la file d’attente Amazon SQS pour lire les messages. Le consommateur contient également du code Python pour se connecter à DynamoDB à l’aide de la fonctionnalité AWS IAM AssumeRole afin de s’authentifier auprès du point de terminaison DynamoDB à l’aide de l’identité IAM associée au pod EKS hébergeant l’application.

# presumes policy deployment ahead of time such as: aws iam create-policy --policy-name <policy_name> --policy-document <policy_document.json>
dynamodb = boto3.resource('dynamodb', region_name='<region>')
table = dynamodb.Table('<dynamodb_table_name>')
table.put_item(
    Item = {
      'id':'<guid>',
      'data':jsonMessage["<message_data>"],
      'srcStamp':jsonMessage["<source_timestamp_from_message>"],
      'destStamp':'<current_timestamp_now>',
      'messageProcessingTime':'<duration>'
    }
)

Implémentation d’Azure

L’implémentation Azure utilise le kit SDK Azure pour Python afin d’interagir avec les tables Stockage Azure.

Vous devez maintenant faire en sorte que le code du producteur s’authentifie auprès du service Stockage Table Azure. Comme indiqué plus haut, le schéma utilisé dans la section précédente avec DynamoDB n’est pas compatible avec Stockage Table Azure. Vous utilisez un schéma de table compatible avec Azure Cosmos DB pour stocker les mêmes données que la charge de travail AWS dans DynamoDB.

Cet exemple montre le code requis pour Azure :

from azure.storage.queue import QueueClient
from azure.data.tables import (TableServiceClient)

    creds = DefaultAzureCredential()
    table = TableServiceClient(
        endpoint=f"https://{storage_account_name}.table.core.windows.net/",  
        credential=creds).get_table_client(table_name=azure_table)

entity={
    'PartitionKey': _id,
    'RowKey': str(messageProcessingTime.total_seconds()),
    'data': jsonMessage['msg'],
    'srcStamp': jsonMessage['srcStamp'],
    'dateStamp': current_dateTime
}
        
response = table.insert_entity(
    table_name=azure_table,
    entity=entity,
    timeout=60
)

Contrairement à DynamoDB, le code Stockage Table Azure spécifie à la fois PartitionKey et RowKey. L’ID PartitionKey est similaire à l’ID uniqueidentifer dans DynamoDB. PartitionKey est un uniqueidentifier pour une partition dans un conteneur logique dans Stockage Table Azure. RowKey est un uniqueidentifier pour toutes les lignes d’une partition donnée.

Vous pouvez consulter le code complet du producteur et du consommateur dans notre dépôt GitHub.

Créer des images conteneur et les envoyer (push) à Azure Container Registry

À présent, vous pouvez générer les images conteneur et les envoyer à Azure Container Registry (ACR).

Dans le répertoire app du référentiel cloné, un script d’interpréteur de commandes nommé docker-command.sh génère les images conteneur et les envoie à ACR. Ouvrez le fichier .sh et passez en revue le code. Le script génère les images conteneur du producteur et du consommateur, et les envoie à ACR. Pour plus d’informations, consultez Présentation des registres de conteneurs dans Azure et Envoyer et extraire des images dans ACR.

Pour générer les images conteneur et les envoyer à ACR, vérifiez que la variable d’environnement AZURE_CONTAINER_REGISTRY est définie sur le nom du registre vers lequel vous souhaitez envoyer les images, puis exécutez la commande suivante :

./app/docker-command.sh

Étapes suivantes

Préparer le déploiement de 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

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2024-08-02

Partager via

Mettre à jour le code d’application de la charge de travail de workflow basé sur les événements (EDW)

Code d’accès aux données

Implémentation AWS

Implémentation d’Azure

Code d’authentification

Implémentation AWS

Implémentation d’Azure

Code du producteur

Implémentation AWS

Implémentation d’Azure

Code du consommateur

Implémentation AWS

Implémentation d’Azure

Créer des images conteneur et les envoyer (push) à Azure Container Registry

Étapes suivantes

Contributeurs

Commentaires

Ressources supplémentaires