أريد أن أحكي قصة عن كيفية بدء تشغيل التطبيق في Openshift. وفي سياق المسرحية أيضًا ، نفكر في الأدوات المساعدة لإدارة التطبيق داخل Openshift. هذا هو نسخة من الأداء في kubernetes SPB meetup # 3 ..
الغرض
عادة ، يتم نشر العملاء على خوادم منفصلة ، ولكن بعد ذلك ظهرت المهمة ، لاختبار إمكانية تشغيل في openhift وجمع أشعل النار.
تحتاج أولاً إلى التحدث عن طلبنا. مشروع ذو تاريخ غني تستخدم في المنظمات الكبيرة وربما يتقاطع كل واحد منكما بشكل غير مباشر. يدعم التطبيق العديد من قواعد البيانات والتكاملات وما إلى ذلك.
المتطلبات الأساسية
يجب أن يعمل التطبيق في بيئات مختلفة تمامًا. ونتيجة لذلك ، فإن وثائق التثبيت الخاصة بنا واسعة للغاية. ولكن إذا نظرت إليك ، فلا يوجد شيء معقد:
- تطبيق مخطط قاعدة البيانات.
- تكوين خادم التطبيق.
- تثبيت الترخيص.
- تخصيص التطبيق والتكامل مع الأنظمة الخارجية.
لكن العالم قاسي ، كان لدينا عدد من القيود:
- يمكن بناء التطبيق فقط على وجه التحديد من جنكينز ، التي تشارك في التوقيع. وهناك فقط.
- لا يوجد أي وصول من عميل Openshift إلى بيئة التطوير.
- لعدد من الأسباب الإيديولوجية ، لم يكن من الممكن إعادة استخدام صور Docker الحالية للتطوير.
- لدينا قواعد تشغيل ansible لتثبيت وتكوين التطبيق على الخوادم.
عرض حاوية Ansible
حاوية Ansible عبارة عن برنامج مفتوح المصدر يهدف إلى أتمتة تجميع الحاوية ونشرها والتحكم في العملية. كما قد تخمن من الاسم. يستخدم Ansible لبناء الحاويات. لقد قمنا بالفعل بكتابة أدوار Ansible لتثبيت ونشر التطبيقات على الخوادم ، لذلك قررنا عدم إعادة اختراع العجلة وإعادة استخدامها. لن تكون الأداة المثالية فحسب ، ولكن إعادة الاستخدام السريع للأدوار الحالية كانت عاملاً حاسماً في العرض التوضيحي.
بشكل عام ، من أجل القيام بالعرض التوضيحي ، اتخذنا الأدوار الحالية التي تقوم بتكوين كل شيء وكل شيء ، وجعلنا "حاوية متجانسة". لم تكن هناك مشاكل خاصة مع جمع الحاوية يتضمن Openshift بعض التوصيات الرائعة ، لكنني سأذكرها بشكل منفصل:
- الأدوار اللازمة للانتهاء. نستخدم systemd.
- بشكل افتراضي ، لأسباب أمنية ، يُحظر استخدام بعض syscall في openhift. نتيجة لذلك ، سيكون هناك فروق دقيقة مع chroot ، sudo. مرحبًا CVE-2019-5736 .
- وبالمثل ، لأسباب أمنية ، يتم تشغيل الحاوية من تحت مستخدم بمعرف عشوائي ، وهذا أيضًا سلوك مخصص.
الفكرة الرئيسية في هذه المرحلة هي أننا صنعنا عرضًا سريعًا للغاية.
حاويات متعددة التجريبي
نفذت الحاوية التجريبية دورها ورأيناها في مكونات منفصلة:
- طلبنا
- قاعدة البيانات.
- خدمات خارجية ، الخ ...
أول ما واجهتك ، وكيفية تهيئة قاعدة البيانات؟ من الواضح أننا نستخدم عمليات الترحيل ، لكن متى وكيف نطبقها؟ هنا يجدر إعطاء رابط لمقال رائع يصف الجهاز POD: PODs life . بشكل عام ، هناك عدة طرق:
- استخدام الحرف الأول الحاويات
- استخدم أنظمة الأوركسترا التي ستحدد ترتيب نشر الخدمات وترحيل القوائم عند الضرورة.
قررنا اتباع مسار الحاويات الأولي. أي في POD من تطبيقنا ، قبل بدء تطبيقنا ، تبدأ الحاوية التي تتحرك هجرات. ولكن كيف لتكوين التطبيق نفسه والتكامل الخارجي؟
تهيئة التطبيق
كما ذكرت بالفعل ، يمكن أن يعمل تطبيقنا وينبغي أن يعمل في بيئات مختلفة تمامًا ، مع قواعد بيانات وتكاملات مختلفة. مرة أخرى ، والسؤال هو كيفية إعداد كل شيء؟
- استخدم أنظمة الأوركسترا التي تحدد ترتيب نشر الخدمات وتطبيق التكوين بعد بدء تشغيل التطبيق.
- تمر عبر متغيرات البيئة إلى الحاوية كيفية تكوين.
- استخدام بداية هوك.
- قم بإنشاء حاوية منفصلة تحتوي على التكوين وقم بتطبيقه على التطبيق. الهجرة التماثلية تقريبا لقاعدة البيانات.
اخترنا النهج الأخير ، لأنه انها تسمح لك لجعل التكوين استنساخه والاكتفاء الذاتي. ولكن لسبب ما ، قمنا في البداية بإنشاء هذه الحاوية في وحدة تحكم النسخ متماثل منفصلة بعامل 1.
حسنا ، اقرأ الوثائق مرة أخرى.
جراب (كما هو الحال في جراب من الحيتان أو جراب البازلاء) هي مجموعة من حاوية واحدة أو أكثر (مثل حاويات Docker) ، مع تخزين / شبكة مشتركة ، ومواصفات لكيفية تشغيل الحاويات.
POD هي مجموعة من الحاويات. نتيجة لذلك ، لدينا الفرعية تتألف من 3 حاويات
- حاوية أولية لتهيئة PostgreSQL.
- حاوية مع التطبيق.
- الحاوية مع تكوين التطبيق.
مجموعة الأدوات
حصلنا على رسم تخطيطي لكيفية ظهور التطبيق المنشور. الآن حان الوقت لمناقشة الأدوات في الطبيعة ، وهناك الكثير جاهز بالفعل ، وسأنظر في بعض القائمة أدناه واستخلص استنتاجات ذاتية.
قوالب فتح
قوالب فتح
الايجابيات:
- الأم ولديهم وثائق ممتازة.
سلبيات:
- محرك قالب آخر.
- ملفات YAML الطويلة والرهيبة.
- إذا كانت لديك تبعيات بين الخدمات وترتيب بدء تشغيلها ، فسيكون ذلك صعبًا.
البرامج النصية والقالب
الايجابيات:
- يمكنك استخدام أدوات رائعة وكل قوة OOP.
سلبيات:
- العكازات التي تدعم. وليس فقط لك.
مزود Terraform k8s
الايجابيات:
- لا تقلق بشأن أولوية إنشاء عناصر البنية الأساسية.
- يمكنك إعادة استخدام رمز البنية التحتية كوحدات نمطية.
- يمكنك إضافة منطق تهيئة التطبيق.
سلبيات:
- لا يوجد دعم لـ Openshift ، k8s فقط.
- قفص الاتهام في بعض الأحيان وحدات.
- تولا آخر على فريقك.
حاوية ansible
حاوية ansible
الايجابيات:
- جعل CM ، لا باش
- يمكنك إعادة استخدام الرمز كأدوار.
- في حالتنا ، أداة واحدة لكل شيء.
سلبيات:
- صور ضخمة ، لأن الذهاب في طبقة واحدة.
- تبدو مهجورة وغير مدعومة. وقد حلت محلها ansible بندر .
وحدة k8s Ansible
وحدة Ansible + k8s
الايجابيات:
- كتاب لعب واحد لوصف جميع البنى التحتية للمشروع داخل Openshift.
- إعادة استخدام الرمز في شكل أدوار.
- يمكنك إضافة منطق تهيئة التطبيق.
سلبيات:
- لا يوجد دعم وكيل.
- كنت تأخذ الرعاية من الإزالة. إذا لم تعد هناك حاجة للكائن ، فقم بوصف إزالته.
- أنت نفسك تصف تسلسل إنشاء عناصر البنية التحتية.
Ansible حزمة قواعد اللعبة التي تمارسها
تقدم الأداة المساعدة Ansible Playbook Bundle (APB) مقاربة: دعنا نحزم أدوارًا غير مرئية لنشر التطبيق داخل k8s / openhift في حاوية وتشغيل داخل k8s / openhift.
الايجابيات:
- أحمل كل شيء معي.
- قابلة للاختبار وقابلة للتكرار.
- التكامل مع كتالوج الخدمة (واجهة ويب سهلة الاستخدام لتشغيل التطبيقات).
سلبيات:
- تحتاج امتيازات مستوى المسؤول.
- الوثائق في بعض الأحيان يترك الكثير مما هو مرغوب فيه.
النتيجة
لا أريد أن أكون الملاذ الأخير ، لكنني سأشارك في استنتاجاتي:
PS