تطوير التطبيقات ونشر Blue-Green استنادًا إلى منهجية تطبيق Twelve-Factor مع أمثلة php و docker

لنبدأ بنظرية صغيرة. ماذا حدث تطبيق Twelve Factor?

بكلمات بسيطة ، تم تصميم هذا المستند لتبسيط تطوير تطبيقات SaaS ، والمساعدة من خلال جعل المطورين ومهندسي DevOps على دراية بالمشكلات والممارسات التي غالبًا ما يتم مواجهتها في تطوير التطبيقات الحديثة.

تم إنشاء المستند من قبل مطوري منصة Heroku.

يمكن تطبيق منهجية تطبيق Twelve-Factor App على التطبيقات المكتوبة بأي لغة برمجة وباستخدام أي مجموعة من خدمات دعم الجهات الخارجية (قواعد البيانات وقوائم انتظار الرسائل وذاكرة التخزين المؤقت وما إلى ذلك).

باختصار حول العوامل نفسها التي تستند إليها هذه المنهجية:

1. قاعدة بيانات - قاعدة شفرة واحدة لتعقب المصدر - عمليات نشر متعددة
2. التبعيات - الإعلان صراحة عن التبعيات وعزلها
3. ترتيب - حفظ التكوين في وقت التشغيل
4. خدمات الطرف الثالث (خدمات الدعم) - التعامل مع خدمات الدعم كموارد قابلة للتوصيل
5. بناء ، إطلاق ، تشغيل - مراحل البناء والتشغيل منفصلة بدقة
6. العمليات - قم بتشغيل التطبيق كعملية عديمة الحالة واحدة أو أكثر
7. ميناء ملزم - خدمات التصدير عبر ربط المنافذ
8. تماثل - توسيع نطاق التطبيق الخاص بك مع العمليات
9. التخلص - تعظيم الموثوقية مع بدء التشغيل السريع والإغلاق السلس
10. تطوير التطبيق / تكافؤ التشغيل - حافظ على بيئات التطوير والتشغيل والإنتاج متشابهة قدر الإمكان
11. تسجيل - تعامل مع السجل على أنه تيار من الأحداث
12. المهام الإدارية - أداء مهام الإدارة / الإدارة بعمليات لمرة واحدة

لمزيد من المعلومات حول 12 عاملاً ، راجع الموارد التالية:

• مصدر رسمي - يجب أن يقرأ
• مقالة على habr. تطبيق Twelve-Factor - تطبيق Twelve-Factor - ترجمة رسمية
• مقالة على habr. 7 عوامل مفقودة في تطبيق 12 Factor - نظرة جديدة على الـ 12 عاملاً من أجل تحسينها.

ما هو نشر Blue-Green؟

يعد نشر Blue-Green طريقة لتقديم تطبيق إلى إنتاج بحيث لا يرى العميل النهائي أي تغييرات من جانبه. بمعنى آخر ، نشر تطبيق بصفر الوقت الضائع.

يبدو مخطط نشر BG الكلاسيكي مثل الصورة أدناه.

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

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

نصيحة سيئة وجيدة

إخلاء المسئولية: توضح الأمثلة أدناه الأدوات المساعدة / المنهجيات التي أستخدمها ، يمكنك استخدام أي بدائل على الإطلاق بوظائف مماثلة.

ستتقاطع معظم الأمثلة بطريقة ما مع تطوير الويب (يا لها من مفاجأة) ، مع PHP و Docker.

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

1. قاعدة بيانات

استخدم FTP و FileZilla لتحميل الملفات على الخوادم واحدًا تلو الآخر ، ولا تقم بتخزين الكود في أي مكان باستثناء خادم الإنتاج.

يجب أن يحتوي المشروع دائمًا على قاعدة رمز واحدة ، أي أن كل الكود يأتي من واحد بوابة مخزن. الخوادم (الإنتاج ، التدريج ، الاختبار 1 ، الاختبار 2 ...) تستخدم رمزًا من فروع مستودع واحد مشترك. وبالتالي ، نحقق تناسق الكود.

2. التبعيات

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

يجب أن يحتوي المشروع دائمًا على قائمة مفهومة بوضوح من التبعيات (بالتبعية ، أعني أيضًا البيئة). يجب تحديد جميع التبعيات بوضوح وعزلها.
كمثال ، لنأخذ ملحن и عامل في حوض السفن.

ملحن - مدير الحزم الذي يسمح لك بتثبيت المكتبات في PHP. يمنحك Composer القدرة على تحديد الإصدارات بدقة أو عدم تحديدها بشكل صريح. يمكن أن يكون هناك 20 مشروعًا مختلفًا على الخادم ، وسيكون لكل منها قائمة خاصة بالحزم والمكتبات المستقلة عن الأخرى.

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

3. التكوين

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

التكوينات - هذا هو الشيء الوحيد الذي يجب أن يختلف في نشر المشروع (النشر). من الناحية المثالية ، يجب تمرير التكوينات من خلال متغيرات البيئة (env vars).

أي ، حتى إذا قمت بتخزين العديد من ملفات التكوين .config.prod .config.local وأعد تسميتها في وقت النشر إلى .config (التكوين الرئيسي الذي يقرأ التطبيق البيانات منه) - لن يكون هذا هو النهج الصحيح ، لأن في هذه الحالة ، ستكون المعلومات من التكوينات متاحة للجمهور لجميع مطوري التطبيقات وسيتم اختراق البيانات من خادم الإنتاج. يجب تخزين جميع التكوينات مباشرة في نظام النشر (CI / CD) وإنشاء بيئات مختلفة بقيم مختلفة ضرورية لبيئة معينة في وقت النشر.

4. خدمات الطرف الثالث (خدمات الدعم)

اربط بشدة بالبيئة ، واستخدم اتصالات مختلفة لنفس الخدمات في بيئات معينة.

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

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

5. بناء ، تحرير ، تشغيل

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

يجب فصل جميع مراحل النشر عن بعضها البعض.

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

هذا هو المكان الذي نتذكر فيه نشر Blue-Green ، والذي يسمح لك ليس فقط بالتبديل بين الكود ، ولكن أيضًا التبديل بين جميع الموارد وحتى البيئات مع القدرة على التراجع عن كل شيء.

6- العمليات

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

فيما يتعلق بالجلسات ، قم بتخزين البيانات فقط في ذاكرة تخزين مؤقت يتم التحكم فيها بواسطة خدمات جهات خارجية (memcached ، redis) ، لذلك حتى إذا كان لديك 20 عملية تطبيق قيد التشغيل ، فسيتمكن أي منها من الوصول إلى ذاكرة التخزين المؤقت من مواصلة العمل مع العميل في نفس الحالة حيث كان المستخدم يعمل مع التطبيق في عملية أخرى. باستخدام هذا النهج ، اتضح أنه بغض النظر عن عدد نُسخ خدمات الجهات الخارجية التي تستخدمها ، سيعمل كل شيء بشكل صحيح وبدون مشاكل في الوصول إلى البيانات.

7. ميناء ملزم

يجب أن يعرف خادم الويب فقط كيفية العمل مع خدمات الجهات الخارجية. ومن الأفضل بشكل عام رفع خدمات الجهات الخارجية مباشرة داخل خادم الويب. على سبيل المثال ، كوحدة PHP في Apache.
يجب أن تكون جميع خدماتك في متناول بعضها البعض من خلال استدعاء بعض العناوين والمنافذ (localgost: 5432 ، localhost: 3000 ، nginx: 80 ، php-fpm: 9000) ، أي من nginx يمكنني الوصول إلى كل من php- fpm و postgres ، ومن php-fpm إلى postgres و nginx ، ومن كل خدمة بحد ذاتها ، يمكنني الوصول إلى خدمة أخرى. وبالتالي ، فإن صحة الخدمة ليست مرتبطة بصحة خدمة أخرى.

8. التوازي

اعمل مع عملية واحدة ، ثم فجأة لن تتمكن العديد من العمليات من التوافق مع بعضها البعض!

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

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

9. التخلص منها

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

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

10. تطوير التطبيقات / تكافؤ التشغيل

يجب أن يكون إصدار التطبيق والإصدار المرحلي والمحلي مختلفًا. في الإنتاج ، لدينا إطار عمل Yii Lite و Yii محليًا ، بحيث يعمل بشكل أسرع في الإنتاج!

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

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

11. التسجيل (السجلات)

نكتب السجلات إلى الملفات وقاعدة البيانات! لا نقوم بتنظيف الملفات وقاعدة البيانات من السجلات. دعنا فقط نشتري قرصًا صلبًا مقابل 9000 بيتا بايت والمعايير.

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

12. مهام الإدارة

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

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

مثال تطبيقي في PHP و Laravel و Laradock و Docker-Compose

ملاحظة: تم عمل جميع الأمثلة على نظام التشغيل MacOS. سيعمل معظمها مع Linux أيضًا. عذرًا ، مستخدمي Windows ، لكني لم أعمل مع Windows لفترة طويلة.

تخيل موقفًا ليس لدينا أي إصدار من PHP مثبت على جهاز الكمبيوتر الخاص بنا ولا شيء على الإطلاق.
قم بتثبيت أحدث إصدارات docker و docker-compose. (يمكن العثور على هذا عبر الإنترنت)

docker -v && 
docker-compose -v

1. نضع لارادوك

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. تكوين Laradock لكي يعمل تطبيقنا.

cd laradock && 
cp env-example .env

2.1. افتح دليل habr (المجلد الأصل الذي تم استنساخ laradock فيه) في أي محرر. (في حالة PHPStorm الخاصة بي)

في هذه المرحلة ، نضع فقط اسم المشروع.

2.2. نطلق صورة مساحة العمل. (في حالتك ، سيتم إنشاء الصور لبعض الوقت)
Workspace عبارة عن صورة معدة خصيصًا للعمل مع إطار العمل نيابة عن المطور.

اذهب داخل الحاوية مع

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3 تثبيت Laravel

composer create-project --prefer-dist laravel/laravel application

2.4 بعد التثبيت ، نتحقق مما إذا كان الدليل الذي يحتوي على المشروع قد تم إنشاؤه ، ونقتل الإنشاء.

ls
exit
docker-compose down

2.5 نعود إلى PHPStorm ونضبط المسار الصحيح لتطبيق Laravel في ملف .env.

3. أضف كل الشفرة إلى Git.

للقيام بذلك ، سننشئ مستودعًا على Github (أو في أي مكان آخر). دعنا نذهب إلى دليل habr في المحطة وننفذ الكود التالي.

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

نتحقق مما إذا كان كل شيء في محله.

للراحة ، أوصي باستخدام نوع من الواجهة المرئية لـ Git ، في حالتي هذا هو GitKraken. (رابط الإحالة هنا)

4. إطلاق!

قبل البدء ، تأكد من عدم وجود أي شيء معلق على المنفذين 80 و 443.

docker-compose up -d nginx php-fpm

وبالتالي ، فإن مشروعنا يتكون من 3 خدمات منفصلة:

• nginx - خادم الويب
• php-fpm - php لتلقي الطلبات من خادم الويب
• مساحة العمل - php للمطور

في الوقت الحالي ، توصلنا إلى أننا أنشأنا تطبيقًا يقابل 4 نقاط من أصل 12 ، وهي:

1. قاعدة بيانات - كل الكود موجود في مستودع واحد (ملاحظة صغيرة: قد يكون من الصواب إحضار عامل ميناء داخل مشروع Laravel ، لكن هذا ليس مهمًا).

2. التبعيات - جميع تبعياتنا مكتوبة صراحةً في application / composer.json وفي كل Dockerfile لكل حاوية.

3. خدمات الطرف الثالث (خدمات الدعم) - كل خدمة (php-fom ، nignx ، مساحة العمل) تعيش حياتها الخاصة وتكون متصلة من الخارج وعند العمل مع خدمة واحدة ، لن تتأثر الأخرى.

4. العمليات كل خدمة هي عملية واحدة. كل خدمة لا تخزن الحالة الداخلية.

5. ميناء ملزم

docker ps

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

6. تماثل

يتيح لنا Docker إنتاج عمليات متعددة لنفس الخدمات مع موازنة تلقائية للحمل بينها.

أوقف الحاويات وابدأها بعلم --حجم

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

كما نرى ، تحتوي حاوية php-fpm على نُسخ. لا نحتاج إلى تغيير أي شيء في العمل مع هذه الحاوية. نواصل أيضًا الوصول إليه على المنفذ 9000 ، ويقوم Docker بتنظيم التحميل بين الحاويات لنا.

7. التخلص - يمكن قتل كل حاوية دون الإضرار بالآخر. لن يؤثر إيقاف الحاوية أو إعادة تشغيلها على تشغيل التطبيق في عمليات التشغيل اللاحقة. يمكن أيضًا رفع كل حاوية في أي وقت.

8. تطوير التطبيق / تكافؤ التشغيل كل بيئاتنا هي نفسها. من خلال تشغيل النظام على الخادم في الإنتاج ، لا يتعين عليك تغيير أي شيء في أوامرك. كل شيء سيعتمد على Docker بنفس الطريقة.

9. تسجيل - تنتقل جميع السجلات الموجودة في هذه الحاويات إلى الدفق وتكون مرئية في وحدة تحكم Docker. (في هذه الحالة ، في الواقع ، مع حاويات أخرى محلية الصنع ، قد لا يكون الأمر كذلك إذا لم تعتني بها)

 docker-compose logs -f

ولكن ، هناك مشكلة تتمثل في أن القيم الافتراضية في PHP و Nginx تكتب أيضًا سجلات إلى ملف. تحتاج إلى تلبية الـ 12 عاملاً اغلاق كتابة السجلات إلى ملف في تكوينات كل حاوية على حدة.

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

10 المهام الإدارية - يتم حل جميع مهام الإدارة عن طريق Laravel بفضل أداة الحرفيين تمامًا كما يود مبتكرو تطبيق 12 عاملاً.

كمثال ، سأوضح كيف يتم تنفيذ بعض الأوامر.
نذهب إلى الحاوية.

 
docker-compose exec workspace bash
php artisan list

الآن يمكننا استخدام أي أمر. (يرجى ملاحظة أننا لم نقم بإعداد قاعدة البيانات وذاكرة التخزين المؤقت ، لذلك لن يتم تنفيذ نصف الأوامر بشكل صحيح ، لأنها مصممة للعمل مع ذاكرة التخزين المؤقت وقاعدة البيانات).

11 التكوينات و 12. بناء ، إطلاق ، تشغيل

كنت أرغب في تكريس هذا الجزء لنشر Blue-Green ، ولكن تبين أنه كان مفصلاً للغاية بالنسبة لهذه المقالة. سأكتب مقالة منفصلة عن هذا.

باختصار ، يعتمد المفهوم على أنظمة CI / CD مثل جنكينز и جيتلاب سي. في كليهما ، يمكنك تعيين متغيرات البيئة المرتبطة ببيئة معينة. وفقًا لذلك ، في هذا السيناريو ، البند ج التكوينات.

والنقطة حول بناء ، إطلاق ، تشغيل تم حلها بواسطة الوظائف المضمنة في كلتا المرافقين المسماة خط أنابيب.

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

رمز التطبيق قيد التشغيل جيثب.
لا تنس تهيئة الوحدة الفرعية عند استنساخ هذا المستودع.

ملاحظة: يمكن استخدام كل هذه الأساليب مع أي أدوات مساعدة ولغات برمجة أخرى. الشيء الرئيسي هو أن الجوهر لا يختلف.

المصدر: www.habr.com