spryker base

Docker Image Claranet/Spryker基礎

重要說明：該項目已棄用！請使用claranet/spryker-demoshop作為引導參考或我們的claranet/php父映像，以進行更通用的PHP用例！我們不再維護這個項目了。

• 什麼？
• 為什麼？
• 設計
  • Docker圖像
  • 建立時間環境
  • 運行時環境
  • 構建層
  • 私人存儲庫
  • Spryker配置
  • Docker卷
• 會議
• 創建您的自定義圖像
• 構建與運行
• 配置
  • 運行時環境變量 - 參考
  • 構建時間變量 - 參考
  • 注入自定義配置
    • 外部卷
    • 子圖像覆蓋
• 定制
  • build.conf
  • 建立步驟
  • init
    • 容器級別
    • 設置寬
  • 部署
  • 自定義構建步驟
    • 記錄
    • 安裝其他軟件包
• 在這裡沒有記錄嗎？
• 常問問題
  • 在哪裡可以找到日誌？
  • 您正在使用哪個基本圖像？
  • 為什麼不再使用高山呢？
  • 如何進一步加快圖像構建？
• 問題

什麼？

該圖像的目的是為YVE和ZED提供基礎基礎架構。在構建/初始化腳本以及商店本身周圍的進一步工具方面，基礎架構。此圖像無法提供準備使用的商店！為了使用此處實現的功能，請沿Spryker Shop的實際實施來編寫自己的Dockerfile （使用此基本圖像來繼承）。

該項目仍在Beta中，可能會發生破壞變化！

這就是為什麼我們渴望從您那裡得到反饋！這是一項正在進行的工作，致力於使Spryker商店盡可能容易地進行碼頭。為了成功實現此目標，我們需要確定值得概括並放入此基礎圖像中的共同步驟。因此，請告訴我們您的需求和經驗。

如果您想在操作中查看此圖像以及如何使用它，請查看集裝箱的Spryker Demoshop。該Demoshop用作基本圖像的參考實現。與Spryker一起進行捆綁並使Demoshop以完全相同的方式使用Demoshop的方式相同。

核心特徵是：

• 提供最常見的PHP模塊的PHP運行時環境
• 使用Dockers ONBUILD觸發功能來連接和控制兒童圖像構建過程
• 提供合理的默認FPM/NGINX配置
• 它通過提供可鉤構建，初始化和配置步驟來開放自定義
• 期望像spryker-demoshop這樣的基礎結構
• 沒有進一步的限制，您絕對可以自由地設計自己的購物方式

為什麼？

容器化的好處：

• 一致性
• 可重複性
• Portablity
• 無縫部署形成本地開發到產品環境中

設計

Docker圖像

第一個前提是，我們決定從一個圖像中為YVE和ZED容器提供服務。好處是始終在整個集群中始終升級共享代碼基礎。折衷是圖像稍大，因為必須包括兩個組件的要求。

建立時間環境

另一個前提是 - 這對於您對此堆棧的理解至關重要 - 在開發和生產環境中構建一個統一的圖像。這會影響APPLICATION_ENV的使用情況，該應用程序由Spryker應用程序本身評估。

該變量具有以下影響：

1. 在構建時間期間：
   1. 通過依賴項分辨率（Composer，NPM）將安裝哪些軟件包？
   2. 資產建設中的不同模式
2. 在運行時間：
   1. 應用程序將在哪裡找到配置文件（Propel Config）？
   2. 在哪裡可以找到外部資源？
   3. 該應用程序是否可以啟用Symfony Debug/Devel行為？

本地配置文件和外部資源的位置無需在容器化環境中額外考慮，因為無論如何這些堆棧都是隔離的。因此，請確保在./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 （此圖像）：
  • 基礎層 - 安裝所有OS級基礎基礎架構，PHP和最常見的模塊。
• claranet/spryker-demoshop （下游商店圖像，例如Demoshop）：
  • 基礎層 - 安裝其他PHP模塊和/或從spryker-base圖像中覆蓋基層（請注意$REBUILD_BASE_LAYER構建變量）
  • 依賴層 - 解決所有商店特定的PHP/節點依賴關係
  • 代碼層 - 構建商店特定代碼，例如ORM，Tranfer對象

私人存儲庫

如果您需要從私人存儲庫中提取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配置

由於在擴展的環境中，外部服務可在不同的地址上到達，具體取決於代碼在環境中運行的環境，因此我們需要調整一些配置。因此，我們使用配置文件優先級的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 。

Docker卷

目前，由於假設瞬態環境，這兩種環境都使用未命名的體積devel和prod 。這意味著，整個堆棧的創建是為了檢查您的代碼鹼基的唯一目的。它在任何情況下都不意味著某些生產等級設置，在該設置中，數據需要在容器的娛樂中持續存在！ ！ ！

假定的工作流可以描述為：

1. 創建環境
2. 用虛擬數據初始化
3. 發展代碼庫
4. 迭代：重建 - >運行 - > init->進化
5. 破壞環境

會議

為了重用此處實施的功能，需要將以下方面與基本圖像保持一致：

• 關注Spryker參考目錄層次結構
  • ./src/Pyz您的商店實施
  • ./config配置
  • ./public/{Yves,Zed} - 應用程序的入口點
• 依賴性
  • PHP： composer.json和composer.lock
  • 節點： packages.json ， packages.lock and yarn.lock
• 使Spryker配置考慮Env vars。結帳shop_skel/config/config/shardy/config_local.php，示例這一點的含義
• 控制您要安裝./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進行注入。

外部卷

服務的配置準備包括幾個構成有效配置的文件。

所有相關文件都將在特定目錄中預期所有配置

預期的位置是：

• nginx
  • /etc/nginx/spryker/yves.conf.d/*.conf
  • /etc/nginx/spryker/zed.conf.d/*.conf
• PHP FPM
  • /etc/php/fpm/yves.conf.d/*.conf
  • /etc/php/fpm/zed.conf.d/*.conf
• php ini
  • /etc/ /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的第一個指令，因此這些被限制的文件將首先在容器的運行時提供。

定制

基本圖像中做出的大多數設計決策都由可定制性和可擴展性的想法約束。只能用於單個商店圖像的基本圖像非常毫無用處，並且遠離所謂的基礎。

build.conf

構建過程幾乎是名稱所暗示的過程，該過程產生圖像，該過程在運行時在以後的運行時共享。

一些構建腳本考慮您可以在./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圖像提供的文件。通過這種機制，您可以通過提供無用的腳本來禁用功能，或者您可以通過添加腳本來改變行為，該腳本對某些方式進行不同或另外的操作。

init

可以採用上述相同的機制來改變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的圖像。

如何進一步加快圖像構建？

想到了兩件事：

• 使用緩存HTTP請求的本地代理
• 使用擬議的Docker多階段構建

很快還會出現。 :)

問題

請查看 /問題。