Freigeben über

Vorbereiten der Bereitstellung der EDW-Workload in Azure

Das AWS-Workloadbeispiel wird mithilfe von Bash, CloudFormation und AWS CLI bereitgestellt. Die Python-Consumer-App wird als Container bereitgestellt. In den folgenden Abschnitten wird beschrieben, wie sich der Azure-Workflow unterscheidet. Es gibt Änderungen an den Bash-Skripts, die zum Bereitstellen des AKS-Clusters (Azure Kubernetes Service) und der unterstützenden Infrastruktur verwendet werden. Darüber hinaus werden die Kubernetes-Bereitstellungsmanifeste geändert, um KEDA für die Verwendung einer Azure Storage-Warteschlangenskalierung anstelle der Amazon SQS-Skalierung (Simple Queue Service) zu konfigurieren.

Der Azure-Workflow verwendet das Feature AKS NAP (Node Autoprovisioning), das auf Karpenter basiert. Dieses Feature vereinfacht die Bereitstellung und Verwendung von Karpenter in AKS erheblich, da es nicht erforderlich ist, zum expliziten Bereitstellen von Karpenter Helm zu verwenden. Wenn Sie jedoch Karpenter direkt bereitstellen müssen, können Sie dies mit dem AKS-Karpenter-Anbieter auf GitHub tun.

Konfigurieren des Kubernetes-Bereitstellungsmanifests

AWS verwendet ein Kubernetes-YAML-Bereitstellungsmanifest, um die Workload in EKS bereitzustellen. Der YAML-Code für die AWS-Bereitstellung enthält Verweise auf SQS und DynamoDB für KEDA-Skalierungsanbieter. Daher müssen Sie ihn ändern, um KEDA-äquivalente Werte für die Azure-Skalierungsanbieter anzugeben, die für die Verbindung mit der Azure-Infrastruktur verwendet werden sollen. Konfigurieren Sie dazu den KEDA-Skalierungsanbieter der Azure Storage-Warteschlange.

Die folgenden Codeschnipsel zeigen YAML-Beispielmanifeste für AWS- und Azure-Implementierungen.

AWS-Implementierung

    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: <sqs app name>
        image: <name of Python app container>
        imagePullPolicy: Always
        env:
        - name: SQS_QUEUE_URL
          value: https://<Url To SQS>/<region>/<QueueName>.fifo
        - name: DYNAMODB_TABLE
          value: <table name>
        - name: AWS_REGION
          value: <region>

Azure-Implementierung

    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: keda-queue-reader
        image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
        imagePullPolicy: Always
        env:
        - name: AZURE_QUEUE_NAME
          value: $AZURE_QUEUE_NAME
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: $AZURE_STORAGE_ACCOUNT_NAME
        - name: AZURE_TABLE_NAME
          value: $AZURE_TABLE_NAME

Festlegen von Umgebungsvariablen

Bevor Sie einen der Bereitstellungsschritte ausführen, müssen Sie einige Konfigurationsinformationen mithilfe der folgenden Umgebungsvariablen festlegen:

  • K8sversion: die im AKS-Cluster bereitgestellte Version von Kubernetes
  • KARPENTER_VERSION: die Im AKS-Cluster bereitgestellte Version von Karpenter
  • SERVICE_ACCOUNT: der Name des Dienstkontos, das der verwalteten Identität zugeordnet ist
  • AQS_TARGET_DEPLOYMENT: der Name der Bereitstellung von Consumer-App-Containern
  • AQS_TARGET_NAMESPACE: der Namespace, in dem die Consumer-App bereitgestellt wird
  • AZURE_QUEUE_NAME: der Name der Azure Storage-Warteschlange
  • AZURE_TABLE_NAME: der Name der Azure Storage-Tabelle, in der die verarbeiteten Nachrichten gespeichert werden
  • LOCAL_NAME: ein einfacher Stamm für Ressourcennamen, die in den Bereitstellungsskripts erstellt werden
  • LOCATION: die Azure-Region für die Bereitstellung
  • TAGS: alle benutzerdefinierten Tags zusammen mit den zugehörigen Werten
  • STORAGE_ACCOUNT_SKU: die SKU des Azure Storage-Kontos
  • ACR_SKU: die Azure Container Registry-SKU
  • AKS_NODE_COUNT: die Anzahl der Knoten

Sie können das Bash-Skript environmentVariables.sh im Verzeichnis deployment unseres GitHub-Repositorys überprüfen. Für diese Umgebungsvariablen wurden Standardwerte festgelegt, sodass Sie die Datei nur aktualisieren müssen, wenn Sie die Standardwerte ändern möchten. Die Namen der Azure-Ressourcen werden dynamisch im Skript deploy.sh erstellt und in der Datei deploy.state gespeichert. Sie können die Datei deploy.state verwenden, um Umgebungsvariablen für Azure-Ressourcennamen zu erstellen.

Nächste Schritte

Bereitstellen der EDW-Workload in Azure

Beitragende

Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

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