spryker demoshop
1.0.0
docker-composeيتطلب: نسخة حديثة ومستقرة من Docker و Docker-Cormpose (مع Docker-corm.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 ، وإنشاء شبكة ، وإنشاء جميع الحاويات ، وربط الكود المحلي الخاص بك في الحاوية من أجل تمكينك من العيش من الخارج ، وتوصيل الحاوية ببعضها البعض ويعرض الخدمات العامة أخيرًا. مثل yves و zed و Jenkins-Master و Postgresql و Elasticsearch.
يرجى التحلي بالصبر أثناء إنشاء مكدس Spryker ، لأن روتين التهيئة يستغرق بعض الوقت حتى يتم استيراد جميع البيانات في قاعدة البيانات ثم يتم تصديرها إلى Redis و Elasticsearch. حاليا هذا يستغرق حوالي 10 دقائق.
بعد الانتهاء من التهيئة ، يمكنك توجيه متصفحك إلى عناوين URL التالية:
هذه نسخة مقيد للتنفيذ المرجعي الرسمي لـ Spryker Demoshop. إنه جاهز للتشغيل خارج الصندوق عن طريق سحب جميع التبعيات المطلوبة تلقائيًا وإنشاء مكدس يضم PostgreSQL و Redis و Elasticsearch و Jenkins. أثناء وقت التشغيل ، تتم تهيئة كل من الخدمات.
يمكنك استخدام هذا المستودع إما كإظهار عرض لمتجر نموذجية يعتمد على نظام التشغيل التجاري Spryker أو كنقطة انطلاق لتطوير تطبيقك الخاص بدءًا من شوكة Demoshop.
يتم توريث إجراء الإنشاء والبدء إلى جانب أدوات أخرى من صورة Claranet/PHP. ستجد هناك أفكار التصميم الفني وراء هذا الالتفاف والإجابات على نقاط أخرى مثل:
docker/ FileSystemفوائد الحاويات:
يتم كشف العديد من الخدمات من قبل مكدس Docker-Corm. من أجل تشغيل المداخن بالتوازي ومنع تصادم المنافذ ، نحتاج إلى محاذاة تخصيص المنفذ.
لذلك تم تنفيذ المخطط التالي: تم ترميز رقم المنفذ على هذا النحو: ECCDD
لذلك يمكن الوصول إلى yves de عبر http: // localhost: 20100/and yves US عبر http: // localhost: 20102
إشعار: لا ينطبق التمايز بين المتاجر/المجالات حسب المنفذ إلا على بيئة التطوير المحلية. يقوم مكدس درجة الإنتاج الفعلي الذي توفره Claranet بهذا التمييز بناءً على اسم المجال الفعلي.
الفرضية المركزية هي - وهذا هو أمر بالغ الأهمية لفهمك لهذا المكدس - لبناء صورة موحدة واحدة عبر بيئات التطوير والإنتاج. هذا يؤثر على استخدام APPLICATION_ENV الذي يتم تقييمه بواسطة تطبيق Spryker نفسه.
هذا المتغير له التأثير التالي:
موقع ملفات التكوين المحلية والموارد الخارجية لا يحتاج إلى دراسة إضافية في بيئة الحاويات ، لأن كل هذه المداخن معزولة على أي حال. لذا يرجى التأكد من عدم وجود عبارة تكوين تحت ./config/Shared/ سوف تستخدم APPLICATION_ENV لتحديد مساراتهم !!!
نحن نعتبر النقطة 1.1 فقط تستحق التمييز. ونظرًا لأن هذا يمكن تحقيقه من خلال حقن VARs المناسبة في الحاويات الفعالة ، فإننا لا نميز بين البيئات أثناء بناء الصور. نظرًا لأن النقطة 1.1 تتطلب حل المزيد من التبعيات عادةً ، فإننا نقوم دائمًا بإنشاء الصورة باستخدام APPLICATION_ENV على development . ولكن في هذا الوضع ، سيتم تشغيل التطبيق فعليًا مستقلًا من ذلك.
هذا يعني أنه حتى حاويات الإنتاج سيكون لها تبعيات تطوير. السبب الرئيسي لذلك هو شرط التكافؤ dev/test/prod لضمان أن الحاويات تتصرف تمامًا في جميع المراحل وفي جميع البيئات. المقايضة لهذه الفرضية مرة أخرى صور فعالة أكبر.
أثناء وقت التشغيل ، يمكن التحكم في سلوك تطبيق Spryker عن طريق تعيين APPLICATION_ENV الذي يقبل إما development أو production . إذا كنت تستخدم ./docker/run docker/run ، سيتم تعيين هذا المتغيرات تلقائيًا.
إن الفكرة وراء البرنامج النصي المرفق المقدم عبر ./docker/run هي التمييز الأساسي بين بيئات devel prod . الفرق الرئيسي بين تلك البيئات من حيث docker-compose هو توظيف حوامل الربط في وضع Devel ، مما يتيح للمطور تحرير قاعدة التعليمات البرمجية من الخارج أثناء تشغيل الرمز في الخلفية داخل الحاويات.
نظرًا لأن هذا الإعداد يسعى إلى الحد من الجهود اليدوية ، قمنا بإعداد البرامج النصية للقذائف التي تجعل المنطق اللازم ودعمك باختصارات للمهام الأكثر شيوعًا مثل بناء الصورة أو إنشاء أو تمزيق إعداد الحاوية. تحقق من ./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 - موقع التكوين المحلي ؛ في هذه الحالة ، فإن التكوين لبيئة الحاويات.يمكّنك هذا الطلب من استخدام ملف التكوين الخاص بك بشكل مستقل تمامًا عن البيئة الفعالة التي سيعملها المتجر. يمكنك حتى التحكم في سلوك مختلف بين البيئات. لقد تجاوزنا فقط أن نقول الإعدادات المحلية للموقع ، والتي تنشأ منها هذه الفكرة.
في الوقت الحالي ، تقوم كلتا البيئتين devel و prod باستخدام أحجام لم تكشف عن اسمها والتي ترجع إلى افتراض بيئة عابرة. هذا يعني أن المكدس بالكامل يتم إنشاؤه لغرض وحيد هو التحقق من قاعدة الكود الخاصة بك. لا يعني ذلك تحت أي ظرف من الظروف كإعداد لدرجة الإنتاج ، حيث تحتاج البيانات إلى استمرار استجمام الحاويات !!!
يمكن وصف سير العمل المفترض على أنه:
تم لف docker-compose(1) عبر البرنامج النصي shell ./docker/run . يوفر هذا البرنامج النصي اختصارات لمعظم المهام الشائعة أثناء الانتباه إلى المستودع المحلي وتكوينه:
فقط لإنشاء استخدام صورة Docker: ./docker/run build
ينطبق هذا على كلتا البيئتين لأن كلاهما يعتمد على نفس الصورة. ستقوم ببناء صورة Spryker-Demoshop الرئيسية بالإضافة إلى نكهة Jenkins-Slave المتخصصة من صورة Spryker-Demoshop.
في الواقع ، يتم بناء صورتين ، واحدة لصورة المتجر الفعلية التي يتم استخدامها لحاويات Nginx وحاويات PHP في كل من yvs وطبقة Zed ، وواحدة لحاوية Jenkins Slave. هذا الأخير يمتد فقط صورة المتجر من خلال جميع مكونات Jenkins المطلوبة من أجل إنشاء Jenkins Slave/Horker. سبب القيام بذلك في أعلى صورة المتجر الفعلية هو أن جميع وظائف الواجهة الخلفية التي يتم تشغيلها عبر Jenkins تتطلب قاعدة رمز Spryker الكاملة.
يستغرق وقت البناء على محطة عمل منتظمة مع SSDs المدمجة حاليًا 10 دقائق لكلتا الصورتين.
إذا كنت ترغب في بدء عملك بناءً على demoshop ، فقد تجد بيئة التطوير المحلية مثيرة للاهتمام. يمكّنك هذا الإعداد من تثبيت قاعدة الرموز المحلية في حاويات تشغيل ورؤية التغييرات على قاعدة التعليمات البرمجية ساري المفعول على الفور.
فقط ركض ./docker/run devel up وهناك تذهب.
تدمير مكدس التطوير بما في ذلك جميع المجلدات غير المخصصة لم ./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`
في حال كنت بحاجة إلى إعادة بناء صورة المتجر وترغب فقط في إعادة إنشاء حاوية yvs و/أو zed مع الحفاظ على جميع حاويات البيانات (redis ، es ، psql): ./docker/run devel rebuild
إذا كنت ترغب فقط في إعادة إنشاء تلك الحاويات دون إعادة بناءها تشغيل: ./docker/run devel recreate
على الرغم من أن تصحيح الأخطاء قد يكون مفيدًا بدلاً من ترك /entrypoint.sh تهيئة الحاوية لتخطي هذه الخطوات والتحقق من نفسك. يمكنك القيام بذلك عن طريق تغيير command: run-zed للحاوية المتعلقة 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. قبل هذا الإصدار ، قدمنا عملية إنشاء وتثبيت وتثبيت وتوفير كامل في البرامج النصية الموجودة في القاعدة وصورة Spryker. تم إسقاط هذا لصالح مثبت Spryker الجديد الذي لا يمثل أكثر من عقد بين التطبيق والبنية التحتية. هذا العقد بشكل صريح يثبت جميع الإجراءات اللازمة التي يجب اتخاذها من أجل بناء المتجر. لقد أعدنا هذا العقد لروتين التثبيت عبر config/installer/claranet.yml .
أسقطنا دعم جبال الألب لصالح دبيان امتداد! إذا كنت بحاجة إلى جبال الألب ، فيرجى استخدام الإصدارات السابقة 2.28.0 ، لكننا لا ندعم جبال الألب.
ملاحظة أيضًا: تم تبديل الصورة الأصل من 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.
