في المنشور السابق ، تطرقنا قليلاً إلى إمكانيات صورة أداة إنشاء S2I الجديدة (المصدر إلى الصورة) ، المصممة لبناء ونشر تطبيقات الويب الحديثة على منصة OpenShift. ثم كنا مهتمين بموضوع النشر السريع للتطبيق ، ولكننا سننظر اليوم في كيفية استخدام صورة S2I كصورة منشئ "نظيفة" ودمجها مع تجميعات OpenShift ذات الصلة.
صورة باني نظيفة
كما ذكرنا في الجزء الأول ، تحتوي معظم تطبيقات الويب الحديثة على ما يسمى بمرحلة البناء ، والتي عادةً ما تؤدي عمليات مثل نقل الشفرة ، وسلسلة ملفات متعددة ، والتصغير. تتم إضافة الملفات الناتجة - ثابت HTML و JavaScript و CSS - إلى مجلد الإخراج. يعتمد موقع هذا المجلد عادةً على أدوات البناء المستخدمة ، وبالنسبة لـ React سيكون هذا هو المجلد ./build (سنعود إلى هذا بمزيد من التفاصيل أدناه).
المصدر إلى الصورة (S2I)
لا يتعلق هذا المنشور على الإطلاق بمفهوم S2I وكيفية استخدامه (يمكنك قراءة المزيد عنه هنا ) ، ولكن من المهم أن تكون واضحًا بشأن مرحلتي هذه العملية من أجل فهم ما تقوم به صورة Web App Builder.
مرحلة التجميع
تتشابه خطوة التجميع بطبيعتها مع ما يحدث عندما تقوم بتشغيل بناء عامل ميناء وتنتهي بصورة Docker جديدة. وفقًا لذلك ، تحدث هذه المرحلة عند بدء بناء على منصة OpenShift.
في حالة صورة Web App Builder ، يكون نص التجميع مسؤولاً عن تثبيت تبعيات تطبيقك وتشغيل البنية . بشكل افتراضي ، تستخدم صورة المنشئ npm run build build ، لكن يمكن تجاوزه عبر متغير البيئة NPM_BUILD.
كما قلنا سابقًا ، يعتمد موقع التطبيق النهائي الذي تم إنشاؤه بالفعل على الأدوات التي تستخدمها. على سبيل المثال ، في حالة React ، سيكون هذا هو المجلد. / Build ، وللتطبيقات Angular ، مجلد project_name / dist. وكما هو موضح في المنشور الأخير ، يمكن تجاوز موقع دليل الإخراج ، الذي تم تعيينه للبناء افتراضيًا ، عبر متغير البيئة OUTPUT_DIR. حسنًا ، نظرًا لأن موقع مجلد الإخراج يختلف من إطار إلى آخر ، يمكنك ببساطة نسخ الإخراج الذي تم إنشاؤه إلى المجلد القياسي في الصورة ، أي / opt / apt-root / output. هذا مهم لفهم بقية هذه المقالة ، ولكن في الوقت الحالي دعونا نلقي نظرة سريعة على المرحلة التالية - مرحلة التشغيل (مرحلة التشغيل).
مرحلة التشغيل
تحدث هذه المرحلة عندما يتم إجراء استدعاء لتشغيل عامل الإرساء على صورة جديدة تم إنشاؤها أثناء مرحلة التجميع. يحدث ذلك أيضًا عند النشر على منصة OpenShift. بشكل افتراضي ، يستخدم البرنامج النصي للتشغيل وحدة الخدمة لخدمة المحتوى الثابت الموجود في دليل الإخراج القياسي أعلاه.
هذه الطريقة جيدة لنشر التطبيقات بسرعة ، ولكن لا يوصى عمومًا بتقديم محتوى ثابت بهذه الطريقة. حسنًا ، نظرًا لأننا لا نقدم سوى المحتوى الثابت فقط ، فلن تكون هناك حاجة إلى Node.js المثبت داخل صورتنا - خادم الويب يكفي.
بمعنى آخر ، نحتاج إلى شيء أثناء التجميع وآخر أثناء التنفيذ. هذا هو المكان الذي تصبح فيه الإنشاءات المقيدة في متناول اليد.
يبني بالسلاسل
وإليك ما يكتبون عن بالسلاسل يبني في وثائق OpenShift:
"يمكن ربط مجموعتين ببعضهما البعض ، أحدهما ينشئ الكيان المترجم والآخر يستضيف الكيان في صورة منفصلة تُستخدم لتشغيل هذا الكيان."
بمعنى آخر ، يمكننا استخدام صورة Web App Builder لتشغيل بنائنا ثم استخدام صورة خادم الويب NGINX لخدمة المحتوى الخاص بنا.
وبالتالي ، يمكننا استخدام صورة Web App Builder كمنشئ "خالص" ولا يزال لدينا صورة صغيرة لوقت التشغيل.
الآن دعونا نلقي نظرة على هذا بمثال محدد.
في هذا البرنامج التعليمي ، سنستخدم تطبيق React بسيطًا تم إنشاؤه باستخدام أداة سطر أوامر create-reaction-app. سيساعدنا ملف قالب OpenShift في
تجميع كل شيء معًا . دعنا نلقي نظرة فاحصة على هذا الملف ونبدأ بقسم المعلمات.
parameters:
- name: SOURCE_REPOSITORY_URL
description: The source URL for the application
displayName: Source URL
required: true
- name: SOURCE_REPOSITORY_REF
description: The branch name for the application
displayName: Source Branch
value: master
required: true
- name: SOURCE_REPOSITORY_DIR
description: The location within the source repo of the application
displayName: Source Directory
value: .
required: true
- name: OUTPUT_DIR
description: The location of the compiled static files from your web apps builder
displayName: Output Directory
value: build
required: false
كل شيء واضح هنا ، ولكن يجب الانتباه إلى المعلمة OUTPUT_DIR. بالنسبة لتطبيق React من مثالنا ، لا داعي للقلق ، نظرًا لأن React تستخدم القيمة الافتراضية كمجلد إخراج ، ولكن في حالة Angular أو أي شيء آخر ، يجب تغيير هذه المعلمة حسب الحاجة.
الآن دعونا نلقي نظرة على قسم ImageStreams.
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-builder // 1
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-runtime // 2
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: web-app-builder-runtime // 3
spec:
tags:
- name: latest
from:
kind: DockerImage
name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
kind: ImageStream
metadata:
name: nginx-image-runtime // 4
spec:
tags:
- name: latest
from:
kind: DockerImage
name: 'centos/nginx-112-centos7:latest'
ألق نظرة على الصورتين الثالثة والرابعة. يتم تعريف كلاهما على أنهما صور Docker ، ويمكنك أن ترى بوضوح من أين أتوا.
الصورة الثالثة هي web-app-builder وهي مأخوذة من nodeshift / ubi8-s2i-web-app مع علامة 10.x على Docker hub .
الرابعة هي صورة NGINX (الإصدار 1.12) مع أحدث علامة على Docker hub .
الآن دعونا نلقي نظرة على أول صورتين. كلاهما فارغان في البداية ويتم إنشاؤهما فقط في مرحلة البناء. ستكون الصورة الأولى ، منشئ تطبيقات الويب التفاعلية ، نتيجة لخطوة التجميع التي ستدمج صورة وقت تشغيل منشئ تطبيقات الويب وكودنا المصدر. لهذا وضعنا "-builder" في اسم هذه الصورة.
الصورة الثانية - وقت تشغيل تطبيق الويب - رد فعل - ستكون نتيجة الجمع بين وقت تشغيل nginx-image وبعض الملفات من صورة أداة إنشاء تطبيقات الويب. سيتم استخدام هذه الصورة أيضًا أثناء النشر وستحتوي فقط على خادم الويب و HTML و JavaScript و CSS الثابت لتطبيقنا.
مشوش؟ الآن دعنا نلقي نظرة على تكوينات البناء وستصبح أكثر وضوحًا.
هناك نوعان من تكوينات البناء في نموذجنا. ها هي الأولى ، وهي قياسية جدًا:
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-builder
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-builder:latest // 1
source: // 2
git:
uri: ${SOURCE_REPOSITORY_URL}
ref: ${SOURCE_REPOSITORY_REF}
contextDir: ${SOURCE_REPOSITORY_DIR}
type: Git
strategy:
sourceStrategy:
env:
- name: OUTPUT_DIR // 3
value: ${OUTPUT_DIR}
from:
kind: ImageStreamTag
name: web-app-builder-runtime:latest // 4
incremental: true // 5
type: Source
triggers: // 6
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- imageChange: {}
type: ImageChange
كما ترى ، يشير السطر المسمى 1 إلى أنه سيتم وضع نتيجة هذا الإصدار في نفس صورة أداة إنشاء تطبيقات الويب التفاعلية التي رأيناها سابقًا في قسم ImageStreams.
يخبرك السطر المسمى 2 من أين تحصل على الرمز. في حالتنا ، هذا هو مستودع git ، ويتم تحديد الموقع والمرجع ومجلد السياق بواسطة المعلمات التي رأيناها بالفعل أعلاه.
السطر المسمى 3 موجود بالفعل في قسم المعلمات. يضيف متغير البيئة OUTPUT_DIR ، والذي تم بناؤه في مثالنا.
يشير السطر المسمى 4 إلى استخدام صورة Web-app-builder-runtime التي رأيناها بالفعل في قسم ImageStream.
يقول السطر المسمى 5 أننا نريد استخدام بنية تدريجية إذا كانت صورة S2I تدعمها وصورة Web App Builder. عند التشغيل الأول ، بعد الانتهاء من مرحلة التجميع ، ستحفظ الصورة مجلد node_modules في ملف أرشيف. بعد ذلك ، في عمليات التشغيل اللاحقة ، ستقوم الصورة ببساطة بفك ضغط هذا المجلد لتقصير وقت الإنشاء.
وأخيرًا ، فإن الخط المسمى 6 هو مجرد عدد قليل من المشغلات بحيث يبدأ البناء تلقائيًا ، دون تدخل يدوي ، عندما يتغير شيء ما.
الكل في الكل ، هذا تكوين بناء قياسي جدًا.
الآن دعونا نلقي نظرة على تكوين البناء الثاني. إنه مشابه جدًا للأول ، لكن هناك اختلاف واحد مهم.
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-runtime
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-runtime:latest // 1
source: // 2
type: Image
images:
- from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 3
paths:
- sourcePath: /opt/app-root/output/. // 4
destinationDir: . // 5
strategy: // 6
sourceStrategy:
from:
kind: ImageStreamTag
name: nginx-image-runtime:latest
incremental: true
type: Source
triggers:
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- type: ImageChange
imageChange: {}
- type: ImageChange
imageChange:
from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 7
إذن ، التكوين الثاني للبناء هو وقت تشغيل تطبيق الويب ، ويبدأ بشكل قياسي.
السطر المسمى 1 ليس شيئًا جديدًا - إنه يقول فقط أنه يتم وضع نتيجة الإنشاء في صورة وقت تشغيل تطبيق الويب.
يشير السطر المسمى 2 ، كما في التكوين السابق ، إلى مكان الحصول على شفرة المصدر منه. لكن لاحظ أننا نقول هنا إنها تأتي من صورة. علاوة على ذلك ، من الصورة التي أنشأناها للتو - من منشئ تطبيقات الويب التفاعلية (المشار إليها في السطر المسمى 3). توجد الملفات التي نريد استخدامها داخل الصورة ويتم تحديد موقعها هناك على السطر المسمى 4 ، في حالتنا هو / opt / app-root / output /. إذا كنت تتذكر ، فهذا هو المكان الذي يتم فيه وضع الملفات التي تم إنشاؤها من نتائج إنشاء تطبيقنا.
مجلد الوجهة المحدد في السطر المسمى 5 هو مجرد الدليل الحالي (تذكر أن هذا كله يدور داخل شيء سحري يسمى OpenShift ، وليس على جهاز الكمبيوتر المحلي الخاص بك).
قسم الإستراتيجية - السطر المسمى 6 - مشابه أيضًا لتكوين البناء الأول. هذه المرة فقط سنستخدم nginx-image-runtime ، والذي رأيناه بالفعل في قسم ImageStream.
أخيرًا ، السطر المسمى 7 هو قسم المشغلات الذي يطلق هذا الإصدار في كل مرة تتغير فيها صورة منشئ تطبيقات الويب.
بخلاف ذلك ، يحتوي هذا القالب على تكوين نشر قياسي إلى حد ما ، بالإضافة إلى الأشياء التي تتعلق بالخدمات والمسارات ، لكننا لن نتطرق إلى ذلك. لاحظ أن الصورة التي سيتم نشرها هي صورة وقت تشغيل تطبيق الويب التفاعلي.
انشر التطبيق
لذلك ، بعد إلقاء نظرة على القالب ، دعنا نرى كيفية استخدامه لنشر التطبيق.
يمكننا استخدام أداة عميل OpenShift تسمى oc لنشر القالب الخاص بنا:
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f
$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app
الأمر الأول في لقطة الشاشة أعلاه هو طريقة هندسية متعمدة للعثور على القالب. / Openshiftio / application.yaml.
يقوم الأمر الثاني ببساطة بإنشاء تطبيق جديد يعتمد على هذا القالب.
بعد عمل هذه الأوامر ، سنرى أن لدينا مجموعتين:
وبالعودة إلى شاشة النظرة العامة ، سنرى إطلاق البود:
انقر على الرابط وسننتقل إلى تطبيقنا ، وهو صفحة تطبيق React الافتراضية:
ملحق 1
لمحبي Angular ، لدينا أيضًا نموذج للتطبيق .
القالب هو نفسه هنا ، باستثناء متغير OUTPUT_DIR.
الملحق 2
في هذه المقالة ، استخدمنا NGINX كخادم ويب ، ولكن من السهل جدًا استبداله بـ Apache ، فقط قم بتغيير صورة NGINX في ملف القالب إلى صورة Apache .
خاتمة
في الجزء الأول من هذه السلسلة ، أوضحنا لك كيفية نشر تطبيقات الويب الحديثة بسرعة على منصة OpenShift. درسنا اليوم ما الذي يجعل صورة تطبيق الويب وكيف يمكن دمجها مع خادم ويب خالص مثل NGINX باستخدام عمليات إنشاء متسلسلة لإنشاء بناء تطبيق أكثر استعدادًا للإنتاج. في المقالة الأخيرة التالية في هذه السلسلة ، سنوضح لك كيفية تشغيل خادم تطوير لتطبيقك على OpenShift والحفاظ على مزامنة الملفات المحلية والبعيدة.
محتويات سلسلة هذه المقالة
- الجزء 1: كيفية نشر تطبيقات الويب الحديثة في بضع خطوات فقط ؛
- الجزء 2: كيفية استخدام صورة S2I الجديدة مع صورة خادم HTTP موجودة ، على سبيل المثال ، NGINX ، باستخدام تجميعات OpenShift المرتبطة لتنظيم نشر الإنتاج ؛
- 3: OpenShift .