{"id":18906605,"url":"https://github.com/claranet/spryker-demoshop","last_synced_at":"2025-10-30T20:41:27.055Z","repository":{"id":52143789,"uuid":"90019228","full_name":"claranet/spryker-demoshop","owner":"claranet","description":"Containerized demoshop based on the Spryker Commerce OS","archived":false,"fork":false,"pushed_at":"2023-01-12T06:49:38.000Z","size":234600,"stargazers_count":16,"open_issues_count":13,"forks_count":8,"subscribers_count":10,"default_branch":"master","last_synced_at":"2025-03-28T00:34:22.142Z","etag":null,"topics":["claranet","commerce","container","demo-shop","docker","dockerfile","os","shop","spryker","spryker-demoshop","yves","zed"],"latest_commit_sha":null,"homepage":"https://www.claranet.de/spryker-hosting","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/claranet.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG-claranet.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-05-02T10:10:08.000Z","updated_at":"2021-04-06T12:00:33.000Z","dependencies_parsed_at":"2023-02-09T10:31:04.881Z","dependency_job_id":null,"html_url":"https://github.com/claranet/spryker-demoshop","commit_stats":null,"previous_names":[],"tags_count":25,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/claranet%2Fspryker-demoshop","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/claranet%2Fspryker-demoshop/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/claranet%2Fspryker-demoshop/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/claranet%2Fspryker-demoshop/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/claranet","download_url":"https://codeload.github.com/claranet/spryker-demoshop/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":249006449,"owners_count":21197279,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["claranet","commerce","container","demo-shop","docker","dockerfile","os","shop","spryker","spryker-demoshop","yves","zed"],"created_at":"2024-11-08T09:17:02.902Z","updated_at":"2025-10-29T11:35:03.250Z","avatar_url":"https://github.com/claranet.png","language":"PHP","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Docker Image claranet/spryker-demoshop\n\n[![build status badge](https://img.shields.io/travis/claranet/spryker-demoshop/master.svg)](https://travis-ci.org/claranet/spryker-demoshop/branches)\n\n\u003c!-- vim-markdown-toc GFM --\u003e\n\n* [TL;DR](#tldr)\n* [What?](#what)\n* [Why?](#why)\n* [Services](#services)\n* [Design](#design)\n    * [Build Time Environment](#build-time-environment)\n    * [Runtime Environments](#runtime-environments)\n    * [Spryker Configuration](#spryker-configuration)\n    * [Docker Volumes](#docker-volumes)\n* [Using the wrapper script](#using-the-wrapper-script)\n    * [Build Image](#build-image)\n    * [Start Development Environment](#start-development-environment)\n    * [Rebuilding / Recreating](#rebuilding--recreating)\n    * [Interface to `docker-compose`](#interface-to-docker-compose)\n    * [Debug Failed Build](#debug-failed-build)\n* [Deprecations](#deprecations)\n    * [2.31.0](#2310)\n    * [2.28.0](#2280)\n* [Known Issues](#known-issues)\n    * [PHP 7.2](#php-72)\n    * [PHP OPCACHE](#php-opcache)\n\n\u003c!-- vim-markdown-toc --\u003e\n\n\n## TL;DR\n\nRequires: a recent, stable version of [docker](https://docs.docker.com/) and\n[docker-compose](https://docs.docker.com/compose/) (with docker-compose.yml 3.4\nsupport) on your\n[Linux](https://docs.docker.com/engine/installation/linux/ubuntu/) or\n[MacOS](https://docs.docker.com/docker-for-mac/install/) system. \n\nSince this stack is quite complex including a fully fleged ES, it requires at\nleast 4GB of memory. If you are running docker on Windows/MacOS please adjust\nthe settings accordingly.\n\nIf requisites are met, running the shop is fairly easy. Just enter these steps:\n\n    $ git clone https://github.com/claranet/spryker-demoshop.git\n    $ cd spryker-demoshop\n    $ ./docker/run devel pull\n    $ ./docker/run devel up\n\nThis pulls the docker image, create a network, create all the containers, bind\nmounts your local code into the container in order to enable you to live-edit\nfrom outside, connects the container to each other and finally exposes the\npublic services. Like Yves, Zed, Jenkins-Master, Postgresql and Elasticsearch.\n\n**Please be patient while the spryker stack is being created, because the\ninitialization routine takes quite some time for all the data to be imported\ninto the database and then exported to redis and elasticsearch. Currently this\ntakes about 10 minutes.**\n\nAfter the initialization has been finished, you are able to point your browser\nto the following URLs:\n\n* Yves: http://localhost:20100\n* Zed: http://localhost:20200\n* Jenkins-Master: http://localhost:20300\n* Elasticsearch: http://localhost:20500\n* Postgresql: localhost:20600\n\n\n## What?\n\nThis is a dockerized version of the official reference implementation of the\n[Spryker Demoshop](https://github.com/spryker/demoshop). It is ready to run\nout-of-the-box by automatically pulling all required dependencies and creating\na stack comprising PostgreSQL, Redis, Elasticsearch and Jenkins. During runtime\neach of the services gets initialized.\n\nYou can use this repository either as a demonstration for a paradigmatic shop\nbased on Spryker Commerce OS or as starting point for the development of\nyour own implementation beginning with a fork of the demoshop.\n\nThe build and start procedure along with further tooling are inherited from the\n[claranet/php](https://github.com/claranet/php) image. There\nyou will find the technical design ideas behind this dockerization and answers\nto further points like:\n\n* Private Repositories\n* Build Layer\n* Environments\n* `docker/` filesystem structure\n* sections / subsection \u0026 steps concept\n\n\n## Why?\n\nBenefits of containerization:\n\n* Consistency\n* Reproducibility\n* Portablity\n* Seamless deployment form local development into prod environment\n\n## Services\n\n![Spryk Container Stack](./docker/docs/container-stack.png)\n\nSeveral services are being exposed by the docker-compose stack. In order to\nrun stacks in parallel and prevent port collisions we need to align port\nallocation.\n\nTherefore the following scheme has been implemented: The port number is encoded\nlike this: **ECCDD**\n\n* **E** - Environment\n    * 1 - production\n    * 2 - development\n* **CC** - Component\n    * 01 - yves\n    * 02 - zed\n    * 03 - jenkins\n    * 05 - elasticsearch\n    * 06 - postgresql\n    * 07 - rabbitmq\n* **DD** - Domain\n    * 00 - DE\n    * 01 - AT\n    * 02 - US\n\nSo yves DE is reachable via http://localhost:20100/ and yves US via http://localhost:20102\n\nNotice: The differentiation between stores/domains by port is only applicable to the\nlocal devel environment. The actual production grade stack provided by Claranet\nis doing this distinction based on the actual domain name.\n\n\n## Design\n\n### Build Time Environment\n\nA central premise is - and this one is crucial for your understanding of this\nstack - to build one unified image across development and production\nenvironments. This affects the usage of `APPLICATION_ENV` which gets evaluated\nby the Spryker App itself.\n\nThis variable has the following impact:\n\n1. During Build Time:\n    1. Which packages are going to be installed via dependency resolution\n     (composer, npm)?\n    1. Different modes in assets building\n1. During Run Time:\n    1. Where does the application is about to find configuration files (propel config)?\n    1. Where are external resources to be found?\n    1. Shall the app enable symfony debug/devel behaviour?\n\nThe location of local configuration files and external resources is nothing\nwhich needs extra consideration in containerized environment, since all those\nstacks are isolated anyways. ***So please ensure that no configuration\nstatement under `./config/Shared/` will utilize `APPLICATION_ENV` for\nidentifying their pathes!!!***\n\nWe consider only point 1.1 worth a distinction. And since this could be\nachieved with injecting proper vars into the effective containers, we do not\ndistinguish between environments while building the images. Since point 1.1\nrequires typically more dependencies to be resolved, we always build the image\nwith `APPLICATION_ENV` set to `development`. But in which mode the application\nactually will be ran is independant from that.\n\nThis means that even the production containers will have development dependencies\nincluded. Primary reason for this is the requirement for dev/test/prod parity\nto ensure the containers behave exactly the same in all stages and in all\nenvironments. Tradeoff for this premise is again larger effective images.\n\nDuring runtime the behaviour of the Spryker Application can be controlled by\nsetting `APPLICATION_ENV` which accepts either `development` or `production`.\nIf you use the `./docker/run` script this variables will be set automatically.\n\n\n### Runtime Environments\n\nThe idea behind the wrapper script provided via `./docker/run` is\nthe basic distinction between `devel` and `prod` environments. The main\ndifference between those environments in terms of `docker-compose` is the\nemployment of bind mounts in the devel mode, which enables the developer to\nedit the code base from the outside while running the code in the background\nwithin the containers.\n\nSince this setup strives for reducing manual efforts we prepared shell scripts\nwhich render the necessary logic and support you with shortcuts for the most\ncommon tasks like building the image or creating or tearing down the container\nsetup. Check out `./docker/run help`\n\nThe `prod` environment is meant for testing the result of your work in a\nnear-to-prod environment, which means that no shared data between your local\nrepository and the container will be established. Furthermore will the\napplication be run with `APPLICTION_ENV=production` set which disables development\nspecific extensions.\n\n\n### Spryker Configuration\n\nSince in a dockerized environment external services are reachable on different\naddresses depending on the environment the code is running in, the\ncontainer/image needs to be configurable from the outside via environment\nvariables. These need to be consumed by the spryker app. Therefore this image\nis expecting specific environment variables injected as docker env vars and\nwhich are being consiumed via a prepared `config_local.php`.\n\nWe're leveraging the Spryker native mechanism of a configuration file hierarchy\nwhich defines order, precedence and the scheme of to be considered\nconfiguration files. This image provides its own site local configuration file\nwhich could be found in this repository under `docker/config_local.php` and\nwhich could be found in the resulting docker image under\n`config/Shared/config_local.php`. Since this file is the one which overrides\nall the others.\n\nConfiguration order is as the following (last overides prio ones):\n* `config_default.php` - Base configuration\n* `config_default-development.php` - Configuration relevant for development mode (see `APPLICATION_ENV`)\n* `config_local.php` - site local configuration; in this case its the configuration for containerized environment.\n\nThis order enables you to use your config file completely independently of\nthe effective environment the shop will run in. You can even control different\nbehaviour between environments. We just override the so to say site local\nsettings, which this idea is originating from.\n\n\n### Docker Volumes\n\nCurrently both environments `devel` and `prod` using unnamed volumes which is\ndue to the assumption of a transient environment. This means, the whole stack\ngets created for the sole purpose of checking your code base aginst it. **Its is\nunder no circumstance meant as some production grade setup, where data needs to\npersisted over recreations of containers!!!**\n\nThe assumed workflow could be described as:\n\n1. Create environment\n1. Initialize with demo data during init\n1. Evolve code base\n1. Iterate: rebuild -\u003e run -\u003e init -\u003e evolve\n1. Destroy environment including volumes\n\n\n## Using the wrapper script\n\n`docker-compose(1)` has been wrapped via the shell script `./docker/run`. This\nscript provides shortcuts for most of the common tasks while paying attention\nto the local repository and its configuration:\n\n\n### Build Image\n\nJust to build the docker image use: `./docker/run build`\n\nThis applies to both environments since both are based on the very same image.\nIt will build the main spryker-demoshop image as well as a specialized\njenkins-slave flavour from the spryker-demoshop image.\n\nActually 2 images are being built, one for the actual shop image which is being\nused for the nginx and the php containers in both the yves and the zed layer,\nand one for the jenkins slave container. The latter only extends the shop image\nby all required Jenkins components in order to create Jenkins slave/worker. The\nreason for doing this in top of the actual shop image is that all the backend\njobs being ran via Jenkins require the full spryker code base.\n\nThe build time on a regular workstation with SSDs built in currently takes\naprpoximately 10 minutes for both images.\n\n\n### Start Development Environment\n\nIf you want to start you own work based on the demoshop you might find the\nlocal development environment interesting. This setup enables you to mount your\nlocal code base into a running containers and see changes to the code base take\neffect immediately.\n\nJust run `./docker/run devel up` and there you go.\n\nDestroy devel stack including all of the allocated unnamed volumes:\n`./docker/run devel down -v`\n\nThe following pathes are bind mounted into the container:\n\n    * `./assets:/app/assets`\n    * `./src/Pyz:/app/src/Pyz`\n    * `./composer.json:/app/composer.json`\n    * `./package.json:/app/package.json`\n    * `./tests:/app/tests`\n\n\n### Rebuilding / Recreating\n\nIn case you need to rebuild the shop image and just want to recreate the Yves\nand/or Zed container while keeping all of the data containers (redis, es, psql)\nrunning: `./docker/run devel rebuild`\n\nIf you just want to recreate those containers without rebuilding them run:\n`./docker/run devel recreate`\n\nWhile debugging it might be useful instead of letting `/entrypoint.sh`\ninitialize the container to skip this steps and check for yourself. You could\ndo this by changing the `command: run-zed` directive of the concerning\ncontainer to `command: sleep 1w` in the `docker-compose-devel.yml` and\nrecreate the container by running `./docker/run devel recreate zed`.\n\n\n### Interface to `docker-compose`\n\nSince all this is based on `docker-compose(1)` you might need to call it by\nyourself, for example to enter a container via shell:\n`./docker/run devel compose exec yves bash`\n\n\n### Debug Failed Build\n\nIf the output of the build is not that telling and you are in need of a deeper\ndebug session, consider the following steps in order to resurrect the died\nintermediate build container:\n\n    ./docker/run build\n    # assumed that the last created container is the failed intermediate build container\n    docker commit $(docker ps -lq) debug\n    docker run --rm --it debug /bin/sh\n\nAnd here you go in investigating the cause for the build failure.\n\n\n## Deprecations\n\n### 2.31.0\n\nWe introduced the usage of the Spryker Installer. Prior to this version we have\nrendered the whole sprykwer build, install and provisioning process in shell\nscripts residing in the base and the spryker image. This has been dropped in\nfavor of the new Spryker Installer which represents nothing more than a\ncontract between the application and the infrastructure. This contract\nexplicitly hilights all the necessary actions to be taken in order to build the\nshop. We've prepared such a contract of an installation routine via\n`config/installer/claranet.yml`.\n\n### 2.28.0\n\nWe dropped alpine support in favor of debian stretch! If you require alpine,\nplease use versions prior 2.28.0, but we do not further support alpine.\n\nAlso note: The parent image switched from `claranet/spryker-base` to\n`claranet/php`, which breaks the previous `docker/` filesystem structure! We\nhave chose this path because the former base image could be even further\ngeneralized to match not only spryker requirements, but rather any PHP based\napplication requirements.\n\n\n## Known Issues\n\nIf you find a bug not listed here, please [report](https://github.com/claranet/spryker-demoshop/issues) them!\n\n### PHP 7.2\n\nWe won't ship the demoshop until https://bugs.php.net/bug.php?id=76029 is fixed and we can enable opcache. Opcache is essential in prod environments, and it doesn't make sense to use 7.2 in dev and 7.1 in production...\n\n### PHP OPCACHE\n\nSince Spryker Demoshop `2.32` it seems, that there is a bug which causes the OPCACHE to throws exceptions. So we were forced to disable OPCACHE.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fclaranet%2Fspryker-demoshop","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fclaranet%2Fspryker-demoshop","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fclaranet%2Fspryker-demoshop/lists"}