أقترح قراءة نص تقرير ألكسندر سيغاتشيف من Inventos "عملية التطوير والاختبار باستخدام Docker + Gitlab CI"
غالبًا ما يطرح أولئك الذين بدأوا للتو في تنفيذ عملية التطوير والاختبار استنادًا إلى Docker + Gitlab CI أسئلة أساسية. من أين نبدأ؟ كيف تنظم؟ كيف تختبر؟
هذا التقرير جيد لأنه يتحدث بطريقة منظمة عن عملية التطوير والاختبار باستخدام Docker و Gitlab CI. التقرير نفسه من عام 2017. أعتقد أنه من هذا التقرير يمكنك معرفة الأساسيات والمنهجية والفكرة وخبرة الاستخدام.
من يهتم ، من فضلك تحت القط.
اسمي الكسندر سيغاتشيف. أعمل لدى Inventos. سأخبرك عن تجربتي في استخدام Docker وكيف نقوم بتنفيذها تدريجياً على المشاريع في الشركة.
موضوع العرض التقديمي: عملية التطوير باستخدام Docker و Gitlab CI.
هذا هو حديثي الثاني عن Docker. في وقت التقرير الأول ، استخدمنا Docker في التطوير فقط على أجهزة المطورين. كان عدد الموظفين الذين استخدموا Docker حوالي 2-3 أشخاص. تدريجيًا ، تم اكتساب الخبرة وانتقلنا إلى أبعد من ذلك قليلاً. رابط لموقعنا .
ماذا سيكون في هذا التقرير؟ سوف نشارك تجربتنا حول ما جمعناه ، وما هي المشاكل التي قمنا بحلها. لم يكن جميلًا في كل مكان ، لكن سمح له بالمضي قدمًا.
شعارنا هو: إرساء كل ما يمكننا الحصول عليه.
ما هي المشاكل التي نحلها؟
عندما يكون هناك عدة فرق في الشركة ، يكون المبرمج موردًا مشتركًا. هناك مراحل يتم فيها إخراج المبرمج من مشروع واحد وإعطائه لبعض الوقت لمشروع آخر.
لكي يفهم المبرمج بسرعة ، فإنه يحتاج إلى تنزيل الكود المصدري للمشروع وإطلاق البيئة في أقرب وقت ممكن ، مما سيسمح له بالمضي قدمًا في حل مشكلات هذا المشروع.
عادة ، إذا بدأت من الصفر ، فهناك القليل من الوثائق في المشروع. معلومات حول كيفية الإعداد متاحة فقط للمسنين القدامى. يقوم الموظفون بإعداد مكان عملهم بأنفسهم في يوم أو يومين. لتسريع هذا ، استخدمنا Docker.
السبب التالي هو توحيد الإعدادات في التنمية. من واقع خبرتي ، يأخذ المطورون زمام المبادرة دائمًا. في كل حالة خامسة ، يتم إدخال مجال مخصص ، على سبيل المثال ، vasya.dev. يجلس بجانبه جاره بيتيا ، الذي مجاله هو petya.dev. يقومون بتطوير موقع ويب أو بعض مكونات النظام باستخدام اسم المجال هذا.
عندما ينمو النظام وتبدأ أسماء النطاقات هذه في الدخول في التكوينات ، ينشأ تعارض في بيئة التطوير ويتم إعادة كتابة مسار الموقع.
يحدث الشيء نفسه مع إعدادات قاعدة البيانات. شخص ما لا يهتم بالأمان ويعمل بكلمة مرور جذر فارغة. في مرحلة التثبيت ، طلبت MySQL من شخص ما كلمة مرور وتبين أن كلمة المرور هي 123. غالبًا ما يحدث أن تكوين قاعدة البيانات يتغير باستمرار اعتمادًا على التزام المطور. قام شخص ما بتصحيح ملف التكوين. كانت هناك حيل عندما أجرينا نوعًا من اختبار التكوين في .gitignore وكان على كل مطور تثبيت قاعدة البيانات. هذا جعل من الصعب البدء. من الضروري ، من بين أمور أخرى ، تذكر قاعدة البيانات. يجب تهيئة قاعدة البيانات وإدخال كلمة مرور وتسجيل المستخدم وإنشاء جدول وما إلى ذلك.
مشكلة أخرى هي الإصدارات المختلفة للمكتبات. غالبًا ما يحدث أن يعمل مطور مع مشاريع مختلفة. هناك مشروع ليجاسي بدأ قبل خمس سنوات (من 2017 - ملاحظة محرر). في وقت الإطلاق ، بدأنا بـ MySQL 5.5. هناك أيضًا مشاريع حديثة حيث نحاول تنفيذ إصدارات أكثر حداثة من MySQL ، على سبيل المثال ، 5.7 أو أقدم (في 2017 - ملاحظة محرر)
يعرف أي شخص يعمل مع MySQL أن هذه المكتبات تجلب معها التبعيات. من الصعب إلى حد ما تشغيل قاعدتين معًا. على الأقل ، يواجه العملاء القدامى مشكلة في الاتصال بقاعدة البيانات الجديدة. وهذا بدوره يخلق العديد من المشاكل.
المشكلة التالية هي عندما يعمل المطور على جهاز محلي ، فإنه يستخدم الموارد المحلية والملفات المحلية وذاكرة الوصول العشوائي المحلية. يتم تنفيذ جميع التفاعلات في وقت تطوير حل للمشكلات في إطار حقيقة أنها تعمل على جهاز واحد. مثال على ذلك هو عندما يكون لدينا خوادم خلفية في الإنتاج 3 ، ويقوم المطور بحفظ الملفات في الدليل الجذر ومن هناك يأخذ nginx الملفات للرد على الطلب. عندما يدخل مثل هذا الرمز في الإنتاج ، يتضح أن الملف موجود على أحد الخوادم الثلاثة.
اتجاه الخدمات المصغرة يتطور الآن. عندما نقسم تطبيقاتنا الكبيرة إلى بعض المكونات الصغيرة التي تتفاعل مع بعضها البعض. يتيح لك ذلك تحديد التقنيات لمجموعة محددة من المهام. كما يسمح لك بمشاركة العمل والمسؤوليات بين المطورين.
مطور Frondend ، الذي يتم تطويره على JS ، ليس له أي تأثير تقريبًا على Backend. مطور الواجهة الخلفية ، بدوره ، يطور ، في حالتنا ، Ruby on Rails ولا يتداخل مع Frondend. يتم تنفيذ التفاعل باستخدام API.
على سبيل المكافأة ، بمساعدة Docker ، تمكنا من إعادة تدوير الموارد على Staging. كل مشروع ، بسبب تفاصيله ، يتطلب إعدادات معينة. فعليًا ، كان من الضروري تخصيص خادم افتراضي وتكوينه بشكل منفصل ، أو مشاركة نوع من البيئة المتغيرة والمشاريع التي يمكن ، اعتمادًا على إصدار المكتبات ، التأثير على بعضها البعض.
أدوات. ماذا نستعمل؟
- عامل ميناء نفسه. يصف Dockerfile تبعيات تطبيق واحد.
- Docker-compose عبارة عن حزمة تجمع بعضًا من تطبيقات Docker الخاصة بنا.
- نستخدم GitLab لتخزين كود المصدر.
- نحن نستخدم GitLab-CI لتكامل النظام.
يتكون التقرير من جزأين.
سيتحدث الجزء الأول عن كيفية تشغيل Docker على أجهزة المطورين.
سيتحدث الجزء الثاني عن كيفية التفاعل مع GitLab ، وكيف نجري الاختبارات وكيف ننتقل إلى Staging.
Docker هي تقنية تسمح (باستخدام نهج تعريفي) لوصف المكونات الضرورية. هذا مثال Dockerfile. نعلن هنا أننا ورثنا من صورة Ruby: 2.3.0 Docker الرسمية. يحتوي على Ruby الإصدار 2.3 مثبتًا. نقوم بتثبيت مكتبات البناء المطلوبة و NodeJS. نصف أننا نقوم بإنشاء دليل /app. قم بتعيين دليل التطبيق كدليل العمل. في هذا الدليل نضع الحد الأدنى المطلوب من Gemfile و Gemfile.lock. ثم نبني المشاريع التي تثبت صورة التبعية هذه. نشير إلى أن الحاوية ستكون جاهزة للاستماع على المنفذ الخارجي 3000. الأمر الأخير هو الأمر الذي يبدأ مباشرة تطبيقنا. إذا قمنا بتنفيذ أمر بدء المشروع ، سيحاول التطبيق تشغيل الأمر المحدد وتشغيله.
هذا هو مثال بسيط على ملف إنشاء عامل ميناء. في هذه الحالة ، نظهر أن هناك اتصال بين حاويتين. هذا مباشرة في خدمة قاعدة البيانات وخدمة الويب. تتطلب تطبيقات الويب الخاصة بنا في معظم الحالات نوعًا من قواعد البيانات كخلفية لتخزين البيانات. نظرًا لأننا نستخدم MySQL ، فإن المثال مع MySQL - لكن لا شيء يمنعنا من استخدام بعض قواعد البيانات الأخرى (PostgreSQL و Redis).
نأخذ من المصدر الرسمي من Docker hub صورة MySQL 5.7.14 بدون تغييرات. نقوم بتجميع الصورة المسؤولة عن تطبيق الويب الخاص بنا من الدليل الحالي. إنها تجمع صورة لنا أثناء الإطلاق الأول. ثم يقوم بتشغيل الأمر الذي نقوم بتنفيذه هنا. إذا عدنا إلى الوراء ، فسنرى أنه قد تم تحديد أمر الإطلاق عبر Puma. بوما هي خدمة مكتوبة بلغة روبي. في الحالة الثانية ، نتجاوز. يمكن أن يكون هذا الأمر تعسفيًا حسب احتياجاتنا أو مهامنا.
نصف أيضًا أننا بحاجة إلى إعادة توجيه منفذ على الجهاز المضيف للمطورين لدينا من 3000 إلى 3000 على ميناء الحاوية. يتم ذلك تلقائيًا باستخدام iptables وآليته المضمنة مباشرةً في Docker.
يمكن للمطور أيضًا ، كما كان من قبل ، الوصول إلى أي عنوان IP متاح ، على سبيل المثال ، 127.0.0.1 هو عنوان IP المحلي أو الخارجي للجهاز.
يشير السطر الأخير إلى أن حاوية الويب تعتمد على حاوية db. عندما نطلق على بداية حاوية الويب ، فإن docker-compose سيبدأ قاعدة البيانات لنا أولاً. بالفعل في بداية قاعدة البيانات (في الواقع ، بعد إطلاق الحاوية! هذا لا يضمن جاهزية قاعدة البيانات) سيطلق التطبيق ، الواجهة الخلفية لدينا.
هذا يتجنب الأخطاء عندما لا يتم إحضار قاعدة البيانات ويحفظ الموارد عندما نقوم بإيقاف حاوية قاعدة البيانات ، وبالتالي تحرير الموارد لمشاريع أخرى.
ما يعطينا استخدام قاعدة البيانات dockerization في المشروع. نقوم بإصلاح إصدار MySQL لجميع المطورين. هذا يتجنب بعض الأخطاء التي قد تحدث عندما تتباعد الإصدارات ، عندما يتغير بناء الجملة والتكوين والإعدادات الافتراضية. هذا يسمح لك بتحديد اسم مضيف مشترك لقاعدة البيانات وتسجيل الدخول وكلمة المرور. نحن نبتعد عن حديقة الأسماء والتعارضات في ملفات التكوين التي كانت لدينا سابقًا.
لدينا الفرصة لاستخدام تهيئة أكثر أمثل لبيئة التطوير ، والتي ستختلف عن الإعداد الافتراضي. تم تكوين MySQL للأجهزة الضعيفة افتراضيًا وأداؤها خارج الصندوق ضعيف جدًا.
يتيح لك Docker استخدام مترجم Python و Ruby و NodeJS و PHP للإصدار المطلوب. نتخلص من الحاجة إلى استخدام نوع من مدير الإصدارات. في السابق ، استخدم Ruby حزمة rpm التي تسمح لك بتغيير الإصدار اعتمادًا على المشروع. كما يسمح ، بفضل حاوية Docker ، بترحيل الكود بسلاسة وإصداره مع التبعيات. ليس لدينا مشكلة في فهم إصدار كل من المترجم الشفهي والكود. لتحديث الإصدار ، قم بخفض الحاوية القديمة ورفع الحاوية الجديدة. إذا حدث خطأ ما ، يمكننا خفض الحاوية الجديدة ورفع الحاوية القديمة.
بعد بناء الصورة ، ستكون الحاويات في كل من التطوير والإنتاج هي نفسها. هذا ينطبق بشكل خاص على التركيبات الكبيرة.
في الواجهة الأمامية ، نستخدم JavaScipt و NodeJS.
الآن لدينا آخر مشروع على ReacJS. قام المطور بتشغيل كل شيء في الحاوية وتم تطويره باستخدام إعادة التحميل السريع.
بعد ذلك ، يتم تشغيل مهمة تجميع JavaScipt ويتم تقديم الكود المترجم إلى statics من خلال موارد توفير nginx.
لقد قدمت هنا مخطط مشروعنا الأخير.
ما المهام التي تم حلها؟ كنا بحاجة إلى بناء نظام تتفاعل معه الأجهزة المحمولة. يتلقون البيانات. أحد الاحتمالات هو إرسال إشعارات إلى هذا الجهاز.
ماذا فعلنا من أجل هذا؟
قمنا بتقسيم التطبيق إلى مكونات مثل: الجزء المسؤول في JS ، الواجهة الخلفية ، والتي تعمل من خلال واجهة REST تحت Ruby on Rails. تتفاعل الواجهة الخلفية مع قاعدة البيانات. يتم إعطاء النتيجة التي تم إنشاؤها للعميل. تتفاعل لوحة الإدارة مع الواجهة الخلفية وقاعدة البيانات عبر واجهة REST.
كان علينا أيضًا إرسال إشعارات فورية. قبل ذلك ، كان لدينا مشروع يطبق آلية مسؤولة عن تسليم الإشعارات لمنصات الهاتف المحمول.
لقد قمنا بتطوير المخطط التالي: يتفاعل عامل من المتصفح مع لوحة الإدارة ، وتتفاعل لوحة الإدارة مع الواجهة الخلفية ، والمهمة هي إرسال إشعارات الدفع.
تتفاعل الإشعارات الفورية مع مكون آخر يتم تنفيذه في NodeJS.
يتم إنشاء قوائم الانتظار ثم يتم إرسال الإخطارات وفقًا لآليتها.
يتم رسم قاعدتي بيانات هنا. في الوقت الحالي ، بمساعدة Docker ، نستخدم قاعدتي بيانات مستقلتين لا ترتبط ببعضهما بأي شكل من الأشكال. بالإضافة إلى ذلك ، لديهم شبكة افتراضية مشتركة ، ويتم تخزين البيانات المادية في أدلة مختلفة على جهاز المطور.
نفس الشيء لكن بالأرقام. هذا هو المكان الذي تكون فيه إعادة استخدام الكود أمرًا مهمًا.
إذا تحدثنا سابقًا عن إعادة استخدام الكود في شكل مكتبات ، ففي هذا المثال ، تتم إعادة استخدام خدمتنا التي تستجيب للإشعارات الفورية كخادم كامل. يوفر API. وتطورنا الجديد يتفاعل معه بالفعل.
في ذلك الوقت ، كنا نستخدم الإصدار 4 من NodeJS. الآن (في 2017 - ملاحظة محرر) في التطورات الأخيرة ، نستخدم الإصدار 7 من NodeJS. لا توجد مشكلة في المكونات الجديدة لإشراك إصدارات جديدة من المكتبات.
إذا لزم الأمر ، يمكنك إعادة بناء نسخة NodeJS ورفعها من خدمة إعلام Push.
وإذا تمكنا من الحفاظ على توافق API ، فسيكون من الممكن استبداله بمشاريع أخرى تم استخدامها سابقًا.
ماذا تحتاج لإضافة Docker؟ نضيف Dockerfile إلى مستودعنا ، والذي يصف التبعيات الضرورية. في هذا المثال ، يتم تقسيم المكونات منطقيًا. هذا هو الحد الأدنى من مجموعة مطور الخلفية.
عند إنشاء مشروع جديد ، نقوم بإنشاء Dockerfile ، ووصف النظام البيئي المطلوب (Python ، Ruby ، NodeJS). في docker-compose ، يصف التبعية الضرورية - قاعدة البيانات. نصف أننا بحاجة إلى قاعدة بيانات لإصدار كذا وكذا ، وتخزين البيانات هناك وهناك.
نستخدم حاوية ثالثة منفصلة مع nginx لخدمة static. من الممكن تحميل الصور. تضعهم الواجهة الخلفية في مجلد مُعد مسبقًا ، والذي يتم تثبيته أيضًا في حاوية مع nginx ، مما يعطي الثابت.
لتخزين تكوين nginx و mysql ، أضفنا مجلد Docker حيث نقوم بتخزين التكوينات الضرورية. عندما يقوم المطور باستنساخ git لمستودع على جهازه ، يكون لديه بالفعل مشروع جاهز للتطوير المحلي. ليس هناك شك في ما هو المنفذ أو ما هي الإعدادات لتطبيقها.
بعد ذلك ، لدينا عدة مكونات: admin ، inform-API ، دفع الإخطارات.
من أجل بدء كل هذا ، أنشأنا مستودعًا آخر ، أطلقنا عليه اسم التطبيق dockerized. في الوقت الحالي ، نستخدم عدة مستودعات قبل كل مكون. إنهم مختلفون منطقيًا - في GitLab يبدو كمجلد ، لكن على جهاز المطور ، مجلد لمشروع معين. مستوى واحد لأسفل هي المكونات التي سيتم دمجها.
هذا مثال على محتويات التطبيق المرسي فقط. نأتي أيضًا بدليل Docker هنا ، حيث نقوم بملء التكوينات المطلوبة لتفاعلات جميع المكونات. يوجد README.md يصف بإيجاز كيفية تشغيل المشروع.
هنا قمنا بتطبيق ملفين لإنشاء عامل ميناء. يتم ذلك من أجل التمكن من الجري بخطوات. عندما يعمل مطور مع النواة ، فإنه لا يحتاج إلى دفع الإخطارات ، فهو ببساطة يقوم بتشغيل ملف إنشاء عامل ميناء ، وبالتالي ، يتم حفظ المورد.
إذا كانت هناك حاجة للتكامل مع دفع الإخطارات ، فسيتم تشغيل docker-compose.yaml و docker-compose-push.yaml.
نظرًا لوجود docker-compose.yaml و docker-compose-push.yaml في مجلد ، يتم إنشاء شبكة افتراضية واحدة تلقائيًا.
وصف المكونات. هذا ملف أكثر تقدمًا وهو مسؤول عن مجموعة المكونات. ما المميز هنا؟ نقدم هنا مكون الموازن.
هذه صورة Docker جاهزة يتم تشغيلها nginx وتطبيق يستمع على مقبس Docker. ديناميكي ، حيث يتم تشغيل وإيقاف الحاويات ، فإنه يعيد إنشاء تكوين nginx. نقوم بتوزيع معالجة المكونات بواسطة أسماء نطاقات من المستوى الثالث.
بالنسبة لبيئة التطوير ، نستخدم المجال .dev - api.informer.dev. تتوفر التطبيقات ذات المجال .dev على الجهاز المحلي للمطور.
علاوة على ذلك ، يتم نقل التكوينات إلى كل مشروع ويتم إطلاق جميع المشاريع معًا في نفس الوقت.
بيانياً ، اتضح أن العميل هو متصفحنا أو بعض الأدوات التي نطلب بواسطتها الموازن.
يحدد موازن اسم المجال الحاوية التي يجب الاتصال بها.
يمكن أن يكون nginx ، وهو ما يعطي المشرف JS. يمكن أن يكون هذا هو nginx ، الذي يعطي واجهة برمجة التطبيقات ، أو ملفات ثابتة ، تُعطى لـ nginx في شكل تحميلات للصور.
يوضح الرسم التخطيطي أن الحاويات متصلة بشبكة افتراضية ومخفية خلف وكيل.
على جهاز المطور ، يمكنك الوصول إلى الحاوية مع معرفة عنوان IP ، لكننا لا نستخدم هذا من حيث المبدأ. عمليا ليست هناك حاجة للوصول المباشر.
ما هو المثال الذي يجب النظر إليه لإضفاء طابع الإرساء على تطبيقك؟ في رأيي ، خير مثال على ذلك هو صورة عامل ميناء MySQL الرسمي.
إنه أمر صعب للغاية. هناك العديد من الإصدارات. لكن وظائفه تسمح لك بتغطية العديد من الاحتياجات التي قد تنشأ في عملية التطوير الإضافي. إذا قضيت الوقت واكتشفت كيف يتفاعل كل شيء ، فأعتقد أنك لن تواجه مشاكل في التنفيذ الذاتي.
يحتوي Hub.docker.com عادةً على روابط إلى github.com ، والتي تحتوي على بيانات أولية مباشرةً يمكنك من خلالها إنشاء الصورة بنفسك.
علاوة على ذلك ، يوجد في هذا المستودع برنامج نصي docker-endpoint.sh ، وهو المسؤول عن التهيئة الأولية والمعالجة الإضافية لبدء تشغيل التطبيق.
في هذا المثال أيضًا ، هناك القدرة على التكوين باستخدام متغيرات البيئة. من خلال تحديد متغير البيئة عند تشغيل حاوية واحدة أو من خلال docker-compose ، يمكننا أن نقول إننا بحاجة إلى تعيين كلمة مرور فارغة لـ docker للتجذر على MySQL أو أي شيء نريده.
هناك خيار لإنشاء كلمة مرور عشوائية. نقول إننا بحاجة إلى مستخدم ، نحتاج إلى تعيين كلمة مرور للمستخدم ، ونحتاج إلى إنشاء قاعدة بيانات.
في مشاريعنا ، وحدنا ملف Dockerfile قليلاً ، وهو المسؤول عن التهيئة. هناك قمنا بتصحيحه وفقًا لاحتياجاتنا لجعله مجرد امتداد لحقوق المستخدم التي يستخدمها التطبيق. سمح لنا هذا ببساطة بإنشاء قاعدة بيانات من وحدة تحكم التطبيق لاحقًا. تحتوي تطبيقات Ruby على أمر لإنشاء قواعد البيانات وتعديلها وحذفها.
هذا مثال لما يبدو عليه إصدار معين من MySQL على github.com. يمكنك فتح Dockerfile ومعرفة كيف يجري التثبيت هناك.
docker-endpoint.sh هو البرنامج النصي المسؤول عن نقطة الإدخال. أثناء التهيئة الأولية ، هناك حاجة إلى بعض خطوات الإعداد ، ويتم تنفيذ كل هذه الإجراءات فقط في نص التهيئة.
دعنا ننتقل إلى الجزء الثاني.
لتخزين أكواد المصدر ، قمنا بالتبديل إلى gitlab. هذا نظام قوي إلى حد ما وله واجهة مرئية.
أحد مكونات Gitlab هو Gitlab CI. يتيح لك وصف سلسلة من الأوامر التي سيتم استخدامها لاحقًا لتنظيم نظام تسليم التعليمات البرمجية أو تشغيل الاختبار التلقائي.
Gitlab CI 2 الحديث - تقرير من نادي Ruby Russia - مفصل تمامًا وربما يثير اهتمامك.
الآن سننظر في ما هو مطلوب لتفعيل Gitlab CI. لبدء Gitlab CI ، نحتاج فقط إلى وضع ملف .gitlab-ci.yml في جذر المشروع.
هنا نصف أننا نريد تنفيذ سلسلة من الحالات مثل الاختبار والنشر.
نقوم بتنفيذ البرامج النصية التي تستدعي مباشرة docker-compose لبناء تطبيقنا. هذا مجرد مثال للخلفية.
بعد ذلك ، نقول إنه من الضروري تشغيل عمليات الترحيل لتغيير قاعدة البيانات وتشغيل الاختبارات.
إذا تم تنفيذ البرامج النصية بشكل صحيح ولم تُرجع رمز خطأ ، فحينئذٍ ينتقل النظام إلى المرحلة الثانية من النشر.
يتم تنفيذ مرحلة النشر حاليًا للتشغيل. لم ننظم إعادة تشغيل بدون توقف.
نقوم بإطفاء جميع الحاويات قسرًا ، ثم نرفع جميع الحاويات مرة أخرى ، ونجمعها في المرحلة الأولى أثناء الاختبار.
نحن نقوم بتشغيل عمليات ترحيل قاعدة البيانات التي كتبها المطورون لمتغير البيئة الحالي.
هناك ملاحظة أن هذا ينطبق فقط على الفرع الرئيسي.
عند تغيير الفروع الأخرى لا يتم تنفيذها.
من الممكن تنظيم عمليات الطرح حسب الفروع.
لتنظيم هذا الأمر بشكل أكبر ، نحتاج إلى تثبيت Gitlab Runner.
هذه الأداة مكتوبة في Golang. إنه ملف واحد ، كما هو شائع في عالم Golang ، والذي لا يتطلب أي تبعيات.
عند بدء التشغيل ، نسجل Gitlab Runner.
نحصل على المفتاح في واجهة ويب Gitlab.
ثم نسمي أمر التهيئة في سطر الأوامر.
قم بإعداد Gitlab Runner بشكل تفاعلي (Shell ، Docker ، VirtualBox ، SSH)
سيتم تنفيذ الكود الموجود على Gitlab Runner في كل التزام ، اعتمادًا على إعداد .gitlab-ci.yml.
كيف يبدو مرئيًا في Gitlab في واجهة الويب. بعد أن قمنا بتوصيل GItlab CI ، لدينا علم يوضح حالة البناء في الوقت الحالي.
نرى أن الالتزام قد تم قبل 4 دقائق ، والذي اجتاز جميع الاختبارات ولم يسبب أي مشاكل.
يمكننا إلقاء نظرة فاحصة على البنيات. هنا نرى أن الدولتين قد مرت بالفعل. حالة الاختبار وحالة النشر على التدريج.
إذا نقرنا على بنية معينة ، فسيكون هناك ناتج وحدة تحكم للأوامر التي تم تشغيلها في العملية وفقًا لـ .gitlab-ci.yml.
هذا ما يبدو عليه تاريخ منتجاتنا. نرى أنه كانت هناك محاولات ناجحة. عند إرسال الاختبارات ، لا تنتقل إلى الخطوة التالية ولا يتم تحديث رمز التدريج.
ما المهام التي تم حلها عند التدريج عندما طبقنا عامل الإرساء؟ يتكون نظامنا من مكونات وكان علينا إعادة التشغيل ، فقط جزء من المكونات التي تم تحديثها في المستودع ، وليس النظام بأكمله.
للقيام بذلك ، كان علينا تحطيم كل شيء في مجلدات منفصلة.
بعد أن فعلنا ذلك ، واجهتنا مشكلة في حقيقة أن Docker-compose ينشئ مساحة شبكية خاصة به لكل أب ولا يرى مكونات الجيران.
من أجل الالتفاف ، أنشأنا الشبكة في Docker يدويًا. لقد كتب في Docker-compose أنك تستخدم مثل هذه الشبكة لهذا المشروع.
وبالتالي ، فإن كل مكون يبدأ بهذه الشبكة يرى مكونات في أجزاء أخرى من النظام.
المشكلة التالية هي تقسيم التدريج عبر مشاريع متعددة.
نظرًا لأن كل هذا يبدو جميلًا وقريبًا قدر الإمكان من الإنتاج ، فمن الجيد استخدام المنفذ 80 أو 443 ، والذي يتم استخدامه في كل مكان في WEB.
كيف حللناها؟ لقد خصصنا برنامج Gitlab Runner لجميع المشاريع الكبرى.
يتيح لك Gitlab تشغيل العديد من Gitlab Runners الموزعة ، والتي ستتولى ببساطة جميع المهام بدورها بطريقة فوضوية وتشغيلها.
حتى لا يكون لدينا منزل ، قمنا بتحديد مجموعة مشاريعنا في Gitlab Runner واحد ، والذي يتكيف دون مشاكل مع أحجامنا.
نقلنا nginx-proxy إلى برنامج نصي منفصل لبدء التشغيل وأضفنا شبكات لجميع المشاريع فيه.
يحتوي مشروعنا على شبكة واحدة ، وللموازن عدة شبكات حسب أسماء المشروع. يمكنه التوكيل عن طريق أسماء المجال.
تأتي طلباتنا عبر المجال الموجود على المنفذ 80 ويتم حلها في مجموعة حاويات تخدم هذا المجال.
ما هي المشاكل الأخرى التي كانت موجودة؟ هذا هو ما تعمل جميع الحاويات كجذر افتراضيًا. هذا هو جذر غير مساوٍ لمضيف جذر النظام.
ومع ذلك ، إذا أدخلت الحاوية ، فسيكون جذرًا وسيحصل الملف الذي أنشأناه في هذه الحاوية على حقوق الجذر.
إذا دخل المطور الحاوية وقام ببعض الأوامر هناك لإنشاء الملفات ، ثم غادر الحاوية ، فسيكون لديه ملف في دليل العمل الخاص به لا يمكنه الوصول إليه.
كيف يمكن ان تحل؟ يمكنك إضافة المستخدمين الذين سيكونون في الحاوية.
ما هي المشاكل التي نشأت عندما أضفنا المستخدم؟
عند إنشاء مستخدم ، غالبًا ما لا نمتلك نفس معرف المجموعة (UID) ومعرف المستخدم (GID).
لحل هذه المشكلة في الحاوية ، نستخدم المستخدمين بمعرف 1000.
في حالتنا ، تزامن هذا مع حقيقة أن جميع المطورين تقريبًا يستخدمون نظام التشغيل Ubuntu OS. وعلى Ubuntu ، يمتلك المستخدم الأول معرفًا بقيمة 1000.
هل لدينا خطط؟
اقرأ وثائق Docker. المشروع يتطور بنشاط ، والوثائق تتغير. أصبحت البيانات التي تم تلقيها منذ شهرين أو ثلاثة أشهر قديمة بالفعل.
من المحتمل جدًا أن تكون بعض المشكلات التي حللناها قد تم حلها بالفعل بالوسائل القياسية.
لذلك أريد أن أذهب إلى أبعد من ذلك بالفعل للذهاب مباشرة إلى التنسيق.
أحد الأمثلة على ذلك هو آلية Docker المدمجة التي تسمى Docker Swarm ، والتي تخرج من الصندوق. أريد تشغيل شيء ما في الإنتاج يعتمد على تقنية Docker Swarm.
تجعل حاويات التفريخ من غير الملائم العمل مع جذوع الأشجار. الآن يتم عزل السجلات. هم منتشرون عبر الحاويات. تتمثل إحدى المهام في تسهيل الوصول إلى السجلات من خلال واجهة الويب.
المصدر: www.habr.com