VM Windows — Backend-Wartung

Support DQE
Support DQE
  • Aktualisiert

1.1 Warum Wartungsarbeiten durchführen

Diese Anwendung wurde für hohe Ausfallsicherheit entwickelt und erfordert keine häufige Wartung. In manchen Situationen kann es jedoch notwendig sein, den Stack neu zu starten, um eine neue Version anzuwenden oder sich von einem Fehlerzustand zu erholen.

Wenn beispielsweise die Datenverarbeitung fehlschlägt, können sich temporäre Dateien in den Redis- oder RabbitMQ-Volumes ansammeln. Das Stoppen und Neustarten der Anwendung löscht diese Dateien und setzt die Warteschlange zurück.

Hinweis: Dieser Abschnitt behandelt ausschließlich die Wartung auf Docker-Ebene. Netzwerk- oder Firewall-Konfigurationen, die spezifisch für Ihre Organisation sind, liegen außerhalb des Umfangs dieses Dokuments.

1.2 Wann sollten Sie Wartungsarbeiten durchführen?

1.2.1 Fehlgeschlagene Datenprozesse

Das erste Signal dafür, dass Ihre Anwendung Aufmerksamkeit benötigt, ist, wenn von Salesforce gestartete Datenprozesse den Status Failed anzeigen. Bevor Sie handeln, prüfen Sie die Fehlerbeschreibung, um Probleme in Ihren Deduplizierungsregeln oder anderen Integrationen auszuschließen.

Wenn der Fehler auf den Server selbst hinweist, fahren Sie mit Abschnitt 1.3, Vorgehensweise, fort.

1.2.2 Ausstehende Datenprozesse

Wenn die Auftragswarteschlange bei derselben Nachricht hängen bleibt und Datenprozesse blockiert, löschen Sie das RabbitMQ-Volume und starten Sie die Anwendung neu.

  1. Schritt 1 — Die Anwendung stoppen:

    cd C:\dqe-unify
    docker compose stop rabbitmq
  2. Schritt 2 — Das RabbitMQ-Datenvolume löschen:

    # Delete all files in the rabbitvol directory
    Remove-Item -Recurse -Force "C:\dqe-unify\volumes\rabbitvol\*"
  3. Schritt 3 — RabbitMQ neu starten:

    docker compose start rabbitmq

Wenn das Problem weiterhin besteht, führen Sie einen vollständigen Neustart wie in Abschnitt 1.3 beschrieben durch.

1.3 Vorgehensweise

1.3.1 Schritt 1 – Protokolle abrufen

Protokolle auf einer Windows-VM werden direkt von Docker verwaltet. Verwenden Sie die folgenden Befehle, um sie abzurufen.

Live-Protokolle für alle Dienste anzeigen:

cd C:\dqe-unify
docker compose logs -f

Protokolle für einen bestimmten Dienst anzeigen:

docker compose logs -f unify-server
docker compose logs -f queue-worker

Protokolle zur Analyse in eine Datei exportieren:

docker compose logs --no-color unify-server  C:\dqe-unify\logs\unify-server.log
docker compose logs --no-color queue-worker   C:\dqe-unify\logs\queue-worker.log

Protokollaufbewahrung: Docker-Protokolle werden auf der Festplatte der VM gespeichert und nicht automatisch rotiert. Um die Protokollrotation zu konfigurieren, bearbeiten Sie die Docker-Daemon-Konfiguration (C:\ProgramData\Docker\config\daemon.json):

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "5"
  }
}

1.3.2 Schritt 2 – Anwendung neu erstellen / aktualisieren

Um eine neuere Image-Version bereitzustellen oder alle Volumes zu löschen, stoppen und entfernen Sie die Container, laden Sie dann die neuesten Images herunter und starten Sie neu.

  1. Schritt 1 — Alle Container stoppen und entfernen:

    cd C:\dqe-unify
    docker compose down
  2. Schritt 2 — Optional: Bei Bedarf die persistenten Volumes löschen:

    Remove-Item -Recurse -Force "C:\dqe-unify\volumes\redisvol\*"
    Remove-Item -Recurse -Force "C:\dqe-unify\volumes\rabbitvol\*"
  3. Schritt 3 — Die neuesten Images herunterladen:

    docker compose pull
  4. Schritt 4 — Die Anwendung neu starten:

    docker compose up -d

1.3.3 Schritt 3 – Neustart

Für einen einfachen Neustart, ohne Volumes zu löschen oder neue Images herunterzuladen, führen Sie Folgendes aus:

cd C:\dqe-unify
docker compose restart

Überwachen Sie den Neustart:

docker compose ps

Alle Dienste sollten den Status running erreichen. Wenn ein Dienst exited anzeigt oder in einer restarting-Schleife verbleibt, überprüfen Sie dessen Protokolle und wenden Sie sich an den DQE Software-Support, falls das Problem nicht behoben werden kann.

Wichtig: Die Richtlinie restart: always in der Compose-Datei stellt sicher, dass Container nach einem VM-Neustart oder einem Neustart des Docker-Daemons automatisch neu gestartet werden. Für routinemäßige VM-Neustarts ist kein manueller Eingriff erforderlich.

1.4 Automatischen Start beim VM-Boot sicherstellen

Unter Windows Server läuft Docker Engine als Windows-Dienst. Stellen Sie sicher, dass er so konfiguriert ist, dass er automatisch startet, damit Container nach jedem VM-Neustart ohne manuellen Eingriff neu gestartet werden.

Überprüfen Sie den Starttyp des Dienstes in PowerShell als Administrator:

Get-Service docker | Select-Object Name, StartType, Status

Wenn StartType nicht Automatic ist, legen Sie ihn fest:

Set-Service -Name docker -StartupType Automatic
Start-Service docker

Da restart: always für jeden Dienst in docker-compose.yml festgelegt ist, startet Docker Engine automatisch alle Container neu, wenn der Dienst beim Booten startet. Es ist keine zusätzliche Konfiguration erforderlich.

1.5 Referenz nützlicher Befehle

Aktion Befehl (ausgeführt aus C:\dqe-unify)
Alle Dienste starten docker compose up -d
Alle Dienste stoppen docker compose down
Alle Dienste neu starten docker compose restart
Status anzeigen docker compose ps
Alle Protokolle anzeigen docker compose logs -f
Server-Protokolle anzeigen docker compose logs -f unify-server
Worker-Protokolle anzeigen docker compose logs -f queue-worker
Neueste Images herunterladen docker compose pull
Neu erstellen und neu bereitstellen docker compose down && docker compose pull && docker compose up -d
Mit einer Container-Shell verbinden docker compose exec unify-server bash
Ressourcennutzung des Containers prüfen docker stats

Verknüpfung mit

War dieser Beitrag hilfreich?

0 von 0 fanden dies hilfreich