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
这适用于这两个环境，因为两者都基于同一图像。它将从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。
