Dizze post is skreaun om't ús personiel nochal wat petearen hie mei kliïnten oer it ûntwikkeljen fan applikaasjes op Kubernetes en de spesifikaasjes fan sa'n ûntwikkeling op OpenShift.
Wy begjinne normaal mei it proefskrift dat Kubernetes gewoan Kubernetes is, en OpenShift is al in Kubernetes-platfoarm, lykas Microsoft AKS of Amazon EKS. Elk fan dizze platfoarms hat syn eigen foardielen, rjochte op in bepaalde doelgroep. En dêrnei streamt it petear al yn in ferliking fan de sterke en swakke punten fan spesifike platfoarms.
Yn 't algemien tochten wy dit berjocht te skriuwen mei in útfier lykas "Harkje, it makket net út wêr't jo de koade útfiere, op OpenShift of op AKS, op EKS, op guon oanpaste Kubernetes, ja op elke Kubernetes (litte wy it koart KUK neame) "It is echt ienfâldich, sawol dêr as dêr."
Dan hawwe wy plannen om de ienfâldichste "Hello World" te nimmen en it te brûken om te sjen wat mienskiplik is en wat de ferskillen binne tusken de CMC en it Red Hat OpenShift Container Platform (hjirnei, OCP of gewoan OpenShift).
Yn 'e rin fan it skriuwen fan dizze post realisearren wy lykwols dat wy sa wend binne wurden oan it brûken fan OpenShift dat wy gewoan net realisearje hoe't it is groeid en feroare yn in geweldig platfoarm dat folle mear is wurden dan allinich in Kubernetes-distribúsje. Wy hawwe de neiging om de folwoeksenens en ienfâld fan OpenShift as fanselssprekkend te nimmen, wylst wy de pracht fan har útsjocht.
Yn 't algemien is de tiid foar aktive bekearing kommen, en no sille wy stap foar stap de yndieling fan ús "Hello World" op KUK en op OpenShift fergelykje, en wy sille it sa objektyf mooglik dwaan (goed, útsein soms in persoanlike hâlding foar it ûnderwerp te sjen). As jo ynteressearre binne yn in suver subjektive miening oer dit probleem, dan kinne jo it lêze . En yn dizze post sille wy ús hâlde oan 'e feiten en allinich de feiten.
Klusters
Dat, ús "Hello World" hat klusters nedich. Litte wy gewoan "nee" sizze tsjin alle iepenbiere wolken, om net te beteljen foar servers, registers, netwurken, gegevensferfier, ensfh. Dêrtroch kieze wy in ienfâldige ien-knooppuntkluster op (foar KUK) en (foar in OpenShift-kluster). Beide fan dizze opsjes binne echt maklik te ynstallearjen, mar fereaskje nochal in soad boarnen op jo laptop.
Gearstalling op KUK-e
Dat litte we gean.
Stap 1 - Bouwe ús kontenerôfbylding
Litte wy begjinne mei it ynsetten fan ús "Hello World" nei minikube. Dit sil fereaskje:
- 1. Ynstallearre Docker.
- 2. Ynstallearre Git.
- 3. Ynstallearre Maven (eins, dit projekt brûkt mvnw binêr, dus do kinst dwaan sûnder it).
- 4. Eins is de boarne sels, d.w.s. repository klon
De earste stap is it meitsjen fan in Quarkus-projekt. Wês net bang as jo Quarkus.io noait hawwe brûkt - it is maklik. Jo selektearje gewoan de komponinten dy't jo wolle brûke yn it projekt (RestEasy, Hibernate, Amazon SQS, Camel, ensfh.), En dan Quarkus sels, sûnder ien fan jo dielname, set it maven-argetype op en set alles op github. Dat is, letterlik ien klik fan 'e mûs - en jo binne klear. Dit is wêrom wy fan Quarkus hâlde.
De maklikste manier om ús "Hallo Wrâld" op te bouwen yn in kontenerearre ôfbylding is de quarkus-maven-útwreidings foar Docker te brûken, dy't al it nedige wurk sil dwaan. Mei de komst fan Quarkus is dit echt maklik en ienfâldich wurden: foegje de container-image-docker tafoeging ta en jo kinne ôfbyldings meitsje mei maven-kommando's.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
En as lêste bouwe wy ús ôfbylding mei Maven. As resultaat feroaret ús boarnekoade yn in klearmakke kontenerôfbylding, dy't al kin wurde útfierd yn 'e kontener-runtime.
./mvnw -X clean package -Dquarkus.container-image.build=true
Dat, yn feite, is alles, no kinne jo de kontener útfiere mei it kommando docker run, nei't jo ús tsjinst yn kaart brocht hawwe op poarte 8080, sadat it tagong kin wurde.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Neidat de kontener-eksimplaar is begon, bliuwt alles oer om te kontrolearjen mei it curl-kommando dat ús tsjinst rint:
Dat, alles wurket, en it wie echt maklik en ienfâldich.
Stap 2 - Stjoer ús kontener yn by it bewarplak foar kontenerôfbylding
Foar no wurdt de ôfbylding dy't wy makke hawwe lokaal opslein yn ús lokale konteneropslach. As wy dizze ôfbylding wolle brûke yn ús KUK-omjouwing, dan moatte wy it yn in oar repository pleatse. Kubernetes hat dizze funksjes net, dus wy sille dockerhub brûke. Want as earste is it fergees, en as twadde docht (hast) elkenien it.
Dit is ek heul ienfâldich, en allinich in dockerhub-akkount is hjir nedich.
Dat, wy ynstallearje dockerhub en stjoere ús ôfbylding dêr.
Stap 3 - Start Kubernetes
D'r binne in protte manieren om in kubernetes-konfiguraasje gear te setten om ús "Hello World" út te fieren, mar wy sille de ienfâldichste fan har brûke, om't wy sokke minsken binne ...
Earst begjinne wy it minikube-kluster:
minikube start
Stap 4 - Us kontenerôfbylding ynsette
No moatte wy ús koade en kontenerôfbylding konvertearje nei kubernetes-konfiguraasje. Mei oare wurden, wy hawwe in pod en in ynsetdefinysje nedich dy't wiist op ús kontenerôfbylding op dockerhub. Ien fan 'e maklikste manieren om dit te dwaan is om it kommando oanmeitsje ynset út te fieren dat wiist op ús ôfbylding:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Mei dit kommando fertelden wy ús COOK om in ynsetkonfiguraasje te meitsjen, dy't de pod-spesifikaasje foar ús kontenerôfbylding moat befetsje. Dit kommando sil dizze konfiguraasje ek tapasse op ús minikube-kluster, en in ynset meitsje dy't ús kontenerôfbylding sil downloade en in pod op it kluster útfiert.
Stap 5 - iepen tagong ta ús tsjinst
No't wy in ynset kontenerôfbylding hawwe, is it tiid om te tinken oer hoe't jo eksterne tagong kinne konfigurearje foar dizze Restful-tsjinst, dy't yn feite is programmearre yn ús koade.
D'r binne hjir in protte manieren. Jo kinne bygelyks it eksposearje kommando brûke om automatysk passende Kubernetes-komponinten te meitsjen lykas tsjinsten en einpunten. Eigentlik is dit wat wy sille dwaan troch it eksposearje kommando út te fieren foar ús ynsetobjekt:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Lit ús efkes stilhâlde by de "-type" opsje fan it eksposearje kommando.
As wy de komponinten bleatstelle en meitsje dy't nedich binne om ús tsjinst út te fieren, moatte wy ûnder oare fan bûten ferbine kinne mei de hello-quarkus-tsjinst dy't yn ús software-definieare netwurk sit. En parameter type lit ús dingen oanmeitsje en ferbine lykas load balancers om ferkear nei dat netwurk te routeren.
Bygelyks, skriuwen type=LoadBalancer, Inisjalisearje wy automatysk de publike wolk load balancer om te ferbinen mei ús Kubernetes-kluster. Dit is fansels geweldich, mar jo moatte begripe dat sa'n konfiguraasje strak bûn wurdt oan in spesifike iepenbiere wolk en it sil dreger wêze om it oer te setten tusken Kubernetes-eksimplaren yn ferskate omjouwings.
Yn ús foarbyld type=NodePort, dat is, de oprop nei ús tsjinst giet troch it IP-adres fan 'e knooppunt en it poartenûmer. Dizze opsje lit jo gjin iepenbiere wolken brûke, mar fereasket in oantal ekstra stappen. Earst hawwe jo jo eigen load balancer nedich, dus wy sille de NGINX load balancer yn ús kluster ynsette.
Stap 6 - Set in load balancer
minikube hat in oantal platfoarmfunksjes dy't it maklik meitsje om de komponinten te meitsjen dy't jo nedich binne foar eksterne tagong, lykas yngongskontrôles. Minikube komt bondele mei de Nginx-yngongskontrôler, en alles wat wy hoege te dwaan is it ynskeakelje en konfigurearje.
minikube addons enable ingress
No, mei mar ien kommando, sille wy in Nginx-yngongskontrôler meitsje dy't sil wurkje yn ús minikube-kluster:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Stap 7 - Stel de yngong yn
No moatte wy de Nginx-yngongskontrôler konfigurearje om hello-quarkus-oanfragen te akseptearjen.
En as lêste moatte wy dizze konfiguraasje tapasse.
kubectl apply -f ingress.yml
Om't wy dit alles op ús eigen masine dogge, foegje wy gewoan it IP-adres fan ús knooppunt ta oan it /etc/hosts-bestân om http-oanfragen nei ús minikube te rjochtsjen nei de NGINX load balancer.
192.168.99.100 hello-quarkus.info
Dat is it, no is ús minikube-tsjinst fan bûten te krijen fia de Nginx-yngongskontrôler.
No, dat wie maklik, krekt? Of net safolle?
Run op OpenShift (Code Ready Containers)
En lit ús no sjen hoe't it allegear dien wurdt op it Red Hat OpenShift Container Platform (OCP).
Lykas yn it gefal fan minikube, kieze wy in skema mei in single-node OpenShift-kluster yn 'e foarm fan Code Ready Containers (CRC). It waard eartiids minishift neamd en wie basearre op it OpenShift Origin-projekt, mar no is it CRC en boud op Red Hat's OpenShift Container Platform.
Hjir, sorry, wy kinne net oars as sizze: "OpenShift is geweldich!"
Yn it earstoan tochten wy te skriuwen dat ûntwikkeling op OpenShift net oars is fan ûntwikkeling op Kubernetes. En eins is it sa. Mar yn it proses fan it skriuwen fan dizze post, hawwe wy ûnthâlden hoefolle ûnnedige bewegingen jo moatte meitsje as jo gjin OpenShift hawwe, en dêrom, wer, it is prachtich. Wy hâlde fan dingen om maklik te wêzen, en hoe maklik it is om ús foarbyld op OpenShift yn te setten en út te fieren yn ferliking mei minikube is wat ús ynspirearre om dizze post te skriuwen.
Litte wy it proses trochrinne en sjen wat wy moatte dwaan.
Dus yn it minikube-foarbyld binne wy begon mei Docker ... Wachtsje, wy hawwe Docker net mear nedich ynstalleare op 'e masine.
En wy hawwe gjin lokale git nedich.
En Maven is net nedich.
En jo hoege gjin kontenerôfbylding mei de hân te meitsjen.
En jo hoege net te sykjen nei in repository fan kontenerôfbyldings.
En jo hoege gjin yngongskontrôler te ynstallearjen.
En jo hoege ingress ek net te konfigurearjen.
Begrypsto it? Om ús applikaasje op OpenShift yn te setten en út te fieren, is net ien fan 'e boppesteande nedich. En it proses sels is as folget.
Stap 1 - Jo OpenShift-kluster begjinne
Wy brûke Code Ready Containers út Red Hat, dat is yn wêzen deselde Minikube, mar allinnich mei in folsleine single-node Openshift kluster.
crc start
Stap 2 - Bouwe en ynsette de applikaasje nei it OpenShift-kluster
It is op dizze stap dat de ienfâld en it gemak fan OpenShift him yn al syn gloarje manifestearje. Lykas by alle Kubernetes-distribúsjes, hawwe wy in protte manieren om in applikaasje op in kluster út te fieren. En, lykas yn it gefal fan KUK, kieze wy spesifyk de ienfâldichste.
OpenShift is altyd boud as platfoarm foar it bouwen en útfieren fan containerisearre applikaasjes. It bouwen fan konteners hat altyd in yntegraal diel fan dit platfoarm west, dus d'r binne in bosk ekstra Kubernetes-boarnen foar de oerienkommende taken.
Wy sille OpenShift's Source 2 Image (S2I) proses brûke, dat ferskate ferskillende manieren hat om ús boarne (koade as binaries) te nimmen en it te feroarjen yn in kontenerisearre ôfbylding dy't rint op in OpenShift-kluster.
Dêrfoar hawwe wy twa dingen nedich:
- Us boarnekoade yn it git-repository
- Bouwer-ôfbylding, basearre op hokker de gearkomste sil wurde útfierd.
D'r binne in protte sokke ôfbyldings, ûnderhâlden sawol troch Red Hat as troch de mienskip, en wy sille de OpenJDK-ôfbylding brûke, goed, om't ik in Java-applikaasje bouwe.
Jo kinne in S2I-build útfiere sawol fan 'e OpenShift Developer grafyske konsole as fan' e kommandorigel. Wy sille it kommando nije-app brûke, en fertelle wêr't it bouwerôfbylding en ús boarnekoade te krijen binne.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Dat is it, ús applikaasje is makke. Dêrby die it S2I-proses de folgjende dingen:
- In tsjinst build-pod makke foar alle soarten dingen yn ferbân mei it bouwen fan de applikaasje.
- In OpenShift Build-konfiguraasje makke.
- Ik haw de bouwerôfbylding downloade nei it ynterne OpenShift docker-register.
- Kloned "Hello World" nei lokaal repository.
- Seach dat der in maven pom yn siet en sa kompilearre de app mei maven.
- In nije kontenerôfbylding makke mei de kompilearre Java-applikaasje en set dizze ôfbylding yn it ynterne kontenerregister.
- In Kubernetes-ynset makke mei spesifikaasjes foar in pod, tsjinst, ensfh.
- Containerôfbylding lansearre.
- Ferwiderde tsjinst build-pod.
D'r is in protte op dizze list, mar it wichtichste is dat de heule bou allinich binnen OpenShift plakfynt, it ynterne Docker-register is binnen OpenShift, en it bouproses makket alle Kubernetes-komponinten en rint se op it kluster.
As jo de lansearring fan S2I yn 'e konsole fisueel kontrolearje, kinne jo sjen hoe't de boupod wurdt lansearre tidens de bou.
En litte wy no de logboeken fan 'e bouwerpod besjen: earst kinne jo dêr sjen hoe't Maven har wurk docht en ôfhinklikens downloadt om ús java-applikaasje te bouwen.
Nei't de maven-bou is foltôge, wurdt de bou fan 'e kontenerôfbylding begon, en dan wurdt dizze boude ôfbylding nei it ynterne repository stjoerd.
Alles, it assemblageproses is foltôge. Litte wy no derfoar soargje dat de pods en tsjinsten fan ús applikaasje binne begon yn it kluster.
oc get service
Da's alles. En der is mar ien team. Alles wat wy hoege te dwaan is dizze tsjinst bleatstelle foar tagong fan bûten.
Stap 3 - meitsje de tsjinst bleatsteld foar tagong fan bûten
Lykas yn it gefal fan KUK, op it OpenShift-platfoarm, hat ús "Hello World" ek in router nedich om ekstern ferkear nei in tsjinst yn it kluster te rjochtsjen. Yn OpenShift makket dit it heul maklik. As earste is de HAProxy-routingkomponint standert ynstalleare yn it kluster (it kin wizige wurde yn deselde NGINX). Twad binne d'r spesjale en tige oanpasbere boarnen neamd Routes, dy't tinke oan Ingress-objekten yn goede âlde Kubernetes (feitlik hawwe OpenShift's Routes sterk ynfloed op it ûntwerp fan Ingress-objekten, dy't no kinne wurde brûkt yn OpenShift), mar foar ús "Hello World", en yn hast alle oare gefallen, sil de standertrûte sûnder ekstra konfiguraasje genôch wêze foar ús.
Om in routable FQDN te meitsjen foar "Hello World" (ja, OpenShiift hat in eigen DNS foar routing troch tsjinstnammen), bleatstelle wy gewoan ús tsjinst:
oc expose service quarkus-hello-world
As jo nei de nij oanmakke rûte sjogge, dan kinne jo dêr de FQDN en oare rûteynformaasje fine:
oc get route
En as lêste hawwe wy tagong ta ús tsjinst fan 'e browser:
Mar no wie it echt maklik!
Wy hâlde fan Kubernetes en alles wat dizze technology jo kinne dwaan, en wy hâlde ek fan ienfâld en ljochtens. Kubernetes is ûntworpen om ferdielde, skalberbere konteners ongelooflijk maklik te betsjinjen te meitsjen, mar de ienfâld is net mear genôch om applikaasjes hjoed yn produksje te bringen. En dit is wêr't OpenShift yn spiel komt, dy't mei de tiden byhâldt en Kubernetes biedt, foaral rjochte op 'e ûntwikkelder. In protte muoite is ynvestearre om it OpenShift-platfoarm spesifyk oan te passen foar de ûntwikkelder, ynklusyf it meitsjen fan ark lykas S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-yntegraasje, Developer Catalogs, Helm-yntegraasje, monitoring, en in protte oaren.
Wy hoopje dat dit artikel ynteressant en nuttich wie foar jo. En jo kinne ekstra boarnen, materialen en oare dingen fine dy't nuttich binne foar ûntwikkeling op it OpenShift-platfoarm op it portaal .
Boarne: www.habr.com