Hallo liebe Shopware-Community,
Ich habe mir zur Entwicklung Shopware direkt aus dem Shopware-Github-Repository geforkt (shopwareLabs/shopware).
Ich würde gerne die vorhande docker-compose.yml und das dazugehörige dev-environment zur weiteren Entwicklung nutzen, wenn ich diese allerdings durchstarte, finde ich keine Möglichkeit, die Shopware-Installation aufzurufen.
Was ich gemacht habe (wirklich der exakte Ablauf, so sollte es ja auch sein bei einem richtig konfigurierten Docker-Container):
git clone https://github.com/shopwareLabs/shopware
cd shopware
docker-compose up
Der Container fährt sauber hoch und laut Log ist alles soweit da.
Ich habe durch apachectl -S herausgefunden, dass der VHost unter dem domain name docker.vm registriert wird und auch wirklich auf Port 80 läuft.
Habe mir in der HOSTS-file docker.vm und f791b4f92d3a auf 127.0.0.1 gemappt.
Aufgerufen habe ich
http://localhost/{shopware|index|recovery/install/index}.php
Bei f791b4f92d3a handelt es sich um meine Container-ID, die anscheinend im app-container in /opt/docker/etc/httpd/conf.d/10-server.conf ebenfalls als vhost eingetragen wird.
In jedem der Fälle, egal welche URL ich aufrufe, erhalte ich einen 404 direkt von Apache, heißt, der Shopware-Bootstrap wird nie getriggert. Apache selbst scheint aber auf dem richtigen Port zu antworten (ist der einzige Apache, der auf meinem System existiert, inkl. anderer Container, also muss er das sein)
Ich habe außerdem versucht, die .htaccess Datei zu korrumpieren damit ich wenigstens einen 500er bekomme um zu sehen ob irgendwas triggert, aber auch diesen kriege ich nicht erzeugt, d.h. die .htaccess wird vollständig ignoriert und somit scheint /app auch nicht mein DocumentRoot zu sein.
Es scheint fast so, als würde der Docker-Container auf etwas völlig anderes mappen, allerdings habe ich in der Config überprüft, dass:
-
Die App-files auch wirklich in /app liegen
-
Der DocumentRoot des Apache2 auch wirklich /app ist
-
Der Vhost docker.vm auch wirklich auf /app zeigt (was er tut)
apachectl -S hatte folgende Ausgabe:
VirtualHost configuration:
*:80 docker.vm (/opt/docker/etc/httpd/vhost.conf:5)
*:443 docker.vm (/opt/docker/etc/httpd/vhost.conf:21)
ServerRoot: „/etc/apache2“
Main DocumentRoot: „/app“
Main ErrorLog: „/docker.stderr“
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir=„/var/run/apache2/“ mechanism=default
PidFile: „/var/run/apache2/apache2.pid“
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name=„www-data“ id=33
Group: name=„www-data“ id=33
Sieht im Grunde ganz gut aus, selbst die Änderung am Logging nach docker.stderr wird von der Config grundsätzlich anerkannt.
Laut Dockerfiles sollen die Logs in den Docker-Output gemappt werden, das passiert ebenfalls nicht. Ich erhalte keinerlei Access-Logs, zu keinem Zeitpunkt, weder im docker-compose output noch sonst wo. Ich kann diese auch nicht unter /var/log/apache2/*.log finden, heißt, sie landen irgendwo im Nirvana.
Ports sind alle frei, für sämtliche in der docker-compose enthaltenen Dienste, inkl. PHP-FPM mit Port 9000.
Nun frage ich mich: Was mache ich falsch? Im Grunde ist das doch ein geradliniger Prozess, aber ich scheine etwas zu übersehen.
Betriebssystem ist Windows 10 64bit mit Docker im Hyper-V Modus, ich nutze Docker für sämtliche meiner Projekte und derartige Spielchen konnte ich bisher nicht beobachten, nutze allerdings auch meist nginx innerhalb der Container.
Vielen Dank für eure Hilfe,
Gruß,
Torben
)
Michael Telgmann