Vabandust, OpenShift, me ei hinnanud sind piisavalt ja kohtlesime sind iseenesestmõistetavalt.

See post on kirjutatud, kuna meie töötajatel on olnud üsna palju vestlusi klientidega Kubernetesi ja OpenShifti rakenduste arendamise spetsiifikast.

Alustame tavaliselt väitest, et Kubernetes on lihtsalt Kubernetes, ja OpenShift on juba Kubernetes platvorm, nagu Microsoft AKS või Amazon EKS. Igal neist platvormidest on oma eelised, suunatud teatud sihtrühmale. Pärast seda vestlus suundub juba konkreetsete platvormide tugevuste ja nõrkuste võrdlemisse.

Üldiselt mõtleme kirjutada postituse, mille järeldus oleks midagi sellist, et "kuulake, pole tähtis, kus koodi käitada, kas OpenShiftis või AKS-is, EKS-is, mingisuguses kohandatud Kubernetesis, või mis tahes Kubernetesis". (lühidalt nimetame seda KUK-iks) – see on tegelikult ühtemoodi lihtne, nii seal kui ka seal.

Seejärel plaanisime võtta kõige lihtsama "Hello World" ja selle näite põhjal näidata, mis on ühist ja milles on erinevused KUKi ja Red Hat OpenShift Container Platformi (edasi, OCP või lihtsalt OpenShift) vahel.

Kirjutamise käigus oleme aru saanud, et oleme OpenShifti kasutamist niivõrd harjunud, et ei teadvusta, kui palju see on kasvanud ja muutunud imeliseks platvormiks, mis on palju rohkem kui lihtsalt Kubernetesi jaotamine. Oleme harjunud võtma OpenShifti küpsust ja lihtsust iseenesestmõistetavana, unustades selle suurepärasuse.

Nüüd on aeg aktiivseks kahetsuseks ning võrreldame samm-sammult oma "Hello World" käivitamist KUK-is ja OpenShiftis ning teeme seda võimalikult objektiivselt (vahel võib-olla väljendades isiklikku arvamust). Kui teid huvitab ainult subjektiivne arvamus, siis seda saab lugeda siit (EN). Selles postituses kinnitume ainult faktidele.

Klastrid

Seega, et meie "Hello World" töötaks, vajame klastreid. Ütleme kohe "ei" igasugustele avalikele pilvedele, et vältida serverite, registrite, võrkude, andmeedastuse jne eest maksmist. Seega valime lihtsa ühe sõlmega klastrite Minikube (KUK-i jaoks) ja Code Ready Containers (OpenShifti klastri jaoks). Mõlemad variandid on tõeliselt lihtsad seadistada, kuid nõuavad teie sülearvutil üsna palju ressursse.

Ehitus KUK-is

Nii et, hakkame pihta.

Samm 1 – kogume meie konteineripildi

Alustame sellega, et käivitame meie 'Hello World' minikubes. Selleks on vajalikud:

1. 1. Paigaldatud Docker.
2. 2. Paigaldatud Git.
3. 3. Paigaldatud Maven (tegelikult kasutatakse selle projekti puhul mvnw-binäri, seega võib selle ka jätta välja).
4. 4. Loomulikult allikas ise, st repositooriumi kloon github.com/gcolman/quarkus-hello-world.git

Esmalt tuleb luua Quarkus projekt. Ärge kartke, isegi kui te pole kunagi töötanud Quarkus.io saidiga – see on lihtne. Lihtsalt valige komponendid, mida soovite projektis kasutada (RestEasy, Hibernate, Amazon SQS, Camel jne), ja seejärel seadistab Quarkus ilma teie osaluseta maven arhetüübi ja üles laadib kõik GitHubi. See tähendab, et vajutate sõna otseses mõttes hiire ühte klikki – ja kõik on valmis. Sellepärast me armastame Quarkust.

Kõige lihtsam viis meie 'Hello World' kokku panna konteineripildiks on kasutada quarkus-maven laiendusi Dockerile, mis teevad kogu vajaliku töö ära. Quarkuse tulekuga on see tõeliselt lihtne: lisate laienduse container-image-docker ja saate luua pilte maveni käskudega.

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

Ja lõpuks kompileerime meie pildi, kasutades Mavenit. Selle tulemusena muutub meie lähtekood valmis konteineripildiks, mida saab juba konteinerite käituskeskkonnas kasutada.

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

Nüüd on see kõik — saame konteineri käivitada käsuga docker run, suunates meie teenuse pordi 8080 peale, et sellele ligi pääseda.

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

Pärast konteineri instantsi käivitamist jääb vaid kontrollida käsuga curl, kas meie teenus töötab:

Nii et kõik töötab ja see oli tõeliselt lihtne ja mugav.

Etapp 2 – saadame meie konteineri konteineripiltide registrisse

Praegu hoitakse meie loodud pilti kohalikult meie lokaalses konteinerite hoidlas. Kui soovime seda pilti oma K8s keskkonnas kasutada, tuleb see panna mõnda teise registrisse. Kuberneteses pole selliseid funktsioone, seega kasutame dockerhubi. Esiteks, see on tasuta, ja teiseks, (peaaegu) kõik teevad nii.

See on samuti väga lihtne, ja ainus, mida seal vaja, on konto dockerhubis.

Nii et loome dockerhubi konto ja saadame sinna meie pildi.

Samm 3 – käivitame Kubernetes

Kubernetesi konfiguratsiooni kogumiseks on palju viise, et käivitada meie 'Hello World', kuid kasutame neist kõige lihtsamat, kuna me oleme sellised inimesed...

Alustame minikube klastri käivitamisega:

minikube start

Samm 4 – juurutame meie konteineri pildi

Nüüd peame meie koodi ja konteineri pildi muutma Kubernetes'i konfiguratsioonideks. Teisisõnu, me vajame pod'i ja juurutamise määratlust, mis viitab meie konteineri pildile DockerHubis. Üks lihtsamaid viise selle tegemiseks on käivitada käsk create deployment, viidates meie pildile:

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

Selle käsklusega ütlesime meie KUBEt'ile, et luua juurutamisconfiguratsioon, mis peab sisaldama pod'i spetsiifikatsiooni meie konteineri pildi jaoks. See käsk rakendab ka selle konfiguratsiooni meie minikube klasstris ja loob juurutamise, mis allalaadib meie konteineri pildi ja käivitab pod'i klastri sees.

Samm 5 – avame juurdepääsu meie teenusele

Nüüd, kui meil on juurutatud konteineri pilt, on aeg mõelda, kuidas konfigureerida välisesse juurdepääsu sellele Restful-teenusele, mis on tegelikult meie koodis programmeeritud.

Siin on palju võimalusi. Näiteks saab kasutada käsklust expose, et automaatselt luua vastavad Kubernetes-komponendid, nagu teenused ja lõpp-punktid. Just nii me teeme, käivitades käskluse expose meie deployment-objekti jaoks:

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

Võtame hetkeks aja, et peatuda käsku expose valikul „--type”.

Kui teeme expose'i ja loome komponendid, mis on vajalikud meie teenuse käivitamiseks, peame muu hulgas tagama, et väljastpoolt saaks ühendust võtta teenusega hello-quarkus, mis asub meie programmipõhises võrgus. Ja parameeter type aitab meil luua ja ühendada selliseid asju nagu koormuse tasandajad, et suunata liiklust sellesse võrku.

Näiteks, määrates type=LoadBalancer, aktiveerime automaatselt koormuse tasandaja avalikus pilves, et ühenduda meie Kubernetes-klastriga. See on muidugi suurepärane, kuid tuleb aru saada, et selline konfiguratsioon on tihedalt seotud konkreetse avaliku pilvega ja seda on raskem üle kanda erinevate Kubernetes-instantide vahel erinevates keskkondades.

Meie näites type=NodePort, st. see our service using the IP address of the node and port number. This option allows us to avoid using any public clouds, but requires a number of additional steps. First of all, you need your own load balancer, which means we will deploy an NGINX load balancer in our cluster.

Step 6 – Install the load balancer

Minikube has a number of platform functions that simplify the creation of components needed for external access, such as ingress controllers. Minikube comes with the Nginx ingress controller, and all we need to do is enable and configure it.

minikube addons enable ingress

Now with just one command, I will create the Nginx ingress controller that will operate within our minikube cluster:

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

Step 7 – Configure ingress

Next, we need to configure the Nginx ingress controller to handle requests for hello-quarkus.

And finally, we need to apply this configuration.

kubectl apply -f ingress.yml

Since we're doing all this on our computer, we simply add the IP address of our node to the /etc/hosts file to direct HTTP requests to our minikube on the NGINX load balancer.

192.168.99.100 hello-quarkus.info

Nüüd on meie minikube teenus saadaval väljastpoolt Nginx'i ingress-kontrolleri kaudu.

No mis, kas see ei olnud lihtne, jah? Või mitte just eriti?

Käivitamine OpenShiftis (Code Ready Containers)

Nüüd vaatame, kuidas see kõik käib Red Hat OpenShift Container Platformil (OCP).

Nagu minikube puhul, valime ühe sõlme OpenShift klastrite skeemi Code Ready Containers (CRC) vormis. Varem tuntud kui minishift, mis põhines OpenShift Origini projektil, nüüd on see CRC ja ehitatud Red Hati OpenShift Container Platformi peale.

Siin me vabandame, et ei saa jätta ütlemata: «OpenShift on imeline!»

Alguses mõtlesime kirjutada, et OpenShiftis arendamine ei erine Kuberneteses arendamisest. Ja tegelikult on see nii. Kuid selle postituse kirjutamise ajal meenutasime, kui palju liigseid samme tuleb astuda, kui OpenShiftit pole ja seetõttu on see tõepoolest imeline. Meile meeldib, kui kõik käib lihtsalt, ja see, kui lihtsalt meie näide OpenShiftis minikube'iga võrreldes käivitub ja tööle hakkab, ajendas meid selle postituse kirjutama.

Lähme protsessist läbi ja vaatame, mida me peame tegema.

Nii et näites minikube'iga alustasime Dockeriga... Oota, meil ei ole enam vaja, et masinal oleks Docker paigaldatud.

Ja kohalikku git'i ei ole meil vaja.
Ja Maven ei ole vajalik.
Ja ei pea käsitsi konteineripilti looma.
Ja ei pea otsima mingit konteineripiltide register.
Ja ingress-kontrollerit ei ole vaja installida.
Ja ingress'i konfigureerimine ei ole samuti vajalik.

Sa said aru, jah? Et meie rakendust OpenShift'is juurutada ja käivitada, ei ole vaja mitte midagi eelnevalt mainituist. Protsess näeb välja järgmine.

Samm 1 – Käivitame oma OpenShift klastrit

Kasutame Red Hati Code Ready Containers'i, mis on põhimõtteliselt sama, mis Minikube, kuid ainult täisfunktsionaalne ühte sõlme OpenShift klaster.

crc start

Samm 2 – Teeme rakenduse kogumise ja juurutamise OpenShift klasteris

Just sellest sammust alates paistab OpenShift'i lihtsus ja mugavus täielikult silma. Nagu kõikides Kubernetes' jaotustes, on meil palju viise rakenduse käivitamiseks klastris. Ja nagu KUK-i puhul, valime me spetsiaalselt kõige lihtsama versiooni.

OpenShift on alati ehitatud konteinerirakenduste loomise ja käitamise platvormina. Konteinerite koostamine on alati olnud selle platvormi lahutamatu osa, nii et siit leiate hulga täiendavaid Kubernetes'i ressursse vastavate ülesannete jaoks.

Kasutame OpenShift'i Source 2 Image (S2I) protsessi, millel on mitmeid erinevaid viise meie lähtekoodi (näiteks koodi või binaarfailide) konteineripildiks muutmiseks, mis töötab OpenShift'i klastris.

Selleks vajame kahte asja:

• Meie lähtekood git-repositoriumis
• Builder-pilt, mille alusel toimub koostamine.

Selliseid pilte on palju, mida toetavad nii Red Hat'i jõud kui ka kogukond. Kasutame OpenJDK pilti, kuna ma kogun Java-rakendust.

S2I koostamist saab käivitada nii OpenShift Developer'i graafilisest liidesest kui ka käsurealt. Kasutame käsku new-app, määrates, kust võtta builder-pilt ja meie lähtekood.

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

Kõik, meie rakendus on loodud. Selles protsessis on S2I teinud järgmised asjad:

• Loodud teeninduslik build-pood rakenduse kogumisega seotud asjade jaoks.
• Loodud OpenShift Build konfiguratsioon.
• Laaditud builder-pilt sisemisse OpenShift docker-rekistrisse.
• Kloneeritud 'Hello World' lokaalsetesse repo.
• Nägin, et seal on maven pom, ja seetõttu kompileerisin rakenduse koos maveniga.
• Loodud uus konteineripilt, mis sisaldab kompileeritud Java rakendust, ja see pilt pandi sisemisse konteinerite registrisse.
• Loodud Kubernetes Deployment pod’i, teenuse jne spetsifikatsioonidega.
• Käivitati konteineripildi deploy.
• Kustutatud teeninduslik build-pood.

Selles nimekirjas on palju asju, aga peamine on see, et kogu kogumine toimub ainult OpenShift’is, sisemine Docker-rekistrite asub OpenShift'is ja kogumise protsess loob kõik Kubernetes komponendid ning käivitab need klastri sees.

Kui visuaalselt jälgida S2I käivitamist konsoolis, siis võib näha, kuidas build pood käivitatakse kogumise ajal.

Ja nüüd vaatame builder pod’i logisid: kõigepealt on seal näha, kuidas maven oma tööd teeb ja allalaadib sõltuvusi meie java rakenduse kogumiseks.

Pärast maven-kogumise lõpetamist käivitub konteineri pildi koostamine ja seejärel saadetakse see koostatud pilt sisemisse repositooriumisse.

Protsess on lõpetatud. Nüüd veendume, et klastris on käivitatud meie rakenduse pod'id ja teenused.

oc get service

Ja kõik. Ainult üks käsk. Meil jääb üle vaid see teenus avada, et sellele väljast ligi pääseda.

Samm 3 – avame teenuse väliseks ligipääsuks

Nagu KUK-i puhul, vajab ka meie 'Hello World' OpenShiftis ruuterit, et suunata välist liiklust teenusele klastris. OpenShiftis on see väga lihtne. Esiteks, klastris on vaikimisi seadistatud HAProxy marsruutimise komponent (seda saab muuta ka NGINX-iks). Teiseks, siin on spetsiaalsed ja laialdase konfigureerimismahuga ressursid, mida nimetatakse Routes'iks ja mis meenutavad Ingress-objekte vanas heades Kuberneteses (t tegelikult mõjutasid OpenShift'i Routes-objektid tugevalt Ingress-objektide kujundamist, mida saab nüüd kasutada ka OpenShiftis), kuid meie 'Hello World'i jaoks ja peaaegu kõigil muudel juhtudel piisab meile tavalise Route'i kasutamisest ilma täiendava seadistamiseta.

Ette luua „Hello World“ marsruutitava FQDN (jah, OpenShiftis on oma DNS teenuste nimede marsruutimiseks), teeme lihtsalt teenusele expose:

oc expose service quarkus-hello-world

Kui vaatame just loodud marsruuti, leiate sealt FQDN-i ja teised marsruudiga seotud andmed:

oc get route

Ja lõpuks, pääseme oma teenusele veebibrauserist:

Nüüd oli see tõesti lihtne!

Me armastame Kubernetes't ja kõike, mida see tehnoloogia võimaldab, samuti armastame lihtsust ja kergust. Kubernetes loodi selleks, et erakordselt lihtsustada hajutatud, skaleeritavate konteinerite haldamist, kuid rakenduste kasutusele võtmiseks ei piisa tänapäeva lihtsusest. Siin tuleb mängu OpenShift, mis on ajaga kaasas ja pakub Kubernetes't, mis on suunatud eelkõige arendajatele. OpenShift'i platvormi arendamiseks on tehtud palju tööd, sealhulgas selliste tööriistade nagu S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE integreerimine, Developer Catalogues, Helm integreerimine, monitooring ja paljud teised loomine.

Loodame, et see artikkel oli teile huvitav ja kasulik. Täiendavate ressursside, materjalide ja muude OpenShift'i platvormil arendamiseks vajalike asjade leidmiseks külastage portaali Red Hat Developers.

Allikas: habr.com