spryker demoshop
1.0.0
docker-composeТребуется: недавняя, стабильная версия Docker и Docker-Compose (с поддержкой Docker-Compose.yml 3.4) в вашей системе Linux или MacOS.
Поскольку этот стек довольно сложный, включая полностью подготовленную ES, он требует как минимум 4 ГБ памяти. Если вы запускаете Docker в Windows/MacOS, пожалуйста, настройте соответствующие настройки.
Если реквизиты выполнены, запуск магазина довольно простой. Просто введите эти шаги:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
Это вытягивает изображение Docker, создает сеть, создает все контейнеры, связывает ваш локальный код в контейнер, чтобы вы могли выходить из себя снаружи, соединяет контейнер друг к другу и, наконец, выявляет общественные услуги. Как Ив, Зед, Дженкинс-Мастер, PostgreSQL и Elasticsearch.
Пожалуйста, будьте терпеливы, пока создается стек Spryker, потому что процедура инициализации занимает довольно много времени, чтобы все данные были импортированы в базу данных, а затем экспортируются в Redis и Elasticsearch. В настоящее время это занимает около 10 минут.
После завершения инициализации вы можете указать свой браузер на следующие URL:
Это докеризованная версия официальной справочной реализации Spryker Demoshop. Он готов запустить вне коробки, автоматически вытащить все необходимые зависимости и создав стек, включающий PostgreSQL, Redis, Elasticsearch и Jenkins. Во время выполнения каждая из услуг инициализируется.
Вы можете использовать этот репозиторий либо в качестве демонстрации для парадигматического магазина на основе ОС Spryker Commerce, либо в качестве отправной точки для разработки вашей собственной реализации, начиная с вилки Demoshop.
Процедура сборки и начала вместе с дальнейшим инструментом унаследована от изображения Claranet/PHP. Там вы найдете идеи технического дизайна, стоящие за этой докеризацией и ответы на дальнейшие точки, такие как:
docker/ файловая системаПреимущества контейнеризации:
Несколько услуг выявляются стеком с композитом Docker. Чтобы запустить стеки параллельно и предотвратить столкновения портов, нам нужно выровнять распределение портов.
Поэтому была реализована следующая схема: номер порта кодируется таким: ECCDD
Таким образом, yves de доступен через http: // localhost: 20100/and yves us через http: // localhost: 20102
УВЕДОМЛЕНИЕ: Различение между магазинами/доменами по порту применима только к местной среде развития. Фактический стек производственных классов, предоставленный Claranet, выполняет это различие на основе фактического доменного имени.
Центральная предпосылка - и это имеет решающее значение для вашего понимания этого стека - для создания одного единого изображения в рамках разработки и производственной среды. Это влияет на использование APPLICATION_ENV , которое оценивается самим приложением Spryker.
Эта переменная оказывает следующее влияние:
Расположение локальных файлов конфигурации и внешних ресурсов - это ничто, что требует дополнительного рассмотрения в контейнерной среде, поскольку все эти стеки в любом случае изолированы. Поэтому, пожалуйста, убедитесь, что ни один оператор конфигурации в соответствии с ./config/Shared/ не будет использовать APPLICATION_ENV для определения их пути !!!
Мы рассматриваем только точку 1.1 достойной различия. И поскольку это может быть достигнуто при инъекции правильных VAR в эффективные контейнеры, мы не различаем окружающую среду при создании изображений. Поскольку точка 1.1, как правило, требует более зависимостей, которые нужно решить, мы всегда строим изображение с APPLICATION_ENV , установленным для development . Но в каком режиме заявка на самом деле будет выполнено, независимо от этого.
Это означает, что даже в производственных контейнерах будут включены зависимости развития. Основной причиной этого является требование для Dev/Test/Prod Carity, чтобы гарантировать, что контейнеры ведут себя точно так же на всех этапах и во всех средах. Компромисс для этой предпосылки опять же более крупные эффективные изображения.
Во время выполнения поведение приложения Spryker можно контролировать путем установки APPLICATION_ENV , который принимает либо development , либо production . Если вы используете скрипт ./docker/run эти переменные будут установлены автоматически.
Идея сценария обертки, предоставленная через ./docker/run является основным различием между средами devel и prod . Основное различие между этими средами с точки зрения docker-compose заключается в использовании применения привязки в режиме развития, что позволяет разработчику редактировать базу кода извне во время запуска кода в фоновом режиме в контейнерах.
Поскольку эта установка стремится к сокращению ручных усилий, мы подготовили сценарии оболочек, которые делают необходимую логику и поддерживают вас ярлыками для наиболее распространенных задач, таких как создание изображения или создание или разрыв установки контейнера. Проверьте ./docker/run help
Среда prod предназначена для тестирования результата вашей работы в среде почти до производства, что означает, что общие данные между вашим локальным хранилищем и контейнером не будут установлены. Кроме того, приложение будет запущено с помощью набора APPLICTION_ENV=production , которое отключает конкретные расширения разработки.
Поскольку в стационарной среде внешние службы доступны по разным адресам в зависимости от среды, в которой работает код, контейнер/изображение должно быть настраиваемым снаружи через переменные среды. Они должны быть поглощены приложением Spryker. Следовательно, это изображение ожидает конкретных переменных среды, введенных в виде Docker Env Vars и которые последовали через подготовленный config_local.php .
Мы используем нативный механизм Spryker иерархии файла конфигурации, которая определяет порядок, приоритет и схему для рассматриваемых файлов конфигурации. Это изображение предоставляет свой собственный сайт локальный файл конфигурации, который можно найти в этом репозитории в docker/config_local.php и который можно найти в полученном изображении Docker в config/Shared/config_local.php . Поскольку этот файл - тот, который переопределяет все остальные.
Заказ на конфигурацию является следующим (последнее переосмысление приоритетов):
config_default.php - базовая конфигурацияconfig_default-development.php - конфигурация, соответствующая режиму разработки (см. APPLICATION_ENV )config_local.php - локальная конфигурация сайта; В этом случае его конфигурация для контейнерной среды.Этот заказ позволяет вам использовать ваш файл конфигурации полностью независимо от эффективной среды, в которой будет работать магазин. Вы даже можете контролировать различное поведение между средами. Мы просто переопределяем SO, чтобы сказать локальные настройки сайта, из которых возникает эта идея.
В настоящее время обе среды devel и prod используя неназванные тома, что связано с предположением о переходной среде. Это означает, что весь стек создается для единственной цели проверки базы вашей кода. Он при каких -либо обстоятельствах не предназначен для некоторой настройки производственного уровня, где данные должны сохраняться в отношении воссозданий контейнеров !!!
Предполагаемый рабочий процесс можно описать как:
docker-compose(1) был завернут через сценарий оболочки ./docker/run . Этот скрипт обеспечивает ярлыки для большинства общих задач, обращая внимание на локальный репозиторий и его конфигурацию:
Просто чтобы построить изображение Docker. Использование: ./docker/run build
Это относится к обеим средам, поскольку оба основаны на одном и том же изображении. Он построит основное изображение Spryker-Demoshop, а также специализированный вкус Jenkins-Slave из изображения Spryker-Demoshop.
На самом деле строится 2 изображения, одно для реального витрины магазина, которое используется для nginx и контейнеров PHP в слое YVES и ZED, и одно для подчиненного контейнера Дженкинса. Последний расширяет изображение магазина только по всем необходимым компонентам Jenkins, чтобы создать рабов/работника Дженкинса. Причина для этого в дополнение к реальному визуализации магазина заключается в том, что все бэкэндные задания, выполняемые через Дженкинс, требуют полной базы кода Spryker.
Время сборки на обычной рабочей станции с SSD, встроенными в настоящее время в настоящее время, занимает апрелистские 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`
Если вам нужно восстановить изображение магазина и просто хотите воссоздать контейнер YVE и/или ZED, сохраняя при этом все контейнеры данных (Redis, ES, PSQL) ./docker/run devel rebuild
Если вы просто хотите воссоздать эти контейнеры, не восстанавливая их бег: ./docker/run devel recreate
При отладке это может быть полезно, вместо того, чтобы позволить /entrypoint.sh инициализировать контейнер, чтобы пропустить эти шаги и проверить сами. Вы можете сделать это, изменив command: run-zed Directive о контейнере для command: sleep 1w в docker-compose-devel.yml и воссоздайте контейнер с помощью ./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. Это было отброшено в пользу нового установщика Spryker, который представляет собой не что иное, как контракт между приложением и инфраструктурой. Этот контракт явно заставляет все необходимые действия, которые необходимо предпринять для создания магазина. Мы подготовили такой контракт на подпрограмму установки через config/installer/claranet.yml .
Мы отказались от альпийской поддержки в пользу Debian Stretch! Если вам требуется альпийский, используйте версии до 2.28.0, но мы не поддерживаем Alpine.
Также обратите внимание: родительское изображение переключается с claranet/spryker-base на claranet/php , которое разбивает предыдущую структуру docker/ FileSystem! Мы выбрали этот путь, потому что первое базовое изображение может быть еще более обобщенным, чтобы соответствовать не только требованиям Spryker, но и любым требованиям на основе PHP.
Если вы найдете ошибку, не указанную здесь, сообщите о них!
Мы не будем отправлять Demoshop до тех пор, пока не будет установлен https://bugs.php.net/bug.php?id=76029, и мы можем включить Opcache. Opcache необходим в средах Prod, и не имеет смысла использовать 7.2 в Dev и 7.1 в производстве ...
Поскольку Spryker Demoshop 2.32 кажется, что есть ошибка, которая заставляет Opcache выбрасывает исключения. Таким образом, мы были вынуждены отключить Opcache.
