Azure Container App (ACA) — Installation des Backend-Servers

Hinweis: Alle nachfolgend beschriebenen Elemente sind Empfehlungen von DQE, basierend auf Erfahrungen bei der Bereitstellung bei verschiedenen Kunden.

Der Kunde ist für die Integration in seine eigene Architektur verantwortlich.

Ein mit dem Kontext und der internen Infrastruktur vertrauter Architekt sollte die Empfehlungen von DQE mit der Infrastruktur des Kunden abstimmen.

Im Rahmen der Installation wurde der Ansatz dockerisiert, und alle Komponenten werden in Docker bereitgestellt.

• Redis zur Datenspeicherung und -verarbeitung
• RabbitMQ – Planer der von der DQE-Engine ausgeführten Aktionen
• Die Redis-Datenbank wird nach jedem Prozess gelöscht

1. Bereitstellungsarchitektur

Der Austausch zwischen Frontend und Backend wird nachfolgend detailliert beschrieben.

Um eine Instanz der Unify-Server-Anwendung in Ihrer Azure-Organisation bereitzustellen, stellt DQE-Software einen dedizierten Zugang zur Container-Registry bereit. Es gibt verschiedene Möglichkeiten, diesen Container bereitzustellen, wir empfehlen jedoch die Verwendung einer Azure Container App.

Das Verfahren wird im Abschnitt Installation erläutert.

Dies erfordert die Konfiguration eines Azure Gateway oder eines anderen Load Balancers, um diese Anwendung mit einer öffentlichen IP-Adresse und DNS verfügbar zu machen. Andernfalls kann die Salesforce-Organisation, in der Sie das Benutzeroberflächenpaket installiert haben, nicht auf die Anwendung zugreifen.

Um diese Anwendung bereitzustellen, müssen Sie eine YAML-Konfigurationsdatei erstellen, die in diesem Dokument detailliert beschrieben wird.

2. Flussmatrix

Nachfolgend finden Sie ein Diagramm, das alle ein- und ausgehenden Datenflüsse des Azure Application Gateway in einem standardmäßigen Unify-Datenprozess beschreibt.

Alle in diesem Diagramm beschriebenen IP-Adressen und Ports müssen in Ihrem Gateway oder Ihrer Firewall geöffnet werden, damit der Prozess abgeschlossen werden kann. Alle eingehenden Verbindungen erfolgen über HTTPS.

3. Salesforce-Verbindungen

Authentifizierung

Wenn Sie das Unify-UI-Paket in Ihrer Salesforce-Organisation installieren, müssen Sie einige Konfigurationsschritte durchlaufen. Während dieser Schritte registriert sich die Salesforce-Organisation beim Unify Server. In diesem Schritt erstellt der Server ein eindeutiges Passwort und Schlüssel-Anmeldedaten, die in Ihrer Organisation gespeichert und zur Authentifizierung bei Ihrer Unify-Server-Instanz verwendet werden.

Das von Salesforce zur Authentifizierung von Benutzern verwendete Sicherheitsprotokoll, das die verschiedenen vom Paket ausgeführten Vorgänge wie Massenimport und -export ermöglicht, ist JSON Web Token (JWT).

Dieses JWT kann von Salesforce nur für die Benutzer validiert werden, die in der mit dem Unify-UI-Paket installierten Connected App aktiviert sind.

Weitere Informationen finden Sie in der offiziellen Salesforce-Dokumentation hier.

Ablauf

Nachfolgend finden Sie die Beschreibung der Abläufe zwischen Salesforce und dem ACA-Unify-Server sowie zwischen dem ACA-Unify-Server und den DQE-Servern.

Schritt 1 – Einen neuen Prozess definieren

Ein Salesforce-Benutzer definiert einen neuen Prozess.

Beschreibung des Prozesses

• Objekt: Person Account
• Art der Verarbeitung: E-Mail-Validierung
• Verarbeitetes Feld: E-Mail
• Filter: siehe Geschäftsregeln

Schritt 2 – Den Prozess starten

Ein Salesforce-Benutzer startet den Prozess. Dieser Benutzer muss zu den autorisierten Logins in der Connected-App-Einrichtung gehören.

Schritt 3 – Die Verarbeitungsanfrage senden

Die Verarbeitungsanfrage wird an den ACA-Unify-Server gesendet.

Schritt 4 – Authentifizierung bei Salesforce

Der ACA-Unify-Server authentifiziert sich über die Connected App mithilfe eines JWT-Tokens bei Salesforce.

Schritt 5 – Daten exportieren

Salesforce erlaubt dem Server, einen Datenexport durchzuführen.

Schritt 6 – Exportierte Daten speichern

Der ACA-Unify-Server exportiert die relevanten Daten, wie die Felder Id und Email des Objekts Person Account, und speichert sie im CSV-Format in Azure File Storage.

Schritt 7 – Die Daten verarbeiten

Wenn es sich um eine Datenqualitätsverarbeitung handelt: Der ACA-Unify-Server führt anonymisierte Einzel-API-Aufrufe für jede E-Mail in der extrahierten Datei durch. Dies gilt nur für die E-Mail-Qualifizierung.

Während des gesamten Prozesses ist dies der einzige Schritt, bei dem einige Daten per REST-API über eine sichere Verbindung an den Produktionsserver von DQE-Software gesendet werden können.

Wenn es sich um eine Deduplizierungsverarbeitung handelt: Der ACA-Unify-Server berechnet Duplikatgruppen und gleicht Datensätze gemäß den während der Workshops definierten Abgleichsregeln ab.

Schritt 8 – Die Ergebnisdatei erstellen

Der ACA-Unify-Server fasst alle Verarbeitungsantworten in einer finalen CSV-Datei zusammen.

Handelt es sich um eine Deduplizierung, berechnet der ACA-Unify-Server das Ergebnis der Datenzusammenführung innerhalb der identifizierten Duplikatgruppen. Dieses Ergebnis wird in dem dafür vorgesehenen Feld DQE_Fusion_Json_c im Objekt Lead gespeichert, bis es verwendet wird, falls der Zusammenführungsprozess am Ende der Verarbeitung automatisch oder manuell ausgelöst wird.

Schritt 9 – Authentifizierung bei Salesforce

Der ACA-Unify-Server authentifiziert sich bei Salesforce.

Schritt 10 – Import oder Aktualisierung zulassen

Salesforce erlaubt dem Server, einen Datenimport oder eine Aktualisierung durchzuführen.

Schritt 11 – Verarbeitungsergebnisse senden

Der ACA-Unify-Server sendet die Verarbeitungsergebnisse über die von Salesforce bereitgestellten Bulk-APIs an die relevanten Datensätze, hier Person Account. Die Person Accounts werden mit dafür erstellten Feldern angereichert, wie der Duplikatgruppennummer und gegebenenfalls dem Feld, das das Zusammenführungsergebnis dieser Gruppe speichert.

Schritt 12 – CSV-Dateien löschen

Der ACA-Unify-Server löscht die ursprünglich beim Export in Schritt 6 empfangene CSV-Datei sowie die in Schritt 8 erzeugte CSV-Datei mit den Ergebnissen.

Schritt 13 – Den Verarbeitungsbericht senden

Der ACA-Unify-Server sendet einen statistischen Verarbeitungsbericht an Salesforce, der die Anzahl der verarbeiteten Datensätze und die Verarbeitungszeit enthält. Dieser Bericht ist in der Unify-Anwendung im Objekt Runs sichtbar.

3.1. Zusammensetzung und Dienste

Der Stack besteht aus Docker-Images, die über Azure Container Apps orchestriert werden. Für jeden Dienst werden nachfolgend die Attribute und deren Funktionen beschrieben.

Webanwendung (one-server)

Ein Backend-Container, der eine Microservices-Anwendung enthält. Diese Anwendung stellt alle APIs bereit, die zum Starten von Prozessen, zur Verwaltung von Verarbeitungswarteschlangen und zur Instanziierung von Verarbeitungs-Workern aufgerufen werden. Sie ist für ihre ordnungsgemäße Funktion von Redis und RabbitMQ abhängig. Dieser Dienst wird über den Nginx-Reverse-Proxy im Web bereitgestellt.

Docker-Compose-Einstellungen

• image: Der Name des in der DQE Azure Container Registry gehosteten Images:

  <Name of the registry container>.azurecr.io/<name of the image>

• depends_on: redis, rabbitmq
• environment: SFAPIVERSION, PORT, REDIS_URL, CLOUDAMQP_URL, CUSTOMUI, UNIFYSERVERURL
• command: bash ./entrypoint.sh

Worker (queue-worker)

Ein Backend-Container, der Warteschlangenaufgaben asynchron verarbeitet. Er entnimmt Aufgaben aus der RabbitMQ-Warteschlange und führt sie aus. Verwendet dasselbe Docker-Image wie die Webanwendung.

In Docker Compose festzulegende Parameter

• image: dasselbe Image wie der Webanwendungsdienst
• depends_on: redis, rabbitmq
• environment: SFAPIVERSION, WORKDIRPATH, REDIS_URL, CLOUDAMQP_URL
• command: python -u ./unify/queue_worker.pyc

CustomUI

Dieser Dienst ist eine Webanwendung, die ein Frontend zur Konfiguration von Deduplizierungsregeln bereitstellt. Er muss daher ebenfalls im Web verfügbar gemacht werden. Dieser Dienst nutzt zudem einige APIs des Backends, um beispielsweise Metadaten aus dem CRM abzurufen.

• image: <imageURL>
• command: npm start
• environment: PORT=8001, SESSION_SECRET

Nginx

Ein Reverse-Proxy, der eingehende HTTP/HTTPS-Anfragen vom Application Gateway an die Webanwendung und CustomUI weiterleitet. Seine Konfigurationsdatei wird in der Azure File Share nginxconf gespeichert und zur Laufzeit in den Container eingebunden.

• image: <imageURL>
• ports: 80
• volume: nginxconf:/etc/nginx/conf.d

Redis

Dieser Dienst ist eine Key/Value-Datenbank, die zum Speichern interner Betriebsschlüssel wie Salesforce-Org-Konfigurationen, Sitzungen usw. verwendet wird.

Es ist möglich, das offizielle Image redis:alpine zu verwenden, aber als Sicherheitsmaßnahme blockieren einige Cloud-Anbieter das Abrufen öffentlicher Images und erlauben nur Images aus privaten Registries. Um diese Einschränkung zu umgehen, veröffentlicht DQE zudem ein kompatibles Redis-Image in seiner privaten Registry.

Parameter

• image: <imageURL>
• volumes: redisvol:/data (Azure File Share)

RabbitMQ

Dieser Dienst ist ein leistungsfähiger Warteschlangen-Manager, der den Empfang und die Planung von Verarbeitungsanfragen ermöglicht. Bis ein Prozess einem Worker zugewiesen und abgeschlossen wurde, verbleibt er in der Warteschlange. Dies ermöglicht zudem Ausfallsicherheit — wird der Server neu gestartet, setzt er die letzte Verarbeitung in der Warteschlange dort fort, wo sie unterbrochen wurde.

Wie beim Redis-Dienst-Image haben Sie die Möglichkeit, eine öffentliche Version oder die Version aus der privaten DQE-Registry zu verwenden.

Parameter

• image: <imageURL>
• volumes: rabbitvol:/var/lib/rabbitmq (Azure File Share)
• environment: RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS, RABBITMQ_DEFAULT_VHOST

4. Installation

In diesem Abschnitt beschreiben wir das Installationsprotokoll zur Erstellung einer Instanz des DQE Unify Server als Azure Container App.

Wir stellen zudem ein Beispiel zur Erstellung eines Azure Application Gateway bereit.

Dieser Teil hängt jedoch stark von Ihrer eigenen Organisation ab. Das technische Team des Kunden ist für die Umsetzung der verschiedenen Empfehlungen verantwortlich.

Weitere Informationen zur Konfiguration Ihres Azure Application Gateway finden Sie in der Microsoft-Dokumentation hier.

4.1. Ein Application Gateway erstellen

4.1.1. Registerkarte „Grundlagen"

Die erste Registerkarte sollte ein Formular wie folgt anzeigen. Füllen Sie die verschiedenen Teile wie unten gezeigt aus.

4.1.1.1. WAF-Richtlinie

Die WAF (Web Application Firewall) dient dazu, die IP-Bereiche festzulegen, die zum Aufruf des Application Gateway berechtigt sind, wie z. B. Salesforce-IP-Bereiche.

Erstellen Sie eine neue WAF über das Feld WAF policy in 4.1.1. Registerkarte „Grundlagen".

4.1.1.2. VNET

Das VNET (Virtual Network) dient zur Verbindung des Application Gateway und der ACA (Azure Container App). Alle Datenflüsse laufen über dieses private Netzwerk.

Erstellen Sie ein neues VNET über das Feld Virtual network in 4.1.1. Registerkarte „Grundlagen".

4.1.2. Frontends

Die erste Registerkarte sollte ein Formular wie folgt anzeigen. Füllen Sie die verschiedenen Teile wie unten gezeigt aus.

4.1.2.1. Öffentliche IP-Adresse

Die öffentliche IP wird vom Application Gateway bereitgestellt. Sie dient zur Weiterleitung des Datenverkehrs an die ACA.

Erstellen Sie eine neue öffentliche IP über das Feld Public IP address in 4.1.2. Frontends.

4.1.3. Backends

Die erste Registerkarte sollte ein Formular wie folgt anzeigen. Füllen Sie die verschiedenen Teile wie unten gezeigt aus.

4.1.3.1. Backend-Pool

Der Backend-Pool ermöglicht es dem Application Gateway, Datenflüsse über das VNET zur ACA weiterzuleiten. Er wird während des Schritts Network bei der ACA-Erstellung automatisch ausgefüllt.

Erstellen Sie einen neuen Backend-Pool über Add a backend pool in 4.1.3. Backends.

4.1.4. Konfiguration

Die erste Registerkarte sollte ein Formular wie folgt anzeigen. Füllen Sie die verschiedenen Teile wie unten gezeigt aus.

4.1.4.1. Routing Rules – Listener

Diese Konfiguration ermöglicht Aufrufe des Application Gateway über das HTTPS-Protokoll.

4.1.4.2. Routing Rules – Backend Target

Das Backend Target wird vom Application Gateway verwendet, um zu bestimmen, wohin eingehender Datenverkehr weitergeleitet wird. Es verwendet den zuvor erstellten Backend-Pool.

4.1.4.3. Routing Rules – Backend Setting

Das Backend Setting wird vom Application Gateway verwendet, um zu bestimmen, welches Protokoll bei der Weiterleitung des Datenverkehrs an die ACA verwendet wird. Dieser Datenverkehr wird über das private VNET gesendet.

Warnung: Das Protokoll muss HTTP sein (nicht HTTPS). Der interne Ingress der ACA kommuniziert innerhalb des privaten VNET über HTTP. Das Protokoll im Backend Setting muss auf HTTP gesetzt werden, nicht auf HTTPS. Ist HTTPS eingestellt, kann das Application Gateway keine Verbindung zum ACA-Backend herstellen.

Klicken Sie anschließend auf Review + create.

4.2. Eine Container Apps Environment (ACAE) erstellen

4.2.1. Ein VNET-Subnetz für die ACAE hinzufügen

Erstellen Sie ein neues, an Microsoft.App/environments delegiertes Subnetz aus dem in 4.1.1.2. VNET erstellten VNET.

4.2.2. Azure CLI installieren

Azure CLI muss auf Ihrem Computer installiert sein.

4.2.2.1. UNIX

$ sudo curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

4.2.2.2. Windows

Siehe die Microsoft-Dokumentation hier.

4.2.3. ACAE erstellen

Hinweis: Der DQE-Unify-Stack erfordert einen Dedicated-Plan, da der queue-worker 5 Gi Arbeitsspeicher benötigt, was das Limit von 2 Gi pro Container im Consumption-Plan überschreitet. Das Flag --enable-workload-profiles aktiviert die Unterstützung des Dedicated-Plans für die Umgebung.

4.2.3.1. UNIX

az containerapp env create \
 --name <container apps environments name> \
 --resource-group <resource group> \
 --location <location> \
 --internal-only true \
 --enable-workload-profiles \
 --infrastructure-subnet-resource-id $(az network vnet subnet show \
    --resource-group <vnet resource group> \
    --vnet-name <vnet name (created on 4.1.1.1)> \
    --name <subnet name (created on 4.2.1)> \
    --query id -o tsv)

4.2.3.2. Windows

az containerapp env create `
 --name <container apps environments name> `
 --resource-group <resource group> `
 --location <location> `
 --internal-only true `
 --enable-workload-profiles `
 --infrastructure-subnet-resource-id $(az network vnet subnet show `
    --resource-group <vnet resource group> `
    --vnet-name <vnet name (created on 4.1.1.1)> `
    --name <subnet name (created on 4.2.1)> `
    --query id -o tsv)

4.2.3.3. Ein Dedicated-Workload-Profil (D8) hinzufügen

Fügen Sie der Umgebung ein Dedicated-D8-Workload-Profil (8 vCPU / 32 Gi) hinzu. Dieser Knoten bietet ausreichend Kapazität für den gesamten Stack (insgesamt 5 vCPU / 10 Gi).

UNIX

az containerapp env workload-profile add \
  --name <container apps environments name> \
  --resource-group <resource group> \
  --workload-profile-name "Dedicated-D8" \
  --workload-profile-type D8 \
  --min-nodes 1 \
  --max-nodes 1

Windows

az containerapp env workload-profile add `
  --name <container apps environments name> `
  --resource-group <resource group> `
  --workload-profile-name "Dedicated-D8" `
  --workload-profile-type D8 `
  --min-nodes 1 `
  --max-nodes 1

4.3. Eine Container App aus YAML erstellen

4.3.1. Ein Storage-Konto erstellen

4.3.1.1. Grundlagen

Füllen Sie alle erforderlichen Informationen aus.

4.3.1.2. Erweitert

Keine Änderung erforderlich.

4.3.1.3. Registerkarte Netzwerk

4.3.1.4. Datensicherung

Keine Änderung erforderlich.

4.3.1.5. Verschlüsselung

Keine Änderung erforderlich.

4.3.1.6. Tags

Keine Änderung erforderlich.

4.3.1.7. Review + Create

Erstellen Sie das Storage-Konto.

4.3.2. File Shares erstellen

Der Container benötigt drei File Shares: rabbitvol, nginxconf und redisvol.

Um HTTPS auf der ACA zu verwenden, wird Nginx bereitgestellt. Damit alle erforderlichen Informationen vorhanden sind, fügen Sie der nginxconf-File-Share die folgenden Dateien hinzu:

• Die SSL-Zertifikatsdatei .pem oder .crt
• Die SSL-Schlüsseldatei .key
• Wenn die .pem-Datei ein Passwort hat, fügen Sie es in einer Textdatei hinzu und legen Sie diese Textdatei ebenfalls in der File Share ab
• Die in 4.3.6. Nginx konfigurieren definierte Datei default.conf

4.3.3. Eine Storage-Umgebung erstellen

Das folgende Verfahren muss für jeden zuvor erstellten File-Share-Namen ausgeführt werden:

• redisvol
• rabbitvol
• nginxconf

4.3.3.1. UNIX

az containerapp env storage set \
　　--access-mode ReadWrite \
　　--azure-file-account-name <account storage name> \
　　--azure-file-account-key <account storage key> \
　　--azure-file-share-name <fileshare name (redisvol, rabbitvol, nginxconf)> \
　　--storage-name <storage environment name (redisvol, rabbitvol, nginxconf)> \
　　--name <container app name> \
　　--resource-group <resource group> \
　　--output table

4.3.3.2. Windows

az containerapp env storage set `
　　--access-mode ReadWrite `
　　--azure-file-account-name <account storage name> `
　　--azure-file-account-key <account storage key> `
　　--azure-file-share-name <fileshare name (redisvol, rabbitvol, nginxconf)> `
　　--storage-name <storage environment name (redisvol, rabbitvol, nginxconf)> `
　　--name <container app name> `
　　--resource-group <resource group> `
　　--output table

4.3.4. YAML-Konfigurationsdatei der Container App

Erstellen Sie auf Ihrem lokalen Rechner eine YAML-Datei für die Azure Container App. Das ACA-Format unterscheidet sich vom ACI-Format: Volumes verwenden storageType: AzureFile unter Bezugnahme auf die in 4.3.3 erstellten Storage-Umgebungsnamen, und die Registry-Anmeldedaten werden in configuration.registries deklariert. Alle Container teilen sich innerhalb einer einzigen Container App denselben Netzwerk-Namespace, sodass die Kommunikation zwischen den Containern über localhost erfolgt.

Sie müssen die folgenden Schlüssel ausfüllen:

• environmentId: die vollständige Ressourcen-ID der in 4.2.3 erstellten ACAE. Format: subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.App/managedEnvironments/{container apps environments name}
• location: <Location>
• configuration.registries: server, username und passwordSecretRef mit Bezug auf das von DQE bereitgestellte Registry-Passwort
• volumes.storageName: muss mit den in 4.3.3 erstellten Storage-Umgebungsnamen übereinstimmen: redisvol, rabbitvol und nginxconf.

Warnung: Mount-Pfad des RabbitMQ-Volumes: Die YAML-Datei bindet das RabbitMQ-Volume unter /bitnami (Bitnami-Image-Pfad) ein. Wenn Sie stattdessen das offizielle rabbitmq-Image verwenden, ändern Sie den mountPath in /var/lib/rabbitmq. Bei falschem Pfad startet RabbitMQ ohne Persistenz und kann möglicherweise keine Daten schreiben.

location: <Location>
name: dqe-unify
type: Microsoft.App/containerApps
properties:
  # Reference the Dedicated D8 workload profile created on 4.2.3.3
  workloadProfileName: "Dedicated-D8"
  environmentId: /subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.App/managedEnvironments/{container apps environments name (created on 4.2.3)}
  configuration:
    activeRevisionsMode: Single
    ingress:
      external: false   # Traffic comes from the Application Gateway via private VNET
      targetPort: 80
    registries:
      - server: <registry URL>
        username: <Username provided by DQE>
        passwordSecretRef: registry-password
    secrets:
      - name: registry-password
        value: <Password provided by DQE>
  template:
    containers:

      # Redis — 0.5 vCPU / 1 Gi (ratio 1:2)
      - name: redis
        image: <ImageURL>
        resources:
          cpu: 0.5
          memory: 1Gi
        volumeMounts:
          - volumeName: redisvol
            mountPath: /data

      # RabbitMQ — 1 vCPU / 2 Gi (ratio 1:2)
      - name: rabbitmq
        image: <ImageURL>
        resources:
          cpu: 1
          memory: 2Gi
        env:
          - name: RABBITMQ_DEFAULT_PASS
            value: guest
          - name: RABBITMQ_DEFAULT_USER
            value: guest
          - name: RABBITMQ_DEFAULT_VHOST
            value: admin
        volumeMounts:
          - volumeName: rabbitvol
            mountPath: /bitnami

      # Nginx — 0.25 vCPU / 0.5 Gi (ratio 1:2)
      - name: nginx
        image: <ImageURL>
        resources:
          cpu: 0.25
          memory: 0.5Gi
        volumeMounts:
          - volumeName: nginxconf
            mountPath: /etc/nginx/conf.d

      # Unify UI — 0.25 vCPU / 0.5 Gi (ratio 1:2)
      - name: unify-ui
        image: <ImageURL>
        command: ["npm", "start"]
        resources:
          cpu: 0.25
          memory: 0.5Gi
        env:
          - name: SESSION_SECRET
            value: myveryimportantSecret
          - name: PORT
            value: "8001"

      # Unify web server — 0.5 vCPU / 1 Gi (ratio 1:2)
      - name: one-server
        image: <ImageURL>
        command: ["bash", "./entrypoint.sh"]
        resources:
          cpu: 0.5
          memory: 1Gi
        env:
          - name: SFAPIVERSION
            value: v59.0
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@localhost:5672/admin
          - name: CUSTOMUI
            value: http://localhost:8001
          - name: UNIFYSERVERURL
            value: http://localhost:8000
          - name: PORT
            value: "8000"

      # Queue Worker — 2.5 vCPU / 5 Gi (ratio 1:2) — requires Dedicated plan
      - name: queue-worker
        image: <ImageURL>
        command: ["python", "-u", "./unify/queue_worker.pyc"]
        resources:
          cpu: 2.5
          memory: 5Gi
        env:
          - name: SFAPIVERSION
            value: v59.0
          - name: WORKDIRPATH
            value: /app/unify
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: CLOUDAMQP_URL
            value: amqp://guest:guest@localhost:5672/admin

    # Azure File Share volumes — storageName must match names created on 4.3.3
    volumes:
      - name: redisvol
        storageType: AzureFile
        storageName: redisvol
      - name: rabbitvol
        storageType: AzureFile
        storageName: rabbitvol
      - name: nginxconf
        storageType: AzureFile
        storageName: nginxconf

    scale:
      minReplicas: 1   # Always keep 1 replica running
      maxReplicas: 1   # Single replica — no horizontal scaling for stateful services

4.3.5. Die Container App bereitstellen

Öffnen Sie auf Ihrem lokalen Rechner eine Eingabeaufforderung und melden Sie sich mit Azure CLI bei Azure an:

az login

Erstellen Sie die Azure Container App aus der zuvor erstellten YAML-Datei:

az containerapp create \
  --resource-group <your Resource Group Name> \
  --name dqe-unify \
  --environment <container apps environments name (created on 4.2.3)> \
  --yaml <yaml file path>

Nach Abschluss des Vorgangs sollten Sie die folgenden Informationen erhalten:

Warnung: Startreihenfolge: Die ACA startet alle Container gleichzeitig — es gibt kein Äquivalent zu dependsOn. RabbitMQ und Redis sind möglicherweise noch nicht bereit, wenn one-server und queue-worker starten. Enthält die Anwendung keine Retry-Logik, stürzen die Container ab und starten in einer Schleife neu, bis die Dienste verfügbar sind. Dies wird automatisch durch restartPolicy: Always gehandhabt, kann jedoch zu einer Verzögerung von 1–2 Minuten führen, bevor die Anwendung vollständig einsatzbereit ist.

4.3.6. Nginx konfigurieren

Erstellen Sie eine Datei default.conf mit folgendem Inhalt. Diese Konfiguration verwaltet die HTTP-Verbindung zwischen dem Application Gateway und der ACA über das private VNET. Alle Container teilen sich innerhalb der Container App denselben Netzwerk-Namespace, sodass das Routing zwischen den Containern über localhost erfolgt.

server {
listen 80;
location / {
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_pass http://127.0.0.1:8001;
}

location /unify/ {
rewrite /unify/(.*) /$1 break;
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8000;
}
}

Laden Sie diese Datei in die zuvor erstellte nginxconf-File-Share hoch.

Warnung: Starten Sie die ACA neu, damit Nginx mit der neuesten Änderung aktualisiert wird.

4.4. Den Application-Gateway-Backend-Pool einrichten

Nachdem die ACA erstellt wurde, rufen Sie deren internen FQDN ab. Im Gegensatz zu ACI stellt eine ACA mit internem Ingress einen Hostnamen bereit, keine direkte IP:

az containerapp show \
  --name dqe-unify \
  --resource-group <resource group> \
  --query "properties.configuration.ingress.fqdn" -o tsv

Der FQDN hat folgendes Format: dqe-unify.internal.<environment-id>.<region>.azurecontainerapps.io.

Gehen Sie zu Application Gateway > Backend Pool > {Your Backend Pool} > Edit the backend pool. Fügen Sie den ACA-FQDN als Backend-Ziel hinzu und wählen Sie den Typ FQDN, nicht IP-Adresse.

4.5. Den Health Probe des Application Gateway einrichten

Der Health Probe wird vom Application Gateway verwendet, um regelmäßig zu prüfen, ob die API auf der ACA verfügbar ist. Richten Sie den Health Probe ein und klicken Sie dann auf Test. Wenn der Status Healthy ist, ist die ACA korrekt konfiguriert und gestartet.

Warnung: Health-Probe-Pfad: Setzen Sie den Probe-Pfad auf / (root) und das Protokoll auf HTTP auf Port 80. Der Unify Server gibt auf dem Root-Pfad eine 200-Antwort zurück, wenn er verfügbar ist. Verwenden Sie kein HTTPS für den Probe — der interne Ingress der ACA terminiert TLS nicht auf dem privaten VNET.

Fügen Sie über das Application Gateway einen Health Probe hinzu:

Klicken Sie auf Test > Add.

4.5.1. Den DNS einrichten

Sie müssen sich an Ihre Administratoren oder eine Person mit Zugriff auf die DNS-Zone wenden und darum bitten, einen DNS-Namen hinzuzufügen, der auf die öffentliche IP Ihres Application Gateway verweist.

4.5.2. WAF-Konfiguration

Die WAF dient dazu, bestimmte IP-Adressen, die versuchen, das Application Gateway aufzurufen, zu autorisieren oder zu blockieren. Damit Salesforce-Prozesse funktionieren, muss die WAF die Salesforce-IP-Bereiche autorisieren.

Klicken Sie in der WAF auf Switch to prevention mode. Dies ermöglicht es der WAF, die untenstehenden benutzerdefinierten Regeln zu verwenden.

Fügen Sie in den benutzerdefinierten Regeln hinzu:

• Salesforce-IP-Adressbereiche, einschließlich Basic- und Hyperforce-Bereiche
• DQE Check-Lizenzserver: beim Support erfragen
• SF Automation 1: beim Support erfragen
• SF Automation 2: beim Support erfragen

Die vollständige Liste der Salesforce-IP-Adressen finden Sie hier.

Überprüfen Sie nach Abschluss dieser Schritte Ihre Bereitstellung wie in 4.5. Den Health Probe des Application Gateway einrichten beschrieben.