你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn 。
更新事件驱动工作流 (EDW) 工作负载的应用程序代码
本文内容
数据访问代码
验证码
生成者代码
使用者代码
创建容器映像并推送到 Azure 容器注册表
后续步骤
供稿人
显示另外 3 个
本文概述了使用 Azure SDK 在 Azure 中复制 EDW 工作负载以使用 Azure 服务的关键应用程序代码更新。
AWS 工作负载依赖于 AWS 服务及其关联的数据访问 AWS SDK。 我们已将 AWS 服务映射到等效的 Azure 服务 ,因此现在我们可以使用 Azure SDK 在 Python 中创建代码来访问生产者队列和使用者结果数据库表的数据。
对于数据平面,生成者消息正文(有效负载)是 JSON,它不需要对 Azure 进行任何架构更改。 原始使用者应用将处理的消息保存在 DynamoDB 表中。 通过对使用者应用代码的微小修改,我们可以将处理的消息存储在 Azure 存储表中。
AWS 工作负载使用 IAM 角色策略来定义对 Amazon 简单队列服务 (SQS) 资源的完全访问权限:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "*"
}
]
}
AWS 工作负载使用 IAM 角色策略来定义对 Amazon DynamoDB 资源的完全访问权限:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "*"
}
]
}
在 AWS 工作负载中,可以使用 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
让我们了解如何使用 AKS 在 Azure 环境中执行类似的 AWS 服务配置逻辑。
你应用两个 Azure RBAC 角色定义来控制对 Azure 存储队列和 Azure 存储表的数据平面访问。 这些角色类似于 AWS 用来控制对 SQS 和 DynamoDB 的访问的 IAM 角色策略。 Azure RBAC 角色不与资源捆绑在一起。 你需要将角色分配给与给定资源关联的服务主体。
在 EDW 工作负载的 Azure 实现中,将角色分配给链接到 AKS Pod 中的工作负载标识的用户分配的托管标识。 Azure 存储队列和 Azure 存储表的 Azure Python SDK 会自动使用安全主体的上下文来访问这两个资源中的数据。
你使用 存储队列数据参与者 角色允许角色被分配者针对 Azure 存储队列进行读取、写入或删除,并使用 存储表数据参与者 角色允许被分配者针对 Azure 存储表读取、写入或删除数据。
以下步骤演示如何使用 Azure CLI 创建托管标识并分配存储队列数据参与者 和存储表数据参与者 角色:
使用 az identity create
命令创建托管标识。
managedIdentity=$(az identity create \
--resource-group $resourceGroup \
--name $managedIdentityName
使用 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
使用 az role assignment create
命令将存储表数据参与者 角色分配给托管标识。
az role assignment create \
--assignee-object-id $principalId \
--assignee-principal-type ServicePrincipal
--role "Storage Table Data Contributor" \
--scope $resourceId
若要查看工作示例,请参阅 GitHub 存储库 中的 deploy.sh
脚本。
AWS 工作负载使用 AWS boto3 Python 库与 Amazon SQS 队列交互,以配置存储队列访问。 AWS 标识和访问管理 AssumeRole
功能使用与托管应用程序的 EKS Pod 关联的 IAM 标识向 SQS 终结点进行身份验证。
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 实现使用用于 Python 的 Azure SDK 和无密码 OAuth 身份验证来与 Azure 存储队列服务交互。 DefaultAzureCredential
Python 类可识别工作负载标识,并使用与工作负载标识关联的托管标识向存储队列进行身份验证。
以下示例演示如何使用 DefaultAzureCredential
类向 Azure 存储队列进行身份验证:
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')
可以在 GitHub 存储库 中查看队列生成者 (aqs-producer.py
) 的代码。
DynamoDB 访问的原始 AWS 代码使用 AWS boto3 Python 库与 Amazon SQS 队列进行交互。 工作负载的使用者部分使用与制作者相同的代码连接到 Amazon SQS 队列来读取消息。 使用者还包含使用 AWS 标识和访问管理 AssumeRole
功能连接到 DynamoDB 的 Python 代码,以使用与托管应用程序的 EKS Pod 关联的 IAM 标识向 DynamoDB 终结点进行身份验证。
# 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 实现使用用于 Python 的 Azure SDK 与 Azure 存储表进行交互。
现在,你需要生成者代码向 Azure 存储表进行身份验证。 如前所述,上一部分中 DynamoDB 使用的架构与 Azure 存储表不兼容。 使用与 Azure Cosmos DB 兼容的表架构存储与 DynamoDB 中的 AWS 工作负载相同的数据。
以下示例演示 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
)
与 DynamoDB 不同,Azure 存储表代码同时指定 PartitionKey
和 RowKey
。 PartitionKey
类似于 DynamoDB 中的 ID uniqueidentifer
。 PartitionKey
是 Azure 存储表逻辑容器中 uniqueidentifier
的分区。 RowKey
是给定分区中所有行的 uniqueidentifier
。
可以在 GitHub 存储库 中查看完整的生成者和使用者代码。
现在,可以生成容器映像并将其推送到 Azure 容器注册表 (ACR) 。
在克隆存储库的 app
目录中,名为 docker-command.sh
的 shell 脚本会生成容器映像并将其推送到 ACR。 打开 .sh
文件并查看代码。 该脚本会生成生成者和使用者容器映像,并将其推送到 ACR。 有关详细信息,请参阅 Azure 中的容器注册表简介 以及在 ACR 中推送和拉取映像 。
若要生成容器映像并将其推送到 ACR,请确保环境变量 AZURE_CONTAINER_REGISTRY
设置为要将映像推送到的注册表的名称,然后运行以下命令:
./app/docker-command.sh
Microsoft 会维护本文。 本系列文章为以下参与者的原创作品:
Ken Kilty | 首席 TPM
Russell de Pina | 首席 TPM
Jenny Hayes | 高级内容开发人员
Carol Smith | 高级内容开发人员
Erin Schaffer | 内容开发人员 2