مرحبا بالجميع في هذه المدونة! هذه هي المقالة الثالثة في سلسلة نعرض فيها لك كيفية نشر تطبيقات الويب الحديثة على Red Hat OpenShift.
في المنشورتين السابقتين ، قمنا بتغطية كيفية نشر تطبيقات الويب الحديثة في بضع خطوات فقط وكيفية استخدام صورة S2I جديدة جنبًا إلى جنب مع صورة خادم HTTP سابقة الإنشاء مثل NGINX باستخدام عمليات إنشاء متسلسلة لتنظيم نشر الإنتاج.
سنعرض اليوم كيفية تشغيل خادم تطوير لتطبيقك على النظام الأساسي OpenShift ومزامنته مع نظام الملفات المحلي ، ونتحدث أيضًا عن ماهية خطوط OpenShift Pipelines وكيف يمكن استخدامها كبديل للتجميعات المرتبطة.
OpenShift كبيئة تطوير
سير عمل التطوير
كما ورد بالفعل في ، فإن سير عمل التطوير النموذجي لتطبيقات الويب الحديثة هو ببساطة "خادم تطوير" يتتبع التغييرات في الملفات المحلية. عند حدوثها ، يتم تشغيل إنشاء التطبيق ثم يتم تحديثه إلى المتصفح.
في معظم الأطر الحديثة ، يتم تضمين "خادم التطوير" في أدوات سطر الأوامر المناسبة.
مثال محلي
أولاً ، دعنا نرى كيف يعمل في حالة تشغيل التطبيقات محليًا. لنأخذ التطبيق كمثال. من المقالات السابقة ، على الرغم من أن نفس مفاهيم سير العمل تقريبًا تنطبق على جميع الأطر الحديثة الأخرى.
لذلك ، لبدء "خادم التطوير" في مثال React الخاص بنا ، سنكتب الأمر التالي:
$ npm run start
ثم سنرى في النافذة الطرفية شيئًا كالتالي:
وسيتم فتح تطبيقنا في المتصفح الافتراضي:
الآن ، إذا أجرينا تغييرات على الملف ، يجب أن يتم تحديث التطبيق في المتصفح.
حسنًا ، مع التطوير في الوضع المحلي ، كل شيء واضح ، ولكن كيف يتم تحقيق ذلك على OpenShift؟
خادم التطوير على OpenShift
إذا كنت تتذكر في ، قمنا بتحليل ما يسمى بمرحلة التشغيل (مرحلة التشغيل) لصورة S2I ورأينا أنه افتراضيًا ، يتم تقديم تطبيق الويب الخاص بنا بواسطة وحدة الخدمة.
ومع ذلك ، إذا ألقيت نظرة فاحصة من هذا المثال ، فإنه يحتوي على متغير البيئة $ NPM_RUN ، والذي يسمح لك بتشغيل الأمر الخاص بك.
على سبيل المثال ، يمكننا استخدام وحدة nodeshift لنشر تطبيقنا:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
ملاحظة: تم اختصار المثال أعلاه لتوضيح الفكرة العامة.
هنا ، أضفنا متغير البيئة NPM_RUN إلى عملية النشر لدينا ، والتي تخبر وقت التشغيل بتشغيل أمر بدء الغزل ، والذي يبدأ خادم تطوير React داخل جراب OpenShift الخاص بنا.
إذا نظرت إلى سجل حجرة قيد التشغيل ، فسيكون هناك شيء مثل هذا:
بالطبع ، لن يكون كل هذا شيئًا حتى نتمكن من مزامنة الكود المحلي مع الكود ، والذي يتم التحكم فيه أيضًا من أجل التغييرات ، ولكنه يعيش على خادم بعيد.
تزامن التعليمات البرمجية المحلية والبعيدة
لحسن الحظ ، يمكن أن يساعد nodeshift بسهولة في المزامنة ، ويمكنك استخدام أمر الساعة لتتبع التغييرات.
لذلك بعد تشغيل الأمر لنشر خادم التطوير لتطبيقنا ، يمكننا استخدام هذا الأمر بأمان:
$ npx nodeshift watch
نتيجة لذلك ، سيتم إجراء اتصال بجراب التشغيل الذي أنشأناه قبل ذلك بقليل ، وسيتم تنشيط مزامنة ملفاتنا المحلية مع الكتلة البعيدة ، وستبدأ مراقبة الملفات الموجودة على نظامنا المحلي من أجل التغييرات.
لذلك ، إذا قمنا الآن بتحديث ملف src / App.js ، فسيتفاعل النظام مع هذه التغييرات ، ونسخها إلى الكتلة البعيدة وبدء خادم التطوير ، الذي سيقوم بعد ذلك بتحديث تطبيقنا في المتصفح.
لإكمال الصورة ، دعنا نظهر كيف تبدو هذه الأوامر في مجملها:
$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000
$ npx nodeshift watch --strictSSL=false
أمر watch هو تجريد أعلى الأمر oc rsync ، يمكنك معرفة المزيد حول كيفية عمل ذلك .
كان هذا مثالًا على React ، ولكن يمكن استخدام نفس الطريقة بالضبط مع أطر أخرى ، ما عليك سوى تعيين متغير البيئة NPM_RUN حسب الحاجة.
فتح خطوط الأنابيب
بعد ذلك ، سنتحدث عن أداة مثل OpenShift Pipelines وكيف يمكن استخدامها كبديل للبنى المقيدة.
ما هي خطوط أنابيب OpenShift
OpenShift Pipelines عبارة عن نظام CI / CD للتكامل المستمر والتسليم قائم على السحابة لخطوط الأنابيب باستخدام Tekton. Tekton هو إطار عمل CI / CD أصلي مفتوح المصدر ومرن لـ Kubernetes يعمل على أتمتة النشر عبر منصات متعددة (Kubernetes ، بدون خادم ، أجهزة افتراضية ، إلخ) عن طريق التجريد بعيدًا عن الطبقة الأساسية.
يتطلب فهم هذه المقالة بعض المعرفة بخطوط الأنابيب ، لذلك ننصحك بشدة بالقراءة أولاً .
تهيئة بيئة العمل
للتلاعب بالأمثلة الواردة في هذه المقالة ، تحتاج أولاً إلى إعداد بيئة عمل:
- قم بتثبيت وتكوين مجموعة OpenShift 4. تستخدم أمثلةنا حاويات CodeReady (CRD) لهذا الغرض ، ويمكن العثور على إرشادات التثبيت الخاصة بها .
- بعد أن تصبح المجموعة جاهزة ، تحتاج إلى تثبيت مشغل خط الأنابيب عليها. لا تخف ، إنها سهلة ، تعليمات التثبيت .
- تحميل (تيكن) .
- قم بتشغيل أداة سطر الأوامر create-reaction-app لإنشاء تطبيق سيتم نشره بعد ذلك (هذا تطبيق بسيط ).
- (اختياري) قم بنسخ المستودع لتشغيل التطبيق النموذجي محليًا باستخدام تثبيت npm ثم بدء npm.
سيحتوي مستودع التطبيق أيضًا على مجلد k8s ، والذي سيحتوي على Kubernetes / OpenShift YAMLs المستخدمة لنشر التطبيق. ستكون هناك مهام ، و ClusterTasks ، وموارد وخطوط أنابيب سنقوم بإنشائها في هذا .
يهبط
الخطوة الأولى لمثالنا هي إنشاء مشروع جديد في مجموعة OpenShift. دعنا نسمي خط أنابيب webapp هذا المشروع وننشئه بالأمر التالي:
$ oc new-project webapp-pipeline
لاحقًا ، سيظهر اسم المشروع هذا في الكود ، لذلك إذا قررت تسميته بشيء آخر ، فلا تنس تحرير الكود من الأمثلة وفقًا لذلك. بدءًا من هذه النقطة ، لن ننتقل من أعلى إلى أسفل ، ولكن من أسفل إلى أعلى: أي ، سنقوم أولاً بإنشاء جميع مكونات الناقل ، وبعد ذلك فقط هو نفسه.
إذن ، أولاً وقبل كل شيء ...
مهام
لنقم بإنشاء بعض المهام (المهام) ، والتي ستساعد بعد ذلك في نشر التطبيق ضمن خط الأنابيب الخاص بنا. المهمة الأولى ، application_manifests_task ، هي المسؤولة عن تطبيق YAML لموارد Kubernetes (الخدمة والنشر والمسار) الموجودة في مجلد k8s لتطبيقنا. المهمة الثانية - update_deployment_task - مسؤولة عن تحديث الصورة التي تم نشرها بالفعل إلى تلك التي تم إنشاؤها بواسطة خط الأنابيب الخاص بنا.
لا تقلق إذا لم يكن واضحًا بعد. في الواقع ، هذه المهام تشبه المرافق ، وسوف ندخلها بمزيد من التفصيل لاحقًا. في الوقت الحالي ، دعنا ننشئها فقط:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml
بعد ذلك ، باستخدام الأمر tkn CLI ، تحقق من إنشاء المهام:
$ tkn task ls
NAME AGE
apply-manifests 1 minute ago
update-deployment 1 minute ago
ملاحظة: هذه مهام محلية لمشروعك الحالي.
مهام الكتلة
مهام الكتلة هي في الأساس نفس المهام فقط. أي أنها مجموعة من الخطوات التي يمكن إعادة استخدامها والتي يتم دمجها بطريقة أو بأخرى عند بدء مهمة معينة. الفرق هو أن مهمة الكتلة متاحة في كل مكان داخل الكتلة. للاطلاع على قائمة مهام المجموعة التي يتم إنشاؤها تلقائيًا عند إضافة عامل تشغيل خط أنابيب ، استخدم الأمر tkn CLI مرة أخرى:
$ tkn clustertask ls
NAME AGE
buildah 1 day ago
buildah-v0-10-0 1 day ago
jib-maven 1 day ago
kn 1 day ago
maven 1 day ago
openshift-client 1 day ago
openshift-client-v0-10-0 1 day ago
s2i 1 day ago
s2i-go 1 day ago
s2i-go-v0-10-0 1 day ago
s2i-java-11 1 day ago
s2i-java-11-v0-10-0 1 day ago
s2i-java-8 1 day ago
s2i-java-8-v0-10-0 1 day ago
s2i-nodejs 1 day ago
s2i-nodejs-v0-10-0 1 day ago
s2i-perl 1 day ago
s2i-perl-v0-10-0 1 day ago
s2i-php 1 day ago
s2i-php-v0-10-0 1 day ago
s2i-python-3 1 day ago
s2i-python-3-v0-10-0 1 day ago
s2i-ruby 1 day ago
s2i-ruby-v0-10-0 1 day ago
s2i-v0-10-0 1 day ago
لنقم الآن بإنشاء مجموعتين من المهام. الأول سينشئ صورة S2I ويرسلها إلى سجل OpenShift الداخلي ؛ والثاني هو بناء صورتنا المستندة إلى NGINX ، باستخدام التطبيق الذي أنشأناه بالفعل كمحتوى.
إنشاء وإرسال صورة
عند إنشاء المهمة الأولى ، سنكرر ما فعلناه بالفعل في المقالة السابقة حول التجميعات المرتبطة. تذكر أننا استخدمنا صورة S2I (ubi8-s2i-web-app) من أجل "إنشاء" تطبيقنا ، وانتهى بنا الأمر بصورة مخزنة في سجل OpenShift الداخلي. سنستخدم الآن صورة تطبيق الويب S2I هذه لإنشاء DockerFile لتطبيقنا ، ثم نستخدم Buildah لبناء الصورة الناتجة ودفعها إلى السجل الداخلي OpenShift ، لأن هذا هو بالضبط ما يفعله OpenShift عند نشر تطبيقاتك باستخدام NodeShift.
كيف نعرف كل هذا تسأل؟ من ، قمنا فقط بنسخها وإنهائها لأنفسنا.
لذلك ، نقوم الآن بإنشاء مهمة مجموعة تطبيقات الويب s2i:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml
لن نحلل هذا بالتفصيل ، لكننا سنتناول فقط المعلمة OUTPUT_DIR:
params:
- name: OUTPUT_DIR
description: The location of the build output directory
default: build
بشكل افتراضي ، هذه المعلمة هي build ، حيث تضع React المحتوى المبني. تستخدم الأطر الأخرى مسارات مختلفة ، على سبيل المثال في Ember هو dist. ستكون مخرجات مهمة المجموعة الأولى لدينا عبارة عن صورة تحتوي على HTML و JavaScript و CSS قمنا بجمعها.
نبني صورة على أساس NGINX
بالنسبة لمهمة المجموعة الثانية ، يجب أن تبني لنا صورة مبنية على NGINX باستخدام محتوى التطبيق الذي أنشأناه بالفعل. في الواقع ، هذا هو الجزء من القسم السابق حيث نظرنا إلى الإنشاءات المقيدة.
للقيام بذلك ، نحن - تمامًا كما هو مذكور أعلاه - ننشئ مهمة كتلة webapp-build-runtime:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml
إذا نظرت إلى الكود الخاص بمهام المجموعة هذه ، يمكنك أن ترى أنه لا يحدد مستودع Git الذي نعمل معه ، أو أسماء الصور التي نقوم بإنشائها. نحدد فقط ما نمرره بالضبط إلى Git ، أو بعض الصور حيث نريد إخراج الصورة النهائية. لهذا السبب يمكن إعادة استخدام هذه المهام المجمعة عند العمل مع تطبيقات أخرى.
ثم ننتقل برشاقة إلى النقطة التالية ...
موارد
لذلك ، نظرًا لأنه ، كما قلنا للتو ، يجب أن تكون مهام المجموعة عامة قدر الإمكان ، فنحن بحاجة إلى إنشاء الموارد التي سيتم استخدامها في المدخلات (مستودع Git) والمخرجات (الصور النهائية). المورد الأول الذي نحتاجه هو Git ، حيث يوجد تطبيقنا ، شيء من هذا القبيل:
# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: web-application-repo
spec:
type: git
params:
- name: url
value: https://github.com/nodeshift-starters/react-pipeline-example
- name: revision
value: master
هنا PipelineResource من النوع git. يشير مفتاح url في قسم المعلمات إلى مستودع معين ويقوم بتعيين الفرع الرئيسي (هذا اختياري ، لكننا نكتبه للتأكد من اكتماله).
نحتاج الآن إلى إنشاء مورد للصورة ، حيث سيتم حفظ نتائج مهمة تطبيق الويب s2i ، ويتم ذلك على النحو التالي:
# This resource is the result of running "npm run build", the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: built-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest
هنا ، PipelineResource هي صورة من النوع ، وتشير قيمة معلمة url إلى OpenShift Image Registry ، تحديدًا الموجود في مساحة اسم مسار الويب. تذكر تغيير هذا الإعداد إذا كنت تستخدم مساحة اسم مختلفة.
وأخيرًا ، سيكون المورد الأخير الذي نحتاجه أيضًا من نوع الصورة ، وستكون هذه هي صورة NGINX النهائية ، والتي سيتم استخدامها بعد ذلك أثناء النشر:
# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: runtime-web-application-image
spec:
type: image
params:
- name: url
value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest
مرة أخرى ، لاحظ أن هذا المورد يخزن الصورة في سجل OpenShift الداخلي في مساحة اسم مسار تطبيقات الويب.
لإنشاء كل هذه الموارد دفعة واحدة ، نستخدم الأمر create:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml
للتأكد من إنشاء الموارد ، يمكنك القيام بذلك:
$ tkn resource ls
خط انابيب
الآن بعد أن أصبح لدينا جميع المكونات الضرورية ، سنقوم بتجميع خط أنابيب منها عن طريق إنشائه بالأمر التالي:
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml
لكن قبل تشغيل هذا الأمر ، دعنا نلقي نظرة على هذه المكونات. الأول هو الاسم:
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
name: build-and-deploy-react
بعد ذلك ، في قسم المواصفات ، نرى إشارة إلى الموارد التي أنشأناها سابقًا:
spec:
resources:
- name: web-application-repo
type: git
- name: built-web-application-image
type: image
- name: runtime-web-application-image
type: image
ثم نقوم بإنشاء مهام لتشغيل خط الأنابيب الخاص بنا. بادئ ذي بدء ، يجب أن تنفذ مهمة تطبيق الويب s2i التي أنشأناها بالفعل:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
تأخذ هذه المهمة معلمات الإدخال (مورد gir) والإخراج (مورد صورة تطبيق ويب مدمج). نقوم أيضًا بتمرير معلمة خاصة إليه حتى لا يتحقق من TLS نظرًا لأننا نستخدم الشهادات الموقعة ذاتيًا:
resources:
inputs:
- name: source
resource: web-application-repo
outputs:
- name: image
resource: built-web-application-image
params:
- name: TLSVERIFY
value: "false"
المهمة التالية هي نفسها تقريبًا ، فقط مهمة مجموعة webapp-build-runtime التي أنشأناها بالفعل تسمى هنا:
name: build-runtime-image
taskRef:
name: webapp-build-runtime
kind: ClusterTask
كما هو الحال مع المهمة السابقة ، فإننا نمرر موردًا ، ولكنه الآن عبارة عن صورة تطبيق ويب مدمجة (ناتج مهمتنا السابقة). وفي الختام ، قمنا مرة أخرى بتعيين الصورة. نظرًا لأنه يجب تنفيذ هذه المهمة بعد المهمة السابقة ، فإننا نضيف حقل runAfter:
resources:
inputs:
- name: image
resource: built-web-application-image
outputs:
- name: image
resource: runtime-web-application-image
params:
- name: TLSVERIFY
value: "false"
runAfter:
- build-web-application
المهمتان التاليتان مسؤولتان عن تطبيق ملفات YAML للخدمة والتوجيه والنشر الموجودة في دليل k8s لتطبيق الويب الخاص بنا ، وعن تحديث هذا النشر عند إنشاء صور جديدة. قمنا بتعيين هاتين المهمتين العنقوديتين في بداية المقالة.
تشغيل خط الأنابيب
لذلك ، يتم إنشاء جميع أجزاء خط الأنابيب الخاص بنا ، وسنبدأ بالأمر التالي:
$ tkn pipeline start build-and-deploy-react
في هذه المرحلة ، يتم استخدام سطر الأوامر بشكل تفاعلي ويجب تحديد الموارد المناسبة استجابة لكل طلب من طلباته: بالنسبة لمورد git ، حدد web-application-repo ، ثم لمورد الصورة الأول ، تطبيق الويب المدمج- صورة ، وأخيرًا لمصدر الصورة الثاني - وقت التشغيل - ويب - تطبيق - صورة:
? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr
تحقق الآن من حالة خط الأنابيب باستخدام الأمر التالي:
$ tkn pipeline logs -f
بعد بدء خط الأنابيب ونشر التطبيق ، استعلم عن المسار المنشور باستخدام الأمر التالي:
$ oc get route react-pipeline-example --template='http://{{.spec.host}}'
لمزيد من الرؤية ، يمكنك رؤية خط الأنابيب الخاص بنا في وضع المطور لوحدة تحكم الويب في القسم خطوط الأنابيبكما يظهر في الشكل. 1.
رسم بياني 1. نظرة عامة على خطوط الأنابيب الجارية.
يؤدي النقر فوق خط أنابيب قيد التشغيل إلى عرض تفاصيل إضافية ، كما هو موضح في الشكل 2.
أرز. 2. معلومات إضافية عن الناقل.
بعد مزيد من التفاصيل ، يمكنك رؤية التطبيقات قيد التشغيل في العرض طبيعة الكابل، كما هو موضح في الشكل 3.
الشكل 3. جراب الجري.
يؤدي النقر فوق الدائرة الموجودة في الزاوية اليمنى العلوية من الرمز إلى فتح تطبيقنا ، كما هو موضح في الشكل 4.
أرز. 4. تطبيق React قيد التشغيل.
اختتام
لذلك ، أوضحنا كيفية تشغيل خادم تطوير لتطبيقك على OpenShift ومزامنته مع نظام الملفات المحلي. نظرنا أيضًا في كيفية محاكاة قالب بناء متسلسل باستخدام خطوط أنابيب OpenShift. يمكن العثور على جميع رموز الأمثلة من هذه المقالة .
مصادر إضافية
- كتاب إلكتروني مجاني
- مقالات أخرى على على موقع ريد هات
إعلانات الندوات القادمة
نبدأ سلسلة ندوات عبر الإنترنت يوم الجمعة حول التجربة الأصلية لاستخدام Red Hat OpenShift Container Platform و Kubernetes:
المصدر: www.habr.com