متاسفم، OpenShift، ما به اندازه کافی از شما قدردانی نکردیم و شما را بدیهی فرض کردیم

این پست به این دلیل نوشته شده است که کارمندان ما در مورد توسعه اپلیکیشن در Kubernetes و ویژگی های چنین توسعه ای در OpenShift صحبت های زیادی با مشتریان داشتند.

ما معمولاً با این تز شروع می کنیم که Kubernetes فقط Kubernetes است و OpenShift در حال حاضر یک پلت فرم Kubernetes است، مانند Microsoft AKS یا Amazon EKS. هر یک از این پلتفرم ها دارای مزایای خاص خود هستند که مخاطبان هدف خاصی را هدف قرار می دهند. و پس از این، گفتگو به مقایسه نقاط قوت و ضعف پلتفرم های خاص می رسد.

به طور کلی، ما فکر کردیم که این پست را با نتیجه‌گیری بنویسیم: «گوش دهید، فرقی نمی‌کند کد را کجا اجرا کنید، در OpenShift یا AKS، در EKS، در برخی Kubernetes سفارشی یا در هر Kubernetes دیگری. (برای اختصار اجازه دهید آن را KUK بنامیم) "این واقعاً ساده است، هم آنجا و هم آنجا."

سپس برنامه‌ریزی کردیم که ساده‌ترین «Hello World» را بگیریم و از مثال آن برای نشان دادن آنچه رایج است و تفاوت بین KUC و Red Hat OpenShift Container Platform (از این پس OCP یا به سادگی OpenShift) استفاده کنیم.

با این حال، همانطور که این پست را نوشتیم، متوجه شدیم که برای مدت طولانی آنقدر به استفاده از OpenShift عادت کرده بودیم که به سادگی متوجه نشدیم که چگونه رشد کرده و به یک پلتفرم شگفت انگیز تبدیل شده است که بسیار بیشتر از یک توزیع Kubernetes است. ما تمایل داریم که بلوغ و سادگی OpenShift را بدیهی بدانیم و درخشندگی آن را از دست بدهیم.

به طور کلی، زمان توبه فعال فرا رسیده است، و اکنون ما گام به گام راه اندازی "Hello World" خود را در KUK و OpenShift مقایسه می کنیم و این کار را تا حد امکان عینی انجام خواهیم داد (خوب، به جز با نشان دادن گاهی اوقات نگرش شخصی به موضوع). اگر به یک نظر کاملاً ذهنی در مورد این موضوع علاقه دارید، می توانید آن را بخوانید اینجا (EN). و در این پست به حقایق و فقط حقایق پایبند خواهیم بود.

خوشه ها

بنابراین، «سلام جهان» ما به خوشه‌ها نیاز دارد. ما فوراً به هر ابر عمومی "نه" می گوییم، تا هزینه ای برای سرورها، رجیستری ها، شبکه ها، انتقال داده ها و غیره پرداخت نکنیم. بر این اساس، ما یک خوشه تک گره ساده را انتخاب می کنیم مینی کوب (برای KUK) و ظروف آماده کد (برای خوشه 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.io کار نکرده اید، نگران نباشید - آسان است. شما فقط کامپوننت هایی را که می خواهید در پروژه استفاده کنید انتخاب کنید (RestEasy، Hibernate، Amazon SQS، Camel و غیره)، و سپس خود Quarkus، بدون هیچ مشارکتی، کهن الگوی maven را پیکربندی می کند و همه چیز را روی github قرار می دهد. یعنی به معنای واقعی کلمه با یک کلیک ماوس و کار تمام است. به همین دلیل است که ما کوارکوس را دوست داریم.

ساده ترین راه برای ساختن «Hello World» ما در یک تصویر ظرف، استفاده از پسوندهای quarkus-maven برای Docker است که تمام کارهای لازم را انجام می دهد. با ظهور کوارکوس، این کار واقعاً آسان و ساده شده است: پسوند container-image-docker را اضافه کنید و می توانید با استفاده از دستورات maven تصاویر ایجاد کنید.

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

در نهایت با استفاده از Maven تصویر خود را می سازیم. در نتیجه، کد منبع ما به یک تصویر ظرف آماده تبدیل می شود که می تواند از قبل در محیط اجرای Container اجرا شود.

./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 - ظرف خود را به مخزن تصویر ظرف ارسال کنید

در حال حاضر، تصویری که ما ایجاد کردیم به صورت محلی، در ذخیره سازی کانتینر محلی ما ذخیره می شود. اگر بخواهیم از این تصویر در محیط COOK خود استفاده کنیم، باید آن را در یک مخزن دیگر قرار دهیم. Kubernetes چنین ویژگی هایی ندارد، بنابراین ما از dockerhub استفاده خواهیم کرد. زیرا اولاً رایگان است و ثانیاً (تقریباً) همه این کار را انجام می دهند.

این نیز بسیار ساده است و تنها چیزی که نیاز دارید یک حساب کاربری dockerhub است.

بنابراین، ما dockerhub را نصب کرده و تصویر خود را به آنجا ارسال می کنیم.

مرحله 3 - Kubernetes را راه اندازی کنید

راه‌های زیادی برای جمع‌آوری پیکربندی kubernetes برای اجرای «Hello World» وجود دارد، اما ما از ساده‌ترین آنها استفاده می‌کنیم، این روشی است که ما هستیم...

ابتدا، بیایید خوشه minikube را راه اندازی کنیم:

minikube start

مرحله 4 - تصویر ظرف ما را مستقر کنید

اکنون باید کد و تصویر ظرف خود را به تنظیمات kubernetes تبدیل کنیم. به عبارت دیگر، ما به یک تعریف pod و استقرار نیاز داریم که به تصویر کانتینر ما در dockerhub اشاره کند. یکی از ساده‌ترین راه‌ها برای انجام این کار این است که دستور create deployment را با اشاره به تصویر ما اجرا کنیم:

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

با این دستور به COO خود گفتیم که یک پیکربندی استقرار ایجاد کند، که باید مشخصات pod برای تصویر کانتینر ما باشد. این دستور همچنین این پیکربندی را در خوشه minikube اعمال می‌کند و یک استقرار ایجاد می‌کند که تصویر ظرف ما را دانلود کرده و غلاف را در خوشه راه‌اندازی می‌کند.

مرحله 5 - دسترسی به سرویس ما را باز کنید

اکنون که یک تصویر کانتینر مستقر شده‌ایم، وقت آن است که به نحوه پیکربندی دسترسی خارجی به این سرویس Restful فکر کنیم، که در واقع در کد ما برنامه‌ریزی شده است.

در اینجا راه های زیادی وجود دارد. برای مثال، می‌توانید از دستور expose برای ایجاد خودکار اجزای مناسب Kubernetes، مانند سرویس‌ها و نقاط پایانی استفاده کنید. در واقع، این کاری است که ما با اجرای دستور expose برای شیء استقرار خود انجام خواهیم داد:

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

بیایید لحظه ای به گزینه "-type" دستور expose نگاه کنیم.

هنگامی که اجزای لازم برای اجرای سرویس خود را در معرض دید قرار می دهیم و ایجاد می کنیم، از جمله موارد دیگر، باید بتوانیم از بیرون به سرویس hello-quarkus که در داخل شبکه تعریف شده توسط نرم افزار ما قرار دارد، متصل شویم. و پارامتر نوع به ما اجازه می دهد تا چیزهایی مانند بار متعادل کننده ها را برای هدایت ترافیک به این شبکه ایجاد و متصل کنیم.

مثلا با نوشتن type=LoadBalancer، ما به طور خودکار یک متعادل کننده بار را در ابر عمومی برای اتصال به خوشه Kubernetes خود ارائه می کنیم. البته این عالی است، اما باید بدانید که چنین پیکربندی به شدت به یک ابر عمومی خاص مرتبط است و انتقال بین نمونه های Kubernetes در محیط های مختلف دشوارتر خواهد بود.

در مثال ما type=NodePort، یعنی سرویس ما با آدرس IP و شماره پورت گره قابل دسترسی است. این گزینه به شما امکان می دهد از هیچ ابر عمومی استفاده نکنید، اما به تعدادی مرحله اضافی نیاز دارد. در مرحله اول، شما نیاز به متعادل کننده بار خود دارید، بنابراین ما متعادل کننده بار NGINX را در خوشه خود مستقر خواهیم کرد.

مرحله 6 - یک بار متعادل کننده نصب کنید

minikube دارای تعدادی عملکرد پلت فرم است که ایجاد اجزای قابل دسترسی خارجی مانند کنترل کننده های ورودی را آسان تر می کند. Minikube به همراه کنترلر ورودی Nginx ارائه می شود و تنها کاری که باید انجام دهیم این است که آن را فعال و پیکربندی کنیم.

minikube addons enable ingress

اکنون یک کنترلر ورودی Nginx را تنها با یک دستور ایجاد می کنیم که در خوشه minikube ما کار می کند:

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

مرحله 7 - راه اندازی ingress

اکنون باید کنترلر ورودی Nginx را طوری پیکربندی کنیم که درخواست‌های hello-quarkus را بپذیرد.

و در نهایت باید این پیکربندی را اعمال کنیم.

kubectl apply -f ingress.yml

از آنجایی که همه این کارها را روی رایانه خود انجام می دهیم، به سادگی آدرس IP گره خود را به فایل میزبان /etc/ اضافه می کنیم تا درخواست های http را به minikube خود به متعادل کننده بار NGINX هدایت کنیم.

192.168.99.100 hello-quarkus.info

تمام، اکنون سرویس minikube ما از طریق کنترلر ورودی Nginx به صورت خارجی قابل دسترسی است.

خوب، این آسان بود، درست است؟ یا نه آنقدر؟

در حال اجرا در OpenShift (ظروف آماده کد)

حال بیایید ببینیم که چگونه همه اینها در پلتفرم کانتینر OpenShift Red Hat (OCP) انجام می شود.

مانند minikube، ما یک طراحی خوشه OpenShift تک گره را در قالب ظروف آماده کد (CRC) انتخاب می کنیم. قبلاً minishift نام داشت و بر اساس پروژه OpenShift Origin بود، اما اکنون CRC است و بر روی پلتفرم OpenShift Container Red Hat ساخته شده است.

در اینجا، با عرض پوزش، نمی‌توانیم بگوییم: "OpenShift فوق العاده است!"

در ابتدا فکر کردیم بنویسیم که توسعه در OpenShift با توسعه در Kubernetes تفاوتی ندارد. و در اصل این طور است. اما در روند نوشتن این پست، به یاد آوردیم که وقتی OpenShift ندارید، چند حرکت اضافی باید انجام دهید، و به همین دلیل است که باز هم فوق العاده است. ما آن را دوست داریم که همه چیز به راحتی انجام شود، و اینکه مثال ما چقدر آسان است که در OpenShift در مقایسه با minikube اجرا و اجرا شود، چیزی است که ما را به نوشتن این پست ترغیب کرد.

بیایید روند را طی کنیم و ببینیم چه کاری باید انجام دهیم.

بنابراین، در مثال minikube، ما با Docker شروع کردیم... صبر کنید، دیگر نیازی به نصب Docker روی دستگاه نداریم.

و ما نیازی به گیت محلی نداریم.
و Maven مورد نیاز نیست.
و نیازی به ایجاد یک تصویر ظرف با دست ندارید.
و لازم نیست به دنبال مخزنی از تصاویر کانتینر بگردید.
و نیازی به نصب کنترلر ورودی نیست.
و نیازی به پیکربندی ingress نیز ندارید.

می فهمی، درسته؟ برای استقرار و اجرای برنامه ما در OpenShift، به هیچ یک از موارد بالا نیاز ندارید. و خود فرآیند به این شکل است.

مرحله 1 - خوشه OpenShift خود را راه اندازی کنید

ما از Code Ready Containers از Red Hat استفاده می کنیم که در اصل همان Minikube است، اما فقط با یک کلاستر Openshift تک گره کامل.

crc start

مرحله 2 - برنامه را در خوشه OpenShift بسازید و مستقر کنید

در این مرحله است که سادگی و راحتی OpenShift با شکوه تمام آشکار می شود. مانند تمام توزیع های Kubernetes، ما راه های زیادی برای اجرای یک برنامه در یک کلاستر داریم. و مانند مورد KUK، ما به طور خاص ساده ترین را انتخاب می کنیم.

OpenShift همیشه به عنوان یک پلتفرم برای ایجاد و اجرای برنامه های کانتینری ساخته شده است. ساخت کانتینر همیشه بخشی جدایی ناپذیر از این پلتفرم بوده است، بنابراین منابع اضافی Kubernetes برای کارهای مرتبط وجود دارد.

ما از فرآیند OpenShift's Source 2 Image (S2I) استفاده خواهیم کرد، که چندین راه مختلف برای گرفتن منبع ما (کد یا باینری) و تبدیل آن به یک تصویر محفظه‌ای که روی یک خوشه OpenShift اجرا می‌شود، دارد.

برای این کار به دو چیز نیاز داریم:

• کد منبع ما در مخزن git است
• تصویر سازنده که ساخت بر اساس آن انجام خواهد شد.

بسیاری از این تصاویر هم توسط Red Hat و هم در سطح جامعه نگهداری می شوند، و ما از تصویر OpenJDK استفاده خواهیم کرد، زیرا من در حال ساخت یک برنامه جاوا هستم.

می‌توانید بیلد S2I را هم از کنسول گرافیکی OpenShift Developer و هم از خط فرمان اجرا کنید. ما از دستور new-app استفاده می کنیم و به آن می گوییم که تصویر سازنده و کد منبع خود را از کجا دریافت کند.

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" در مخزن محلی کلون شد.
• من دیدم که یک maven pom در آنجا وجود دارد، بنابراین برنامه را با استفاده از maven کامپایل کردم.
• یک تصویر کانتینر جدید حاوی برنامه جاوا کامپایل شده ایجاد کرد و این تصویر را در رجیستری کانتینر داخلی قرار داد.
• ایجاد Kubernetes Deployment با مشخصات pod، سرویس و غیره.
• من شروع به استقرار تصویر ظرف کردم.
• build-pod سرویس حذف شد.

موارد زیادی در این لیست وجود دارد، اما نکته اصلی این است که کل ساخت به طور انحصاری در OpenShift اتفاق می‌افتد، رجیستری داخلی Docker در OpenShift قرار دارد و فرآیند ساخت، تمام اجزای Kubernetes را ایجاد می‌کند و آنها را در کلاستر اجرا می‌کند.

اگر به صورت بصری راه اندازی S2I را در کنسول نظارت کنید، می توانید نحوه راه اندازی build pod پس از تکمیل ساخت را مشاهده کنید.

حالا بیایید نگاهی به لاگ های builder pod بیاندازیم: اولاً، نشان می دهد که maven چگونه کار خود را انجام می دهد و وابستگی ها را برای ساخت برنامه جاوا ما دانلود می کند.

پس از تکمیل ساخت maven، ساخت تصویر کانتینر شروع می شود و سپس این تصویر ساخته شده به مخزن داخلی ارسال می شود.

همین، فرآیند ساخت کامل شده است. حالا بیایید مطمئن شویم که پادها و سرویس های برنامه ما در کلاستر اجرا می شوند.

oc get service

همین. و فقط یک تیم تنها کاری که باید انجام دهیم این است که این سرویس را برای دسترسی از خارج در معرض دید قرار دهیم.

مرحله 3 - سرویس را برای دسترسی از خارج در معرض دید قرار دهید

همانطور که در مورد KUC، در پلتفرم OpenShift، "Hello World" ما نیز به یک روتر برای هدایت ترافیک خارجی به سرویس درون خوشه نیاز دارد. OpenShift این کار را بسیار آسان می کند. اولاً، مؤلفه مسیریابی HAProxy به طور پیش فرض در خوشه نصب می شود (می توان آن را به همان NGINX تغییر داد). ثانیاً، منابع ویژه و بسیار قابل تنظیمی به نام Routes وجود دارد که یادآور اشیاء Ingress در Kubernetes خوب قدیمی است (در واقع، مسیرهای OpenShift تأثیر زیادی بر طراحی اشیاء Ingress گذاشته است که اکنون می توانند در OpenShift استفاده شوند) اما برای "Hello World" ما. و تقریباً در همه موارد دیگر، Route استاندارد بدون پیکربندی اضافی برای ما کافی است.

برای ایجاد یک 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 در پورتال پیدا کنید توسعه دهندگان کلاه قرمزی.

منبع: www.habr.com