Freigeben über

Aktualisieren des Anwendungscodes einer EDW-Workload

In diesem Artikel werden wichtige Aktualisierungen am Anwendungscode beschrieben, die erforderlich sind, um die EDW-Workload in Azure mithilfe von Azure-SDKs zu replizieren und damit in Azure-Diensten zu arbeiten.

Datenzugriffscode

AWS-Implementierung

Die AWS-Workload basiert auf AWS-Diensten und den zugehörigen AWS-SDKs für den Datenzugriff. Sie haben bereits etwas über die Zuordnung von AWS-Diensten zu den entsprechenden Azure-Diensten erfahren, sodass Sie nun den Code für den Zugriff auf Daten in Datenbanktabellen für die Producerwarteschlange und die Consumerergebnisse in Python mithilfe von Azure-SDKs erstellen können.

Azure-Implementierung

Für die Datenebene ist der Nachrichtentext (Payload) des Producers JSON, sodass keine Schemaänderungen für Azure erforderlich sind. Die ursprüngliche Consumer-App speichert die verarbeiteten Nachrichten in einer DynamoDB-Tabelle. Mit geringfügigen Änderungen am Code der Consumer-App können Sie die verarbeiteten Nachrichten in einer Azure Storage-Tabelle speichern.

Authentifizierungscode

AWS-Implementierung

Die AWS-Workload verwendet eine IAM-Rollen-Richtlinie, die Vollzugriff auf eine Amazon SQS-Ressource (Simple Queue Service) definiert:

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

Die AWS-Workload verwendet eine IAM-Rollen-Richtlinie, die Vollzugriff auf eine Amazon DynamoDB-Ressource definiert:

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

In der AWS-Workload weisen Sie diese Richtlinien mithilfe der AWS CLI zu:

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

Azure-Implementierung

Sehen Sie sich nun an, wie Sie ähnliche AWS-Dienstkommunikationslogik innerhalb der Azure-Umgebung mit AKS ausführen.

Sie wenden zwei Azure RBAC-Rollendefinitionen an, um den Zugriff auf Datenebene auf die Azure Storage-Warteschlange und die Azure Storage-Tabelle zu steuern. Diese Rollen ähneln den IAM-Rollen-Richtlinien, die AWS verwendet, um den Zugriff auf SQS und DynamoDB zu steuern. Azure RBAC-Rollen werden nicht mit der Ressource gebündelt. Stattdessen weisen Sie die Rollen einem Dienstprinzipal zu, der einer bestimmten Ressource zugeordnet ist.

In der Azure-Implementierung der EDW-Workload weisen Sie die Rollen einer benutzerseitig zugewiesenen verwalteten Identität zu, die mit einer Workloadidentität in einem AKS-Pod verknüpft ist. Die Python-SDKs von Azure für die Azure Storage-Warteschlange und die Azure Storage-Tabelle verwenden automatisch den Kontext des Sicherheitsprinzipals, um auf Daten in beiden Ressourcen zuzugreifen.

Sie verwenden die Rolle Mitwirkender an Storage-Warteschlangendaten, um Personen mit dieser Rolle das Lesen, Schreiben oder Löschen in der Azure Storage-Warteschlange zu gewähren, und die Rolle Mitwirkender an Speichertabellendaten, damit diese Personen Daten in einer Azure Storage-Tabelle lesen, schreiben oder löschen können.

Die folgenden Schritte zeigen, wie Sie mithilfe der Azure-Befehlszeilenschnittstelle eine verwaltete Identität erstellen und die Rollen Mitwirkender an Storage-Warteschlangendaten und Mitwirkender an Speichertabellendaten zuweisen:

  1. Erstellen Sie mithilfe des az identity create-Befehls eine verwaltete Identität.

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

  2. Weisen Sie der verwalteten Identität mithilfe des Befehls die Rolle az role assignment create zu.

    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

  3. Weisen Sie der verwalteten Identität mithilfe des Befehls die Rolle az role assignment create zu.

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

Ein funktionierendes Beispiel finden Sie im deploy.sh im Skript .

Producercode

AWS-Implementierung

Die AWS-Workload verwendet die AWS-Python-Bibliothek „boto3“ für die Interaktion mit Amazon SQS-Warteschlangen, um den Zugriff auf Storage-Warteschlangen zu konfigurieren. Die AWS IAM-Funktion AssumeRole authentifiziert sich beim SQS-Endpunkt mithilfe der IAM-Identität, die dem EKS-Pod zugeordnet ist, in dem die Anwendung gehostet wird.

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')

Azure-Implementierung

Die Azure-Implementierung verwendet das Azure SDK für Python und die kennwortlose OAuth-Authentifizierung, um mit Azure Storage-Warteschlangendiensten zu interagieren. Die DefaultAzureCredential-Klasse in Python beachtet Workloadidentitäten und verwendet die verwaltete Identität, die der Workloadidentität zugeordnet ist, für die Authentifizierung bei der Storage-Warteschlange.

Das folgende Beispiel zeigt die Authentifizierung bei einer Azure Storage-Warteschlange mithilfe der DefaultAzureCredential-Klasse:

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')

Sie können den Code für den Warteschlangenproducer (aqs-producer.py) in unserem GitHub-Repository überprüfen.

Consumercode

AWS-Implementierung

Der ursprüngliche AWS-Code für den DynamoDB-Zugriff verwendet die AWS-Python-Bibliothek „boto3“ für die Interaktion mit Amazon SQS-Warteschlangen. Der Consumerteil der Workload verwendet denselben Code wie der Producer für das Herstellen einer Verbindung mit der Amazon SQS-Warteschlange zum Lesen von Nachrichten. Der Consumer enthält auch Python-Code, um eine Verbindung mit DynamoDB herzustellen und mithilfe der AWS IAM-Funktion AssumeRole die Authentifizierung am DynamoDB-Endpunkt durchzuführen. Dabei wird die IAM-Identität verwendet, die dem EKS-Pod zugeordnet ist, in dem die Anwendung gehostet wird.

# 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>'
    }
)

Azure-Implementierung

Bei der Azure-Implementierung wird das Azure SDK für Python für die Interaktion mit Azure Storage-Tabellen verwendet.

Nun benötigen Sie den Producercode, um sich bei der Azure Storage-Tabelle zu authentifizieren. Wie bereits erwähnt, ist das Schema, das im vorherigen Abschnitt mit DynamoDB verwendet wird, nicht mit Azure Storage-Tabellen kompatibel. Sie verwenden ein Tabellenschema, das mit Azure Cosmos DB kompatibel ist, um die gleichen Daten wie die AWS-Workload in DynamoDB zu speichern.

Das folgende Beispiel zeigt den für Azure erforderlichen Code:

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
)

Im Gegensatz zu DynamoDB gibt der Code der Azure Storage-Tabelle sowohl PartitionKey als auch RowKey an. PartitionKey ähnelt der ID uniqueidentifer in DynamoDB. PartitionKey ist für eine Partition in einem logischen Container in der Azure Storage-Tabelle ein uniqueidentifier. RowKey ist für alle Zeilen in einer bestimmten Partition ein uniqueidentifier.

Sie können den vollständigen Producer- und Consumercode in unserem GitHub-Repository überprüfen.

Erstellen von Containerimages und Pushen in Azure Container Registry

Jetzt können Sie die Containerimages erstellen und in Azure Container Registry (ACR) pushen.

Im Verzeichnis app des geklonten Repositorys erstellt das Shellskript docker-command.sh die Containerimages und pusht sie an ACR. Öffnen Sie die .sh-Datei, und überprüfen Sie den Code. Das Skript erstellt die Containerimages für Producer und Consumer und pusht sie an ACR. Weitere Informationen finden Sie unter Einführung in Containerregistrierungen in Azure und Pushen und Pullen von Images in ACR.

Um die Containerimages zu erstellen und an ACR zu pushen, muss die Umgebungsvariable AZURE_CONTAINER_REGISTRY auf den Namen der Registrierung festgelegt werden, an die Sie die Images pushen möchten. Führen Sie anschließend den folgenden Befehl aus:

./app/docker-command.sh

Nächste Schritte

Vorbereiten der Bereitstellung der EDW-Workload in Azure

Beitragende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

  • Ken Kilty | Leitender TPM
  • Russell de Pina | Leiter TPM
  • Jennifer Hayes | Senior Content Developer
  • Carol Smith | Senior Content Developer
  • Erin Schaffer | Inhaltsentwickler 2
  • Last updated on