الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

Docker Image Claranet/Spryker-Base

ملاحظة مهمة: تم إهمال هذا المشروع! يرجى استخدام claranet/spryker-demoshop كمرجع bootstrap أو صورة الوالدين claranet/php للحصول على مجموعة كبيرة من PHP! لم نعد نحافظ على هذا المشروع بعد الآن.

  • ماذا؟
  • لماذا؟
  • تصميم
    • صورة Docker
    • بناء بيئة الوقت
    • بيئات وقت التشغيل
    • بناء طبقة
    • المستودعات الخاصة
    • تكوين Spryker
    • مجلدات Docker
  • الاتفاقيات
  • قم بإنشاء صورتك المخصصة
  • بناء وتشغيل
  • التكوينات
    • متغيرات بيئة وقت التشغيل - المرجع
    • البناء متغير الوقت - المرجع
    • حقن التكوينات المخصصة
      • مجلدات خارجية
      • تشكل صورة الطفل
  • التخصيص
    • build.conf
    • بناء الخطوات
    • init
      • مستوى الحاوية
      • الإعداد على نطاق واسع
    • النشر
    • خطوات بناء مخصصة
      • قطع الأشجار
      • تثبيت حزم إضافية
  • غير موثق هنا؟
  • التعليمات
    • أين تجد سجلات؟
    • ما هي الصورة الأساسية التي تستخدمها؟
    • لماذا لا تستخدم جبال الألب بعد الآن؟
    • كيف تزيد من تسريع بناء الصورة؟
  • مشاكل

ماذا؟

تخدم هذه الصورة الغرض من توفير البنية التحتية الأساسية لـ YVES و ZED. البنية التحتية من حيث البرامج النصية للبناء/init والمزيد من الأدوات حول المتجر نفسه. هذه الصورة لا توفر متجرًا جاهزًا لاستخدام متجر! من أجل استخدام الميزات التي تم تنفيذها هنا ، اكتب Dockerfile الخاصة بك - والتي تستخدم هذه الصورة الأساسية للوراثة من - على طول تنفيذك الفعلي لمتجر Spryker.

هذا المشروع لا يزال في الإصدار التجريبي وسيخضع لتغييرات محتملة!

لهذا السبب نحن حريصون على الحصول على ملاحظات منك! هذا هو العمل الجاري للتقدم الذي يسعى إلى جعل موطن متجر Spryker سهلًا قدر الإمكان. من أجل تحقيق هذا الهدف بنجاح ، نحتاج إلى تحديد الخطوات المشتركة التي تستحق تعميمها ووضعها في هذه الصورة الأساسية. لذا أخبرنا عن احتياجاتك وتجاربك.

إذا كنت ترغب في رؤية هذه الصورة في العمل وكيف سيتم استخدامها ، تحقق من Demoshop spryker. هذا demoshop بمثابة تطبيق مرجعي للصورة الأساسية. بنفس الطريقة التي يطور بها Spryker حزمهم وجعل demoshop تعكس تلك التغييرات التي نستخدمها demoshop بنفس الطريقة تمامًا.

السمات الأساسية هي:

  • توفير بيئة وقت تشغيل PHP مع أكثر وحدات PHP شيوعا
  • يستخدم ميزة Dockers ONBUILD Trigger لربط عملية بناء صورة الطفل والتحكم فيه
  • توفير تكوين FPM/NGINX الافتراضي المعقول
  • مفتوح للتخصيص من خلال توفير خطوات الإنشاء والتكوين القابلة للتوصيل
  • يتوقع الهيكل الأساسي مثل Spryker-Demoshop
  • لا توجد قيود أخرى ، فأنت حر تمامًا في تصميمك بالطريقة التي تريدها

لماذا؟

فوائد الحاويات:

  • تناسق
  • استنساخ
  • portablity
  • يشكل النشر غير الملحوم التنمية المحلية في بيئة Prod

تصميم

صورة Docker

الفرضية الأولى هي أننا قررنا خدمة حاوية YVES و Zed من صورة واحدة. والفائدة هي دائمًا ترقية قاعدة التعليمات البرمجية المشتركة عبر مجموعة كاملة. المقايضة هي صور أكبر قليلاً ، حيث يجب تضمين متطلبات كلا المكونين.

بناء بيئة الوقت

فرضية أخرى هي - وهذا هو أمر بالغ الأهمية لفهمك لهذا المكدس - لبناء صورة موحدة واحدة عبر بيئات التطوير والإنتاج. هذا يؤثر على استخدام APPLICATION_ENV الذي يتم تقييمه بواسطة تطبيق Spryker نفسه.

هذا المتغير له التأثير التالي:

  1. أثناء وقت البناء:
    1. ما هي الحزم التي سيتم تثبيتها عبر دقة التبعية (الملحن ، NPM)؟
    2. أوضاع مختلفة في بناء الأصول
  2. أثناء وقت التشغيل:
    1. أين التطبيق على وشك العثور على ملفات التكوين (تكوين الدفع)؟
    2. أين توجد الموارد الخارجية؟
    3. هل يمكّن التطبيق السلوك Symfony Debug/Devel؟

موقع ملفات التكوين المحلية والموارد الخارجية لا يحتاج إلى دراسة إضافية في بيئة الحاويات ، لأن كل هذه المداخن معزولة على أي حال. لذا يرجى التأكد من عدم وجود عبارة تكوين تحت ./config/Shared/ سوف تستخدم APPLICATION_ENV لتحديد مساراتهم !!!

نحن نعتبر النقطة 1.1 فقط تستحق التمييز. ونظرًا لأن هذا يمكن تحقيقه من خلال حقن VARs المناسبة في الحاويات الفعالة ، فإننا لا نميز بين البيئات أثناء بناء الصور. نظرًا لأن النقطة 1.1 تتطلب حل المزيد من التبعيات عادةً ، فإننا نقوم دائمًا بإنشاء الصورة باستخدام APPLICATION_ENV على development . ولكن في أي وضع سيتم تشغيل التطبيق بالفعل مستقل من البناء.

هذا يعني أنه حتى حاويات الإنتاج سيكون لها تبعيات DEV. السبب الرئيسي لذلك هو شرط التكافؤ dev/test/prod لضمان أن الحاويات تتصرف تمامًا في جميع المراحل وفي جميع البيئات. المقايضة لهذه الفرضية مرة أخرى صور فعالة أكبر. أثناء وقت التشغيل ، يمكن التحكم في سلوك تطبيق Spryker عن طريق تعيين APPLICATION_ENV الذي يقبل إما development أو production . إذا كنت تستخدم ./docker/run docker/run ، سيتم تعيين هذا المتغيرات تلقائيًا.

بيئات وقت التشغيل

تتبع الفكرة وراء البرامج النصية المنصوص عليها في هذا ./shop/docker المجلد الفرعي التمييز الأساسي بين بيئات devel prod . الفرق الرئيسي بين تلك البيئات من حيث docker-compose هو توظيف حوامل الربط في وضع Devel ، مما يتيح للمطور تحرير قاعدة التعليمات البرمجية من الخارج أثناء تشغيل الرمز في الخلفية داخل الحاويات.

نظرًا لأن هذا الإعداد يسعى إلى الحد من الجهود اليدوية ، قمنا بإعداد البرامج النصية للقذائف التي تجعل المنطق اللازم ودعمك باختصارات للمهام الأكثر شيوعًا مثل بناء الصورة أو إنشاء أو تمزيق إعداد الحاوية. تحقق من ./docker/run help

تهدف بيئة prod إلى اختبار نتيجة عملك في بيئة قريبة من البرودة ، مما يعني أنه لن يتم إنشاء بيانات مشتركة بين مستودعك المحلي والحاوية. علاوة على ذلك ، سيتم تشغيل التطبيق باستخدام APPLICTION_ENV=production التي تعطل عمليات التطوير المحددة.

بناء طبقة

يتمثل المفهوم الذي أدخلته هذه الصورة الأساسية في تقسيم صورة المتجر الناتجة إلى 3 طبقات متميزة (بفعالية هناك أكثر من 3 طبقات فقط ، لأن كل عبارة في Dockerfile تؤدي إلى طبقة جديدة ؛ لكن فكرة 3 طبقات متميزة تجريد منطق OnbatiLd Trigger أكثر سهولة ومفهومة). هناك بعض الأسباب لهذا:

  • أولاً ، يجب أن تستفيد من ذاكرة التخزين المؤقت Docker وتسريع عمليات إعادة البناء التكرارية لصورة المتجر. نظرًا لأن هذه الطبقات يتم طلبها من عام إلى محدد ، يجب تقليل الحاجة إلى إعادة بناء المكدس بأكمله أثناء العمل بشكل متكرر على قاعدة التعليمات البرمجية لتنفيذ المتجر الفعلي.

  • ثانياً ، يمكن استرداد طبقات مختلفة بالتوازي أثناء سحب الصورة ، مما يزيد من وقت إنشاء الحاويات والذي لا يتمتع بالتطوير المحلي فحسب ، بل للنشر في إعداد الإنتاج. علاوة على ذلك ، نظرًا لأن الطبقات العامة لا تتغير في كثير من الأحيان ، يجب تقليل الحاجة إلى إعادة البناء فحسب ، بل لإعادة تشكيل الصورة بأكملها أيضًا.

لسوء الحظ ، لا يأتي هذا بدون تكلفة ، سيكون حجم الصورة الفعال أعلى قليلاً من تلك التي يتم تراكمها بواسطة طبقة واحدة فقط. في الوقت الحالي ، يبدو أن هذا بمثابة مفاضلة مقبولة.

ما هي مسؤوليات تلك الطبقات وأين تقع ومتى سيتم بناؤها؟

  • claranet/spryker-base (هذه الصورة):
    • الطبقة الأساسية - قم بتثبيت جميع البنية التحتية الأساسية لمستوى نظام التشغيل ، PHP والوحدات النمطية الأكثر شيوعًا.
  • claranet/spryker-demoshop (صورة المتجر المصب ، على سبيل المثال demoshop):
    • الطبقة الأساسية - قم بتثبيت وحدات PHP إضافية و/أو تجاوز الطبقة الأساسية من صورة spryker-base (ضع في اعتبارك $REBUILD_BASE_LAYER Variable)
    • طبقة التبعية - حل جميع تبعيات PHP/Node المحددة المتجر
    • طبقة الرمز - بناء رمز محدد مثل ORM ، كائنات tranfer

المستودعات الخاصة

في حالة حاجة إلى سحب تبعيات PHP أو العقدة من مستودع خاص ، تحتاج فقط إلى توفير ~/.netrc . سيتم اكتشاف هذا الملف تلقائيًا وبشكل مؤقت كما تم حقن Docker Build Argle في حاوية البناء العابرة ، وتستخدمها GIT لاستنساخ المستودعات المناسبة ، وبعد ذلك تم القضاء على طبقة إعادة التثبيت مباشرة قبل إغلاق الطبقة.

التنسيق الخاص بـ $HOME/.netrc على النحو التالي: 

 machine git.company.local
login my_user_name
password my_private_token

من أجل تسري مفعول جميع التبعيات المعينة ، يجب إعطاء إما عن url http أو يتم تحويلها عبر git config --global "url.https://".insteadof "git://git@ التي تم إعدادها بالفعل من قبل الصورة الأساسية.

إذا كنت ترغب في إضافة المزيد من القواعد المحددة ، قم بإنشاء برنامج نصي بناء في طبقة التبعية يتم تنفيذه قبل عملية حل التبعية: 

 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]"

نظرًا لأن عناوين URL GIT يمكن إعطاءها في مجموعة تعسفية ، فهذا ضروري في بعض الظروف.

كل هذا ضروري لأن Docker يرفض تنفيذ أحجام وقت البناء مما يجعل هذه العملية أسهل. لكنهم حصلوا على أسباب مذهلة بالفعل ، نظرًا لأن سموه ستعرض لخطر التكاثر ، لأن Dockerfile ليس هو المصدر الوحيد لعمليات الإنشاء. IS - كما هو الحال في أي حجة تقنية - لا الحقيقة المطلقة ، فقط المقايضات.

تكوين Spryker

نظرًا لأن الخدمات الخارجية في البيئة المقيد يمكن الوصول إليها على عنوان مختلف اعتمادًا على البيئة ، فإن الكود يعمل في نحتاج إلى تعديل بعض التكوينات. لذلك ، نستخدم آلية Spryker الأصلية لطبقة ملف التكوين من أجل حقن تكويننا عبر موقع تكوين تكوين config/Shared/config_local.php . لأن هذا الملف هو الذي يتجاوز جميع الآخرين.

أمر التكوين كما يلي:

  • config_default.php - التكوين الأساسي
  • config_default-development.php - التكوين ذي الصلة لوضع التطوير (انظر APPLICATION_ENV )
  • config_local.php - موقع التكوين المحلي ؛ في هذه الحالة ، فإن التكوين لبيئة الحاويات.

يمكّنك هذا الطلب من استخدام ملف التكوين الخاص بك بشكل مستقل تمامًا عن البيئة الفعالة التي سيعملها المتجر. يمكنك حتى التحكم في سلوك مختلف بين البيئات. لقد تجاوزنا فقط أن نقول الإعدادات المحلية للموقع ، والتي تنشأ منها هذه الفكرة.

لهذا ، كنا بحاجة إلى إزالة config/Shared/config_local.php من قائمة .gitignore .

مجلدات Docker

في الوقت الحالي ، تقوم كلتا البيئتين devel و prod باستخدام أحجام لم تكشف عن اسمها والتي ترجع إلى افتراض بيئة عابرة. هذا يعني ، يتم إنشاء المكدس بالكامل لغرض وحيد هو التحقق من قاعدة الكود الخاصة بك. لا يعني ذلك تحت أي ظرف من الظروف كإعداد لدرجة الإنتاج ، حيث تحتاج البيانات إلى استمرار استجمام الحاويات !!!

يمكن وصف سير العمل المفترض على أنه:

  1. خلق بيئة
  2. تهيئة مع البيانات الوهمية
  3. تطوير قاعدة الكود
  4. التكرار: Rebuild -> Run -> init -> تطور
  5. تدمير البيئة

الاتفاقيات

من أجل إعادة استخدام الوظائف المنفذة هنا ، يجب توافق الجوانب التالية مع الصورة الأساسية:

  • اتبع التسلسل الهرمي لدليل مرجع Spryker
    • ./src/Pyz - تطبيق متجرك
    • ./config - التكوين
    • ./public/{Yves,Zed}
  • التبعيات
    • PHP: composer.json و composer.lock
    • العقدة: packages.json ، packages.lock and yarn.lock
  • جعل تكوين Spryker النظر في env vars. تحقق من Shop_skel/config/sharpt/config_local.php الذي يمثل ما هو المقصود بهذه النقطة
  • التحكم في التبعيات التي تريد تثبيتها (امتدادات PHP ، ديب العقدة ./docker/build.conf إلخ.
  • التحكم في عملية بناء الصورة عن طريق وضع البرامج النصية للبناء المخصصة تحت ./docker/build.d/
  • التحكم في عملية التهيئة للإعداد عن طريق وضع البرامج النصية الخاصة بك تحت ./docker/init.d/

تحقق من demoShop لقد استعدنا لاستخدام هذه الصورة هنا. يجب أن يجيب هذا على جميع الأسئلة التي قد تكون لديك.

قم بإنشاء صورتك المخصصة

نظرًا لأن التنفيذ المرجعي هو demoshop الذي يحتفظ به لنا ، فهذا بداية جيدة. إما عن طريق فصوص هذا الريبو أو بالبدء من الصفر.

إذا كنت ترغب في البدء من الصفر ، فإن القطع الأثرية الوحيدة التي تحتاجها من Demoshop هي:

  • ./docker/*
  • ./Dockerfile
  • ./.dockerignore
  • ./config/Shared/config_local.php

بهذا ، أنت مستعد لملء مستودعك بالرمز وتخصيصه لتلبية احتياجاتك الفردية.

ضع في اعتبارك Dockerfile التي تبدو نظيفة مثل هذا: 

 FROM claranet/spryker-base:latest

هذه الروائح مثل إعادة الاستخدام. سائدا

بناء وتشغيل

حصل هيكل العظمي و demoshop وكذلك على نص Shell تحت ./docker/run الذي يوفر لك اختصارات للمهام الأكثر شيوعًا. الخروج من readme.md هناك لمزيد من التفاصيل. 

 # 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

التكوينات

متغيرات بيئة وقت التشغيل - المرجع

يجب توفير هذه المتغيرات أثناء إنشاء الحاويات كمتغيرات بيئة.

يتم استهلاك معظم المتغيرات بواسطة ملف 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"

تستهلكها خطافات التهيئة:

  • ZED_ADMIN_PASSWORD - إذا تم تعيين كلمة المرور الافتراضية لمستخدم [email protected]
  • ENABLE_XDEBUG - سيتم تنشيط وتكوين وحدة PHP وحدة xdebug .
  • ENABLE_OPCACHE - سيتم تنشيط وتكوين وحدة PHP وحدة opcache .

البناء متغير الوقت - المرجع

يجب توفير هذه المتغيرات عبر مشروعك الخاص ./docker/build.conf

  • PROJECT (إلزامي)-يتحكم في بادئة اسم الخدمات التي تم docker-compose
  • IMAGE (إلزامية) - ما هو اسم صورة Docker الناتجة؟
  • VERSION (إلزامي) - ما هو إصدار صورة Docker التي نعمل عليها؟
  • BUILD_DEPENDENCIES - حزم التوزيع (Debian) ليتم تثبيتها أثناء وقت البناء
  • BASE_DEPENDENCIES - حزم التوزيع (Debian) ليتم تثبيتها بالإضافة إلى ذلك
  • PHP_EXTENSIONS - قائمة منفصلة للمساحة لتمديد PHP ليتم تثبيتها
  • NPM_DEPENDENCIES - حزم التوزيع التي سيتم تمييزها قبل معالجة NPM في طبقة DEPS
  • KEEP_DEVEL_TOOLS (افتراضي: خطأ) - هل يتم تثبيت أدوات التطوير والاحتفاظ بها خارج البناء؟
  • SKIP_CLEANUP (افتراضي: خطأ) - تخطي خطوة التنظيف في كل مرحلة بناء طبقة. هذا يساعد في قضايا تصحيح الأخطاء. كن على دراية ، أن هذا يتخطى مسح بيانات الاعتماد كذلك! لذلك لا تصدر مثل هذه الصورة في البرية !!!
  • CRONJOB_HANDLER - يحدد مكان تسجيل cronjobs. حاليا جينكينز وكروند مدعوم.
  • REBUILD_BASE_LAYER - إذا تم إعطاء هذا البناء var ، فسيتم إعادة بناء الطبقة الأساسية أثناء بناء صورة المتجر في اتجاه مجرى النهر

حقن التكوينات المخصصة

من أجل التحكم في سلوك NGINX أو PHP-FPM أو PHP ، يمكنك إما حقن التكوين من الجزء الخارجي من الحاوية كما يتصاعد الربط أو عبر Dockerfile من صورة متجر الطفل.

مجلدات خارجية

تم إعداد تكوين الخدمات لتضمين العديد من الملفات التي شكلت التكوين الفعال.

يتم مسبق جميع التكوينات لتكون متوقعة تحت دليل محدد حيث ستقوم جميع الملفات ذات الصلة

المواقع المتوقعة هي:

  • nginx
    • /etc/nginx/spryker/yves.conf.d/*.conf
    • /etc/nginx/spryker/zed.conf.d/*.conf
  • PHP FPM
    • /etc/php/fpm/yves.conf.d/*.conf
    • /etc/php/fpm/zed.conf.d/*.conf
  • PHP ini
    • /etc/ /etc/php/ini/*.ini .

يمكن العثور على التكوين الافتراضي تحت: 

 /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

في البيئات التي يمكنك من خلالها تثبيت الدلائل الكاملة في الحاوية ، قمنا بإعداد آلية تتوقع التسلسل الهرمي للدليل تحت /mnt/configs وعلى إنشاء الحاوية ، فإنه يتوافق مع جميع الملفات تحت هذا الموقع إلى موقعها المقابل تحت /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

تشكل صورة الطفل

نظرًا لطبيعة أنظمة الملفات ذات الطبقات ، فإن صورة الطفل التي ترثها هذه الصورة الأساسية يمكن أن تكوين تكوينات بسيطة من أجل تحقيق السلوك المطلوب لتلك الخدمات.

يمكن تخصيصها بسهولة عن طريق توفير ملفات التكوين بنفسك عبر Dockerfile : 

 FROM claranet/spryker-base:latest
COPY my_custom_zed.conf /etc/nginx/spryker/zed.conf.d/custom.conf

نظرًا لأن تشغيل OnBuild سيكون أول توجيهات لـ Dockerfile للأطفال ، فستتوفر هذه الملفات المتجاوز لأول مرة أثناء تشغيل الحاوية.

التخصيص

تخضع معظم قرارات التصميم المتخذة في الصورة الأساسية لفكرة التخصيص والتوسيع. الصورة الأساسية التي يمكن استخدامها مرة واحدة فقط لصورة متجر فردية عديمة الفائدة إلى حد بعيد وبعيدًا عن شيء يسمى قاعدة.

build.conf

عملية الإنشاء إلى حد كبير حيث يشير الاسم إلى العملية التي تنتج الصورة التي يتم مشاركتها بواسطة جميع الحاويات المشتقة أثناء وقت التشغيل لاحقًا.

بعض البرامج النصية للبناء تعتبر المعلمات التي يمكنك تعيينها ./docker/build.conf

انظر المرجع أعلاه ..

بناء الخطوات

Hook Dir: ./docker/build.d/

إذا كنت ترغب في توسيع خطوات الإنشاء الموروثة من الصورة الأساسية أو لتعطيلها ، فأنت بحاجة إلى وضع نص إنشاء مخصص تحت ./docker/build.d/ . ستجد هناك 3 أدلة تعكس كل مرحلة/طبقة:

  • ./docker/build.d/base/ - منشآت مستوى نظام التشغيل الأساسي
  • ./docker/build.d/deps/
  • ./docker/build.d/shop/ - تعامل مع توليد الكود لقاعدة رمز المتجر الفعلية

يتم تنفيذ البرامج النصية لكل فرعي تم تنفيذها معجمًا (تم الحصول على Actuall).

على سبيل المثال ، إذا كنت ترغب في تغيير الطريقة التي يتم بها بناء ذاكرة التخزين المؤقت للملاحة بواسطة الصورة الأساسية ، فيجب عليك توفير برنامج نصي في نفس الموقع الذي يتم توفيره بواسطة الصورة الأساسية ضمن ./docker/build.d/shop/650_build_navigation_cache.sh . نظرًا لأن الصورة الناتجة وكذلك الحاوية ستستخدم أنظمة ملفات الاتحاد ، فإن الملفات التي توفرها صورة المتجر تحصل على الأسبقية على تلك التي توفرها صورة BAS. من خلال هذه الآلية ، يمكنك إما تعطيل الوظيفة ببساطة عن طريق توفير برنامج نصي لا يفعل شيئًا أو يمكنك تغيير السلوك عن طريق إضافة نص يقوم بشيء مختلف أو بالإضافة إلى ذلك.

init

يمكن استخدام نفس الآلية الموضحة أعلاه لتغيير الطريقة التي يتم بها تنفيذ تهيئة حاوية Spryker والإعداد بأكمله. تأتي الصورة الأساسية مع افتراضات ذات معنى صالحة للبيئات الشائعة ، ولكن يمكن تجاوزها عن طريق وضع البرامج النصية المخصصة في المواقع المناسبة.

توفر الصورة الأساسية السنانير لكليهما ، وتهيئة كل من الحاوية ، ولهيئة الإعداد بأكمله.

مستوى الحاوية

Hook Dir: ./docker/entry.d/

تحكم الوسائط في نقطة إدخال وقت التشغيل ( run-yves ، run-zed ، run-yves-and-zed ، run-cron ) الدور الذي تلعبه هذه الحاوية الفعلية ، وكلها مصدر الملفات المدرجة في دليل الخطاف هذا. عبر المتغيرات ، تقرر البرامج النصية الخدمات التي يجب تمكينها والبدء خلال وقت التشغيل.

تتمثل المهمة الشائعة في تمكين xdebug كما هو مطلوب عبر ENV var ENABLE_XDEBUG على إنشاء الحاوية.

نظرًا للطبيعة ، سيتم تنفيذ جميع الخطافات في كل بداية حاوية.

الإعداد على نطاق واسع

Hook Dir: ./docker/init.d/

عادة ما يحتاج كل مثيل متجر إلى تنفيذ الخطوات الأولية لتهيئة مثل هذا المتجر. خلال هذا الإعداد تهيئة واسعة جميع البرامج النصية shell تحت الخطاف يتم تنفيذها. على سبيل المثال لتهيئة قاعدة البيانات باستخدام بيانات وهمية مثل DemoShop ، يضع البرنامج النصي تحت ./docker/init.d/500_import_demo_data.sh .

لم يتم ذلك بشكل ضمني ، يجب أن تولد حاوية منفصلة مع نقطة الدخول arg init .

النشر

Hook Dir: ./docker/deploy.d/

نفس إجراء البداية هو إجراء النشر. سيتم تنفيذ هذا الإجراء أثناء عمليات النشر. يتكون مفهوم دورة الحياة من هذين السنانير: سيتم استدعاء init في المرة الأولى ، وسيتم النشر في كل مرة يتم فيها تنفيذ إصدار جديد من الصورة.

لم يتم ذلك بشكل ضمني ، يجب أن تولد حاوية منفصلة مع deploy نقطة الدخول ARG.

خطوات بناء مخصصة

كما ذكرنا سابقًا ، فأنت حر في إضافة خطوات البناء والبدء المخصص للغاية. سوف يساعدك ./docker/common.inc.sh تحقق من ذلك بنفسك.

قطع الأشجار

اجعل خطوة البناء الخاصة بك تخبر باستخدام وظائف الإخراج المعدة:

  • errorText - رفع خطأ
  • successText - أرسل النجاح مرة أخرى
  • sectionHead - عنوان الطباعة لمجموعة من المهام
  • sectionText - طباعة معلومات خطوة البناء الوسيطة

تثبيت حزم إضافية

نحن نقدم وظيفة install_packages لجميع خطوات الإنشاء المضمنة. يرجى التأكد من أنك تستخدمه! إنه يأتي مع إمكانية علامة الحزم على أنها تبعيات "بناء". ستتم إزالة الحزم التي تم وضع علامة عليها مع إزالة الاعتماد على البناء بعد تشطيبات بناء الطبقة. للإعلام عن الحزم على أنها تبعيات بناء فقط --build -كحجة أولى: 

 # remove "gcc" at the end of our image build
install_packages --build gcc
 
# keep "top" in the resulting image
install_packages top

غير موثق هنا؟

ما زلنا في المراحل المبكرة من هذا المشروع ، لذلك قد تكون الوثائق غير مكتملة. إذا كنت ترغب في معرفة المزيد عن الميزات التي نقدمها ، فيرجى إلقاء نظرة على مكتبة Shell.

التعليمات

أين تجد سجلات؟

في مثيلات (مثيلات) yvs/zed ، يمكنك العثور على سجلات NGINX و PHP-FPM وسجلات التطبيق داخل /بيانات/سجلات/

ما هي الصورة الأساسية التي تستخدمها؟

نحن نعتمد على صور PHP الرسمية: https://hub.docker.com/_/php/

لماذا لا تستخدم جبال الألب بعد الآن؟

سؤال جيد جدا حقا!

لقد قررنا الذهاب إلى جبال الألب بسبب أوقات بناء الصور الأقصر - كل من بناء المصدر وتثبيت الحزمة. لقد كان أكثر أو أقل إثباتًا للمفهوم الذي يجب أن يظهر ، أنه يمكن استضافة مشاريع الرفع الثقيلة على جبال الألب. الفوائد المتوقعة هي تقليل أحجام الصور ووقت بناء أسرع وكذلك أوقات تشغيل أسرع.

لسوء الحظ ، اتضح أن musl lib c يقدم قيودًا لا يطاق في سياق العميل - حيث يكون التنوع هو المفتاح. منذ 0.9.6 ، انتقلنا إلى الصور المستندة إلى Debian.

كيف تزيد من تسريع بناء الصورة؟

هناك شيئان يتبادر إلى الذهن:

  • باستخدام وكيل محلي يطلب من طلبات HTTP مخزنة مؤقتًا
  • باستخدام بناء Docker متعدد المراحل المقترح

المزيد ليأتي قريبا. سائدا

مشاكل

يرجى إلقاء نظرة على /القضايا.

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل