spryker base
1.0.0
Важное примечание: этот проект устарел! Пожалуйста, используйте claranet/spryker-demoshop в качестве ссылки на начальную загрузку или наше родительское изображение claranet/php для более общего варианта использования PHP! Мы больше не поддерживаем этот проект.
Это изображение служит целью обеспечения базовой инфраструктуры для Ива и Зеда. Инфраструктура с точки зрения сценариев сборки/инициирования и дальнейшего инструмента вокруг самого магазина. Это изображение не обеспечивает готового к использованию магазин! Чтобы использовать функции, реализованные здесь, напишите свой собственный Dockerfile - который использует это базовое изображение, чтобы наследовать - по вашей реальной реализации магазина Spryker.
Этот проект все еще находится в бета -версии и будет подвергаться возможным нарушениям!
Вот почему мы стремимся получить от вас отзывы! Это работа в процессе работы, которая стремится сделать так, чтобы сделать так же проще в магазине 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. Основной причиной этого является требование для Dev/Test/Prod Carity, чтобы гарантировать, что контейнеры ведут себя точно так же на всех этапах и во всех средах. Компромисс для этой предпосылки опять же более крупные эффективные изображения. Во время выполнения поведение приложения Spryker можно контролировать путем установки APPLICATION_ENV , который принимает либо development , либо production . Если вы используете скрипт ./docker/run эти переменные будут установлены автоматически.
Идея сценариев, представленных в этом ./shop/docker , следуют основному различию между средами devel и prod . Основное различие между этими средами с точки зрения docker-compose заключается в использовании применения привязки в режиме развития, что позволяет разработчику редактировать базу кода извне во время запуска кода в фоновом режиме в контейнерах.
Поскольку эта установка стремится к сокращению ручных усилий, мы подготовили сценарии оболочек, которые делают необходимую логику и поддерживают вас ярлыками для наиболее распространенных задач, таких как создание изображения или создание или разрыв установки контейнера. Проверьте ./docker/run help
Среда prod предназначена для тестирования результата вашей работы в среде почти до производства, что означает, что общие данные между вашим локальным хранилищем и контейнером не будут установлены. Кроме того, приложение будет запущено с помощью набора APPLICTION_ENV=production , которое отключает конкретные расширения разработки.
Концепция, представленная этим базовым изображением, состоит в том, чтобы разделить результирующее изображение магазина на 3 различных слоя (эффективно существует более 3 слоев, поскольку каждое утверждение в Dockerfile приводит к новому слою; но идея 3 различных слоев абстрактных логики триггеров на билд. Есть несколько причин для этого:
Во -первых, он должен использовать кеш Docker и ускорить итерационные восстановления изображения магазина. Поскольку эти слои заказаны от общего до конкретного, необходимость восстановления всего стека при итеративной работе над базой кода фактической реализации магазина должна быть уменьшена.
Во -вторых, различные слои могут быть извлечены в параллельно при вытяжении изображения, что ускоряет время создания контейнера, которое имеет отношение не только к местному развитию, но и для развертывания производственной установки. Кроме того, поскольку общие слои не меняются часто, необходимость не только для восстановления, но и для переизбывания всего изображения также должно быть уменьшено.
К сожалению, это не без затрат, эффективный размер изображения будет немного выше, чем тот, который будет создан только одним слоем. Прямо сейчас это кажется приемлемым компромиссом.
Каковы обязанности этих слоев и где они находятся и когда они будут построены?
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
Чтобы вступить в силу, все заданные зависимости должны быть даны либо в виде URL -адреса HTTP, либо они преобразуются с помощью 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]"
Поскольку URL -адреса GIT могут быть даны в произвольной комбинации, это в некоторых обстоятельствах необходимо.
Все это необходимо, потому что Docker отказывается реализовать объемы времени сборки, что облегчит этот процесс. Но они действительно получили поразительные причины, так как такая функция рискует воспроизводимость, потому что Dockerfile не является единственным источником строительных сооружений. IS - как в любом техническом аргументе - без абсолютной правды, только компромиссы.
Поскольку в придаче, внешние службы доступны по разным адресам в зависимости от среды, в которой используется код, нам нужна некоторая конфигурация, которая будет скорректирована. Поэтому мы используем нативный механизм приоритета файла конфигурации Spryker, чтобы ввести нашу конфигурацию через сайт локальный файл config/Shared/config_local.php . Поскольку этот файл - тот, который переопределяет все остальные.
Заказ на конфигурацию как следующее:
config_default.php - базовая конфигурацияconfig_default-development.php - конфигурация, соответствующая режиму разработки (см. APPLICATION_ENV )config_local.php - локальная конфигурация сайта; В этом случае его конфигурация для контейнерной среды.Этот заказ позволяет вам использовать ваш файл конфигурации полностью независимо от эффективной среды, в которой будет работать магазин. Вы даже можете контролировать различное поведение между средами. Мы просто переопределяем SO, чтобы сказать локальные настройки сайта, из которых возникает эта идея.
Для этого нам нужно было удалить config/Shared/config_local.php из списка .gitignore .
В настоящее время обе среды devel и prod используя неназванные тома, что связано с предположением о переходной среде. Это означает, что весь стек создается для единственной цели проверки базы вашего кода. Он при каких -либо обстоятельствах не предназначен для некоторой настройки производственного уровня, где данные должны сохраняться в отношении воссозданий контейнеров !!!
Предполагаемый рабочий процесс можно описать как:
Чтобы повторно использовать функциональные возможности, реализованные здесь, следующие аспекты должны быть выровнены с базовым изображением:
./src/Pyz - внедрение вашего магазина./config - Конфигурация./public/{Yves,Zed} - точки входа в приложение (root document)composer.json и composer.lockpackages.json , packages.lock и yarn.lock./docker/build.conf./docker/build.d/./docker/init.d/Проверьте Demoshop, который мы подготовили для использования этого изображения здесь. Это должно ответить на все вопросы, которые у вас могут возникнуть.
Поскольку эталонная реализация - это Demoshop, который поддерживается нами, это довольно хороший стартер. Либо, просто разбейте это репо, либо начав с нуля.
Если вы хотите начать с нуля, единственные интересные артефакты, которые вам нужны от Demoshop:
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.phpПри этом вы готовы заполнить свой репозиторий своим кодом и настроить его на ваши индивидуальные потребности.
Имейте в виду Dockerfile , который выглядит так же чистым, как и этот:
FROM claranet/spryker-base:latest
Это пахнет как повторное использование. :)
Shop Skeleton и Demoshop также получили сценарий Shell под ./docker/run , который предоставляет вам ярлыки для самых распространенных задач. Проверьте 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-composeIMAGE (обязательное) - Как называется полученное изображение Docker?VERSION (обязательна) - над какой версией изображения Docker мы работаем?BUILD_DEPENDENCIES - пакеты дистрибуции (Debian), которые будут установлены во время сборкиBASE_DEPENDENCIES - Distribution (Debian) пакеты должны быть установлены дополнительноPHP_EXTENSIONS - Пространство разделен Список расширения PHP, который будет установленNPM_DEPENDENCIES - Пакеты распределения, которые будут включены до обработки NPM в слое DEPSKEEP_DEVEL_TOOLS (по умолчанию: false) - должны быть установлены инструменты разработки и сохранены за пределами сборки?SKIP_CLEANUP (по умолчанию: false) - Skip очистки на каждой стадии сборки слоя. Это помогает в вопросах отладки. Имейте в виду, что это также пропускает сбивание полномочий! Так что никогда не выпускайте такое изображение в дикую природу !!!CRONJOB_HANDLER - определяет, где следует зарегистрировать Cronjobs. В настоящее время поддерживают Дженкинс и Кронд.REBUILD_BASE_LAYER - если дана эта сборка VAR, базовый слой будет восстановлен во время строительства изображения вниз по течению Чтобы контролировать поведение NGINX, PHP-FPM или PHP, вы можете либо ввести конфигурацию из внешней части контейнера в качестве крепления связывания, либо через 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 станет первыми директивами для выполнения Dockerfile , которые будут выполнены, эти переопределенные файлы будут сначала доступны во время выполнения контейнера.
Большинство дизайнерских решений, принятых на базовом изображении, регулируются идеей настраиваемости и расширяемости. Базовое изображение, которое можно использовать только один раз для отдельного изображения магазина, довольно бесполезно и далеко от того, что называется базой.
Процесс сборки в значительной степени, как и название предполагает процесс, который создает изображение, которое поделится всеми полученными контейнерами во время выполнения позже.
Некоторые сценарии сборки рассматривают параметры, которые вы можете установить ./docker/build.conf
См. Ссылку выше ..
Крюк Dir: ./docker/build.d/
Если вы либо хотите расширить шаги сборки, унаследованные от базового изображения, либо отключить их, вам необходимо разместить свой собственный сценарий сборки под ./docker/build.d/ . Там вы найдете 3 каталога, отражающие каждый этап/слой:
./docker/build.d/base/ - Установка уровня базовых ОС./docker/build.d/deps/ - дело с зависимостями PHP/Node Speciation Speciation./docker/build.d/shop/ - Работать с генерацией кода фактической базы кода магазинаСценарии каждого поддира получают лексически выполнять выполненные (актуальные источники).
Например, если вы хотите изменить способ создания кэша навигации базовым изображением, вы должны предоставить сценарий в том же месте, где он предоставляется базовым изображением под ./docker/build.d/shop/650_build_navigation_cache.sh . Поскольку полученное изображение, а также контейнер будут использовать файловые системы Union, файлы, предоставленные изображением магазина С помощью этого механизма вы можете либо отключить функциональность, просто предоставив сценарий, который ничего не делает, либо вы можете изменить поведение, добавив сценарий, который делает что -то по -другому или дополнительно.
Тот же самый механизм, описанный выше, может быть использован для изменения способа выполнения инициализации контейнера Spryker и всей установки. Базовое изображение поставляется с значимыми значениями по умолчанию, действительным для общих сред, но может быть переопределено путем размещения пользовательских сценариев в соответствующих местах.
Базовое изображение обеспечивает крючки для обоих, инициализации каждого контейнера и для инициализации всей установки.
Крюк Дир: ./docker/entry.d/
Аргументы ввода времени выполнения ( run-yves , run-zed , run-yves-and-zed , run-cron ), регулирующие, какую роль играет этот фактический контейнер, все источны файлы, указанные в этом каталоге Hook. Через переменные сценарии решают, какие услуги включить и начать во время выполнения.
Общей задачей было бы включить xdebug , как запрошен через Env var ENABLE_XDEBUG при создании контейнера.
Из -за природы все крючки будут выполнены на каждом запуске контейнера.
Крюк Dir: ./docker/init.d/
Обычно каждый экземпляр магазина должен выполнять начальные шаги для инициализации такого магазина. Во время этой настройки широко инициализация все сценарии оболочки под руководством крючком, которые получают выполнение. Например, для инициализации базы данных с фиктивными данными, такими как Demoshop, действительно размещает скрипт в подразделение ./docker/init.d/500_import_demo_data.sh .
Это не сделано, что не так, отдельный контейнер должен быть порожден с помощью точки round arg init .
Крюк Дир: ./docker/deploy.d/
То же самое, что и начало процедуры - процедура развертывания. Эта процедура будет проводиться во время развертывания. Концепция жизненного цикла состоит из этих 2 крючков: init будет вызван в первый раз, и развертывание каждый раз, когда будет выполнена новая версия изображения.
Это не сделано, что не так, отдельный контейнер должен быть порожден с помощью deploy Arg в записи.
Как уже упоминалось, вы можете добавить свои очень индивидуальные шаги сборки и начала. Сценарий ./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 вы можете найти NGINX, PHP-FPM и журналы приложений в /data/logs/
Мы зависим от официальных изображений PHP: https://hub.docker.com/_/php/
Действительно, очень хороший вопрос!
Мы решили пойти на Alpine из -за более короткого времени построения изображений - как сборка источника, так и установки упаковки. Это было более или менее доказательство концепции, которое должно продемонстрировать, что даже тяжелые проекты по подъеме могут быть размещены на альпийском языке. Ожидаемыми преимуществами являются уменьшенные размеры изображения и более быстрое время настройки, а также более быстрое время работы.
К сожалению, оказывается, что Musl Lib C вводит ограничения, которые невыносимы в контексте клиентов - где универсальность является ключом. С 0.9.6 мы перешли на изображения на основе Debian.
На ум приходит две вещи:
Скоро появится еще. :)
Пожалуйста, посмотрите на /проблемы.
