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 DQE One 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 Application Gateway oder eines anderen Load Balancers, um diese Anwendung mit einer öffentlichen IP-Adresse und DNS verfügbar zu machen. Andernfalls kann die Salesforce-Org, in der Sie das DQE One-Paket 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 DQE One-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 DQE One-Paket in Ihrer Salesforce-Org installieren, müssen Sie einige Konfigurationsschritte durchlaufen. Während dieser Schritte registriert sich die Salesforce-Org beim DQE One Server. In diesem Schritt erstellt der Server ein eindeutiges Passwort und Schlüssel-Anmeldedaten, die in Ihrer Org gespeichert und zur Authentifizierung bei Ihrer DQE One 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 DQE One-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 DQE One Server auf ACA sowie zwischen dem DQE One Server auf ACA 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 Benutzern in der Connected-App-Einrichtung gehören.

Schritt 3 – Die Verarbeitungsanfrage senden

Die Verarbeitungsanfrage wird an den DQE One Server auf ACA gesendet.

Schritt 4 – Authentifizierung bei Salesforce

Der DQE One Server auf ACA 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 DQE One Server auf ACA 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 DQE One Server auf ACA 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 DQE One Server auf ACA berechnet Duplikatgruppen und gleicht Datensätze gemäß den während der Workshops definierten Abgleichsregeln ab.

Schritt 8 – Die Ergebnisdatei erstellen

Der DQE One Server auf ACA fasst alle Verarbeitungsantworten in einer finalen CSV-Datei zusammen.

Handelt es sich um eine Deduplizierung, berechnet der DQE One Server auf ACA das Ergebnis der Datenzusammenführung innerhalb der identifizierten Duplikatgruppen. Dieses Ergebnis wird in dem dafür vorgesehenen Feld DQE_Fusion_Json__c des verarbeiteten Objekts 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 DQE One Server auf ACA 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 DQE One Server auf ACA 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 DQE One Server auf ACA 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 DQE One Server auf ACA sendet einen statistischen Verarbeitungsbericht an Salesforce, der die Anzahl der verarbeiteten Datensätze und die Verarbeitungszeit enthält. Dieser Bericht ist in der DQE One-Anwendung im Objekt Runs sichtbar.

3.1. Zusammensetzung und Dienste

Der Stack besteht aus Docker-Images, die als Container einer einzigen Azure Container App bereitgestellt werden. Alle Container der App teilen sich dasselbe Netzwerk und kommunizieren daher über localhost. 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 von Salesforce 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 unter dem Pfad /unify/ im Web bereitgestellt.

Container-Einstellungen

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

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

• startet, sobald Redis und RabbitMQ erreichbar sind
• 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.

Container-Einstellungen

• image: dasselbe Image wie der Webanwendungsdienst
• startet, sobald RabbitMQ und die Webanwendung erreichbar sind
• environment: SFAPIVERSION, WORKDIRPATH, REDIS_URL, CLOUDAMQP_URL
• command: python -u ./unify/queue_worker.pyc

Benutzeroberfläche (one-ui)

Dieser Dienst ist eine Webanwendung, die ein Frontend zur Konfiguration von Deduplizierungsregeln bereitstellt. Er muss daher ebenfalls im Web verfügbar gemacht werden, über Nginx auf dem Stammpfad /. 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-Anfragen vom Application Gateway an die Webanwendung und die Benutzeroberfläche weiterleitet. HTTPS wird am Application Gateway terminiert. 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/mnesia (Azure File Share)
• environment: RABBITMQ_DEFAULT_USER, RABBITMQ_DEFAULT_PASS, RABBITMQ_DEFAULT_VHOST, RABBITMQ_NODENAME

4. Installation

In diesem Abschnitt beschreiben wir das Installationsprotokoll zur Erstellung einer Instanz des DQE One 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

Diese 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

Diese 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. Erstellen Sie ihn vorerst leer: Das ACA-Ziel wird in 4.4. Den Application-Gateway-Backend-Pool einrichten hinzugefügt, sobald die ACA existiert.

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

4.1.4. Konfiguration

Diese 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. Das SSL-Zertifikat Ihrer Domain wird hier auf den HTTPS-Listener hochgeladen: HTTPS wird am Application Gateway terminiert.

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.

• Backend protocol: HTTP
• Backend port: 80
• Override with new host name: Yes
• Host name override: Pick host name from backend target

Warnung: Die ACA leitet Anfragen anhand ihres Hostnamens weiter. Sendet das Application Gateway nicht den Hostnamen der ACA (Pick host name from backend target), antwortet die ACA mit 404 und das Backend bleibt fehlerhaft. HTTP wird von der ACA akzeptiert, da ihr Ingress mit allowInsecure: true konfiguriert ist (siehe 4.3.4); der Datenverkehr bleibt innerhalb des privaten VNET.

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. Das Subnetz muss mindestens /27 groß sein und ausschließlich der Umgebung dienen.

4.2.2. Azure CLI installieren

Azure CLI muss auf Ihrem Computer installiert sein.

4.2.2.1. UNIX

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az extension add --name containerapp --upgrade

4.2.2.2. Windows

Siehe die Microsoft-Dokumentation hier, und führen Sie anschließend az extension add --name containerapp --upgrade aus.

4.2.3. ACAE erstellen

Hinweis: Der DQE One-Stack erfordert einen Dedicated-Plan. Alle Container der App laufen in demselben Replikat und benötigen insgesamt 5 vCPU / 10 Gi, was das Maximum von 4 vCPU / 8 Gi pro Replikat 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.2)> \
    --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.2)> `
    --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

Hinweis: Wenn Sie den öffentlichen Netzwerkzugriff auf ausgewählte Netzwerke beschränken, fügen Sie das in 4.2.1 erstellte ACAE-Subnetz hinzu. Andernfalls können die File Shares nicht eingebunden werden und die Container starten nicht.

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

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

Fügen Sie die in 4.3.6. Nginx konfigurieren definierte Datei default.conf der File Share nginxconf hinzu. In dieser File Share ist kein Zertifikat erforderlich: Das SSL-Zertifikat wird auf dem Listener des Application Gateway installiert (4.1.4.1).

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 apps environments name (created on 4.2.3)> \
  --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 apps environments name (created on 4.2.3)> `
  --resource-group <resource group> `
  --output table

Hinweis: --name ist der Name der Container Apps Environment, nicht der Container App: Der Speicher wird an die Umgebung angebunden.

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 und username, von DQE bereitgestellt
• configuration.secrets: das von DQE bereitgestellte Registry-Passwort, ein sicheres RabbitMQ-Passwort (wird auch in amqp-url eingefügt, vermeiden Sie daher die Zeichen @ : / ? #) und ein langes, zufälliges Session-Secret
• volumes.storageName: muss mit den in 4.3.3 erstellten Storage-Umgebungsnamen übereinstimmen: redisvol, rabbitvol und nginxconf.

Wichtige Punkte:

• Passwörter werden als ACA-Secrets (secretRef) gespeichert und erscheinen nie im Klartext in der Container-Konfiguration. Geben Sie die ausgefüllte YAML-Datei nicht weiter und versionieren Sie sie nicht.
• Die ACA startet alle Container gleichzeitig. one-server wartet auf Redis und RabbitMQ, und queue-worker wartet auf RabbitMQ und one-server, bevor sie starten.
• RabbitMQ-Volume: Beim offiziellen rabbitmq-Image wird nur der Datenordner mnesia auf der File Share eingebunden, da die Datei .erlang.cookie nicht auf einer Azure File Share gespeichert werden kann. RABBITMQ_NODENAME behält über Neustarts hinweg denselben Knotennamen bei, damit Prozesse in der Warteschlange wiedergefunden werden. Wenn Sie das Bitnami-Image verwenden, binden Sie /bitnami/rabbitmq/mnesia ein und verwenden Sie stattdessen die Variablen RABBITMQ_USERNAME, RABBITMQ_PASSWORD und RABBITMQ_VHOST.
• allowInsecure: true ermöglicht es der ACA, den vom Application Gateway über das private VNET gesendeten HTTP-Datenverkehr anzunehmen. Ohne diese Einstellung leitet die ACA HTTP-Anfragen auf HTTPS um.

location: <Location>
name: dqe-one
type: Microsoft.App/containerApps
properties:
  # 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 the private VNET
      targetPort: 80        # Nginx
      transport: http
      allowInsecure: true   # Accept HTTP from the Application Gateway (otherwise ACA redirects to HTTPS)
    registries:
      - server: <registry URL>
        username: <Username provided by DQE>
        passwordSecretRef: registry-password
    secrets:
      - name: registry-password
        value: <Password provided by DQE>
      - name: rabbitmq-password
        value: <RabbitMQ password>
      - name: amqp-url
        value: amqp://dqeone:<RabbitMQ password>@localhost:5672/admin
      - name: session-secret
        value: <Long random string>
  template:
    containers:

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

      # RabbitMQ (official image) — 1 vCPU / 2 Gi
      # Bitnami image: use RABBITMQ_USERNAME / RABBITMQ_PASSWORD / RABBITMQ_VHOST
      # and mountPath /bitnami/rabbitmq/mnesia instead
      - name: rabbitmq
        image: <ImageURL>
        resources:
          cpu: 1
          memory: 2Gi
        env:
          - name: RABBITMQ_DEFAULT_USER
            value: dqeone
          - name: RABBITMQ_DEFAULT_PASS
            secretRef: rabbitmq-password
          - name: RABBITMQ_DEFAULT_VHOST
            value: admin
          - name: RABBITMQ_NODENAME        # stable node name: queues are found again after a restart
            value: rabbit@localhost
        volumeMounts:
          - volumeName: rabbitvol
            mountPath: /var/lib/rabbitmq/mnesia   # data only: .erlang.cookie cannot live on an Azure File Share

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

      # DQE One UI — 0.25 vCPU / 0.5 Gi
      - name: one-ui
        image: <ImageURL>
        command: ["npm", "start"]
        resources:
          cpu: 0.25
          memory: 0.5Gi
        env:
          - name: SESSION_SECRET
            secretRef: session-secret
          - name: PORT
            value: "8001"

      # DQE One web server — 0.5 vCPU / 1 Gi
      # Waits for Redis and RabbitMQ: ACA starts all containers at the same time
      - name: one-server
        image: <ImageURL>
        command:
          - bash
          - -c
          - "until (echo > /dev/tcp/127.0.0.1/6379) 2>/dev/null && (echo > /dev/tcp/127.0.0.1/5672) 2>/dev/null; do echo waiting-for-redis-rabbitmq; sleep 3; done; exec bash ./entrypoint.sh"
        resources:
          cpu: 0.5
          memory: 1Gi
        env:
          - name: SFAPIVERSION
            value: v65.0
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: CLOUDAMQP_URL
            secretRef: amqp-url
          - name: CUSTOMUI
            value: http://localhost:8001
          - name: UNIFYSERVERURL
            value: http://localhost:8000
          - name: PORT
            value: "8000"

      # Queue Worker — 2.5 vCPU / 5 Gi
      - name: queue-worker
        image: <ImageURL>
        command:
          - bash
          - -c
          - "until (echo > /dev/tcp/127.0.0.1/5672) 2>/dev/null && (echo > /dev/tcp/127.0.0.1/8000) 2>/dev/null; do echo waiting-for-rabbitmq-server; sleep 3; done; exec python -u ./unify/queue_worker.pyc"
        resources:
          cpu: 2.5
          memory: 5Gi
        env:
          - name: SFAPIVERSION
            value: v65.0
          - name: WORKDIRPATH
            value: /app/unify
          - name: REDIS_URL
            value: redis://localhost:6379
          - name: CLOUDAMQP_URL
            secretRef: amqp-url

    # Azure File Share volumes — storageName must match the 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 — Redis and RabbitMQ are stateful

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-one \
  --environment <container apps environments name (created on 4.2.3)> \
  --yaml <yaml file path>

Nach Abschluss des Vorgangs sollten Sie die folgenden Informationen erhalten:

Die Anwendung ist nach etwa 1–2 Minuten vollständig einsatzbereit, sobald RabbitMQ gestartet ist. So verfolgen Sie den Start eines Containers:

az containerapp logs show --name dqe-one --resource-group <resource group> --container one-server --follow

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. Die Benutzeroberfläche wird auf dem Stammpfad bereitgestellt, die API des DQE One Server unter /unify/.

server {
    listen 80;

    # DQE One UI (CustomUI)
    location / {
        proxy_pass         http://127.0.0.1:8001;
        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_set_header   X-Forwarded-Proto https;
    }

    # DQE One Server API — the trailing "/" removes the /unify/ prefix
    location /unify/ {
        proxy_pass         http://127.0.0.1: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_set_header   X-Forwarded-Proto https;
        proxy_read_timeout 300s;
    }
}

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

Warnung: Starten Sie die ACA neu, damit Nginx die neueste Änderung übernimmt:

az containerapp revision restart \
  --name dqe-one \
  --resource-group <resource group> \
  --revision $(az containerapp revision list --name dqe-one --resource-group <resource group> --query "[0].name" -o tsv)

4.3.7. Eine private DNS-Zone erstellen

Die Umgebung ist intern: Der Hostname der ACA kann nur über das private Azure-DNS aufgelöst werden. Ohne eine mit dem VNET verknüpfte private DNS-Zone kann das Application Gateway den Hostnamen der ACA nicht auflösen, und das Backend bleibt fehlerhaft.

UNIX

ENV_DOMAIN=$(az containerapp env show --name <container apps environments name> --resource-group <resource group> --query properties.defaultDomain -o tsv)
ENV_IP=$(az containerapp env show --name <container apps environments name> --resource-group <resource group> --query properties.staticIp -o tsv)
VNET_ID=$(az network vnet show --resource-group <vnet resource group> --name <vnet name> --query id -o tsv)

az network private-dns zone create --resource-group <resource group> --name $ENV_DOMAIN
az network private-dns link vnet create --resource-group <resource group> --zone-name $ENV_DOMAIN \
  --name aca-vnet-link --virtual-network $VNET_ID --registration-enabled false
az network private-dns record-set a add-record --resource-group <resource group> --zone-name $ENV_DOMAIN \
  --record-set-name "*" --ipv4-address $ENV_IP

Windows

$ENV_DOMAIN = az containerapp env show --name <container apps environments name> --resource-group <resource group> --query properties.defaultDomain -o tsv
$ENV_IP = az containerapp env show --name <container apps environments name> --resource-group <resource group> --query properties.staticIp -o tsv
$VNET_ID = az network vnet show --resource-group <vnet resource group> --name <vnet name> --query id -o tsv

az network private-dns zone create --resource-group <resource group> --name $ENV_DOMAIN
az network private-dns link vnet create --resource-group <resource group> --zone-name $ENV_DOMAIN `
  --name aca-vnet-link --virtual-network $VNET_ID --registration-enabled false
az network private-dns record-set a add-record --resource-group <resource group> --zone-name $ENV_DOMAIN `
  --record-set-name "*" --ipv4-address $ENV_IP

4.4. Den Application-Gateway-Backend-Pool einrichten

Nachdem die ACA erstellt wurde, rufen Sie deren Hostnamen (FQDN) ab. Eine ACA mit internem Ingress stellt einen Hostnamen bereit, keine direkte IP:

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

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 Anwendung 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.

• Protocol: HTTP
• Pick host name from backend settings: Yes
• Path: /
• Backend settings: das in 4.1.4.3 erstellte Backend Setting (Port 80)

Warnung: Der Stammpfad / liefert über Nginx eine 200-Antwort, wenn der Stack verfügbar ist. Verwenden Sie kein HTTPS für den Probe: Das Backend Setting verwendet HTTP innerhalb des 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. Dieser DNS-Name muss dem auf dem HTTPS-Listener installierten SSL-Zertifikat entsprechen.

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.