Azure Container Instance (ACI) — Salesforce-Installation

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

Der Kunde ist dafür verantwortlich, die Lösung in seine eigene Architektur zu integrieren.

Ein Architekt, der mit dem Kundenkontext und der internen Infrastruktur vertraut ist, 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: wird zur Datenspeicherung und -verarbeitung verwendet.
• RabbitMQ: plant die vom DQE-Engine ausgeführten Aktionen.
• Die Redis-Datenbank wird nach jedem Prozess gelöscht.

1. Bereitstellungsarchitektur

Der Datenaustausch zwischen Frontend und Backend wird im Folgenden 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 mehrere Möglichkeiten, diesen Container bereitzustellen, DQE empfiehlt jedoch die Verwendung einer Azure Container Instance.

Das Vorgehen wird im Abschnitt Installation erläutert.

Hierfür ist die Konfiguration eines Azure Gateway oder eines anderen Load Balancers erforderlich, um diese Anwendung mit einer öffentlichen IP-Adresse und DNS verfügbar zu machen. Andernfalls kann die Salesforce-Organisation, in der das Benutzeroberflächenpaket installiert ist, 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

Das folgende Diagramm beschreibt alle ein- und ausgehenden Datenflüsse des Azure Application Gateway in einem Standard-Unify-Datenprozess.

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 mehrere Konfigurationsschritte durchführen. Während dieser Schritte registriert sich die Salesforce-Organisation beim Unify Server. In diesem Schritt erstellt der Server ein eindeutiges Passwort und Schlüsselanmeldedaten, die in Ihrer Organisation gespeichert und zur Authentifizierung bei Ihrer Unify Server-Instanz verwendet werden.

Das von Salesforce verwendete Sicherheitsprotokoll zur Authentifizierung von Benutzern und zur Zulassung der vom Paket durchgeführten Vorgänge, wie z. B. Massenimport und -export, ist JSON Web Token (JWT).

Dieses JWT kann von Salesforce nur für 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.

Prozess

Der folgende Abschnitt beschreibt die Datenflüsse zwischen Salesforce und dem ACI Unify Server sowie zwischen dem ACI Unify Server und den DQE-Servern.

Schritt 1 – Einen neuen Prozess definieren

Ein Salesforce-Benutzer definiert einen neuen Prozess.

Beispielhafte Prozessbeschreibung:

• Objekt: Person Account
• Verarbeitungstyp: 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-Konfiguration gehören.

Schritt 3 – Die Verarbeitungsanfrage senden

Die Verarbeitungsanfrage wird an den ACI Unify Server gesendet.

Schritt 4 – Bei Salesforce authentifizieren

Der ACI 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 ACI Unify Server exportiert die relevanten Daten, wie z. B. 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 Data-Quality-Verarbeitung handelt: Der ACI 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, in 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 ACI Unify Server berechnet Duplikatgruppen und gleicht Datensätze gemäß den während der Workshops definierten Abgleichsregeln ab.

Schritt 8 – Die Ergebnisdatei generieren

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

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

Schritt 9 – Bei Salesforce authentifizieren

Der ACI 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 ACI Unify Server sendet die Verarbeitungsergebnisse über die von Salesforce bereitgestellten Bulk-APIs an die relevanten Datensätze, zum Beispiel Person Account. Person Accounts werden mit eigens dafür erstellten Feldern angereichert, wie z. B. der Nummer der Duplikatgruppe, der der Datensatz zugeordnet wurde, und gegebenenfalls dem Feld, das das Zusammenführungsergebnis dieser Gruppe speichert.

Schritt 12 – CSV-Dateien löschen

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

Schritt 13 – Den Verarbeitungsbericht senden

Der ACI 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.

4. Installation

Dieser Abschnitt beschreibt das Installationsprotokoll zur Erstellung einer Instanz des DQE Unify Server als Azure Container Instance.

Er enthält außerdem ein Beispiel für die Erstellung eines Azure Application Gateway.

Dieser Teil hängt stark von der jeweiligen Organisation des Kunden ab. Das technische Team des Kunden ist dafür verantwortlich, die verschiedenen Empfehlungen umzusetzen.

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

4.1. Ein Application Gateway erstellen

4.1.1. Basics-Tab

Der erste Tab zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.

4.1.1.1. WAF-Richtlinie

Die WAF (Web Application Firewall) wird verwendet, um die IP-Bereiche festzulegen, die zum Aufruf des Application Gateway berechtigt sind, z. B. die Salesforce-IP-Bereiche.

Erstellen Sie eine neue WAF über das Feld WAF policy im 4.1.1. Basics-Tab.

4.1.1.2. VNET

Das VNET (Virtual Network) wird verwendet, um das Application Gateway und die ACI (Azure Container Instance) zu verbinden. Alle Datenflüsse laufen über dieses private Netzwerk.

Erstellen Sie ein neues VNET über das Feld Virtual network im 4.1.1. Basics-Tab.

4.1.2. Frontends

Der Tab Frontends zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.

4.1.2.1. Öffentliche IP-Adresse

Die öffentliche IP-Adresse wird vom Application Gateway bereitgestellt und dient dazu, den Datenverkehr zur ACI weiterzuleiten.

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

4.1.3. Backends

Der Tab Backends zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.

4.1.3.1. Backend Pool

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

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

4.1.4. Configuration

Der Tab Configuration zeigt ein Formular ähnlich dem unten stehenden. Füllen Sie die verschiedenen Felder wie dargestellt aus.

4.1.4.1. Routingregeln – Listener

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

4.1.4.2. Routingregeln – Backend Target

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

4.1.4.3. Routingregeln – Backend Setting

Das Backend Setting wird vom Application Gateway verwendet, um zu bestimmen, welches Protokoll beim Weiterleiten des Datenverkehrs an die ACI verwendet wird. Dieser Datenverkehr wird über das private VNET gesendet.

Klicken Sie anschließend auf Review + create.

4.2. Eine Container Instance aus einer YAML-Datei erstellen

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

Erstellen Sie ein neues Subnetz, das Microsoft.ContainerInstance/containerGroups zugeordnet ist, ausgehend von dem in 4.1.1.2. VNET erstellten VNET.

4.2.2. Azure CLI

Die 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. Ein Speicherkonto erstellen

4.2.3.1. Basics-Tab

4.2.3.2. Advanced

Nichts zu ändern.

4.2.3.3. Networking

4.2.3.4. Data Protection

Nichts zu ändern.

4.2.3.5. Encryption

Nichts zu ändern.

4.2.3.6. Tags

Nichts zu ändern.

4.2.3.7. Review + Create

Erstellen Sie das Speicherkonto.

4.2.4. Dateifreigaben erstellen

Der Container benötigt drei Dateifreigaben:

• rabbitvol
• nginxconf
• redisvol

Um HTTPS auf der ACI zu verwenden, wird Nginx bereitgestellt. Fügen Sie der Dateifreigabe nginxconf die folgenden Dateien hinzu:

• Die SSL-Zertifikatsdatei .pem oder .crt. Sie muss zuerst das Serverzertifikat und anschließend die Zwischenzertifikate enthalten. Eine umgekehrte Reihenfolge verhindert den Start von Nginx (Fehler key values mismatch).
• Die SSL-Schlüsseldatei .key, die zum ersten Zertifikat in der Datei passen muss.
• Falls der Schlüssel passwortgeschützt ist, eine Textdatei mit dem Passwort.
• Die in 4.2.8 definierte Datei default.conf.

Prüfen Sie vor dem Hochladen, ob Zertifikat und Schlüssel zusammenpassen (beide Ergebnisse müssen identisch sein):

openssl x509 -in <Zertifikat> -noout -pubkey | openssl md5
openssl pkey -in <Schluessel> -pubout | openssl md5

Wichtig: Salesforce prüft das vom Server präsentierte Zertifikat: anerkannte Zertifizierungsstelle, vollständige Zertifikatskette und Gültigkeitsdatum. Erneuern Sie das Zertifikat vor Ablauf und starten Sie die ACI nach jedem Austausch neu.

4.2.5. Einen Log Analytics Workspace erstellen

Der Log Analytics Workspace wird verwendet, um alle Logs der ACI zu speichern. Standardmäßig werden die Logs 30 Tage lang aufbewahrt.

4.2.5.1. Basics-Tab

4.2.5.2. Review + Create

Erstellen Sie den Log Analytics Workspace.

4.2.5.3. Workspace-ID und -Schlüssel abrufen

4.2.6. YAML-Konfigurationsdatei der ACI

Erstellen Sie auf Ihrem lokalen Rechner eine YAML-Datei. Die YAML-Konfigurationsdatei finden Sie unten.

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

• name: <Container Group Name>
• location: <Location>
• imageRegistryCredentials.username: <Username provided by DQE>
• imageRegistryCredentials.password: <Password provided by DQE>
• diagnostics.logAnalytics.workspaceId: <Log Analytics Workspace ID>, verfügbar über 4.2.5.3. Workspace-ID und -Schlüssel abrufen.
• diagnostics.logAnalytics.workspaceKey: <Log Analytics Workspace Key>, verfügbar über 4.2.5.3. Workspace-ID und -Schlüssel abrufen.
• Alle Werte für <file share name>, <storage account name> und <storage account key>.

Beispiel mit dem zuvor erstellten Speicherkonto und der Dateifreigabe:

• <file share name> = redisvol
• <storage account name> = myaccountstoragename
• <storage account key> = verfügbar über Storage account > Access keys > Show keys.
• id: subscriptions/{subscriptionsId}/resourceGroups/{resourceGroupsName}/providers/Microsoft.Network/virtualNetworks/{VNETName}/subnets/{VNETSubnetsName}

Beispiel:

# =============================================================================
#  Unify sur Azure Container Instances (groupe privé dans un VNet, Nginx en frontal)
#  Déploiement : az container create -g <rg> --file aci-unify.yaml
#
#  Rappel ACI : tous les conteneurs du groupe partagent le même réseau -> 127.0.0.1
# =============================================================================
name: <Container Group Name>
apiVersion: '2023-05-01'
location: <Location>
properties:
  osType: Linux
  restartPolicy: Always

  containers:
    # ------------------------------------------------------------------ Redis
    - name: redis
      properties:
        image: <ImageURL>
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.5
        volumeMounts:
          - name: redisvol
            mountPath: /data

    # --------------------------------------------------------------- RabbitMQ
    # Image officielle (comme dans le docker-compose) : variables RABBITMQ_DEFAULT_*.
    # Si l'image est Bitnami : variables RABBITMQ_USERNAME / RABBITMQ_PASSWORD /
    # RABBITMQ_VHOST et montage sur /bitnami/rabbitmq/mnesia.
    - name: rabbitmq
      properties:
        image: <ImageURL>
        environmentVariables:
          - name: RABBITMQ_DEFAULT_USER
            value: guest
          - name: RABBITMQ_DEFAULT_PASS
            secureValue: <RabbitMQ password>
          - name: RABBITMQ_DEFAULT_VHOST
            value: admin
          - name: RABBITMQ_NODENAME          # nom de nœud stable => données retrouvées après recréation
            value: rabbit@localhost
        resources:
          requests:
            memoryInGB: 1
            cpu: 1
        volumeMounts:
          # Uniquement mnesia : le .erlang.cookie (chmod 400) ne peut pas vivre sur un partage SMB
          - name: rabbitvol
            mountPath: /var/lib/rabbitmq/mnesia

    # ------------------------------------------------------------------ Nginx
    # La conf (conf.d) doit viser 127.0.0.1:8000 et 127.0.0.1:8001
    - name: nginx
      properties:
        image: <ImageURL>
        ports:
          - protocol: TCP
            port: 80
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.25
        volumeMounts:
          - name: nginxconf
            mountPath: /etc/nginx/conf.d
            readOnly: true

    # --------------------------------------------------------------- Unify UI
    - name: unify-ui
      properties:
        image: <ImageURL>
        command: ["npm", "start"]
        environmentVariables:
          - name: SESSION_SECRET
            secureValue: <Session secret>
          - name: PORT
            value: '8001'
        resources:
          requests:
            memoryInGB: 1
            cpu: 0.25

    # ------------------------------------------------------------- One server
    - name: one-server
      properties:
        image: <ImageURL>
        # ACI n'a pas de depends_on : on attend Redis et RabbitMQ avant de lancer l'entrypoint
        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"
        environmentVariables:
          - name: SFAPIVERSION
            value: v59.0                     # v65.0 dans le docker-compose : à aligner
          - name: PORT
            value: '8000'
          - name: REDIS_URL
            value: redis://127.0.0.1:6379
          - name: CLOUDAMQP_URL
            secureValue: amqp://guest:<RabbitMQ password>@127.0.0.1:5672/admin
          - name: CUSTOMUI
            value: http://127.0.0.1:8001
          - name: UNIFYSERVERURL
            value: http://127.0.0.1:8000     # URL Nginx si utilisée par un navigateur / callback
        resources:
          requests:
            memoryInGB: 2
            cpu: 1

    # ----------------------------------------------------------- Queue worker
    - name: queue-worker
      properties:
        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-web; sleep 3; done; exec python -u ./unify/queue_worker.pyc"
        environmentVariables:
          - name: SFAPIVERSION
            value: v59.0
          - name: WORKDIRPATH
            value: /app/unify
          - name: REDIS_URL
            value: redis://127.0.0.1:6379
          - name: CLOUDAMQP_URL
            secureValue: amqp://guest:<RabbitMQ password>@127.0.0.1:5672/admin
        resources:
          requests:
            memoryInGB: 5
            cpu: 1

  imageRegistryCredentials:
    - server: <Registry server>   # nom d'hôte seul (ex. xxx.azurecr.io), pas l'URL complète de l'image
      username: <Username provided by DQE>
      password: <Password provided by DQE>

  diagnostics:
    logAnalytics:
      workspaceId: <Log Analytics Workspace Id>
      workspaceKey: <Log Analytics Workspace Key>
      logType: ContainerInstanceLogs

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

  subnetIds:
    # Le chemin doit commencer par "/" ; sous-réseau délégué à Microsoft.ContainerInstance/containerGroups
    - id: /subscriptions/<subscriptionId>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/subnets/<subnet>

  # Un partage Azure Files DISTINCT par volume
  volumes:
    - name: redisvol
      azureFile:
        shareName: <redis-share>
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>
    - name: rabbitvol
      azureFile:
        shareName: <rabbitmq-share>
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>
    - name: nginxconf
      azureFile:
        shareName: <nginx-conf-share>
        readOnly: true
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>

4.2.7. Die ACI erstellen

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

az login

Erstellen Sie die ACI aus der YAML-Datei:

az container create -g <your Resource Group Name> -f <.yaml file path>

Nach Abschluss des Vorgangs sollten Sie die folgenden Informationen sehen:

4.2.8. Nginx konfigurieren

Erstellen Sie eine Datei default.conf mit folgendem Inhalt. Diese Konfiguration wird für die HTTP-Verbindung zwischen dem Gateway und der ACI über das private Subnetz verwendet.

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 Dateifreigabe nginxconf hoch.

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

4.3. Den Backend Pool des Application Gateway einrichten

Nachdem die ACI erstellt wurde, navigieren Sie zu Application Gateway > Backend Pool > your backend pool > Edit backend pool.

Fügen Sie die private IP-Adresse Ihrer erstellten ACI hinzu.

4.4. Den Application Gateway Health Probe einrichten

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

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

Klicken Sie auf Test > Add.

4.4.1. DNS einrichten

Wenden Sie sich an Ihre Administratoren oder an jede Person mit Zugriff auf die DNS-Zone, und bitten Sie diese, einen DNS-Namen hinzuzufügen, der auf die öffentliche IP-Adresse Ihres Application Gateway verweist.

4.4.2. WAF-Konfiguration

Die WAF wird verwendet, um bestimmte IP-Adressen, die versuchen, das Application Gateway aufzurufen, zuzulassen oder zu blockieren. Damit Salesforce-Prozesse funktionieren, muss die WAF die Salesforce-IP-Bereiche zulassen.

Klicken Sie in der WAF auf Switch to prevention mode. Dadurch kann die WAF die unten stehenden benutzerdefinierten Regeln verwenden.

Fügen Sie in den benutzerdefinierten Regeln hinzu:

• Salesforce-IP-Adressbereiche, einschließlich der Basic- und Hyperforce-Bereiche.
• DQE-Lizenzprüfserver: fragen Sie den Support.
• SF Automation 1: fragen Sie den Support.
• SF Automation 2: fragen Sie den Support.

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

Nachdem Sie diese Schritte abgeschlossen haben, überprüfen Sie Ihre Bereitstellung wie in 4.4. Den Application Gateway Health Probe einrichten beschrieben.