Ky postim u shkrua sepse punonjësit tanë patën mjaft biseda me klientët në lidhje me zhvillimin e aplikacioneve në Kubernetes dhe specifikat e një zhvillimi të tillë në OpenShift.
Zakonisht fillojmë me tezën se Kubernetes është vetëm Kubernetes, dhe OpenShift është tashmë një platformë Kubernetes, si Microsoft AKS ose Amazon EKS. Secila prej këtyre platformave ka avantazhet e veta, që synojnë një audiencë të caktuar të synuar. Dhe pas kësaj, biseda kthehet në krahasimin e pikave të forta dhe të dobëta të platformave specifike.
Në përgjithësi, ne menduam ta shkruanim këtë postim me një përfundim si "Dëgjo, nuk ka rëndësi se ku të ekzekutosh kodin, në OpenShift apo në AKS, në EKS, në disa Kubernete të personalizuara ose në çfarëdo Kubernetes (për shkurt le ta quajmë KUK) "Është vërtet e thjeshtë, si atje ashtu edhe atje."
Më pas kemi planifikuar të marrim "Hello World" më të thjeshtë dhe të përdorim shembullin e tij për të treguar se çfarë është e zakonshme dhe cili është ndryshimi midis KUC dhe Platformës së Kontejnerëve OpenShift Red Hat (në tekstin e mëtejmë, OCP ose thjesht OpenShift).
Sidoqoftë, ndërsa shkruam këtë postim, kuptuam se ishim mësuar të përdornim OpenShift për kaq shumë kohë, saqë thjesht nuk e kuptuam se si ishte rritur dhe u shndërrua në një platformë mahnitëse që u bë shumë më tepër sesa thjesht një shpërndarje Kubernetes. Ne priremi ta marrim si të mirëqenë pjekurinë dhe thjeshtësinë e OpenShift dhe të humbasim shkëlqimin e tij.
Në përgjithësi, ka ardhur koha për pendim aktiv dhe tani do të krahasojmë hap pas hapi vënien në punë të "Hello World" tonë në KUK dhe në OpenShift, dhe këtë do ta bëjmë sa më objektivisht të jetë e mundur (epo, përveçse duke treguar ndonjëherë një qëndrimi personal ndaj temës). Nëse jeni të interesuar për një mendim thjesht subjektiv për këtë çështje, atëherë mund ta lexoni . Dhe në këtë postim do t'i përmbahemi fakteve dhe vetëm fakteve.
Grupimet
Pra, "Hello World" ynë kërkon grupime. Ne do t'i themi menjëherë "jo" çdo reje publike, në mënyrë që të mos paguajmë për serverët, regjistrat, rrjetet, transferimin e të dhënave, etj. Prandaj, ne zgjedhim një grup të thjeshtë me një nyje (për KUK) dhe (për grupimin OpenShift). Të dyja këto opsione janë vërtet të lehta për t'u instaluar, por do të kërkojnë mjaft burime në laptopin tuaj.
Kuvendi në KUK-e
Le të shkojmë.
Hapi 1 – ndërtimi i imazhit të kontejnerit tonë
Le të fillojmë duke vendosur "Hello World" tonë në minikube. Për ta bërë këtë do t'ju duhet:
- 1. Docker i instaluar.
- 2. Git i instaluar.
- 3. Instaluar Maven (në fakt, ky projekt përdor binarin mvnw, kështu që ju mund të bëni pa të).
- 4. Në fakt, vetë burimi, d.m.th. klon depoje
Hapi i parë është krijimi i një projekti Quarkus. Mos u shqetësoni nëse nuk keni punuar kurrë me 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 vetë Quarkus, pa pjesëmarrjen tuaj, konfiguron arketipin maven dhe vendos gjithçka në github. Kjo do të thotë, fjalë për fjalë një klikim të miut dhe ju keni mbaruar. Kjo është arsyeja pse ne e duam Quarkus.
Mënyra më e lehtë për të ndërtuar "Hello World" tonë në një imazh të kontejnerit është përdorimi i shtesave quarkus-maven për Docker, i cili do të bëjë të gjithë punën e nevojshme. Me ardhjen e Quarkus, kjo është bërë vërtet e lehtë dhe e thjeshtë: shtoni zgjerimin e kontejnerit-image-docker dhe mund të krijoni imazhe duke përdorur komandat maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Më në fund, ne ndërtojmë imazhin tonë duke përdorur Maven. Si rezultat, kodi ynë burim shndërrohet në një imazh të gatshëm të kontejnerit që tashmë mund të ekzekutohet në mjedisin e kohës së funksionimit të kontejnerit.
./mvnw -X clean package -Dquarkus.container-image.build=true
Kjo është e gjitha, tani mund ta nisni kontejnerin me komandën docker run, duke e vendosur 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
Pasi të ketë filluar shembulli i kontejnerit, gjithçka që mbetet është të kontrolloni me komandën curl që shërbimi ynë po funksionon:
Pra, gjithçka funksionon dhe ishte vërtet e lehtë dhe e thjeshtë.
Hapi 2 – dërgoni kontejnerin tonë në depon e imazhit të kontejnerit
Për momentin, imazhi që krijuam ruhet në nivel lokal, në ruajtjen tonë lokale të kontejnerit. Nëse duam ta përdorim këtë imazh në mjedisin tonë COOK, atëherë ai duhet të vendoset në ndonjë depo tjetër. Kubernetes nuk ka karakteristika të tilla, kështu që ne do të përdorim dockerhub. Sepse, së pari, është falas, dhe së dyti, (pothuajse) të gjithë e bëjnë atë.
Kjo është gjithashtu shumë e thjeshtë, dhe gjithçka që ju nevojitet është një llogari dockerhub.
Pra, ne instalojmë dockerhub dhe dërgojmë imazhin tonë atje.
Hapi 3 – nisni Kubernetes
Ka shumë mënyra për të mbledhur konfigurimin e kubernetes për të ekzekutuar "Hello World", por ne do të përdorim më të thjeshtat prej tyre, kështu jemi...
Së pari, le të hapim grupin minikube:
minikube start
Hapi 4 - vendos imazhin tonë të kontejnerit
Tani duhet të konvertojmë kodin tonë dhe imazhin e kontejnerit në konfigurime kubernetes. Me fjalë të tjera, na duhet një pod dhe përkufizimi i vendosjes që tregon imazhin tonë të kontejnerit në dockerhub. Një nga mënyrat më të lehta për ta bërë këtë është të ekzekutoni komandën e krijimit të vendosjes duke treguar imazhin tonë:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Me këtë komandë ne i thamë COO-së tonë që të krijojë një konfigurim vendosjeje, i cili duhet të përmbajë specifikimin e pod për imazhin tonë të kontejnerit. Kjo komandë do ta zbatojë gjithashtu këtë konfigurim në grupin tonë minikube dhe do të krijojë një vendosje që do të shkarkojë imazhin e kontejnerit tonë dhe do të nisë podin në grup.
Hapi 5 – hapni aksesin në shërbimin tonë
Tani që kemi një imazh të kontejnerit të vendosur, është koha të mendojmë se si të konfigurojmë aksesin e jashtëm në këtë shërbim Restful, i cili, në fakt, është programuar në kodin tonë.
Ka shumë mënyra këtu. Për shembull, mund të përdorni komandën expose për të krijuar automatikisht komponentët e duhur të Kubernetes, të tilla si shërbimet dhe pikat fundore. Në fakt, kjo është ajo që ne do të bëjmë duke ekzekutuar komandën e ekspozimit për objektin tonë të vendosjes:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Le të marrim një moment për të parë opsionin "-type" të komandës expose.
Kur ekspozojmë dhe krijojmë komponentët e nevojshëm për të ekzekutuar shërbimin tonë, ne, ndër të tjera, duhet të jemi në gjendje të lidhemi nga jashtë me shërbimin hello-quarkus, i cili ndodhet brenda rrjetit tonë të përcaktuar nga softueri. Dhe parametri lloj na lejon të krijojmë dhe lidhim gjëra të tilla si balancuesit e ngarkesës për të drejtuar trafikun në këtë rrjet.
Për shembull, duke shkruar type=LoadBalancer, ne ofrojmë automatikisht një balancues ngarkese në renë publike për t'u lidhur me grupin tonë Kubernetes. Kjo, natyrisht, është e shkëlqyeshme, por duhet të kuptoni se një konfigurim i tillë do të lidhet rreptësisht me një re specifike publike dhe do të jetë më e vështirë për t'u transferuar midis rasteve të Kubernetes në mjedise të ndryshme.
Në shembullin tonë type=NodePort, domethënë, shërbimi ynë aksesohet nga adresa IP dhe numri i portit të nyjës. Ky opsion ju lejon të mos përdorni asnjë re publike, por kërkon një numër hapash shtesë. Së pari, ju nevojitet balancuesi juaj i ngarkesës, kështu që ne do të vendosim balancuesin e ngarkesës NGINX në grupin tonë.
Hapi 6 - instaloni një balancues të ngarkesës
minikube ka një sërë funksionesh platformash që e bëjnë më të lehtë krijimin e komponentëve të aksesueshëm nga jashtë, siç janë kontrollorët e hyrjes. Minikube vjen i bashkuar me kontrolluesin e hyrjes Nginx, dhe gjithçka që duhet të bëjmë është ta aktivizojmë dhe konfigurojmë atë.
minikube addons enable ingress
Tani do të krijojmë një kontrollues të hyrjes Nginx me vetëm një komandë, i cili do të funksionojë brenda grupit tonë minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Hapi 7 - Vendosja e hyrjes
Tani duhet të konfigurojmë kontrolluesin e hyrjes Nginx në mënyrë që ai të pranojë kërkesat hello-quarkus.
Dhe së fundi, ne duhet të aplikojmë këtë konfigurim.
kubectl apply -f ingress.yml
Meqenëse po i bëjmë të gjitha këto në kompjuterin tonë, ne thjesht shtojmë adresën IP të nyjes sonë në skedarin hosts /etc/ për të drejtuar kërkesat http në minikube tonë në balancuesin e ngarkesës NGINX.
192.168.99.100 hello-quarkus.info
Kjo është e gjitha, tani shërbimi ynë minikube është i aksesueshëm nga jashtë përmes kontrolluesit të hyrjes Nginx.
Epo, ishte e lehtë, apo jo? Apo jo aq shumë?
Punon në OpenShift (Kontenierë të gatshëm për kod)
Tani le të shohim se si bëhet e gjithë kjo në Platformën Red Hat OpenShift Container (OCP).
Ashtu si me minikube, ne zgjedhim një dizajn grupi OpenShift me një nyje në formën e kontejnerëve të gatshëm për kod (CRC). Më parë, ai quhej minishift dhe bazohej në projektin OpenShift Origin, por tani është CRC dhe i ndërtuar në platformën OpenShift Container të Red Hat.
Këtu, na vjen keq, nuk mund të mos themi: "OpenShift është i mrekullueshëm!"
Fillimisht menduam të shkruanim se zhvillimi në OpenShift nuk ndryshon nga zhvillimi në Kubernetes. Dhe në thelb kështu është. Por në procesin e shkrimit të këtij postimi, ne kujtuam se sa lëvizje shtesë duhet të bëni kur nuk keni OpenShift, dhe kjo është arsyeja pse, përsëri, është e mrekullueshme. Ne e duam kur gjithçka bëhet me lehtësi, dhe sa i lehtë është shembulli ynë për t'u vendosur dhe ekzekutuar në OpenShift në krahasim me minikube është ajo që na shtyu të shkruajmë këtë postim.
Le të kalojmë procesin dhe të shohim se çfarë duhet të bëjmë.
Pra, në shembullin minikube, ne filluam me Docker... Prisni, nuk kemi më nevojë për Docker të instaluar në makinë.
Dhe ne nuk kemi nevojë për pajisje lokale.
Dhe Maven nuk është i nevojshëm.
Dhe nuk keni nevojë të krijoni një imazh të kontejnerit me duart tuaja.
Dhe nuk keni pse të kërkoni ndonjë depo të imazheve të kontejnerëve.
Dhe nuk ka nevojë të instaloni një kontrollues hyrje.
Dhe nuk keni nevojë të konfiguroni as hyrjen.
E kuptoni, apo jo? Për të vendosur dhe ekzekutuar aplikacionin tonë në OpenShift, nuk ju nevojitet asnjë nga sa më sipër. Dhe vetë procesi duket kështu.
Hapi 1 – Nisni grupin tuaj OpenShift
Ne përdorim Code Ready Containers nga Red Hat, i cili është në thelb i njëjti Minikube, por vetëm me një grup Openshift me një nyje të plotë.
crc start
Hapi 2 – Ndërtoni dhe vendosni aplikacionin në grupin OpenShift
Është në këtë hap që thjeshtësia dhe komoditeti i OpenShift zbulohen në të gjithë lavdinë e tij. Ashtu si me të gjitha shpërndarjet Kubernetes, ne kemi shumë mënyra për të ekzekutuar një aplikacion në një grup. Dhe, si në rastin e KUK-së, ne posaçërisht zgjedhim më të thjeshtën.
OpenShift është ndërtuar gjithmonë si një platformë për krijimin dhe ekzekutimin e aplikacioneve të kontejnerizuara. Ndërtimi i kontejnerëve ka qenë gjithmonë një pjesë integrale e kësaj platforme, kështu që ka një ton burimesh shtesë Kubernetes për detyrat e lidhura.
Ne do të përdorim procesin OpenShift Source 2 Image (S2I), i cili ka disa mënyra të ndryshme për të marrë burimin tonë (kodin ose binarët) dhe për ta kthyer atë në një imazh të kontejneruar që funksionon në një grup OpenShift.
Për ta bërë këtë na duhen dy gjëra:
- Kodi ynë burim është në depon e git
- Imazhi i ndërtuesit mbi bazën e të cilit do të kryhet ndërtimi.
Ka shumë imazhe të tilla të mbajtura si nga Red Hat ashtu edhe në nivel komuniteti, dhe ne do të përdorim imazhin OpenJDK, mirë, pasi unë jam duke ndërtuar një aplikacion Java.
Ju mund të ekzekutoni ndërtimin S2I si nga tastiera grafike OpenShift Developer ashtu edhe nga linja e komandës. Ne do të përdorim komandën e aplikacionit të ri, duke i treguar se ku të marrë imazhin e ndërtuesit dhe kodin tonë burimor.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Kjo është e gjitha, aplikacioni ynë është krijuar. Duke vepruar kështu, procesi S2I bëri gjërat e mëposhtme:
- Krijoi një build-pod shërbimi për të gjitha llojet e gjërave që lidhen me ndërtimin e aplikacionit.
- Krijoi konfigurimin OpenShift Build.
- Kam shkarkuar imazhin e ndërtuesit në regjistrin e brendshëm të dokerit OpenShift.
- Klonuar "Hello World" në depon lokale.
- Pashë që kishte një maven pom atje, kështu që e përpilova aplikacionin duke përdorur maven.
- Krijoi një imazh të ri të kontejnerit që përmban aplikacionin e përpiluar Java dhe vendosi këtë imazh në regjistrin e brendshëm të kontejnerit.
- Krijoi Kubernetes Deployment me specifika për pod, shërbim, etj.
- Fillova të vendos imazhin e kontejnerit.
- U hoq build-pod i shërbimit.
Ka shumë në këtë listë, por gjëja kryesore është se e gjithë ndërtimi ndodh ekskluzivisht brenda OpenShift, regjistri i brendshëm i Docker është brenda OpenShift dhe procesi i ndërtimit krijon të gjithë komponentët Kubernetes dhe i ekzekuton ato në grup.
Nëse monitoroni vizualisht nisjen e S2I në tastierë, mund të shihni se si lansohet build pod kur të përfundojë ndërtimi.
Tani le të hedhim një vështrim në regjistrat e pod ndërtues: së pari, ai tregon se si maven e bën punën e tij dhe shkarkon varësitë për të ndërtuar aplikacionin tonë java.
Pasi të përfundojë ndërtimi i maven, fillon ndërtimi i imazhit të kontejnerit dhe më pas ky imazh i ndërtuar dërgohet në depon e brendshme.
Kjo është e gjitha, procesi i ndërtimit ka përfunduar. Tani le të sigurohemi që pods dhe shërbimet e aplikacionit tonë të funksionojnë në grup.
oc get service
Kjo eshte e gjitha. Dhe vetëm një ekip. Gjithçka që duhet të bëjmë është ta ekspozojmë këtë shërbim për akses nga jashtë.
Hapi 3 – ekspozoni shërbimin për akses nga jashtë
Ashtu si në rastin e KUC, në platformën OpenShift, "Hello World" ynë ka nevojë gjithashtu për një ruter për të drejtuar trafikun e jashtëm në shërbimin brenda grupit. OpenShift e bën këtë shumë të lehtë. Së pari, komponenti i rrugëzimit HAProxy është instaluar në grup si parazgjedhje (mund të ndryshohet në të njëjtin NGINX). Së dyti, ka burime të veçanta dhe shumë të konfigurueshme të quajtura Rrugë dhe që të kujtojnë objektet e Ingress në Kubernetes të mirë të vjetër (në fakt, Rrugët e OpenShift ndikuan shumë në hartimin e objekteve Ingress, të cilat tani mund të përdoren në OpenShift) , por për "Hello World" tonë. , dhe pothuajse në të gjitha rastet e tjera, Rruga standarde është e mjaftueshme për ne pa konfigurim shtesë.
Për të krijuar një FQDN të rutueshme për "Hello World" (po, OpenShiift ka DNS-në e vet për rrugëtim sipas emrave të shërbimeve), ne thjesht do të ekspozojmë shërbimin tonë:
oc expose service quarkus-hello-world
Nëse shikoni rrugën e krijuar rishtazi, mund të gjeni FQDN dhe informacione të tjera të rrugëtimit atje:
oc get route
Dhe së fundi, ne hyjmë në shërbimin tonë nga shfletuesi:
Por tani ishte vërtet e lehtë!
Ne e duam Kubernetes dhe gjithçka që kjo teknologji na lejon të bëjmë, dhe na pëlqen gjithashtu thjeshtësia dhe lehtësia. Kubernetes u krijua për të thjeshtuar jashtëzakonisht funksionimin e kontejnerëve të shpërndarë, të shkallëzuar, por thjeshtësia e tij nuk është më e mjaftueshme për të vënë aplikacionet në prodhim sot. Këtu hyn në lojë OpenShift, duke ecur në hap me kohën dhe duke ofruar Kubernetes, që synon kryesisht zhvilluesin. Është investuar shumë përpjekje për të përshtatur platformën OpenShift posaçërisht për zhvilluesin, duke përfshirë krijimin e mjeteve të tilla si S2I, ODI, Developer Portal, OpenShift Operator Framework, Integrimi IDE, Katalogët e Zhvilluesve, Integrimi i Helm, monitorimi dhe shumë të tjera.
Shpresojmë që ky artikull të ishte interesant dhe i dobishëm për ju. Ju mund të gjeni burime shtesë, materiale dhe gjëra të tjera të dobishme për zhvillim në platformën OpenShift në portal .
Burimi: www.habr.com