Vabanda, OpenShift, me ei hinnanud sind piisavalt ja pidasime sind iseenesestmõistetavaks

See post on Kubernetes and OpenShift application development is a common topic in our client discussions.

We usually start by stating that Kubernetes is just Kubernetes, whereas OpenShift is a Kubernetes platform, like Microsoft AKS or Amazon EKS. Each platform has its own advantages tailored for different target audiences, and the conversation then shifts to comparing the strengths and weaknesses of specific platforms.

Overall, we considered writing this post with the conclusion that it doesn’t really matter where you run the code, whether it's on OpenShift, AKS, EKS, or any custom Kubernetes—let's call it KUK for brevity. —it's really just the same on both. Then we planned to take a simple 'Hello World' and show what is common and what the differences are between KUK and the Red Hat OpenShift Container Platform (hereafter referred to as OCP or simply OpenShift).

However, while writing this post, we realized that we've become so accustomed to using OpenShift that we don't even recognize how it has grown into an amazing platform, far beyond just being a Kubernetes distribution. We tend to take the maturity and simplicity of OpenShift for granted, overlooking its magnificence.

In summary, it’s time for some active reflection, and we will step by step compare deploying our 'Hello World' on KUK and OpenShift, doing so as objectively as possible (though we might occasionally express personal views). If you're interested in strictly subjective opinions on this matter, you can read it

here (EN). In this post, we will stick to facts and only facts. .Clusters

So, for our 'Hello World', we need clusters. Let’s say 'no' to any public clouds to avoid charges for servers, registries, networks, data transfers, etc. Therefore, we choose a simple single-node cluster on

KUK and Minikube Code Ready Containers for the OpenShift cluster. Both of these options are actually quite easy to install but will require quite a bit of resources on your laptop. Building on KUK

Step 1 – building our container image

Nii et, lähme!

Let's start by deploying our 'Hello World' on minikube. For this, we will need:

1. Docker installed.

1. 2. Git installed.
2. 2. Paigaldatud Git.
3. 3. Paigaldatud Maven (tegelikult kasutatakse selles projektis mvnw-binaari, seega saab ka ilma selleta hakkama).
4. 4. Tegelikult lähtekood, st reposti kloon github.com/gcolman/quarkus-hello-world.git

Esiteks tuleb luua Quarkus'i projekt. Ärge muretsege, kui te pole kunagi Quarkus.io saidiga töötanud – see on lihtne. Lihtsalt valige komponendid, mida soovite projektis kasutada (RestEasy, Hibernate, Amazon SQS, Camel jne), ja Quarkus seadistab maven'i arhetüübi ja laadib kõik github'i ilma teie sekkumiseta. See tähendab, et sõna otseses mõttes piisab ühest hiireklõpsust – ja kõik on valmis. Selle üle me Quarkus't armastame.

Lihtsaim viis meie 'Hello World' konteineri pildi kokkupanemiseks on kasutada quarkus-maveni laiendusi Dockerile, mis teevad kogu vajaliku töö ära. Quarkus'e tulekuga on see tõeliselt lihtne: lisage laiendus container-image-docker ja saate luua pilte maven'i käskudega.

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

Ja lõpuks, teeme meie pildi koostamise Maveniga. Tulemuseks on see, et meie lähtekood muudetakse valmis konteineripildiks, mida saab juba konteinerite käitamisruumis käivitada.

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

Nii et see ongi, nüüd saab konteinerit käivitada käsuga docker run, suunates meie teenuse porti 8080, 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, et meie teenus töötab:

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

Samm 2 – saadame meie konteineri konteineripiltide hoidlasse

Praegu hoitakse meie loodud pilti kohapeal, meie kohalikus konteinerite hoidlas. Kui tahame seda pilti kasutada oma KUBERA keskkonnas, tuleb see panna mõnda teise hoidlasse. Kubernetesis ei ole selliseid funktsioone, seega kasutame dockerhub'i. Esiteks, see on tasuta ja teiseks, (peaaegu) kõik teevad nii.

See on samuti väga lihtne, ja siin on vaja ainult dockerhub'i kontot.

Nii et loome dockerhub'i ja saadame sinna meie pildi.

Samm 3 – käivitame Kubernetes'e

On palju viise, kuidas koguda kubernetes'i konfiguratsiooni meie 'Hello World'i käivitamiseks, kuid kasutame kõige lihtsamat, sellised me oleme...

Alustuseks käivitame minikube'i klastrit:

minikube start

Samm 4 – käivitame meie konteineripildi

Nüüd peame meie koodi ja konteineripildi muutma kubernetes konfigureerimiseks. Teisisõnu, vajame pod'i ja deployment definitsiooni, mis viitavad meie konteineripildile dockerhub'is. Üks lihtsamaid viise seda teha 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äsuga palusime meie KUBEl luua deployment konfiguratsioon, mis peab sisaldama pod'i spetsifikatsiooni meie konteineripildi jaoks. See käsk rakendab samuti seda konfiguratsiooni meie minikube klastri jaoks ja loob deployment'i, mis allalaadib meie konteineripildi ja käivitab pod'i klastris.

Samm 5 – avame juurdepääsu meie teenusele

Nüüd, kui meil on käivitatud konteineripilt, on aeg mõelda, kuidas konfigureerida välise juurdepääsu sellele Restful-teenusele, mis on tegelikult meie koodis programmeeritud.

Siin on palju viise. Näiteks saame kasutada käsku expose, et automaatselt luua vastavad Kubernetes komponendid, nagu teenused ja lõpp-punktid. Just nii me teeme, käivitades käsu expose meie deployment-objekti jaoks:

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

Asetame nüüd tähelepanu expose käsu valikule „--type”.

Kui teeme expose ja loome komponendid, mis on vajalikud meie teenuse käivitamiseks, peame muu hulgas tagama, et väljastpoolt oleks võimalik ühendust saada teenusega hello-quarkus, mis asub meie tarkvara määratud võrgus. Ja parameeter type võimaldab 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 ühendada meie Kubernetes klastri. See, muidugi, on suurepärane, kuid tuleb mõista, et selline konfiguratsioon on tihedalt seotud konkreetse avaliku pilvega ja seda on keerulisem üle kanda erinevate keskkondade Kubernetes'i instance'ide vahel.

Meie näites type=NodePort, see, the request to our service is made via the node's IP address and port number. This option allows not to use any public clouds, but requires a number of additional steps. Firstly, you need your own load balancer, so we will deploy an NGINX load balancer in our cluster.

Step 6 – set up the load balancer

Minikube has a range of platform features that simplify the creation of necessary components for external access, such as ingress controllers. Minikube comes with the Nginx ingress controller, and we just need to enable and configure it.

minikube addons enable ingress

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

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

Step 7 – Configure ingress

Now we need to configure the Nginx ingress controller so that it handles requests to hello-quarkus.

And finally, we need to apply this configuration.

kubectl apply -f ingress.yml

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

192.168.99.100 hello-quarkus.info

That's it, now our minikube service is available externally through the Nginx ingress controller.

Well, that was easy, right? Or not so much?

Running on OpenShift (Code Ready Containers)

Now let's see how this is done on the Red Hat OpenShift Container Platform (OCP).

As with minikube, we choose a single-node OpenShift cluster scheme in the form of Code Ready Containers (CRC). This used to be called minishift and was based on the OpenShift Origin project, but now it's CRC and built on the Red Hat OpenShift Container Platform.

Here we cannot help but say, 'OpenShift is wonderful!'

Initially, we thought to write that development on OpenShift is no different from development on Kubernetes. And in essence, that’s true. But while writing this post, we remembered how many extra steps you have to take when you don’t have OpenShift, and hence it is, we repeat, wonderful. We love when everything is easy, and the way our example is deployed and started on OpenShift compared to minikube is what actually prompted us to write this post.

Let’s go through the process and see what we will need to do.

So, in the minikube example we started with Docker... Wait, we no longer need Docker installed on the machine.

Ja kohalik git pole meile vajalik.
Ja Maven ei ole vajalik.
Ja ei pea käsitsi konteineripilti looma.
Ja ei pea otsima mingit konteineripiltide hoidlat.
Ja ingress-kontrollerit ei pea installima.
Ja ingress'i konfigureerimine ei ole vajalik.

Te mõistate, jah? Et meie rakendust OpenShiftis käivitada, ei vaja te midagi ülalkirjeldatut. Ja kogu protsess näeb välja järgmine.

Samm 1 – Käivita oma OpenShift klaster

Kasutame Red Hati Code Ready Containers't, mis on tegelikult sama, mis Minikube, kuid täisfunktsionaalne ühe sõlmeline OpenShifti klaster.

crc start

Samm 2 – Teostame rakenduse koondamise ja käivitamise OpenShifti klastris

Just sellel sammul ilmneb OpenShifti lihtsus ja mugavus täielikult. Nagu kõigis Kubernetesi jaotustes, on meil palju viise, kuidas rakendust klastris käivitada. Ja nagu Kubernetesel, valime me spetsiaalselt kõige lihtsama.

OpenShift on alati olnud loodud konteinerirakenduste loomise ja käitamise platvormiks. Konteinerite koondamine on alati olnud selle platvormi lahutamatu osa, seetõttu on siin palju täiendavaid Kubernetesi ressursse vastavate ülesannete jaoks.

Kasutame OpenShifti Source 2 Image (S2I) protsessi, millel on mitu erinevat viisi, kuidas võtta meie lähtekood (kas kood või binaarfailid) ja muuta see konteineripildiks, mida saab käitada OpenShifti klastris.

Selleks vajame kahte asja:

• Meie lähtekood git-i hoidlas
• Builder-pilt, mille alusel koondamine toimub.

On palju selliseid pilte, mida toetavad nii Red Hat kui ka kogukond, ja me kasutame OpenJDK pilti, kuna ma koondan Java-rakendust.

S2I koondamist saab käivitada nii OpenShift Developeri graafilise liidese kaudu kui ka käsurealt. Kasutame käsku new-app, öeldes talle, 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. Samal ajal teostas S2I järgmised toimingud:

• Loodi teenuse build-pod, et tegeleda rakenduse kokkupanemisega seotud asjadega.
• Loodi OpenShifti Build konfigureerimine.
• Laaditi builder-pilt OpenShifti sisemisse docker-registrisse.
• Klooniti "Hello World" kohalikku hoidlasse.
• Nägin, et seal on maven pom, ja seetõttu kompileerisin rakenduse maven'i abil.
• Loomisin uue konteineripildi, mis sisaldas kompileeritud Java-rakendust, ja panin selle pildi sisemisse konteineriregistrisse.
• Loomisin Kubernetes'i Deployment'i pod'i, teenuse jne spetsifikatsioonidega.
• Käivitasin konteineripildi juurutamise.
• Kustutasin teenuse build-podi.

Selles nimekirjas on palju erinevaid elemente, kuid kõige tähtsam on, et kogu kogumine toimub ainult OpenShiftis, sisemine Docker-registern on OpenShiftis ja kogumisprotsess loob kõik Kubernetes'i komponendid ning käivitab need klastris.

Kui visuaalselt jälgida S2I käivitamist konsoolis, siis võib näha, kuidas build pod 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'i kogumise lõppu käivitatakse konteineripildi koostamine, ja seejärel saadetakse see kogutud pilt sisemisse hoidlasse.

Kõik, kogumisprotsess on lõpetatud. Nüüd veendume, et klastri pod'id ja teenused meie rakenduse jaoks on käivitatud.

oc get service

Nii, ja kõik. Ainult ühe käsuga. Meil jääb üle ainult see teenus avada, et sellele väljastpoolt juurde pääseda.

Samm 3 - teeme teenuse avamise välispidisele juurdepääsule

Nagu KUK-i puhul, vajab meie "Hello World" OpenShiftis ka ruuterit, et suunata välist liiklust teenusele klastri sees. OpenShiftis on see väga lihtne. Esiteks, klastri sees on vaikimisi paigaldatud HAProxy marsruutimise komponent (seda võib vahetada sama NGINX-i vastu). Teiseks, siin on spetsiaalsed ja laialdased konfigureerimisvõimalustega ressursid, mida nimetatakse Routes'iteks ja mis meenutavad Ingress-objekte vanas heades Kuberneteses ( tegelikult on OpenShift'i Routes tugevalt mõjutanud Ingress-objektide disaini, mida saab nüüd kasutada ka OpenShiftis), kuid meie "Hello World'i" jaoks, ja peaaegu kõigis teistes juhtumites, piisab meile tavalisest Route'ist ilma täiendava seadistamiseta.

Et luua "Hello World" jaoks marsruutitav FQDN (jah, OpenShiftis on nimega teenuste marsruutimiseks oma DNS), teeme lihtsalt meie teenuse avamise:

oc expose service quarkus-hello-world

Kui vaadata just loodud Route'i, siis sealt võib leida FQDN-i ja muid marsruutimisse puutuvaid andmeid:

oc get route

Ja lõpuks, pöördume oma teenuse poole brauserist:

Aga nüüd oli see tõesti lihtne!

Me armastame Kubernetesit ja kõike, mida see tehnoloogia võimaldab, samuti armastame me lihtsust ja kergust. Kubernetes loodi selleks, et muuta hajutatud ja skaleeritavate konteinerite haldamine uskumatult lihtsaks, kuid nüüd on rakenduste käivitamiseks sellest lihtsusest juba puudu. Siin tulebki mängu OpenShift, mis on ajaga kaasas käinud ja pakub Kubernetesit, mis on suunatud peamiselt arendajatele. OpenShift'i platvormi on arendajate jaoks kohandamiseks tehtud tohutult tööd, sealhulgas selliste tööriistade nagu S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-de integreerimine, arendaja kataloogid, Helm'i integreerimine, jälgimine ja palju muud.

Loodame, et see artikkel oli teile huvitav ja kasulik. Lisamaterjale, ressursse ja muid kasulikke arendusvahendeid OpenShift'i platvormil leiate portaalist Red Hat Developers.

Allikas: habr.com