spryker demoshop
1.0.0
docker-compose的接口要求：在Linux或MacOS系統上，最新的，穩定的Docker和Docker-Compose（帶有Docker-Compose.yml 3.4支持）。
由於此堆棧非常複雜，包括完全旋轉的ES，因此至少需要4GB的內存。如果您在Windows/MacOS上運行Docker，請相應地調整設置。
如果滿足要求，經營商店非常容易。只需輸入以下步驟：
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
這樣可以將Docker映像，創建網絡，創建所有容器，將您的本地代碼安裝到容器中，以使您可以從外部進行實時播放，將容器連接到彼此，並最終公開公共服務。像Yves，Zed，Jenkins-Master，PostgreSQL和Elasticsearch。
在創建Spryker堆棧時，請耐心等待，因為初始化例程需要很多時間才能將所有數據導入到數據庫中，然後導出到Redis和Elasticsearch。目前，這大約需要10分鐘。
初始化完成後，您可以將瀏覽器指向以下URL：
這是Spryker Demoshop的正式參考實現的對接版本。它可以通過自動拉動所有必需的依賴項並創建一個包括PostgreSQL，Redis，Elasticsearch和Jenkins的堆棧來開箱即用。在運行時，每個服務都會初始化。
您可以將此存儲庫用作基於Spryker Commerce OS的範式商店的演示，也可以用作開發自己實現的起點，從Demoshop的叉子開始。
構建和啟動過程以及進一步的工具是從Claranet/PHP圖像繼承的。在這裡，您會在此Dockerization背後找到技術設計思想，並回答了其他觀點，例如：
docker/文件系統結構容器化的好處：
Docker-Compose堆棧正在公開多種服務。為了並行運行堆棧並防止端口碰撞，我們需要對齊端口分配。
因此，已經實施了以下方案：端口號是這樣編碼的： ECCDD
因此，可以通過http：// localhost：20100/and yves我們通過http：// localhost：20102來達到Yves de。
注意：按端口劃分的商店/域之間的差異僅適用於本地開發環境。 Claranet提供的實際生產等級堆棧是根據實際域名進行這種區別。
中心前提是 - 這對於您對堆棧的理解至關重要 - 在開發和生產環境中構建一個統一的圖像。這會影響APPLICATION_ENV的使用情況，該應用程序由Spryker應用程序本身評估。
該變量具有以下影響：
本地配置文件和外部資源的位置無需在容器化環境中額外考慮，因為無論如何這些堆棧都是隔離的。因此，請確保在./config/Shared/下沒有配置語句將使用APPLICATION_ENV來識別其路徑！ ！ ！
我們僅認為1.1點值得一提。而且，由於將適當的VAR注入有效的容器中可以實現，因此我們在構建圖像時不會區分環境。由於點1.1通常需要更多的依賴項，因此我們始終將圖像構建為APPLICATION_ENV設置為development 。但是，在哪種模式下，應用程序實際上將是獨立的。
這意味著即使生產容器也將包含開發依賴性。造成這種情況的主要原因是需要開發/測試/產品奇偶校驗，以確保在所有階段和所有環境中這些容器的行為完全相同。此前提的權衡再次是更大的有效圖像。
在運行時，可以通過設置接受development或production APPLICATION_ENV來控制Spryker應用程序的行為。如果使用./docker/run腳本，則將自動設置此變量。
通過./docker/run提供的包裝腳本背後的想法是devel和prod環境之間的基本區別。這些環境在docker-compose方面的主要區別是在DEVEL模式下使用BIND安裝座，這使開發人員能夠在容器內的後台運行代碼時從外部編輯代碼庫。
由於這種設置努力減少手動努力，因此我們準備了Shell Scripts，該腳本呈現必要的邏輯，並為您提供捷徑，以完成最常見的任務，例如構建圖像或創建或拆除容器設置。查看./docker/run help
prod環境旨在在近乎生產的環境中測試您的工作結果，這意味著將在本地存儲庫和容器之間建立任何共享數據。此外，將使用APPLICTION_ENV=production集運行該應用程序，從而禁用開發特定的擴展名。
由於在模塊化的環境中，外部服務可在不同的地址上取決於代碼所在的環境，因此需要通過環境變量從外部配置容器/圖像。這些需要由Spryker應用程序消費。因此，此圖像期望將特定的環境變量注入Docker env vars，並通過準備好的config_local.php將其保存。
我們正在利用配置文件層次結構的Spryker本機機制，該機制定義了順序，優先級和要考慮配置文件的方案。此圖像提供了自己的網站本地配置文件，可以在docker/config_local.php下的此存儲庫中找到，並且可以在config/Shared/config_local.php下的結果docker image中找到。由於此文件是覆蓋所有其他文件的文件。
配置順序如下（最後一次超過PRIO）：
config_default.php基本配置config_default-development.php與開發模式相關的配置（請參閱APPLICATION_ENV ）config_local.php網站本地配置;在這種情況下，它是容器化環境的配置。此訂單使您可以完全獨立於商店將要運行的有效環境完全使用配置文件。您甚至可以控制環境之間的不同行為。我們只是覆蓋了SO來說本地設置，這個想法來自於此。
目前，由於假設瞬態環境，這兩種環境都使用未命名的體積devel和prod 。這意味著，整個堆棧的創建是為了檢查您的代碼鹼基的唯一目的。它在任何情況下都不意味著某些生產等級設置，在該設置中，數據需要在容器的娛樂中持續存在！ ！ ！
假定的工作流可以描述為：
docker-compose(1)已通過Shell腳本包裝./docker/run 。該腳本為大多數常見任務提供快捷方式，同時關注本地存儲庫及其配置：
只是為了構建Docker映像使用： ./docker/run build build
這適用於這兩個環境，因為兩者都基於同一圖像。它將從Spryker-Demoshop圖像中構建主要的Spryker-Demoshop圖像以及專門的Jenkins-Slave風味。
實際上正在構建2張圖像，一個用於實際的商店圖像，該圖像用於NGINX和YVE和ZED層中的PHP容器，另一幅用於Jenkins Slave容器。後者僅通過所有必需的Jenkins組件擴展商店圖像，以創建Jenkins Slave/Worker。在實際商店圖像之上這樣做的原因是，所有通過Jenkins運行的後端作業都需要完整的Spryker代碼庫。
在常規工作站上建造的SSD的構建時間目前需要10分鐘的時間，這兩張圖像都需要10分鐘。
如果您想根據Demoshop開始自己的工作，則可能會發現本地開發環境很有趣。此設置使您可以將本地代碼庫安裝到運行的容器中，並立即查看代碼庫的更改。
只需運行./docker/run devel up即可。
銷毀Devel堆棧，包括所有分配的未命名卷： ./docker/run devel down -v
以下路徑被安裝到容器中：
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
如果您需要重建商店圖像，並且只想重新創建Yves和/或ZED容器，同時使所有數據容器（Redis，ES，PSQL）運行： ./docker/run devel rebuild
如果您只想在不重建它們的情況下重新創建這些容器： ./docker/run devel recreate
在調試時，它可能很有用，而不是讓/entrypoint.sh初始化容器以跳過此步驟並檢查自己。您可以通過更改command: run-zed指令，以命令：在docker-compose-devel.yml中command: sleep 1w ，然後通過運行./docker/run devel recreate zed容器。
docker-compose的接口由於所有這些都基於docker-compose(1)您可能需要自己調用它，例如，通過shell進入容器： ./docker/run devel compose exec yves bash
如果構建的輸出不是說明的，而您需要更深入的調試會話，請考慮以下步驟以復活已故的中間構建容器：
./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
在這裡，您可以調查構建故障的原因。
我們介紹了Spryker安裝程序的用法。在此版本之前，我們將整個Sprykwer構建，安裝和配置過程列在位於基礎和Spryker映像中的Shell腳本中。這已被刪除，支持新的Spryker安裝程序，該安裝程序無非是應用程序和基礎架構之間的合同。這份合同明確地將所有必要的措施都明確地建立了。我們已經通過config/installer/claranet.yml準備了安裝例程的合同。
我們放棄了高山的支持，支持Debian Stretch！如果您需要高山，請在2.28.0之前使用版本，但我們不會進一步支持高山。
另請注意：父映像從claranet/spryker-base切換到claranet/php ，它破壞了先前的docker/ Filesysty Suncord！我們之所以選擇這條路徑，是因為以前的基本圖像可以進一步概括以符合Spryker的要求，還可以符合任何基於PHP的應用程序要求。
如果您在此處找到未列出的錯誤，請報告它們！
直到https://bugs.php.net/bug.php?id=76029已固定，我們才能啟用Opcache。 OPCACHE在產品環境中至關重要，在DEV中使用7.2和7.1在生產中是沒有意義的...
由於Spryker Demoshop 2.32似乎似乎有一個錯誤導致Opcache引發異常。因此，我們被迫禁用Opcache。
