معذرة OpenShift ، لم نكن نقدر لك ما يكفي ولم نأخذك كأمر مسلم به

تمت كتابة هذا المنشور لأن موظفينا أجروا الكثير من المحادثات مع العملاء حول تطوير التطبيقات على Kubernetes وتفاصيل هذا التطوير على OpenShift.







نبدأ عادةً بالأطروحة القائلة بأن Kubernetes هي Kubernetes فقط ، وأن OpenShift عبارة عن منصة Kubernetes بالفعل ، مثل Microsoft AKS أو Amazon EKS. كل من هذه المنصات لها مزاياها الخاصة ، وتستهدف واحدًا أو آخر من الجمهور المستهدف. وبعد ذلك ، تمتد المحادثة بالفعل إلى مقارنة نقاط القوة والضعف في منصات معينة.



بشكل عام ، فكرنا في كتابة هذا المنشور مع خاتمة مثل "استمع ، لا يهم مكان تشغيل الكود ، على OpenShift أو على AKS ، أو على EKS ، أو على بعض Kubernetes المخصصة ، أو على أي Kubernetes (للإيجاز ، دعنا نسميها KUK) بسيط حقًا ، هناك وهناك ".



ثم خططنا لأخذ أبسط عبارة "Hello World" وباستخدام مثالها ، أظهر ما هو مشترك وما هي الاختلافات بين KUK و Red Hat OpenShift Container Platform (يشار إليها فيما بعد بـ OCP أو ببساطة OpenShift).



ومع ذلك ، أثناء كتابة هذا المنشور ، أدركنا أننا كنا معتادين جدًا على استخدام OpenShift لفترة طويلة لدرجة أننا ببساطة لا ندرك كيف تطورت وتحولت إلى منصة مذهلة أصبحت أكثر بكثير من مجرد توزيع Kubernetes. لقد اعتدنا على اعتبار نضج OpenShift وبساطته أمرًا مفروغًا منه مع إغفال تألقه.



بشكل عام ، حان الوقت للتوبة النشطة ، والآن سنقارن خطوة بخطوة بدء تشغيل برنامج "Hello World" على KUK وعلى OpenShift ، وسنفعل ذلك بموضوعية قدر الإمكان (حسنًا ، ربما ، في بعض الأحيان نظهر موقفًا شخصيًا تجاه هذا الموضوع). إذا كنت مهتمًا برأي شخصي بحت حول هذه المسألة ، فيمكنك قراءته هنا (بالإنكليزية) . في هذا المنشور ، سنلتزم بالحقائق والحقائق فقط.



عناقيد المجموعات



لذا ، فإن برنامج "Hello World" الخاص بنا يحتاج إلى مجموعات. دعنا نقول لا لأي سحابة عامة ، حتى لا ندفع مقابل الخوادم والسجلات والشبكات ونقل البيانات وما إلى ذلك. وفقًا لذلك ، نختار مجموعة بسيطة أحادية العقدة على Minikube (لـ KUK ) وحاويات Code Ready (لمجموعة OpenShift). كلا الخيارين سهل التثبيت حقًا ، لكنهما سيتطلبان الكثير من الموارد على الكمبيوتر المحمول.







التجميع على KUK-e



إذا هيا بنا.



الخطوة 1 - بناء صورة الحاوية الخاصة بنا



سأبدأ بنشر "Hello World" على minikube. سيتطلب ذلك:



  1. 1. تثبيت عامل ميناء.
  2. 2. تثبيت Git.
  3. 3. مثبت Maven (في الواقع يستخدم هذا المشروع ثنائي mvnw ، لذا يمكنك الاستغناء عنه).
  4. 4. في الواقع ، المصدر نفسه ، أي استنساخ من المستودع github.com/gcolman/quarkus-hello-world.git


الخطوة الأولى هي إنشاء مشروع Quarkus. لا تنزعج إذا لم تعمل مع Quarkus.io مطلقًا - فهذا سهل. ما عليك سوى تحديد المكونات التي تريد استخدامها في المشروع (RestEasy ، و Hibernate ، و Amazon SQS ، و Camel ، وما إلى ذلك) ، ثم يقوم Quarkus نفسه ، دون أي مشاركة منك ، بتكوين النموذج الأصلي المخضرم وتحميل كل شيء إلى github. وهذا يعني ، حرفيًا نقرة واحدة بالماوس - وقد انتهيت. لهذا السبب نحب Quarkus.







أسهل طريقة لبناء "Hello World" في صورة حاوية هي استخدام امتدادات Docker quarkus-maven ، والتي ستؤدي كل العمل. مع ظهور Quarkus ، أصبح هذا أمرًا سهلاً وبسيطًا حقًا: أضف امتداد حاوية صورة الحاوية ويمكنك إنشاء صور بأوامر المخضرم.



./mvnw quarkus:add-extension -Dextensions=”container-image-docker”


أخيرًا ، نبني صورتنا باستخدام Maven. نتيجة لذلك ، يتحول كود المصدر الخاص بنا إلى صورة حاوية جاهزة يمكن إطلاقها بالفعل في وقت تشغيل الحاوية.







./mvnw -X clean package -Dquarkus.container-image.build=true


هذا ، في الواقع ، كل شيء ، يمكنك الآن بدء الحاوية باستخدام أمر docker run ، بعد تعيين خدمتنا إلى المنفذ 8080 حتى تتمكن من الوصول إليها.



docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world








بعد بدء مثيل الحاوية ، يبقى فقط التحقق باستخدام الأمر curl من تشغيل خدمتنا:







لذلك كل شيء يعمل وكان حقًا سهلًا وبسيطًا.



الخطوة 2 - دفع الحاوية الخاصة بنا إلى مستودع صور الحاوية



حتى الآن ، يتم تخزين الصورة التي أنشأناها محليًا ، في مخزن الحاويات المحلي لدينا. إذا أردنا استخدام هذه الصورة في بيئة KUK الخاصة بنا ، فيجب وضعها في مستودع آخر. لا يحتوي Kubernetes على مثل هذه الميزات ، لذلك سنستخدم dockerhub. لأنه ، أولاً ، إنه مجاني ، وثانيًا ، (تقريبًا) يفعله الجميع.



هذا أيضًا بسيط جدًا ، وتحتاج فقط إلى حساب dockerhub.



لذلك ، نقوم بتثبيت dockerhub وإرسال صورتنا هناك.







الخطوة 3 - إطلاق Kubernetes



هناك العديد من الطرق لتجميع إعدادات kubernetes معًا لتشغيل Hello World ، لكننا سنستخدم أبسطها ، فنحن نوع الأشخاص الذين نحن ...



أولاً ، ابدأ مجموعة minikube:



minikube start


الخطوة 4 - نشر صورة الحاوية الخاصة بنا



نحتاج الآن إلى تحويل الكود وصورة الحاوية في تكوين kubernetes. بعبارة أخرى ، نحتاج إلى تعريف للحاوية والنشر مع الإشارة إلى صورة الحاوية الخاصة بنا على dockerhub. إحدى أسهل الطرق للقيام بذلك هي تشغيل أمر إنشاء النشر الذي يشير إلى صورتنا:







kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT


باستخدام هذا الأمر ، طلبنا من KUK إنشاء تكوين نشر يجب أن يحتوي على مواصفات pod لصورة الحاوية الخاصة بنا. سيقوم هذا الأمر أيضًا بتطبيق هذا التكوين على مجموعة minikube الخاصة بنا ، وإنشاء نشر يقوم بتنزيل صورة الحاوية الخاصة بنا ويبدأ الكبسولة في الكتلة.



الخطوة 5 - فتح الوصول إلى خدمتنا



الآن بعد أن أصبح لدينا صورة حاوية منتشرة ، حان الوقت للتفكير في كيفية تكوين الوصول الخارجي إلى هذه الخدمة المريحة ، والتي ، في الواقع ، مبرمجة في الكود الخاص بنا.



هناك عدة طرق. على سبيل المثال ، يمكنك استخدام الأمر expose لإنشاء مكونات Kubernetes المناسبة تلقائيًا مثل الخدمات ونقاط النهاية. في الواقع ، هذا ما سنفعله بتنفيذ الأمر expose لكائن النشر الخاص بنا:



kubectl expose deployment hello-quarkus — type=NodePort — port=8080


دعنا نتحدث عن خيار "- type" لأمر expose للحظة.



عندما نكشف وننشئ المكونات اللازمة لتشغيل خدمتنا ، فإننا نريد ، من بين أشياء أخرى ، أن نكون قادرين على الاتصال من الخارج بخدمة hello-quarkus الموجودة داخل SDN الخاص بنا. وتسمح لنا معلمة النوع بإنشاء وتوصيل أشياء مثل موازن التحميل لتوجيه حركة المرور إلى هذه الشبكة.



على سبيل المثال ، بكتابة type = LoadBalancer، سنقوم تلقائيًا بتهيئة موازن التحميل في السحابة العامة للاتصال بمجموعة Kubernetes الخاصة بنا. هذا ، بالطبع ، رائع ، لكن عليك أن تفهم أن مثل هذا التكوين سيكون مرتبطًا بشكل صارم بسحابة عامة معينة وسيكون من الصعب نقلها بين مثيلات Kubernetes في بيئات مختلفة.



في مثالنا ، اكتب = NodePort ، أي أن الاتصال بخدمتنا يمر عبر عنوان IP الخاص بالعقدة ورقم المنفذ. يتيح لك هذا الخيار عدم استخدام أي سحابة عامة ، ولكنه يتطلب عددًا من الخطوات الإضافية. أولاً ، أنت بحاجة إلى موازن التحميل الخاص بك ، لذلك سنقوم بنشر موازن تحميل NGINX في مجموعتنا.



الخطوة 6 - تثبيت موازن التحميل



يحتوي Minikube على عدد من وظائف النظام الأساسي التي تجعل من السهل إنشاء المكونات اللازمة للوصول الخارجي ، مثل أجهزة التحكم في الدخول. يأتي Minikube مرفقًا بوحدة تحكم Nginx ingress ، ونحتاج فقط إلى تمكينه وتكوينه.



minikube addons enable ingress


الآن ، بأمر واحد فقط ، سننشئ وحدة تحكم Nginx ingress التي ستعمل داخل مجموعة minikube الخاصة بنا:



ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m


الخطوة 7 - تكوين الدخول



نحتاج الآن إلى تكوين وحدة تحكم Nginx ingress لقبول طلبات hello-quarkus.











أخيرًا ، نحتاج إلى تطبيق هذا التكوين.







kubectl apply -f ingress.yml








نظرًا لأننا نقوم بكل هذا على جهاز الكمبيوتر الخاص بنا ، فإننا ببساطة نضيف عنوان IP الخاص بالعقدة إلى ملف / etc / hosts لتوجيه طلبات http إلى minikube الخاص بنا إلى موازن تحميل NGINX.



192.168.99.100 hello-quarkus.info


هذا كل شيء ، الآن يمكن الوصول إلى خدمة minikube الخاصة بنا من الخارج من خلال وحدة تحكم إدخال Nginx.







حسنًا ، كان ذلك سهلاً ، أليس كذلك؟ أم لا حقا؟









إطلاق على OpenShift (حاويات جاهزة للتعليمات البرمجية)



لنرى الآن كيف يتم كل شيء على Red Hat OpenShift Container Platform (OCP).



كما هو الحال مع minikube ، نختار مخططًا يحتوي على مجموعة OpenShift أحادية العقدة في شكل حاويات Code Ready (CRC). كان يطلق عليه اسم minishift وكان يعتمد على مشروع OpenShift Origin ، ولكنه الآن عبارة عن CRC وهو مبني على Red Hat's OpenShift Container Platform.



نحن هنا ، آسفون ، لا يسعنا إلا أن نقول: "OpenShift رائع!"



في البداية ، اعتقدنا أن نكتب أن التطوير على OpenShift لا يختلف عن التطوير على Kubernetes. وفي الحقيقة هو كذلك. لكن أثناء كتابة هذا المنشور ، تذكرنا عدد الحركات غير الضرورية التي يتعين عليك القيام بها عندما لا يكون لديك OpenShift ، وبالتالي ، مرة أخرى ، إنه أمر رائع. نحن نحب ذلك عندما يتم كل شيء بسهولة ، ومدى سهولة مقارنته بـ minikube ، يتم نشر مثالنا وتشغيله على OpenShift ، في الواقع ، وقد دفعنا إلى كتابة هذا المنشور.



لنستعرض العملية ونرى ما يتعين علينا القيام به.



لذلك ، في مثال minikube ، بدأنا بـ Docker ... توقف ، لم نعد بحاجة إلى تثبيت Docker على الجهاز.



ولسنا بحاجة إلى بوابة محلية.

وليس هناك حاجة مخضرم.

ولا يتعين عليك إنشاء صورة حاوية بيديك.

ولا داعي للبحث عن أي مستودع لصور الحاوية.

ولست بحاجة إلى تثبيت وحدة تحكم الدخول.

ولا تحتاج إلى تكوين دخول أيضًا.




فهمت ، أليس كذلك؟ لا تحتاج إلى أي مما سبق لنشر تطبيقنا وتشغيله على OpenShift. والعملية نفسها تبدو هكذا.



الخطوة 1 - إطلاق OpenShift Cluster



نحن نستخدم حاويات Code Ready من Red Hat ، وهي في الأساس نفس Minikube ، ولكن فقط مع مجموعة Openhift أحادية العقدة كاملة.



crc start


الخطوة 2 - إنشاء التطبيق ونشره في مجموعة OpenShift Cluster



في هذه الخطوة تتجلى بساطة OpenShift وملاءمتها في كل مجدها. كما هو الحال مع جميع توزيعات Kubernetes ، لدينا العديد من الطرق لتشغيل تطبيق على مجموعة. وكما في حالة KUK ، نختار أبسطها عن عمد.



لطالما تم إنشاء OpenShift كمنصة لإنشاء التطبيقات ذات الحاويات وتشغيلها. لطالما كانت حاويات البناء جزءًا لا يتجزأ من هذه المنصة ، لذلك هناك مجموعة من موارد Kubernetes الإضافية للمهام ذات الصلة.



سنستخدم عملية OpenShift Source 2 Image (S2I) ، والتي لها عدة طرق مختلفة لأخذ مصدرنا (الكود أو الثنائيات) وتحويله إلى صورة حاوية تعمل على مجموعة OpenShift.



لهذا نحتاج شيئين:



  • كود المصدر الخاص بنا في مستودع git
  • صورة منشئ ، بناءً على سيتم تنفيذ البناء.


هناك العديد من هذه الصور ، يتم صيانتها بواسطة Red Hat وعلى مستوى المجتمع ، وسنستخدم صورة OpenJDK ، حيث إنني أقوم بإنشاء تطبيق Java.



يمكنك بدء إنشاء S2I من كل من وحدة التحكم الرسومية OpenShift Developer ومن سطر الأوامر. سنستخدم أمر التطبيق الجديد لإخباره بمكان الحصول على صورة المنشئ وكود المصدر الخاص بنا.







oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git


هذا كل شيء ، تم إنشاء تطبيقنا. عند القيام بذلك ، قامت عملية S2I بالأشياء التالية:



  • إنشاء خدمة build-pod لجميع أنواع الأشياء المتعلقة ببناء التطبيق.
  • إنشاء تكوين OpenShift Build.
  • تنزيل صورة المنشئ إلى سجل عامل الإرساء الداخلي لـ OpenShift.
  • تم نسخ "Hello World" إلى المستودع المحلي.
  • رأيت أنه كان هناك مخضرم بوم هناك وقم بتجميع التطبيق مع المخضرم.
  • إنشاء صورة حاوية جديدة تحتوي على تطبيق Java المترجم ووضع تلك الصورة في سجل الحاوية الداخلي.
  • تم إنشاء نشر Kubernetes بمواصفات pod والخدمة وما إلى ذلك.
  • تم إطلاق نشر صورة الحاوية.
  • تمت إزالة جراب بناء الخدمة.


هناك الكثير من الأشياء في هذه القائمة ، ولكن الشيء الرئيسي هو أن جميع الإنشاءات تتم بشكل حصري داخل OpenShift ، وأن سجل Docker الداخلي موجود داخل OpenShift ، وتقوم عملية الإنشاء بإنشاء جميع مكونات Kubernetes وتشغيلها في المجموعة.



إذا كنت تتعقب بصريًا إطلاق S2I في وحدة التحكم ، يمكنك معرفة كيفية تشغيل جراب الإنشاء أثناء الإنشاء.







الآن دعنا نلقي نظرة على سجلات جراب البناء: أولاً ، يوضح كيف يقوم المخضرم بعمله ويقوم بتنزيل التبعيات لبناء تطبيق جافا الخاص بنا.







بعد الانتهاء من بناء المخضرم ، يبدأ بناء صورة الحاوية ، ثم يتم دفع هذه الصورة المبنية إلى المستودع الداخلي.







هذا كل شيء ، اكتملت عملية التجميع. الآن دعنا نتأكد من أن البودات والخدمات الخاصة بتطبيقنا تعمل في الكتلة.



oc get service








هذا كل شئ. وفريق واحد فقط. علينا فقط أن نعرض هذه الخدمة للوصول الخارجي.



الخطوة 3 - كشف الخدمة للوصول الخارجي



كما في حالة KUK ، في منصة OpenShift ، يحتاج "Hello World" أيضًا إلى جهاز توجيه لتوجيه حركة المرور الخارجية إلى خدمة داخل المجموعة. OpenShift يجعل هذا الأمر سهلاً للغاية. أولاً ، يتم تثبيت مكون التوجيه HAProxy في الكتلة افتراضيًا (يمكن تغييره إلى نفس NGINX). ثانيًا ، هناك موارد خاصة وقابلة للتكوين بدرجة كبيرة تسمى الطرق ، والتي تشبه كائنات الدخول في Kubernetes القديمة الجيدة (في الواقع ، أثرت مسارات OpenShift بشدة على تصميم كائنات الدخول ، والتي يمكن استخدامها الآن في OpenShift) ، ولكن بالنسبة لـ "Hello World" ، وفي جميع الحالات الأخرى تقريبًا ، يعد المسار القياسي بدون تكوين إضافي كافياً بالنسبة لنا.



لإنشاء FQDN قابل للتوجيه لـ "Hello World" (نعم ، لدى OpenShiift DNS خاص به للتوجيه حسب اسم الخدمة) ، نكشف ببساطة خدمتنا:







oc expose service quarkus-hello-world


إذا نظرت إلى المسار الذي تم إنشاؤه حديثًا ، يمكنك العثور على FQDN ومعلومات التوجيه الأخرى هناك:



oc get route








أخيرًا ، نصل إلى خدمتنا من المتصفح:







الآن كان الأمر سهلاً حقًا!



نحن نحب Kubernetes وكل ما تتيح لنا التكنولوجيا القيام به ، ونحب أيضًا البساطة والخفة. تم تصميم Kubernetes لتسهيل تشغيل الحاويات الموزعة والقابلة للتطوير بشكل لا يصدق ، لكن بساطته لم تعد كافية لطرح التطبيقات. وهنا يأتي دور OpenShift ، والذي يواكب العصر ويقدم Kubernetes ، الذي يركز بشكل أساسي على المطور. تم استثمار الكثير من الجهد لتصميم منصة OpenShift خصيصًا للمطور ، بما في ذلك إنشاء أدوات مثل S2I و ODI و Developer Portal و OpenShift Operator Framework وتكامل IDE وكتالوجات المطورين وتكامل Helm والمراقبة وغيرها الكثير.



نأمل أن تكون هذه المقالة ممتعة ومفيدة لك. ويمكنك العثور على موارد إضافية ومواد وأشياء أخرى مفيدة للتطوير على منصة OpenShift على بوابة مطوري Red Hat .



All Articles