اس بلاگ پر سب کو ہیلو! یہ اس سلسلے کی تیسری پوسٹ ہے جس میں ہم دکھاتے ہیں کہ Red Hat OpenShift پر جدید ویب ایپلیکیشنز کو کیسے تعینات کیا جائے۔
پچھلی دو پوسٹس میں، ہم نے دکھایا کہ جدید ویب ایپلیکیشنز کو صرف چند مراحل میں کیسے تعینات کیا جائے اور کس طرح ایک نئی S2I امیج کے ساتھ آف دی شیلف HTTP سرور امیج، جیسے کہ NGINX، پروڈکشن کی تعیناتیوں کو آرکیسٹریٹ کرنے کے لیے زنجیروں والی تعمیرات کا استعمال کیا جائے۔ .
آج ہم دکھائیں گے کہ اوپن شفٹ پلیٹ فارم پر آپ کی ایپلیکیشن کے لیے ڈویلپمنٹ سرور کیسے چلایا جائے اور اسے مقامی فائل سسٹم کے ساتھ ہم آہنگ کیا جائے، اور اس بارے میں بھی بات کریں گے کہ اوپن شفٹ پائپ لائنز کیا ہیں اور انہیں منسلک اسمبلیوں کے متبادل کے طور پر کیسے استعمال کیا جا سکتا ہے۔
ایک ترقیاتی ماحول کے طور پر اوپن شفٹ
ترقیاتی کام کا بہاؤ
جیسا کہ پہلے ہی بیان کیا گیا ہے۔ ، جدید ویب ایپلیکیشنز کے لیے عام ترقی کا عمل محض ایک قسم کا "ڈویلپمنٹ سرور" ہے جو مقامی فائلوں میں ہونے والی تبدیلیوں کو ٹریک کرتا ہے۔ جب وہ واقع ہوتے ہیں، ایپلیکیشن کی تعمیر کو متحرک کیا جاتا ہے اور پھر اسے براؤزر میں اپ ڈیٹ کیا جاتا ہے۔
زیادہ تر جدید فریم ورک میں، اس طرح کا "ڈویلپمنٹ سرور" متعلقہ کمانڈ لائن ٹولز میں بنایا گیا ہے۔
مقامی مثال
سب سے پہلے، آئیے دیکھتے ہیں کہ مقامی طور پر ایپلی کیشنز چلاتے وقت یہ کیسے کام کرتا ہے۔ آئیے ایک مثال کے طور پر درخواست کو لیں۔ پچھلے مضامین سے، اگرچہ تقریباً وہی ورک فلو تصورات دیگر تمام جدید فریم ورکس میں لاگو ہوتے ہیں۔
لہذا، ہماری React مثال میں "dev server" شروع کرنے کے لیے، ہم درج ذیل کمانڈ درج کریں گے:
$ npm run start
پھر ٹرمینل ونڈو میں ہم کچھ اس طرح دیکھیں گے:
اور ہماری ایپلیکیشن ڈیفالٹ براؤزر میں کھل جائے گی:
اب، اگر ہم فائل میں تبدیلیاں کرتے ہیں، تو ایپلیکیشن کو براؤزر میں اپ ڈیٹ ہونا چاہیے۔
ٹھیک ہے، مقامی موڈ میں ترقی کے ساتھ سب کچھ واضح ہے، لیکن OpenShift پر اسے کیسے حاصل کیا جائے؟
OpenShift پر ترقیاتی سرور
اگر آپ کو یاد ہے، میں ، ہم نے S2I امیج کے نام نہاد رن فیز کو دیکھا اور دیکھا کہ بطور ڈیفالٹ، سرو ماڈیول ہماری ویب ایپلیکیشن کی خدمت کے لیے ذمہ دار ہے۔
تاہم، اگر آپ قریب سے نظر آتے ہیں اس مثال سے، اس میں $NPM_RUN ماحولیاتی متغیر ہے، جو آپ کو اپنی کمانڈ پر عمل کرنے کی اجازت دیتا ہے۔
مثال کے طور پر، ہم اپنی ایپلیکیشن کو تعینات کرنے کے لیے نوڈ شفٹ ماڈیول استعمال کر سکتے ہیں:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
نوٹ: اوپر دی گئی مثال کو عام خیال کو واضح کرنے کے لیے مختصر کیا گیا ہے۔
یہاں ہم نے اپنی تعیناتی میں NPM_RUN ماحولیاتی متغیر شامل کیا ہے، جو یارن اسٹارٹ کمانڈ کو چلانے کے لیے رن ٹائم بتاتا ہے، جو ہمارے OpenShift پوڈ کے اندر React ڈویلپمنٹ سرور کو شروع کرتا ہے۔
اگر آپ چلتے ہوئے پوڈ کے لاگ کو دیکھیں تو یہ کچھ اس طرح نظر آئے گا:
بلاشبہ، یہ سب کچھ اس وقت تک نہیں ہوگا جب تک کہ ہم مقامی کوڈ کو کوڈ کے ساتھ ہم آہنگ نہ کر لیں، جس کی تبدیلیوں کے لیے بھی نگرانی کی جاتی ہے، لیکن یہ ریموٹ سرور پر رہتا ہے۔
ریموٹ اور لوکل کوڈ کو سنکرونائز کرنا
خوش قسمتی سے، نوڈ شفٹ آسانی سے ہم آہنگی میں مدد کر سکتا ہے، اور آپ تبدیلیوں کو ٹریک کرنے کے لیے واچ کمانڈ استعمال کر سکتے ہیں۔
لہذا جب ہم اپنی ایپلیکیشن کے لیے ڈویلپمنٹ سرور کو تعینات کرنے کے لیے کمانڈ چلاتے ہیں، تو ہم محفوظ طریقے سے درج ذیل کمانڈ کو استعمال کر سکتے ہیں:
$ 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
واچ کمانڈ oc rsync کمانڈ کے اوپر ایک خلاصہ ہے، آپ اس بارے میں مزید جان سکتے ہیں کہ یہ کیسے کام کرتا ہے۔ .
یہ React کے لیے ایک مثال تھی، لیکن بالکل وہی طریقہ دوسرے فریم ورک کے ساتھ استعمال کیا جا سکتا ہے، صرف NPM_RUN ماحولیاتی متغیر کو ضرورت کے مطابق سیٹ کریں۔
اوپن شفٹ پائپ لائنز
اس کے بعد ہم اوپن شفٹ پائپ لائنز جیسے ٹول کے بارے میں بات کریں گے اور یہ کہ اسے زنجیروں والی تعمیرات کے متبادل کے طور پر کیسے استعمال کیا جا سکتا ہے۔
اوپن شفٹ پائپ لائنز کیا ہیں؟
OpenShift Pipelines ایک کلاؤڈ-آبائی CI/CD مسلسل انضمام اور ترسیل کا نظام ہے جسے Tekton کا استعمال کرتے ہوئے پائپ لائنوں کو منظم کرنے کے لیے ڈیزائن کیا گیا ہے۔ Tekton ایک لچکدار اوپن سورس Kubernetes-آبائی CI/CD فریم ورک ہے جو آپ کو مختلف پلیٹ فارمز (Kubernetes، سرور لیس، ورچوئل مشینیں، وغیرہ) پر بنیادی پرت سے خلاصہ کرکے خودکار تعیناتی کی اجازت دیتا ہے۔
اس مضمون کو سمجھنے کے لیے پائپ لائنز کے بارے میں کچھ علم درکار ہے، اس لیے ہم پرزور مشورہ دیتے ہیں کہ آپ پہلے پڑھیں .
اپنے کام کے ماحول کو ترتیب دینا
اس مضمون میں دی گئی مثالوں کے ساتھ کھیلنے کے لیے، آپ کو پہلے اپنے کام کا ماحول تیار کرنا ہوگا:
- OpenShift 4 کلسٹر انسٹال اور کنفیگر کریں۔ ہماری مثالیں اس کے لیے CodeReady Containers (CRD) کا استعمال کرتی ہیں، جس کے لیے انسٹالیشن کی ہدایات مل سکتی ہیں۔ .
- کلسٹر کے تیار ہونے کے بعد، آپ کو اس پر پائپ لائن آپریٹر انسٹال کرنے کی ضرورت ہے۔ ڈرو مت، یہ آسان ہے، تنصیب کی ہدایات .
- ڈاؤن لوڈ کریں (tkn) .
- ایک ایسی ایپلی کیشن بنانے کے لیے Create-react-app کمانڈ لائن ٹول چلائیں جسے آپ پھر تعینات کریں گے (یہ ایک سادہ ایپلیکیشن ہے ).
- (اختیاری) مثال کی ایپلیکیشن کو مقامی طور پر npm انسٹال کے ساتھ چلانے کے لیے ریپوزٹری کو کلون کریں اور پھر npm اسٹارٹ کریں۔
ایپلیکیشن ریپوزٹری میں ایک k8s فولڈر بھی ہوگا، جس میں Kubernetes/OpenShift YAMLs ہوں گے جو ایپلیکیشن کو تعینات کرنے کے لیے استعمال ہوتے ہیں۔ ٹاسکس، کلسٹر ٹاسک، وسائل اور پائپ لائنز ہوں گے جو ہم اس میں بنائیں گے۔ .
آو شروع کریں
ہماری مثال کے لیے پہلا قدم OpenShift کلسٹر میں ایک نیا پروجیکٹ بنانا ہے۔ آئیے اس پروجیکٹ کو webapp-pipeline کہتے ہیں اور اسے درج ذیل کمانڈ سے بنائیں:
$ oc new-project webapp-pipeline
اس پروجیکٹ کا نام بعد میں کوڈ میں ظاہر ہوگا، لہذا اگر آپ اسے کچھ اور نام دینے کا فیصلہ کرتے ہیں، تو اس کے مطابق مثال کے کوڈ میں ترمیم کرنا نہ بھولیں۔ اس مقام سے شروع کرتے ہوئے، ہم اوپر سے نیچے نہیں جائیں گے، بلکہ نیچے سے اوپر جائیں گے: یعنی، ہم سب سے پہلے کنویئر کے تمام اجزاء بنائیں گے، اور اس کے بعد ہی کنویئر خود۔
تو سب سے پہلے...
کام
آئیے کچھ کام بناتے ہیں، جو اس کے بعد ہماری پائپ لائن میں ایپلیکیشن کو تعینات کرنے میں مدد کریں گے۔ پہلا کام - apply_manifests_task - ان Kubernetes وسائل (سروس، تعیناتی اور راستے) کے YAML کو لاگو کرنے کے لیے ذمہ دار ہے جو ہماری درخواست کے 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-web-app کلسٹر ٹاسک بنائیں:
$ 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
پہلے سے طے شدہ طور پر، یہ پیرامیٹر تعمیر کے برابر ہوتا ہے، جہاں React جمع شدہ مواد رکھتا ہے۔ دوسرے فریم ورک مختلف راستے استعمال کرتے ہیں، مثال کے طور پر، امبر میں یہ 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، جہاں ہماری درخواست رہتی ہے، کچھ اس طرح:
# 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
یہاں پائپ لائن ریسورس گٹ قسم کا ہے۔ پیرامز سیکشن میں یو آر ایل کلید ایک مخصوص ریپوزٹری کی طرف اشارہ کرتی ہے اور ماسٹر برانچ کی وضاحت کرتی ہے (یہ اختیاری ہے، لیکن ہم اسے مکمل ہونے کے لیے لکھتے ہیں)۔
اب ہمیں تصویر کے لیے ایک وسیلہ بنانے کی ضرورت ہے جہاں s2i-web-app ٹاسک کے نتائج محفوظ کیے جائیں گے، یہ اس طرح کیا جاتا ہے:
# 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
یہاں پائپ لائن ریسورس امیج کی قسم کا ہے، اور یو آر ایل پیرامیٹر کی قدر اندرونی اوپن شفٹ امیج رجسٹری کی طرف اشارہ کرتی ہے، خاص طور پر ویب ایپ پائپ لائن نام کی جگہ میں واقع ہے۔ اگر آپ مختلف نام کی جگہ استعمال کر رہے ہیں تو اس ترتیب کو تبدیل کرنا نہ بھولیں۔
اور آخر کار، آخری وسیلہ جس کی ہمیں ضرورت ہے وہ بھی ٹائپ امیج کا ہو گا اور یہ حتمی 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
ایک بار پھر، نوٹ کریں کہ یہ وسیلہ تصویر کو webapp-pipeline namespace میں داخلی 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-web-app ٹاسک کو انجام دینا ہوگا جو ہم نے پہلے ہی بنایا ہے:
tasks:
- name: build-web-application
taskRef:
name: s2i-web-app
kind: ClusterTask
یہ کام ان پٹ (gir resource) اور آؤٹ پٹ (built-web-application-image resource) پیرامیٹرز لیتا ہے۔ ہم اسے ایک خاص پیرامیٹر بھی پاس کرتے ہیں تاکہ یہ 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
اگلے دو کام ہماری ویب ایپلیکیشن کی k8s ڈائرکٹری میں رہنے والی سروس، روٹ اور تعیناتی YAML فائلوں کو استعمال کرنے اور نئی تصاویر بناتے وقت اس تعیناتی کو اپ ڈیٹ کرنے کے ذمہ دار ہیں۔ ہم نے مضمون کے آغاز میں ان دو کلسٹر کاموں کی وضاحت کی ہے۔
کنویئر شروع کرنا
لہذا، ہماری پائپ لائن کے تمام حصے بنائے گئے ہیں، اور ہم اسے درج ذیل کمانڈ سے چلائیں گے۔
$ tkn pipeline start build-and-deploy-react
اس مرحلے پر، کمانڈ لائن کو انٹرایکٹو طریقے سے استعمال کیا جاتا ہے اور آپ کو اس کی ہر درخواست کے جواب میں مناسب وسائل کو منتخب کرنے کی ضرورت ہے: گٹ ریسورس کے لیے، ویب ایپلیکیشن-ریپو کو منتخب کریں، پھر پہلے امیج ریسورس کے لیے، بلٹ ویب ایپلیکیشن -تصویر، اور آخر میں، دوسرے تصویری وسائل کے لیے -رن ٹائم-ویب-ایپلی کیشن-امیج:
? 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. ری ایکٹ ایپلیکیشن چلانا۔
حاصل يہ ہوا
لہذا، ہم نے دکھایا کہ اوپن شفٹ پر آپ کی ایپلیکیشن کے لیے ڈویلپمنٹ سرور کیسے چلایا جائے اور اسے مقامی فائل سسٹم کے ساتھ ہم آہنگ کیا جائے۔ ہم نے یہ بھی دیکھا کہ اوپن شفٹ پائپ لائنز کا استعمال کرتے ہوئے زنجیروں سے بنی ٹیمپلیٹ کی نقل کیسے کی جائے۔ اس مضمون کے تمام مثالی کوڈز مل سکتے ہیں۔ .
اضافی وسائل (EN)
- مفت ای بک
- پر دوسرے مضامین Red Hat ویب سائٹ پر
آئندہ ویبنارز کے اعلانات
ہم Red Hat OpenShift کنٹینر پلیٹ فارم اور Kubernetes کا استعمال کرتے ہوئے مقامی تجربے کے بارے میں جمعہ کے ویبنرز کا ایک سلسلہ شروع کر رہے ہیں:
ماخذ: www.habr.com