spryker base
1.0.0
重要说明：该项目已弃用！请使用claranet/spryker-demoshop作为引导参考或我们的claranet/php父映像，以进行更通用的PHP用例！我们不再维护这个项目了。
该图像的目的是为YVE和ZED提供基础基础架构。在构建/初始化脚本以及商店本身周围的进一步工具方面，基础架构。此图像无法提供准备使用的商店！为了使用此处实现的功能，请沿Spryker Shop的实际实施来编写自己的Dockerfile （使用此基本图像来继承）。
该项目仍在Beta中，可能会发生破坏变化！
这就是为什么我们渴望从您那里得到反馈！这是一项正在进行的工作，致力于使Spryker商店尽可能容易地进行码头。为了成功实现此目标，我们需要确定值得概括并放入此基础图像中的共同步骤。因此，请告诉我们您的需求和经验。
如果您想在操作中查看此图像以及如何使用它，请查看集装箱的Spryker Demoshop。该Demoshop用作基本图像的参考实现。与Spryker一起进行捆绑并使Demoshop以完全相同的方式使用Demoshop的方式相同。
核心特征是：
ONBUILD触发功能来连接和控制儿童图像构建过程容器化的好处：
第一个前提是，我们决定从一个图像中为YVE和ZED容器提供服务。好处是始终在整个集群中始终升级共享代码基础。折衷是图像稍大，因为必须包括两个组件的要求。
另一个前提是 - 这对于您对此堆栈的理解至关重要 - 在开发和生产环境中构建一个统一的图像。这会影响APPLICATION_ENV的使用情况，该应用程序由Spryker应用程序本身评估。
该变量具有以下影响：
本地配置文件和外部资源的位置无需在容器化环境中额外考虑，因为无论如何这些堆栈都是隔离的。因此，请确保在./config/Shared/下没有配置语句将使用APPLICATION_ENV来识别其路径！！！
我们仅认为1.1点值得一提。而且，由于将适当的VAR注入有效的容器中可以实现，因此我们在构建图像时不会区分环境。由于点1.1通常需要更多的依赖项，因此我们始终将图像构建为APPLICATION_ENV设置为development 。但是，在哪种模式下，应用程序将实际运行是独立于构建的。
这意味着即使生产容器也将包含DEV依赖项。造成这种情况的主要原因是需要开发/测试/产品奇偶校验，以确保在所有阶段和所有环境中这些容器的行为完全相同。此前提的权衡再次是更大的有效图像。在运行时，可以通过设置接受development或production APPLICATION_ENV来控制Spryker应用程序的行为。如果使用./docker/run脚本，则将自动设置此变量。
prod此中提供的脚本背后devel想法./shop/docker这些环境在docker-compose方面的主要区别是在DEVEL模式下使用BIND安装座，这使开发人员能够在容器内的后台运行代码时从外部编辑代码库。
由于这种设置努力减少手动努力，因此我们准备了Shell Scripts，该脚本呈现必要的逻辑，并为您提供捷径，以完成最常见的任务，例如构建图像或创建或拆除容器设置。查看./docker/run help
prod环境旨在在近乎生产的环境中测试您的工作结果，这意味着将在本地存储库和容器之间建立任何共享数据。此外，将使用APPLICTION_ENV=production集运行该应用程序，从而禁用开发特定的扩展名。
该基础图像引入的概念是将所得的商店图像拆分为3个不同的层（实际上，只有3层不止3层，因为Dockerfile中的每个语句都会产生一个新层；但是3个不同层的想法更容易且易于理解，因此，3个不同的图层摘要）。有两个原因：
首先，它应该利用Docker Cache并加快商店图像的迭代重建。由于这些层是从通用到特定的，因此应减少在实际商店实施的代码基础上进行迭代工作时对整个堆栈进行重建的需求。
其次，在拉动图像时可以并行检索不同的层，这加快了容器创建时间的速度，这不仅与本地开发有关，而且与生产设置的部署相关。此外，由于通用层不会经常改变，因此不仅需要重建，而且还应减少整个图像。
不幸的是，这并非没有成本，有效的图像大小将略高于仅一层构建的图像大小。现在，这似乎是可以接受的权衡。
这些层的责任是什么？它们在哪里，何时建造？
claranet/spryker-base （此图像）：claranet/spryker-demoshop （下游商店图像，例如Demoshop）：spryker-base图像中覆盖基层（请注意$REBUILD_BASE_LAYER构建变量）如果您需要从私人存储库中提取PHP或节点依赖性，则只需提供~/.netrc即可。当Docker Build Arg注入到瞬态构建容器中，GIT用于克隆适当的存储库，然后在关闭层之前，将自动检测并暂时检测到该文件，并将其用于克隆适当的存储库。
$HOME/.netrc的格式如下：
machine git.company.local
login my_user_name
password my_private_token
为了生效，所有给定的依赖项必须以HTTP URL给出，或者它们通过git config --global "url.https://".insteadof "git://git@进行转换。
如果要添加更具体的规则，请在依赖关系层中创建一个构建脚本，该脚本在依赖项解决过程之前执行：
vi docker/build.d/deps/300_private_repo_override.sh
#!/bin/sh
sectionText "Diverting git transport from SSH to HTTPS: https://git.company.local"
git config --global "url.https://git.company.local/".insteadof "[email protected]:"
git config --global "url.https://git.company.local".insteadof "ssh://[email protected]"
由于可以通过任意组合给出git URL，因此在某些情况下是必要的。
这一切都是必要的，因为Docker拒绝实施构建时间量，这将使此过程更加容易。但是他们确实得到了惊人的原因，因为这样的功能可能会冒着可重复性的可能性，因为Dockerfile并不是构建结构的唯一来源。 IS - 就像在任何技术论点中一样 - 没有绝对的真理，只有权衡。
由于在扩展的环境中，外部服务可在不同的地址上到达，具体取决于代码在环境中运行的环境，因此我们需要调整一些配置。因此，我们使用配置文件优先级的Spryker本机机制，以通过网站本地配置文件config/Shared/config_local.php注入我们的配置。由于此文件是覆盖所有其他文件的文件。
配置顺序如下：
config_default.php基本配置config_default-development.php与开发模式相关的配置（请参阅APPLICATION_ENV ）config_local.php网站本地配置;在这种情况下，它是容器化环境的配置。此订单使您可以完全独立于商店将要运行的有效环境完全使用配置文件。您甚至可以控制环境之间的不同行为。我们只是覆盖了SO来说本地设置，这个想法来自于此。
为此，我们需要删除.gitignore列表的config/Shared/config_local.php 。
目前，由于假设瞬态环境，这两种环境都使用未命名的体积devel和prod 。这意味着，整个堆栈的创建是为了检查您的代码碱基的唯一目的。它在任何情况下都不意味着某些生产等级设置，在该设置中，数据需要在容器的娱乐中持续存在！！！
假定的工作流可以描述为：
为了重用此处实施的功能，需要将以下方面与基本图像保持一致：
./src/Pyz您的商店实施./config配置./public/{Yves,Zed} - 应用程序的入口点composer.json和composer.lockpackages.json ， packages.lock and yarn.lock./docker/build.conf依赖项（PHP扩展，节点deps等。pp。）./docker/build.d/下，控制图像的构建过程./docker/init.d/下，控制设置的初始化过程查看我们准备在此处使用此图像的Demoshop。这应该回答您可能遇到的所有问题。
由于参考实现是我们维护的Demoshop，因此这是一个很好的入门者。通过仅分配此存储库或从头开始。
如果您想从头开始启动您从Demoshop中需要的唯一感兴趣的文物：
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.php这样，您准备使用代码填充存储库，并根据您的个人需求进行自定义。
注意看起来像这样干净的Dockerfile ：
FROM claranet/spryker-base:latest
这闻起来像可重复使用。 :)
商店的骨骼和Demoshop以及./docker/run下的Shell脚本，为您提供最常见的任务的快捷方式。请查看readme.md，以获取更多详细信息。
# Build the image
./docker/run build
# Run the demoshop in development mode
./docker/run devel up
# Stop all the containers of the demoshop including their artifacts
./docker/run devel down -v
这些变量将在容器创建期间作为环境变量提供。
大多数变量由config/Shared/config_local.php文件消耗：
APPLICATION_ENV="production"SPRYKER_SHOP_CC="DE"ZED_HOST="zed"YVES_HOST="yves"ES_HOST="elasticsearch"ES_PROTOCOL="http"ES_PORT="9200"REDIS_STORAGE_PROTOCOL="tcp"REDIS_STORAGE_HOST="redis"REDIS_STORAGE_PORT="6379"REDIS_STORAGE_PASSWORD=""REDIS_SESSION_PROTOCOL="tcp"REDIS_SESSION_HOST="redis"REDIS_SESSION_PORT="6379"REDIS_SESSION_PASSWORD=""ZED_DB_USERNAME="postgres"ZED_DB_PASSWORD=""ZED_DB_DATABASE="spryker"ZED_DB_HOST="database"ZED_DB_PORT="5432"JENKINS_URL="http://jenkins:8080/"RABBITMQ_HOST="rabbitmq"RABBITMQ_PORT="5672"RABBITMQ_USER="spryker"RABBITMQ_PASSWORD=""YVES_SSL_ENABLED="false"YVES_COMPLETE_SSL_ENABLED="false"ZED_SSL_ENABLED="false"ZED_API_SSL_ENABLED="false"被初始化钩子消耗：
ZED_ADMIN_PASSWORD如果设置[email protected]的默认密码将被重置用户ENABLE_XDEBUG将激活和配置PHP模块xdebug 。ENABLE_OPCACHE PHP模块opcache将被激活和配置。这些变量应通过您的项目特定为./docker/build.conf提供
PROJECT （强制性） - 控制docker-compose创建服务的名称前缀IMAGE （强制性） - 由此产生的Docker图像的名称是什么？VERSION （强制性） - 我们正在使用哪个版本的Docker映像？BUILD_DEPENDENCIES构建时间期间要安装的分发（debian）软件包BASE_DEPENDENCIES额外安装的分发（debian）软件包PHP_EXTENSIONS要安装的PHP扩展名列表NPM_DEPENDENCIES分发包将在deps层中的NPM处理之前进行插入KEEP_DEVEL_TOOLS （默认值：false） - 是否应安装开发工具并保持超越构建？SKIP_CLEANUP （默认值：false） - 在每个层构建阶段跳过清理步骤。这有助于调试问题。请注意，这也跳过了凭证！所以永远不要将这样的图像释放到野外！！！CRONJOB_HANDLER定义应在哪里注册cronjob。目前，詹金斯和克朗德得到了支持。REBUILD_BASE_LAYER如果给出了此构建var，则基本层将在下游商店构建期间重建为了控制NGINX，PHP-FPM或PHP的行为，您可以从容器的外部以绑定安装为单位进行注入配置，也可以通过Child Shop Image的Dockerfile进行注入。
服务的配置准备包括几个构成有效配置的文件。
所有相关文件都将在特定目录中预期所有配置
预期的位置是：
/etc/nginx/spryker/yves.conf.d/*.conf/etc/nginx/spryker/zed.conf.d/*.conf/etc/php/fpm/yves.conf.d/*.conf/etc/php/fpm/zed.conf.d/*.conf/etc/php/ini/*.ini 。默认配置应在以下位置找到：
/etc/php/fpm/zed.conf.d/100_base.conf
/etc/php/fpm/zed.conf.d/200_pm.conf
/etc/php/fpm/zed.conf.d/300_php.conf
/etc/php/fpm/yves.conf.d/100_base.conf
/etc/php/fpm/yves.conf.d/200_pm.conf
/etc/php/fpm/yves.conf.d/300_php.conf
/etc/php/ini/xdebug.ini
/etc/php/ini/opcache.ini
/etc/nginx/spryker/zed.conf.d/500-default.conf
/etc/nginx/spryker/yves.conf.d/500_default.conf
在您只能将完整目录安装到容器中的环境中，我们已经准备了一种机制，该机制期望在/mnt/configs下一个目录层次结构，并且在容器创建上，它可以将此位置下的所有文件符合/etc/的相应位置。
# For example:
/mnt/configs/nginx/zed.conf.d/600-custom-headers.conf --> /etc/nginx/zed.conf.d/600-custom-headers.conf
/mnt/configs/php/fpm/yves.conf.d/500-raise-processes.conf --> /etc/php/fpm/yves.conf.d/500-raise-processes.conf
由于分层文件系统的性质，从此基础图像继承的子图像可以简单覆盖配置，以实现这些服务的所需行为。
可以通过Dockerfile独自提供配置文件来轻松自定义这些：
FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf
由于Onbuild Trigger将是要执行的Child Dockerfile的第一个指令，因此这些被限制的文件将首先在容器的运行时提供。
基本图像中做出的大多数设计决策都由可定制性和可扩展性的想法约束。只能用于单个商店图像的基本图像非常毫无用处，并且远离所谓的基础。
构建过程几乎是名称所暗示的过程，该过程产生图像，该过程在运行时在以后的运行时共享。
一些构建脚本考虑您可以在./docker/build.conf中设置的参数
请参阅上面的参考。
Hook Dir： ./docker/build.d/ build.d/
如果您要么要扩展从基本图像继承的构建步骤，或者要禁用它们，则需要将自定义构建脚本放在./docker/build.d/下。在那里，您会找到3个反映每个阶段/层的目录：
./docker/build.d/base/基础OS级安装./docker/build.d/deps/处理特定的php/节点依赖关系./docker/build.d/shop/处理实际商店代码库的代码生成每个子dir的脚本被执行（Actuall采购）。
例如，如果要更改基本图像的导航缓存的方式，则必须在基本映像下提供的位置提供一个脚本./docker/build.d/shop/650_build_navigation_cache.sh 。由于所得的图像以及容器将使用联合文件系统，因此商店图像提供的文件优先于BAS图像提供的文件。通过这种机制，您可以通过提供无用的脚本来禁用功能，或者您可以通过添加脚本来改变行为，该脚本对某些方式进行不同或另外的操作。
可以采用上述相同的机制来改变Spryker容器的初始化和整个设置的初始化方式。基本图像带有有意义的默认值对共同环境有效，但可以通过在适当的位置放置自定义脚本来覆盖。
基本图像为这两者提供了钩子，每个容器的初始化以及整个设置的初始化。
Hook Dir： ./docker/entry.d/ entry.d/
运行时入口处参数（ run-yves ， run-zed ， run-yves-and-zed ， run-cron ）管理该实际容器所具有哪个角色，所有这些都源于此挂钩目录中列出的文件。通过变量，脚本决定要启用哪些服务并在运行时启动。
一个常见的任务是按照容器创建的Env var ENABLE_XDEBUG启用xdebug 。
由于性质，每个容器启动时将执行所有钩子。
Hook Dir： ./docker/init.d/ init.d/
通常，每个商店实例都需要执行初始步骤以初始化此类商店。在此设置范围内，挂钩DIR下的所有Shell脚本都将执行。例如，使用DemoShop（例如Demoshop）在./docker/init.d/500_import_demo_data.sh下将数据库初始化数据库。
这不是明智地完成的，必须使用入口点arg init产生单独的容器。
Hook Dir： ./docker/deploy.d/ deploy.d/
与初始过程相同的是部署程序。该程序将在部署期间进行。生命周期概念由这两个挂钩组成：初始化将首次调用，每次将进行新版本的图像。
这不是明确地进行的，必须使用入口点ARG deploy来产生单独的容器。
如前所述，您可以自由添加非常自定义的构建和初始步骤。 ./docker/common.inc.sh脚本将为您提供一些有用的功能。自己检查一下。
通过使用准备好的输出功能来讲述您的构建步骤：
errorText提出错误successText寄回成功sectionHead一组任务的打印标题sectionText打印中间构建步骤信息我们为所有包含的构建步骤提供一个install_packages函数。请确保您正在使用它！它具有将软件包作为“构建”依赖项标记的可能性。在层构建完成后，将删除以构建依赖性标记的软件包。将标志包作为构建依赖项的标记，仅设置为第一个参数： --build ：
# remove "gcc" at the end of our image build
install_packages --build gcc
# keep "top" in the resulting image
install_packages top
我们仍处于该项目的早期阶段，因此文档可能不完整。如果您想了解有关我们提供的功能的更多信息，请查看Shell库。
在YVE/ZED实例中，您可以在/data/logs/
我们取决于官方PHP图像：https：//hub.docker.com/__/php/
确实很好的问题！
由于图像构建时间较短 - 源构建和包装安装，我们决定选择高山。应该证明，这或多或少是概念验证，即使是繁重的起重项目也可以在高山上托管。预期的好处是减少图像尺寸和更快的构建时间以及更快的运行时间。
不幸的是，事实证明，Musl Lib C引入了限制，这些限制在客户环境中难以忍受 - 多功能性是关键。由于0.9.6，我们已切换到基于Debian的图像。
想到了两件事：
很快还会出现。 :)
请查看 /问题。
