أرغب في مشاركة قصتي حول ترحيل تطبيق إلى Openshift. نتيجةً لذلك ، سأقارن بين أكثر الحلول والأدوات شعبية لإدارة تطبيقك داخل Openshift. هذا هو نسخة من العرض التقديمي في kubernetes SPB meetup # 3 .
دعنا نشر إلى Openshift
ماذا يجب أن نفعل؟
بادئ ذي بدء ، دعونا نتحدث عن طلبنا. إنه حل خارج المؤسسة ، وهو يدعم قواعد بيانات مختلفة وخوادم التطبيقات وواجهات التكامل مع أنظمة الجهات الخارجية. عادةً ما يتم تثبيت عملائنا على خوادم مخصصة ، ومع ذلك ، واجهنا المشكلة. كان علينا ضبط التطبيق داخل Openshift.
المتطلبات الأساسية
التطبيق هو المنتج مع تاريخ طويل ، يجب أن يعمل خارج منطقة الجزاء في بيئات مختلفة تماما. نتيجة لذلك ، هناك الكثير من الصفحات في أدلة التثبيتات الخاصة بنا. ومع ذلك ، فإن مخطط المستوى العلوي سهل مثل الكعكة ، يجب عليك فقط:
- تطبيق مخطط قاعدة البيانات.
- إعداد تكوين خادم التطبيق.
- تثبيت الترخيص الخاص بك.
- تهيئة التطبيق.
لسوء الحظ ، فإن العالم قاسٍ ، كانت هناك بعض الشروط الأساسية المهمة.
- يمكننا إنشاء التطبيق فقط في عبودية جنكينز الخاصة ، بسبب القيود الأمنية
- لم يكن هناك وصول من تثبيت Openshift العميل إلى سجل عامل ميناء المطورين الخاصين.
- لم نتمكن من إعادة استخدام صور عامل الإرساء الحالية ، لأنه تم إنشاؤها لتلبية احتياجات التطوير والاختبار فقط.
- كانت هناك قواعد تشغيل ansible لنشر التطبيق على VMs.
عرض حاوية Ansible
Ansible Container هو مشروع مفتوح المصدر يهدف إلى تمكين أتمتة عملية إنشاء ونشر وإدارة الحاويات بأكملها. والأفضل من ذلك كله ، أنه يستخدم لغة أتمتة Ansible البسيطة والقوية وعديمة الوكيل التي تستخدمها بالفعل ، مما يضمن إمكانية أتمتة دورة حياة التطبيق بأكملها.
لقد كتبنا بالفعل بعض الأدوار Ansible لتثبيت التطبيق على VMs ، لذلك أعدنا استخدامها بحاوية ansible . حاوية Ansible عبارة عن مجموعة أدوات لبناء الحاويات. لست متأكدًا من أنها مجموعة أدوات جيدة حقًا ، إلا أنها تتيح:
- قم بإنشاء حاويات بنفس الطريقة التي ننشر بها خوادمنا.
- التوقف عن السلاسل معا أوامر shell في Dockerfiles.
لم يكن هناك مشكلة كبيرة مع حاوية ansible لأن Openshift إنشاء خطوط إرشادية للصور رائع. ومع ذلك ، أود أن تلاحظ:
- قمنا بتعديل أدوارنا ansible ، لأن
Docker + systemd = pain . - لا توجد إمكانية لاستخدام chroot ، sudo داخل Openshift افتراضيًا ، بسبب الأمان. مجرد قراءة CVE-2019-5736 .
- لأسباب تتعلق بالأمان ، يكون Openshift افتراضيًا ، كما يولِّد UID عشوائيًا لكل حاوية ، وبعبارة أخرى ، يتجاهل openhift خيار USER من Dockerfile.
النقطة الأساسية هي أن حاوية ansible ساعدتنا في إنشاء عرض توضيحي سريع للغاية ، بسبب إعادة الاستخدام.
حاويات متعددة التجريبي
تم بناء الحاوية التجريبية الأولى عبر حاوية غير مرئية. كان جيدا بما فيه الكفاية للعرض ، ومع ذلك ، قررنا عدم استخدامه. نحن تقسيم حاوية متراصة إلى مختلفة:
- استخدمنا حاوية Openshift PostgreSQL الأصلية دون أي تعديلات.
- بنينا تطبيق حاوية عديمي الجنسية.
ومع ذلك ، لم يكن من الواضح تهيئة قاعدة البيانات؟ لقد وجدنا مقالًا رائعًا عن حياة الأشخاص الموجودين داخل الكوبرنيتيس. لذلك ، قررنا استخدام حاوية init لتهيئة قاعدة البيانات.
تهيئة التطبيق
كما ذكرت من قبل ، يجب أن يعمل التطبيق خارج التطبيق في بيئات مختلفة تمامًا ، ويدعم خوادم / قواعد بيانات مختلفة للتطبيقات وواجهات تكامل مع أنظمة الجهات الخارجية.
هناك العديد من الطرق لتهيئة التطبيق:
- تمرير التكوين عبر متغيرات البيئة. هذا يعني إضافة جميع الوثائق / المعرفة الخاصة بنا حول كيفية تهيئة التطبيق لكل حالة استخدام في كل حاوية. هذا لا يبدو جيدا.
- استخدم خطاف البدء ، وهذا هو تقريبا نفس الخط الأول.
- التهيئة أثناء توفير Openshift.
- استخدم حاوية خارجية بتكوين فردي لكل حالة استخدام.
اخترنا آخر واحد ، أنشأنا تحكم النسخ المتماثل إضافية لتهيئة التطبيق؟ حقا؟
نقرأ الوثائق مرة أخرى.
جراب (كما هو الحال في جراب من الحيتان أو جراب البازلاء) هي مجموعة من حاوية واحدة أو أكثر (مثل حاويات Docker) ، مع تخزين / شبكة مشتركة ، ومواصفات لكيفية تشغيل الحاويات.
POD هي مجموعة من الحاويات. نتيجة لذلك ، قررنا تشغيل 3 حاويات في تطبيق POD
- حاوية أولية لتهيئة PostgreSQL.
- حاوية التطبيق.
- حاوية تهيئة التطبيق.
يسمح هذا النهج بتخزين التهيئة الخاصة بنا ككود ، وهناك نتيجتان مهمتان: تكوين التطبيق قابل للاختبار وقابل للتكرار.
يوجد الكثير بالفعل لإدارة openhift.
خلال الهجرة ، لقد اختبرت بعض منهم. أود مشاركة نتائجي.
قوالب فتح
قوالب فتح
الايجابيات:
سلبيات:
- قوالب YAML أخرى.
- تسجيل ملف YAML الرهيب.
- يهمك تبعية الخدمات.
البرامج النصية والقالب
الايجابيات:
سلبيات:
مزود Terraform k8s
الايجابيات:
- لا تهتم بإنشاء النظام.
- إعادة استخدام رمز كوحدات.
- يمكنك إضافة منطق التهيئة.
سلبيات:
- لا يوجد دعم Openshift ، فقط k8s.
- عفا عليها الزمن في بعض الأحيان.
- أداة أخرى
حاوية ansible
حاوية ansible
الايجابيات:
- جعل CM ، لا باش
- إعادة استخدام الأدوار الموجودة. دور = الصورة.
- مجموعة أدوات واحدة لكل شيء.
سلبيات:
- صور ضخمة ، بسبب طبقة واحدة.
- يبدو التخلي عن & قديما.
تم استبدال حاوية Ansible بندر Ansible .
وحدة k8s Ansible
وحدة Ansible + k8s
الايجابيات:
- كتاب اللعب واحد للجميع.
- إعادة استخدام الرمز كأدوار.
- يمكنك إضافة منطق التهيئة.
سلبيات:
- لا يوجد دعم وكيل.
- يهمك إزالة. إذا كنت تريد إزالة شيء ما ، فعليك أن تعلن ذلك.
- يهمك إنشاء النظام. يجب عليك نشر التطبيق قبل التهيئة.
Ansible حزمة قواعد اللعبة التي تمارسها
حزمة Ansible Playbook Bundle (APB) عبارة عن تعريف تطبيق خفيف الوزن (حاوية وصفية). يتم استخدامها لتعريف ونشر مجموعات معقدة من التطبيقات ، وتكوينات النشر ، والنشر ، والخدمات على كتلة OpenShift Origin التي تدير Ansible Service Broker. توفر APBs المزيد من القوة والتكوين البسيط من خلال الاستفادة من قوة Ansible. APBs لديها الميزات التالية:
الفكرة الرئيسية هي أن تقوم بحزم كل شيء في حاوية وتشغيل الحاوية داخل Openshift. Ansible حزمة قواعد اللعبة التي تمارسها
الايجابيات:
- حزم كل شيء.
- قابلة للاختبار وقابلة للتكرار.
- تكامل كتالوج الخدمة.
سلبيات:
- تحتاج أذونات المسؤول.
- الوثائق في بعض الأحيان قديمة.
النتيجة
من جهة ، لا أريد أن أكون السلطة النهائية ، لكن من ناحية أخرى ، أود أن أشارك وجهة نظري. لا يوجد رصاصة الفضة موجودة.
PS