تم إصدار الإصدار الرابع من OpenShift مؤخرًا نسبيًا. الإصدار الحالي 4.3 متاح منذ نهاية شهر يناير وجميع التغييرات فيه إما شيء جديد تمامًا لم يكن موجودًا في الإصدار الثالث، أو تحديث رئيسي لما ظهر في الإصدار 4.1. كل ما سنخبرك به الآن يحتاج إلى معرفته وفهمه وأخذه بعين الاعتبار من قبل أولئك الذين يعملون مع OpenShift ويخططون للتبديل إلى إصدار جديد.
مع إصدار OpenShift 4.2، سهلت Red Hat العمل مع Kubernetes. هناك أدوات ومكونات إضافية جديدة لإنشاء الحاويات وخطوط أنابيب CI/CD وعمليات النشر بدون خادم. تمنح الابتكارات المطورين الفرصة للتركيز على كتابة التعليمات البرمجية، وليس على التقاضي مع Kubernetes.
في الواقع، ما الجديد في OpenShift 4.2 و4.3؟
التحرك نحو السحب الهجينة
عند التخطيط لبنية تحتية جديدة لتكنولوجيا المعلومات أو عند تطوير مشهد تكنولوجيا المعلومات الحالي، تفكر الشركات بشكل متزايد في اتباع نهج سحابي في توفير موارد تكنولوجيا المعلومات، والتي تنفذ من أجلها حلول سحابية خاصة أو تستخدم قوة موفري الخدمات السحابية العامة. وبالتالي، يتم بناء البنى التحتية الحديثة لتكنولوجيا المعلومات بشكل متزايد على نموذج سحابي "هجين"، عندما يتم استخدام كل من الموارد المحلية والموارد السحابية العامة مع نظام إدارة مشترك. تم تصميم Red Hat OpenShift 4.2 خصيصًا لتبسيط عملية الانتقال إلى نموذج سحابي مختلط ويسمح لك بسهولة توصيل الموارد من موفري الخدمة مثل AWS وAzure وGoogle Cloud Platform إلى المجموعة إلى جانب استخدام السحابات الخاصة على VMware وOpenStack.
نهج جديد للتثبيت
في الإصدار الرابع، تغير أسلوب تثبيت OpenShift. توفر Red Hat أداة مساعدة خاصة لنشر مجموعة OpenShift، وتثبيت openshift. الأداة المساعدة هي الملف الثنائي الوحيد المكتوب بلغة Go. يقوم برنامج openshit-installer بإعداد ملف yaml بالإعدادات المطلوبة للنشر.
في حالة التثبيت باستخدام موارد السحابة ، ستحتاج إلى تحديد الحد الأدنى من المعلومات حول المجموعة المستقبلية: منطقة DNS ، وعدد العقد العاملة ، والإعدادات المحددة لموفر السحابة ، ومعلومات الحساب للوصول إلى مزود السحابة. بعد إعداد ملف التكوين ، يمكن نشر الكتلة بأمر واحد.
في حالة التثبيت على موارد الحوسبة الخاصة بك، على سبيل المثال، عند استخدام سحابة خاصة (يدعم vSphere وOpenStack) أو عند التثبيت على خوادم معدنية، ستحتاج إلى تكوين البنية التحتية يدويًا - إعداد الحد الأدنى لعدد الأجهزة الافتراضية أو الخوادم الفعلية اللازمة لإنشاء مجموعة مستوى التحكم، وتكوين خدمات الشبكة. بعد هذا التكوين، يمكن إنشاء مجموعة OpenShift بالمثل باستخدام أمر واحد من الأداة المساعدة openshift-installer.
تحديثات البنية التحتية
التكامل مع CoreOS
التحديث الرئيسي هو التكامل مع Red Hat CoreOS. يمكن الآن لعقد Red Hat OpenShift الرئيسية العمل فقط على نظام التشغيل الجديد. هذا نظام تشغيل مجاني من Red Hat، وهو مصمم خصيصًا للحلول المعبأة في حاويات. Red Hat CoreOS هو نظام Linux خفيف الوزن مُحسّن لتشغيل الحاويات.
إذا كان نظام التشغيل وOpenShift موجودًا بشكل منفصل في الإصدار 3.11، فإنه في الإصدار 4.2 يرتبط ارتباطًا وثيقًا بـ OpenShift. والآن أصبح جهازًا واحدًا - بنية تحتية ثابتة.
بالنسبة للمجموعات التي تستخدم RHCOS لجميع العقد ، يعد تحديث OpenShift Container Platform عملية بسيطة ومؤتمتة للغاية.
في السابق ، لتحديث OpenShift ، كان على المرء أولاً تحديث نظام التشغيل الأساسي الذي كان يعمل عليه المنتج (Red Hat Enterprise Linux في ذلك الوقت). بعد ذلك فقط كان من الممكن تحديث OpenShift تدريجيًا ، عقدة تلو الأخرى. لم يكن هناك حديث عن أي أتمتة للعملية.
الآن ، نظرًا لأن OpenShift Container Platform تتحكم بشكل كامل في الأنظمة والخدمات على كل عقدة ، بما في ذلك نظام التشغيل ، يتم حل هذه المهمة عن طريق الضغط على زر من واجهة الويب. بعد ذلك ، يتم إطلاق مشغل خاص داخل مجموعة OpenShift ، والذي يتحكم في عملية التحديث بأكملها.
منظمة التضامن المسيحي الدولية الجديدة
والثاني هو CSI الجديد، وهو وحدة تحكم في واجهة التخزين تسمح لك بتوصيل أنظمة تخزين خارجية مختلفة بمجموعة OpenShift. يتم دعم عدد كبير من موفري برامج تشغيل التخزين لـ OpenShift استنادًا إلى برامج تشغيل التخزين التي يكتبها بائعو وحدات التخزين أنفسهم. يمكن العثور على قائمة كاملة ببرامج تشغيل CSI المدعومة في هذا المستند: . في هذه القائمة ، يمكنك العثور على جميع النماذج الرئيسية لمصفوفات الأقراص من الشركات المصنعة الرائدة (Dell / EMC و IBM و NetApp و Hitachi و HPE و PureStorage) وحلول SDS (Ceph) والتخزين السحابي (AWS و Azure و Google). يدعم OpenShift 4.2 العمل مع برامج تشغيل CSI لإصدار مواصفات CSI 1.1.
شبكة خدمة RedHat OpenShift
استنادًا إلى مشاريع Istio و Kiali و Jaeger - تتيح شبكة Red Hat OpenShift Service Mesh ، بالإضافة إلى المهام المعتادة لتوجيه الطلبات بين الخدمات ، تتبعها وتصورها. يساعد هذا المطورين على التفاعل بسهولة مع تطبيق تم نشره داخل Red Hat OpenShift ومراقبته وإدارته.
تصور تطبيق يحتوي على بنية الخدمات المصغرة باستخدام Kiali
لتسهيل تثبيت دورة حياة Service Mesh وصيانتها وإدارتها قدر الإمكان، يوفر Red Hat OpenShift للمسؤولين مشغلًا خاصًا، وهو Service Mesh Operator. هذا هو مشغل Kubernetes الذي يسمح لك بنشر حزم Istio وKiali وJaeger المعاد تكوينها على المجموعة، مما يزيل العبء الإداري لإدارة التطبيقات قدر الإمكان.
CRI-O بدلاً من Docker
تم استبدال وقت تشغيل حاوية Docker الافتراضي بـ CRI-O. كان من الممكن استخدام CRI-O بالفعل في الإصدار 3.11، ولكن في 4.2 أصبح الإصدار الرئيسي. ليست جيدة وليست سيئة، ولكن تستحق الأخذ في الاعتبار عند استخدام المنتج.
المشغلين ونشر التطبيق
المشغلون كيان جديد لـ RedHat OpenShift ، والذي ظهر في الإصدار الرابع. إنها طريقة لتعبئة تطبيق Kubernetes ونشره وإدارته. فكر في الأمر على أنه برنامج Kubernetes API ومكوِّن إضافي مُشغل بأداة kubectl للتطبيقات المنشورة في الحاويات.
يساعد مشغلو Kubernetes في أتمتة أي مهمة تتعلق بالإدارة وإدارة دورة الحياة للتطبيق الذي تقوم بنشره على نظام المجموعة الخاص بك. على سبيل المثال، يمكن للمشغل أتمتة التحديثات والنسخ الاحتياطية وقياس التطبيق وتغييرات التكوين وما إلى ذلك. يمكن العثور على القائمة الكاملة للمشغلين على .
يمكن الوصول إلى OperatorHub مباشرة من واجهة الويب الخاصة بوحدة التحكم الإدارية. إنه كتالوج لتطبيقات OpenShift التي تديرها Red Hat. أولئك. سيتم تغطية جميع المشغلين المعتمدين من قبل Red Hat من خلال دعم البائعين.
Portal OperatorHub في وحدة تحكم إدارة OpenShift
الصورة الأساسية العالمية
هذه مجموعة قياسية من صور RHEL OS التي يمكنك استخدامها لإنشاء تطبيقاتك في حاويات. هناك مجموعات الحد الأدنى والقياسية والكاملة. يشغلون مساحة صغيرة جدًا ، ويدعمون جميع الحزم المثبتة الضرورية ولغات البرمجة.
أدوات CI/CD
يقدم RedHat OpenShif 4.2 القدرة على الاختيار بين Jenkins وOpenShift Pipelines استنادًا إلى خطوط أنابيب Tekton.
يعتمد OpenShift Pipelines على Tekton، والذي يتم دعمه بشكل أفضل بواسطة Pipeline مع اقتراب Code وGitOps. في مسارات OpenShift، يتم تشغيل كل خطوة في الحاوية الخاصة بها، لذلك يتم استخدام الموارد فقط أثناء تنفيذ الخطوة. وهذا يمنح المطورين تحكمًا كاملاً في خطوط توصيل الوحدة النمطية والمكونات الإضافية والتحكم في الوصول دون الحاجة إلى خادم CI/CD مركزي لإدارته.
OpenShift Pipelines موجود حاليًا في معاينة المطور وهو متاح كمشغل على مجموعة OpenShift 4. بالطبع، لا يزال بإمكان مستخدمي OpenShift استخدام Jenkins على RedHat OpenShift 4.
تحديثات إدارة المطور
في 4.2 OpenShift ، تم تحديث واجهة الويب بالكامل لكل من المطورين والمسؤولين.
في الإصدارات السابقة من OpenShift، كان الجميع يعملون في ثلاث وحدات تحكم: كتالوج الخدمة، ووحدة تحكم المسؤول، ووحدة تحكم العمل. تنقسم المجموعة الآن إلى جزأين فقط - وحدة تحكم المسؤول ووحدة تحكم المطور.
تلقت وحدة تحكم المطور تحسينات كبيرة في واجهة المستخدم. يعرض الآن بشكل أكثر ملاءمة طبولوجيا التطبيقات وتجميعاتها. وهذا يسهل على المطورين إنشاء ونشر وتصور التطبيقات المعبأة في حاويات والموارد المجمعة. يسمح لهم بالتركيز على ما هو مهم بالنسبة لهم.
بوابة المطور في وحدة تحكم إدارة OpenShift
أودو
Odo عبارة عن أداة مساعدة لسطر الأوامر موجهة نحو المطورين تعمل على تبسيط تطوير التطبيقات في OpenShift. باستخدام تفاعل أسلوب git Push، تساعد واجهة سطر الأوامر (CLI) المطورين الجدد في Kubernetes على إنشاء تطبيقات في OpenShift.
التكامل مع بيئات التطوير
يمكن للمطورين الآن إنشاء تطبيقاتهم وتصحيح أخطائها ونشرها في OpenShift دون ترك بيئة تطوير التعليمات البرمجية المفضلة لديهم مثل Microsoft Visual Studio وJetBrains (بما في ذلك IntelliJ) وEclipse Desktop والمزيد.
ملحق النشر Red Hat OpenShift لـ Microsoft Azure DevOps
تم إصدار ملحق Red Hat OpenShift Deployment لـ Microsoft Azure DevOps. الآن يمكن لمستخدمي هذه المجموعة من أدوات DevOps نشر تطبيقاتهم في Azure Red Hat OpenShift أو أي مجموعة OpenShift أخرى مباشرة من Microsoft Azure DevOps.
الانتقال من الإصدار الثالث إلى الإصدار الرابع
نظرًا لأننا نتحدث عن إصدار جديد، وليس تحديثًا، فليس من السهل أخذ الإصدار الرابع ووضعه فوق الإصدار الثالث. لن يتم دعم الترقية من الإصدار XNUMX إلى الإصدار XNUMX.
ولكن هناك أخبار جيدة: توفر Red Hat أدوات لترحيل المشاريع من 3.7 إلى 4.2. يمكنك ترحيل أحمال عمل التطبيق باستخدام أداة ترحيل التطبيقات العنقودية (CAM). يتيح لك CAM التحكم في الترحيل وتقليل وقت توقف التطبيق.
وردية مفتوحة 4.3
ظهرت الابتكارات الرئيسية الموضحة في هذه المقالة في الإصدار 4.2. في الإصدار 4.3 الذي تم إصداره مؤخرًا، لم تكن التغييرات مهمة، ولكن لا يزال هناك شيء جديد. قائمة التغييرات واسعة جدًا، وإليك أهمها في رأينا:
قم بتحديث إصدار Kubernetes إلى 1.16.
تمت ترقية الإصدار بخطوتين مرة واحدة، في OpenShift 4.2 كان 1.14.
تشفير البيانات في الخ
بدءًا من الإصدار 4.3 ، أصبح من الممكن تشفير البيانات في قاعدة البيانات إلخ. بعد تمكين التشفير ، سيكون تشفير موارد OpenShift API و Kubernetes API التالية ممكنًا: الأسرار وخرائط التكوين والمسارات ورموز الوصول وتفويض OAuth.
قاد
تمت إضافة دعم للإصدار 3 من Helm، وهو مدير حزم مشهور لـ Kubernetes. بينما يتمتع الدعم بوضع TECHNOLOGY PREVIEW. سيتم توسيع دعم Helm ليشمل الدعم الكامل في الإصدارات المستقبلية من OpenShift. يتم توفير الأداة المساعدة helm cli مع OpenShift ويمكن تنزيلها من وحدة تحكم ويب إدارة المجموعة.
تحديث لوحة تحكم المشروع
في الإصدار الجديد ، توفر لوحة معلومات المشروع معلومات إضافية عن صفحة المشروع: حالة المشروع واستخدام الموارد والحصص النسبية للمشروع.
عرض نقاط الضعف في الرصيف في وحدة تحكم الويب
تمت إضافة وظيفة لعرض الثغرات الأمنية المعروفة للصور الموجودة في مستودعات Quay في وحدة التحكم الإدارية. يتم دعم عرض الثغرات الأمنية للمستودعات المحلية والخارجية.
إنشاء مبسط لمركز التشغيل غير المتصل بالإنترنت
بالنسبة لحالة نشر مجموعة OpenShift في شبكة معزولة ذات وصول محدود أو معدوم إلى الإنترنت ، فقد تم تبسيط إنشاء "مرآة" لسجل OperatorHub. الآن يمكن القيام بذلك بثلاثة أوامر فقط.
المؤلفون:
فيكتور بوتشكوف، يوري سيمينيوكوف
المصدر: www.habr.com