VM Windows — Salesforce-Installation

1. Architektur

Die Anwendung und alle ihre Abhängigkeiten werden in Docker-Images kompiliert.

Sobald die Container auf einer Windows Server-Instanz bereitgestellt werden, verbindet sich die Anwendung mit einer Microsoft Dynamics 365-Organisation, auf der das DQE Unify-Paket installiert ist.

Dieses Dokument beschreibt die Konfiguration zur Bereitstellung von DQE Unify Server auf einer virtuellen Windows Server 2022-Maschine mithilfe von Docker Compose, das innerhalb von WSL2 (Windows Subsystem for Linux 2) ausgeführt wird.

Flussdiagramm

Das folgende Diagramm beschreibt alle eingehenden/ausgehenden Datenflüsse sowie die von der Anwendung benötigten IPs und Ports.

Sicherheitsmaßnahmen

Wir können kein Beispiel für die Implementierung der Sicherheitsebene liefern, das perfekt zu Ihrer Architektur passen würde. Wir können jedoch einige Empfehlungen geben, die für die Nutzung der Anwendung selbst relevant sind.

• Protokolle und Ports: Alle ausgehenden/eingehenden Datenflüsse der Anwendung erfolgen über das HTTPS-Protokoll (Port 443). Es ist nicht notwendig, einen weiteren Port auf Ihrer VM zu öffnen. Die DQE-IPs, die erreichbar sein müssen, sind im vorherigen Diagramm beschrieben.
• IP-Filterung: Der Anwendungsserver selbst muss nur von den Microsoft Dynamics 365-Servern aus erreichbar sein. Es wird daher empfohlen, eine Filterung der eingehenden IPs einzurichten. Die vollständige Liste der Azure-IP-Bereiche finden Sie unter: https://www.microsoft.com/en-us/download/details.aspx?id=56519
• Authentifizierungsprotokoll: Bei der Konfiguration der DQE Unify Connected App in Ihrer Dynamics 365-Organisation können Sie die Authentifizierungsmethode auswählen und Ihre Anwendungs-Firewall entsprechend konfigurieren.

Wenn die VM direkt dem Internet ausgesetzt ist, muss sie über einen DNS-Eintrag und ein zugehöriges SSL-Zertifikat verfügen, die auf sie verweisen.

Wenn die VM nicht direkt dem Internet ausgesetzt ist, bedeutet dies in der Regel, dass der Datenverkehr über eine Komponente wie ein Gateway oder einen Load Balancer geleitet wird. In diesem Fall müssen der DNS-Eintrag und das SSL-Zertifikat auf diesem Gateway installiert werden, das den Datenverkehr dann an die interne VM weiterleitet.

Empfehlung

In diesem Abschnitt beschreiben wir die Liste der Komponenten, die für die Installation der DQE Unify Server-Instanz auf einer Windows Server-VM erforderlich sind.

Hinweis: Die Schätzungen basieren auf 1 Million Datensätzen. Je nach Volumen der verarbeiteten Datenbanken kann es notwendig sein, die Speicherkapazität der Container-Instanzen zu erhöhen, um die Verarbeitungszeiten zu optimieren.

Bereitstellung mit Windows Server-VM:

• Servertyp: Windows Server 2022 (64-Bit).
• Container-Laufzeitumgebung: Docker CE, ausgeführt innerhalb von WSL2 (Ubuntu) — erforderlich, da Docker CE auf Windows Server keine Linux-Container nativ ausführen kann.
• Load Balancer: Nicht erforderlich, kann aber verwendet werden, falls bereits vorhanden.

Hardwareanforderungen:

Zusammensetzung und Dienste

Der Stack besteht aus Docker-Images, die über Docker Compose orchestriert werden. Jeder Dienst läuft als Container. Die Dienste kommunizieren über ihren Dienstnamen im internen Docker-Netzwerk miteinander.

Webanwendung (unify-server)

Ein Backend-Container, der eine Microservices-Anwendung enthält. Diese Anwendung stellt alle APIs bereit, die zum Starten von Prozessen, zur Verwaltung von Verarbeitungswarteschlangen und zur Instanziierung von Verarbeitungs-Workern aufgerufen werden. Sie ist für ihre ordnungsgemäße Funktion von Redis und RabbitMQ abhängig. Dieser Dienst wird über den Nginx-Reverse-Proxy im Web bereitgestellt.

Docker Compose-Einstellungen

• image: Der Name des Images, das in der DQE Azure Container Registry gehostet wird:

  <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 — das Image enthält kompilierten Python-Bytecode, keine Quelldateien.

Worker (queue-worker)

Ein Backend-Container, der in der Warteschlange befindliche Aufgaben asynchron verarbeitet. Er verarbeitet Aufgaben aus der RabbitMQ-Warteschlange und führt sie aus. Verwendet dasselbe Docker-Image wie die Webanwendung.

In Docker Compose festzulegende Parameter

• image: Gleiches Image wie der Webanwendungsdienst
• depends_on: rabbitmq (healthy), redis (started)
• environment: REDIS_URL, CLOUDAMQP_URL
• command: python queue_worker.pyc

Nginx

Ein Reverse-Proxy, der eingehende HTTP/HTTPS-Anfragen an den Unify Server auf Port 8000 weiterleitet. Seine Konfigurationsdatei wird im Windows-Dateisystem (C:\dqe-unify\nginxconf\default.conf) gespeichert und über den WSL2-Pfad (/mnt/c/dqe-unify/nginxconf) in den Container eingebunden.

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

Redis

Eine Key/Value-Datenbank, die zur Speicherung interner Betriebsschlüssel wie Dynamics 365-Organisationskonfigurationen, Sitzungen usw. verwendet wird.

Es wird das offizielle Image redis:alpine verwendet. Die Daten werden in einem benannten Docker-Volume gespeichert, das im WSL2-Linux-Dateisystem liegt — Bind-Mounts auf dem Windows-NTFS-Dateisystem werden nicht verwendet, da sie die von Redis benötigten Dateiberechtigungen nicht unterstützen.

Parameter

• image: redis:alpine
• volumes: redis-data:/data (benanntes Docker-Volume)

RabbitMQ

Ein Warteschlangen-Manager, der die Entgegennahme und Planung von Verarbeitungsanfragen ermöglicht. Bis ein Prozess einem Worker zugewiesen und abgeschlossen wurde, verbleibt er in der Warteschlange. Dies sorgt außerdem für Ausfallsicherheit — wird der Server neu gestartet, setzt er die letzte Verarbeitung in der Warteschlange an der Stelle fort, an der sie unterbrochen wurde.

Es wird das offizielle Image rabbitmq:3.13-management verwendet. Die Daten werden in einem benannten Docker-Volume gespeichert. Die Anmeldedaten werden über Umgebungsvariablen festgelegt.

Parameter

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

2. Installation

Alle Installationsschritte werden auf der Windows Server-VM durchgeführt. Mit [PowerShell] gekennzeichnete Schritte müssen in PowerShell als Administrator ausgeführt werden. Mit [WSL2] gekennzeichnete Schritte müssen im Ubuntu-WSL2-Terminal ausgeführt werden.

2.1 Voraussetzung

Verbinden Sie sich mit der Windows Server-VM über eine der verfügbaren Verbindungsoptionen (RDP, Azure Bastion usw.) und öffnen Sie PowerShell als Administrator.

Erstellen Sie die Verzeichnisstruktur der Anwendung über PowerShell:

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

WSL2-Installation [PowerShell]

Aktivieren Sie die erforderlichen Windows-Funktionen:

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

/!\ Neustart erforderlich — Starten Sie die VM nach der Aktivierung dieser Funktionen neu, bevor Sie fortfahren.

Öffnen Sie nach dem Neustart PowerShell als Administrator und installieren Sie Ubuntu:

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

Es öffnet sich ein Terminal, in dem Sie aufgefordert werden, einen Unix-Benutzernamen und ein Passwort zu erstellen. Schließen Sie die Einrichtung ab, bevor Sie fortfahren.

Docker- und Docker Compose-Installation [WSL2]

Öffnen Sie das Ubuntu-WSL2-Terminal und führen Sie Folgendes aus:

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

Hinweis: Das Skript erkennt WSL und empfiehlt Docker Desktop — ignorieren Sie diese Meldung und warten Sie 20 Sekunden, bis die Installation automatisch fortgesetzt wird. Docker Compose ist in dieser Installation enthalten.

Fügen Sie Ihren Benutzer der docker-Gruppe hinzu und starten Sie den Dienst:

sudo usermod -aG docker $USER
sudo service docker start

Schließen Sie das WSL2-Terminal und öffnen Sie es erneut, überprüfen Sie dann:

docker --version
docker compose version

Hinweis: Der Docker-Dienst muss bei jedem Öffnen der WSL2-Sitzung manuell gestartet werden: sudo service docker start

Azure-CLI-Installation [WSL2]

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

Nginx-Konfiguration [PowerShell]

Nginx läuft als Container — es gibt keine Installation auf Host-Ebene. Sie müssen lediglich die Konfigurationsdatei erstellen. Öffnen Sie sie über PowerShell in Notepad:

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

Fügen Sie den folgenden Inhalt ein und speichern Sie:

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

Hinweis: Im Gegensatz zur ACI-Version, bei der Nginx auf localhost:8000 zielt, kommunizieren die Dienste in Docker Compose über ihren Dienstnamen — das Proxy-Ziel ist http://unify-server:8000.

Fügen Sie für HTTPS einen zweiten Server-Block hinzu:

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

Erstellen Sie die Datei C:\dqe-unify\docker-compose.yml mit dem folgenden Inhalt über Notepad. Ersetzen Sie <registry-url> durch die von DQE Software bereitgestellte URL.

Hinweis: Im Gegensatz zur ACI-Version kommunizieren die Dienste in Docker Compose über Dienstnamen (redis, rabbitmq) und nicht über localhost. Die Umgebungsvariablen sind entsprechend konfiguriert.

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

Wichtige Punkte:

• redis-data und rabbitmq-data sind benannte Docker-Volumes, die im WSL2-Linux-Dateisystem gespeichert werden. Bind-Mounts zum Windows-NTFS-Dateisystem werden nicht verwendet, da NTFS die von diesen Containern benötigten chown-Operationen nicht unterstützt.
• Die Nginx-Konfiguration wird von /mnt/c/dqe-unify/nginxconf eingebunden — dem über WSL2 zugänglichen Windows-Ordner.
• platform: linux/amd64 ist bei allen öffentlichen Images erforderlich, um Docker (das in WSL2 auf einem Windows-Host läuft) zu zwingen, die Linux-Version herunterzuladen.
• Die Einstiegspunkte sind app.pyc und queue_worker.pyc — das DQE-Image enthält kompilierten Python-Bytecode und keine .py-Quelldateien.

3. Launcher

Die DQE-Docker-Images werden über eine von DQE Software verwaltete Azure Container Registry bereitgestellt. Alle Befehle in diesem Abschnitt werden über das Ubuntu-WSL2-Terminal ausgeführt.

3.1 Verbindung zur DQE Azure Container Registry herstellen

Starten Sie den Docker-Dienst und authentifizieren Sie sich bei der DQE-Registry:

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

Eine erfolgreiche Anmeldung zeigt an: Login Succeeded

3.2 Start von docker-compose.yml

Wechseln Sie in das Anwendungsverzeichnis und laden Sie die Images herunter:

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

Starten Sie alle Dienste im Hintergrundmodus (detached):

docker compose up -d

Überprüfen Sie, ob alle Container ausgeführt werden:

docker compose ps

Erwartete Ausgabe — alle Dienste sollten den Status running anzeigen:

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

/!\ Wichtig: Wenn ein Container den Status exited oder restarting anzeigt, überprüfen Sie dessen Protokolle: docker compose logs <service-name>