مجھے افسوس ہے، OpenShift، ہم نے آپ کی کافی تعریف نہیں کی اور آپ کو قدر کی نگاہ سے دیکھا

یہ پوسٹ اس لیے لکھی گئی کیونکہ ہمارے ملازمین نے کبرنیٹس پر ایپلیکیشن ڈویلپمنٹ اور اوپن شفٹ پر اس طرح کی ترقی کی تفصیلات کے بارے میں کلائنٹس کے ساتھ کافی بات چیت کی تھی۔

ہم عام طور پر اس تھیسس کے ساتھ شروع کرتے ہیں کہ Kubernetes صرف Kubernetes ہے، اور OpenShift پہلے سے ہی ایک Kubernetes پلیٹ فارم ہے، جیسے Microsoft AKS یا Amazon EKS۔ ان پلیٹ فارمز میں سے ہر ایک کے اپنے فوائد ہیں، جن کا مقصد ایک خاص ہدف والے سامعین کے لیے ہے۔ اور اس کے بعد گفتگو کا رخ مخصوص پلیٹ فارمز کی طاقتوں اور کمزوریوں کا موازنہ کرنے کی طرف ہوتا ہے۔

عام طور پر، ہم نے اس پوسٹ کو ایک نتیجہ کے ساتھ لکھنے کا سوچا جیسے کہ "سنیں، اس سے کوئی فرق نہیں پڑتا کہ کوڈ کہاں چلانا ہے، اوپن شفٹ پر یا AKS پر، EKS پر، کچھ حسب ضرورت کبرنیٹس پر، یا کسی بھی Kubernetes پر۔ (اختصار کے لیے آئیے اسے KUK کہتے ہیں) "یہ واقعی آسان ہے، وہاں اور وہاں دونوں۔"

پھر ہم نے آسان ترین "ہیلو ورلڈ" لینے کا منصوبہ بنایا اور اس کی مثال کو یہ دکھانے کے لیے استعمال کیا کہ عام کیا ہے اور KUC اور Red Hat OpenShift کنٹینر پلیٹ فارم (اس کے بعد، OCP یا صرف OpenShift) میں کیا فرق ہے۔

تاہم، جیسا کہ ہم نے یہ پوسٹ لکھا، ہمیں احساس ہوا کہ ہم اتنے عرصے سے OpenShift استعمال کرنے کے اتنے عادی ہو چکے ہیں کہ ہمیں یہ احساس ہی نہیں ہوا کہ یہ کیسے بڑھ گیا اور ایک حیرت انگیز پلیٹ فارم میں تبدیل ہوا جو صرف ایک Kubernetes کی تقسیم سے کہیں زیادہ بن گیا۔ ہم OpenShift کی پختگی اور سادگی کو قدر کی نگاہ سے دیکھتے ہیں، اور اس کی خوب صورتی کو کھو دیتے ہیں۔

عام طور پر، فعال توبہ کا وقت آ گیا ہے، اور اب ہم قدم بہ قدم KUK اور OpenShift پر اپنے "Hello World" کے کمیشننگ کا موازنہ کریں گے، اور ہم اسے ہر ممکن حد تک معروضی طور پر کریں گے (اچھا، سوائے اس کے کہ کبھی کبھی موضوع کے ساتھ ذاتی رویہ)۔ اگر آپ اس مسئلے پر خالصتاً موضوعی رائے میں دلچسپی رکھتے ہیں، تو آپ اسے پڑھ سکتے ہیں۔ یہاں (EN). اور اس پوسٹ میں ہم حقائق اور صرف حقائق پر قائم رہیں گے۔

کلسٹرز

لہذا، ہماری "ہیلو ورلڈ" کو کلسٹرز کی ضرورت ہے۔ ہم فوری طور پر کسی بھی عوامی بادلوں کو "نہیں" کہیں گے، تاکہ سرورز، رجسٹریوں، نیٹ ورکس، ڈیٹا ٹرانسفر وغیرہ کے لیے ادائیگی نہ کی جائے۔ اس کے مطابق، ہم ایک سادہ سنگل نوڈ کلسٹر آن کا انتخاب کرتے ہیں۔ منیکوب (KUK کے لیے) اور کوڈ کے لئے تیار کنٹینرز (اوپن شفٹ کلسٹر کے لیے)۔ یہ دونوں آپشنز انسٹال کرنا واقعی آسان ہیں، لیکن آپ کے لیپ ٹاپ پر کافی وسائل درکار ہوں گے۔

KUK-e پر اسمبلی

تو، چلتے ہیں.

مرحلہ 1 - ہمارے کنٹینر کی تصویر بنانا

آئیے اپنی "ہیلو ورلڈ" کو منی کیوب پر تعینات کرکے شروع کریں۔ ایسا کرنے کے لیے آپ کو ضرورت ہو گی:

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, etc.)، اور پھر Quarkus خود، آپ کی کسی شرکت کے بغیر، maven archetype کو ترتیب دیتا ہے اور ہر چیز کو github پر رکھتا ہے۔ یعنی، لفظی طور پر ماؤس کا ایک کلک اور آپ کا کام ہو گیا۔ یہی وجہ ہے کہ ہم کوارکس سے محبت کرتے ہیں۔

ہماری "ہیلو ورلڈ" کو کنٹینر کی تصویر میں بنانے کا سب سے آسان طریقہ یہ ہے کہ Docker کے لیے quarkus-maven کی ایکسٹینشن استعمال کی جائے، جو تمام ضروری کام کرے گی۔ Quarkus کی آمد کے ساتھ، یہ واقعی آسان اور آسان ہو گیا ہے: کنٹینر-امیج-ڈوکر ایکسٹینشن شامل کریں اور آپ میون کمانڈز کا استعمال کرتے ہوئے تصاویر بنا سکتے ہیں۔

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

آخر میں، ہم Maven کا استعمال کرتے ہوئے اپنی تصویر بناتے ہیں۔ نتیجے کے طور پر، ہمارا سورس کوڈ ایک ریڈی میڈ کنٹینر امیج میں بدل جاتا ہے جسے پہلے ہی کنٹینر رن ٹائم ماحول میں چلایا جا سکتا ہے۔

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

بس، اب آپ ڈوکر رن کمانڈ کے ساتھ کنٹینر کو شروع کر سکتے ہیں، ہماری سروس کو پورٹ 8080 پر نقشہ بنا کر اس تک رسائی حاصل کر سکتے ہیں۔

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

کنٹینر کی مثال شروع ہونے کے بعد، جو کچھ باقی ہے وہ curl کمانڈ کے ساتھ چیک کرنا ہے کہ ہماری سروس چل رہی ہے:

لہذا سب کچھ کام کرتا ہے اور یہ واقعی آسان اور آسان تھا۔

مرحلہ 2 - ہمارے کنٹینر کو کنٹینر امیج ریپوزٹری میں بھیجیں۔

ابھی کے لیے، ہم نے جو تصویر بنائی ہے وہ مقامی طور پر، ہمارے مقامی کنٹینر اسٹوریج میں محفوظ ہے۔ اگر ہم اس تصویر کو اپنے COOK ماحول میں استعمال کرنا چاہتے ہیں، تو اسے کسی دوسرے ذخیرہ میں رکھنا چاہیے۔ Kubernetes میں ایسی خصوصیات نہیں ہیں، لہذا ہم dockerhub استعمال کریں گے۔ کیونکہ، اول، یہ مفت ہے، اور دوم، (تقریباً) ہر کوئی کرتا ہے۔

یہ بھی بہت آسان ہے، اور آپ کو بس ایک dockerhub اکاؤنٹ کی ضرورت ہے۔

لہذا، ہم dockerhub انسٹال کرتے ہیں اور وہاں اپنی تصویر بھیجتے ہیں۔

مرحلہ 3 - کبرنیٹس لانچ کریں۔

ہماری "Hello World" کو چلانے کے لیے kubernetes کنفیگریشن کو اکٹھا کرنے کے بہت سے طریقے ہیں، لیکن ہم ان میں سے سب سے آسان استعمال کریں گے، یہی طریقہ ہے کہ ہم...

سب سے پہلے، آئیے منی کیوب کلسٹر شروع کریں:

minikube start

مرحلہ 4 - ہمارے کنٹینر کی تصویر لگائیں۔

اب ہمیں اپنے کوڈ اور کنٹینر امیج کو کبرنیٹس کنفیگریشن میں تبدیل کرنے کی ضرورت ہے۔ دوسرے الفاظ میں، ہمیں ایک پوڈ اور تعیناتی کی تعریف کی ضرورت ہے جو dockerhub پر ہمارے کنٹینر کی تصویر کی طرف اشارہ کرے۔ ایسا کرنے کا ایک آسان ترین طریقہ یہ ہے کہ ہماری امیج کی طرف اشارہ کرتے ہوئے create deployment کمانڈ چلائیں:

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

اس کمانڈ کے ساتھ ہم نے اپنے COO کو ایک تعیناتی کنفیگریشن بنانے کے لیے کہا، جس میں ہمارے کنٹینر امیج کے لیے پوڈ کی وضاحت ہونی چاہیے۔ یہ کمانڈ اس ترتیب کو ہمارے منی کیوب کلسٹر پر بھی لاگو کرے گا، اور ایک تعیناتی تخلیق کرے گا جو ہمارے کنٹینر کی تصویر کو ڈاؤن لوڈ کرے گا اور پوڈ کو کلسٹر میں لانچ کرے گا۔

مرحلہ 5 - ہماری سروس تک رسائی کو کھولیں۔

اب جب کہ ہمارے پاس کنٹینر کی تصویر متعین ہے، یہ سوچنے کا وقت ہے کہ اس آرام دہ سروس تک بیرونی رسائی کو کس طرح ترتیب دیا جائے، جو درحقیقت ہمارے کوڈ میں پروگرام کیا گیا ہے۔

یہاں بہت سے طریقے ہیں۔ مثال کے طور پر، آپ ایکسپوز کمانڈ کا استعمال خود بخود مناسب Kubernetes اجزاء، جیسے سروسز اور اینڈ پوائنٹس بنانے کے لیے کر سکتے ہیں۔ دراصل، ہم اپنے تعیناتی آبجیکٹ کے لیے expose کمانڈ کو عمل میں لا کر یہی کریں گے:

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

آئیے ایکسپوز کمانڈ کے "-type" آپشن کو دیکھنے کے لیے ایک لمحہ نکالیں۔

جب ہم اپنی سروس کو چلانے کے لیے ضروری اجزاء کو بے نقاب اور تخلیق کرتے ہیں، تو ہمیں، دیگر چیزوں کے ساتھ، باہر سے ہیلو کوارکس سروس سے جوڑنے کے قابل ہونے کی ضرورت ہوتی ہے، جو ہمارے سافٹ ویئر کے ذریعے طے شدہ نیٹ ورک کے اندر بیٹھتی ہے۔ اور پیرامیٹر قسم ہمیں اس نیٹ ورک پر ٹریفک کو روٹ کرنے کے لیے لوڈ بیلنسرز جیسی چیزیں بنانے اور جوڑنے کی اجازت دیتا ہے۔

مثلاً لکھ کر type=LoadBlancer، ہم اپنے Kubernetes کلسٹر سے منسلک ہونے کے لیے پبلک کلاؤڈ میں خود بخود لوڈ بیلنس فراہم کرتے ہیں۔ یہ، یقیناً، بہت اچھا ہے، لیکن آپ کو یہ سمجھنے کی ضرورت ہے کہ اس طرح کی ترتیب کو ایک مخصوص عوامی کلاؤڈ سے سختی سے جوڑا جائے گا اور مختلف ماحول میں Kubernetes مثالوں کے درمیان منتقل کرنا زیادہ مشکل ہوگا۔

ہماری مثال میں ٹائپ = نوڈ پورٹ، یعنی ہماری سروس تک نوڈ کے 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 کنٹرولر کو ترتیب دینے کی ضرورت ہے تاکہ یہ ہیلو کوارکس کی درخواستوں کو قبول کرے۔

اور آخر میں، ہمیں اس ترتیب کو لاگو کرنے کی ضرورت ہے۔

kubectl apply -f ingress.yml

چونکہ ہم یہ سب کچھ اپنے کمپیوٹر پر کر رہے ہیں، اس لیے ہم اپنے نوڈ کا آئی پی ایڈریس /etc/ میزبان فائل میں شامل کرتے ہیں تاکہ HTTP درخواستوں کو اپنے منی کیوب کو NGINX لوڈ بیلنسر میں روٹ کر سکیں۔

192.168.99.100 hello-quarkus.info

بس، اب ہماری منی کیوب سروس Nginx انگریس کنٹرولر کے ذریعے بیرونی طور پر قابل رسائی ہے۔

ٹھیک ہے، یہ آسان تھا، ٹھیک ہے؟ یا اتنا نہیں؟

OpenShift پر چل رہا ہے (کوڈ ریڈی کنٹینرز)

اب دیکھتے ہیں کہ یہ سب کچھ Red Hat OpenShift Container Platform (OCP) پر کیسے کیا جاتا ہے۔

منی کیوب کی طرح، ہم کوڈ ریڈی کنٹینرز (CRC) کی شکل میں ایک واحد نوڈ اوپن شفٹ کلسٹر ڈیزائن کا انتخاب کرتے ہیں۔ پہلے اسے minishift کہا جاتا تھا اور یہ OpenShift Origin پروجیکٹ پر مبنی تھا، لیکن اب یہ CRC ہے اور Red Hat کے OpenShift کنٹینر پلیٹ فارم پر بنایا گیا ہے۔

یہاں ہم، معذرت، مدد نہیں کر سکتے لیکن یہ کہہ سکتے ہیں: "OpenShift شاندار ہے!"

ابتدائی طور پر، ہم نے یہ لکھنے کا سوچا کہ اوپن شفٹ پر ترقی Kubernetes کی ترقی سے مختلف نہیں ہے۔ اور جوہر میں یہ اس طرح ہے. لیکن اس پوسٹ کو لکھنے کے عمل میں، ہمیں یاد آیا کہ جب آپ کے پاس OpenShift نہیں ہے تو آپ کو کتنی اضافی حرکتیں کرنی پڑتی ہیں، اور اسی لیے، ایک بار پھر، یہ شاندار ہے۔ ہم اس سے محبت کرتے ہیں جب سب کچھ آسانی سے ہو جاتا ہے، اور ہماری مثال منی کیوب کے مقابلے میں OpenShift پر تعینات کرنا اور چلانا کتنا آسان ہے اسی نے ہمیں یہ پوسٹ لکھنے پر اکسایا۔

آئیے اس عمل سے گزرتے ہیں اور دیکھتے ہیں کہ ہمیں کیا کرنے کی ضرورت ہے۔

لہذا، منی کیوب مثال میں، ہم نے Docker کے ساتھ آغاز کیا... رکو، ہمیں اب مشین پر ڈوکر انسٹال کرنے کی ضرورت نہیں ہے۔

اور ہمیں مقامی گٹ کی ضرورت نہیں ہے۔
اور ماون کی ضرورت نہیں ہے۔
اور آپ کو ہاتھ سے کنٹینر کی تصویر بنانے کی ضرورت نہیں ہے۔
اور آپ کو کنٹینر امیجز کا کوئی ذخیرہ تلاش کرنے کی ضرورت نہیں ہے۔
اور انگریس کنٹرولر کو انسٹال کرنے کی ضرورت نہیں ہے۔
اور آپ کو داخلے کو ترتیب دینے کی بھی ضرورت نہیں ہے۔

تم سمجھتے ہو نا؟ OpenShift پر ہماری ایپلیکیشن کو تعینات کرنے اور چلانے کے لیے، آپ کو مندرجہ بالا میں سے کسی کی ضرورت نہیں ہے۔ اور عمل خود اس طرح لگتا ہے۔

مرحلہ 1 – اپنا اوپن شفٹ کلسٹر لانچ کریں۔

ہم Red Hat سے کوڈ ریڈی کنٹینرز استعمال کرتے ہیں، جو کہ بنیادی طور پر ایک ہی Minikube ہے، لیکن صرف ایک مکمل سنگل نوڈ اوپن شفٹ کلسٹر کے ساتھ۔

crc start

مرحلہ 2 – ایپلیکیشن کو اوپن شفٹ کلسٹر میں بنائیں اور تعینات کریں۔

یہ اس مرحلے پر ہے کہ OpenShift کی سادگی اور سہولت اپنی پوری شان کے ساتھ ظاہر ہوتی ہے۔ جیسا کہ تمام Kubernetes ڈسٹری بیوشنز کے ساتھ، ہمارے پاس کلسٹر میں ایپلیکیشن چلانے کے بہت سے طریقے ہیں۔ اور، جیسا کہ KUK کے معاملے میں، ہم خاص طور پر سب سے آسان کا انتخاب کرتے ہیں۔

OpenShift کو ہمیشہ کنٹینرائزڈ ایپلی کیشنز بنانے اور چلانے کے لیے ایک پلیٹ فارم کے طور پر بنایا گیا ہے۔ کنٹینر کی تعمیر ہمیشہ سے اس پلیٹ فارم کا ایک لازمی حصہ رہی ہے، اس لیے متعلقہ کاموں کے لیے بہت سے اضافی Kubernetes وسائل موجود ہیں۔

ہم OpenShift کا سورس 2 امیج (S2I) عمل استعمال کریں گے، جس میں ہمارا سورس (کوڈ یا بائنریز) لینے اور اسے ایک کنٹینرائزڈ امیج میں تبدیل کرنے کے کئی مختلف طریقے ہیں جو اوپن شفٹ کلسٹر پر چلتا ہے۔

ایسا کرنے کے لیے ہمیں دو چیزوں کی ضرورت ہے:

• ہمارا سورس کوڈ گٹ ریپوزٹری میں ہے۔
• بلڈر کی تصویر جس کی بنیاد پر تعمیر کی جائے گی۔

ایسی بہت سی تصاویر ہیں جو Red Hat اور کمیونٹی کی سطح پر برقرار رکھتی ہیں، اور ہم OpenJDK امیج استعمال کریں گے، ٹھیک ہے، کیونکہ میں جاوا ایپلیکیشن بنا رہا ہوں۔

آپ S2I بلڈ کو OpenShift ڈویلپر گرافیکل کنسول اور کمانڈ لائن دونوں سے چلا سکتے ہیں۔ ہم new-app کمانڈ استعمال کریں گے، یہ بتاتے ہوئے کہ بلڈر کی تصویر اور ہمارا سورس کوڈ کہاں سے حاصل کرنا ہے۔

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

بس، ہماری درخواست بن گئی ہے۔ ایسا کرنے میں، S2I عمل نے درج ذیل کام کیے:

• ایپلی کیشن کی تعمیر سے متعلق ہر قسم کی چیزوں کے لیے ایک سروس بلڈ پوڈ بنایا۔
• OpenShift Build config کو بنایا۔
• میں نے بلڈر امیج کو اندرونی اوپن شفٹ ڈوکر رجسٹری میں ڈاؤن لوڈ کیا۔
• مقامی ذخیرہ میں "ہیلو ورلڈ" کو کلون کیا گیا۔
• میں نے دیکھا کہ وہاں ایک maven pom تھا، تو میں نے maven کا استعمال کرتے ہوئے ایپلی کیشن کو مرتب کیا۔
• مرتب کردہ جاوا ایپلیکیشن پر مشتمل ایک نئی کنٹینر امیج بنائی اور اس تصویر کو اندرونی کنٹینر رجسٹری میں ڈال دیا۔
• پوڈ، سروس وغیرہ کے لیے تصریحات کے ساتھ Kubernetes کی تعیناتی بنائی گئی۔
• میں نے کنٹینر کی تصویر لگانا شروع کر دی۔
• سروس بلڈ پوڈ کو ہٹا دیا۔

اس فہرست میں بہت کچھ ہے، لیکن اہم بات یہ ہے کہ پوری تعمیر خصوصی طور پر OpenShift کے اندر ہوتی ہے، اندرونی Docker رجسٹری OpenShift کے اندر ہوتی ہے، اور تعمیر کا عمل تمام Kubernetes اجزاء کو تخلیق کرتا ہے اور انہیں کلسٹر میں چلاتا ہے۔

اگر آپ کنسول میں S2I کے لانچ کی بصری طور پر نگرانی کرتے ہیں، تو آپ دیکھ سکتے ہیں کہ تعمیر مکمل ہونے پر بلڈ پوڈ کیسے لانچ کیا جاتا ہے۔

اب آئیے بلڈر پوڈ لاگز پر ایک نظر ڈالتے ہیں: سب سے پہلے، یہ ظاہر کرتا ہے کہ ماون اپنا کام کیسے کرتا ہے اور ہماری جاوا ایپلیکیشن بنانے کے لیے انحصار کو ڈاؤن لوڈ کرتا ہے۔

ماون کی تعمیر مکمل ہونے کے بعد، کنٹینر امیج کی تعمیر شروع ہو جاتی ہے، اور پھر یہ بلٹ امیج اندرونی ذخیرے میں بھیجی جاتی ہے۔

بس، تعمیر کا عمل مکمل ہو گیا ہے۔ اب آئیے اس بات کو یقینی بنائیں کہ ہماری ایپلیکیشن کی پوڈز اور سروسز کلسٹر میں چل رہی ہیں۔

oc get service

بس۔ اور صرف ایک ٹیم۔ ہمیں بس باہر سے رسائی کے لیے اس سروس کو سامنے لانا ہے۔

مرحلہ 3 - باہر سے رسائی کے لیے سروس کو ظاہر کریں۔

جیسا کہ KUC کے معاملے میں، OpenShift پلیٹ فارم پر ہمارے "Hello World" کو بھی کلسٹر کے اندر موجود سروس کی طرف بیرونی ٹریفک کو ڈائریکٹ کرنے کے لیے ایک روٹر کی ضرورت ہوتی ہے۔ OpenShift یہ بہت آسان بناتا ہے. سب سے پہلے، HAProxy روٹنگ کا جزو ڈیفالٹ کے طور پر کلسٹر میں انسٹال ہوتا ہے (اسے اسی NGINX میں تبدیل کیا جا سکتا ہے)۔ دوم، روٹس نامی خصوصی اور انتہائی حسب ضرورت وسائل ہیں اور وہ اچھے پرانے کبرنیٹس میں Ingress آبجیکٹ سے مشابہت رکھتے ہیں (درحقیقت، OpenShift کے روٹس نے Ingress آبجیکٹ کے ڈیزائن کو بہت متاثر کیا، جو اب OpenShift میں استعمال کیا جا سکتا ہے)، لیکن ہمارے "Hello World" کے لیے۔ اور تقریباً تمام دیگر معاملات میں، معیاری روٹ ہمارے لیے بغیر کسی اضافی ترتیب کے کافی ہے۔

"ہیلو ورلڈ" کے لیے ایک روٹیبل FQDN بنانے کے لیے (جی ہاں، سروس کے ناموں سے روٹنگ کے لیے OpenShift کا اپنا DNS ہے)، ہم صرف اپنی سروس کو بے نقاب کریں گے:

oc expose service quarkus-hello-world

اگر آپ نئے بنائے گئے روٹ کو دیکھیں تو آپ کو وہاں FQDN اور دیگر روٹنگ کی معلومات مل سکتی ہیں:

oc get route

اور آخر میں، ہم براؤزر سے اپنی سروس تک رسائی حاصل کرتے ہیں:

لیکن اب یہ واقعی آسان تھا!

ہمیں Kubernetes اور ہر وہ چیز پسند ہے جو یہ ٹیکنالوجی ہمیں کرنے کی اجازت دیتی ہے، اور ہمیں سادگی اور آسانی بھی پسند ہے۔ Kubernetes کو تقسیم شدہ، توسیع پذیر کنٹینرز کے آپریشن کو ناقابل یقین حد تک آسان بنانے کے لیے بنایا گیا تھا، لیکن اس کی سادگی آج ایپلی کیشنز کو پروڈکشن میں ڈالنے کے لیے کافی نہیں ہے۔ یہ وہ جگہ ہے جہاں OpenShift کام میں آتا ہے، وقت کے ساتھ مل کر اور Kubernetes کی پیشکش کرتا ہے، جس کا مقصد بنیادی طور پر ڈویلپر ہوتا ہے۔ OpenShift پلیٹ فارم کو خاص طور پر ڈویلپر کے لیے تیار کرنے کے لیے کافی کوششیں کی گئی ہیں، بشمول S2I، ODI، ڈیولپر پورٹل، OpenShift آپریٹر فریم ورک، IDE انٹیگریشن، ڈیولپر کیٹلاگ، ہیلم انٹیگریشن، مانیٹرنگ اور بہت سے دوسرے ٹولز کی تخلیق۔

ہم امید کرتے ہیں کہ یہ مضمون آپ کے لیے دلچسپ اور مفید تھا۔ آپ پورٹل پر OpenShift پلیٹ فارم پر ترقی کے لیے مفید اضافی وسائل، مواد اور دیگر چیزیں تلاش کر سکتے ہیں۔ ریڈ ہیٹ ڈویلپرز.

ماخذ: www.habr.com