Ezt a bejegyzést azért írtuk, mert munkatársaink elég sokat beszélgettek az ügyfelekkel a Kubernetes alkalmazásfejlesztéséről és az OpenShift-en történő fejlesztés sajátosságairól.
Általában azzal a tézissel kezdjük, hogy a Kubernetes csak Kubernetes, az OpenShift pedig már Kubernetes platform, mint például a Microsoft AKS vagy az Amazon EKS. Mindegyik platformnak megvannak a maga előnyei, amelyek egy adott célközönséget céloznak meg. Ezután a beszélgetés az egyes platformok erősségei és gyengeségei összehasonlítására irányul.
Általában úgy gondoltuk, hogy ezt a bejegyzést egy olyan következtetéssel írjuk meg, mint „Figyelj, nem számít, hol kell futtatni a kódot, OpenShift-en vagy AKS-en, EKS-en, néhány egyedi Kubernetesen vagy bármilyen Kubernetesen (a rövidség kedvéért nevezzük KUK-nak) – Nagyon egyszerű, ott is, ott is.
Aztán azt terveztük, hogy a legegyszerűbb „Hello World”-et vesszük, és annak példájával megmutatjuk, mi a közös és mi a különbség a KUC és a Red Hat OpenShift Container Platform (továbbiakban OCP vagy egyszerűen OpenShift) között.
A bejegyzés írása közben azonban rájöttünk, hogy annyira hozzászoktunk az OpenShift használatához, hogy egyszerűen nem vettük észre, hogyan nőtt ki, és egy csodálatos platformmá vált, amely sokkal több lett, mint egy Kubernetes disztribúció. Hajlamosak vagyunk természetesnek venni az OpenShift érettségét és egyszerűségét, és szem elől tévesztjük a ragyogását.
Általánosságban elmondható, hogy eljött az aktív bűnbánat ideje, és most lépésről lépésre összehasonlítjuk a „Hello World” beüzemelését a KUK-on és az OpenShift-en, és ezt a lehető legobjektívebben fogjuk megtenni (jó, kivéve, ha néha megmutatunk egy személyes hozzáállás a témához). Ha érdekli egy tisztán szubjektív vélemény ebben a kérdésben, akkor elolvashatja . Ebben a bejegyzésben pedig ragaszkodunk a tényekhez és csak a tényekhez.
Klaszterek
Tehát a „Hello World”-ünkhöz klaszterekre van szükség. Azonnal nemet mondunk minden nyilvános felhőre, hogy ne kelljen fizetni a szerverekért, nyilvántartásokért, hálózatokért, adatátvitelért stb. Ennek megfelelően egy egyszerű egycsomópontos klasztert választunk (KUK esetében) és (OpenShift-fürthöz). Mindkét opció nagyon könnyen telepíthető, de elég sok erőforrást igényel a laptopon.
Összeszerelés a KUK-e-n
Tehát menjünk.
1. lépés – konténerimázsunk kialakítása
Kezdjük azzal, hogy telepítsük a „Hello World”-ünket a minikube-ba. Ehhez szüksége lesz:
- 1. Docker telepítve.
- 2. Git telepítve.
- 3. Telepített Maven (valójában ez a projekt az mvnw binárist használja, szóval nélküle is meg lehet csinálni).
- 4. Tulajdonképpen maga a forrás, i.e. adattár klónja
Az első lépés egy Quarkus projekt létrehozása. Ne ijedjen meg, ha még soha nem dolgozott a Quarkus.io-val – ez egyszerű. Csak ki kell választanod a projektben használni kívánt komponenseket (RestEasy, Hibernate, Amazon SQS, Camel stb.), majd maga a Quarkus az ön részvétele nélkül konfigurálja a maven archetípust, és mindent a githubra tesz. Vagyis szó szerint egyetlen kattintás az egérrel, és kész. Ezért szeretjük a Quarkust.
A „Hello World” konténerképet a legegyszerűbben a quarkus-maven kiterjesztésekkel a Dockerhez használjuk, amelyek minden szükséges munkát elvégeznek. A Quarkus megjelenésével ez nagyon egyszerűvé és egyszerűvé vált: adjuk hozzá a container-image-docker kiterjesztést, és maven parancsok segítségével készíthetünk képeket.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Végül a Maven segítségével építjük fel az arculatunkat. Ennek eredményeként a forráskódunk egy kész konténer képpé alakul, amely már futtatható a konténer futási környezetben.
./mvnw -X clean package -Dquarkus.container-image.build=true
Ez minden, most már elindíthatja a tárolót a docker run paranccsal, leképezve szolgáltatásunkat a 8080-as portra, hogy az elérhető legyen.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
A tárolópéldány elindítása után már csak a curl paranccsal kell ellenőrizni, hogy fut-e szolgáltatásunk:
Szóval minden működik, és nagyon könnyű és egyszerű volt.
2. lépés – küldje el a tárolónkat a konténer képtárba
Egyelőre az általunk létrehozott kép helyileg, a helyi konténertárolónkban van tárolva. Ha ezt a képet a COOK környezetünkben akarjuk használni, akkor valamilyen más tárolóba kell helyezni. A Kubernetes nem rendelkezik ilyen funkciókkal, ezért dockerhubot fogunk használni. Mert egyrészt ingyenes, másrészt (majdnem) mindenki csinálja.
Ez is nagyon egyszerű, és csak egy dockerhub-fiókra van szüksége.
Tehát telepítjük a dockerhubot, és elküldjük a képünket.
3. lépés - Indítsa el a Kuberneteset
A kubernetes konfigurációt sokféleképpen összeállíthatjuk a „Hello World” futtatásához, de mi ezek közül a legegyszerűbbet fogjuk használni, ilyenek vagyunk...
Először indítsuk el a minikube fürtöt:
minikube start
4. lépés – telepítse a konténerképünket
Most át kell alakítanunk a kódunkat és a tárolóképenket kubernetes konfigurációkká. Más szavakkal, szükségünk van egy pod- és telepítésdefinícióra, amely a dockerhubon található tárolóképünkre mutat. Ennek egyik legegyszerűbb módja a create deployment parancs futtatása, amely a képünkre mutat:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Ezzel a paranccsal azt mondtuk a COO-nak, hogy hozzon létre egy telepítési konfigurációt, amelynek tartalmaznia kell a tárolóképünk pod specifikációját. Ez a parancs a minikube-fürtünkre is alkalmazza ezt a konfigurációt, és létrehoz egy olyan telepítést, amely letölti a tárolóképünket, és elindítja a pod-ot a fürtben.
5. lépés – nyílt hozzáférés a szolgáltatásunkhoz
Most, hogy megvan a telepített konténerkép, ideje elgondolkodni azon, hogyan állítsuk be a külső hozzáférést ehhez a Restful szolgáltatáshoz, amely valójában a kódunkban van programozva.
Számos módja van itt. Az expose paranccsal például automatikusan létrehozhatja a megfelelő Kubernetes-összetevőket, például szolgáltatásokat és végpontokat. Valójában ezt fogjuk tenni az expose parancs végrehajtásával a telepítési objektumunkhoz:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Szánjunk egy pillanatra az expose parancs „-type” opciójának áttekintésére.
Amikor nyilvánosságra hozzuk és létrehozzuk a szolgáltatásunk futtatásához szükséges összetevőket, többek között képesnek kell lennünk kívülről kapcsolódni a hello-quarkus szolgáltatáshoz, amely a szoftver által definiált hálózatunkon belül található. És paraméter típus lehetővé teszi számunkra, hogy olyan dolgokat hozzunk létre és csatlakoztassunk, mint a terheléselosztók, hogy a forgalmat erre a hálózatra irányítsuk.
Például írással type=Loadbalancer, automatikusan létrehozunk egy terheléselosztót a nyilvános felhőben a Kubernetes-fürthöz való csatlakozáshoz. Ez természetesen nagyszerű, de meg kell értenie, hogy egy ilyen konfiguráció szigorúan egy adott nyilvános felhőhöz lesz kötve, és nehezebb lesz átvinni a Kubernetes-példányok között különböző környezetekben.
Példánkban type=NodePort, azaz szolgáltatásunk a csomópont IP-címe és portszáma alapján érhető el. Ez az opció lehetővé teszi, hogy ne használjon nyilvános felhőket, de számos további lépést igényel. Először is szüksége van egy saját terheléselosztóra, ezért telepíteni fogjuk az NGINX terheléselosztót a fürtünkben.
6. lépés – terheléselosztó felszerelése
A minikube számos platformfunkcióval rendelkezik, amelyek megkönnyítik a kívülről elérhető összetevők, például a bemeneti vezérlők létrehozását. A Minikube az Nginx bemeneti vezérlővel együtt érkezik, és nekünk nincs más dolgunk, mint engedélyezni és konfigurálni.
minikube addons enable ingress
Most egyetlen paranccsal létrehozunk egy Nginx bemeneti vezérlőt, amely a minikube-fürtünkön belül fog működni:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
7. lépés – Belépés beállítása
Most be kell állítanunk az Nginx bemeneti vezérlőt úgy, hogy az elfogadja 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 számítógépünkön tesszük, egyszerűen hozzáadjuk a csomópontunk IP-címét az /etc/ hosts fájlhoz, hogy a http kéréseket a minikube-ba irányítsuk az NGINX terheléselosztóhoz.
192.168.99.100 hello-quarkus.info
Ennyi, most a minikube szolgáltatásunk külsőleg is elérhető az Nginx bemeneti vezérlőn keresztül.
Nos, ez könnyű volt, igaz? Vagy nem annyira?
Futás OpenShift-en (kódkész tárolók)
Most pedig nézzük meg, hogyan történik mindez a Red Hat OpenShift Container Platformon (OCP).
A minikube-hoz hasonlóan egy csomópontos OpenShift-fürt kialakítást választunk Code Ready Containers (CRC) formájában. Korábban minishiftnek hívták, és az OpenShift Origin projekten alapult, de most CRC, és a Red Hat OpenShift Container Platformjára épül.
Itt, sajnáljuk, nem tehetjük mást, mint azt, hogy „Az OpenShift csodálatos!”
Kezdetben azt gondoltuk, hogy az OpenShift-en végzett fejlesztés nem különbözik a Kubernetes-en végzett fejlesztéstől. És lényegében ez a helyzet. De a bejegyzés írása közben eszünkbe jutott, hogy mennyi plusz mozdulatot kell végrehajtanod, ha nincs OpenShifted, és ezért ismételten csodálatos. Szeretjük, ha mindent könnyen meg lehet csinálni, és hogy a példánkat milyen egyszerű az OpenShift telepítése és futtatása a minikube-hoz képest, ez késztetett minket ennek a bejegyzésnek a megírására.
Menjünk végig a folyamaton, és nézzük meg, mit kell tennünk.
Tehát a minikube példában a Dockerrel kezdtük... Várjunk, már nem kell a gépre telepíteni a Dockert.
És nincs szükségünk helyi gitekre.
Mavenre pedig nincs szükség.
És nem kell a kezével konténerképet létrehoznia.
És nem kell keresnie a konténerképek tárházát.
És nincs szükség bemeneti vezérlő telepítésére.
És a bemenetet sem kell konfigurálnia.
Érted, ugye? Alkalmazásunk OpenShift rendszerben történő üzembe helyezéséhez és futtatásához nincs szüksége a fentiekre. És maga a folyamat így néz ki.
1. lépés – Indítsa el az OpenShift-fürtöt
A Red Hat Code Ready Containers-jét használjuk, ami lényegében ugyanaz a Minikube, de csak egy teljes értékű egycsomópontos Openshift fürttel.
crc start
2. lépés – Az alkalmazás létrehozása és üzembe helyezése az OpenShift-fürtben
Ezen a lépésen mutatkozik meg az OpenShift egyszerűsége és kényelme teljes dicsőségében. Mint minden Kubernetes disztribúció esetében, sokféleképpen futtathatunk egy alkalmazást egy fürtben. És ahogy a KUK esetében is, mi kifejezetten a legegyszerűbbet választjuk.
Az OpenShiftet mindig is platformként építették fel konténeres alkalmazások létrehozására és futtatására. A konténerépítés mindig is szerves része volt ennek a platformnak, így rengeteg további Kubernetes-erőforrás áll rendelkezésre a kapcsolódó feladatokhoz.
Az OpenShift Source 2 Image (S2I) folyamatát fogjuk használni, amelynek többféle módja van a forrás (kód vagy bináris) felvételére, és egy OpenShift-fürtön futó konténeres képpé alakítására.
Ehhez két dologra van szükségünk:
- A forráskódunk a git adattárban található
- Építőkép, amely alapján az építés végrehajtásra kerül.
A Red Hat és közösségi szinten is sok ilyen kép van karbantartva, és mi az OpenJDK image-t fogjuk használni, nos, mivel Java alkalmazást építek.
Az S2I buildet az OpenShift Developer grafikus konzolról és a parancssorból is futtathatja. A new-app parancsot fogjuk használni, megmondva neki, hogy honnan szerezheti be a builder image-t és a forráskódunkat.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Ez az, alkalmazásunk elkészült. Ennek során az S2I folyamat a következőket tette:
- Létrehozott egy szolgáltatás build-pod-ot az alkalmazás felépítésével kapcsolatos mindenféle dologhoz.
- Létrehozta az OpenShift Build konfigurációt.
- Letöltöttem a builder image-et a belső OpenShift dokkoló-nyilvántartásba.
- „Hello World” klónozása a helyi adattárba.
- Láttam, hogy van ott egy maven pom, ezért a maven segítségével fordítottam le az alkalmazást.
- Létrehozott egy új tárolóképet, amely tartalmazza a lefordított Java-alkalmazást, és behelyezte ezt a képet a belső tároló-nyilvántartásba.
- Létrehozta a Kubernetes-telepítést a pod, a szolgáltatás stb. specifikációival.
- Elkezdtem a tárolókép telepítését.
- Eltávolította a szerviz build-pod-ot.
Sok minden található ezen a listán, de a lényeg az, hogy a teljes összeállítás kizárólag az OpenShift-en belül történik, a belső Docker-nyilvántartás az OpenShift-en belül van, és az összeállítási folyamat létrehozza az összes Kubernetes-összetevőt, és futtatja azokat a fürtben.
Ha vizuálisan figyeli az S2I elindítását a konzolon, láthatja, hogyan indul el a build pod, amikor a build befejeződött.
Most pedig vessünk egy pillantást a builder pod naplókra: először is megmutatja, hogyan végzi a maven a dolgát, és letölti a függőségeket a java alkalmazásunk elkészítéséhez.
A maven build befejezése után elindul a konténer képfájl felépítése, majd ez az összeállított képfájl elküldésre kerül a belső tárolóba.
Ez az, az építési folyamat befejeződött. Most győződjünk meg arról, hogy alkalmazásunk podjai és szolgáltatásaink futnak a fürtben.
oc get service
Ez minden. És csak egy csapat. Csak annyit kell tennünk, hogy ezt a szolgáltatást kívülről is elérhetjük.
3. lépés – tegye elérhetővé a szolgáltatást kívülről
Akárcsak a KUC esetében, az OpenShift platformon a „Hello World”-ünknek is szüksége van egy routerre, amely a külső forgalmat a klaszteren belüli szolgáltatáshoz irányítja. Az OpenShift ezt nagyon megkönnyíti. Először is, a HAProxy útválasztási komponens alapértelmezés szerint telepítve van a fürtben (változtatható ugyanarra az NGINX-re). Másodszor, vannak speciális és jól konfigurálható, Routes nevű erőforrások, amelyek a jó öreg Kubernetes Ingress objektumaira emlékeztetnek (sőt, az OpenShift Routes nagyban befolyásolta az Ingress objektumok tervezését, amelyek most már az OpenShiftben is használhatók), de a mi „Hello World” számára. , és szinte minden más esetben a standard Route is elegendő számunkra további konfiguráció nélkül.
Ha egy irányítható FQDN-t szeretne létrehozni a „Hello World” számára (igen, az OpenShiift saját DNS-sel rendelkezik a szolgáltatásnevek szerinti útválasztáshoz), egyszerűen feltesszük a szolgáltatásunkat:
oc expose service quarkus-hello-world
Ha megnézi az újonnan létrehozott útvonalat, ott megtalálja az FQDN-t és egyéb útválasztási információkat:
oc get route
És végül elérjük szolgáltatásunkat a böngészőből:
De most tényleg könnyű volt!
Szeretjük a Kuberneteset és mindazt, amit ez a technológia lehetővé tesz számunkra, és szeretjük az egyszerűséget és a könnyűséget is. A Kubernetes azért jött létre, hogy hihetetlenül leegyszerűsítse az elosztott, méretezhető konténerek működését, de az egyszerűsége ma már nem elegendő az alkalmazások éles üzembe helyezéséhez. Itt jön képbe az OpenShift, amely lépést tart a korral, és elsősorban a fejlesztőknek szánt Kuberneteset kínálja. Sok erőfeszítést tettek az OpenShift platform kimondottan a fejlesztőre való testreszabására, beleértve az olyan eszközök létrehozását, mint az S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE integráció, fejlesztői katalógusok, Helm integráció, felügyelet és még 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, a fejlesztéshez hasznos dolgokat találhat a portál OpenShift platformján .
Forrás: will.com