هذه هي المقالة الأولى في سلسلة من المنشورات حول التغييرات والتحسينات والإضافات في تحديث منصة Red Hat OpenShift 4.0 القادمة والتي ستساعدك على الاستعداد للانتقال إلى الإصدار الجديد.
منذ اللحظة التي اجتمع فيها مجتمع Kubernetes الناشئ لأول مرة في مكتب Google في سياتل في خريف عام 2014، كان من المقرر أن يُحدث مشروع Kubernetes ثورة في طريقة تطوير البرامج ونشرها اليوم. وفي الوقت نفسه، واصل مقدمو الخدمات السحابية العامة الاستثمار بنشاط في تطوير البنية التحتية والخدمات، مما جعل العمل مع تكنولوجيا المعلومات وإنشاء البرامج أسهل بكثير وأكثر سهولة في الوصول إليها، وجعلها ميسورة التكلفة بشكل لا يصدق، وهو أمر لم يكن من الممكن أن يتخيله سوى القليل في بداية العقد.
وبطبيعة الحال، كان الإعلان عن كل خدمة سحابية جديدة مصحوبًا بالعديد من المناقشات بين الخبراء على تويتر، وتم إجراء المناقشات حول مجموعة متنوعة من المواضيع - بما في ذلك نهاية عصر المصادر المفتوحة، وتراجع تكنولوجيا المعلومات المحلية، وحتمية احتكار البرمجيات الجديد في السحابة، وكيف سيحل النموذج X الجديد محل جميع النماذج الأخرى.
وغني عن القول أن كل هذه الخلافات كانت غبية للغاية
الحقيقة هي أنه لن يختفي أي شيء، واليوم يمكننا أن نرى نموًا هائلاً في المنتجات النهائية وطريقة تطويرها، وذلك بسبب الظهور المستمر لبرامج جديدة في حياتنا. وعلى الرغم من أن كل شيء حوله سيتغير، في نفس الوقت، في جوهره، سيبقى كل شيء دون تغيير. سيستمر مطورو البرامج في كتابة التعليمات البرمجية التي تحتوي على أخطاء، وسيظل مهندسو العمليات والمتخصصون في الموثوقية يتجولون باستخدام أجهزة الاستدعاء ويتلقون تنبيهات تلقائية في Slack، وسيظل المديرون يعملون فيما يتعلق بـ OpEx وCapEx، وفي كل مرة يحدث فشل، سيتولى المطور الأكبر سنًا تنهد بحزن قائلا: "لقد قلت لك ذلك"...
أوه حقًا ينبغي مناقشتها، هي الأدوات التي يمكن أن تكون تحت تصرفنا لإنشاء منتجات برمجية أفضل، وكيف يمكنها تحسين الأمان وجعل التطوير أسهل وأكثر موثوقية. ومع ازدياد تعقيد المشاريع، تنشأ مخاطر جديدة، وأصبحت حياة الناس اليوم تعتمد إلى حد كبير على البرمجيات بحيث يتعين على المطورين ببساطة أن يحاولوا القيام بعملهم على نحو أفضل.
Kubernetes هي إحدى هذه الأدوات. يجري العمل حاليًا على دمج Red Hat OpenShift مع الأدوات والخدمات الأخرى في منصة واحدة من شأنها أن تجعل البرنامج أكثر موثوقية وأسهل في الإدارة وأكثر أمانًا للمستخدمين.
مع ذلك، يطرح فريق OpenShift سؤالاً واحدًا بسيطًا:
كيف يمكنك جعل العمل مع Kubernetes أسهل وأكثر ملاءمة؟
الجواب واضح بشكل مدهش:
- أتمتة الجوانب المعقدة للنشر على السحابة أو خارج السحابة؛
- التركيز على الموثوقية مع إخفاء التعقيد؛
- مواصلة العمل المستمر لإصدار تحديثات بسيطة وآمنة؛
- تحقيق القدرة على التحكم وقابلية التدقيق؛
- نسعى جاهدين لضمان مستوى عالٍ من الأمان في البداية، ولكن ليس على حساب سهولة الاستخدام.
يجب أن يأخذ الإصدار التالي من OpenShift في الاعتبار كلاً من تجربة المبدعين وتجربة المطورين الآخرين الذين يقومون بتنفيذ البرامج على نطاق واسع في أكبر الشركات في العالم. بالإضافة إلى ذلك، يجب أن تأخذ في الاعتبار كل الخبرات المتراكمة للأنظمة البيئية المفتوحة التي يقوم عليها العالم الحديث اليوم. وفي الوقت نفسه، من الضروري التخلي عن العقلية القديمة للمطور الهاوي والانتقال إلى فلسفة جديدة للمستقبل الآلي. إنها تحتاج إلى سد الفجوة بين الطرق القديمة والجديدة لنشر البرامج، والاستفادة الكاملة من جميع البنية التحتية المتاحة - سواء كانت مستضافة من قبل أكبر مزود سحابي أو تعمل على أنظمة صغيرة على الحافة.
كيفية تحقيق هذه النتيجة؟
من المعتاد في شركة ريد هات القيام بأعمال مملة وناكرة للجميل لفترة طويلة من أجل الحفاظ على المجتمع القائم ومنع إغلاق المشاريع التي تشارك فيها الشركة. يحتوي مجتمع المصادر المفتوحة على عدد كبير من المطورين الموهوبين الذين يبتكرون أشياء غير عادية - مسلية وتعليمية وتفتح فرصًا جديدة وجميلة بكل بساطة، ولكن بالطبع لا يتوقع أحد أن يتحرك جميع المشاركين في نفس الاتجاه أو يتابعوا الأمور المشتركة الأهداف. إن تسخير هذه الطاقة وإعادة توجيهها في الاتجاه الصحيح يكون ضروريًا في بعض الأحيان لتطوير المجالات التي من شأنها أن تفيد مستخدمينا، ولكن في الوقت نفسه يجب علينا مراقبة تطور مجتمعاتنا والتعلم منها.
في بداية عام 2018، استحوذت Red Hat على مشروع CoreOS، الذي كان له وجهات نظر مماثلة حول المستقبل - أكثر أمانًا وموثوقية، وتم إنشاؤه وفقًا لمبادئ مفتوحة المصدر. وقد عملت الشركة على تطوير هذه الأفكار وتنفيذها، ووضع فلسفتنا موضع التنفيذ - وهي محاولة ضمان تشغيل جميع البرامج بأمان. تم بناء كل هذا العمل على Kubernetes، وLinux، والسحابات العامة، والسحابات الخاصة، وآلاف المشاريع الأخرى التي تدعم نظامنا البيئي الرقمي الحديث.
سيكون الإصدار الجديد من OpenShift 4 واضحًا وآليًا وأكثر طبيعية
ستعمل منصة OpenShift مع أفضل أنظمة تشغيل Linux وأكثرها موثوقية، مع دعم الأجهزة المعدنية، والمحاكاة الافتراضية المريحة، وبرمجة البنية التحتية التلقائية، وبالطبع الحاويات (التي هي في الأساس مجرد صور Linux).
يجب أن يكون النظام الأساسي آمنًا منذ البداية، مع السماح للمطورين بالتكرار بسهولة، أي أن يكون مرنًا وآمنًا بدرجة كافية مع السماح للمسؤولين بمراجعته وإدارته بسهولة.
وينبغي أن يسمح بتشغيل البرامج "كخدمة" وألا يؤدي إلى نمو البنية التحتية التي لا يمكن التحكم فيها بالنسبة للمشغلين.
سيسمح للمطورين بالتركيز على إنشاء منتجات حقيقية للمستخدمين والعملاء. لن تضطر إلى الخوض في غابة إعدادات الأجهزة والبرامج، وستكون جميع المضاعفات العرضية شيئًا من الماضي.
OpenShift 4: منصة NoOps التي لا تحتاج إلى صيانة
В وصف تلك المهام التي ساعدت في تشكيل رؤية الشركة لـ OpenShift 4. هدف الفريق هو تبسيط المهام اليومية لتشغيل البرامج وصيانتها قدر الإمكان، لجعل هذه العمليات سهلة ومريحة - لكل من المتخصصين المشاركين في التنفيذ والمطورين. ولكن كيف يمكنك الاقتراب من هذا الهدف؟ كيفية إنشاء منصة لتشغيل البرامج التي تتطلب الحد الأدنى من التدخل؟ ماذا يعني NoOps حتى في هذا السياق؟
إذا حاولت التجريد، فإن مفاهيم "بدون خادم" أو "NoOps" بالنسبة للمطورين تعني الأدوات والخدمات التي تسمح لك بإخفاء المكون "التشغيلي" أو تقليل هذا العبء على المطور.
- لا تعمل مع الأنظمة، بل مع واجهات التطبيقات (APIs).
- لا تهتم بتنفيذ البرنامج - دع المزود يقوم بذلك نيابةً عنك.
- لا يجب أن تقفز إلى إنشاء إطار عمل كبير على الفور - ابدأ بكتابة أجزاء صغيرة ستكون بمثابة "وحدات بناء"، وحاول جعل هذا الرمز يعمل مع البيانات والأحداث، وليس مع الأقراص وقواعد البيانات.
الهدف، كما كان من قبل، هو تسريع التكرارات في تطوير البرمجيات، وإتاحة الفرصة لإنشاء منتجات أفضل، وحتى لا يضطر المطور إلى القلق بشأن الأنظمة التي يعمل عليها برنامجه. يدرك المطور ذو الخبرة جيدًا أن التركيز على المستخدمين يمكن أن يغير الصورة بسرعة، لذا لا ينبغي عليك بذل الكثير من الجهد في كتابة البرامج إلا إذا كنت متأكدًا تمامًا من الحاجة إليها.
بالنسبة لمحترفي الصيانة والعمليات، قد تبدو كلمة "NoOps" مخيفة بعض الشيء. ولكن عند التواصل مع المهندسين الميدانيين، يصبح من الواضح أن الأنماط والتقنيات التي يستخدمونها بهدف ضمان الموثوقية والموثوقية (Site Reliability Engineering, SRE) لها العديد من أوجه التشابه مع الأنماط الموضحة أعلاه:
- لا تدير الأنظمة - قم بأتمتة عمليات إدارتها.
- لا تقم بتنفيذ البرنامج - قم بإنشاء مسار لنشره.
- تجنب تجميع جميع خدماتك معًا والسماح لفشل إحداها بالتسبب في فشل النظام بأكمله - قم بتوزيعها عبر البنية التحتية بالكامل باستخدام أدوات التشغيل الآلي، وتوصيلها بطرق يمكن مراقبتها ومراقبتها.
تعرف SREs أن شيئًا ما يمكن أن يحدث بشكل خاطئ وسيتعين عليهم تعقب المشكلة وإصلاحها — لذلك يقومون بأتمتة العمل الروتيني وتعيين ميزانيات الأخطاء مسبقًا حتى يكونوا مستعدين لتحديد الأولويات واتخاذ القرارات عند ظهور مشكلة.
Kubernetes في OpenShift عبارة عن منصة مصممة لحل مشكلتين رئيسيتين: بدلاً من إجبارك على فهم الأجهزة الافتراضية أو تحميل واجهات برمجة تطبيقات موازن التحميل، فإنها تعمل مع تجريدات ذات ترتيب أعلى - عمليات النشر والخدمات. بدلاً من تثبيت وكلاء البرامج، يمكنك تشغيل الحاويات، وبدلاً من كتابة حزمة المراقبة الخاصة بك، استخدم الأدوات المتوفرة بالفعل في النظام الأساسي. لذا، فإن الخلطة السرية لـ OpenShift 4 ليست سرًا حقًا - إنها مجرد مسألة أخذ مبادئ SRE والمفاهيم غير الخادمة ونقلها إلى نهايتها المنطقية لمساعدة المطورين ومهندسي العمليات:
- أتمتة وتوحيد البنية التحتية التي تستخدمها التطبيقات
- ربط عمليات النشر والتطوير معًا دون تقييد المطورين أنفسهم
- إن التأكد من أن إطلاق الخدمة أو الميزة أو التطبيق أو المجموعة بأكملها ومراجعتها وتأمينها ليس أكثر صعوبة من الأولى.
ولكن ما الفرق بين منصة OpenShift 4 وأسلافها وبين النهج "المعياري" لحل مثل هذه المشكلات؟ ما الذي يدفع الحجم لفرق التنفيذ والعمليات؟ نظراً لكون الملك في هذه الحالة هو العنقود. لذا،
- نتأكد من أن الغرض من المجموعات واضح (عزيزتي السحابة، التقطت هذه المجموعة لأنني أستطيع ذلك)
- الآلات وأنظمة التشغيل موجودة لخدمة الكتلة (صاحب الجلالة)
- إدارة حالة المضيفين من المجموعة، وتقليل إعادة بنائهم (الانجراف).
- لكل عنصر مهم في النظام، هناك حاجة إلى مربية (آلية) تراقب المشاكل وتزيلها
- يعد فشل *كل* جانب أو عنصر في النظام وآليات التعافي المرتبطة به جزءًا طبيعيًا من الحياة
- يجب تكوين البنية التحتية بأكملها عبر واجهة برمجة التطبيقات (API).
- استخدم Kubernetes لتشغيل Kubernetes. (نعم، نعم، هذا ليس خطأ مطبعي)
- يجب أن تكون التحديثات سهلة وخالية من المتاعب لتثبيتها. إذا استغرق تثبيت التحديث أكثر من نقرة واحدة، فمن الواضح أننا نرتكب خطأ ما.
- لا ينبغي أن تمثل مراقبة أي مكون وتصحيح أخطائه مشكلة، وبالتالي يجب أن يكون التتبع وإعداد التقارير عبر البنية التحتية بأكملها أمرًا سهلاً ومريحًا.
هل تريد رؤية إمكانيات المنصة أثناء العمل؟
أصبحت نسخة المعاينة من OpenShift 4 متاحة للمطورين. باستخدام أداة التثبيت سهلة الاستخدام، يمكنك تشغيل مجموعة على AWS أعلى Red Had CoreOS. لاستخدام المعاينة، تحتاج فقط إلى حساب AWS لتوفير البنية التحتية ومجموعة من الحسابات للوصول إلى صور المعاينة.
- للبدء، انتقل إلى وانقر على "البدء".
- قم بتسجيل الدخول إلى حساب Red Hat الخاص بك (أو أنشئ حسابًا جديدًا) واتبع التعليمات لإعداد مجموعتك الأولى.
بعد التثبيت الناجح، تحقق من البرامج التعليمية لدينا للحصول على فهم أعمق للأنظمة والمفاهيم التي تجعل منصة OpenShift 4 طريقة سهلة ومريحة لتشغيل Kubernetes.
جرب إصدار OpenShift الجديد وشاركنا رأيك. نحن ملتزمون بجعل العمل مع Kumbernetes متاحًا وسهلاً قدر الإمكان - مستقبل NoOps يبدأ اليوم.
والانتباه الآن!
في المؤتمر في 20 أبريل، سيعقد أحد مطوري OpenShift، Vadim Rutkovsky، فئة رئيسية - سوف يكسر عشر مجموعات ويجبرهم على إصلاحها. المؤتمر مدفوع الثمن، لكن مع الرمز الترويجي #RedHat تحصل على خصم 37%
درجة الماجستير الساعة 17:15 - 18:15، والجناح مفتوح طوال اليوم. القمصان والقبعات والملصقات - المعتادة!
القاعة رقم 2
"هنا يجب تغيير النظام بأكمله: نقوم بإصلاح مجموعات k8s المعطلة بالتعاون مع ميكانيكيين معتمدين."
المصدر: www.habr.com