Shopware 6 – WSC Standard Stack (mit WSC_SWPlugin_AiSeoTools)

Fork von Docker-Stacks/projekt-sw6 für Shops mit dem Plugin WSC_SWPlugin_AiSeoTools (KI-Bildkennzeichnung). Unterschiede: worker installiert zusätzlich c2patool, und configs/shopware/z-shopware.yaml aktiviert shopware.media.remote_thumbnails (siehe Projekt.md, Abschnitt „Abweichungen gegenüber projekt-sw6"). Setzt eine erreichbare imagor-Instanz voraus (Docker-Stacks/docker-imagor-media).

Selbst gehosteter Shopware-6-Shop auf Basis des offiziellen ghcr.io/shopware/docker-base-Images, mit OpenSearch, getrennten Redis-Instanzen (Cache + Messenger) und MariaDB.

Template-Hinweis: .env enthält nur Platzhalter (CHANGE_ME, example.*). Vor dem Einsatz anpassen, Passwörter gemäß Anleitung im .env-Kopf erzeugen (openssl rand -hex 32). Werte, die je in Git lagen, gelten als kompromittiert → rotieren.

---

1. Voraussetzungen

• Docker + Docker Compose v2
• Externes Netz traefik_proxy_network (Traefik-Stack)
• Zentrale Stacks für die Integrationen: docker-autoheal-neustart, docker-ofelia-cronjobs, docker-docker-backup-backups
• Backup-Verzeichnis ${BACKUP_PATH} (Default /Daten/Backups) muss auf dem Host existieren
• Die Volume-Ordner unter ./volumes/ existieren bereits nach git clone/pull (leer bis auf .gitkeep, getestet inkl. mariadb:11.4-Init mit .gitkeep im Datenverzeichnis) — der local-Volume-Treiber (o: bind, type: none) legt fehlende Zielverzeichnisse NICHT selbst an, ein frischer Deploy (z. B. via DockHand direkt aus Git) würde sonst beim ersten docker compose up mit "no such file or directory" abbrechen

---

2. Starten

Wichtig: docker compose immer aus diesem Stack-Verzeichnis starten (${PWD}-Mounts).

docker compose build
docker compose up -d

---

3. Shopware-Konfiguration (z-shopware.yaml)

configs/shopware/z-shopware.yaml enthält die Stack-spezifische Shopware-Config (Redis-Cache/Session/Lock, Messenger-Transports, Monolog). Sie muss in den Shopware-Projektcode unter config/packages/z-shopware.yaml deployed werden (liegt zur Laufzeit in volumes/html/config/packages/).

Passende DATABASE_URL / Redis-DSNs werden über Env-Variablen gesetzt.

---

4. Integrationen

Autoheal (Self-Healing)

autoheal=true auf app, opensearch, redis-cache, redis-messenger, sql (alle mit Healthcheck). worker/scheduler laufen bewusst ohne Autoheal – sie beenden sich per --time-limit=300 zyklisch und werden über restart: unless-stopped neu gestartet.

⚠️ Der app-Healthcheck prüft http://localhost:8000/admin. Liefert die App dauerhaft 5xx (z. B. ausstehende Migration beim Erst-Deploy), kann Autoheal den app-Container in eine Restart-Schleife bringen → beim ersten Setup beobachten, ggf. autoheal-Label temporär raus.

CronJobs (Ofelia) – Schedule ist 6-Feld (mit Sekunden!)

Auf app (als ${CRONJOB_USER}): ES-Index Cleanup/Rebuild, Admin-Index, Theme-Compile, Cache-Warmup, Sitemap, cache:clear:delayed.

DB-Backup (shyim/docker-backup) – Schedule 5-Feld

Label auf sql: type=mysql, BACKUP_SCHEDULE (Default alle 6 h), Retention BACKUP_RETENTION. Landet unter /Daten/Backups/<sql-container>/db/….

Datei-Backup (Ofelia + backup-helper)

Da shyim nur named volumes sichert (eure Daten sind Bind-Mounts), läuft das Datei-Backup über den idle backup-helper: Ofelia job-exec packt täglich 05:00 ein tar.gz von /var/www/html nach ${BACKUP_PATH}/<projekt>/files/ (Retention 5 Tage).

---

5. Hinweise / Stolpersteine

• Ofelia vs. shyim Cron-Format: Ofelia = 6-Feld (0 5 0 * * *), shyim = 5-Feld (5 0 * * *). Nicht verwechseln.
• OpenSearch 3: compatibility.override_main_response_version existiert nicht mehr – nicht setzen.
• opcache-blacklist.txt wird nach /etc/opcache-blacklist.txt gemountet (von shopware.ini referenziert, hält Twig-Templates aus dem OPcache).
• Datei-Backup-Command (Ofelia sh -c + $(date)) auf dem Server gegentesten.

---

6. Nützliche Befehle

docker compose config -q          # Konfiguration validieren
docker compose up -d
docker compose logs -f app
docker compose exec -u www-data app php bin/console <command>
docker compose down

7. Shopware Befehle

./bin/console messenger:setup-transports

---

8. CI/CD

Die Pipeline (.forgejo/workflows/ci.yml) läuft self-hosted auf Forgejo, ganz ohne externe Actions (Checkout per git clone). Anders als bei den Nachbar-Stacks gibt es hier keinen Code-Mirror nach Codeberg:

• validate (jeder Push/PR auf main + Tags): docker compose config -q, yamllint (relaxed) und gitleaks (nur Working-Tree). Es wird docker compose v2 genutzt (Runner-Image catthehacker/ubuntu:act-latest; nötig u. a. für v2-Keys wie dockerfile_inline), apt nur als Fallback – kein 64-MB-github-Download.
• release (nur Tag v*): baut ein schlankes Deploy-ZIP und hängt es an ein Forgejo-Release und – als Backup – an ein Codeberg-Release (die Releases-Unit am Codeberg-Repo wird dabei automatisch aktiviert).

Release auslösen:

git tag v1.1
git push origin v1.1

Details siehe CICD-Actions.md.

Lizenz

Copyright (C) 2026 Christian Säum – web-seo-consulting.eu

Dieses Projekt steht unter der GNU Affero General Public License, Version 3 oder (nach deiner Wahl) einer späteren Version (AGPL-3.0-or-later). Der vollständige Lizenztext steht in der Datei LICENSE.

Du darfst die Software nutzen, weitergeben und – auch kommerziell – verkaufen. Gibst du eine veränderte Fassung weiter oder betreibst du sie über ein Netzwerk (z. B. als Dienst), muss deren vollständiger Quellcode ebenfalls unter der AGPL-3.0-or-later verfügbar sein. Der Copyright-Hinweis und die Nennung des ursprünglichen Autors dürfen nicht entfernt werden.

Diese Angabe betrifft nur die in diesem Repository enthaltenen eigenen Dateien (Konfiguration, Skripte, Anpassungen). Eingebundene Fremdsoftware und Container-Images unterliegen weiterhin ihren eigenen Lizenzen.