Съжалявам, OpenShift, не ви оценихме достатъчно и ви приехме за даденост

Тази публикация беше написана, защото нашите служители имаха доста разговори с клиенти относно разработването на приложения на Kubernetes и спецификата на такова разработване на OpenShift.

Обикновено започваме с тезата, че Kubernetes е просто Kubernetes, а OpenShift вече е платформа на Kubernetes, като Microsoft AKS или Amazon EKS. Всяка от тези платформи има своите предимства, насочени към определена целева аудитория. И след това разговорът вече преминава в сравнение на силните и слабите страни на конкретни платформи.

Като цяло мислехме да напишем тази публикация с изход като „Слушайте, няма значение къде изпълнявате кода, на OpenShift или на AKS, на EKS, на някои персонализирани Kubernetes, да на всеки Kubernetes (да го наречем накратко КУК) „Наистина е просто, както там, така и там.“

Тогава планирахме да вземем най-простия „Hello World“ и да го използваме, за да покажем какво е общото и какви са разликите между CMC и платформата за контейнери Red Hat OpenShift (наричана по-нататък OCP или просто OpenShift).

Въпреки това, в процеса на писане на тази публикация, осъзнахме, че толкова сме свикнали да използваме OpenShift, че просто не осъзнаваме как той се разрасна и превърна в невероятна платформа, която се превърна в много повече от просто дистрибуция на Kubernetes. Склонни сме да приемаме зрелостта и простотата на OpenShift за даденост, като същевременно пренебрегваме неговото великолепие.

Като цяло дойде времето за активно покаяние и сега ще сравним стъпка по стъпка пускането в експлоатация на нашия „Здравей свят“ на KUK и на OpenShift и ще го направим възможно най-обективно (е, освен понякога да показваме лично отношение към темата). Ако се интересувате от чисто субективно мнение по този въпрос, можете да го прочетете тук (EN). И в тази публикация ще се придържаме към фактите и само към фактите.

Клъстери

И така, нашият "Hello World" се нуждае от клъстери. Нека просто кажем "не" на всякакви публични облаци, за да не плащаме за сървъри, регистри, мрежи, трансфер на данни и т.н. Съответно, ние избираме прост клъстер с един възел Миникубе (за КУК) и Контейнери, готови за код (за клъстер OpenShift). И двете опции са наистина лесни за инсталиране, но изискват доста ресурси на вашия лаптоп.

Монтаж на КУК-е

Така че да вървим.

Стъпка 1 - Изграждане на нашето изображение на контейнер

Нека започнем с внедряването на нашия „Hello World“ в minikube. Това ще изисква:

1. 1. Инсталиран Docker.
2. 2. Инсталиран Git.
3. 3. Инсталиран Maven (всъщност този проект използва двоичен файл mvnw, така че можете да го направите без него).
4. 4. Всъщност самият източник, т.е. клонинг на хранилище github.com/gcolman/quarkus-hello-world.git

Първата стъпка е да създадете проект Quarkus. Не се страхувайте, ако никога не сте използвали Quarkus.io - лесно е. Вие просто избирате компонентите, които искате да използвате в проекта (RestEasy, Hibernate, Amazon SQS, Camel и т.н.), а след това самият Quarkus, без вашето участие, настройва maven архетипа и поставя всичко в github. Тоест, буквално едно щракване на мишката - и сте готови. Ето защо обичаме Quarkus.

Най-лесният начин да изградим нашия „Hello World“ в контейнерно изображение е да използваме разширенията quarkus-maven за Docker, които ще свършат цялата необходима работа. С появата на Quarkus това стана наистина лесно и просто: добавете разширението container-image-docker и можете да създавате изображения с maven команди.

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

И накрая, ние изграждаме нашия имидж с помощта на Maven. В резултат на това нашият изходен код се превръща в готово изображение на контейнер, което вече може да се изпълнява във времето за изпълнение на контейнера.

./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 - Изпратете нашия контейнер в хранилището за изображения на контейнери

Засега изображението, което създадохме, се съхранява локално в нашето локално контейнерно хранилище. Ако искаме да използваме това изображение в нашата KUK среда, тогава трябва да го поставим в друго хранилище. 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

С тази команда казахме на нашия COOK да създаде конфигурация за внедряване, която трябва да съдържа спецификацията на pod за нашето изображение на контейнер. Тази команда също така ще приложи тази конфигурация към нашия клъстер minikube и ще създаде внедряване, което ще изтегли изображението на нашия контейнер и ще стартира pod на клъстера.

Стъпка 5 - отворен достъп до нашата услуга

Сега, когато имаме разгърнато изображение на контейнер, е време да помислим как да конфигурираме външен достъп до тази услуга Restful, която всъщност е програмирана в нашия код.

Тук има много начини. Например, можете да използвате командата expose за автоматично създаване на подходящи компоненти на Kubernetes, като услуги и крайни точки. Всъщност това е, което ще направим, като изпълним командата expose за нашия обект за разполагане:

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

Нека се спрем за момент на опцията "-type" на командата expose.

Когато изложим и създадем компонентите, необходими за изпълнение на нашата услуга, трябва, наред с други неща, да можем да се свържем отвън с услугата hello-quarkus, която се намира в нашата софтуерно дефинирана мрежа. И параметър тип ни позволява да създаваме и свързваме неща като балансьори на натоварването, за да насочваме трафика към тази мрежа.

Например писане тип=LoadBalancer, ние автоматично инициализираме балансиращото натоварване на публичния облак, за да се свърже с нашия клъстер Kubernetes. Това, разбира се, е страхотно, но трябва да разберете, че такава конфигурация ще бъде тясно свързана с конкретен публичен облак и ще бъде по-трудно да я прехвърляте между екземпляри на Kubernetes в различни среди.

В нашия пример тип=NodePort, тоест обаждането до нашата услуга преминава през IP адреса на възела и номера на порта. Тази опция ви позволява да не използвате публични облаци, но изисква редица допълнителни стъпки. Първо, имате нужда от собствен балансьор на натоварването, така че ние ще внедрим балансиращото натоварване NGINX в нашия клъстер.

Стъпка 6 - Настройте балансьор на натоварването

minikube има редица функции на платформата, които улесняват създаването на необходимите компоненти за външен достъп, като контролери за вход. Minikube идва в комплект с входния контролер Nginx и всичко, което трябва да направим, е да го активираме и конфигурираме.

minikube addons enable ingress

Сега, само с една команда, ще създадем Nginx ingress контролер, който ще работи в нашия клъстер minikube:

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

Стъпка 7 - Настройте входа

Сега трябва да конфигурираме входния контролер на Nginx да приема hello-quarkus заявки.

И накрая, трябва да приложим тази конфигурация.

kubectl apply -f ingress.yml

Тъй като правим всичко това на нашата собствена машина, ние просто добавяме IP адреса на нашия възел към файла /etc/hosts, за да насочваме http заявките към нашия minikube към NGINX load balancer.

192.168.99.100 hello-quarkus.info

Това е всичко, сега нашата услуга minikube е достъпна отвън чрез входния контролер Nginx.

Е, това беше лесно, нали? Или не толкова?

Изпълнение на OpenShift (готови за код контейнери)

А сега нека да видим как всичко се прави на Red Hat OpenShift Container Platform (OCP).

Както в случая с minikube, избираме схема с клъстер OpenShift с един възел под формата на готови за код контейнери (CRC). Преди се наричаше minishift и беше базиран на проекта OpenShift Origin, но сега е CRC и е изграден върху OpenShift Container Platform на Red Hat.

Тук, съжалявам, не можем да не кажем: "OpenShift е страхотен!"

Първоначално мислехме да напишем, че разработката на OpenShift не се различава от разработката на Kubernetes. И всъщност това е така. Но в процеса на писане на тази публикация си спомнихме колко ненужни движения трябва да направите, когато нямате OpenShift, и затова отново е красиво. Обичаме нещата да са лесни и това, което ни вдъхнови да напишем тази публикация, е колко лесно е внедряването и изпълнението на нашия пример на OpenShift в сравнение с minikube.

Нека преминем през процеса и да видим какво трябва да направим.

Така че в примера с minikube започнахме с Docker… Чакайте, вече не се нуждаем от инсталиран Docker на машината.

И нямаме нужда от местен git.
И Мейвън не е необходим.
И не е необходимо да създавате изображение на контейнер на ръка.
И не е нужно да търсите хранилище на изображения на контейнери.
И не е необходимо да инсталирате входен контролер.
Освен това не е необходимо да конфигурирате ingress.

Разбираш ли? За да внедрим и стартираме нашето приложение на OpenShift, не е необходимо нищо от изброеното по-горе. А самият процес е следният.

Стъпка 1 – Стартиране на вашия клъстер OpenShift

Използваме готови за код контейнери от Red Hat, което по същество е същият Minikube, но само с пълен Openshift клъстер с един възел.

crc start

Стъпка 2 - Изградете и разположете приложението в клъстера OpenShift

Именно на тази стъпка простотата и удобството на OpenShift се проявяват в целия си блясък. Както при всички дистрибуции на Kubernetes, имаме много начини да стартираме приложение в клъстер. И както в случая с KUK, ние специално избираме най-простия.

OpenShift винаги е бил изграждан като платформа за изграждане и изпълнение на контейнерни приложения. Изграждането на контейнери винаги е било неразделна част от тази платформа, така че има куп допълнителни ресурси на Kubernetes за съответните задачи.

Ще използваме процеса Source 2 Image (S2I) на OpenShift, който има няколко различни начина да вземем нашия източник (код или двоични файлове) и да го превърнем в контейнеризирано изображение, което работи на клъстер OpenShift.

За това имаме нужда от две неща:

• Нашият изходен код в git хранилището
• Builder-образ, въз основа на който ще се извърши сглобяването.

Има много такива изображения, поддържани както от Red Hat, така и от общността, и ние ще използваме изображението на OpenJDK, добре, тъй като създавам Java приложение.

Можете да стартирате 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 направи следните неща:

• Създаден пакет за изграждане на услуги за всякакви неща, свързани с изграждането на приложението.
• Създадена конфигурация на OpenShift Build.
• Изтеглих изображението на компилатора във вътрешния докер регистър на OpenShift.
• Клониран „Hello World“ в локално хранилище.
• Видях, че там има maven pom и така компилирах приложението с maven.
• Създадено ново изображение на контейнер, съдържащо компилираното Java приложение, и постави това изображение във вътрешния регистър на контейнера.
• Създаде внедряване на Kubernetes със спецификации за под, услуга и т.н.
• Стартирано изображение на контейнер за разгръщане.
• Премахната сервизна компилация.

Има много в този списък, но основното е, че цялото изграждане се извършва изключително в OpenShift, вътрешният регистър на Docker е в OpenShift и процесът на изграждане създава всички компоненти на Kubernetes и ги изпълнява в клъстера.

Ако визуално наблюдавате стартирането на S2I в конзолата, можете да видите как модулът за изграждане се стартира по време на изграждането.

А сега нека да разгледаме регистрационните файлове на builder pod: първо, там можете да видите как maven върши работата си и изтегля зависимости, за да изгради нашето java приложение.

След завършване на изграждането на maven се стартира изграждането на изображението на контейнера и след това изграденото изображение се изпраща във вътрешното хранилище.

Всичко, процесът на сглобяване е завършен. Сега нека се уверим, че модулите и услугите на нашето приложение са стартирали в клъстера.

oc get service

Това е всичко. И има само един отбор. Всичко, което трябва да направим, е да изложим тази услуга за външен достъп.

Стъпка 3 - изложете услугата за достъп отвън

Както в случая с KUK, на платформата OpenShift, нашият „Hello World“ също се нуждае от рутер за насочване на външен трафик към услуга вътре в клъстера. В OpenShift това го прави много лесно. Първо, компонентът за маршрутизиране HAProxy е инсталиран в клъстера по подразбиране (може да бъде променен на същия NGINX). Второ, има специални и силно конфигурируеми ресурси, наречени Routes, които напомнят на Ingress обекти в добрия стар Kubernetes (всъщност Routes на OpenShift силно повлияха на дизайна на Ingress обекти, които сега могат да се използват в OpenShift), но за нашия "Здравей Свят", а в почти всички останали случаи стандартният маршрут е достатъчен за нас без допълнителна конфигурация.

За да създадем FQDN за маршрутизиране за „Hello World“ (да, OpenShiift има собствен DNS за маршрутизиране по имена на услуги), ние просто излагаме нашата услуга:

oc expose service quarkus-hello-world

Ако погледнете новосъздадения маршрут, тогава можете да намерите FQDN и друга информация за маршрутизиране там:

oc get route

И накрая, ние осъществяваме достъп до нашата услуга от браузъра:

Но сега беше наистина лесно!

Обичаме Kubernetes и всичко, което тази технология ви позволява да правите, и също така обичаме простотата и лекотата. Kubernetes е проектиран да направи разпределените, мащабируеми контейнери невероятно лесни за работа, но неговата простота вече не е достатъчна, за да въведе приложенията в производство днес. Това е мястото, където OpenShift влиза в игра, като е в крак с времето и предлага Kubernetes, ориентиран към разработчиците. Бяха положени много усилия, за да се адаптира платформата OpenShift специално за разработчика, включително създаването на инструменти като S2I, ODI, портал за разработчици, OpenShift Operator Framework, IDE интеграция, каталози за разработчици, интеграция на Helm, мониторинг и много други.

Надяваме се, че тази статия е била интересна и полезна за вас. И можете да намерите допълнителни ресурси, материали и други неща, полезни за разработване на платформата OpenShift на портала Разработчици на Red Hat.

Източник: www.habr.com