Овој пост е напишан затоа што нашите вработени имаа доста разговори со клиенти за развој на апликации на Kubernetes и спецификите на таквиот развој на OpenShift.
Обично започнуваме со тезата дека Kubernetes е само Kubernetes, а OpenShift е веќе Kubernetes платформа, како Microsoft AKS или Amazon EKS. Секоја од овие платформи има свои предности, насочени кон одредена целна публика. И после ова, разговорот се свртува кон споредување на силните и слабите страни на одредени платформи.
Генерално, мислевме да го напишеме овој пост со заклучок како „Слушај, не е важно каде да го извршиш кодот, на OpenShift или на AKS, на EKS, на некои сопствени Kubernetes или на кој било Kubernetes (за кратко да го наречеме КУК) „Навистина е едноставно, и таму и таму“.
Потоа планиравме да го земеме наједноставниот „Здраво свет“ и да го искористиме неговиот пример за да покажеме што е заедничко и која е разликата помеѓу KUC и Red Hat OpenShift контејнерската платформа (во натамошниот текст, OCP или едноставно OpenShift).
Меѓутоа, додека го пишувавме овој пост, сфативме дека толку долго сме биле навикнати да користиме OpenShift што едноставно не сфативме како порасна и се претвори во неверојатна платформа која стана многу повеќе од обична дистрибуција на Kubernetes. Ние тежнееме да ги земаме здраво за готово зрелоста и едноставноста на OpenShift и да ја изгубиме од вид неговата брилијантност.
Општо земено, дојде време за активно покајание и сега чекор по чекор ќе го споредиме пуштањето во работа на нашиот „Здраво свет“ на КУК и на OpenShift и тоа ќе го направиме што е можно пообјективно (добро, освен ако понекогаш покажуваме личен став кон предметот). Ако ве интересира чисто субјективно мислење за ова прашање, тогаш можете да го прочитате . И во овој пост ќе се задржиме на фактите и само на фактите.
Кластери
Значи, нашиот „Здраво свет“ бара кластери. Веднаш ќе кажеме „не“ на какви било јавни облаци, за да не плаќаме за сервери, регистри, мрежи, пренос на податоци итн. Според тоа, избираме едноставен кластер со еден јазол на (за КУК) и (за OpenShift кластерот). И двете од овие опции се навистина лесни за инсталирање, но ќе бараат доста ресурси на вашиот лаптоп.
Собрание на КУК-е
Ајде да одиме
Чекор 1 – градење на нашата слика на контејнер
Да почнеме со распоредување на нашиот „Здраво свет“ на minikube. За да го направите ова ќе ви требаат:
- 1. Докер е инсталиран.
- 2. Git е инсталиран.
- 3. Инсталиран Maven (всушност, овој проект го користи бинарниот mvnw, па можете без него).
- 4. Всушност, самиот извор, т.е. клон на складиштето
Првиот чекор е да се создаде проект Quarkus. Не плашете се ако никогаш не сте работеле со Quarkus.io - лесно е. Вие само ги избирате компонентите што сакате да ги користите во проектот (RestEasy, Hibernate, Amazon SQS, Camel итн.), а потоа самиот Quarkus, без никакво ваше учество, го конфигурира архетипот на maven и става сè на github. Тоа е, буквално еден клик на глувчето и ќе завршиш. Ова е причината зошто го сакаме Кваркус.
Најлесен начин да го изградите нашиот „Hello World“ во слика на контејнер е да ги користите екстензиите quarkus-maven за Docker, кои ќе ја завршат целата потребна работа. Со доаѓањето на Quarkus, ова стана навистина лесно и едноставно: додајте ја екстензијата контејнер-слика-докер и можете да креирате слики користејќи мавен команди.
./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 - испратете го нашиот контејнер во складиштето за слики на контејнерот
Засега, сликата што ја создадовме се чува локално, во нашето локално складирање на контејнер. Ако сакаме да ја користиме оваа слика во нашата средина COOK, тогаш таа мора да биде сместена во некое друго складиште. Kubernetes нема такви карактеристики, па затоа ќе користиме dockerhub. Затоа што, прво, тоа е бесплатно, а второ, (скоро) сите го прават тоа.
Ова е исто така многу едноставно, а се што ви треба е сметка на dockerhub.
Значи, инсталираме dockerhub и ја испраќаме нашата слика таму.
Чекор 3 - стартувајте го Kubernetes
Постојат многу начини да се состави конфигурацијата на kubernetes за да се изврши нашиот „Здраво свет“, но ние ќе го користиме наједноставниот од нив, тоа е начинот на кој сме...
Прво, да го лансираме кластерот minikube:
minikube start
Чекор 4 - распоредете ја нашата слика на контејнер
Сега треба да го конвертираме нашиот код и слика на контејнер во конфигурации на kubernetes. Со други зборови, ни треба подлога и дефиниција за распоредување што укажува на сликата на нашиот контејнер на dockerhub. Еден од најлесните начини да го направите ова е да ја извршите командата за креирање распоредување што покажува на нашата слика:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Со оваа команда му кажавме на нашиот КОО да создаде конфигурација за распоредување, која треба да ја содржи спецификацијата за подлогата за сликата на нашиот контејнер. Оваа команда исто така ќе ја примени оваа конфигурација на нашиот minikube кластер и ќе создаде распоред што ќе ја преземе сликата на нашиот контејнер и ќе го стартува подлогата во кластерот.
Чекор 5 – отворен пристап до нашата услуга
Сега кога имаме распоредена слика на контејнер, време е да размислиме како да го конфигурираме надворешниот пристап до оваа услуга Restful, која, всушност, е програмирана во нашиот код.
Тука има многу начини. На пример, можете да ја користите командата expose за автоматски да ги креирате соодветните компоненти на Kubernetes, како што се услугите и крајните точки. Всушност, ова е она што ќе го направиме со извршување на командата expose за нашиот објект за распоредување:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Ајде да одвоиме малку време да ја погледнеме опцијата „-type“ на командата expose.
Кога ги изложуваме и создаваме компонентите неопходни за извршување на нашата услуга, ние, меѓу другото, треба да можеме да се поврземе однадвор со услугата hello-quarkus, која се наоѓа во нашата софтверски дефинирана мрежа. И параметар тип ни овозможува да креираме и поврзуваме работи како што се балансирачи на оптоварување за да го насочиме сообраќајот кон оваа мрежа.
На пример, со пишување тип=LoadBalancer, автоматски обезбедуваме балансирач на оптоварување во јавниот облак за поврзување со нашиот кластер Kubernetes. Ова, се разбира, е одлично, но треба да разберете дека таквата конфигурација ќе биде строго врзана за специфичен јавен облак и ќе биде потешко да се префрли помеѓу примерите на Кубернетес во различни средини.
Во нашиот пример тип=NodePort, односно, до нашата услуга се пристапува преку IP адресата и бројот на портата на јазолот. Оваа опција ви овозможува да не користите никакви јавни облаци, но бара голем број дополнителни чекори. Прво, потребен ви е ваш сопствен балансер на оптоварување, па ние ќе го распоредиме балансерот на оптоварување NGINX во нашиот кластер.
Чекор 6 - инсталирајте баланс на оптоварување
minikube има голем број на функции на платформата кои го олеснуваат создавањето на надворешни достапни компоненти, како што се контролери за влез. Minikube доаѓа во комплет со Nginx контролер за влез, и сè што треба да направиме е да го овозможиме и конфигурираме.
minikube addons enable ingress
Сега ќе создадеме Nginx контролер за влез со само една команда, кој ќе работи во нашиот minikube кластер:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Чекор 7 – Поставување на влез
Сега треба да го конфигурираме контролорот за влез на Nginx за да прифаќа барања за hello-quarkus.
И конечно, треба да ја примениме оваа конфигурација.
kubectl apply -f ingress.yml
Бидејќи сето ова го правиме на нашиот сопствен компјутер, едноставно ја додаваме IP адресата на нашиот јазол во датотеката на домаќините /etc/ за да ги насочиме барањата http до нашиот minikube до балансерот на оптоварување NGINX.
192.168.99.100 hello-quarkus.info
Тоа е сè, сега нашата услуга minikube е достапна надворешно преку Nginx контролерот за влез.
Па, тоа беше лесно, нели? Или не толку многу?
Работи на OpenShift (контејнери подготвени за код)
Сега да видиме како сето ова е направено на Red Hat OpenShift Container Platform (OCP).
Како и кај minikube, избираме дизајн со еден јазол OpenShift кластер во форма на Code Ready Containers (CRC). Претходно се нарекуваше minishift и се базираше на проектот OpenShift Origin, но сега е CRC и изграден на OpenShift контејнерската платформа на Red Hat.
Овде, за жал, не можеме а да не кажеме: „OpenShift е прекрасно!
Првично, мислевме да напишеме дека развојот на OpenShift не се разликува од развојот на Kubernetes. И во суштина вака е. Но, во процесот на пишување на овој пост, се сетивме колку дополнителни движења треба да направите кога немате OpenShift, и затоа, повторно, тоа е прекрасно. Ние сакаме кога сè се прави лесно, и колку е лесен нашиот пример за распоредување и извршување на OpenShift во споредба со minikube е она што не поттикна да го напишеме овој пост.
Ајде да поминеме низ процесот и да видиме што треба да направиме.
Така, во примерот minikube, почнавме со Docker... Чекај, повеќе не ни треба инсталиран Docker на машината.
И не ни треба локален git.
И Мејвен не е потребен.
И не треба да креирате слика на контејнер со вашите раце.
И не мора да барате складиште на слики од контејнери.
И нема потреба да инсталирате контролер за влез.
И не треба да го конфигурирате влезот.
Разбираш, нели? За да ја распоредите и стартувате нашата апликација на OpenShift, не ви треба ништо од горенаведеното. И самиот процес изгледа вака.
Чекор 1 - Стартувајте го вашиот OpenShift кластер
Ние користиме Code Ready Containers од Red Hat, што во суштина е истиот Minikube, но само со полноправно кластер Openshift со еден јазол.
crc start
Чекор 2 – Изградете и распоредете ја апликацијата во кластерот OpenShift
На овој чекор се откриваат едноставноста и практичноста на OpenShift во сета своја слава. Како и со сите Kubernetes дистрибуции, имаме многу начини да извршиме апликација во кластер. И, како и во случајот со КУК, конкретно го избираме наједноставниот.
OpenShift отсекогаш бил изграден како платформа за креирање и водење на контејнеризирани апликации. Изградбата на контејнери отсекогаш била составен дел на оваа платформа, така што има еден тон дополнителни ресурси на Kubernetes за поврзани задачи.
Ќе го користиме процесот на OpenShift Source 2 Image (S2I), кој има неколку различни начини да го земеме нашиот извор (код или бинарни) и да го претвориме во контејнеризирана слика што работи на OpenShift кластер.
За да го направиме тоа потребни ни се две работи:
- Нашиот изворен код е во складиштето git
- Билдер слика врз основа на која ќе се изврши градбата.
Има многу такви слики што се одржуваат и од Red Hat и на ниво на заедницата, а ние ќе ја користиме сликата OpenJDK, добро, бидејќи градам Java апликација.
Можете да ја извршите структурата S2I и од графичката конзола OpenShift Developer и од командната линија. Ќе ја користиме командата за нова апликација, кажувајќи ѝ каде да ја добие сликата на градителот и нашиот изворен код.
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.
- Клониран „Здраво свет“ во локалното складиште.
- Видов дека таму има мавен пом, па ја составив апликацијата користејќи мавен.
- Создаде нова слика на контејнер што ја содржи компајлираната Java апликација и ставете ја оваа слика во внатрешниот регистар на контејнер.
- Создадено Kubernetes Deployment со спецификации за pod, услуга, итн.
- Почнав да ја распоредувам сликата на контејнерот.
- Отстранет сервисниот build-pod.
Има многу на оваа листа, но главната работа е што целата изградба се случува исклучиво во OpenShift, внатрешниот Docker регистар е внатре OpenShift, а процесот на градење ги создава сите компоненти на Kubernetes и ги извршува во кластерот.
Ако визуелно го следите стартувањето на S2I во конзолата, можете да видите како се стартува build pod кога ќе заврши изградбата.
Сега да ги погледнеме логовите на builder pod: прво, покажува како Maven ја врши својата работа и презема зависности за да ја изгради нашата Java апликација.
Откако ќе заврши изградбата на мавен, се започнува со изградбата на сликата на контејнерот, а потоа оваа изградена слика се испраќа во внатрешното складиште.
Тоа е сè, процесот на градење е завршен. Сега да се увериме дека подлогите и услугите на нашата апликација работат во кластерот.
oc get service
Тоа е се. И само еден тим. Сè што треба да направиме е да ја изложиме оваа услуга за пристап однадвор.
Чекор 3 – изложете ја услугата за пристап однадвор
Како и во случајот со KUC, на платформата OpenShift на нашиот „Hello World“ му треба и рутер за да го насочи надворешниот сообраќај кон услугата во кластерот. OpenShift го прави ова многу лесно. Прво, компонентата за рутирање HAProxy е стандардно инсталирана во кластерот (може да се смени на истиот NGINX). Второ, постојат специјални и високо приспособливи ресурси наречени Routes и тие наликуваат на Ingress објекти во старите добри Kubernetes (всушност, рутите на OpenShift во голема мера влијаеја на дизајнот на објектите Ingress, кои сега можат да се користат во OpenShift) , но за нашиот „Здраво светот“ , а во речиси сите други случаи, стандардната Route ни е доволна без дополнителна конфигурација.
За да создадеме рутирачки 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 на порталот .
Извор: www.habr.com