spryker demoshop
1.0.0
docker-composeBenötigt: Eine aktuelle, stabile Version von Docker und Docker-Compose (mit Docker-compose.yml 3.4-Unterstützung) auf Ihrem Linux- oder MacOS-System.
Da dieser Stapel recht komplex ist, einschließlich eines voll ausgestatteten ES, erfordert er mindestens 4 GB Speicher. Wenn Sie Docker unter Windows/MacOS ausführen, passen Sie bitte die Einstellungen entsprechend an.
Wenn die Voraussetzungen erfüllt sind, ist das Laufen des Ladens ziemlich einfach. Geben Sie einfach diese Schritte ein:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
Dadurch wird das Docker-Image gezogen, ein Netzwerk erstellt, alle Container erstellen, die Moderationen Ihres lokalen Code in den Container binden, damit Sie von außen lebendig sind, den Container miteinander verbindet und schließlich die öffentlichen Dienste enthüllt. Wie Yves, Zed, Jenkins-Master, Postgresql und Elasticsearch.
Bitte seien Sie geduldig, während der Spryker -Stack erstellt wird, da die Initialisierungsroutine einige Zeit in Anspruch nimmt, damit alle Daten in die Datenbank importiert und dann in Redis und Elasticsearch exportiert werden. Derzeit dauert dies ungefähr 10 Minuten.
Nach Abschluss der Initialisierung können Sie Ihren Browser auf die folgenden URLs richten:
Dies ist eine dockerisierte Version der offiziellen Referenzimplementierung des Spryker Demoshop. Es ist bereit, außerhalb des Boxs zu laufen, indem Sie automatisch alle erforderlichen Abhängigkeiten ziehen und einen Stapel erstellen, der PostgreSQL, Redis, Elasticsearch und Jenkins umfasst. Während der Laufzeit wird jeder der Dienste initialisiert.
Sie können dieses Repository entweder als Demonstration für einen paradigmatischen Laden verwenden, der auf Spryker Commerce -Betriebssystem basiert, oder als Ausgangspunkt für die Entwicklung Ihrer eigenen Implementierung, beginnend mit einer Gabel des Demoshop.
Das Build- und Startverfahren zusammen mit weiteren Werkzeugen wird vom Claranet/PHP -Bild geerbt. Dort finden Sie die technischen Designideen für diese Dockerisierung und Antworten auf weitere Punkte wie:
docker/ DateisystemstrukturVorteile der Containerisierung:
Mehrere Dienste werden vom Docker-Compose-Stack ausgesetzt. Um Stapel parallel auszuführen und Port -Kollisionen zu verhindern, müssen wir die Portallokation ausrichten.
Daher wurde das folgende Schema implementiert: Die Portnummer ist so codiert: ECCDD
Also ist Yves de über http: // localhost: 20100/und yves uns über http: // localhost: 20102 erreichbar
Hinweis: Die Differenzierung zwischen Geschäften/Domänen nach Port gilt nur für die lokale Entwicklung. Der von Claranet bereitgestellte tatsächliche Produktionsnote -Stapel erstellt diese Auszeichnung basierend auf dem tatsächlichen Domain -Namen.
Eine zentrale Prämisse ist - und diese ist entscheidend für Ihr Verständnis dieses Stapels -, um ein einheitliches Bild in Entwicklungs- und Produktionsumgebungen zu erstellen. Dies wirkt sich auf die Verwendung von APPLICATION_ENV aus, die von der Spryker -App selbst bewertet wird.
Diese Variable hat den folgenden Einfluss:
Der Standort lokaler Konfigurationsdateien und externer Ressourcen ist nichts, was in der Container -Umgebung zusätzlich berücksichtigt werden muss, da alle diese Stapel sowieso isoliert sind. Bitte stellen Sie sicher, dass keine Konfigurationsanweisung unter ./config/Shared/ APPLICATION_ENV verwendet, um ihre Pfade zu identifizieren !!!
Wir betrachten nur Punkt 1.1, der eine Auszeichnung wert ist. Und da dies durch die Injektion von ordnungsgemäßen Vars in die effektiven Behälter erreicht werden kann, unterscheiden wir nicht zwischen Umgebungen, während wir die Bilder erstellen. Da Punkt 1.1 in der Regel mehr Abhängigkeiten behoben werden müssen, erstellen wir das Bild immer mit APPLICATION_ENV auf development . In welchem Modus die Anwendung jedoch tatsächlich ausgeführt wird, ist das unabhängig davon.
Dies bedeutet, dass selbst die Produktionsbehälter Entwicklungsabhängigkeiten enthalten werden. Der Hauptgrund dafür ist die Anforderung für die DEV/Test/Prod -Parität, um sicherzustellen, dass sich die Container in allen Stadien und in allen Umgebungen genau gleich verhalten. Der Kompromiss für diese Prämisse ist wieder größere effektive Bilder.
Während der Laufzeit kann das Verhalten der Spryker -Anwendung gesteuert werden, indem APPLICATION_ENV eingesetzt wird, die entweder development oder production akzeptiert. Wenn Sie das Skript ./docker/run verwenden, werden diese Variablen automatisch festgelegt.
Die Idee hinter dem Wrapper -Skript über ./docker/run ist die grundlegende Unterscheidung zwischen devel und prod . Der Hauptunterschied zwischen diesen Umgebungen in Bezug auf docker-compose ist die Einstellung von Bindmontage im Entwicklungsmodus, mit dem der Entwickler die Codebasis von außen bearbeiten kann, während der Code im Hintergrund innerhalb der Container ausgeführt wird.
Da dieses Setup die manuellen Bemühungen reduziert Schauen Sie sich ./docker/run help
Die prod Umgebung ist zum Testen des Ergebniss Ihrer Arbeit in einer nahezu prodierten Umgebung gedacht, was bedeutet, dass keine gemeinsamen Daten zwischen Ihrem lokalen Repository und dem Container festgelegt werden. Darüber hinaus wird die Anwendung mit APPLICTION_ENV=production Produktionssatz ausgeführt, die die Entwicklungsspezifischen Erweiterungen deaktiviert.
Da in einer dockerisierten Umgebung externe Dienste in verschiedenen Adressen abhängig von der Umgebung erreichbar sind, in der der Code ausgeführt wird, muss der Container/das Bild von außen über Umgebungsvariablen konfigurierbar sein. Diese müssen von der Spryker -App konsumiert werden. Daher erwartet dieses Bild spezifische Umgebungsvariablen, die als Docker -Env -Vars injiziert werden und die über eine vorbereitete config_local.php konsistiert werden.
Wir nutzen den spryker -nativen Mechanismus einer Konfigurationsdateihierarchie, die Reihenfolge, Vorrang und das Schema von als Konfigurationsdateien definiert. Dieses Bild bietet eine eigene lokale Konfigurationsdatei von Site, die in diesem Repository unter docker/config_local.php zu finden ist und im resultierenden Docker -Bild unter config/Shared/config_local.php zu finden ist. Da diese Datei diejenige ist, die alle anderen überschreibt.
Die Konfigurationsreihenfolge ist wie die folgenden (zuletzt Prio -Overuts):
config_default.php - Basiskonfigurationconfig_default-development.php - Konfiguration für den Entwicklungsmodus relevant (siehe APPLICATION_ENV )config_local.php - Site Lokale Konfiguration; In diesem Fall ist die Konfiguration für Container -Umgebungen.Mit dieser Reihenfolge können Sie Ihre Konfigurationsdatei unabhängig von der effektiven Umgebung, in der der Shop ausgeführt wird, vollständig verwenden. Sie können sogar unterschiedliches Verhalten zwischen Umgebungen steuern. Wir haben nur die SO -Sagen -Site -lokalen Einstellungen außer Kraft gesetzt, aus denen diese Idee stammt.
Derzeit devel und prod sowohl Umgebungen als auch prodieren nicht genannte Volumina, was auf die Annahme einer vorübergehenden Umgebung zurückzuführen ist. Dies bedeutet, dass der gesamte Stapel für den einzigen Zweck erstellt wird, Ihre Codebasis zu überprüfen. Es ist unter keinen Umständen als ein Setup der Produktionsstufe, bei dem Daten über die Erholung von Containern bestehen müssen !!!
Der angenommene Workflow könnte beschrieben werden als:
docker-compose(1) wurde über das Shell-Skript ./docker/run gewickelt. Dieses Skript bietet Verknüpfungen für die meisten gemeinsamen Aufgaben und achtet auf das lokale Repository und seine Konfiguration:
Nur um das Docker -Bild zu erstellen: ./docker/run build
Dies gilt für beide Umgebungen, da beide auf demselben Bild basieren. Es wird das Haupt-Spryker-Demoshop-Bild sowie ein spezialisiertes Jenkins-Slave-Geschmack aus dem Spryker-Demoshop-Bild aufbauen.
Tatsächlich werden 2 Bilder aufgebaut, eines für das eigentliche Ladenbild, das für die Nginx und die PHP -Behälter sowohl in der YVES als auch in der ZED -Schicht verwendet wird, und eine für den Jenkins -Sklavenbehälter. Letztere erweitert das Ladenbild nur um alle erforderlichen Jenkins -Komponenten, um Jenkins Slave/Arbeiter zu erstellen. Der Grund dafür ist, dass alle Backend -Jobs, die über Jenkins ausgeführt werden, die volle Spryker -Code -Basis erfordern.
Die Bauzeit auf einer regulären Workstation mit SSDs, die eingebaut wurden, dauert für beide Bilder derzeit 10 Minuten.
Wenn Sie an der Basis des Demoshops mit Ihrer eigenen Arbeit beginnen möchten, finden Sie möglicherweise die lokale Entwicklungsumgebung interessant. Mit diesem Setup können Sie Ihre lokale Codebasis in laufenden Containern motivieren und Änderungen an der Codebasis sofort in Kraft setzen.
./docker/run devel up Sie einfach.
Devel -Stapel zerstören, einschließlich aller zugewiesenen namenlosen Bände: ./docker/run devel down -v
Die folgenden Pfade sind in den Behälter gebunden:
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
Falls Sie das Shop -Image wieder aufbauen müssen und nur den Yves und/oder den Zed -Container neu erstellen möchten, während alle Datencontainer (Redis, ES, PSQL) ausgeführt werden: ./docker/run devel rebuild
Wenn Sie diese Container nur wieder herstellen möchten, ohne sie wieder ./docker/run devel recreate
Während /entrypoint.sh Debuggens kann es nützlich sein, anstatt den Container zu überspringen und selbst zu überprüfen. Sie können dies tun, indem Sie den command: run-zed -Richtlinie des betreffenden Containers zum command: sleep 1w in der docker-compose-devel.yml und erstellen Sie den Container durch Laufen ./docker/run devel recreate zed .
docker-compose Da all dies auf docker-compose(1) ./docker/run devel compose exec yves bash
Wenn die Ausgabe des Builds nicht so aussagekräftig ist und Sie eine tiefere Debug -Sitzung benötigen, sollten Sie die folgenden Schritte in Betracht ziehen, um den gestorbenen Zwischenbau Container wieder aufzunehmen:
./docker/run build
# assumed that the last created container is the failed intermediate build container
docker commit $(docker ps -lq) debug
docker run --rm --it debug /bin/sh
Und hier untersuchen Sie die Ursache für den Bauversagen.
Wir haben die Verwendung des Spryker -Installationsprogramms eingeführt. Vor dieser Version haben wir den gesamten Sprykwer -Build-, Installations- und Bereitstellungsprozess in Shell -Skripten in der Basis und im Spryker -Bild gemacht. Dies wurde zugunsten des neuen Spryker -Installationsprogramms fallen, der nichts weiter als einen Vertrag zwischen der Anwendung und der Infrastruktur darstellt. Dieser Vertrag wird ausdrücklich alle notwendigen Maßnahmen ergriffen, um den Laden zu bauen. Wir haben einen solchen Vertrag über eine Installationsroutine über config/installer/claranet.yml erstellt.
Wir haben die Unterstützung von Alpine zugunsten von Debian Stretch fallen lassen! Wenn Sie Alpine benötigen, verwenden Sie die Versionen vor 2.28.0, aber wir unterstützen Alpine nicht weiter.
ANMERKUNG: Das übergeordnete Bild wurde von claranet/spryker-base zu claranet/php umgeschaltet, das die vorherige Struktur docker/ Dateisystems durchbricht! Wir haben diesen Weg gewählt, weil das frühere Basisbild noch weiter verallgemeinert werden könnte, um nicht nur die Spryker -Anforderungen, sondern auch die Anforderungen an PHP -basierte Anwendungsanforderungen entsprechen zu können.
Wenn Sie einen Fehler finden, der hier nicht aufgeführt ist, melden Sie ihn bitte!
Wir werden den Demoshop erst versenden, bis https://bugs.php.net/bug.php?id=76029 repariert ist und wir Opcache aktivieren können. OPCache ist in Produktumgebungen unerlässlich und es ist nicht sinnvoll, 7.2 in Dev und 7.1 in der Produktion zu verwenden ...
Da Spryker Demoshop 2.32 scheint, gibt es einen Fehler, der dazu führt, dass der Opcache Ausnahmen wirft. Wir waren also gezwungen, Opcache zu deaktivieren.
