Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve as principais atualizações de código do aplicativo para replicar a carga de trabalho do EDW no Azure usando SDKs do Azure para trabalhar com serviços do Azure.
Código de acesso a dados
Implementação do AWS
A carga de trabalho do AWS depende dos serviços do AWS e de seus SDKs do AWS de acesso a dados associados. Já mapeamos os serviços do AWS para serviços equivalentes do Azure, portanto, agora podemos criar o código para acessar os dados da tabela de banco de dados de resultados do produtor e da fila de produtores no Python usando SDKs do Azure.
Implementação no Azure
Para o plano de dados, o corpo da mensagem do produtor (conteúdo) é em JSON e não precisa de nenhuma alteração de esquema para o Azure. O aplicativo do consumidor original salva as mensagens processadas em uma tabela DynamoDB. Com pequenas modificações no código do aplicativo do consumidor, podemos armazenar as mensagens processadas em uma Tabela de Armazenamento do Microsoft Azure.
Código de autenticação
Implementação do AWS
A carga de trabalho da AWS usa uma política de função do IAM que define 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 acesso total a um recurso do Amazon DynamoDB:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "*"
}
]
}
Na carga de trabalho do AWS, você atribui essas políticas usando a CLI do 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
Implementação no Azure
Vamos explorar como executar uma lógica de comunicação de serviço AWS semelhante no ambiente Azure utilizando AKS.
Você aplica duas definições de função RBAC do Azure para controlar o acesso do plano de dados à Fila do Armazenamento do Microsoft Azure e à Tabela de Armazenamento do Microsoft 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 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 do Azure da carga de trabalho do EDW, você atribui as funções a uma identidade gerenciada atribuída pelo usuário vinculada a uma identidade de carga de trabalho em um pod do AKS. Os SDKs do Python do Azure da Fila de Armazenamento do Microsoft Azure e Tabela de Armazenamento do Microsoft Azure usam automaticamente o contexto da entidade de segurança para acessar os dados em ambos os recursos.
Use a função Colaborador de Dados da Fila de Armazenamento para permitir que o destinatário da função leia, escreva ou exclua na Fila de Armazenamento do Microsoft Azure e a função Colaborador de Dados da Tabela de Armazenamento para permitir que o atribuído leia, escreva ou exclua dados em uma Tabela de Armazenamento do Microsoft Azure.
As etapas a seguir mostram como criar uma identidade gerenciada e atribuir as funções Colaborador de Dados da Fila de Armazenamento e Colaborador de Dados da Tabela de Armazenamento usando a CLI do Azure:
Crie uma identidade gerenciada usando o comando
az identity create.managedIdentity=$(az identity create \ --resource-group $resourceGroup \ --name $managedIdentityNameAtribua a função Colaborador de Dados da Fila de Armazenamento à identidade gerenciada usando o comando
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 $resourceIdAtribua a função Colaborador de Dados da Tabela de Armazenamento à identidade gerenciada usando o comando
az role assignment create.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 script deploy.sh em nosso repositório GitHub.
Código do produtor
Implementação do AWS
A carga de trabalho da AWS usa a biblioteca AWS boto3 Python para interagir com filas do Amazon SQS para configurar o acesso à fila de armazenamento. A funcionalidade AssumeRole do IAM do AWS é autenticada no ponto de extremidade do SQS usando a identidade 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 no 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 Microsoft Azure. A classe DefaultAzureCredential do Python tem reconhecimento de identidade de carga de trabalho e usa a identidade gerenciada associada à identidade da carga de trabalho para se autenticar na fila de armazenamento.
O exemplo a seguir mostra como autenticar a uma Fila de Armazenamento do Microsoft Azure usando a 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')
Você pode analisar o código do produtor de fila (aqs-producer.py) em nosso repositório GitHub.
Código do consumidor
Implementação do AWS
O código original da AWS para acesso ao DynamoDB usa a biblioteca AWS boto3 Python para interagir com filas do Amazon SQS. A parte do consumidor da carga de trabalho usa o mesmo código do produtor para se conectar à fila do Amazon SQS para ler mensagens. O consumidor também contém o código do Python para se conectar ao DynamoDB usando a funcionalidade AssumeRole do IAM do AWS para autenticar no ponto de extremidade do DynamoDB usando a identidade IAM associada ao pod do 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 no Azure
A implementação do Azure usa o SDK do Azure para Python para interagir com as Tabelas de Armazenamento do Microsoft Azure.
Agora você precisa do código do produtor para autenticar na Tabela de Armazenamento do Microsoft Azure. Conforme discutido anteriormente, o esquema usado na seção anterior com o DynamoDB é incompatível com a Tabela de Armazenamento do Microsoft Azure. Use um esquema de tabela que seja compatível com o Azure Cosmos DB para armazenar os mesmos dados que a carga de trabalho do AWS no DynamoDB.
O seguinte exemplo 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 Microsoft Azure especifica PartitionKey e RowKey. A PartitionKey é semelhante à ID uniqueidentifer no DynamoDB. Uma PartitionKey é um uniqueidentifier para uma partição em um contêiner lógico na Tabela de Armazenamento do Microsoft Azure. A RowKey é um uniqueidentifier para todas as linhas em uma determinada partição.
Você pode analisar o código completo do produtor e do consumidor em nosso repositório GitHub.
Criar imagens de contêiner e efetuar push para o Registro de Contêiner do Azure
Agora, você pode criar as imagens de contêiner e efetuar push delas para o ACR (Registro de Contêiner do Azure).
No diretório app do repositório clonado, um script de shell chamado docker-command.sh cria as imagens de contêiner e efetua push delas para o ACR. Abra o arquivo .sh e analise o código. O script cria as imagens de contêiner do produtor e do consumidor e efetua push delas para o ACR. Para obter mais informações, consulte Introdução aos registros de contêiner no Azure e Efetuar push e pull de imagens no ACR.
Para criar as imagens de contêiner e efetuar push delas para o ACR, verifique se a variável de ambiente AZURE_CONTAINER_REGISTRY está definida como o nome do registro para o qual você deseja efetuar push das imagens e execute o seguinte comando:
./app/docker-command.sh
Próximas etapas
Colaboradores
A Microsoft atualiza este artigo. Os seguintes colaboradores o escreveram originalmente:
- Ken Kilty | Diretor de TPM
- Russell de Pina | Diretor de TPM
- Jenny Hayes | Desenvolvedora sênior de conteúdo
- Carol Smith | Desenvolvedora sênior de conteúdo
- Erin Schaffer | Desenvolvedora de conteúdo 2