Machine virtuelle Windows — Installation Salesforce

1. Architecture

L'application et toutes ses dépendances sont compilées dans des images Docker.

Dès que les conteneurs sont déployés sur une instance Windows Server, l'application s'associe à une organisation Microsoft Dynamics 365 sur laquelle le package DQE Unify est installé.

Ce document décrit la configuration permettant de déployer DQE Unify Server sur une machine virtuelle Windows Server 2022 à l'aide de Docker Compose s'exécutant à l'intérieur de WSL2 (Windows Subsystem for Linux 2).

Diagramme de flux

Le diagramme ci-dessous décrit tous les flux entrants/sortants ainsi que les IPs et ports requis par l'application.

Mesures de sécurité

Nous ne pouvons pas fournir un exemple d'implémentation de la couche de sécurité qui s'adapterait parfaitement à votre architecture. Cependant, nous pouvons fournir quelques recommandations pertinentes pour l'utilisation de l'application elle-même.

• Protocoles et ports : Tous les flux entrants/sortants de l'application passent par le protocole HTTPS (port 443). Il n'est pas nécessaire d'ouvrir un autre port sur votre VM. Les IPs DQE devant être accessibles sont décrites dans le diagramme précédent.
• Filtrage IP : Le serveur d'application lui-même doit uniquement être accessible depuis les serveurs Microsoft Dynamics 365. Il est donc recommandé de mettre en place un filtrage des IPs entrantes. Voir la liste complète des plages d'IPs Azure sur : https://www.microsoft.com/en-us/download/details.aspx?id=56519
• Protocole d'authentification : Lors de la configuration de la Connected App DQE Unify dans votre organisation Dynamics 365, vous pourrez sélectionner la méthode d'authentification et configurer votre pare-feu applicatif en conséquence.

Si la VM est directement exposée à internet, elle doit disposer d'une entrée DNS et d'un certificat SSL associé qui pointent vers elle.

Si la VM n'est pas directement exposée à internet, cela signifie généralement que le trafic est acheminé via un composant tel qu'une passerelle ou un load balancer. Dans ce cas, le DNS et le certificat SSL doivent être installés sur cette passerelle, qui redirigera ensuite le trafic vers la VM interne.

Recommandation

Dans cette section, nous décrivons la liste des composants nécessaires pour installer l'instance DQE Unify Server sur une VM Windows Server.

Remarque : Les estimations sont basées sur 1 million d'enregistrements. Selon le volume des bases de données traitées, il peut être nécessaire d'augmenter la capacité mémoire des instances de conteneur afin d'optimiser les temps de traitement.

Déploiement avec VM Windows Server :

• Type de serveur : Windows Server 2022 (64 bits).
• Runtime de conteneur : Docker CE s'exécutant à l'intérieur de WSL2 (Ubuntu) — requis car Docker CE sur Windows Server ne peut pas exécuter nativement des conteneurs Linux.
• Load balancer : Non requis, mais peut être utilisé s'il est déjà disponible.

Exigences matérielles :

Composition et services

La stack est composée d'images Docker orchestrées via Docker Compose. Chaque service s'exécute en tant que conteneur. Les services communiquent entre eux via leur nom de service sur le réseau Docker interne.

Application Web (unify-server)

Un conteneur backend contenant une application de microservices. Cette application expose toutes les API appelées pour lancer des processus, gérer les files d'attente de traitement et instancier des workers de traitement. Elle dépend de Redis et RabbitMQ pour fonctionner correctement. Ce service est exposé sur le web via le reverse proxy Nginx.

Paramètres Docker Compose

• image : Le nom de l'image hébergée sur l'Azure Container Registry 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 — l'image contient du bytecode Python compilé, pas les fichiers source.

Worker (queue-worker)

Un conteneur backend qui traite les tâches en file d'attente de manière asynchrone. Il consomme les tâches de la file RabbitMQ et les exécute. Utilise la même image Docker que l'application web.

Paramètres à définir dans Docker Compose

• image : Même image que le service d'application web
• depends_on : rabbitmq (healthy), redis (started)
• environment : REDIS_URL, CLOUDAMQP_URL
• command : python queue_worker.pyc

Nginx

Un reverse proxy qui transmet les requêtes HTTP/HTTPS entrantes vers Unify Server sur le port 8000. Son fichier de configuration est stocké sur le système de fichiers Windows (C:\dqe-unify\nginxconf\default.conf) et monté dans le conteneur via le chemin 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

Une base de données clé/valeur utilisée pour stocker les clés de fonctionnement interne telles que les configurations d'organisation Dynamics 365, les sessions, etc.

L'image officielle redis:alpine est utilisée. Les données sont persistées dans un volume nommé Docker stocké dans le système de fichiers Linux de WSL2 — les bind mounts vers le système de fichiers NTFS Windows ne sont pas utilisés car ils ne prennent pas en charge les permissions de fichiers requises par Redis.

Paramètres

• image : redis:alpine
• volumes : redis-data:/data (volume nommé Docker)

RabbitMQ

Un gestionnaire de files d'attente permettant la réception et la planification des demandes de traitement. Tant qu'un processus n'a pas été assigné à un worker et terminé, il est mis en attente dans la file. Cela apporte également une résilience aux pannes — si le serveur est redémarré, il reprend le dernier traitement en file d'attente là où il s'était arrêté.

L'image officielle rabbitmq:3.13-management est utilisée. Les données sont persistées dans un volume nommé Docker. Les identifiants sont définis via des variables d'environnement.

Paramètres

• image : rabbitmq:3.13-management
• volumes : rabbitmq-data:/var/lib/rabbitmq (volume nommé Docker)
• environment : RABBITMQ_DEFAULT_USER=user, RABBITMQ_DEFAULT_PASS=bitnami

2. Installation

Toutes les étapes d'installation sont effectuées sur la VM Windows Server. Les étapes marquées [PowerShell] doivent être exécutées dans PowerShell en tant qu'administrateur. Les étapes marquées [WSL2] doivent être exécutées dans le terminal Ubuntu WSL2.

2.1 Prérequis

Connectez-vous à la VM Windows Server en utilisant l'une des options de connexion disponibles (RDP, Azure Bastion, etc.) et ouvrez PowerShell en tant qu'administrateur.

Créez l'arborescence de répertoires de l'application depuis PowerShell :

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

Installation de WSL2 [PowerShell]

Activez les fonctionnalités Windows requises :

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

/!\ Redémarrage requis — Redémarrez la VM après avoir activé ces fonctionnalités avant de continuer.

Après le redémarrage, ouvrez PowerShell en tant qu'administrateur et installez Ubuntu :

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

Un terminal s'ouvre et vous demande de créer un nom d'utilisateur et un mot de passe Unix. Terminez la configuration avant de continuer.

Installation de Docker et Docker Compose [WSL2]

Ouvrez le terminal Ubuntu WSL2 et exécutez :

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

Remarque : Le script détecte WSL et recommande Docker Desktop — ignorez le message et attendez 20 secondes que l'installation continue automatiquement. Docker Compose est inclus dans cette installation.

Ajoutez votre utilisateur au groupe docker et démarrez le service :

sudo usermod -aG docker $USER
sudo service docker start

Fermez et rouvrez le terminal WSL2, puis vérifiez :

docker --version
docker compose version

Remarque : Le service Docker doit être démarré manuellement à chaque ouverture de la session WSL2 : sudo service docker start

Installation d'Azure CLI [WSL2]

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

Configuration de Nginx [PowerShell]

Nginx s'exécute en tant que conteneur — il n'y a pas d'installation au niveau de l'hôte. Vous devez uniquement créer le fichier de configuration. Ouvrez-le dans le Bloc-notes depuis PowerShell :

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

Collez le contenu suivant et enregistrez :

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

Remarque : Contrairement à la version ACI où Nginx cible localhost:8000, dans Docker Compose les services communiquent via leur nom de service — la cible du proxy est http://unify-server:8000.

Pour le HTTPS, ajoutez un second bloc 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

Créez le fichier C:\dqe-unify\docker-compose.yml avec le contenu ci-dessous en utilisant le Bloc-notes. Remplacez <registry-url> par l'URL fournie par DQE Software.

Remarque : Contrairement à la version ACI, les services Docker Compose communiquent via des noms de service (redis, rabbitmq), pas via localhost. Les variables d'environnement sont définies en conséquence.

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

Points clés :

• redis-data et rabbitmq-data sont des volumes nommés Docker stockés dans le système de fichiers Linux de WSL2. Les bind mounts vers le système de fichiers NTFS Windows ne sont pas utilisés car NTFS ne prend pas en charge les opérations chown requises par ces conteneurs.
• La configuration Nginx est montée depuis /mnt/c/dqe-unify/nginxconf — le dossier Windows accessible via WSL2.
• platform: linux/amd64 est requis sur toutes les images publiques pour forcer Docker (s'exécutant dans WSL2 sur un hôte Windows) à récupérer la version Linux.
• Les points d'entrée sont app.pyc et queue_worker.pyc — l'image DQE contient du bytecode Python compilé, pas les fichiers source .py.

3. Lanceur

Les images Docker DQE sont fournies via un Azure Container Registry géré par DQE Software. Toutes les commandes de cette section sont exécutées depuis le terminal Ubuntu WSL2.

3.1 Connexion à l'Azure Container Registry DQE

Démarrez le service Docker et authentifiez-vous auprès du registre DQE :

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

Une connexion réussie affiche : Login Succeeded

3.2 Lancement de docker-compose.yml

Accédez au répertoire de l'application et récupérez les images :

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

Démarrez tous les services en mode détaché :

docker compose up -d

Vérifiez que tous les conteneurs sont en cours d'exécution :

docker compose ps

Résultat attendu — tous les services doivent afficher le statut 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

/!\ Important : Si un conteneur affiche le statut exited ou restarting, consultez ses logs : docker compose logs <service-name>