Ky ky ĐżĐŸŃŃ Ă«shtĂ« shkruar sepse punonjĂ«sit tanĂ« kanĂ« pasur shumĂ« biseda me klientĂ«t rreth zhvillimit tĂ« aplikacioneve nĂ« Kubernetes dhe karakteristikave tĂ« kĂ«tij zhvillimi nĂ« OpenShift.
Ne zakonisht e fillojmĂ« me tezĂ«n se Kubernetes Ă«shtĂ« thjesht Kubernetes, ndĂ«rsa OpenShift Ă«shtĂ« njĂ« platformĂ« Kubernetes, si Microsoft AKS ose Amazon EKS. Ădo njĂ«ri nga kĂ«to platforma ka avantazhet e veta, tĂ« fokusuara nĂ« audiencĂ«n pĂ«rkatĂ«se. Pas kĂ«saj, biseda kalon nĂ« krahasimin e forcave dhe dobĂ«sive tĂ« platformave tĂ« caktuara.
NĂ« pĂ«rgjithĂ«si, mendonim tĂ« shkruanim kĂ«tĂ« post me pĂ«rfundimin se "DĂ«gjoni, nuk ka rĂ«ndĂ«si ku e drejtoni kodin, nĂ« OpenShift, AKS, EKS, ose ndonjĂ« Kubernetes tjetĂ«r, madje nĂ« çfarĂ«do Kubernetes-i," (pĂ«r shkak tĂ« shkurtimit le tĂ« thĂ«rrasim atĂ« KUK) â Ă«shtĂ« e vĂ«rtetĂ« thjesht, dhe aty dhe aty.
Më pas, planifikonim të merrnim një "Hello World" të thjeshtë dhe me shembullin e tij të tregojmë se çfarë kanë të përbashkët dhe çfarë dallimesh ka midis KUK dhe Red Hat OpenShift Container Platform (në vazhdim, OCP ose thjesht OpenShift).
Megjithatë, gjatë procesit të shkruarjes së këtij posti, kuptuam se ishim aq të zakonshëm me përdorimin e OpenShift, saqë thjesht nuk e kuptojmë sesi ai është rritur dhe shndërruar në një platformë të mrekullueshme, e cila është bërë shumë më tepër se thjesht një distribucion Kubernetes. Ne e kemi marrë moshën dhe thjeshtësinë e OpenShift për të mirëqenë, duke lënë mënjanë madhështinë e tij.
Kështu, ka ardhur koha për një pendim aktiv, dhe tani do të krahasojmë hap pas hapi aktivizimin e "Hello World" tonë në KUK dhe në OpenShift, duke e bërë këtë sa më objektivisht (me përjashtim të ndonjëherë kur shprehim një qëndrim personal për subjektin). Nëse ju intereson një mendim thjesht subjektiv mbi këtë çështje, mund ta lexoni . Në këtë post do të ndjekim fakte dhe vetëm fakte.
Klastrat
Pra, për "Hello World" tonë na duhen klastra. Të themi "jo" çdo titulli publik të cloud-it, që të mos paguajmë për servera, regjistra, rrjete, transmetime të të dhënave etj. Kështu, ne zgjedhim një klasër të thjeshtë një-nodësh në (për KUK) dhe (për klastrin OpenShift). Të dy këto mundësi janë vërtet të thjeshta për instalim, por kërkojnë shumë burime në laptopin tuaj.
Ndërtimi në KUK
Pra, le të fillojmë.
Hapi 1 â ne ndĂ«rrtojmĂ« imazhin tonĂ« tĂ« kontejnerit
Le të fillojmë duke e aktivizuar "Hello World" tonë në minikube. Për këtë kërkohet:
- 1. Docker i instaluar.
- 2. Git i instaluar.
- 3. Maven që është vendosur (në fakt, në këtë projekt përdoret binari mvnw, kështu që mund ta kaloni këtë hap).
- 4. Në fakt, vetë burimi, dmth, kloni i depozitës
Hapi i parĂ« Ă«shtĂ« krijimi i njĂ« projekti Quarkus. Mos u frikĂ«soni nĂ«se nuk keni punuar ndonjĂ«herĂ« me faqen Quarkus.io â Ă«shtĂ« e thjeshtĂ«. 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Ă« automatikisht arketipin maven dhe do ta ngrejĂ« gjithçka nĂ« github. DomethĂ«nĂ«, me njĂ« klik tĂ« vetĂ«m tĂ« mausit â dhe Ă«shtĂ« gati. Ky Ă«shtĂ« arsyeja pse e duam Quarkus.
Mënyra më e thjeshtë për të ndërtuar 'Hello World' në një imazh kontejneri është të përdorim zgjerimet quarkus-maven për Docker, të cilat do të kryejnë të gjithë punën e nevojshme. Me ardhjen e Quarkus, kjo është bërë vërtet e lehtë dhe e thjeshtë: thjesht shtoni zgjerimin container-image-docker dhe mund të krijoni imazhe me komandat maven.
. /mvnw quarkus:add-extension -Dextensions="container-image-docker"
Dhe, përfundimisht, kryejmë ndërtimin e imazhit tonë duke përdorur Maven. Si rezultat, kodi ynë burimor kthehet në një imazh kontejneri të gatshëm për t'u ekzekutuar në ambientin e ekzekutimit të kontejnerëve.
. /mvnw -X clean package -Dquarkus.container-image.build=true
Këtu, në fakt, është gjithçka, tani mund të nisim kontejnerin me komandën docker run, duke i vendosur shërbimin tonë në portin 8080 për t'u qasur mbi të.
docker run -i â rm -p 8080:8080 gcolman/quarkus-hello-world
Pasi instanca e kontejnerit është nisur, mbetet vetëm të kontrolloni me komandën curl që shërbimi ynë po punon:
Pra, gjithçka funksionon, dhe ishte vërtet e lehtë dhe e thjeshtë.
Hapi 2 â dĂ«rgojmĂ« kontejnerin tonĂ« nĂ« depozitĂ«n e imazheve tĂ« kontejnerĂ«ve
Derisa, imazhi që krijuam ruhet lokalisht, në ruajtjen tonë lokale të kontejnerëve. Nëse dëshirojmë ta përdorim këtë imazh në mjedisin tonë K8s, duhet ta ngremë në një depo tjetër. Në Kubernetes nuk ka funksione të tilla, prandaj do të përdorim dockerhub. Sepse, së pari, është falas, dhe së dyti, (më tërë) të gjithë e bëjnë kështu.
Kjo është gjithashtu shumë e thjeshtë, dhe këtu ne na duhen vetëm një llogari në dockerhub.
Pra, le t'i vendosim dockerhub dhe ta dërgojmë atje imazhin tonë.
Hapi 3 â nisim Kubernetes
Ka shumë mënyra për të ndërtuar konfigurimin e Kubernetes për të nisur 'Hello World' tonë, por do të përdorim më të thjeshtën, sepse kështu jemi ne...
Fillimisht nisim klasterin minikube:
minikube start
Hapi 4 â zhvillojmĂ« imazhin tonĂ« tĂ« kontejnerit
Tani duhet të konvertojmë kodin tonë dhe imazhin e kontejnerit në konfigurimet e Kubernetes. Me fjalë të tjera, na nevojiten definita të pod-it dhe deploy-it me referencë në imazhin tonë në Docker Hub. Një nga mënyrat më të thjeshta për ta bërë këtë është të ekzekutojmë komandën e krijimit të deploy-it, duke iu referuar imazhit tonë:
kubectl create deployment hello-quarkus --image=gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Me këtë komandë i thamë Kubernetesit tonë të krijojë një konfigurim deploy-i, 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ë deploy që do të shkarkojë imazhin tonë të kontejnerit dhe do të nisë pod-in në klaster.
Hapi 5 â hapim qasjen nĂ« shĂ«rbimin tonĂ«
Tani, kur kemi imazhin e kontejnerit të zhvilluar, është koha të mendojmë për mënyrën e konfigurimit të qasjes eksterrne në këtë shërbim Restful, i cili, në fakt, është programuar në kodin tonë.
Ka shumë mënyra për ta bërë këtë. Për shembull, mund të përdorim komandën expose për të krijuar automatikisht komponentët përkatës të Kubernetes, si shërbimet dhe endpointet. Në fakt, kështu do ta bëjmë, duke ekzekutuar komandën expose për objektin tonë të deploy-it:
kubectl expose deployment hello-quarkus --type=NodePort --port=8080
Le të ndalemi për një moment mbi opsionin "--type" të komandës expose.
Kur bëjmë expose dhe krijojmë komponentët e nevojshëm për të nisur shërbimin tonë, ndër të tjera, na nevojitet që të jashtme të jetë e mundur të lidhet me shërbimin hello-quarkus, i cili ndodhet brenda rrjetit tonë të programueshëm. Dhe parametri lloji na lejon të krijojmë dhe lidhemi me elemente si balancuesit e ngarkesës për të drejtuar trafikun në këtë rrjet.
Për shembull, duke shkruar type=LoadBalancer, ne automatikisht inicojmë një balancues ngarkese në re të hapur për të u lidhur me klasterin tonë Kubernetes. Kjo, sigurisht, është mrekullueshme, por duhet të kuptojmë se një konfigurim i tillë do të jetë i lidhur ngushtësisht me një re të caktuar dhe do të jetë më e vështirë për t'u migruar midis instancave të Kubernetes në mjedise të ndryshme.
Në shembullin tonë type=NodePort, që do të thotë se kërkesa për shërbimin tonë bëhet përmes adresës IP të nodës dhe numrit të portës. Ky variant lejon që të mos përdorim asnjë cloud publik, por kërkon disa hapa shtesë. Së pari, na nevojitet një balancues ngarkese privat, prandaj do të krijojmë në klasterin tonë balancuesin e ngarkesës NGINX.
Hapi 6 â vendosja e balancuesit tĂ« ngarkesĂ«s
Minikube ka një sërë funksionesh të platformës që lehtësojnë krijimin e komponenteve të nevojshme për qasje nga jashtë, siç janë kontrollorët ingress. Minikube vjen me kontrollorin ingress Nginx, dhe na mbetet vetëm ta aktivizojmë dhe ta konfigurajmë.
minikube addons enable ingress
Tani me një komandë krijojmë kontrollorin ingress Nginx, i cili do të funksionojë brenda klasterit tonë minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Duke funksionuar 1 33m
Hapi 7 â Konfigurimi i ingress
Tani duhet të konfigurojmë kontrollorin ingress Nginx, që të pranojë kërkesat hello-quarkus.
Dhe, përfundimisht, duhet të aplikojmë këtë konfigurim.
kubectl apply -f ingress.yml
Duke qenë se i bëjmë gjithë këtë në kompjuterin tonë, thjesht shtojmë adresën IP të nodës sonë në skedarin /etc/hosts, për të drejtuar kërkesat http drejt minikube tonë në balancuesin e ngarkesës NGINX.
192.168.99.100 hello-quarkus.info
Gjithçka, tani shërbimi ynë minikube është i aksesueshëm nga jashtë përmes kontrollorit ingress Nginx.
Ajo ishte e lehtë, apo jo? Ose jo aq shumë?
Ekzekutimi në OpenShift (Code Ready Containers)
Tani le të shohim se si bëhet gjithë kjo në Red Hat OpenShift Container Platform (OCP).
Si në rastin e minikube, ne zgjedhim skemën me një klaster të vetëm OpenShift në formën e Code Ready Containers (CRC). Më parë kjo quhej minishift dhe është bazuar në projektin OpenShift Origin, dhe tani është CRC, e ndërtuar mbi platformën Red Hat OpenShift Container.
Këtu, na falni, nuk mund të përmbaheshim pa thënë: 'OpenShift është madhështor!'
Fillimisht menduam të shkruajmë se zhvillimi në OpenShift nuk është ndryshe nga zhvillimi në Kubernetes. Dhe në thelb, kështu është. Por gjatë shkrimit të këtij postimi, na erdhi në mendje se sa shumë ndërlikime ka kur s'ke OpenShift, dhe prandaj, po e përsërisim, është madhështor. Ne i duam gjërat të thjeshta, dhe mënyra se si lehtë zvogëlohet shembulli ynë në OpenShift krahasuar me minikube, në fakt, na nxiti të shkruajmë këtë post.
Le të kalojmë në proces dhe të shohim çfarë na nevojitet të bëjmë.
Kështu, në shembullin e minikube filluam me Docker⊠Prit, nuk na nevojitet më që në makinë të jetë instaluar Docker.
Dhe git lokal nuk na nevojitet.
As Maven nuk është i nevojshëm.
As nuk nevojitet të krijojmë manualisht imazhin e kontejnerit.
As nuk nevojitet të kërkojmë një repository për imazhet e kontejnerëve.
As nuk nevojitet të instalojmë një kontrollues ingress.
As nuk nevojitet të konfigurojmë ingress.
E kuptuat, apo jo? Për të vendosur dhe drejtuar aplikacionin tonë në OpenShift, nuk duhen nga ato që përmendëm më lart. Procesi vetë duket si më poshtë.
Hapi 1 â Nisim klasterin tonĂ« OpenShift
Ne përdorim Code Ready Containers nga Red Hat, i cili në thelb është i njëjti si Minikube, por me një klaster të plotë një-nod i Openshift.
crc start
Hapi 2 â KryejmĂ« ndĂ«rtimin dhe vendosjen e aplikacionit nĂ« klasterin OpenShift
Në këtë hap, thjeshtësia dhe lehtësia e OpenShift shfaqen në mbarë hapsirën. Si në të gjitha shpërndarjet e Kubernetes, kemi shumë mënyra për të vendosur aplikacionin në klaster. Dhe, si në rastin e KUK, ne zgjedhim qëllimisht atë më të lehtë.
OpenShift gjithmonë është ndërtuar si një platformë për krijimin dhe drejtpërdrejtimin e aplikacioneve të kontejnerëve. Ndërtimi i konteinerëve ka qenë gjithmonë një pjesë e pandarë e kësaj platforme, ndaj këtu ka shumë burime shtesë Kubernetes për detyra përkatëse.
Ne do të përdorim procesin OpenShift Source 2 Image (S2I), i cili ka disa mënyra të ndryshme për të marrë kodin tonë burimor (ose skedarët binarë) dhe për ta shndërruar atë në një imazh kontejneri që do të ekzekutohet në klasterin OpenShift.
Për këtë, do na nevojiten dy gjëra:
- Kodi ynë burimor në një repository git
- Imazhi Builder, mbi bazën e të cilit do të kryhet ndërtimi.
Ka shumë imazhe të tilla, të mbështetura si nga Red Hat ashtu edhe nga komuniteti, dhe ne do të përdorim imazhin OpenJDK, pasi po ndërtuoj një aplikacion Java.
Të nisim ndërtimin S2I mund të bëhet 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ë merrte imazhin builder dhe kodin tonë burimor.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Këtu, aplikacioni ynë është krijuar. Procesi S2I ka realizuar këto gjëra:
- Krijoi një build-pod të shërbimit për gjëra që lidhen me ndërtimin e aplikacionit.
- Krijoi konfigurimin e OpenShift Build.
- Shkarkoi imazhin builder në registrin e brendshëm docker të OpenShift.
- Kllonoi "Hello World" në repository-n tonë lokale.
- Pashë se kishte një maven pom, prandaj e 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-in e imazhit të kontejnerit.
- Fshiva pod-in ndihmës build.
Në këtë listë ka shumë gjëra, por e rëndësishmja është se e gjithë ndërtimi ndodh ekskluzivisht brenda OpenShift-it, regjistri i brendshëm Docker ndodhet brenda OpenShift-it, dhe procesi i ndërtimit krijon të gjithë komponentët Kubernetes dhe i nis ata në klaster.
Nëse e ndjekim vizualisht nisjen S2I në konsolë, mund të shohim si gjatë ndërtimit niset pod-i i ndërtimit.
Dhe tani le të shohim log-et e pod-it builder: së pari, aty shihet si maven bën punën e tij dhe shkarkon varësitë për ndërtimin e aplikacionit tonë java.
Pas përfundimit të ndërtimit maven, niset ndërtimi i imazhit të kontejnerit, dhe pastaj ky imazh i ndërtuar dërgohet në repo-in e brendshëm.
Këtu është, procesi i ndërtimit përfundoi. Tani sigurohemi që pod-et dhe shërbimet e aplikacionit tonë janë nisur në klaster.
oc get service
Këtu është gjithçka. Dhe vetëm një komandë. Na 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, asaj «Hello World» i nevojitet gjithashtu një router për të drejtuar trafikun e jashtëm në shërbimin brenda klasterit. Në OpenShift kjo bëhet shumë lehtë. Së pari, në klaster ka një komponent të routing-ut HAProxy të instaluar si standard (mund ta zëvendësojmë me NGINX). Së dyti, ka burime speciale dhe shumë të qarta që quhen Routes dhe i ngjajnë objekteve Ingress në Kubernetes-in e dikurshëm (në fakt, Routes të OpenShift kanë pasur një ndikim të madh në dizajnin e objekteve Ingress, të cilat tani mund të përdoren edhe në OpenShift), por për «Hello World» tonë, madje dhe në shumicën e rasteve të tjera, ne do të mjaftohemi me Route-in standard pa konfigurim shtesë.
Për të krijuar një FQDN të ruterizuar për «Hello World» (po, në OpenShift ka DNS të vet për routing me emra shërbimesh), ne thjesht do të ekzekutojmë expose për shërbimin tonë:
oc expose service quarkus-hello-world
Nëse shohim Route-in sapo të krijuar, aty mund të gjenden FQDN dhe detaje të tjera mbi routing:
oc get route
Dhe për në fund, i qasemi shërbimit tonë nga shfletuesi:
Por tani tani ishte vërtet e lehtë!
Ne e duam Kubernetes dhe gjithçka që kjo teknologji ofron, si dhe ne e duam thjeshtësinë dhe lehtësinë. Kubernetes u krijua për të thjeshtuar në mënyrë të jashtëzakonshme operimin e kontejnerëve të shpërndara dhe të shkallëzueshme, por thjeshtësia e tij nuk mjafton më sot për të futur aplikacionet në funksion. Këtu hyn në lojë OpenShift, i cili është në hap me kohën dhe ofron Kubernetes të orientuar kryesisht ndaj zhvilluesve. U investua shumë për ta përshtatur platformën OpenShift specifikisht për zhvilluesit, duke përfshirë krijimin e instrumenteve të tillë si S2I, ODI, Portali për Zhvilluesit, OpenShift Operator Framework, integrimin me IDE, Katalogët e Zhvilluesve, integrimin me Helm, monitorimin dhe shumë të tjera.
Shpresojmë që ky artikull ishte interesant dhe i dobishëm për ju. Dhe mund të gjeni burime shtesë, materiale dhe gjëra të tjera të dobishme për zhvillimin në platformën OpenShift në portalin .
Burimi: habr.com
