Partilhar via

Atualizar o código do aplicativo para a carga de trabalho orientada a eventos (EDW)

Este artigo descreve as principais atualizações de código de aplicativo para replicar a carga de trabalho EDW no Azure usando SDKs do Azure para trabalhar com serviços do Azure.

Código de acesso aos dados

Implementação da AWS

A carga de trabalho da AWS depende dos serviços da AWS e de seus SDKs da AWS de acesso a dados associados. Já mapeamos os serviços da AWS para serviços equivalentes do Azure, portanto, agora podemos criar o código para acessar dados para a fila do produtor e a tabela do banco de dados de resultados do consumidor em Python usando SDKs do Azure.

Implementação do Azure

Para o plano de dados, o corpo da mensagem do produtor (carga útil) é JSON e não precisa de alterações de esquema para o Azure. O aplicativo consumidor original salva as mensagens processadas em uma tabela do DynamoDB. Com pequenas modificações no código do aplicativo consumidor, podemos armazenar as mensagens processadas em uma Tabela de Armazenamento do Azure.

Código de autenticação

Implementação da AWS

A carga de trabalho da AWS usa uma política de função do IAM que define o acesso total a um recurso do Amazon Simple Queue Service (SQS):

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

A carga de trabalho da AWS usa uma política de função do IAM que define o acesso total a um recurso do Amazon DynamoDB:

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

Na carga de trabalho da AWS, você atribui essas políticas usando a 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

Implementação do Azure

Vamos explorar como executar uma lógica de comunicação de serviço semelhante da AWS no ambiente do Azure usando o AKS.

Você aplica duas definições de função do Azure RBAC para controlar o acesso do plano de dados à Fila de Armazenamento do Azure e à Tabela de Armazenamento do Azure. Essas funções são como as políticas de função do IAM que a AWS usa para controlar o acesso ao SQS e ao DynamoDB. As funções do RBAC do Azure não são agrupadas com o recurso. Em vez disso, você atribui as funções a uma entidade de serviço associada a um determinado recurso.

Na implementação da carga de trabalho EDW no Azure, atribui as funções a uma identidade gerida atribuída pelo utilizador, que está ligada a uma identidade de carga de trabalho num pod AKS. Os SDKs Python do Azure para a Fila de Armazenamento do Azure e a Tabela de Armazenamento do Azure usam automaticamente o contexto da entidade de segurança para acessar dados em ambos os recursos.

Você usa a função Colaborador de Dados da Fila de Armazenamento para permitir que o cessionário da função leia, grave ou exclua na Fila de Armazenamento do Azure e a função Colaborador de Dados da Tabela de Armazenamento para permitir que o cessionário leia, grave ou exclua dados em uma Tabela de Armazenamento do Azure.

As etapas a seguir mostram como criar uma identidade gerenciada e atribuir as funções de Colaborador de Dados da Fila de Armazenamento e Colaborador de Dados da Tabela de Armazenamento usando a CLI do Azure:

  1. Crie uma identidade gerenciada usando o az identity create comando.

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

  2. Atribua a função de Colaborador de Dados da Fila de Armazenamento à identidade gerenciada usando o az role assignment create comando.

    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. Atribua a função de Colaborador de Dados da Tabela de Armazenamento à identidade gerenciada usando o az role assignment create comando.

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

Para ver um exemplo de trabalho, consulte o deploy.sh script em nosso repositório GitHub.

Código do produtor

Implementação da AWS

A carga de trabalho da AWS usa a biblioteca Python do AWS boto3 para interagir com filas do Amazon SQS para configurar o acesso à fila de armazenamento. O recurso do AWS IAM AssumeRole autentica-se para o endpoint do SQS usando a identidade do IAM associada ao pod EKS que hospeda o aplicativo.

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

Implementação do Azure

A implementação do Azure usa o SDK do Azure para Python e a autenticação OAuth sem senha para interagir com os serviços de Fila de Armazenamento do Azure. A DefaultAzureCredential classe Python reconhece a identidade da carga de trabalho e usa a identidade gerenciada associada à identidade da carga de trabalho para autenticar na fila de armazenamento.

O exemplo a seguir mostra como autenticar em uma fila de armazenamento do Azure usando a DefaultAzureCredential classe:

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

Você pode revisar o código para o produtor de fila (aqs-producer.py) em nosso repositório GitHub.

Código do consumidor

Implementação da AWS

O código original da AWS para acesso ao DynamoDB usa a biblioteca Python do AWS boto3 para interagir com filas do Amazon SQS. A parte do consumidor da carga de trabalho computacional usa o mesmo código que o produtor para se conectar à fila do Amazon SQS e ler mensagens. O consumidor também contém código Python para se conectar ao DynamoDB usando o recurso do AWS IAM AssumeRole para autenticar no endpoint do DynamoDB usando a identidade do IAM associada ao pod EKS que hospeda o aplicativo.

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

Implementação do Azure

A implementação do Azure usa o SDK do Azure para Python para interagir com as Tabelas de Armazenamento do Azure.

Agora você precisa do código do produtor para se autenticar na Tabela de Armazenamento do Azure. Conforme discutido anteriormente, o esquema usado na seção anterior com o DynamoDB é incompatível com a Tabela de Armazenamento do Azure. Você usa um esquema de tabela compatível com o Azure Cosmos DB para armazenar os mesmos dados que a carga de trabalho da AWS no DynamoDB.

Este exemplo a seguir mostra o código necessário para o 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
)

Ao contrário do DynamoDB, o código da Tabela de Armazenamento do Azure especifica tanto o PartitionKey quanto o RowKey. O PartitionKey é semelhante ao ID uniqueidentifer no DynamoDB. A PartitionKey é um uniqueidentifier para uma partição em um contêiner lógico na Tabela de Armazenamento do Azure. O RowKey é um uniqueidentifier para todas as linhas em uma determinada partição.

Você pode revisar o código completo do produtor e do consumidor em nosso repositório GitHub.

Criar imagens de contêiner e enviar por push para o Registro de Contêiner do Azure

Agora, você pode criar as imagens de contêiner e enviá-las por push para o Azure Container Registry (ACR).

app No diretório do repositório clonado, um shell script chamado docker-command.sh cria as imagens de contêiner e as envia por push para o ACR. Abra o .sh arquivo e revise o código. O script constrói as imagens de contentor do produtor e do consumidor e envia-os para o Azure Container Registry (ACR). Para obter mais informações, consulte Introdução aos registros de contêiner no Azure e Enviar e receber imagens no ACR.

Para criar as imagens de contêiner e enviá-las por push para o ACR, verifique se a variável AZURE_CONTAINER_REGISTRY de ambiente está definida como o nome do registro para o qual você deseja enviar as imagens por push e, em seguida, execute o seguinte comando:

./app/docker-command.sh

Próximos passos

Preparar para implantar a carga de trabalho EDW no Azure

Contributors

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram-no originalmente:

  • Ken Kilty - Brasil | Principal TPM
  • Russell de Pina - Brasil | Principal TPM
  • Jenny Hayes | Desenvolvedora de Conteúdo Sénior
  • Carol Smith | Desenvolvedora Sénior de Conteúdos
  • Erin Schaffer | Desenvolvedora de Conteúdo 2
  • Last updated on