سنبدأ مدونتنا بالمنشورات المستندة إلى أحدث خطابات مديرنا الفني (ديمتري ستولياروف). تم عقدها جميعًا في عام 2016 في أحداث احترافية مختلفة وكانت مخصصة لموضوع DevOps وDocker. مقطع فيديو واحد من اجتماع Docker موسكو في مكتب Badoo، لدينا بالفعل متصل. وستكون المقالات الجديدة مصحوبة بمقالات تنقل جوهر التقارير. لذا…
31 مايو في المؤتمر ، الذي أقيم كجزء من مهرجان "تقنيات الإنترنت الروسية" (RIT++ 2016)، افتتح قسم "النشر والنشر المستمر" بتقرير "أفضل ممارسات التسليم المستمر مع Docker". لقد قام بتلخيص وتنظيم أفضل الممارسات لبناء عملية التسليم المستمر (CD) باستخدام Docker وغيرها من المنتجات مفتوحة المصدر. ونحن نعمل مع هذه الحلول في الإنتاج، مما يسمح لنا بالاعتماد على الخبرة العملية.
إذا كان لديك الفرصة لقضاء ساعة ، ننصح بمشاهدته كاملاً. بخلاف ذلك، فيما يلي الملخص الرئيسي في شكل نص.
التسليم المستمر مع Docker
تحت التسليم المستمر نحن نفهم سلسلة الأحداث، ونتيجة لذلك يأتي كود التطبيق من مستودع Git أولاً إلى الإنتاج، ثم ينتهي به الأمر في الأرشيف. انها تبدو مثل هذا: Git → Build → Test → Release → Opera.
تم تخصيص معظم التقرير لمرحلة الإنشاء (تجميع التطبيق)، وتم التطرق لفترة وجيزة إلى موضوعات الإصدار والتشغيل. سنتحدث عن المشكلات والأنماط التي تسمح لك بحلها، وقد تكون التطبيقات المحددة لهذه الأنماط مختلفة.
لماذا هناك حاجة إلى Docker هنا على الإطلاق؟ ليس من قبيل الصدفة أننا قررنا التحدث عن ممارسات التسليم المستمر في سياق هذه الأداة مفتوحة المصدر. على الرغم من أن التقرير بأكمله مخصص لاستخدامه، إلا أنه يتم الكشف عن العديد من الأسباب عند النظر في النمط الرئيسي لطرح كود التطبيق.
نمط الطرح الرئيسي
لذلك، عندما نطرح إصدارات جديدة من التطبيق، فإننا بالتأكيد نواجه مشكلة مشكلة التوقف، التي تم إنشاؤها أثناء تبديل خادم الإنتاج. لا يمكن تبديل حركة المرور من الإصدار القديم من التطبيق إلى الإصدار الجديد على الفور: يجب علينا أولاً التأكد من أن الإصدار الجديد لم يتم تنزيله بنجاح فحسب، بل أيضًا "جاهز" (أي جاهز تمامًا لخدمة الطلبات).
وبالتالي، لبعض الوقت، سيعمل كلا الإصدارين من التطبيق (القديم والجديد) في وقت واحد. مما يؤدي تلقائيا إلى الصراع على الموارد المشتركة: الشبكة، نظام الملفات، IPC، الخ. باستخدام Docker، يمكن حل هذه المشكلة بسهولة عن طريق تشغيل إصدارات مختلفة من التطبيق في حاويات منفصلة، حيث يتم ضمان عزل الموارد داخل نفس المضيف (الخادم/الجهاز الظاهري). بالطبع، يمكنك القيام ببعض الحيل دون عزل على الإطلاق، ولكن إذا كانت هناك أداة جاهزة ومريحة، فهناك السبب المعاكس - عدم إهمالها.
توفر الحاويات العديد من المزايا الأخرى عند نشرها. أي تطبيق يعتمد على نسخة محددة (أو نطاق الإصدار) مترجمومدى توفر الوحدات/الامتدادات وما إلى ذلك، بالإضافة إلى إصداراتها. وهذا لا ينطبق فقط على البيئة القابلة للتنفيذ المباشرة، ولكن أيضًا على البيئة بأكملها، بما في ذلك برنامج النظام ونسخته (حتى توزيع Linux المستخدم). نظرًا لحقيقة أن الحاويات لا تحتوي على رمز التطبيق فحسب، بل تحتوي أيضًا على نظام وبرامج تطبيقية مثبتة مسبقًا للإصدارات المطلوبة، يمكنك نسيان مشاكل التبعيات.
دعونا نلخص نمط الطرح الرئيسي الإصدارات الجديدة مع مراعاة العوامل التالية:
- في البداية، يتم تشغيل الإصدار القديم من التطبيق في الحاوية الأولى.
- يتم بعد ذلك طرح الإصدار الجديد و"تسخينه" في حاوية ثانية. من الجدير بالذكر أن هذا الإصدار الجديد نفسه قد لا يحمل كود التطبيق المحدث فحسب، بل أيضًا أيًا من تبعياته، بالإضافة إلى مكونات النظام (على سبيل المثال، إصدار جديد من OpenSSL أو التوزيع بأكمله).
- عندما يصبح الإصدار الجديد جاهزًا تمامًا لخدمة الطلبات، تنتقل حركة المرور من الحاوية الأولى إلى الثانية.
- يمكن الآن إيقاف الإصدار القديم.
يوفر هذا الأسلوب المتمثل في نشر إصدارات مختلفة من التطبيق في حاويات منفصلة راحة أخرى - التراجع السريع إلى الإصدار القديم (بعد كل شيء، يكفي تحويل حركة المرور إلى الحاوية المطلوبة).
تبدو التوصية الأولى النهائية وكأنها شيء لم يتمكن حتى الكابتن من العثور على خطأ فيه: "[عند تنظيم التسليم المستمر باستخدام Docker] استخدم عامل الميناء [ويفهمون ما يعطي]" تذكر أن هذه ليست الحل السحري الذي سيحل كل مشكلة، ولكنها أداة توفر أساسًا رائعًا.
قابلية اعادة الأنتاج
نعني بـ "قابلية التكرار" مجموعة عامة من المشكلات التي تتم مواجهتها عند تشغيل التطبيقات. نحن نتحدث عن مثل هذه الحالات:
- يجب إعادة إنتاج النصوص التي تم فحصها من قبل قسم الجودة للتدريج بدقة في الإنتاج.
- يتم نشر التطبيقات على خوادم يمكنها تلقي الحزم من مرايا مستودعات مختلفة (يتم تحديثها بمرور الوقت، ومعها إصدارات التطبيقات المثبتة).
- "كل شيء يناسبني محليًا!" (... ولا يُسمح للمطورين بالدخول في الإنتاج.)
- تحتاج إلى التحقق من شيء ما في الإصدار القديم (المؤرشف).
- ...
يتلخص جوهرها العام في حقيقة أن الامتثال الكامل للبيئات المستخدمة (وكذلك غياب العامل البشري) ضروري. كيف يمكننا ضمان التكاثر؟ إنشاء صور دوكر بناءً على تعليمات برمجية من Git، ثم استخدامها في أي مهمة: في مواقع الاختبار، وفي الإنتاج، وعلى الأجهزة المحلية للمبرمجين... وفي الوقت نفسه، من المهم تقليل الإجراءات التي يتم تنفيذها بعد تجميع الصورة: كلما كانت أبسط، قل احتمال حدوث أخطاء.
البنية التحتية هي رمز
إذا لم يتم إضفاء الطابع الرسمي على متطلبات البنية التحتية (توافر برنامج الخادم، وإصداره، وما إلى ذلك) و"برمجتها"، فإن بدء أي تحديث للتطبيق يمكن أن يؤدي إلى عواقب وخيمة. على سبيل المثال، في التدريج، قمت بالفعل بالتبديل إلى PHP 7.0 وأعدت كتابة الكود وفقًا لذلك - ومن المؤكد أن ظهوره في الإنتاج باستخدام بعض PHP (5.5) القديم سيفاجئ شخصًا ما. ربما لا تنسى تغييرًا كبيرًا في نسخة المترجم، لكن "الشيطان في التفاصيل": قد تكون المفاجأة في تحديث بسيط لأي تبعية.
يُعرف أسلوب حل هذه المشكلة باسم IaC (البنية التحتية كرمز، "البنية التحتية كرمز") ويتضمن تخزين متطلبات البنية التحتية مع رمز التطبيق. باستخدامه، يمكن للمطورين ومتخصصي DevOps العمل مع نفس مستودع تطبيقات Git، ولكن على أجزاء مختلفة منه. من هذا الرمز، يتم إنشاء صورة Docker في Git، حيث يتم نشر التطبيق مع مراعاة جميع تفاصيل البنية التحتية. ببساطة، يجب أن تكون البرامج النصية (القواعد) لتجميع الصور في نفس المستودع مع كود المصدر ودمجها معًا.
في حالة بنية تطبيق متعددة الطبقات - على سبيل المثال، يوجد nginx، الذي يقف أمام تطبيق يعمل بالفعل داخل حاوية Docker - يجب إنشاء صور Docker من التعليمات البرمجية في Git لكل طبقة. بعد ذلك، ستحتوي الصورة الأولى على تطبيق بمترجم وتبعيات "مقربة" أخرى، وستحتوي الصورة الثانية على nginx المنبع.
صور عامل الميناء والتواصل مع Git
نقوم بتقسيم جميع صور Docker التي تم جمعها من Git إلى فئتين: مؤقتة وإصدارية. صور مؤقتة التي تم وضع علامة عليها باسم الفرع في Git، يمكن الكتابة فوقها بواسطة الالتزام التالي ويتم طرحها للمعاينة فقط (وليس للإنتاج). هذا هو الاختلاف الرئيسي بينهما عن الإصدارات: فأنت لا تعرف أبدًا الالتزام المحدد الموجود فيها.
من المنطقي تجميعها في صور مؤقتة: الفرع الرئيسي (يمكنك نشره تلقائيًا إلى موقع منفصل لرؤية الإصدار الحالي من الإصدار الرئيسي باستمرار)، والفروع ذات الإصدارات، وفروع ابتكارات محددة.
بعد أن تصل معاينة الصور المؤقتة إلى الحاجة إلى الترجمة إلى الإنتاج، يضع المطورون علامة معينة. يتم جمعها تلقائيا عن طريق العلامة صورة الافراج (تتوافق علامتها مع العلامة من Git) ويتم طرحها للتدريج. إذا تم التحقق منه بنجاح من قبل قسم الجودة، فإنه يذهب إلى الإنتاج.
DAPP
كل ما تم وصفه (الطرح، تجميع الصور، الصيانة اللاحقة) يمكن تنفيذه بشكل مستقل باستخدام نصوص Bash وغيرها من الأدوات "المرتجلة". ولكن إذا قمت بذلك، فسيؤدي التنفيذ في مرحلة ما إلى تعقيد كبير وضعف التحكم. ومن خلال فهم ذلك، قمنا بإنشاء أداة سير العمل المتخصصة الخاصة بنا لبناء CI/CD - DAPP.
الكود المصدري الخاص به مكتوب بلغة روبي، وهو مفتوح المصدر ومنشور على . لسوء الحظ، يعد التوثيق حاليًا أضعف نقطة في الأداة، ولكننا نعمل على حلها. وسوف نكتب ونتحدث عن الـ dapp أكثر من مرة، لأن... نحن لا نستطيع الانتظار بصدق لمشاركة قدراته مع المجتمع المهتم بأكمله، ولكن في هذه الأثناء، أرسل مشكلاتك واسحب الطلبات و/أو تابع تطور المشروع على GitHub.
تم التحديث في 13 أغسطس 2019: حاليا مشروع DAPP أعيدت تسميته إلى ، تمت إعادة كتابة الكود الخاص به بالكامل في Go، وتم تحسين وثائقه بشكل كبير.
Kubernetes
أداة أخرى مفتوحة المصدر جاهزة والتي حصلت بالفعل على اعتراف كبير في البيئة المهنية هي Kubernetes، مجموعة إدارة Docker. موضوع استخدامه في تشغيل المشاريع المبنية على Docker يقع خارج نطاق التقرير، لذا يقتصر العرض التقديمي على نظرة عامة على بعض الميزات المثيرة للاهتمام.
للطرح، يقدم Kubernetes ما يلي:
- مسبار الاستعداد — التحقق من جاهزية الإصدار الجديد من التطبيق (لتبديل حركة المرور إليه)؛
- التحديث المتداول - تحديث الصورة المتسلسل في مجموعة من الحاويات (إيقاف التشغيل، التحديث، التحضير للإطلاق، تحويل حركة المرور)؛
- التحديث المتزامن - تحديث صورة في مجموعة بطريقة مختلفة: أولاً على نصف الحاويات، ثم على الباقي؛
- إصدارات الكناري - إطلاق صورة جديدة على عدد محدود (صغير) من الحاويات لرصد الحالات الشاذة.
نظرًا لأن التسليم المستمر لا يقتصر على إصدار إصدار جديد فقط، فإن Kubernetes لديه عدد من الإمكانات لصيانة البنية التحتية اللاحقة: المراقبة والتسجيل المضمنين لجميع الحاويات، والقياس التلقائي، وما إلى ذلك. كل هذا يعمل بالفعل وينتظر فقط الإجراء المناسب التنفيذ في العمليات الخاصة بك.
التوصيات النهائية
- استخدم عامل الميناء.
- قم بإنشاء صور Docker للتطبيقات لجميع احتياجاتك.
- اتبع مبدأ "البنية التحتية هي الكود".
- ربط Git بـ Docker.
- تنظيم ترتيب الطرح.
- استخدم منصة جاهزة (Kubernetes أو غيرها).
مقاطع الفيديو والشرائح
فيديو من العرض (حوالي ساعة) (التقرير نفسه يبدأ من الدقيقة الخامسة – اتبع الرابط للتشغيل من هذه اللحظة).
عرض التقرير:
PS
تقارير أخرى حول الموضوع على مدونتنا:
- «» (ديمتري ستولياروف؛ 27 مايو 2019 في DevOpsConf);
- «» (ديمتري ستولياروف ؛ 8 نوفمبر 2018 على HighLoad ++);
- «» (ديمتري ستولياروف ؛ 7 نوفمبر 2017 على HighLoad ++);
- «» (ديمتري ستولياروف ؛ 6 يونيو 2017 في RootConf).
المصدر: www.habr.com