Kyçti është shkruar pasi punonjësit tanë kanë pasur shumë biseda me klientët mbi zhvillimin e aplikacioneve në Kubernetes dhe specifikat e këtij zhvillimi në OpenShift.
Ne zakonisht fillojmĂ« me tezĂ«n se Kubernetes Ă«shtĂ« thjesht Kubernetes, ndĂ«rsa OpenShift Ă«shtĂ« njĂ« platformĂ« Kubernetes, si Microsoft AKS ose Amazon EKS. Ădo njĂ« prej kĂ«tyre platformave ka avantazhet e veta, orientuar ndaj njĂ« audience tĂ« caktuar. Pas kĂ«saj, biseda kalon nĂ« krahasimin e forcave dhe dobĂ«sive tĂ« platformave specifike.
NĂ« pĂ«rgjithĂ«si, ne menduam tĂ« shkruajmĂ« kĂ«tĂ« postim me njĂ« pĂ«rfundim si "Doni, nuk ka rĂ«ndĂ«si ku e ekzekutoni kodin, nĂ« OpenShift, AKS, EKS, nĂ« ndonjĂ« Kubernetes tĂ« personalizuar, madje nĂ« çfarĂ«do Kubernetes-i" (pĂ«r shkak tĂ« shkurtĂ«sisĂ«, le ta quajmĂ« KUK) â Ă«shtĂ« nĂ« tĂ« vĂ«rtetĂ« e thjeshtĂ«, pĂ«r tĂ« dyja.
Më pas planifikonim të merrnim një "Hello World" të thjeshtë dhe në shembullin e tij të tregonin se çfarë kanë të përbashkët dhe cilat janë diferencat midis KUK dhe Red Hat OpenShift Container Platform (më pas, OCP ose thjesht OpenShift).
Megjithatë, gjatë shkrimit të këtij postimi, kuptuam se ishim mësuar aq shumë me përdorimin e OpenShift, saqë nuk e kuptojmë se sa është rritur dhe kthyer në një platformë të shkëlqyer, e cila tani është shumë më tepër sesa thjesht një distribucion Kubernetes. Jemi mësuar ta perceptojmë pjekurinë dhe thjeshtësinë e OpenShift si diçka të natyrshme, duke humbur nga vëmendja shkëlqimin e tij.
Në përgjithësi, ka ardhur koha për një pendim aktiv, dhe tani do të krahasojmë hap pas hapi testin tonë 'Hello World' në KUK dhe në OpenShift, duke e bërë këtë sa më objektivisht të jetë e mundur (ndoshta duke shprehur ndonjëherë mendimin tonë personal mbi temën). Nëse jeni të interesuar për mendimin e pastër subjektiv mbi këtë çështje, mund ta lexoni . Në këtë postim do të mbajmë qëndrim te faktet dhe vetëm te faktet.
Klusterët
Pra, për 'Hello World' tonë na nevojiten klusterë. Të themi menjëherë 'jo' çdo lloj cloud publik, për të mos paguar për serverët, regjistrat, rrjetet, transferimin e të dhënave, etj. Prandaj, ne zgjedhim një kluster të thjeshtë me një nyje në (për KUK) dhe (për klusterin OpenShift). Të dyja këto variante janë realisht të lehta për t'u instaluar, por do të kërkojnë mjaft burime në laptopin tuaj.
Ndërtimi në KUK
Pra rregullojmë.
Hapi 1 â krijojmĂ« imazhin tonĂ« tĂ« kontejnerit
Së pari do të fillojmë duke e drejtuar 'Hello World' tonë në minikube. Për këtë nevojiten:
- 1. Docker i instaluar.
- 2. Git i instaluar.
- 3. Maven i instaluar (në fakt, në këtë projekt përdoret binari mvnw, kështu që mund të kaloni pa këtë).
- 4. Burimi vetë, pra, kloni i depove
SĂ« pari duhet tĂ« krijoni njĂ« projekt Quarkus. Mos u friksoni nĂ«se nuk keni punuar ndonjĂ«herĂ« me sitin Quarkus.io â Ă«shtĂ« e lehtĂ«. Thjesht zgjidhni komponentĂ«t qĂ« dĂ«shironi tĂ« pĂ«rdorni nĂ« projekt (RestEasy, Hibernate, Amazon SQS, Camel etj.), dhe mĂ« pas Quarkus do ta konfigurojĂ« vetĂ« arketipin maven dhe do ta publikojĂ« gjithçka nĂ« github. Pra, ndonjĂ«herĂ« njĂ« klikim dhe Ă«shtĂ« gati. KĂ«shtu qĂ« e duam Quarkus.
Mënyra më e thjeshtë për të ndërtuar 'Hello World' tonë në imazhin e kontejnerit është të përdorni zgjerimet quarkus-maven për Docker-in, të cilat do të bëjnë të gjithë punën e nevojshme. Me ardhjen e Quarkus, kjo është bërë vërtet e lehtë: shtoni zgjerimin container-image-docker dhe mund të krijoni imazhe me komandat maven.
./mvnw quarkus:add-extension -Dextensions="container-image-docker"
Dhe në fund, realizojmë ndërtimin e imazhit tonë duke përdorur Maven. Si rezultat, kodi ynë burimor shndërrohet në një imazh të gatshëm për konteiner, i cili tashmë mund të ekzekutohet në një mjedis konteinerësh.
./mvnw -X clean package -Dquarkus.container-image.build=true
Ja, tani mund të ekzekutojmë konteinerin me komandën docker run, duke e mapuar shërbimin tonë në portin 8080, në mënyrë që të mund të aksesohet.
docker run -i --rm -p 8080:8080 gcolman/quarkus-hello-world
Pas aktivizimit të instancës së konteinerit, mbetet vetëm të kontrollojmë me komandën curl nëse shërbimi ynë funksionon:
Pra, gjithçka funksionon, dhe ishte vërtet e lehtë dhe e thjeshtë.
Hapi 2 â dĂ«rgojmĂ« konteinerin tonĂ« nĂ« depozitĂ«n e imazheve tĂ« konteinerĂ«ve
Derisa imazhi që krijuam është ruajtur lokal, në magazinën tonë lokale të konteinerëve. Nëse dëshirojmë të përdorim këtë imazh në mjedisin tonë K8s, duhet ta ngarkojmë në ndonjë depo tjetër. Në Kubernetes nuk ka funksione të tilla, prandaj do të përdorim dockerhub. Sepse, së pari, është falas, dhe së dyti, (pothuajse) të gjithë e bëjnë kështu.
Kjo është gjithashtu shumë e thjeshtë, dhe këtu vetëm një llogari në dockerhub është e nevojshme.
Pra, ngarkojmë në dockerhub dhe e dërgojmë imazhin tonë aty.
Hapi 3 â aktivizoni Kubernetes
Ka shumĂ« mĂ«nyra pĂ«r tĂ« mbledhur konfigurimin e kubernetes pĂ«r tĂ« aktivizuar "Hello World" tonĂ«, por ne do tĂ« pĂ«rdorim mĂ«nyrĂ«n mĂ« tĂ« thjeshtĂ«, sepse kjo Ă«shtĂ« mĂ«nyra jonĂ«âŠ
NĂ« fillim, aktivizoni klasterin minikube:
minikube start
Hapi 4 â zhvillojmĂ« imazhin tonĂ« tĂ« kontejnerit
Tani duhet të kthejmë kodin tonë dhe imazhin e kontejnerit në konfigurimet e kubernetes. Me fjalë të tjera, na nevojitet definicioni i pod-it dhe deployment-it me referencë në imazhin tonë në dockerhub. Një nga mënyrat më të thjeshta për ta bërë këtë është të ekzekutojmë komandën create deployment, duke treguar për imazhin tonë:
kubectl create deployment hello-quarkus â image=gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Me këtë komandë, ne i thamë KUK tonë të krijojë konfigurimin e deployment-it, i cili duhet të përmbajë specifikimin e pod-it për imazhin tonë të kontejnerit. Kjo komandë gjithashtu do ta aplikojë këtë konfigurim në klasterin tonë minikube dhe do të krijojë një deployment që do të shkarkojë imazhin tonë të kontejnerit dhe do të aktivizojë pod-in në klaster.
Hapi 5 â hapim qasjen nĂ« shĂ«rbimin tonĂ«
Tani që kemi një imazh kontejneri të zhvilluar, është koha të mendojmë se si të konfigurojmë qasjen e jashtme në këtë shërbim Restful, i cili është programuar në kodin tonë.
Ka janë shumë mënyra. Për shembull, mund të përdorni komandën expose për të krijuar automatikisht komponentët përkatës Kubernetes, siç janë shërbimet dhe pikët e hyrjes. Në fakt, kështu do të veprojmë, duke ekzekutuar komandën expose për objektin tonë deployment.
kubectl expose deployment hello-quarkus --type=NodePort --port=8080
Le të ndalemi për një moment te opsioni "--type" i komandës expose.
Kur bëjmë expose dhe krijojmë komponentët e nevojshëm për të drejtuar shërbimin tonë, na nevojitet që të jashtme të mund të lidhen me shërbimin hello-quarkus, i cili ndodhet brenda rrjetit tonë të definuar me softuer. Dhe parametri type na lejon të krijojmë dhe lidhim gjëra siç janë balancuesit e ngarkesës për të riorientuar trafikun në këtë rrjet.
Për shembull, duke specifikuar type=LoadBalancer, ne automatikisht aktivizojmë balancuesin e ngarkesës në një re publike për t'u lidhur me klusterin tonë Kubernetes. Kjo është, sigurisht, e shkëlqyer, por duhet të kuptohet se një konfigurim i tillë do të jetë i lidhur ngushtë me një re publike specifike dhe do të jetë më e vështirë të transferosh midis instancave të Kubernetes në mjedise të ndryshme.
Në shembullin tonë type=NodePort, domethen, qoftë se adresimi në shërbimin tonë bëhet nëpërmjet IP-së së nodës dhe numrit të portit. Ky variant lejon që të mos përdoren asnjë cloud publik, por kërkon disa hapa shtesë. Së pari, ne kemi nevojë për balancimin e ngarkesës tonë, kështu që do të vendosim një balancues ngarkese NGINX në klasterin tonë.
Hapi 6 â vendosim balancuesin e ngarkesĂ«s
Minikube ka disa funksione platformës që thjeshtojnë krijimin e komponentëve të nevojshëm për qasje nga jashtë, si kontrollorët e ingress. Minikube vjen me kontrollorin ingress Nginx, dhe ne thjesht duhet ta aktivizojmë dhe ta konfigurojmë.
minikube addons enable ingress
Tani, me një komandë, do të krijojmë kontrollorin ingress Nginx, i cili do të funksionojë brenda klasterit tonë minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Po funksionon 1 33m
Hapi 7 â KonfigurojmĂ« ingress
Tani duhet të konfigurojmë kontrollorin ingress Nginx për të pranuar kërkesat hello-quarkus.
Dhe, përfundimisht, duhet ta aplikojmë këtë konfiguratë.
kubectl apply -f ingress.yml
Duke qenë se po i bëjmë të gjitha këto në kompjuterin tonë, thjesht shtojmë IP-në e nodës sonë në skedarin /etc/hosts, për të drejtuar kërkesat http ndaj minikube-tonë në balancuesin e ngarkesës NGINX.
192.168.99.100 hello-quarkus.info
Tani është, tani shërbimi ynë minikube është në dispozicion nga jashtë përmes kontrolluesit ingress Nginx.
Pra, ishte e lehtë, apo jo? Apo jo shumë?
Iniciimi në OpenShift (Code Ready Containers)
Tani do të shohim si të bëhet kjo në Red Hat OpenShift Container Platform (OCP).
Si nĂ« rastin e minikube, ne zgjedhim skemĂ«n me klaster njĂ«-nodshĂ«m OpenShift nĂ« formĂ«n e Code Ready Containers (CRC). Deri tani ai quhej minishift dhe ishte i bazuar nĂ« projektin OpenShift Origin, ndĂ«rsa tani Ă«shtĂ« CRC dhe Ă«shtĂ« ndĂ«rtuar mbi platformĂ«n Red Hatâove OpenShift Container.
Këtu, na falni, nuk mund të ndalemi dhe të mos themi: "OpenShift është i mrekullueshëm!"
Fillimisht menduam të shkruajmë se zhvillimi në OpenShift nuk ndryshon nga zhvillimi në Kubernetes. Dhe në thelb është kështu. Por gjatë shkrimit të këtij artikulli, na erdhën në mendje sa shumë hapa të panevojshëm duhet të bësh kur nuk ke OpenShift, dhe prandaj është, përsëri, i mrekullueshëm. Ne e duam kur gjithçka bëhet lehtë, dhe siç është lehtë krahasuar me minikube që shembulli ynë zbulohet dhe fillon në OpenShift, realisht na frymëzoi për të shkruar këtë postim.
Le të përshkojmë procesin dhe të shohim çfarë do të na nevojitet të bëjmë.
Pra, në shembullin me minikube ne filluam me Docker... Prit, nuk është më e nevojshme që në makinë të jetë instaluar Docker.
Dhe git lokal nuk na nevojitet.
Dhe Maven nuk është i nevojshëm.
Dhe nuk është e nevojshme të krijoni manualisht imazhin e kontejnerit.
Dhe nuk është e nevojshme të kërkoni ndonjë depot të imazheve të kontenierëve.
Dhe nuk është e nevojshme të instaloni kontrollin e ingress.
Dhe as konfigurimi i ingress nuk është i nevojshëm.
E kuptuat, po? Për të vendosur dhe nisur aplikacionin tonë në OpenShift, nuk kemi nevojë për asnjë nga gjërat e lartpërmendura. Procesi vetë duket si më poshtë.
Hapi 1 â Nisni klasterin tuaj OpenShift
Ne përdorim Code Ready Containers nga Red Hat, i cili në thelb është i njëjti Minikube, por me një klaster një-nodësh të plotë OpenShift.
crc start
Hapi 2 â KryejmĂ« ndĂ«rtimin dhe vendosjen e aplikacionit nĂ« klasterin OpenShift
Saktësisht në këtë hap, thjeshtësia dhe lehtësia e OpenShift shfaqen në gjithë shkëlqimin e saj. Ashtu si në të gjitha shpërndarjet e Kubernetes, ne kemi shumë mënyra për të nisur aplikacionin në klaster. Dhe, si në rastin e KUK, ne zgjedhim veçanërisht metodën më të thjeshtë.
OpenShift gjithmonë është ndërtuar si një platformë për krijimin dhe nisjen e aplikacioneve në kontejnerë. Ndërtimi i kontejnerëve ka qenë gjithmonë një pjesë e pandashme e kësaj platforme, prandaj këtu ka shumë burime të tjera Kubernetes për detyra të caktuara.
Ne do të përdorim procesin Source 2 Image (S2I) të OpenShift, i cili ka disa mënyra të ndryshme për të marrë burimin tonë (kodin ose skedarët e binarit) dhe për ta kthyer atë në një imazh kontejneri që do të ekzekutohet në klasterin OpenShift.
Për këtë na nevojiten dy gjëra:
- Kodi ynë burimor në një depo git
- Imazhi Builder, mbi të cilin do të kryhet ndërtimi.
Ekzistojnë shumë imazhe të tillë, të mbështetura si nga Red Hat ashtu edhe në nivelin e komunitetit, dhe ne do të përdorim imazhin OpenJDK, ngase po ndiej të ndërtoj një aplikacion Java.
Mund ta nisni ndërtimin S2I, si nga konsola grafike OpenShift Developer ashtu edhe nga linja e komandës. Ne do ta përdorim komandën new-app, duke i treguar se ku të marrë imazhin build dhe kodin tonë burimor.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
E gjithë, aplikacioni ynë është krijuar. Procesi S2I ka përfunduar këto gjëra:
- Krijova një build-pod shërbimi për çdo gjë që lidhet me ndërtimin e aplikacionit.
- Krijova konfigurimin e OpenShift Build.
- Shkarkova imazhin e builder në regjistrin e brendshëm docker të OpenShift.
- Klonova "Hello World" në repozitorin lokal.
- Pashë që kishte një pom maven, pra kompilova aplikacionin duke përdorur maven.
- Krijova një imazh të ri kontejneri, që përmbante aplikacionin e kompiluar Java, dhe e vendosa këtë imazh në regjistrin e brendshëm të kontejnerëve.
- Krijova një Kubernetes Deployment me specifikimet e pod-it, shërbimit, etj.
- Nisa deploy e imazhit të kontejnerit.
- Fshiva build-pod-in shërbimi.
Në këtë listë ka shumë gjëra, por e rëndësishmja është se të gjithë ndërtimi ndodh ekskluzivisht brenda OpenShift, regjistri i brendshëm Docker ndodhet brenda OpenShift, dhe procesi i ndërtimit krijon të gjitha komponentët Kubernetes dhe i nis ato në klaster.
Nëse ndjekim vizualisht nisjen e S2I në konsolë, mund ta shohim se si gjatë kryerjes së ndërtimit niset build pod.
Tani le të shohim log-et e pod-it builder: së pari, atje shihet se si maven bën punën e tij dhe shkarkon varësi për ndërtimin e aplikacionit tonë java.
Pas pas, përfundimin e ndërtimit maven, nis ndërtimi i imazhit të kontejnerit dhe pastaj ky imazh i ndërtuar dërgohet në depo të brendshme.
Kjo është e gjitha. Procesi i ndërtimit përfundoi. Tani le të sigurohemi se pod't dhe shërbimet e aplikacionit tonë janë aktivizuar në klaster.
oc get service
Kjo është e gjitha. Dhe vetëm një komandë. Tani mbetet të bëjmë expose të këtij shërbimi për qasje nga jashtë.
Hapi 3 â bĂ«jmĂ« expose tĂ« shĂ«rbimit pĂ«r qasje nga jashtĂ«
Si në rastin e KUK, në platformën OpenShift, edhe «Hello World» ynë ka nevojë për një router për të drejtuar trafikun e jashtëm në shërbimin brenda klasterit. Në OpenShift, kjo është shumë e thjeshtë. Së pari, komponenti i rutinës HAProxy është instaluar sipas parazgjedhjes në klaster (mund të zëvendësohet me të njëjtin NGINX). Së dyti, ka burime speciale me mundësi të gjera konfigurimi, të quajtura Routes, që i ngjajnë objekteve Ingress në Kubernetes-in e vjetër (në të vërtetë, Routes nga OpenShift kanë ndikuar shumë në dizajnin e objekteve Ingress, të cilat tani mund të përdoren gjithashtu në OpenShift), por për «Hello World» tonë, dhe në të gjitha rastet e tjera, na mjafton një Route standard pa konfigurim shtesë.
Për të krijuar një FQDN të routuar për 'Hello World' (po, në OpenShift ka DNS të tij për routes sipas emrave të shërbimeve), ne thjesht do të ekzekutojmë expose për shërbimin tonë:
oc expose service quarkus-hello-world
Nëse shikojmë vetëm Route-n e sapokrijuar, atje mund të gjejmë FQDN dhe informacione të tjera rreth routimit:
oc get route
Dhe në fund, qasemi në shërbimin tonë nga shfletuesi:
Tani, kjo ishte me të vërtetë e lehtë!
Ne e duam Kubernetes dhe gjithçka që kjo teknologji na lejon të bëjmë, si dhe ne e duam thjeshtësinë dhe lehtësinë. Kubernetes u krijua për të thjeshtuar jashtëzakonisht operimin e kontejnerëve të shpërndarë dhe të shkallëzueshëm, por për implementimin e aplikacioneve, thjeshtësia e tij sot nuk mjafton. Këtu hyn në lojë OpenShift, i cili ecën me kohën dhe ofron Kubernetes të orientuar kryesisht drejt zhvilluesit. U investua shumë për të përshtatur platformën OpenShift pikërisht për zhvilluesin, duke përfshirë krijimin e mjeteve si S2I, ODI, Developer Portal, OpenShift Operator Framework, integrimin me IDE, Katalogët e Zhvilluesve, integrimin me Helm, monitorimin dhe shumë të tjera.
ShpresojmĂ« se ky artikull ishte i ĐžĐœŃĐ”ŃĐ”Ńançëm dhe i dobishĂ«m pĂ«r ju. Burime shtesĂ«, materiale dhe gjĂ«ra tĂ« tjera tĂ« dobishme pĂ«r zhvillimin nĂ« platformĂ«n OpenShift mund tĂ« gjenden nĂ« portalin .
Burimi: habr.com
