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