Azure Container Instance (ACI) — Dynamics installation

Support DQE
Support DQE
  • Aktualisiert

1. Installation

Dieser Abschnitt beschreibt die Bereitstellung des DQE Unify Server auf Azure Container Instances (ACI). Der Anwendungsstack — Redis, RabbitMQ, Nginx, Unify Server und Queue Worker — läuft als eine einzige Azure Container Group. Alle Container teilen denselben Netzwerk-Namespace und kommunizieren über localhost.

1.1 Voraussetzungen

1.1.1 Ressourcenanforderungen

Container CPU (vCores) Arbeitsspeicher
redis 0.5 0.5 GB
rabbitmq 0.5 1 GB
nginx 0.5 0.5 GB
unify-server 0.5 1 GB
queue-worker 1.0 5 GB
Gesamt 3.0 8 GB

Hinweis: Die Schätzungen basieren auf 1 Million Datensätzen. Je nach Datenvolumen müssen Sie die Speicherzuweisung des queue-worker-Containers möglicherweise erhöhen.

1.1.2 Software-Anforderungen

Software Version / Hinweise
Azure CLI Neueste stabile Version — Befehl az im Terminal verfügbar
Azure-Abonnement Aktives Abonnement mit Berechtigungen zum Erstellen von Container Instances, Virtual Networks und Storage Accounts
Internetzugang Erforderlich, um Images aus der DQE Container Registry abzurufen

1.2 Anmeldung bei der DQE Container Registry

Alle Images (DQE Unify, Redis, RabbitMQ, Nginx) werden in einer privaten Azure Container Registry gehostet. Verwenden Sie die von DQE Software bereitgestellten Anmeldedaten, um sich von Ihrem lokalen Terminal aus anzumelden:

az login
docker login <registry-url> --username <Username provided by DQE> --password <Password provided by DQE>

Eine erfolgreiche Anmeldung zeigt: Login Succeeded.

Hinweis: Die Registry-Anmeldedaten werden auch in der Container-Group-YAML-Datei (Abschnitt 1.7) benötigt, damit ACI die Images zum Zeitpunkt der Bereitstellung abrufen kann.

1.3 Azure Storage konfigurieren

Azure Container Instances unterstützen keine lokalen Bind Mounts. Persistente Daten für Redis und RabbitMQ müssen in Azure File Shares gespeichert werden. Die Nginx-Konfigurationsdatei wird ebenfalls in eine File Share hochgeladen, damit der Container sie zur Laufzeit einbinden kann.

  1. Schritt 1 — Erstellen Sie ein Storage Account:

    az storage account create \
  --name dqeunifystorage \
  --resource-group <resource-group> \
  --location <location> \
  --sku Standard_LRS

  2. Schritt 2 — Rufen Sie den Storage-Account-Schlüssel ab:

    az storage account keys list \
  --account-name dqeunifystorage \
  --resource-group <resource-group> \
  --query "[0].value" -o tsv

  3. Schritt 3 — Erstellen Sie die File Shares:

    az storage share create --name redisvol   --account-name dqeunifystorage
az storage share create --name rabbitvol  --account-name dqeunifystorage
az storage share create --name nginxconf  --account-name dqeunifystorage

1.4 Nginx konfigurieren

Nginx fungiert als Reverse Proxy und leitet eingehende HTTP-/HTTPS-Anfragen an den Unify Server weiter. In ACI teilen sich alle Container denselben Netzwerk-Namespace, daher lautet das Proxy-Ziel http://localhost:8000 und nicht ein Dienstname.

Erstellen Sie die Datei default.conf lokal und laden Sie sie anschließend in die Azure File Share hoch.

Die Datei default.conf muss folgenden Inhalt enthalten:

server {
    listen 80;

    location / {
        proxy_pass         http://localhost:8000;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_read_timeout 300s;
    }
}

Hochladen in die Azure File Share:

az storage file upload \
  --account-name dqeunifystorage \
  --share-name nginxconf \
  --source ./default.conf \
  --path default.conf

HTTPS

Fügen Sie einen zweiten Server-Block hinzu und laden Sie Ihr SSL-Zertifikat und den privaten Schlüssel in die nginxconf-File-Share hoch. Aktualisieren Sie die Container-Group-YAML, um Port 443 freizugeben.

server {
    listen 443 ssl;

    ssl_certificate      /etc/nginx/ssl/cert.crt;
    ssl_certificate_key  /etc/nginx/ssl/cert.key;

    location / {
        proxy_pass         http://localhost:8000;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        proxy_read_timeout 300s;
    }
}

Hinweis: Laden Sie die Zertifikatsdateien in die nginxconf-File-Share unter einem Unterverzeichnis ssl/ hoch und binden Sie die File Share in der Nginx-Container-Konfiguration unter /etc/nginx/ssl ein.

1.5 Log Analytics Workspace konfigurieren

Ein Log Analytics Workspace zentralisiert Container-Logs und ermöglicht die Überwachung über Azure Monitor. Die Workspace-ID und der Schlüssel werden in der Container-Group-YAML referenziert (Abschnitt 1.7).

  1. Schritt 1 — Erstellen Sie einen Log Analytics Workspace:

    az monitor log-analytics workspace create \
  --resource-group <resource-group> \
  --workspace-name dqe-unify-logs \
  --location <location>

  2. Schritt 2 — Rufen Sie die Workspace-ID ab:

    az monitor log-analytics workspace show \
  --resource-group <resource-group> \
  --workspace-name dqe-unify-logs \
  --query customerId -o tsv

  3. Schritt 3 — Rufen Sie den Workspace Primary Key ab:

    az monitor log-analytics workspace get-shared-keys \
  --resource-group <resource-group> \
  --workspace-name dqe-unify-logs \
  --query primarySharedKey -o tsv

Hinweis: Halten Sie die Workspace-ID und den Primary Key bereit — sie werden als Platzhalter <workspace-id> und <workspace-key> in der Container-Group-YAML verwendet (Abschnitt 1.7).

1.6 Virtual Network (VNET) konfigurieren

Die Container Group muss in ein Azure Virtual Network bereitgestellt werden, damit sie eine private IP-Adresse erhält, die innerhalb Ihrer Azure-Umgebung erreichbar ist (Dynamics 365-Backend, internes DNS, Application Gateway). Das Subnetz muss explizit für Microsoft.ContainerInstance/containerGroups delegiert werden — dies ist eine zwingende Voraussetzung für die ACI-VNET-Integration.

  1. Schritt 1 — Erstellen Sie ein Virtual Network:

    az network vnet create \
  --name dqe-unify-vnet \
  --resource-group <resource-group> \
  --location <location> \
  --address-prefix 10.0.0.0/16

  2. Schritt 2 — Erstellen Sie ein für ACI delegiertes Subnetz:

    az network vnet subnet create \
  --name dqe-unify-subnet \
  --vnet-name dqe-unify-vnet \
  --resource-group <resource-group> \
  --address-prefix 10.0.0.0/24 \
  --delegations Microsoft.ContainerInstance/containerGroups

  3. Schritt 3 — Rufen Sie die vollständige Subnetz-Ressourcen-ID ab:

    az network vnet subnet show \
  --name dqe-unify-subnet \
  --vnet-name dqe-unify-vnet \
  --resource-group <resource-group> \
  --query id -o tsv

    Der zurückgegebene Wert hat die Form:

    /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/dqe-unify-vnet/subnets/dqe-unify-subnet

    Halten Sie diesen Wert bereit — er wird als Platzhalter subnetIds[0].id in der Container-Group-YAML verwendet (Abschnitt 1.7).

Hinweis: Ein für Microsoft.ContainerInstance/containerGroups delegiertes Subnetz kann keine anderen Ressourcentypen hosten. Verwenden Sie ein dediziertes Subnetz — ein /24-Block (256 Adressen) wird empfohlen. ACI verbraucht eine IP-Adresse pro Container-Group-Bereitstellung.

Hinweis: Wenn der Kunde bereits über ein bestehendes VNET verfügt, überspringen Sie Schritt 1 und 2 und erstellen Sie das dedizierte Subnetz innerhalb des bestehenden VNET. Rufen Sie die Subnetz-ID mit Schritt 3 ab.

1.7 Container-Group-Konfigurationsdatei

Erstellen Sie die Datei container-group.yaml mit dem folgenden Inhalt. Ersetzen Sie alle Platzhalter in spitzen Klammern vor der Bereitstellung.

Platzhalter Beschreibung
<resource-group> Name der Azure Resource Group
<location> Azure-Region, zum Beispiel westeurope
<registry-url> URL der DQE Container Registry
<Username provided by DQE> Von DQE Software bereitgestellter Registry-Benutzername
<Password provided by DQE> Von DQE Software bereitgestelltes Registry-Passwort
<storage-account-key> In Abschnitt 1.3 Schritt 2 abgerufener Schlüssel
<workspace-id> Log Analytics Workspace-ID (abgerufen in Abschnitt 1.5 Schritt 2)
<workspace-key> Log Analytics Workspace Primary Key (abgerufen in Abschnitt 1.5 Schritt 3)
<subscription-id> / <vnet-name> / <subnet-name> Subnetz-Ressourcen-ID, abgerufen in Abschnitt 1.6 Schritt 3 
name: dqe-unify-aci
apiVersion: '2021-10-01'
location: <azure-region>

tags:
  docker-compose-application: docker-compose-application

properties:
  containers:
    - name: redis
      properties:
        image: <registry-url>/dqe-unify-redis:latest
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.5
        volumeMounts:
          - name: redisvol
            mountPath: /data

    - name: rabbitmq
      properties:
        image: <registry-url>/dqe-unify-rabbitmq:latest
        ports:
          - protocol: TCP
            port: 5672
        resources:
          requests:
            memoryInGB: 1
            cpu: 1
        volumeMounts:
          - name: rabbitvol
            mountPath: /bitnami
            readOnly: false

    - name: nginx
      properties:
        image: <registry-url>/dqe-unify-nginx:latest
        ports:
          - protocol: TCP
            port: 80
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.25
        volumeMounts:
          - name: nginxconf
            mountPath: /etc/nginx/conf.d

    - name: unify-server
      properties:
        image: <registry-url>/unify-server-web-ms-dynamics:<version>
        command: ["python", "-u", "app.pyc"]
        ports:
          - protocol: TCP
            port: 8000
        environmentVariables:
          - name: REDIS_URL
            value: redis://127.0.0.1:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@127.0.0.1:5672/
          - name: PORT
            value: 8000
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.25

    - name: queue-worker
      properties:
        image: <registry-url>/unify-server-web-ms-dynamics:<version>
        command: ["python", "-u", "queue_worker.pyc"]
        environmentVariables:
          - name: REDIS_URL
            value: redis://127.0.0.1:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@127.0.0.1:5672/
        resources:
          requests:
            memoryInGB: 5
            cpu: 1

  imageRegistryCredentials:
    - server: <registry-url>
      username: <registry-username>
      password: <registry-password>

  diagnostics:
    logAnalytics:
      workspaceId: <log-analytics-workspace-id>
      workspaceKey: <log-analytics-workspace-key>

  restartPolicy: Always

  ipAddress:
    ports:
      - protocol: TCP
        port: 80
    type: Private

  osType: Linux

  volumes:
    - name: rabbitvol
      azureFile:
        shareName: rabbitvol
        readOnly: false
        storageAccountName: <storage-account-name>
        storageAccountKey: <storage-account-key>

    - name: nginxconf
      azureFile:
        shareName: nginxconf
        readOnly: false
        storageAccountName: <storage-account-name>
        storageAccountKey: <storage-account-key>

    - name: redisvol
      azureFile:
        shareName: redisvol
        readOnly: false
        storageAccountName: <storage-account-name>
        storageAccountKey: <storage-account-key>

  subnetIds:
    - id: /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<subnet-name>

Wichtige Konfigurationshinweise:

  • Alle Container in einer ACI Container Group teilen denselben Netzwerk-Namespace — die Dienste kommunizieren über localhost, nicht über Dienstnamen.
  • Die Variablen REDIS_URL und CLOUDAMQP_URL verwenden localhost anstelle von redis und rabbitmq.
  • Das Image unify-server-web-ms-dynamics:v3.0 enthält kompilierten Python-Bytecode — der Einstiegspunkt ist app.pyc, nicht app.py.
  • RabbitMQ verwendet das offizielle Image mit über Umgebungsvariablen gesetzten Anmeldedaten. Der virtuelle Host ist standardmäßig /.
  • Der Block diagnostics.logAnalytics leitet die gesamte Container-Standardausgabe/Fehlerausgabe an den Log Analytics Workspace weiter. Logs erscheinen innerhalb weniger Minuten nach der Bereitstellung in Azure Monitor unter der Tabelle ContainerInstanceLog_CL.

1.8 Bereitstellung der Anwendung

  1. Schritt 1 — Bereitstellung der Container Group:

    az container create \
  --resource-group <resource-group> \
  --file container-group.yaml

  2. Schritt 2 — Überprüfen Sie den Bereitstellungsstatus:

    az container show \
  --resource-group <resource-group> \
  --name dqe-unify \
  --query "instanceView.state" -o tsv

    Erwartete Ausgabe: Running.

  3. Schritt 3 — Rufen Sie die der Container Group zugewiesene private IP-Adresse ab:

    az container show \
  --resource-group <resource-group> \
  --name dqe-unify \
  --query "ipAddress.ip" -o tsv

    Die zurückgegebene IP-Adresse ist nur aus dem Azure Virtual Network oder aus verbundenen Netzwerken erreichbar.

  4. Schritt 4 — Überprüfen Sie, ob alle Container laufen:

    az container show \
  --resource-group <resource-group> \
  --name dqe-unify \
  --query "containers[].{Name:name, State:instanceView.currentState.state}" \
  -o table

    Erwartete Ausgabe: Alle Container sollten den Status Running anzeigen:

    Name            State
-----------     -------
redis           Running
rabbitmq        Running
nginx           Running
unify-server    Running
queue-worker    Running

Wichtig: Wenn ein Container den Status Terminated oder Waiting anzeigt, überprüfen Sie sofort dessen Logs: az container logs --resource-group <rg> --name dqe-unify --container-name <service-name>.

Hinweis: ACI startet alle Container gleichzeitig. RabbitMQ und Redis benötigen möglicherweise einige Sekunden, um bereit zu sein. Der Unify Server versucht beim Start automatisch, die Verbindung erneut herzustellen.

1.9 Network Security Group (NSG) konfigurieren

Wenn die Container Instance in einem Azure Virtual Network bereitgestellt wird, konfigurieren Sie die zugehörige NSG so, dass eingehender Datenverkehr auf den erforderlichen Ports zugelassen wird.

  1. Gehen Sie zu Azure Portal → Network Security Groups → [Ihre NSG] → Inbound security rules.
  2. Klicken Sie auf Add.
  3. Setzen Sie Destination port ranges: 80. Wenn HTTPS über einen externen Reverse Proxy oder ein Application Gateway aktiviert ist, können zusätzliche Regeln erforderlich sein.
  4. Setzen Sie Protocol auf TCP und Action auf Allow.
  5. Klicken Sie auf Add.

Hinweis: Port 8000 (Unify Server) und Port 5672 (RabbitMQ) sind intern innerhalb der Container Group und müssen nicht extern freigegeben werden.

Dynamics 365 — Eingehende IP-Bereiche autorisieren

Der DQE Unify Server empfängt Anfragen von Microsoft Dynamics 365, das auf Azure-Infrastruktur läuft. Sie müssen die entsprechenden Azure-IP-Bereiche in der NSG autorisieren.

Die vollständige und aktuelle Liste der Microsoft Azure IP-Bereiche steht zum Download bereit unter:
Microsoft Azure IP Ranges and Service Tags

Laden Sie die JSON-Datei herunter, identifizieren Sie die für Ihre Region relevanten Service-Tags Dynamics365 und AzureCloud und fügen Sie die entsprechenden IP-Bereiche als eingehende Allow-Regeln auf dem vom Reverse Proxy oder Application Gateway freigegebenen Port hinzu (in der Regel Port 80 oder 443, abhängig von der Infrastrukturkonfiguration). Alternativ können Sie Source auf Service Tag setzen und Dynamics365 direkt in der NSG-Regel auswählen.

1.10 DNS einrichten

Wenden Sie sich an Ihre Netzwerk- oder DNS-Administratoren, um einen internen DNS-Eintrag zu erstellen, der auf die private IP-Adresse der Container Group oder auf den vom Reverse Proxy/Application Gateway freigegebenen Hostnamen verweist.

Eintragstyp Name Wert
A unify.yourdomain.com Private IP der ACI Container Group

Alternativ können Sie der Container Instance direkt im Azure Portal ein DNS-Namensbezeichnung zuweisen: Azure Portal → Container Instances → [dqe-unify] → Overview → DNS name label. Dies ergibt einen Hostnamen der Form dqe-unify.<location>.azurecontainer.io.

1.11 Bereitstellung überprüfen

Sobald sich das DNS verbreitet hat, öffnen Sie einen Browser und navigieren Sie zu:

http://unify.yourdomain.com

Sie können auch direkt mit der öffentlichen IP-Adresse testen:

curl http://<private-ip>

Erwartete Antwort des Unify Server:

{"status": "available"}

Wenn die Anwendung antwortet, ist die Bereitstellung abgeschlossen und der Server ordnungsgemäß konfiguriert.

2. Anwendungseinrichtung

Sobald die Anwendung läuft, müssen die NSG und jede vorgelagerte Firewall oder jeder Proxy so konfiguriert werden, dass die unten aufgeführten IP-Bereiche zugelassen werden.

2.1 Zu autorisierende IP-Adressen

DQE Software Office Server

Wenden Sie sich an den DQE-Software-Support, um die zu autorisierende IP-Adresse zu erhalten.

DQE – Deduplizierungsdienst

Wenden Sie sich an den DQE-Software-Support, um die zu autorisierende IP-Adresse zu erhalten.

DQE – Qualitätsdienst

Wenden Sie sich an den DQE-Software-Support, um die zu autorisierende IP-Adresse zu erhalten.

Erforderliche Aktion: Teilen Sie DQE Software die ausgehende öffentliche IP-Adresse mit, die von Ihrer Azure-Infrastruktur verwendet wird (NAT Gateway, Azure Firewall oder gleichwertig), damit sie für die DQE-Dienste autorisiert werden kann.

Azure-IP-Bereiche — Dynamics 365 und Azure-Dienste

Die vollständige und aktuelle Liste der Microsoft Azure IP-Bereiche (IPv4 und IPv6) steht zum Download bereit unter:

Microsoft Azure IP Ranges and Service Tags

Laden Sie die JSON-Datei herunter und identifizieren Sie die für Ihre Region relevanten Service-Tags (Dynamics365, AzureCloud). Fügen Sie die entsprechenden IP-Bereiche zu den eingehenden NSG-Regeln hinzu.

Verknüpfung mit

War dieser Beitrag hilfreich?

0 von 0 fanden dies hilfreich