Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule opisano kluczowe aktualizacje kodu aplikacji w celu replikowania obciążenia EDW na platformie Azure przy użyciu zestawów SDK platformy Azure do pracy z usługami platformy Azure.
Kod dostępu do danych
Implementacja platformy AWS
Obciążenie platformy AWS opiera się na usługach AWS i skojarzonych z nimi zestawach SDK platformy AWS. Zamapowaliśmy już usługi AWS na równoważne usługi platformy Azure, więc teraz możemy utworzyć kod umożliwiający dostęp do danych dla tabeli bazy danych wyników producenta i producenta w języku Python przy użyciu zestawów SDK platformy Azure.
Implementacja platformy Azure
W przypadku płaszczyzny danych treść komunikatu producenta (ładunek) to JSON i nie wymaga żadnych zmian schematu dla platformy Azure. Oryginalna aplikacja konsumenta zapisuje przetworzone komunikaty w tabeli DynamoDB. Dzięki drobnym modyfikacjom kodu aplikacji konsumenckiej możemy przechowywać przetworzone komunikaty w tabeli usługi Azure Storage.
Kod uwierzytelniania
Implementacja platformy AWS
Obciążenie platformy AWS używa zasad roli zarządzanie dostępem i tożsamościami, które definiują pełny dostęp do zasobu usługi Amazon Simple Queue Service (SQS):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "*"
}
]
}
Obciążenie platformy AWS używa zasad roli zarządzanie dostępem i tożsamościami, które definiują pełny dostęp do zasobu amazon DynamoDB:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "*"
}
]
}
W obciążeniu platformy AWS te zasady są przypisywane przy użyciu interfejsu wiersza polecenia platformy 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
Implementacja platformy Azure
Przyjrzyjmy się, jak wykonać podobną logikę komunikacji usługi AWS w środowisku platformy Azure przy użyciu usługi AKS.
Stosujesz dwie definicje ról RBAC platformy Azure, aby kontrolować dostęp płaszczyzny danych do kolejki usługi Azure Storage i tabeli usługi Azure Storage. Te role są podobne do zasad ról zarządzania dostępem i tożsamościami używanych przez platformę AWS do kontrolowania dostępu do baz danych SQS i DynamoDB. Role RBAC platformy Azure nie są powiązane z zasobem. Zamiast tego przypisujesz role do jednostki usługi skojarzonej z danym zasobem.
W implementacji obciążenia EDW na platformie Azure role są przypisywane do tożsamości zarządzanej przypisanej przez użytkownika połączonej z tożsamością obciążenia w zasobniku usługi AKS. Zestawy SDK języka Python platformy Azure dla kolejki usługi Azure Storage i tabeli usługi Azure Storage automatycznie używają kontekstu podmiotu zabezpieczeń w celu uzyskania dostępu do danych w obu zasobach.
Rola Współautor danych kolejki magazynu umożliwia przypisywanie roli do odczytu, zapisu lub usuwania względem kolejki usługi Azure Storage oraz roli Współautor danych tabeli magazynu, aby zezwolić użytkownikowi na odczytywanie, zapisywanie lub usuwanie danych względem tabeli usługi Azure Storage.
W poniższych krokach pokazano, jak utworzyć tożsamość zarządzaną i przypisać role Współautor danych kolejki magazynu i Współautor danych tabeli magazynu przy użyciu interfejsu wiersza polecenia platformy Azure:
Utwórz tożsamość zarządzaną przy użyciu
az identity createpolecenia .managedIdentity=$(az identity create \ --resource-group $resourceGroup \ --name $managedIdentityNamePrzypisz rolę Współautor danych kolejki magazynu do tożsamości zarządzanej
az role assignment createprzy użyciu polecenia .principalId=$(echo $managedIdentity | jq -r `.principalId`) az role assignment create \ --assignee-object-id $principalId \ --assignee-principal-type ServicePrincipal --role "Storage Queue Data Contributor" \ --scope $resourceIdPrzypisz rolę Współautor danych tabeli magazynu do tożsamości zarządzanej
az role assignment createprzy użyciu polecenia .az role assignment create \ --assignee-object-id $principalId \ --assignee-principal-type ServicePrincipal --role "Storage Table Data Contributor" \ --scope $resourceId
Aby zobaczyć działający przykład, zapoznaj się ze skryptem deploy.sh w naszym repozytorium GitHub.
Kod producenta
Implementacja platformy AWS
Obciążenie platformy AWS używa biblioteki AWS boto3 języka Python do interakcji z kolejkami amazon SQS w celu skonfigurowania dostępu do kolejki magazynu. Funkcja IAM AssumeRole platformy AWS uwierzytelnia się w punkcie końcowym SQS przy użyciu tożsamości IAM skojarzonej z zasobnikiem EKS hostujące aplikację.
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')
Implementacja platformy Azure
Implementacja platformy Azure używa zestawu Azure SDK dla języka Python i uwierzytelniania OAuth bez hasła do interakcji z usługami Kolejki usługi Azure Storage.
DefaultAzureCredential Klasa języka Python uwzględnia tożsamość obciążenia i używa tożsamości zarządzanej skojarzonej z tożsamością obciążenia do uwierzytelniania w kolejce magazynu.
W poniższym przykładzie pokazano, jak uwierzytelniać się w kolejce usługi Azure Storage przy użyciu DefaultAzureCredential klasy :
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')
Możesz przejrzeć kod producenta kolejki (aqs-producer.py) w naszym repozytorium GitHub.
Kod odbiorcy
Implementacja platformy AWS
Oryginalny kod platformy AWS na potrzeby dostępu do bazy danych DynamoDB używa biblioteki języka Python platformy AWS boto3 do interakcji z kolejkami amazon SQS. Część konsumenta obciążenia używa tego samego kodu co producent do nawiązywania połączenia z kolejką Amazon SQS w celu odczytywania komunikatów. Użytkownik zawiera również kod języka Python umożliwiający nawiązanie połączenia z bazą danych DynamoDB przy użyciu funkcji zarządzania dostępem i tożsamościami AssumeRole platformy AWS w celu uwierzytelnienia w punkcie końcowym bazy danych DynamoDB przy użyciu tożsamości IAM skojarzonej z zasobnikiem EKS hostujące aplikację.
# 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>'
}
)
Implementacja platformy Azure
Implementacja platformy Azure używa zestawu Azure SDK dla języka Python do interakcji z tabelami usługi Azure Storage.
Teraz potrzebny jest kod producenta do uwierzytelniania w tabeli usługi Azure Storage. Jak wspomniano wcześniej, schemat używany w poprzedniej sekcji z bazą danych DynamoDB jest niezgodny z tabelą usługi Azure Storage. Schemat tabeli zgodny z usługą Azure Cosmos DB służy do przechowywania tych samych danych co obciążenie platformy AWS w bazie danych DynamoDB.
W poniższym przykładzie pokazano kod wymagany dla platformy 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
)
W przeciwieństwie do bazy danych DynamoDB kod tabeli usługi Azure Storage określa zarówno , jak PartitionKey i RowKey. Wartość jest podobna PartitionKey do identyfikatora uniqueidentifer w bazie danych DynamoDB. A PartitionKey jest elementem uniqueidentifier dla partycji w kontenerze logicznym w tabeli usługi Azure Storage. Element RowKey jest elementem uniqueidentifier dla wszystkich wierszy w danej partycji.
Pełny kod producenta i odbiorcy można przejrzeć w naszym repozytorium GitHub.
Tworzenie obrazów kontenerów i wypychanie do usługi Azure Container Registry
Teraz możesz skompilować obrazy kontenerów i wypchnąć je do usługi Azure Container Registry (ACR).
app W katalogu sklonowanego repozytorium skrypt powłoki o nazwie docker-command.sh tworzy obrazy kontenerów i wypycha je do usługi ACR.
.sh Otwórz plik i przejrzyj kod. Skrypt kompiluje obrazy kontenerów producentów i konsumentów i wypycha je do usługi ACR. Aby uzyskać więcej informacji, zobacz Wprowadzenie do rejestrów kontenerów na platformie Azure i wypychanie i ściąganie obrazów w usłudze ACR.
Aby skompilować obrazy kontenera i wypchnąć je do usługi ACR, upewnij się, że zmienna środowiskowa AZURE_CONTAINER_REGISTRY jest ustawiona na nazwę rejestru, do którego chcesz wypchnąć obrazy, a następnie uruchom następujące polecenie:
./app/docker-command.sh
Następne kroki
Współautorzy
Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie to napisali:
- Ken Kilty | Moduł TPM podmiotu zabezpieczeń
- Russell de Pina | Moduł TPM podmiotu zabezpieczeń
- Jenny Hayes | Starszy deweloper zawartości
- Carol Smith | Starszy deweloper zawartości
- Erin Schaffer | Content Developer 2