VM Windows — Instalación de Salesforce

1. Arquitectura

La aplicación y todas sus dependencias se compilan en imágenes Docker.

En cuanto los contenedores se despliegan en una instancia de Windows Server, la aplicación se empareja con una organización de Microsoft Dynamics 365 que tiene instalado el paquete DQE Unify.

Este documento describe la configuración para desplegar DQE Unify Server en una máquina virtual Windows Server 2022 mediante Docker Compose ejecutándose dentro de WSL2 (Windows Subsystem for Linux 2).

Diagrama de flujo

El siguiente diagrama describe todos los flujos entrantes/salientes, así como las IP y los puertos requeridos por la aplicación.

Medidas de seguridad

No podemos proporcionar un ejemplo de cómo implementar la capa de seguridad que se adapte perfectamente a su arquitectura. Sin embargo, podemos ofrecer algunas recomendaciones relevantes para el uso de la propia aplicación.

• Protocolos y puertos: Todos los flujos entrantes/salientes de la aplicación pasan por el protocolo HTTPS (puerto 443). No es necesario abrir ningún otro puerto en su VM. Las IP de DQE que deben ser accesibles se describen en el diagrama anterior.
• Filtrado de IP: El propio servidor de aplicaciones solo necesita ser accesible desde los servidores de Microsoft Dynamics 365. Por lo tanto, se recomienda configurar un filtrado de las IP entrantes. Consulte la lista completa de rangos de IP de Azure en: https://www.microsoft.com/en-us/download/details.aspx?id=56519
• Protocolo de autenticación: Al configurar la Connected App de DQE Unify en su organización de Dynamics 365, podrá seleccionar el método de autenticación y configurar el firewall de su aplicación en consecuencia.

Si la VM está expuesta directamente a internet, debe tener una entrada DNS y un certificado SSL asociado que apunten a ella.

Si la VM no está expuesta directamente a internet, esto generalmente significa que el tráfico se enruta a través de un componente como un gateway o un balanceador de carga. En este caso, el DNS y el certificado SSL deben instalarse en ese gateway, que luego reenviará el tráfico a la VM interna.

Recomendación

En esta sección, describimos la lista de componentes necesarios para instalar la instancia de DQE Unify Server en una VM Windows Server.

Nota: Las estimaciones se basan en 1 millón de registros. Según el volumen de las bases de datos procesadas, puede ser necesario aumentar la capacidad de memoria de las instancias de contenedor para optimizar los tiempos de procesamiento.

Despliegue con VM Windows Server:

• Tipo de servidor: Windows Server 2022 (64 bits).
• Runtime de contenedores: Docker CE ejecutándose dentro de WSL2 (Ubuntu) — necesario porque Docker CE en Windows Server no puede ejecutar contenedores Linux de forma nativa.
• Balanceador de carga: No es obligatorio, pero puede utilizarse si ya está disponible.

Requisitos de hardware:

Composición y servicios

El stack está compuesto por imágenes Docker orquestadas mediante Docker Compose. Cada servicio se ejecuta como un contenedor. Los servicios se comunican entre sí a través de su nombre de servicio en la red interna de Docker.

Web Application (unify-server)

Un contenedor backend que contiene una aplicación de microservicios. Esta aplicación expone todas las API llamadas para lanzar procesos, gestionar las colas de procesamiento e instanciar los workers de procesamiento. Depende de Redis y RabbitMQ para funcionar correctamente. Este servicio se expone en la web a través del reverse proxy Nginx.

Configuración de Docker Compose

• image: el nombre de la imagen alojada en el Azure Container Registry de DQE:

  <registry-url>/unify-server-web-ms-dynamics:v3.0

• depends_on: rabbitmq (healthy), redis (started)
• environment: REDIS_URL, CLOUDAMQP_URL, PORT
• command: python app.pyc — la imagen contiene bytecode Python compilado, no archivos fuente.

Worker (queue-worker)

Un contenedor backend que procesa las tareas en cola de forma asíncrona. Consume tareas de la cola de RabbitMQ y las ejecuta. Utiliza la misma imagen Docker que la web application.

Parámetros a configurar en Docker Compose

• image: la misma imagen que el servicio web application
• depends_on: rabbitmq (healthy), redis (started)
• environment: REDIS_URL, CLOUDAMQP_URL
• command: python queue_worker.pyc

Nginx

Un reverse proxy que reenvía las solicitudes HTTP/HTTPS entrantes hacia el Unify Server en el puerto 8000. Su archivo de configuración se almacena en el sistema de archivos de Windows (C:\dqe-unify\nginxconf\default.conf) y se monta en el contenedor a través de la ruta WSL2 (/mnt/c/dqe-unify/nginxconf).

• image: nginx:latest
• ports: 80:80, 443:443
• volume: /mnt/c/dqe-unify/nginxconf:/etc/nginx/conf.d:ro

Redis

Una base de datos clave/valor utilizada para almacenar claves de funcionamiento interno, como las configuraciones de la organización de Dynamics 365, las sesiones, etc.

Se utiliza la imagen oficial redis:alpine. Los datos se persisten en un volumen con nombre de Docker almacenado en el sistema de archivos Linux de WSL2 — no se utilizan bind mounts en el sistema de archivos NTFS de Windows porque no admiten los permisos de archivo requeridos por Redis.

Parámetros

• image: redis:alpine
• volumes: redis-data:/data (volumen con nombre de Docker)

RabbitMQ

Un gestor de colas que permite la recepción y planificación de las solicitudes de procesamiento. Hasta que un proceso se asigne a un worker y se complete, permanecerá en la cola. Esto también proporciona resiliencia ante fallos: si se reinicia el servidor, se retoma el último procesamiento de la cola donde se dejó.

Se utiliza la imagen oficial rabbitmq:3.13-management. Los datos se persisten en un volumen con nombre de Docker. Las credenciales se establecen mediante variables de entorno.

Parámetros

• image: rabbitmq:3.13-management
• volumes: rabbitmq-data:/var/lib/rabbitmq (volumen con nombre de Docker)
• environment: RABBITMQ_DEFAULT_USER=user, RABBITMQ_DEFAULT_PASS=bitnami

2. Instalación

Todos los pasos de instalación se realizan en la VM Windows Server. Los pasos marcados como [PowerShell] deben ejecutarse en PowerShell como Administrador. Los pasos marcados como [WSL2] deben ejecutarse en la terminal Ubuntu de WSL2.

2.1 Requisito previo

Conéctese a la VM Windows Server utilizando una de las opciones de conexión disponibles (RDP, Azure Bastion, etc.) y abra PowerShell como Administrador.

Cree la estructura de directorios de la aplicación desde PowerShell:

New-Item -ItemType Directory -Path "C:\dqe-unify"
New-Item -ItemType Directory -Path "C:\dqe-unify\nginxconf"

Instalación de WSL2 [PowerShell]

Habilite las funciones de Windows necesarias:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Enable-WindowsOptionalFeature -Online -FeatureName Containers -All -NoRestart

/!\ Se requiere reiniciar — Reinicie la VM después de habilitar estas funciones antes de continuar.

Después de reiniciar, abra PowerShell como Administrador e instale Ubuntu:

wsl --set-default-version 2
wsl --install -d Ubuntu

Se abrirá una terminal solicitándole crear un nombre de usuario y una contraseña de Unix. Complete la configuración antes de continuar.

Instalación de Docker y Docker Compose [WSL2]

Abra la terminal Ubuntu de WSL2 y ejecute:

curl -fsSL https://get.docker.com | sudo sh

Nota: El script detecta WSL y recomienda Docker Desktop — ignore el mensaje y espere 20 segundos a que la instalación continúe automáticamente. Docker Compose está incluido en esta instalación.

Añada su usuario al grupo docker e inicie el servicio:

sudo usermod -aG docker $USER
sudo service docker start

Cierre y vuelva a abrir la terminal WSL2, y luego verifique:

docker --version
docker compose version

Nota: El servicio Docker debe iniciarse manualmente cada vez que se abre la sesión de WSL2: sudo service docker start

Instalación de Azure CLI [WSL2]

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

Configuración de Nginx [PowerShell]

Nginx se ejecuta como un contenedor — no hay instalación a nivel de host. Solo necesita crear el archivo de configuración. Ábralo en el Bloc de notas desde PowerShell:

notepad C:\dqe-unify\nginxconf\default.conf

Pegue el siguiente contenido y guarde:

server {
    listen 80;

    location / {
        proxy_pass         http://unify-server: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_read_timeout 300s;
    }
}

Nota: A diferencia de la versión ACI, donde Nginx apunta a localhost:8000, en Docker Compose los servicios se comunican mediante su nombre de servicio — el destino del proxy es http://unify-server:8000.

Para HTTPS, añada un segundo bloque server:

server {
    listen 443 ssl;
    server_name <your-domain.com>;

    ssl_certificate     /etc/nginx/ssl/cert.crt;
    ssl_certificate_key /etc/nginx/ssl/cert.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    location / {
        proxy_pass         http://unify-server: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_read_timeout 300s;
    }
}

2.2 Windows Unify Server — docker-compose.yml

Cree el archivo C:\dqe-unify\docker-compose.yml con el contenido siguiente usando el Bloc de notas. Sustituya <registry-url> por la URL proporcionada por DQE Software.

Nota: A diferencia de la versión ACI, los servicios de Docker Compose se comunican mediante nombres de servicio (redis, rabbitmq), no mediante localhost. Las variables de entorno se configuran en consecuencia.

services:

  # ── Redis ─────────────────────────────────────────────────────────
  redis:
    image: redis:alpine
    platform: linux/amd64
    restart: always
    volumes:
      - redis-data:/data
    networks:
      - unify-net

  # ── RabbitMQ ──────────────────────────────────────────────────────
  rabbitmq:
    image: rabbitmq:3.13-management
    platform: linux/amd64
    restart: always
    ports:
      - "5672:5672"
    volumes:
      - rabbitmq-data:/var/lib/rabbitmq
    environment:
      - RABBITMQ_DEFAULT_USER=user
      - RABBITMQ_DEFAULT_PASS=bitnami
    networks:
      - unify-net
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "ping"]
      interval: 30s
      timeout: 10s
      retries: 5

  # ── Nginx reverse proxy ───────────────────────────────────────────
  nginx:
    image: nginx:latest
    platform: linux/amd64
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /mnt/c/dqe-unify/nginxconf:/etc/nginx/conf.d:ro
    depends_on:
      - unify-server
    networks:
      - unify-net

  # ── Unify Server (web) ────────────────────────────────────────────
  unify-server:
    image: <registry-url>/unify-server-web-ms-dynamics:v3.0
    restart: always
    command: ["python", "app.pyc"]
    ports:
      - "8000:8000"
    environment:
      - REDIS_URL=redis://redis:6379
      - CLOUDAMQP_URL=amqp://user:bitnami@rabbitmq:5672/
      - PORT=8000
    depends_on:
      rabbitmq:
        condition: service_healthy
      redis:
        condition: service_started
    networks:
      - unify-net
    deploy:
      resources:
        limits:
          memory: 1g
          cpus: '0.5'

  # ── Queue Worker ──────────────────────────────────────────────────
  queue-worker:
    image: <registry-url>/unify-server-web-ms-dynamics:v3.0
    restart: always
    command: ["python", "queue_worker.pyc"]
    environment:
      - REDIS_URL=redis://redis:6379
      - CLOUDAMQP_URL=amqp://user:bitnami@rabbitmq:5672/
    depends_on:
      rabbitmq:
        condition: service_healthy
      redis:
        condition: service_started
    networks:
      - unify-net
    deploy:
      resources:
        limits:
          memory: 5g
          cpus: '1.0'

volumes:
  redis-data:
  rabbitmq-data:

networks:
  unify-net:
    driver: bridge

Puntos clave:

• redis-data y rabbitmq-data son volúmenes con nombre de Docker almacenados en el sistema de archivos Linux de WSL2. No se utilizan bind mounts al sistema de archivos NTFS de Windows porque NTFS no admite las operaciones chown requeridas por estos contenedores.
• La configuración de Nginx se monta desde /mnt/c/dqe-unify/nginxconf — la carpeta de Windows accesible a través de WSL2.
• platform: linux/amd64 es necesario en todas las imágenes públicas para forzar a Docker (que se ejecuta en WSL2 en un host Windows) a descargar la versión Linux.
• Los puntos de entrada son app.pyc y queue_worker.pyc — la imagen de DQE contiene bytecode Python compilado, no archivos fuente .py.

3. Lanzador

Las imágenes Docker de DQE se proporcionan a través de un Azure Container Registry gestionado por DQE Software. Todos los comandos de esta sección se ejecutan desde la terminal Ubuntu de WSL2.

3.1 Conexión al Azure Container Registry de DQE

Inicie el servicio Docker y autentíquese en el registry de DQE:

sudo service docker start
docker login <registry-url> --username <Login provided by DQE> --password <Pwd provided by DQE>

Un inicio de sesión correcto muestra: Login Succeeded

3.2 Lanzamiento de docker-compose.yml

Navegue hasta el directorio de la aplicación y descargue las imágenes:

cd /mnt/c/dqe-unify
docker compose pull

Inicie todos los servicios en modo detached:

docker compose up -d

Verifique que todos los contenedores estén en ejecución:

docker compose ps

Salida esperada — todos los servicios deben mostrar el estado running:

NAME                        IMAGE                                                  STATUS
dqe-unify-nginx-1           nginx:latest                                           running
dqe-unify-rabbitmq-1        rabbitmq:3.13-management                               running (healthy)
dqe-unify-redis-1           redis:alpine                                           running
dqe-unify-unify-server-1    <registry-url>/unify-server-web-ms-dynamics:v3.0      running
dqe-unify-queue-worker-1    <registry-url>/unify-server-web-ms-dynamics:v3.0      running

/!\ Importante: Si algún contenedor muestra el estado exited o restarting, revise sus logs: docker compose logs <service-name>