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.
-
Schritt 1 — Die Anwendung stoppen:
cd C:\dqe-unify docker compose stop rabbitmq -
Schritt 2 — Das RabbitMQ-Datenvolume löschen:
# Delete all files in the rabbitvol directory Remove-Item -Recurse -Force "C:\dqe-unify\volumes\rabbitvol\*" -
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.
-
Schritt 1 — Alle Container stoppen und entfernen:
cd C:\dqe-unify docker compose down -
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\*" -
Schritt 3 — Die neuesten Images herunterladen:
docker compose pull -
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