Mezu hau idatzi da gure langileek bezeroekin Kubernetes-en aplikazioen garapenari buruz eta OpenShift-en garapen horren berezitasunei buruz elkarrizketa asko izan dituztelako.
Normalean Kubernetes Kubernetes besterik ez dela dioen tesiarekin hasten gara, eta OpenShift dagoeneko Kubernetes plataforma bat dela, Microsoft AKS edo Amazon EKS bezala. Plataforma horietako bakoitzak bere abantailak ditu, xede-publiko jakin bati zuzenduta. Eta horren ostean, elkarrizketa plataforma zehatzen indarguneak eta ahuleziak alderatzera jotzen du.
Orokorrean, post hau "Entzun, ez du axola non exekutatu kodea, OpenShift-en edo AKS-n, EKS-n, Kubernetes pertsonalizatu batzuetan edo edozein Kubernetes-en" bezalako ondorio batekin idaztea pentsatu dugu. (Laburtasunagatik deitu dezagun KUK) Β«Benetan erraza da, bai han eta baita hanΒ».
Ondoren, "Hello World" sinpleena hartu eta bere adibidea erabiltzea aurreikusi genuen KUC eta Red Hat OpenShift Container Platform (aurrerantzean, OCP edo OpenShift besterik gabe) zer den ohikoa eta zein desberdintasun dagoen erakusteko.
Hala ere, argitalpen hau idatzi ahala, konturatu ginen hainbeste denboraz OpenShift erabiltzen ohituta geundela, ezen ez ginen konturatu nola hazi zen eta Kubernetes banaketa hutsa baino askoz gehiago bihurtu zen plataforma harrigarri batean bihurtu zen. OpenShift-en heldutasuna eta sinpletasuna berebizikotzat hartu ohi dugu, eta bere distira bistatik galtzen dugu.
Orokorrean, damu aktiborako garaia iritsi da, eta orain pausoz pauso alderatuko dugu gure βKaixo Munduaβ martxan jartzea KUK-en eta OpenShift-en, eta hori ahalik eta objektiboen egingo dugu (beno, batzuetan bat erakutsi izan ezik). gaiarekiko jarrera pertsonala). Gai honi buruzko iritzi subjektibo hutsa interesatzen bazaizu, irakur dezakezu . Eta post honetan gertakariei eutsiko diegu eta gertakariei bakarrik.
Klusterrak
Beraz, gure "Hello World"-ek klusterrak behar ditu. Berehala esango diegu βezβ edozein hodei publikori, zerbitzariak, erregistroak, sareak, datu-transferentzia eta abar ez ordaintzeko. Horren arabera, nodo bakarreko kluster sinple bat aukeratzen dugu (KUK-rako) eta (OpenShift klustererako). Bi aukera hauek oso errazak dira instalatzeko, baina baliabide asko beharko dituzte zure ordenagailu eramangarrian.
KUK-e-n muntaia
Goazen, beraz.
1. urratsa - gure edukiontziaren irudia eraikitzea
Has gaitezen gure βKaixo munduaβ zabaltzen minikube-ra. Horretarako behar izango duzu:
- 1. Docker instalatuta.
- 2. Git instalatuta.
- 3. Maven instalatu (egia esan, proiektu honek mvnw bitarra erabiltzen du, beraz, gabe egin dezakezu).
- 4. Egia esan, iturria bera, alegia. biltegiko klona
Lehen urratsa Quarkus proiektu bat sortzea da. Ez kezkatu inoiz Quarkus.io-rekin lan egin ez baduzu - erraza da. Proiektuan erabili nahi dituzun osagaiak hautatzea besterik ez duzu (RestEasy, Hibernate, Amazon SQS, Camel, etab.), eta gero Quarkusek berak, zure parte-hartzerik gabe, maven arketipoa konfiguratzen du eta dena github-en jartzen du. Hau da, literalki saguaren klik bat eta listo. Horregatik maite dugu Quarkus.
Gure "Hello World" edukiontzi-irudi batean eraikitzeko modurik errazena Docker-erako quarkus-maven luzapenak erabiltzea da, beharrezko lan guztia egingo baitu. Quarkus-en etorrerarekin, hau oso erraza eta sinplea bihurtu da: gehitu edukiontzi-irudi-docker luzapena eta irudiak sor ditzakezu maven komandoak erabiliz.
./mvnw quarkus:add-extension -Dextensions=βcontainer-image-dockerβ
Azkenik, gure irudia Maven erabiliz eraikitzen dugu. Ondorioz, gure iturburu-kodea edukiontzien exekuzio-ingurunean dagoeneko exekutatu daitekeen edukiontzi-irudi prest bihurtzen da.
./mvnw -X clean package -Dquarkus.container-image.build=true
Hori da guztia, orain edukiontzia abiarazi dezakezu docker run komandoarekin, gure zerbitzua 8080 atakan mapatuz, atzitu ahal izateko.
docker run -i β rm -p 8080:8080 gcolman/quarkus-hello-world
Edukiontziaren instantzia hasi ondoren, gure zerbitzua exekutatzen ari den curl komandoarekin egiaztatzea besterik ez da geratzen:
Beraz, dena funtzionatzen du eta oso erraza eta erraza izan zen.
2. urratsa - bidali gure edukiontzia edukiontzien irudi biltegira
Oraingoz, sortu dugun irudia lokalean gordetzen da, gure tokiko edukiontzien biltegian. Irudi hau gure COOK ingurunean erabili nahi badugu, beste biltegi batean jarri behar da. Kubernetes-ek ez ditu horrelako ezaugarriak, beraz, dockerhub erabiliko dugu. Lehenik eta behin, doan delako, eta bigarrenik, (ia) denek egiten dutelako.
Hau ere oso erraza da, eta behar duzun guztia dockerhub kontu bat da.
Beraz, dockerhub instalatzen dugu eta hara bidaltzen dugu gure irudia.
3. urratsa - abiarazi Kubernetes
Kubernetes-en konfigurazioa muntatzeko modu asko daude gure βKaixo Munduaβ exekutatzeko, baina horietako sinpleenak erabiliko ditugu, horrela gaude...
Lehenik eta behin, abiarazi dezagun minikube klusterra:
minikube start
4. urratsa: zabaldu gure edukiontziaren irudia
Orain gure kodea eta edukiontziaren irudia kubernetes konfigurazio bihurtu behar ditugu. Beste era batera esanda, dockerhub-eko edukiontziaren irudira seinalatzen duen pod eta inplementazio definizio bat behar dugu. Horretarako modurik errazenetako bat gure irudira seinalatzen duen sortu inplementazio komandoa exekutatzen da:
kubectl create deployment hello-quarkus β image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Komando honekin gure COO inplementazio konfigurazio bat sortzeko esan genion, gure edukiontziaren irudiaren pod zehaztapena eduki beharko lukeena. Komando honek konfigurazio hau gure minikube klusterrean ere aplikatuko du, eta gure edukiontziaren irudia deskargatuko duen inplementazio bat sortuko du eta klusterrean poda abiaraziko duena.
5. urratsa - ireki gure zerbitzurako sarbidea
Edukiontzi-irudi bat zabalduta daukagunez, gure kodean programatuta dagoen Restful zerbitzu honetara kanpoko sarbidea nola konfiguratu pentsatzeko garaia da.
Modu asko daude hemen. Adibidez, expose komandoa erabil dezakezu Kubernetes-en osagai egokiak automatikoki sortzeko, hala nola zerbitzuak eta amaiera-puntuak. Egia esan, hau da gure inplementazio-objekturako expose komandoa exekutatuz egingo duguna:
kubectl expose deployment hello-quarkus β type=NodePort β port=8080
Har dezagun une bat expose komandoaren "-type" aukera aztertzeko.
Gure zerbitzua exekutatzeko beharrezkoak diren osagaiak azaltzen eta sortzen ditugunean, guk, besteak beste, kanpotik konektatu behar dugu hello-quarkus zerbitzura, gure softwareak definitutako sarearen barruan dagoena. Eta parametroa mota karga-orekatzaileak bezalako gauzak sortu eta konektatzeko aukera ematen digu trafikoa sare honetara bideratzeko.
Adibidez, idatziz mota=LoadBalancer, automatikoki hornitzen dugu karga-orekatzailea hodei publikoan gure Kubernetes klusterera konektatzeko. Hau, noski, bikaina da, baina ulertu behar duzu konfigurazio hori hodei publiko zehatz bati hertsiki lotuta egongo dela eta ingurune ezberdinetan Kubernetes instantzien artean transferitzea zailagoa izango dela.
Gure adibidean mota=NodePorta, hau da, gure zerbitzua nodoaren IP helbidea eta ataka zenbakiaren bidez sartzen da. Aukera honek hodei publikorik ez erabiltzeko aukera ematen du, baina urrats gehigarri batzuk behar ditu. Lehenik eta behin, zure karga-orekatzailea behar duzu, beraz, NGINX karga-orekatzailea zabalduko dugu gure klusterrean.
6. urratsa: instalatu karga-orekatzailea
minikube-k plataforma-funtzio batzuk ditu, kanpotik eskura daitezkeen osagaiak sortzea errazten dutenak, hala nola sarrera kontrolatzaileak. Minikube Nginx sarrera kontrolagailuarekin batera dator, eta egin behar dugun guztia gaitzea eta konfiguratzea da.
minikube addons enable ingress
Orain Nginx sarrera kontroladore bat sortuko dugu komando bakarrarekin, gure minikube kluster barruan funtzionatuko duena:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
7. urratsa - Sarrera konfiguratzea
Orain Nginx sarrera kontrolatzailea konfiguratu behar dugu, kaixo-quarkus eskaerak onar ditzan.
Eta azkenik, konfigurazio hau aplikatu behar dugu.
kubectl apply -f ingress.yml
Hori guztia gure ordenagailuan egiten ari garenez, gure nodoaren IP helbidea gehitzen dugu /etc/ hosts fitxategian http eskaerak gure minikubera NGINX karga-balantzatzailera bideratzeko.
192.168.99.100 hello-quarkus.info
Hori da, orain gure minikube zerbitzua kanpotik eskura daiteke Nginx sarrera kontrolagailuaren bidez.
Beno, hori erraza zen, ezta? Edo ez hainbeste?
OpenShift-en exekutatzen (Code Ready Containers)
Orain ikus dezagun nola egiten den Red Hat OpenShift Container Platform (OCP) hau guztia.
Minikuberekin bezala, nodo bakarreko OpenShift kluster diseinua aukeratzen dugu Code Ready Containers (CRC) moduan. Lehen, minishift deitzen zen eta OpenShift Origin proiektuan oinarritzen zen, baina orain CRC da eta Red Hat-en OpenShift Container Platform-en eraikia.
Hemen, barkatu, ezin dugu esan: "OpenShift zoragarria da!"
Hasieran, OpenShift-en garapena Kubernetes-en garapena ez dela desberdina idaztea pentsatu genuen. Eta funtsean horrela da. Baina mezu hau idazteko prozesuan, OpenShift ez duzunean zenbat mugimendu gehigarri egin behar dituzun gogoratu dugu, eta horregatik, berriro ere, zoragarria da. Maite dugu dena erraz egiten denean, eta gure adibidea zein erraza den OpenShift-en zabaltzea eta exekutatzeko minikuberekin alderatuta, argitalpen hau idaztera bultzatu gaitu.
Goazen prozesua eta ikus dezagun zer egin behar dugun.
Beraz, minikube adibidean, Dockerrekin hasi ginen... Itxaron, jada ez dugu Docker instalatu behar makinan.
Eta ez dugu tokiko git behar.
Eta Maven ez da beharrezkoa.
Eta ez duzu eskuekin edukiontzi irudi bat sortu behar.
Eta ez duzu edukiontzien irudien biltegirik bilatu behar.
Eta ez dago sarrera kontrolagailurik instalatu beharrik.
Eta ez duzu sarrera konfiguratu beharrik ere.
Ulertzen duzu, ezta? Gure aplikazioa OpenShift-en zabaltzeko eta exekutatzeko, ez duzu goiko hauetako bat behar. Eta prozesuak berak itxura hau du.
1. urratsa - Abiarazi zure OpenShift clusterra
Red Hat-eko Code Ready Containers erabiltzen dugu, funtsean Minikube bera dena, baina Openshift nodo bakarreko kluster osoarekin soilik.
crc start
2. urratsa - Eraiki eta zabaldu aplikazioa OpenShift klusterean
Urrats honetan OpenShift-en soiltasuna eta erosotasuna bere distira guztian agertzen dira. Kubernetes banaketa guztietan bezala, aplikazio bat kluster batean exekutatzeko modu asko ditugu. Eta, KUK-en kasuan bezala, berariaz aukeratzen dugu sinpleena.
OpenShift edukiontzidun aplikazioak sortzeko eta exekutatzeko plataforma gisa eraiki izan da beti. Edukiontzien eraikuntza plataforma honen zati bat izan da beti, beraz, Kubernetes baliabide gehigarri asko daude erlazionatutako zereginetarako.
OpenShift-en Source 2 Image (S2I) prozesua erabiliko dugu, gure iturburua (kodea edo bitarrak) hartu eta OpenShift kluster batean exekutatzen den edukiontzidun irudi bat bihurtzeko hainbat modu dituena.
Horretarako bi gauza behar ditugu:
- Gure iturburu kodea git biltegian dago
- Eraikitzailearen irudia zeinaren arabera egingo den eraikuntza.
Red Hat-ek eta komunitate mailan mantentzen dituen irudi asko daude, eta OpenJDK irudia erabiliko dugu, tira, Java aplikazio bat eraikitzen ari naizenez.
S2I eraikuntza exekutatu dezakezu OpenShift Developer kontsola grafikotik eta komando-lerrotik. New-app komandoa erabiliko dugu, eraikitzailearen irudia eta gure iturburu-kodea non lortu behar diren esanez.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Hori da, gure aplikazioa sortu da. Horrela, S2I prozesuak gauza hauek egin zituen:
- Eraikitze-pod zerbitzu bat sortu da aplikazioa eraikitzearekin lotutako gauza guztietarako.
- OpenShift Build konfigurazioa sortu du.
- Eraikitzailearen irudia OpenShift barneko docker erregistrora deskargatu nuen.
- "Hello World" tokiko biltegira klonatu da.
- Han maven pom bat zegoela ikusi nuen, beraz, aplikazioa maven erabiliz osatu nuen.
- Konpilatutako Java aplikazioa duen edukiontzi-irudi berri bat sortu eta irudi hau barneko edukiontzien erregistroan jarri.
- Kubernetes Deployment sortu zen pod, zerbitzu eta abarren zehaztapenekin.
- Edukiontziaren irudia zabaltzen hasi nintzen.
- Zerbitzuaren build-pod kendu da.
Zerrenda honetan asko dago, baina gauza nagusia da eraikuntza osoa OpenShift barruan soilik gertatzen dela, barne Docker erregistroa OpenShift barruan dagoela eta eraikitze-prozesuak Kubernetes osagai guztiak sortzen dituela eta klusterrean exekutatzen dituela.
Kontsolan S2I-ren abiaraztearen ikusmenaren jarraipena egiten baduzu, eraikuntza amaitzean nola abiarazten den ikus dezakezu.
Orain, ikus ditzagun builder pod erregistroak: lehenik eta behin, maven-ek bere lana nola egiten duen erakusten du eta gure java aplikazioa eraikitzeko menpekotasunak deskargatzen ditu.
Maven eraikitzea amaitu ondoren, edukiontziaren irudiaren eraikuntza hasten da eta, ondoren, eraikitako irudi hau barne biltegira bidaltzen da.
Hori da, eraikitze prozesua amaitu da. Orain ziurtatu dezagun gure aplikazioaren lekak eta zerbitzuak klusterrean exekutatzen ari direla.
oc get service
Hori da dena. Eta talde bakarra. Egin behar duguna da zerbitzu hau kanpotik sartzeko.
3. urratsa - erakutsi zerbitzua kanpotik sartzeko
KUC-en kasuan bezala, OpenShift plataforman gure "Hello World"-ek ere bideratzaile bat behar du kanpoko trafikoa kluster barruko zerbitzura bideratzeko. OpenShift-ek hau oso erraza egiten du. Lehenik eta behin, HAProxy bideratze-osagaia klusterrean instalatuta dago lehenespenez (NGINX berera alda daiteke). Bigarrenik, Baliabide bereziak eta oso konfiguragarriak daude Routes izenekoak eta Ingress objektuak gogorarazten dituzten Kubernetes zahar onetan (hain zuzen ere, OpenShift-en Routes-ek eragin handia izan zuen Ingress objektuen diseinuan, orain OpenShift-en erabil daitezkeenak), baina gure βHello Worldβ-rako. , eta ia gainerako kasu guztietan, Ibilbide estandarra nahikoa da konfigurazio gehigarririk gabe.
"Hello World"-rako FQDN bideragarri bat sortzeko (bai, OpenShiift-ek bere DNS propioa du zerbitzu-izenen arabera bideratzeko), gure zerbitzua azalduko dugu:
oc expose service quarkus-hello-world
Sortu berri den Ibilbidea begiratzen baduzu, FQDNa eta beste bideratze-informazioa aurki ditzakezu bertan:
oc get route
Eta azkenik, nabigatzailetik sartzen gara gure zerbitzua:
Baina orain oso erraza zen!
Kubernetes eta teknologia honek ahalbidetzen digun guztia maite dugu, eta sinpletasuna eta erraztasuna ere maite ditugu. Kubernetes edukiontzi banatu eta eskalagarrien funtzionamendua izugarri errazteko sortu zen, baina bere sinpletasuna ez da nahikoa aplikazioak gaur egun ekoizpenean jartzeko. Hor sartzen da OpenShift jokoa, garaiari eutsiz eta Kubernetes eskainiz, batez ere garatzaileei zuzenduta. Ahalegin handia inbertitu da OpenShift plataforma garatzailearentzat bereziki egokitzeko, besteak beste, S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE integrazioa, Garatzaileen katalogoak, Helm integrazioa, monitorizazioa eta beste hainbat tresnak sortzea.
Artikulu hau zuretzat interesgarria eta erabilgarria izatea espero dugu. Atariko OpenShift plataforman garapenerako baliagarriak diren baliabide, material eta bestelako gauza osagarriak aurki ditzakezu .
Iturria: www.habr.com