Azure Container Instance (ACI) — Salesforce-Installation

Support DQE
Support DQE
  • Aktualisiert

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.

AzureACISF

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.

FlowMatrix

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.

Salesforce-Authentifizierungsdiagramm

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.

Salesforce-Datenexportfluss

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.

Ablauf der Ergebnisdateierstellung

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.

Ablauf des Verarbeitungsberichts

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.

Application Gateway Basics-Tab

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.

WAF-Richtlinienkonfiguration

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.

VNET-Konfiguration

4.1.2. Frontends

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

Application Gateway Frontends

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.

Konfiguration der öffentlichen IP

4.1.3. Backends

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

Application Gateway Backends

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.

Backend-Pool-Konfiguration

4.1.4. Configuration

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

Application Gateway Configuration

4.1.4.1. Routingregeln – Listener

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

Routingregeln Listener

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.

Routingregeln Backend Target

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.

Routingregeln Backend Setting

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.

ACI-Subnetzkonfiguration

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

Speicherkonto Basics-Tab

4.2.3.2. Advanced

Nichts zu ändern.

4.2.3.3. Networking

Speicherkonto Networking-Tab

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

Erstellung der Dateifreigaben

Um HTTPS auf der ACI zu verwenden, wird Nginx bereitgestellt. Damit Nginx über alle erforderlichen Informationen verfügt, fügen Sie der Dateifreigabe nginxconf die folgenden Dateien hinzu:

  • Die SSL-Zertifikatsdatei .pem oder .crt.
  • Die SSL-Schlüsseldatei .key.
  • Falls die .pem-Datei ein Passwort hat, fügen Sie das Passwort in einer Textdatei hinzu und laden Sie diese in die Dateifreigabe hoch.
  • Die Datei default.conf, die in 4.2.8. Nginx konfigurieren definiert ist.

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

Log Analytics Basics-Tab

4.2.5.2. Review + Create

Erstellen Sie den Log Analytics Workspace.

4.2.5.3. Workspace-ID und -Schlüssel abrufen

Log Analytics Workspace-ID und -Schlüssel

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:

name: <Container Group Name>  # Name of the container group
apiVersion: '2021-10-01'
location: <Location>
tags: {"docker-compose-application": "docker-compose-application"}
properties: # Properties of container group
  containers: # Array of container instances in the group
    # Redis Image configuration
    - name: redis
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.5
        volumeMounts: # Array of volume mounts for the instance
          -   name: redisvol
              mountPath: /data

    # RabbitMQ Image configuration
    - name: rabbitmq # Name of an instance
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 5672
        environmentVariables:
          -   name: RABBITMQ_DEFAULT_PASS
              value: guest
          -   name: RABBITMQ_DEFAULT_USER
              value: guest
          -   name: RABBITMQ_DEFAULT_VHOST
              value: admin

        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 1
        volumeMounts: # Array of volume mounts for the instance
          -   name: "rabbitvol"
              mountPath: /bitnami
              readOnly: false

    # Nginx Image configuration
    - name: nginx
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 80
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.25
        volumeMounts: # Array of volume mounts for the instance
          -   name: nginxconf
              mountPath: /etc/nginx/conf.d

    # Unify UI web server Image configuration
    - name: unify-ui
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        command:
          - "npm"
          - "start"
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 8001
        environmentVariables:
          -   name: SESSION_SECRET
              value: myveryimportantSecret
          -   name: PORT
              value: 8001
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.25

    # Unify web server Image configuration
    - name: one-server
      properties: # Properties of an instance
        image: <ImageURL>  # Container image used to create the instance
        command:
          - "bash"
          - "./entrypoint.sh"
        ports: # External-facing ports exposed on the instance, must also be set in group ipAddress property
          -   protocol: TCP
              port: 8000
        environmentVariables:
          -   name: SFAPIVERSION 
              value: v59.0
          -   name: REDIS_URL
              value: redis://127.0.0.1:6379
          -   name: CLOUDAMQP_URL
              value: amqp://guest:guest@127.0.0.1:5672/admin
          -   name: CUSTOMUI
              value: http://127.0.0.1:8001
          -   name: UNIFYSERVERURL
              value: http://127.0.0.1:8000
          -   name: PORT
              value: 8000
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 1
            cpu: 0.25

    # Unify Worker Image configuration
    - name: queue-worker
      properties: # Properties of an instance
        image: <ImageURL> # Container image used to create the instance
        command:
          - "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
              value: amqp://guest:guest@127.0.0.1:5672/admin
        resources: # Resource requirements of the instance
          requests:
            memoryInGB: 5
            cpu: 1

  # Credential to pull the Unify image from private container
  imageRegistryCredentials:
    - server: <ImageURL>
      username: <Username provide by DQE>
      password: <Password provide by DQE>

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

  restartPolicy: Always
  ipAddress: # IP address configuration of container group
    ports:
      - protocol: TCP
        port: 80
    type: Private
  osType: Linux

  # Volumes parametre (azure fileshared)
  volumes: # Array of volumes available to the instances
    - name: rabbitvol
      azureFile:
        shareName: <file share name>
        readOnly: false
        storageAccountName: <storage account name>
        storageAccountKey: <storage account key>

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

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


  subnetIds: # Subnet to deploy the container group into
    - id: subscriptions/{subscriptions Id}/resourceGroups/{resourceGroupsName}/providers/Microsoft.Network/virtualNetworks/{VNETName}/subnets/{VNETSubnetsName}

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:

Ergebnis der ACI-Erstellung

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.

Einrichtung des Application Gateway Backend Pool

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:

Einrichtung des Application Gateway Health Probe

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.

WAF-Konfiguration

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

WAF-Präventionsmodus

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.

Benutzerdefinierte WAF-Regeln

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.

Verknüpfung mit

War dieser Beitrag hilfreich?

0 von 0 fanden dies hilfreich