Azure Container Instance (ACI) — Instalación en Salesforce

Support DQE
Support DQE
  • Actualización

Nota: Todos los elementos descritos a continuación son recomendaciones de DQE, basadas en la experiencia de despliegue con distintos clientes.

El cliente es responsable de integrar la solución en su propia arquitectura.

Un arquitecto familiarizado con el contexto del cliente y la infraestructura interna debe alinear las recomendaciones de DQE con la infraestructura del cliente.

Como parte de la instalación, el enfoque se ha dockerizado y todos los componentes se despliegan en Docker:

  • Redis: se utiliza para el almacenamiento y procesamiento de datos.
  • RabbitMQ: programa las acciones realizadas por el motor de DQE.
  • La base de datos Redis se elimina después de cada proceso.

1. Arquitectura de despliegue

A continuación se detallan los intercambios entre el front end y el back end.

Para desplegar una instancia de la aplicación Unify Server en su organización de Azure, DQE-Software proporciona acceso dedicado al registro de contenedores. Existen varias formas de desplegar este contenedor, pero DQE recomienda utilizar una Azure Container Instance.

El procedimiento se explica en la sección de instalación.

Esto requiere la configuración de un Azure Gateway, u otro balanceador de carga, para exponer esta aplicación con una dirección IP pública y un DNS. De lo contrario, la organización de Salesforce donde se instala el paquete de interfaz de usuario no podrá acceder a la aplicación.

Para desplegar esta aplicación, debe crear un archivo de configuración YAML, que se detalla en este documento.

Diagrama de arquitectura de despliegue

2. Matriz de flujos

El siguiente diagrama describe todos los flujos que entran y salen de Azure Application Gateway en un proceso estándar de datos de Unify.

Todas las direcciones IP y puertos descritos en este diagrama deben estar abiertos en su gateway o firewall para que el proceso se complete. Todas las conexiones entrantes utilizan HTTPS.

Diagrama de la matriz de flujos

3. Conexiones con Salesforce

Autenticación

Cuando instala el paquete Unify-UI en su organización de Salesforce, debe completar varios pasos de configuración. Durante estos pasos, la organización de Salesforce se registra en Unify Server. En esta etapa, el servidor crea una contraseña única y credenciales de clave, que se almacenan en su organización y se utilizan para autenticarse en su instancia de Unify Server.

Diagrama de autenticación de Salesforce

El protocolo de seguridad utilizado por Salesforce para autenticar a los usuarios y permitir las operaciones realizadas por el paquete, como la importación y exportación masiva, es JSON Web Token (JWT).

Este JWT solo puede ser validado por Salesforce para los usuarios habilitados en la connected app instalada con el paquete Unify-UI.

Encontrará más información en la documentación oficial de Salesforce aquí.

Proceso

La siguiente sección describe los flujos entre Salesforce y el ACI Unify Server, y entre el ACI Unify Server y los servidores de DQE.

Paso 1: definir un nuevo proceso

Un usuario de Salesforce define un nuevo proceso.

Ejemplo de descripción de proceso:

  • Objeto: Person Account
  • Tipo de procesamiento: validación de email
  • Campo procesado: Email
  • Filtros: ver reglas de negocio.

Paso 2: iniciar el proceso

Un usuario de Salesforce inicia el proceso. Este usuario debe formar parte de los inicios de sesión autorizados en la configuración de la connected app.

Paso 3: enviar la solicitud de procesamiento

La solicitud de procesamiento se envía al ACI Unify Server.

Paso 4: autenticarse con Salesforce

El ACI Unify Server se autentica con Salesforce a través de la connected app utilizando un token JWT.

Paso 5: exportar datos

Salesforce permite al servidor realizar una exportación de datos.

Flujo de exportación de datos de Salesforce

Paso 6: guardar los datos exportados

El ACI Unify Server exporta los datos relevantes, como los campos Id y Email del objeto Person Account, y los guarda en Azure File Storage en formato CSV.

Paso 7: procesar los datos

Si el proceso es de calidad de datos: el ACI Unify Server realiza llamadas API unitarias anonimizadas para cada email del archivo extraído. Esto se aplica únicamente a la cualificación de email.

Durante todo el proceso, este es el único paso en el que se pueden enviar algunos datos mediante API REST a través de una conexión segura al servidor de producción de DQE-Software.

Si el proceso es de deduplicación: el ACI Unify Server calcula los grupos de duplicados y concilia los registros según las reglas de coincidencia definidas durante los talleres.

Paso 8: generar el archivo de resultados

El ACI Unify Server agrega todas las respuestas de procesamiento en un archivo CSV final.

Si el proceso es de deduplicación, el ACI Unify Server calcula el resultado de la fusión de datos dentro de los grupos de duplicados identificados. Este resultado se almacena en el campo DQE_Fusion_Json_c, creado para este fin en el objeto Lead, a la espera de ser utilizado si el proceso de fusión se activa automática o manualmente al final del procesamiento.

Flujo de generación del archivo de resultados

Paso 9: autenticarse en Salesforce

El ACI Unify Server se autentica en Salesforce.

Paso 10: permitir la importación o actualización

Salesforce permite al servidor realizar una importación o actualización de datos.

Paso 11: enviar los resultados del procesamiento

El ACI Unify Server envía los resultados del procesamiento a los registros correspondientes, por ejemplo Person Account, a través de las Bulk API expuestas por Salesforce. Los Person Accounts se enriquecen con campos creados para este fin, como el número del grupo de duplicados al que se ha asociado el registro y, en su caso, el campo que almacena el resultado de la fusión de ese grupo.

Paso 12: eliminar los archivos CSV

El ACI Unify Server elimina el archivo CSV recibido inicialmente durante la exportación en el paso 6 y el archivo CSV generado que contiene los resultados del paso 8.

Paso 13: enviar el informe de procesamiento

El ACI Unify Server envía un informe estadístico de procesamiento a Salesforce, que incluye el número de registros procesados y el tiempo de procesamiento. Este informe es visible en la aplicación Unify, en el objeto Runs.

Flujo del informe de procesamiento

4. Instalación

Esta sección describe el protocolo de instalación utilizado para crear una instancia de DQE Unify Server como Azure Container Instance.

También ofrece un ejemplo de cómo crear un Azure Application Gateway.

Esta parte depende en gran medida de la propia organización del cliente. El equipo técnico del cliente es responsable de aplicar las diferentes recomendaciones.

Para obtener más información sobre la configuración de un Azure Application Gateway, consulte la documentación de Microsoft aquí.

4.1. Crear un Application Gateway

4.1.1. Pestaña Basic

La primera pestaña muestra un formulario similar al siguiente. Rellene las distintas partes tal como se indica.

Pestaña básica de Application Gateway

4.1.1.1. Política WAF

El WAF (Web Application Firewall) se utiliza para definir los rangos de IP autorizados a llamar al Application Gateway, como los rangos de IP de Salesforce.

Cree una nueva política WAF desde el campo WAF policy en la 4.1.1. Pestaña Basic.

Configuración de la política WAF

4.1.1.2. VNET

La VNET (red virtual) se utiliza para conectar el Application Gateway y la ACI (Azure Container Instance). Todos los flujos pasan por esta red privada.

Cree una nueva VNET desde el campo Virtual network en la 4.1.1. Pestaña Basic.

Configuración de VNET

4.1.2. Frontends

La pestaña Frontends muestra un formulario similar al siguiente. Rellene las distintas partes tal como se indica.

Frontends de Application Gateway

4.1.2.1. Dirección IP pública

La dirección IP pública es expuesta por el Application Gateway y se utiliza para enrutar el tráfico hacia la ACI.

Cree una nueva IP pública desde el campo Public IP address en 4.1.2. Frontends.

Configuración de IP pública

4.1.3. Backends

La pestaña Backends muestra un formulario similar al siguiente. Rellene las distintas partes tal como se indica.

Backends de Application Gateway

4.1.3.1. Backend Pool

El backend pool permite al Application Gateway enrutar los flujos a través de la VNET hacia la ACI. Se rellena automáticamente durante el paso Network de la creación de la ACI.

Cree un nuevo backend pool desde Add a backend pool en 4.1.3. Backends.

Configuración del backend pool

4.1.4. Configuration

La pestaña Configuration muestra un formulario similar al siguiente. Rellene las distintas partes tal como se indica.

Configuración de Application Gateway

4.1.4.1. Routing Rules - Listener

Esta configuración permite las llamadas al Application Gateway a través de HTTPS.

Listener de reglas de enrutamiento

4.1.4.2. Routing Rules - Backend Target

El backend target es utilizado por el Application Gateway para determinar hacia dónde enrutar el tráfico entrante. Utiliza el backend pool creado previamente.

Backend target de las reglas de enrutamiento

4.1.4.3. Routing Rules - Backend Setting

El backend setting es utilizado por el Application Gateway para determinar qué protocolo utilizar al enrutar el tráfico hacia la ACI. Este tráfico se envía a través de la VNET privada.

Backend setting de las reglas de enrutamiento

A continuación, haga clic en Review + create.

4.2. Crear una Container Instance a partir de un archivo YAML

4.2.1. Añadir una subred VNET para la ACI

Cree una nueva subred delegada a Microsoft.ContainerInstance/containerGroups a partir de la VNET creada en 4.1.1.2. VNET.

Configuración de la subred de la ACI

4.2.2. Azure CLI

Se requiere Azure CLI en su equipo.

4.2.2.1. UNIX
sudo curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
4.2.2.2. Windows

Consulte la documentación de Microsoft aquí.

4.2.3. Crear una cuenta de almacenamiento

4.2.3.1. Pestaña Basics

Pestaña básica de la cuenta de almacenamiento

4.2.3.2. Advanced

Nada que cambiar.

4.2.3.3. Networking

Pestaña de redes de la cuenta de almacenamiento

4.2.3.4. Data Protection

Nada que cambiar.

4.2.3.5. Encryption

Nada que cambiar.

4.2.3.6. Tags

Nada que cambiar.

4.2.3.7. Review + Create

Cree la cuenta de almacenamiento.

4.2.4. Crear file shares

El contenedor requiere tres file shares:

  • rabbitvol
  • nginxconf
  • redisvol

Creación de file shares

Para utilizar HTTPS en la ACI, se aprovisiona Nginx. Para garantizar que Nginx dispone de toda la información necesaria, añada los siguientes archivos al file share nginxconf:

  • El archivo de certificado SSL .pem o .crt.
  • El archivo de clave SSL .key.
  • Si el archivo .pem tiene contraseña, añada la contraseña en un archivo de texto y cárguelo en el file share.
  • El archivo default.conf definido en 4.2.8. Configurar Nginx.

4.2.5. Crear un Log Analytics Workspace

El Log Analytics Workspace se utiliza para almacenar todos los registros de la ACI. Por defecto, los registros se almacenan durante 30 días.

4.2.5.1. Pestaña Basics

Pestaña básica de Log Analytics

4.2.5.2. Review + Create

Cree el Log Analytics Workspace.

4.2.5.3. Obtener el ID y la clave del workspace

ID y clave del workspace de Log Analytics

4.2.6. Archivo de configuración YAML de la ACI

En su máquina local, cree un archivo YAML. El archivo de configuración YAML se proporciona a continuación.

Debe completar las siguientes claves:

  • 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>, disponible en 4.2.5.3. Obtener el ID y la clave del workspace.
  • diagnostics.logAnalytics.workspaceKey: <Log Analytics Workspace Key>, disponible en 4.2.5.3. Obtener el ID y la clave del workspace.
  • Todos los valores <file share name>, <storage account name> y <storage account key>.

Ejemplo con la cuenta de almacenamiento y el file share creados previamente:

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

Ejemplo:

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. Crear la ACI

En su máquina local, abra una línea de comandos e inicie sesión en Azure con Azure CLI:

az login

Cree la ACI a partir del archivo YAML:

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

Una vez completada la operación, debería ver la siguiente información:

Resultado de la creación de la ACI

4.2.8. Configurar Nginx

Cree un archivo default.conf con el siguiente contenido. Esta configuración se utiliza para la conexión HTTP entre el gateway y la ACI a través de la subred privada.

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;
}
}

Cargue este archivo en el file share nginxconf creado previamente.

Advertencia: reinicie la ACI para que Nginx se actualice con el último cambio.

4.3. Configurar el Backend Pool del Application Gateway

Una vez creada la ACI, vaya a Application Gateway > Backend Pool > su backend pool > Edit backend pool.

Añada la dirección IP privada de la ACI creada.

Configuración del backend pool de Application Gateway

4.4. Configurar el Health Probe del Application Gateway

El health probe es utilizado por el Application Gateway para comprobar frecuentemente si la API de la ACI está activa. Configure el health probe y, a continuación, haga clic en Test. Si el estado es Healthy, la ACI está correctamente configurada e iniciada.

Añada un health probe desde el Application Gateway:

Configuración del health probe de Application Gateway

Haga clic en Test > Add.

4.4.1. Configurar el DNS

Contacte con sus administradores, o con cualquier persona que tenga acceso a la zona DNS, y pídales que añadan un nombre DNS que apunte a la IP pública de su Application Gateway.

4.4.2. Configuración del WAF

El WAF se utiliza para autorizar o bloquear direcciones IP específicas que intenten llamar al Application Gateway. Para que los procesos de Salesforce funcionen, el WAF debe autorizar los rangos de IP de Salesforce.

Configuración del WAF

En el WAF, haga clic en Switch to prevention mode. Esto permite que el WAF utilice las reglas personalizadas siguientes.

Modo de prevención del WAF

En las reglas personalizadas, añada:

  • Los rangos de direcciones IP de Salesforce, incluidos los rangos básicos y de Hyperforce.
  • Servidor de licencias de DQE check: consulte con soporte.
  • SF Automation 1: consulte con soporte.
  • SF Automation 2: consulte con soporte.

Reglas personalizadas del WAF

Puede encontrar la lista exhaustiva de direcciones IP de Salesforce aquí.

Tras completar estos pasos, verifique su despliegue tal como se describe en 4.4. Configurar el Health Probe del Application Gateway.

Relacionada con

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 0 de 0