Delen via

Code bijwerken voor de event-driven workflow (EDW) werkbelasting

In dit artikel worden belangrijke updates van toepassingscode beschreven voor het repliceren van de EDW-workload in Azure met behulp van Azure SDK's om te werken met Azure-services.

Code voor gegevenstoegang

AWS-implementatie

De AWS-workload is afhankelijk van AWS-services en de bijbehorende AWS-SDK's voor gegevenstoegang. We hebben AWS-services al toegewezen aan equivalente Azure-services, dus we kunnen nu de code maken voor toegang tot gegevens voor de databasetabel voor producentenwachtrijen en consumentenresultaten in Python met behulp van Azure SDK's.

Azure-implementatie

Voor het gegevensvlak is de hoofdtekst van het producentbericht (payload) JSON en hoeft er geen schemawijzigingen voor Azure te worden aangebracht. De oorspronkelijke consumenten-app slaat de verwerkte berichten op in een DynamoDB-tabel. Met kleine wijzigingen in de code van de consumenten-app kunnen we de verwerkte berichten opslaan in een Azure Storage-tabel.

Verificatiecode

AWS-implementatie

De AWS-workload maakt gebruik van een IAM-rolbeleid dat volledige toegang tot een Amazon Simple Queue Service-resource (SQS) definieert:

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

De AWS-workload maakt gebruik van een IAM-rolbeleid dat volledige toegang tot een Amazon DynamoDB-resource definieert:

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

In de AWS-workload wijst u dit beleid toe met behulp van de AWS CLI:

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-implementatie

Laten we eens kijken hoe u vergelijkbare communicatielogica voor AWS-services uitvoert in de Azure-omgeving met behulp van AKS.

Er worden twee Azure RBAC-roldefinities toegepast om de toegang tot het datavlak van de Azure Storage-wachtrij en de Azure Storage-tabel te controleren. Deze rollen zijn vergelijkbaar met het IAM-rolbeleid dat AWS gebruikt om de toegang tot SQS en DynamoDB te beheren. Azure RBAC-rollen worden niet gebundeld met de resource. In plaats daarvan wijst u de rollen toe aan een service-principal die is gekoppeld aan een bepaalde resource.

In de Azure-implementatie van de EDW-workload wijst u de rollen toe aan een door de gebruiker toegewezen beheerde identiteit die is gekoppeld aan een workloadidentiteit in een AKS-pod. De Azure Python SDK's voor de Azure Storage-wachtrij en Azure Storage-tabel gebruiken automatisch de context van de beveiligingsprincipaal voor toegang tot gegevens in beide resources.

U gebruikt de rol Inzender voor opslagwachtrijgegevens om toe te staan dat de toegewezen rol gegevens kan lezen, schrijven of verwijderen in de Azure Storage-wachtrij en de rol Inzender voor opslagtabellen om de toegewezen gebruiker toestemming te geven gegevens te lezen, schrijven of verwijderen voor een Azure Storage-tabel.

De volgende stappen laten zien hoe u een beheerde identiteit maakt en de rollen Inzender voor opslagwachtrijgegevens en Opslagtabelgegevens inzender toewijst met behulp van de Azure CLI:

  1. Maak een beheerde identiteit met behulp van de az identity create opdracht.

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

  2. Wijs de rol Storage Queue Data Contributor toe aan de beheerde identiteit met de opdracht 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

  3. Wijs de rol Storage Table Data Contributor toe aan de beheerde identiteit met behulp van de az role assignment create opdracht.

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

Raadpleeg het deploy.sh script in onze GitHub-opslagplaats als u een werkend voorbeeld wilt zien.

Producentcode

AWS-implementatie

De AWS-workload maakt gebruik van de PYTHON-bibliotheek AWS boto3 om te communiceren met Amazon SQS-wachtrijen om toegang tot opslagwachtrijen te configureren. De AWS IAM-functie AssumeRole wordt geverifieerd bij het SQS-eindpunt met behulp van de IAM-identiteit die is gekoppeld aan de EKS-pod die als host fungeert voor de toepassing.

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-implementatie

De Azure-implementatie maakt gebruik van de Azure SDK voor Python en OAuth-verificatie zonder wachtwoord om te communiceren met Azure Storage Queue-services. De DefaultAzureCredential Python-klasse ondersteunt de workloadidentiteit en gebruikt de beheerde identiteit die is gekoppeld aan de workloadidentiteit om zich te authentiseren bij de opslagwachtrij.

In het volgende voorbeeld ziet u hoe u zich kunt verifiëren bij een Azure Storage-wachtrij met behulp van de 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')

U kunt de code voor de wachtrijproducent (aqs-producer.py) bekijken in onze GitHub-opslagplaats.

Consumentencode

AWS-implementatie

De oorspronkelijke AWS-code voor DynamoDB-toegang maakt gebruik van de PYTHON-bibliotheek AWS boto3 om te communiceren met Amazon SQS-wachtrijen. Het consumentengedeelte van de workload gebruikt dezelfde code als de producent om verbinding te maken met de Amazon SQS-wachtrij om berichten te lezen. De consument bevat ook Python-code om verbinding te maken met DynamoDB met behulp van de AWS IAM-mogelijkheid AssumeRole om te verifiëren bij het DynamoDB-eindpunt met behulp van de IAM-identiteit die is gekoppeld aan de EKS-pod die als host fungeert voor de toepassing.

# 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-implementatie

De Azure-implementatie maakt gebruik van de Azure SDK voor Python om te communiceren met Azure Storage-tabellen.

Nu hebt u de producentcode nodig om te verifiëren bij Azure Storage Table. Zoals eerder is besproken, is het schema dat in de vorige sectie met DynamoDB wordt gebruikt, niet compatibel met Azure Storage Table. U gebruikt een tabelschema dat compatibel is met Azure Cosmos DB om dezelfde gegevens op te slaan als de AWS-workload in DynamoDB.

In dit volgende voorbeeld ziet u de code die vereist is voor 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
)

In tegenstelling tot DynamoDB specificeert de Azure Storage Table-code zowel PartitionKey als RowKey. De PartitionKey id in DynamoDB is vergelijkbaar met de id uniqueidentifer . Een PartitionKey is een uniqueidentifier voor een partitie in een logische container in de Azure-opslagtafel. Dit RowKey is een uniqueidentifier voor alle rijen in een bepaalde partitie.

U kunt de volledige producent- en consumentencode bekijken in onze GitHub-opslagplaats.

Containerinstallatiekopieën maken en pushen naar Azure Container Registry

U kunt nu de containerinstallatiekopieën bouwen en naar Azure Container Registry (ACR) pushen.

In de app map van de gekloonde opslagplaats bouwt een shellscript met de naam docker-command.sh containerafbeeldingen en pusht deze naar ACR. Open het .sh bestand en controleer de code. Met het script worden de containerafbeeldingen van de producenten- en consumentencontainers gebouwd en naar ACR geüpload. Voor meer informatie, zie Inleiding tot containerregisters in Azure en Push en pull beelden in ACR.

Als u de containerinstallatiekopieën wilt bouwen en naar ACR wilt pushen, moet u ervoor zorgen dat de omgevingsvariabele AZURE_CONTAINER_REGISTRY is ingesteld op de naam van het register waarnaar u de installatiekopieën wilt pushen en voer vervolgens de volgende opdracht uit:

./app/docker-command.sh

Volgende stappen

De EDW-werkbelasting voorbereiden op Azure

Medewerkers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben het oorspronkelijk geschreven:

  • Ken Kilty | Hoofd TPM
  • Russell de Pina | Principal TPM
  • Jenny Hayes | Senior Content Developer
  • Carol Smith | Senior Content Developer
  • Erin Schaffer | Inhoudsontwikkelaar 2
  • Last updated on