spryker base
1.0.0
Nota importante: ¡este proyecto está en desuso! ¡Utilice el claranet/spryker-demoshop como una referencia de Bootstrap o nuestra imagen parente de claranet/php para un caso de uso PHP más genérico! Ya no mantenemos este proyecto.
Esta imagen tiene el propósito de proporcionar la infraestructura base para Yves y Zed. Infraestructura en términos de scripts de construcción/init y herramientas adicionales alrededor de la tienda en sí. ¡Esta imagen no proporciona una tienda lista para usar! Para usar las características implementadas aquí, escriba su propio Dockerfile , que utiliza esta imagen base para heredar, a lo largo de su implementación real de una tienda Spryker.
¡Este proyecto todavía está en beta y se someterá a posibles cambios de ruptura!
¡Por eso estamos ansiosos por recibir comentarios de usted! Este es un esfuerzo de trabajo en progreso que se esfuerza por hacer que Dockering sea una tienda Spryker lo sea lo más fácil posible. Para lograr con éxito este objetivo, necesitamos identificar los pasos comunes que vale la pena ser generalizados y poner en esta imagen base. Así que cuéntanos sobre tus necesidades y tus experiencias.
Si desea ver esta imagen en acción y cómo se utilizará, consulte el Spryker Demoshop en contenedores. Este Demoshop sirve como implementación de referencia para la imagen base. De la misma manera que Spryker está progresando en sus paquetes y haciendo que el DemaP que refleje esos cambios, usamos el Demoshop exactamente de la misma manera.
Los rasgos centrales son:
ONBUILD para conectar y controlar el proceso de construcción de imágenes infantilesBeneficios de la contenedorización:
La primera premisa es que decidimos servir al contenedor Yves y Zed de una imagen. El beneficio es actualizar siempre la base del código compartido en un clúster completo. La compensación son imágenes ligeramente más grandes, ya que los requisitos de ambos componentes deben incluirse.
Otra premisa 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 es independiente de la compilación.
Esto significa que incluso los contenedores de producción tendrán dependencias 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 de los scripts proporcionados en este ./shop/docker subcarpeta sigue 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.
El concepto introducido por esta imagen base es dividir la imagen del taller resultante en 3 capas distintas (efectivamente hay más de 3 capas, ya que cada declaración en Dockerfile da como resultado una nueva capa; pero la idea de 3 capas distintas abstrae la lógica de activación de Onbuild más fácil y comprensible). Hay un par de razones para esto:
Primero, debe aprovechar el caché de Docker y acelerar las reconstrucciones iterativas de la imagen de la tienda. Dado que estas capas se ordenan de genéricas a específicas, se debe reducir la necesidad de reconstrucciones de toda la pila mientras trabajan iterativamente en la base de código de la implementación real del taller.
En segundo lugar, se pueden recuperar diferentes capas en paralelo mientras se extraen la imagen, lo que acelera el tiempo de creación de contenedores que es relevante no solo para el desarrollo local, sino más bien para las implementaciones de la configuración de producción. Además, dado que las capas genéricas no cambian tan a menudo, la necesidad no solo para las reconstrucciones sino también para la reabastecimiento de toda la imagen también debería reducirse.
Desafortunadamente, esto no viene sin costo, el tamaño de imagen efectivo será ligeramente más alto que el que se acumula solo una capa. En este momento, esta parece ser una compensación aceptable.
¿Cuáles son las responsabilidades de esas capas y dónde se encuentran y cuándo se van a construir?
claranet/spryker-base (esta imagen):claranet/spryker-demoshop (la imagen de la tienda aguas abajo, por ejemplo, el DEMOSHOP):spryker-base (cuide la variable de compilación $REBUILD_BASE_LAYER ) En caso de que sus dependencias de PHP o nodo necesiten ser extraídos de un repositorio privado, solo necesita proporcionar un ~/.netrc . Este archivo se detectará automáticamente y temporalmente como Docker Build Arg inyectado en el contenedor de compilación transitorio, utilizado por GIT para clonar los repositorios apropiados, y luego eliminó la capa de resuegación justo antes de que se cierre la capa.
El formato de $HOME/.netrc es el siguiente:
machine git.company.local
login my_user_name
password my_private_token
Para entrar en vigencia, todas las dependencias dadas deben administrarse como URL HTTP o se transforman a través de git config --global "url.https://".insteadof "git://git@ que ya ha sido preparado por la imagen base.
Si desea agregar reglas más específicas, cree un script de compilación en la capa de dependencia que se ejecuta antes del proceso de resolución de dependencia:
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]"
Dado que las URL GIT se pueden administrar en una combinación arbitraria, esto es en algunas circunstancias necesarias.
Todo esto es necesario porque Docker se niega a implementar volúmenes de tiempo de compilación, lo que facilitaría este proceso. Pero realmente obtuvieron razones sorprendentes, ya que una característica se arriesgaría a la reproducibilidad, porque Dockerfile no es la única fuente de intracciones de construcción. Es, como en cualquier argumento tecnológico, sin verdad absoluta, solo compensaciones.
Dado que en un entorno dockerizado se puede accesible los servicios externos en una dirección diferente, dependiendo del entorno, el código se ejecuta, necesitamos que se ajuste alguna configuración. Por lo tanto, usamos el mecanismo nativo de Spryker de precedencia del archivo de configuración para inyectar nuestra configuración a través del archivo de configuración local del sitio 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:
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.
Para esto, necesitábamos eliminar config/Shared/config_local.php en la lista .gitignore .
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:
Para reutilizar las funcionalidades implementadas aquí, los siguientes aspectos deben estar alineados con la imagen base:
./src/Pyz - Implementación de su tienda./config - Configuración./public/{Yves,Zed} - EntryPoints a su aplicación (ROOT DEL DOCUMENT)composer.json y composer.lockpackages.json , packages.lock e yarn.lock./docker/build.conf./docker/build.d/./docker/init.d/Echa un vistazo al Demoshop que hemos preparado para usar esta imagen aquí. Esto debería responder a todas las preguntas que pueda tener.
Dado que la implementación de referencia es la Demoshop que mantiene nosotros, este es un entrante bastante bueno. Ya sea simplemente bifurcando este repositorio o comenzando desde cero.
Si desea comenzar desde cero, los únicos artefactos de interés que necesita del Demoshop son:
./docker/*./Dockerfile./.dockerignore./config/Shared/config_local.phpCon esto, está listo para poblar su repositorio con su código y personalizarlo a sus necesidades individuales.
Tenga en cuenta el Dockerfile que se ve tan limpio como esto:
FROM claranet/spryker-base:latest
Esto huele a reutilización. :)
El esqueleto de la tienda y el Demoshop también obtuvieron un script de shell ./docker/run que le proporciona accesos directos a las tareas más comunes. Consulte el ReadMe.md allí para obtener más detalles.
# 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
Esas variables se proporcionarán durante la creación de contenedores como variables de entorno.
La mayoría de las variables consumidas por el archivo 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"Consumido por los ganchos de inicialización:
ZED_ADMIN_PASSWORD : si se establece la contraseña predeterminada del usuario [email protected] se restableceráENABLE_XDEBUG : el módulo PHP xdebug se activará y configurará.ENABLE_OPCACHE : el módulo PHP opcache se activará y configurará. Esas variables se proporcionarán a través de su proyecto específico ./docker/build.conf
PROJECT (obligatorio): controla el prefijo de nombre de los servicios creados docker-composeIMAGE (obligatoria) - ¿Cuál es el nombre de la imagen de Docker resultante?VERSION (obligatoria) - ¿En qué versión de la imagen de Docker estamos trabajando?BUILD_DEPENDENCIES - paquetes de distribución (Debian) que se instalarán durante el tiempo de compilaciónBASE_DEPENDENCIES - paquetes de distribución (Debian) que se instalarán adicionalmentePHP_EXTENSIONS : la lista separada de la extensión PHP se instalaráNPM_DEPENDENCIES : paquetes de distribución que se introducirán antes del manejo de NPM en la capa DepsKEEP_DEVEL_TOOLS (predeterminado: falso) - ¿Se instalarán las herramientas de desarrollo y se mantendrán más allá de la compilación?SKIP_CLEANUP (predeterminado: falso): omita el paso de limpieza en cada etapa de compilación de la capa. Esto ayuda en los problemas de depuración. ¡Tenga en cuenta que esto también se omite las credenciales! ¡Así que nunca libere una imagen así en la naturaleza!CRONJOB_HANDLER : define dónde se deben registrar Cronjobs. Actualmente, Jenkins y Crond son apoyados.REBUILD_BASE_LAYER : si se da este VAR de compilación, la capa base se reconstruirá durante la compilación de la imagen de la tienda posterior Para controlar el comportamiento de NGINX, PHP-FPM o PHP, puede inyectar configuración desde el exterior del contenedor como montajes de enlace o a través de Dockerfile de la imagen del taller infantil.
La configuración de los servicios se prepara para incluir varios archivos que constituyeron la configuración efectiva.
Todas las configuraciones se preparan para esperarse en un directorio específico donde todos los archivos relevantes
Las ubicaciones esperadas son:
/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 .La configuración predeterminada se encuentra en:
/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
En los entornos donde solo puede montar directorios completos en el contenedor, hemos preparado un mecanismo que espera una jerarquía de directorio en /mnt/configs y en la creación del contenedor, enlace todos los archivos en esta ubicación a su ubicación correspondiente en /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
Debido a la naturaleza de los sistemas de archivos en capas, la imagen infantil que hereda de esta imagen base puede simplificar las configuraciones de sobrescribencia para lograr el comportamiento deseado de esos servicios.
Esos se pueden personalizar fácilmente suministrando archivos de configuración por usted mismo a través de Dockerfile :
FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf
Dado que el desencadenante de OnBuild será las primeras directivas del niño Dockerfile que se ejecutará, estos archivos anulados estarán disponibles por primera vez durante el tiempo de ejecución del contenedor.
La mayoría de las decisiones de diseño tomadas en la imagen base se rigen por la idea de personalización y extensibilidad. Una imagen base que solo podría usarse una vez para una imagen de tienda individual es bastante inútil y lejos de algo llamado Base.
El proceso de compilación es más o menos, como su nombre sugiere el proceso que produce la imagen que comparten todos los contenedores derivados durante el tiempo de ejecución más adelante.
Algunos scripts de compilación consideran los parámetros que puede configurar ./docker/build.conf
Ver referencia anterior ..
Hook Dir: ./docker/build.d/
Si desea extender los pasos de compilación heredados de la imagen base o deshabilitarlos, debe colocar su script de compilación personalizado en ./docker/build.d/ . Allí encontrará 3 directorios que reflejan cada etapa/capa:
./docker/build.d/base/ - Instalaciones de nivel del sistema operativo base./docker/build.d/deps/ - Tratar con dependencias de PHP/nodo específicas de la tienda./docker/build.d/shop/ - tratar con la generación de código de la base de código de taller realLos scripts de cada subdir se ejecutan léxicamente ordenados (de origen actuall).
Por ejemplo, si desea cambiar la forma en que el caché de navegación se construye con la imagen base, debe proporcionar un script en la misma ubicación que está proporcionada por la imagen base en ./docker/build.d/shop/650_build_navigation_cache.sh . Dado que la imagen resultante y el contenedor utilizarán los sistemas de archivos de la Unión, los archivos proporcionados por la imagen del taller tienen precedencia sobre las proporcionadas por la imagen BAS. Según este mecanismo, puede deshabilitar una funcionalidad simplemente suministrando un script que no hace nada o puede alterar el comportamiento agregando un script que hace algo de manera diferente o adicional.
El mismo mecanismo descrito anteriormente podría emplearse para alterar la forma en que se ejecutará la inicialización del contenedor Spryker y toda la configuración. La imagen base viene con valores predeterminados significativos válidos para entornos comunes, pero podría anularse colocando scripts personalizados en ubicaciones apropiadas.
La imagen base proporciona ganchos para ambos, la inicialización de cada uno de los contenedores y para la inicialización de toda la configuración.
Hook Dir: ./docker/entry.d/
Los argumentos de entrada de tiempo de ejecución ( run-yves , run-zed , run-yves-and-zed , run-cron ) rigen qué papel está teniendo este contenedor real, todos los archivos enumerados en este directorio de gancho. A través de las variables, los scripts deciden qué servicios habilitar y comenzar durante el tiempo de ejecución.
Una tarea común sería habilitar xdebug como se solicita a través de ENABLE_XDEBUG
Debido a la naturaleza, todos los ganchos se ejecutarán en cada inicio del contenedor.
Hook Dir: ./docker/init.d/
Comúnmente, cada instancia de la tienda necesita llevar a cabo pasos iniciales para inicializar dicha tienda. Durante esta configuración amplia inicialización, todos los scripts de shell debajo de la directora de gancho se ejecutan. Por ejemplo, para inicializar la base de datos con datos ficticios como DemosShop coloca script en ./docker/init.d/500_import_demo_data.sh .
Esto no se realiza implacamente, se debe generar un contenedor separado con el initing arg init .
Hook Dir: ./docker/deploy.d/
Lo mismo que el procedimiento de inicio es el procedimiento de implementación. Este procedimiento se llevará a cabo durante las implementaciones. El concepto de ciclo de vida consta de esos 2 ganchos: Init se llamará la primera vez y la implementación cada vez que se llevará a cabo una nueva versión de la imagen.
Esto no se hace implicantemente, se debe generar un contenedor separado con el deploy de EntryPoint Arg.
Como ya se mencionó, es libre de agregar sus pasos de compilación e init más personalizados. El script ./docker/common.inc.sh lo ayudará con algunas funciones útiles. Compruébalo solo.
Haga que su paso de compilación sea dando cuenta utilizando funciones de salida preparadas:
errorText : plantea un errorsuccessText - Enviar el éxitosectionHead : imprima el título para un grupo de tareassectionText - Imprimir información de paso de compilación intermedio Proporcionamos una función install_packages para todos los pasos de compilación incluidos. ¡Asegúrese de que lo esté usando! Viene con la posibilidad de marcar los paquetes como dependencias de "construir". Los paquetes marcados como dependencias de compilación se eliminarán después de que termine la capa de compilación. Para marcar los paquetes como dependencias de compilación simplemente establecidas --build Build como el primer argumento:
# remove "gcc" at the end of our image build
install_packages --build gcc
# keep "top" in the resulting image
install_packages top
Todavía estamos en las primeras etapas de este proyecto, por lo que la documentación podría estar incompleta. Si desea obtener más información sobre las características que estamos proporcionando, eche un vistazo a la biblioteca de shell.
En las instancias (s) YVES/ZED puede encontrar Nginx, PHP-FPM y registros de aplicaciones dentro /Data/Logs/
Dependemos de las imágenes PHP oficiales: https://hub.docker.com/_/php/
¡Muy buena pregunta de hecho!
Hemos decidido ir por Alpine debido a los tiempos de construcción de imágenes más cortos, tanto la compilación de la fuente como la instalación del paquete. Ha sido más o menos una prueba de concepto que debería demostrar que incluso los proyectos de elevación pesada pueden ser alojados en Alpine. Los beneficios esperados son los tamaños de imagen reducidos y el tiempo de construcción más rápido, así como los tiempos de ejecución más rápidos.
Desafortunadamente, resulta que Musl Lib C introduce una limitación insoportable en el contexto del cliente, donde la versatilidad es la clave. Desde 0.9.6 hemos cambiado a imágenes basadas en Debian.
Dos cosas me vienen a la mente:
Más por venir pronto. :)
Por favor, eche un vistazo a los problemas.
