هذا هو الأول من سلسلة منشوراتنا المخصصة للتحسينات والإضافات في التحديث القادم لمنصة Red Hat OpenShift إلى الإصدار 4.0 ، مما سيساعدك على الاستعداد للانتقال إلى الإصدار الجديد.
ما هي الأدوات التي يمكنك الحصول عليها تحت تصرفك لإنشاء منتجات برمجيات أفضل ، وكيف ستعمل على تحسين الأمان وجعل التطوير أسهل وأكثر موثوقية؟
منذ اللحظة التي اجتمع فيها ممثلو مجتمع Kubernetes الذي تم تشكيله حديثًا لأول مرة في خريف عام 2014 في مكتب Google في سياتل ، يمكن القول بالفعل أن مشروع Kubernetes كان يهدف إلى تغيير المقاربات الحديثة لتطوير البرامج وتنفيذها بشكل أساسي. في الوقت نفسه ، واصل مقدمو الخدمات السحابية العامة الاستثمار بكثافة في تطوير البنية التحتية والخدمات ، مما سهل إلى حد كبير وتبسيط العمل مع تكنولوجيا المعلومات وإنشاء البرامج ، وجعلها في متناول الجميع بشكل لا يصدق ، وهو ما كان يمكن أن يتخيله القليلون في بداية العقد.
بالطبع ، كان الإعلان عن كل خدمة سحابية جديدة مصحوبًا بالعديد من المناقشات التي أجراها خبراء على Twitter ، وعقدت النزاعات حول مجموعة متنوعة من الموضوعات - بما في ذلك نهاية عصر المصادر المفتوحة ، وتراجع تكنولوجيا المعلومات من جانب العميل (تقنية المعلومات المحلية) ، وحتمية احتكار البرامجيات الجديد في السحابة ، وكيف سيحل النموذج الجديد X محل جميع النماذج الأخرى.
ومع ذلك ، فإن الحقيقة هي أن لا شيء يختفي ، ويمكنك اليوم ملاحظة النمو الهائل للمنتجات والأساليب النهائية لتطويرها ، والذي يرتبط بالظهور المستمر للبرامج الجديدة في حياتنا. وعلى الرغم من حقيقة أن كل شيء سوف يتغير ، في الوقت نفسه ، في جوهره ، سيبقى كل شيء كما هو دون تغيير. سيستمر مطورو البرامج في كتابة التعليمات البرمجية مع وجود أخطاء ، وسيواصل مهندسو الصيانة ومتخصصو الموثوقية السير مع أجهزة الاستدعاء وتلقي تنبيهات تلقائية في سلاك ، وسيظل المديرون يعملون على مفاهيم OpEx و CapEx ، وكلما حدث فشل ، يقوم كبار سوف تنهد المطور بحزن بكلمات: "قلت" ...
مع التعقيد المتزايد للمشاريع ، تظهر أيضًا مخاطر جديدة ، وتعتمد حياة الناس اليوم على البرامج لدرجة أن المطورين ملزمون ببساطة بمحاولة القيام بعملهم بشكل أفضل.
Kubernetes هي واحدة من هذه الأداة. يجري العمل على دمجها مع الأدوات والخدمات الأخرى في نظام أساسي واحد في إطار Red Hat OpenShift ، مما سيجعل البرنامج أكثر موثوقية وسهلة الإدارة وآمنة للمستخدمين.
مع ذلك ، يطرح السؤال التالي: كيف نجعل العمل مع Kubernetes أسهل وأكثر راحة؟قد تبدو الإجابة بسيطة بشكل مدهش:
- أتمتة اللحظات المعقدة عند النشر على السحابة أو خارجها
- التركيز على الموثوقية مع إخفاء التعقيد ؛
- استمر في العمل على إصدار تحديثات بسيطة وآمنة
- تحقيق القدرة على التدقيق وقدرات التدقيق ؛
- نسعى جاهدين في البداية لتوفير إجراءات أمنية مشددة ، ولكن ليس على حساب سهولة الاستخدام.
يجب أن يأخذ الإصدار التالي من OpenShift في الحسبان تجربة المبدعين وتجربة المطورين الآخرين الذين يقومون بتنفيذ البرامج على نطاق واسع في أكبر الشركات في العالم. بالإضافة إلى ذلك ، من الضروري مراعاة جميع التجارب المتراكمة للنظم الإيكولوجية المفتوحة التي تشكل اليوم أساس العالم الحديث. في هذه الحالة ، من الضروري التخلي عن العقلية القديمة لمطور الهواة والانتقال إلى فلسفة جديدة لمستقبل تلقائي. يجب أن يكون "جسرًا" بين الطرق القديمة والجديدة لنشر البرامج والاستفادة الكاملة من جميع البنية التحتية المتاحة - لا يهم ما إذا كان يتم خدمتها بواسطة أكبر موفر خدمة سحابية أو يعمل على أنظمة صغيرة على الهامش.
كيفية تحقيق هذه النتيجة؟
في Red Hat ، من المعتاد القيام بأعمال مملة وغير مجففة لفترة طويلة من أجل الحفاظ على المجتمع الراسخ ومنع إغلاق المشاريع التي تشارك فيها الشركة. يتكون مجتمع المصادر المفتوحة من عدد كبير من المطورين الموهوبين الذين يصنعون الأشياء الأكثر استثنائية - مسلية وتعليمية واكتشاف فرص جديدة وجميلة ببساطة ، ولكن ، بالطبع ، لا يتوقع أحد أن يتحرك جميع المشاركين في نفس الاتجاه أو متابعة أهداف مشتركة. يعد استخدام هذه الطاقة ، وإعادة توجيهها في الاتجاه الصحيح ، ضروريًا في بعض الأحيان لتطوير المناطق التي ستكون مفيدة لمستخدمينا ، ولكن في الوقت نفسه ، يجب علينا مراقبة تطور مجتمعاتنا والتعلم منها.
في بداية عام 2018 ، استحوذت ريد هات على مشروع CoreOS ، الذي كان له وجهات نظر متشابهة بشأن المستقبل - وهو نهج أكثر أمانًا وموثوقية ، ومصدر مفتوح. عملت الشركة على زيادة تطوير هذه الأفكار وتنفيذها ، وتنفيذ فلسفتنا - في محاولة لتحقيق التشغيل الآمن لجميع البرامج. يعتمد كل هذا العمل على Kubernetes و Linux والسحب العامة والسحب الخاصة وآلاف المشاريع الأخرى التي تقوم عليها نظامنا البيئي الرقمي الحديث.
سيكون الإصدار الجديد من OpenShift 4 مفهوما وآليًا وأكثر طبيعيةستعمل منصة OpenShift مع أفضل أنظمة تشغيل Linux وأكثرها موثوقية ، مع دعم الأجهزة المعدنية المجردة ، والمحاكاة الافتراضية المريحة ، والبرمجة التلقائية للبنية التحتية ، وبالطبع الحاويات (التي هي في الأساس مجرد صور Linux).
يجب أن يكون النظام الأساسي آمنًا من البداية ، ولكن في الوقت نفسه يوفر إمكانية تكرار مناسب للمطورين - أي يتمتعون بمرونة وموثوقية كافية ، مع السماح للمسؤولين بالتدقيق وتوفير إدارة سهلة.
يجب أن يسمح لك بتشغيل البرنامج "في شكل خدمة" ، وألا يؤدي إلى التوسع غير المنضبط للبنية التحتية للمشغلين.
سيتيح للمطورين التركيز على إنشاء منتجات حقيقية للمستخدمين والعملاء. لا حاجة للتعرية على غابة إعدادات الأجهزة والبرامج ، وكل المضاعفات العشوائية ستكون شيئًا من الماضي.
OpenShift 4: منصة NoOps لا تتطلب صيانة
يصف
هذا المنشور المهام التي ساعدت في تشكيل رؤية الشركة لـ OpenShift 4. يضطلع الفريق بمهمة تبسيط المهام اليومية لتشغيل البرامج وصيانتها إلى أقصى حد ممكن ، مما يجعل هذه العمليات سهلة وبدون مجهود ، سواء للمتخصصين في التنفيذ أو المطورين. ولكن كيف يمكن للمرء أن يقترب من هذا الهدف؟ كيف تنشئ منصة لإطلاق البرامج التي تتطلب الحد الأدنى من التدخل؟ ماذا يعني NoOps في هذا السياق؟
إذا حاولت تجاهلها ، فبالنسبة للمطورين ، تعني مفاهيم "بدون خادم" أو "NoOps" الأدوات والخدمات التي تتيح لك إخفاء المكون "التشغيلي" أو تقليل هذا العبء بالنسبة للمطور.
- لا تعمل مع الأنظمة ، ولكن مع واجهات التطبيق (واجهات برمجة التطبيقات).
- لا تقم بتطبيق البرنامج - دع الموفر يقوم بذلك بدلاً من ذلك.
- لا ينبغي لك على الفور إنشاء إطار كبير - ابدأ بكتابة الأجزاء الصغيرة التي ستكون بمثابة "لبنات بناء" ، حاول جعل هذا الرمز يعمل مع البيانات والأحداث ، وليس مع الأقراص وقواعد البيانات.
المهمة ، كما كان من قبل ، هي تسريع التكرار في تطوير البرمجيات ، وإتاحة الفرصة لإنشاء منتجات أفضل ، بحيث لا يستطيع المطور القلق بشأن الأنظمة التي يعمل عليها البرنامج. يدرك المطور ذو الخبرة جيدًا أنه إذا ركزت على المستخدمين ، يمكن أن تتغير الصورة بسرعة ، لذلك يجب ألا تستثمر الكثير من الجهد في كتابة البرامج إذا لم تكن لديك ثقة مطلقة في ضرورة ذلك.
بالنسبة للمهنيين المشاركين في الصيانة والتشغيل ، قد تبدو كلمة "NoOps" مخيفة إلى حد ما. ولكن أثناء التواصل مع مهندسي التشغيل ، يصبح من الواضح أن الأنماط والأساليب المستخدمة من قبلهم ، والتي تهدف إلى ضمان موثوقية الموثوقية (هندسة موثوقية الموقع ، SRE) ، تتداخل إلى حد كبير مع الأنماط المذكورة أعلاه:
- لا تدير الأنظمة - أتمتة عمليات الإدارة الخاصة بهم.
- لا تقم بتنفيذ البرنامج - قم بإنشاء خط أنابيب لنشره.
- حاول ألا تجمع كل خدماتك معًا ولا تسمح لفشل إحداها في فشل النظام بأكمله - تفريقهم عبر البنية التحتية باستخدام أدوات التشغيل الآلي وتوصيلها ، مما يوفر إمكانية التحكم والمراقبة.
يعلم متخصصو SRE أن هناك شيئًا ما قد يحدث ، ويجب عليهم تتبع المشكلة وحلها - وبالتالي ، فإنهم يقومون بأتمتة الروتين ويحددون مسبقًا تحمُّل الخطأ حتى يكونوا مستعدين لتحديد الأولويات واتخاذ القرارات عند حدوث مشكلة .
OpenShift’s Kubernetes عبارة عن منصة مصممة لحل مهمتين رئيسيتين: بدلاً من إجبارك على التعامل مع الأجهزة الافتراضية أو تحميل واجهات برمجة التطبيقات لموازنة ، العمل مع التجريدات ذات الترتيب العالي - مع عمليات النشر والخدمات. بدلاً من تثبيت وكلاء البرنامج ، يمكنك تشغيل الحاويات ، وبدلاً من كتابة مكدس المراقبة الخاص بك ، استخدم الأدوات المتوفرة بالفعل على النظام الأساسي. وبالتالي ، فإن المكون السري لـ OpenShift 4 لا يمثل في الواقع أي سر - تحتاج فقط إلى أخذ مبادئ SRE والمفاهيم بدون خادم كأساس ، وتقديمهم إلى نهايتها المنطقية ، لمساعدة المطورين ومهندسي الصيانة:
- أتمتة وتوحيد البنية التحتية المستخدمة من قبل التطبيقات
- يجمع بين عمليات النشر والتطوير دون تقييد المطورين أنفسهم
- التأكد من أن بدء تشغيل أو مراجعة أو حماية خدمة مائة أو وظيفة أو تطبيق أو مكدس كامل ليس أكثر صعوبة من الأول.
ولكن ما الفرق بين منصة OpenShift 4 وسابقاتها والنهج "القياسي" لحل مثل هذه المشكلات؟ كيف يتم تحقيق التوسع لفرق التنفيذ والتشغيل؟ يرجع ذلك إلى حقيقة أن الملك في هذه الحالة هو العنقودية. وهكذا،
- نجعل الغرض من المجموعات مفهومة (عزيزي السحابة ، لقد رفعت هذه المجموعة لأنني أستطيع)
- توجد آلات وأنظمة تشغيل لخدمة المجموعة (صاحب الجلالة)
- إدارة حالة المضيفين من الكتلة ، وتقليل إعادة البناء (الانجراف).
- لكل عنصر مهم في النظام ، هناك حاجة إلى مربية (آلية) لتتبع المشكلات وحلها
- الفشل * في كل جانب * أو عنصر من عناصر النظام ؛ آليات الاسترداد المقابلة هي جزء عادي من الحياة
- يجب تكوين البنية التحتية بأكملها من خلال واجهة برمجة التطبيقات.
- استخدم Kubernetes لإطلاق Kubernetes. (نعم ، نعم ، هذا ليس خطأ مطبعي)
- يجب تثبيت التحديثات بسهولة وبشكل طبيعي. إذا تطلب الأمر أكثر من نقرة واحدة لتثبيت التحديث ، فمن الواضح أنك / نحن نقوم بشيء خاطئ.
- لا ينبغي أن تكون مراقبة وتصحيح أي مكون مشكلة ، وبالتالي ، يجب أن يكون التتبع والإبلاغ عبر البنية التحتية بأكملها أمرًا بسيطًا وملائمًا.
هل تريد أن ترى قدرات المنصة في العمل؟
أصبح الإصدار الأولي من OpenShift 4 متاحًا للمطورين. مع أداة التثبيت سهلة الاستخدام ، يمكنك تشغيل نظام AWS أعلى Red Had CoreOS. لاستخدام إصدار المعاينة ، تحتاج فقط إلى حساب AWS لتوفير البنية التحتية ومجموعة من الحسابات للوصول إلى صور إصدار المعاينة.
- للبدء ، انتقل إلى try.openshift.com وانقر على "البدء".
- قم بتسجيل الدخول إلى حساب Red Hat الخاص بك (أو أنشئ حسابًا جديدًا) واتبع الإرشادات لإعداد المجموعة الأولى.
بعد التثبيت الناجح ، تحقق من دروس
OpenShift Training الخاصة بنا لمعرفة المزيد حول الأنظمة والمفاهيم التي تجعل من منصة OpenShift 4 أداة بسيطة ومريحة لإطلاق Kubernetes.
وفي مؤتمر DevOpsForum 2019 ، سيعقد أحد مطوري OpenShift ، Vadim Rutkovsky ، فئة رئيسية "هنا تحتاج إلى تغيير النظام بالكامل: إصلاح مجموعات k8 المكسورة إلى جانب الأقفال المعتمدة" - سوف يكسر عشر مجموعات ويظهر كيفية إصلاحها.يتم دفع القبول في المؤتمر ، ولكن باستخدام الرمز الترويجي #RedHat - خصم 37 ٪.
نحن في انتظارك في 20 أبريل في فصل ماجستير في القاعة رقم 2 في الساعة 17:15 ، وفي جناحنا - طوال اليوم. معلومات مفيدة عن المنتج ، لقاء مع الخبراء ، قمصان ، قبعات ، ملصقات Red Hat - كل شيء كالمعتاد! :-)