spryker demoshop
1.0.0
docker-composeRequiere: una versión reciente y estable de Docker y Docker-Compose (con Docker-Compose.yml 3.4 Soporte) en su sistema Linux o MacOS.
Dado que esta pila es bastante compleja, incluida una ES completamente volada, requiere al menos 4 GB de memoria. Si está ejecutando Docker en Windows/MacOS, ajuste la configuración en consecuencia.
Si se cumplen los requisitos, ejecutar la tienda es bastante fácil. Solo ingrese estos pasos:
$ git clone https://github.com/claranet/spryker-demoshop.git
$ cd spryker-demoshop
$ ./docker/run devel pull
$ ./docker/run devel up
Esto extrae la imagen de Docker, crea una red, crea todos los contenedores, ata su código local al contenedor para permitirle editar en vivo desde el exterior, conecta el contenedor entre sí y finalmente expone los servicios públicos. Como Yves, Zed, Jenkins-Master, PostgreSQL y Elasticsearch.
Sea paciente mientras se crea la pila Spryker, porque la rutina de inicialización lleva bastante tiempo para que todos los datos se importen a la base de datos y luego se exporten a Redis y Elasticsearch. Actualmente esto lleva unos 10 minutos.
Después de que se haya terminado la inicialización, puede apuntar su navegador a las siguientes URL:
Esta es una versión dockerizada de la implementación de referencia oficial del Spryker Demoshop. Está listo para salir de la caja extrayendo automáticamente todas las dependencias requeridas y creando una pila que comprende PostgreSQL, Redis, Elasticsearch y Jenkins. Durante el tiempo de ejecución, cada uno de los servicios se inicializa.
Puede usar este repositorio como una demostración para una tienda paradigmática basada en Spryker Commerce OS o como punto de partida para el desarrollo de su propia implementación que comienza con una bifurcación del Demoshop.
El procedimiento de compilación e inicio junto con más herramientas se heredan de la imagen Claranet/PHP. Allí encontrará las ideas de diseño técnico detrás de esta docerización y respuestas a más puntos como:
docker/ FileSystemBeneficios de la contenedorización:
Varios servicios están siendo expuestos por la pila Docker-Compose. Para ejecutar pilas en paralelo y evitar colisiones de puertos, necesitamos alinear la asignación de puertos.
Por lo tanto, se ha implementado el siguiente esquema: el número de puerto está codificado así: ECCDD
Entonces Yves DE puede accesible a través de http: // localhost: 20100/y yves us a través de http: // localhost: 20102
AVISO: La diferenciación entre tiendas/dominios por puerto solo es aplicable al entorno de desarrollo local. La pila de grado de producción real proporcionada por Claranet está haciendo esta distinción basada en el nombre de dominio real.
Una premisa central es, y esta es crucial para su comprensión de esta pila, para construir una imagen unificada en los entornos de desarrollo y producción. Esto afecta el uso de APPLICATION_ENV que es evaluado por la aplicación Spryker.
Esta variable tiene el siguiente impacto:
La ubicación de los archivos de configuración locales y los recursos externos no es nada que necesite una consideración adicional en el entorno contenedorizado, ya que todas esas pilas están aisladas de todos modos. Por lo tanto, ¡asegúrese de que ninguna declaración de configuración en ./config/Shared/ utilizará APPLICATION_ENV para identificar sus Casas!
Consideramos que solo el punto 1.1 vale una distinción. Y dado que esto podría lograrse con inyectar vars adecuados en los contenedores efectivos, no distinguimos entre entornos mientras construimos las imágenes. Dado que el punto 1.1 requiere que se resuelvan más dependencias, siempre construimos la imagen con APPLICATION_ENV establecido en development . Pero en qué modo se ejecutará la aplicación en realidad es independiente de eso.
Esto significa que incluso los contenedores de producción tendrán dependencias de desarrollo incluidas. La razón principal de esto es el requisito de paridad Dev/Test/Prod para garantizar que los contenedores se comporten exactamente igual en todas las etapas y en todos los entornos. La compensación para esta premisa es nuevamente imágenes efectivas más grandes.
Durante el tiempo de ejecución, el comportamiento de la aplicación Spryker se puede controlar configurando APPLICATION_ENV que acepta development o production . Si usa el script ./docker/run estas variables se establecerán automáticamente.
La idea detrás del script de envoltura proporcionado a través de ./docker/run es la distinción básica entre entornos devel y prod . La principal diferencia entre esos entornos en términos de docker-compose es el empleo de los montajes de enlace en el modo Devel, que permite al desarrollador editar la base de código desde el exterior mientras ejecuta el código en el fondo dentro de los contenedores.
Dado que esta configuración se esfuerza por reducir los esfuerzos manuales, preparamos los scripts de shell que hacen que la lógica necesaria lo apoye con atajos para las tareas más comunes como construir la imagen o crear o derribar la configuración del contenedor. Echa un vistazo ./docker/run help
El entorno prod está destinado a probar el resultado de su trabajo en un entorno cercano a la product, lo que significa que no se establecerán datos compartidos entre su repositorio local y el contenedor. Además, la aplicación se ejecutará con el conjunto APPLICTION_ENV=production que deshabilita las extensiones específicas del desarrollo.
Dado que en un entorno dockerizado se puede accesible los servicios externos en diferentes direcciones dependiendo del entorno que el código se ejecute, el contenedor/imagen debe ser configurable desde el exterior a través de variables de entorno. Estos deben ser consumidos por la aplicación Spryker. Por lo tanto, esta imagen espera variables de entorno específicas inyectadas como Docker Env Vars y que se están considerando a través de una config_local.php preparada.
Estamos aprovechando el mecanismo nativo de Spryker de una jerarquía de archivos de configuración que define el orden, la precedencia y el esquema de ser considerados archivos de configuración. Esta imagen proporciona su propio archivo de configuración local del sitio que se podría encontrar en este repositorio en docker/config_local.php y que se puede encontrar en la imagen de Docker resultante en config/Shared/config_local.php . Dado que este archivo es el que anula a todos los demás.
El orden de configuración es como el siguiente (último Overides Prio):
config_default.php - Configuración baseconfig_default-development.php - Configuración relevante para el modo de desarrollo (consulte APPLICATION_ENV )config_local.php - configuración local del sitio; En este caso, es la configuración para entorno contenedorizado.Este pedido le permite usar su archivo de configuración completamente independientemente del entorno efectivo en el que se ejecutará el taller. Incluso puede controlar el comportamiento diferente entre los entornos. Acabamos de anular la configuración local de So para decir, de la cual se origina esta idea.
Actualmente, ambos entornos devel y prod utilizando volúmenes no identificados, lo que se debe a la suposición de un entorno transitorio. Esto significa que toda la pila se crea con el único propósito de verificar su base de base. ¡No tiene ninguna circunstancia la configuración de grado de producción, donde los datos deben persistir sobre las recreaciones de contenedores!
El flujo de trabajo asumido podría describirse como:
docker-compose(1) se ha envuelto a través del script de shell ./docker/run . Este script proporciona atajos para la mayoría de las tareas comunes mientras presta atención al repositorio local y su configuración:
Solo para construir el uso de la imagen Docker: ./docker/run build
Esto se aplica a ambos entornos, ya que ambos se basan en la misma imagen. Construirá la imagen principal de Spryker-Demoshop, así como un sabor especializado en Jenkins-Slave a partir de la imagen Spryker-Demoshop.
En realidad, se están construyendo 2 imágenes, una para la imagen real del taller que se está utilizando para los contenedores NGINX y PHP tanto en el Yves como en la capa Zed, y otra para el contenedor de esclavos Jenkins. Este último solo extiende la imagen de la tienda de todos los componentes Jenkins requeridos para crear Jenkins Slave/Worker. La razón para hacer esto en la parte superior de la imagen real de la tienda es que todos los trabajos de backend que se ejecutan a través de Jenkins requieren la base completa del código Spryker.
El tiempo de construcción en una estación de trabajo regular con SSD incorporados actualmente toma apraximadamente 10 minutos para ambas imágenes.
Si desea comenzar su propio trabajo basado en DemosShop, puede encontrar interesante el entorno de desarrollo local. Esta configuración le permite montar su base de código local en un contenedores en ejecución y ver los cambios en la base de código que surgen de inmediato.
Simplemente corre ./docker/run devel up y ahí lo vaya.
Destruye la pila de desarrollo, incluidos todos los volúmenes no identificados sin nombre: ./docker/run devel down -v
Las siguientes rutas están montadas en el contenedor:
* `./assets:/app/assets`
* `./src/Pyz:/app/src/Pyz`
* `./composer.json:/app/composer.json`
* `./package.json:/app/package.json`
* `./tests:/app/tests`
En caso de que necesite reconstruir la imagen del taller y solo desea recrear el contenedor de Yves y/o Zed mientras mantiene todos los contenedores de datos (Redis, ES, PSQL) en ejecución: ./docker/run devel rebuild
Si solo quieres recrear esos contenedores sin reconstruirlos, corre: ./docker/run devel recreate
Si bien la depuración, puede ser útil en lugar de dejar /entrypoint.sh inicializa el contenedor para omitir estos pasos y verificar por ti mismo. Puede hacer esto cambiando el command: run-zed del contenedor preocupante al command: sleep 1w en el docker-compose-devel.yml y recrear el contenedor ejecutando ./docker/run devel recreate zed .
docker-compose Dado que todo esto se basa en docker-compose(1) es posible que deba llamarlo usted mismo, por ejemplo, para ingresar un contenedor a través de Shell: ./docker/run devel compose exec yves bash
Si la salida de la compilación no es tan reveladora y necesita una sesión de depuración más profunda, considere los siguientes pasos para resucitar el contenedor de compilación intermedia muerta:
./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
Y aquí vas a investigar la causa de la falla de construcción.
Presentamos el uso del instalador Spryker. Antes de esta versión, hemos renderizado todo el proceso de construcción, instalación y aprovisionamiento de Sprykwer en scripts de shell que residen en la base y la imagen Spryker. Esto se ha eliminado a favor del nuevo instalador Spryker que representa nada más que un contrato entre la aplicación y la infraestructura. Este contrato resulta explícitamente todas las acciones necesarias que se tomarán para construir la tienda. Hemos preparado dicho contrato de una rutina de instalación a través de config/installer/claranet.yml .
¡Dejamos el apoyo alpino a favor de Debian Stretch! Si necesita Alpine, use versiones anteriores a 2.28.0, pero no admitimos más alpine.
¡Tenga en cuenta también: la imagen principal cambió de claranet/spryker-base a claranet/php , que rompe la estructura anterior del sistema docker/ FileS! Hemos elegido esta ruta porque la imagen base anterior podría generalizarse aún más para que coincida no solo con los requisitos de Spryker, sino más bien cualquier requisito de aplicación basado en PHP.
Si encuentra un error que no figura aquí, repórtelo.
No enviaremos el Delop hasta https://bugs.php.net/bug.php?id=76029 es arreglado y podemos habilitar OPCACHE. Opcache es esencial en entornos de prod, y no tiene sentido usar 7.2 en Dev y 7.1 en producción ...
Desde que Spryker Demoshop 2.32 parece, que hay un error que hace que Opcache arroje excepciones. Así que nos vimos obligados a deshabilitar Opcache.
