Sajnálom, OpenShift, nem értékeltünk eléggé téged, és természetesnek vettünk.

Ez a bejegyzés azért íródott, mert munkatársaink sokat beszéltek az ügyfelekkel az alkalmazások Kubernetes-en történő fejlesztéséről és az OpenShift-en való specifikus fejlesztésről.

Általában azzal kezdjük, hogy a Kubernetes egyszerűen Kubernetes, míg az OpenShift már egy Kubernetes-alapú platform, mint például a Microsoft AKS vagy az Amazon EKS. Ezeknek a platformoknak megvannak a saját előnyeik, amelyek egyedi célközönségre irányulnak. Ezután a beszélgetés már az egyes platformok erősségeinek és gyengeségeinek összehasonlításába torkollik.

Összességében azt gondoltuk, hogy ezt a bejegyzést egy olyan következtetéssel zárjuk, mint: "Figyeljetek, mindegy, hol futtatjátok a kódot, OpenShift-en vagy AKS-en, EKS-en, bármilyen testreszabott Kubernetes-en, akármilyen Kubernetes-en" (a rövidség kedvéért hívjuk KUK-nak) – ez tényleg egyszerű, ott is, és itt is.

Ezután terveztük, hogy egy egyszerű "Hello World" példával megmutatjuk, hogy mi a közös és mi a különbség a KUK és a Red Hat OpenShift Container Platform (ezután OCP vagy egyszerűen OpenShift) között.

Azonban ennek a bejegyzésnek az írása közben rájöttünk, hogy annyira hozzászoktunk az OpenShift használatához, hogy egyszerűen nem tudjuk, mennyire megnőtt és mennyire lenyűgöző platform lett, amely már jóval túl van a pusztán Kubernetes disztribúción. Hozzászoktunk ahhoz, hogy az OpenShift érettségét és egyszerűségét természetesnek vegyük, figyelmen kívül hagyva annak nagyszerűségét.

Összességében eljött az aktív megbánás ideje, és most lépésről lépésre összehasonlítjuk a "Hello World" bevezetését a KUK-ban és az OpenShift-en, és ezt a lehető legobjektívebben tesszük (bár néha személyes véleményünket is kifejezzük a témával kapcsolatban). Ha titeket pusztán szubjektív vélemény érdekel erről, azt el lehet olvasni itt (EN). Ebben a bejegyzésben azonban a tényekre és csakis a tényekre fogunk összpontosítani.

Kluster

Tehát a "Hello World"-ünkhöz szükségünk van klaszterekre. Azonnal elmondjuk, hogy "nem" a nyilvános felhőknek, hogy ne kelljen fizetnünk a szerverekért, tárolókért, hálózatért, adatátvitelért stb. Tehát egy egyszerű egycsomópontos klasztert választunk a Minikube (KUK számára) és a Code Ready Containers (OpenShift klaszterhez). Mindkét lehetőség valóban egyszerűen telepíthető, de elég sok erőforrást igényelnek a laptopodon.

Build a KUK-en

Nos, lássuk.

1. lépés - összeállítjuk a konténerszótárunkat

Kezdjük azzal, hogy a "Hello World"-ünket a minikube-on indítjuk el. Ehhez szükséges:

1. 1. Telepített Docker.
2. 2. Telepített Git.
3. 3. Telepített Maven (tulajdonképpen ebben a projektben a mvnw bináris fájlt használjuk, így erre nincs szükség).
4. 4. Magának a forrásnak a klónja, vagyis a repository klónja github.com/gcolman/quarkus-hello-world.git

Első lépésként létre kell hozni egy Quarkus projektet. Ne ijedjetek meg, ha még soha nem dolgoztatok a Quarkus.io webhellyel – ez könnyű. Csak válasszátok ki azokat a komponenseket, amelyeket a projektben szeretnétek használni (RestEasy, Hibernate, Amazon SQS, Camel stb.), a többit pedig a Quarkus már automatikusan, a ti közreműködésetek nélkül beállítja, és mindent feltölt a githubra. Tehát szó szerint egy kattintás – és kész. Ezért szeretjük a Quarkust.

A legegyszerűbb módja a „Hello World” konténerkép létrehozásának, ha a quarkus-maven Docker kiterjesztést használjuk, amely elvégzi az összes szükséges munkát. A Quarkus bevezetésével ez valóban könnyű és egyszerű lett: hozzáadja a container-image-docker kiterjesztést, és maven parancsokkal képes képeket létrehozni.

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

És végül, a Maven segítségével összeállítjuk a képet. Ennek eredményeként a forráskódunk kész konténerképpé alakul, amely már futtatható konténeres környezetben.

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

Nos, ez igazából minden, most elindíthatjuk a konténert a docker run paranccsal, illetve átirányíthatjuk a szolgáltatásunkat a 8080-as portra, hogy elérhető legyen.

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

Miután a konténer példány elindult, csak annyit kell ellenőrizni a curl parancs segítségével, hogy a szolgáltatás működik-e:

Tehát minden rendben működik, és ez valóban könnyű és egyszerű volt.

2. lépés – elküldjük a konténert a konténerképek repository-jába

A jelenleg létrehozott kép helyben van, a helyi konténer tárolónkban. Ha ezt a képet szeretnénk használni a K8S környezetünkben, akkor egy másik repository-ba kell helyezni. A Kubernetesben nincsenek ilyen funkciók, ezért a dockerhub-ot fogjuk használni. Egyrészt mert ingyenes, másrészt pedig (majdnem) mindenki ezt csinálja.

Ez is nagyon egyszerű, és itt csak egy dockerhub fiókra van szükség.

Tehát bejelentkezünk a dockerhub-ra és feltöltjük oda a képünket.

3. lépés – elindítjuk a Kubernetest

Számos módja van a Kubernetes konfiguráció összeállításának a „Hello World” elindításához, de a legegyszerűbbet fogjuk használni, hiszen ilyenek vagyunk...

Először indítsuk el a minikube klasztert:

minikube start

4. lépés – telepítjük a konténerképünket

Most át kell alakítanunk a kódunkat és a konténerképünket Kubernetes konfigurációvá. Más szavakkal, szükségünk van egy podra és deployment definícióra, amely hivatkozik a Docker Hub-on lévő konténerképünkre. Az egyik legegyszerűbb módja ennek az, hogy végrehajtjuk a create deployment parancsot, megadva a képünket:

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

Ezzel a parancssal azt mondtuk a Kubernetes-nek, hogy hozzon létre egy deployment konfigurációt, amely tartalmazza a pod specifikációt a konténerképünkhöz. Ez a parancs ezt a konfigurációt a minikube klaszterünkre is alkalmazza, és létrehozza a deploymentet, amely letölti a konténerképünket, és elindítja a podot a klaszterben.

5. lépés – hozzáférés megnyitása a szolgáltatásunkhoz

Most, hogy van egy telepített konténerképünk, ideje elgondolkodni, hogyan konfiguráljuk a külső hozzáférést ehhez a Restful szolgáltatáshoz, amelyet valójában a kódunkban programoztunk.

Itt sok lehetőség van. Például használhatjuk az expose parancsot, hogy automatikusan létrehozzuk a szükséges Kubernetes komponenseket, mint a szolgáltatások és az endpointok. Valójában így fogunk cselekedni, végrehajtva az expose parancsot a deployment objektumunk számára:

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

Most álljunk meg egy pillanatra az expose parancs "--type" opciójánál.

Amikor végrehajtjuk az expose-t, és létrehozzuk a szükséges komponenseket a szolgáltatásunk futtatásához, többek között azt is szeretnénk, hogy kívülről csatlakozhassanak a hello-quarkus szolgáltatáshoz, amely a programozott hálózatunkon belül található. Az type paraméter lehetővé teszi számunkra, hogy létrehozzunk és csatlakoztassunk olyan dolgokat, mint a terheléselosztók, hogy irányítsák a forgalmat erre a hálózatra.

Például, ha megadjuk type=LoadBalancer, automatikusan inicializálunk egy terheléselosztót a nyilvános felhőben, hogy csatlakozhassunk a Kubernetes klaszterünkhöz. Ez természetesen nagyszerű, de fontos megérteni, hogy az ilyen konfiguráció szorosan a konkrét nyilvános felhőhöz lesz kötve, és nehezebben mozgatható más Kubernetes példányok között különböző környezetekben.

A példánkban type=NodePort, azaz a szolgáltatásunkhoz való hozzáférés a csomópont IP-címén és a portszámon keresztül történik. Ez a megoldás lehetővé teszi, hogy ne használjunk nyilvános felhőket, de számos további lépést igényel. Először is szükség van saját terheléselosztóra, ezért telepítünk egy NGINX terheléselosztót a klaszterünkre.

6. lépés – telepítjük a terheléselosztót

A minikube számos platformspecifikus funkciót kínál, amelyek megkönnyítik a külső hozzáféréshez szükséges összetevők, például ingress vezérlők létrehozását. A minikube ingyenes ingress vezérlőt tartalmaz, nekünk csupán be kell kapcsolnunk és konfigurálnunk kell.

minikube addons enable ingress

Most egy parancssal létrehozzuk az Nginx ingress vezérlőt, amely a minikube klaszterünkben fog működni:

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

7. lépés – konfiguráljuk az ingress-t

Most be kell állítanunk az Nginx ingress vezérlőt, hogy az észlelje a hello-quarkus kéréseket.

És végül alkalmaznunk kell ezt a konfigurációt.

kubectl apply -f ingress.yml

Mivel mindezt a saját gépünkön végezzük, egyszerűen hozzáadjuk a csomópontunk IP-címét a /etc/hosts fájlhoz, hogy az http-kérések a minikube-unkat az NGINX terheléselosztóra irányítsák.

192.168.99.100 hello-quarkus.info

Kész, most a minikube szolgáltatásunk külsőleg elérhető az Nginx ingress vezérlőn keresztül.

Na, ez könnyű volt, nem? Vagy nem olyan könnyű?

Futtatás OpenShift-en (Code Ready Containers)

Most nézzük meg, hogyan működik mindez a Red Hat OpenShift Container Platform (OCP) alatt.

A minikube esetéhez hasonlóan itt is egy egycsomópontos OpenShift klaszteres sémát választunk, amely Code Ready Containers (CRC) formájában létezik. Korábban ezt minishiftnek hívták, a OpenShift Origin projektre épült, most pedig CRC-ként ismert, és a Red Hat OpenShift Container Platformon alapul.

Itt elnézést kérünk, de nem tudjuk megállni, hogy ne mondjuk: "OpenShift csodálatos!"

Kezdetben azt akartuk írni, hogy az OpenShift környezetében végzett fejlesztés nem különbözik a Kubernetes-szel végzett fejlesztéstől. Valójában így is van. De ennek a posztnak az írása közben eszünkbe jutott, hogy mennyi felesleges lépést kell megtenni, ha nincs OpenShift, és ezért azt mondjuk, hogy csodálatos. Szeretjük, ha minden könnyen működik, és hogy mennyivel könnyebb az OpenShift alatt működtetni és elindítani a példánkat a minikube-hoz képest, valójában ösztönözte minket, hogy megírjuk ezt a posztot.

Nézzük át a folyamatot, és nézzük meg, hogy mit kell tennünk.

Tehát a minikube példán keresztül a Dockerrel kezdtük... Álljon meg, most már nincs szükségünk arra, hogy a gépen telepítve legyen a Docker.

És helyi git-re nincs szükségünk.
És Mavenre sincs szükség.
És nem kell manuálisan létrehozni a konténerképet.
És nem kell konténerkép-tárakat keresnünk.
És ingress-vezérlőt sem kell telepítenünk.
És ingress-t is konfigurálni sem kell.

Értetted, igaz? Az OpenShift-en való alkalmazásunk telepítéséhez és elindításához nincs szükségünk semmi többre a fentiekből. A folyamat azonban a következőképpen néz ki.

1. lépés – Elindítjuk a saját OpenShift klaszterünket

A Red Hat Code Ready Containers-t használjuk, ami lényegében ugyanaz, mint a Minikube, de egy teljes értékű egycsomópontos OpenShift klaszterrel.

crc start

2. lépés – Az alkalmazás építése és telepítése az OpenShift klaszterbe

Ezen a lépésen bontakozik ki legjobban az OpenShift egyszerűsége és kényelme. Mint minden Kubernetes disztribúcióban, itt is sok módja van az alkalmazás indításának a klaszterben. És mint a Kúknál, most is szándékosan a legegyszerűbbet választjuk.

Az OpenShift mindig is olyan platformként épült, amely konténeralapú alkalmazások létrehozására és futtatására szolgál. A konténerek építése mindig is a platform elengedhetetlen részét képezte, ezért itt rengeteg további Kubernetes erőforrás áll rendelkezésre ezekhez a feladatokhoz.

Az OpenShift S2I (Source 2 Image) folyamatát fogjuk használni, amelynek több különböző módja van annak, hogy a forrásállományunkat (kód vagy bináris fájlok) konténerképpé alakítsuk, amely az OpenShift klaszterben futhat.

Ehhez két dologra van szükségünk:

• Forráskódunk egy git tárhelyen
• A builder-kép, amely alapján az építés fog történni.

Számos ilyen kép létezik, amelyeket mind a Red Hat támogat, mind a közösségi szinten, és mi az OpenJDK képet fogjuk használni, mivel Java alkalmazást építek.

Az S2I építést elindíthatjuk az OpenShift Developer grafikus konzoljából vagy parancssorból is. Mi az new-app parancsot fogjuk használni, megadva neki, honnan vegye a builder-képet és a forráskódunkat.

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

Kész, az alkalmazásunk létrejött. Az S2I folyamat során a következőket végezte el:

• Létrehozott egy build-podot az alkalmazás építésével kapcsolatos feladatokhoz.
• Létrehozott egy OpenShift Build konfigurációt.
• Letöltötte a builder-képet az OpenShift belső docker-regisztrálójába.
• A 'Hello World' projektet klónozta a helyi tárhelyünkre.
• Láttam, hogy van maven pom, ezért a maven segítségével lefordítottam az alkalmazást.
• Létrehoztam egy új konténerképet, ami a lefordított Java alkalmazást tartalmazza, és ezt a képet elhelyeztem a belső konténerregiszterben.
• Készítettem egy Kubernetes Deployment-et pod, szolgáltatás stb. specifikációkkal.
• Elindítottam a konténerkép deployálását.
• Töröltem a build-pod szolgáltatást.

Ebben a listában sok minden szerepel, de a lényeg, hogy az egész build kifejezetten az OpenShift belsejében zajlik, a belső Docker-regiszter is itt található, és a build folyamata létrehozza az összes Kubernetes komponenst és elindítja őket a klaszterben.

Ha vizuálisan nyomon követjük az S2I indítását a konzolban, láthatjuk, hogy a build pod elindulása közben hogyan fut le a build.

Most nézzük meg a builder pod naplóit: először is, látható, hogy a maven hogyan végzi a munkáját és tölti le a függőségeket a Java alkalmazásunk buildeléséhez.

Miután befejeződött a maven build, elindul a konténerkép build folyamata, majd ez a létrehozott kép elküldésre kerül a belső tárolóba.

Kész, a build folyamata befejeződött. Most ellenőrizzük, hogy a klaszterben elindultak a podok és a szolgáltatások a mi alkalmazásunk számára.

oc get service

Ennyi, és mindez egyetlen parancs. Már csak annyit kell tennünk, hogy kiadjuk ennek a szolgáltatásnak a kitettségét a külső hozzáférés érdekében.

3. lépés – a szolgáltatás kitettsége külső hozzáférés érdekében

Ahogy a KUK esetében, az OpenShift platformon a mi 'Hello World'-ünkhöz is szükség van egy routerre, hogy a külső forgalmat irányítani tudja a klaszter belső szolgáltatására. Az OpenShift ezt nagyon egyszerűvé teszi. Először is, a klaszterben alapértelmezetten telepítve van a HAProxy router komponens (amit át lehet cserélni ugyanarra NGINX-re). Másodszor, itt vannak a speciális és széleskörben konfigurálható erőforrások, amelyeket Route-nak hívnak, és hasonlítanak a régi jó Kubernetes Ingress objektumokra (valójában az OpenShift Route-ok jelentősen befolyásolták az Ingress objektumok tervezését, amelyeket most már OpenShift-ben is lehet használni), de a mi 'Hello World'-ünkhöz, és szinte minden más esetben elegendő lesz a standard Route kiegészítő beállítás nélkül.

Ahhoz, hogy létrehozzunk egy útválasztott FQDN-t a 'Hello World' számára (igen, OpenShift-ben van DNS az szolgáltatásneveken történő útválasztáshoz), egyszerűen végrehajtjuk a szolgáltatásunk kitettségét:

oc expose service quarkus-hello-world

Ha megnézzük az éppen létrehozott Route-ot, akkor ott találunk FQDN-t és egyéb útválasztási információkat:

oc get route

Végül pedig megkeressük a szolgáltatásunkat a böngészőből:

Most már ez tényleg könnyű volt!

Szeretjük a Kubernetes-t és mindazt, amit ez a technológia lehetővé tesz, valamint a egyszerűséget és könnyedséget. A Kubernetes-t úgy fejlesztették ki, hogy hihetetlenül megkönnyítse a felosztott, skálázható konténerek üzemeltetését, de ma már nem elég egyszerű az alkalmazások üzembe helyezéséhez. Itt lép színre az OpenShift, amely lépést tart a korral, és a Kubernetes-t elsősorban a fejlesztők számára optimalizálja. Rengeteg energiát fektettek az OpenShift platform kifejlesztésébe a fejlesztők igényeinek megfelelően, beleértve olyan eszközök létrehozását, mint az S2I, ODI, Fejlesztői Portál, OpenShift Operator Framework, IDE integráció, Fejlesztői Katalógusok, Helm integráció, monitoring és sok más.

Reméljük, hogy ez a cikk érdekes és hasznos volt az Ön számára. További forrásokat, anyagokat és egyéb hasznos információkat a fejlesztéshez az OpenShift platformon a következő portálon találhatja: Red Hat Developers.

Forrás: habr.com