Ang post na ito ay isinulat dahil ang aming mga tauhan ay may kaunting pag-uusap sa mga kliyente tungkol sa pagbuo ng mga aplikasyon sa Kubernetes at ang mga detalye ng naturang pag-unlad sa OpenShift.
Karaniwan kaming nagsisimula sa thesis na ang Kubernetes ay Kubernetes lamang, at ang OpenShift ay isa nang Kubernetes platform, tulad ng Microsoft AKS o Amazon EKS. Ang bawat isa sa mga platform na ito ay may sariling mga pakinabang, na nakatuon sa isang partikular na target na madla. At pagkatapos nito, ang pag-uusap ay dumadaloy na sa isang paghahambing ng mga kalakasan at kahinaan ng mga partikular na platform.
Sa pangkalahatan, naisip naming isulat ang post na ito na may output tulad ng "Makinig, hindi mahalaga kung saan mo patakbuhin ang code, sa OpenShift o sa AKS, sa EKS, sa ilang custom na Kubernetes, oo sa anumang Kubernetes (tawagin natin itong KUK for short) "Ito ay talagang simple, parehong doon at doon."
Pagkatapos ay binalak naming kunin ang pinakasimpleng "Hello World" at gamitin ito upang ipakita kung ano ang karaniwan at kung ano ang mga pagkakaiba sa pagitan ng CMC at ng Red Hat OpenShift Container Platform (simula dito, OCP o simpleng OpenShift).
Gayunpaman, sa kurso ng pagsulat ng post na ito, napagtanto namin na nasanay na kami sa paggamit ng OpenShift na hindi namin napagtanto kung paano ito lumago at naging isang kamangha-manghang platform na naging higit pa sa isang pamamahagi ng Kubernetes. May posibilidad naming balewalain ang kapanahunan at pagiging simple ng OpenShift, na nawawala sa paningin ng kagandahan nito.
Sa pangkalahatan, dumating na ang oras para sa aktibong pagsisisi, at ngayon ay ihahambing namin ang hakbang-hakbang na pag-commissioning ng aming "Hello World" sa KUK at sa OpenShift, at gagawin namin ito nang may layunin hangga't maaari (mabuti, maliban kung minsan ay nagpapakita ng personal na saloobin sa paksa). Kung interesado ka sa isang puro subjective na opinyon sa isyung ito, maaari mo itong basahin . At sa post na ito ay mananatili tayo sa mga katotohanan at mga katotohanan lamang.
Mga kumpol
Kaya, ang aming "Hello World" ay nangangailangan ng mga kumpol. Sabihin lang natin ang "hindi" sa anumang pampublikong ulap, upang hindi magbayad para sa mga server, rehistro, network, paglipat ng data, atbp. Alinsunod dito, pumili kami ng isang simpleng kumpol na may isang node (para sa KUK) at (para sa isang OpenShift cluster). Ang parehong mga opsyon na ito ay talagang madaling i-install, ngunit nangangailangan ng napakaraming mapagkukunan sa iyong laptop.
Pagpupulong sa KUK-e
Kaya umalis na tayo.
Hakbang 1 - Pagbuo ng Imahe ng Aming Container
Magsimula tayo sa pag-deploy ng ating "Hello World" sa minikube. Mangangailangan ito ng:
- 1. Naka-install na Docker.
- 2. Naka-install na Git.
- 3. Naka-install na Maven (talaga, ang proyektong ito ay gumagamit ng mvnw binary, kaya magagawa mo nang wala ito).
- 4. Actually, ang source mismo, i.e. clone ng imbakan
Ang unang hakbang ay lumikha ng isang proyekto ng Quarkus. Huwag matakot kung hindi mo pa nagamit ang Quarkus.io - madali lang. Piliin mo lang ang mga bahagi na gusto mong gamitin sa proyekto (RestEasy, Hibernate, Amazon SQS, Camel, atbp.), at pagkatapos ay ang Quarkus mismo, nang wala ang alinman sa iyong paglahok, ay nagse-set up ng maven archetype at inilalagay ang lahat sa github. Iyon ay, literal na isang pag-click ng mouse - at tapos ka na. Ito ang dahilan kung bakit mahal namin ang Quarkus.
Ang pinakamadaling paraan upang mabuo ang aming "Hello World" sa isang containerized na imahe ay ang paggamit ng quarkus-maven extension para sa Docker, na gagawa ng lahat ng kinakailangang gawain. Sa pagdating ng Quarkus, naging madali at simple ito: idagdag ang extension ng container-image-docker at maaari kang lumikha ng mga larawan gamit ang mga maven command.
./mvnw quarkus:add-extension -Dextensions=βcontainer-image-dockerβ
At sa wakas, binubuo namin ang aming imahe gamit ang Maven. Bilang resulta, ang aming source code ay nagiging isang yari na larawan ng lalagyan, na maaari nang patakbuhin sa runtime ng lalagyan.
./mvnw -X clean package -Dquarkus.container-image.build=true
Iyon, sa katunayan, ay ang lahat, ngayon ay maaari mong patakbuhin ang lalagyan gamit ang docker run command, na na-map ang aming serbisyo sa port 8080 upang ito ay ma-access.
docker run -i β rm -p 8080:8080 gcolman/quarkus-hello-world
Matapos magsimula ang instance ng container, ang natitira na lang ay suriin gamit ang curl command na tumatakbo ang aming serbisyo:
Kaya, lahat ay gumagana, at ito ay talagang madali at simple.
Hakbang 2 - Isumite ang aming lalagyan sa repositoryo ng larawan ng lalagyan
Sa ngayon, ang larawang ginawa namin ay lokal na nakaimbak sa aming lokal na imbakan ng lalagyan. Kung gusto naming gamitin ang larawang ito sa aming KUK environment, kailangan naming ilagay ito sa ibang repository. Walang mga feature na ito ang Kubernetes, kaya gagamitin namin ang dockerhub. Dahil, una, libre ito, at pangalawa, (halos) lahat ay gumagawa nito.
Napakasimple rin nito, at dockerhub account lang ang kailangan dito.
Kaya, nag-install kami ng dockerhub at ipinadala ang aming larawan doon.
Hakbang 3 - Simulan ang Kubernetes
Mayroong maraming mga paraan upang pagsamahin ang isang kubernetes configuration upang patakbuhin ang aming "Hello World", ngunit gagamitin namin ang pinakasimpleng ng mga ito, dahil kami ay tulad ng mga tao ...
Una, sisimulan natin ang minikube cluster:
minikube start
Hakbang 4 - Pag-deploy ng Ating Container Image
Ngayon ay kailangan naming i-convert ang aming code at container image sa kubernetes configuration. Sa madaling salita, kailangan namin ng pod at isang kahulugan ng deployment na tumuturo sa aming imahe ng lalagyan sa dockerhub. Ang isa sa mga pinakamadaling paraan upang gawin ito ay ang patakbuhin ang command na lumikha ng deployment na tumuturo sa aming larawan:
kubectl create deployment hello-quarkus β image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Gamit ang command na ito, sinabi namin sa aming COOK na gumawa ng configuration ng deployment, na dapat maglaman ng detalye ng pod para sa aming container na imahe. Ilalapat din ng command na ito ang configuration na ito sa aming minikube cluster, at gagawa ng deployment na magda-download ng aming container image at magpapatakbo ng pod sa cluster.
Hakbang 5 - buksan ang access sa aming serbisyo
Ngayong mayroon na kaming naka-deploy na imahe ng lalagyan, oras na para isipin kung paano i-configure ang external na access sa Restful service na ito, na, sa katunayan, ay naka-program sa aming code.
Maraming paraan dito. Halimbawa, maaari mong gamitin ang expose command para awtomatikong gumawa ng mga naaangkop na bahagi ng Kubernetes gaya ng mga serbisyo at endpoint. Sa totoo lang, ito ang gagawin namin sa pamamagitan ng pagpapatupad ng expose command para sa aming deployment object:
kubectl expose deployment hello-quarkus β type=NodePort β port=8080
Pag-isipan muna natin ang "-type" na opsyon ng expose command nang ilang sandali.
Kapag inilantad at nilikha namin ang mga sangkap na kailangan upang patakbuhin ang aming serbisyo, kailangan namin, bukod sa iba pang mga bagay, upang makakonekta mula sa labas patungo sa serbisyong hello-quarkus na nasa loob ng aming network na tinukoy ng software. At parameter uri nagbibigay-daan sa amin na gumawa at magkonekta ng mga bagay tulad ng mga load balancer upang iruta ang trapiko sa network na iyon.
Halimbawa, pagsulat type=LoadBalancer, awtomatiko naming sinisimulan ang pampublikong cloud load balancer para kumonekta sa aming Kubernetes cluster. Ito, siyempre, ay mahusay, ngunit kailangan mong maunawaan na ang naturang pagsasaayos ay mahigpit na maiuugnay sa isang partikular na pampublikong ulap at magiging mas mahirap na ilipat ito sa pagitan ng mga pagkakataon ng Kubernetes sa iba't ibang mga kapaligiran.
Sa ating halimbawa uri=NodePort, ibig sabihin, ang tawag sa aming serbisyo ay napupunta sa pamamagitan ng IP address ng node at ang port number. Binibigyang-daan ka ng opsyong ito na huwag gumamit ng anumang pampublikong ulap, ngunit nangangailangan ng ilang karagdagang hakbang. Una, kailangan mo ng sarili mong load balancer, kaya i-deploy namin ang NGINX load balancer sa aming cluster.
Hakbang 6 - Mag-set up ng load balancer
Ang minikube ay may ilang feature ng platform na nagpapadali sa paggawa ng mga component na kailangan mo para sa external na access, gaya ng mga ingress controller. Ang Minikube ay kasama ng Nginx ingress controller, at ang kailangan lang nating gawin ay paganahin ito at i-configure ito.
minikube addons enable ingress
Ngayon, sa isang command lang, gagawa kami ng Nginx ingress controller na gagana sa loob ng aming minikube cluster:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Hakbang 7 - I-set up ang pagpasok
Ngayon kailangan nating i-configure ang Nginx ingress controller para tanggapin ang mga kahilingang hello-quarkus.
At sa wakas, kailangan nating ilapat ang pagsasaayos na ito.
kubectl apply -f ingress.yml
Dahil ginagawa namin ang lahat ng ito sa sarili naming makina, idinaragdag lang namin ang IP address ng aming node sa /etc/hosts file para idirekta ang mga kahilingan sa http sa aming minikube sa NGINX load balancer.
192.168.99.100 hello-quarkus.info
Iyon lang, ngayon ang aming serbisyo ng minikube ay magagamit mula sa labas sa pamamagitan ng Nginx ingress controller.
Well, madali lang iyon, tama ba? O hindi masyado?
Tumakbo sa OpenShift (Code Ready Containers)
At ngayon tingnan natin kung paano ito ginagawa sa Red Hat OpenShift Container Platform (OCP).
Tulad ng kaso ng minikube, pipili kami ng scheme na may single-node OpenShift cluster sa anyo ng Code Ready Containers (CRC). Tinatawag itong minishift at nakabatay sa OpenShift Origin project, ngunit ngayon ay CRC na ito at binuo sa OpenShift Container Platform ng Red Hat.
Dito, paumanhin, hindi namin maiwasang sabihin: "Mahusay ang OpenShift!"
Sa una, naisip naming isulat na ang pag-unlad sa OpenShift ay hindi naiiba sa pag-unlad sa Kubernetes. At sa totoo lang, ganyan talaga. Ngunit sa proseso ng pagsulat ng post na ito, naalala namin kung gaano karaming mga hindi kinakailangang paggalaw ang kailangan mong gawin kapag wala kang OpenShift, at samakatuwid, muli, ito ay maganda. Gustung-gusto namin ang mga bagay na maging madali, at kung gaano kadaling i-deploy at patakbuhin ang aming halimbawa sa OpenShift kumpara sa minikube ang naging inspirasyon namin na isulat ang post na ito.
Patakbuhin natin ang proseso at tingnan kung ano ang kailangan nating gawin.
Kaya sa halimbawa ng minikube, nagsimula kami sa Docker... Maghintay, hindi na namin kailangan na naka-install ang Docker sa makina.
At hindi namin kailangan ng isang lokal na git.
At hindi kailangan si Maven.
At hindi mo kailangang lumikha ng isang lalagyan na imahe sa pamamagitan ng kamay.
At hindi mo kailangang maghanap ng anumang imbakan ng mga imahe ng lalagyan.
At hindi mo kailangang mag-install ng ingress controller.
At hindi mo rin kailangang i-configure ang pagpasok.
Naiintindihan mo ba? Upang i-deploy at patakbuhin ang aming application sa OpenShift, wala sa itaas ang kailangan. At ang proseso mismo ay ang mga sumusunod.
Hakbang 1 β Pagsisimula ng Iyong OpenShift Cluster
Gumagamit kami ng Code Ready Container mula sa Red Hat, na halos pareho ang Minikube, ngunit may buong single-node Openshift cluster lang.
crc start
Hakbang 2 - Buuin at I-deploy ang Application sa OpenShift Cluster
Sa hakbang na ito makikita ang pagiging simple at kaginhawahan ng OpenShift sa lahat ng kaluwalhatian nito. Tulad ng lahat ng mga distribusyon ng Kubernetes, marami kaming paraan upang magpatakbo ng isang application sa isang cluster. At, tulad ng sa kaso ng KUK, pipiliin namin ang pinakasimpleng isa.
Ang OpenShift ay palaging binuo bilang isang platform para sa pagbuo at pagpapatakbo ng mga containerized na application. Ang pagbuo ng mga lalagyan ay palaging isang mahalagang bahagi ng platform na ito, kaya mayroong isang grupo ng mga karagdagang mapagkukunan ng Kubernetes para sa mga kaukulang gawain.
Gagamitin namin ang proseso ng OpenShift's Source 2 Image (S2I), na may iba't ibang paraan para kunin ang aming source (code o binary) at gawing isang containerized na imahe na tumatakbo sa isang OpenShift cluster.
Para dito kailangan namin ng dalawang bagay:
- Ang aming source code sa git repository
- Builder-image, batay sa kung saan isasagawa ang pagpupulong.
Mayroong maraming mga ganoong larawan, na pinananatili pareho ng Red Hat at ng komunidad, at gagamitin namin ang imahe ng OpenJDK, mabuti, dahil gumagawa ako ng isang Java application.
Maaari kang magpatakbo ng isang S2I build mula sa graphical console ng OpenShift Developer at mula sa command line. Gagamitin namin ang new-app na command, na sinasabi dito kung saan kukunin ang builder image at ang aming source code.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Iyon lang, ang aming application ay nilikha. Sa paggawa nito, ginawa ng proseso ng S2I ang mga sumusunod na bagay:
- Gumawa ng service build-pod para sa lahat ng uri ng bagay na nauugnay sa pagbuo ng application.
- Gumawa ng OpenShift Build config.
- Na-download ko ang imahe ng tagabuo sa panloob na OpenShift docker registry.
- Na-clone ang "Hello World" sa lokal na imbakan.
- Nakita kong mayroong isang maven pom doon at kaya pinagsama-sama ang app na may maven.
- Gumawa ng bagong imahe ng lalagyan na naglalaman ng pinagsama-samang Java application at inilagay ang larawang ito sa panloob na pagpapatala ng lalagyan.
- Gumawa ng Kubernetes Deployment na may mga detalye para sa isang pod, serbisyo, atbp.
- Inilunsad ang deploy na larawan ng container.
- Inalis ang build-pod ng serbisyo.
Marami sa listahang ito, ngunit ang pangunahing bagay ay ang buong build ay eksklusibong nagaganap sa loob ng OpenShift, ang panloob na Docker registry ay nasa loob ng OpenShift, at ang proseso ng build ay lumilikha ng lahat ng mga bahagi ng Kubernetes at pinapatakbo ang mga ito sa cluster.
Kung biswal mong sinusubaybayan ang paglulunsad ng S2I sa console, makikita mo kung paano inilulunsad ang build pod sa panahon ng build.
At ngayon tingnan natin ang mga log ng builder pod: una, doon mo makikita kung paano ginagawa ng maven ang trabaho nito at nagda-download ng mga dependency upang buuin ang aming java application.
Matapos makumpleto ang maven build, magsisimula ang build ng container image, at pagkatapos ay ipapadala ang built image na ito sa internal repository.
Lahat, ang proseso ng pagpupulong ay nakumpleto. Ngayon, siguraduhin natin na ang mga pod at serbisyo ng ating aplikasyon ay nagsimula na sa cluster.
oc get service
Iyon lang. At mayroon lamang isang koponan. Ang kailangan lang nating gawin ay ilantad ang serbisyong ito para sa labas ng access.
Hakbang 3 - ilantad ang serbisyo para sa pag-access mula sa labas
Tulad ng kaso ng KUK, sa OpenShift platform, ang aming "Hello World" ay nangangailangan din ng isang router upang idirekta ang panlabas na trapiko sa isang serbisyo sa loob ng cluster. Sa OpenShift ginagawa nitong napakadali. Una, ang HAProxy routing component ay naka-install sa cluster bilang default (maaari itong baguhin sa parehong NGINX). Pangalawa, may mga espesyal at lubos na nako-configure na mapagkukunan na tinatawag na Mga Ruta, na nakapagpapaalaala sa mga Ingress object sa magandang lumang Kubernetes (sa katunayan, ang OpenShift's Routes ay lubos na nakaimpluwensya sa disenyo ng Ingress object, na magagamit na ngayon sa OpenShift) , ngunit para sa aming "Hello Mundo", at sa halos lahat ng iba pang mga kaso, ang karaniwang Ruta ay sapat para sa amin nang walang karagdagang pagsasaayos.
Para gumawa ng routable FQDN para sa βHello Worldβ (oo, ang OpenShiift ay may sariling DNS para sa pagruruta ayon sa mga pangalan ng serbisyo), inilalantad lang namin ang aming serbisyo:
oc expose service quarkus-hello-world
Kung titingnan mo ang bagong likhang Ruta, makikita mo ang FQDN at iba pang impormasyon sa pagruruta doon:
oc get route
At sa wakas, ina-access namin ang aming serbisyo mula sa browser:
Ngunit ngayon ito ay talagang madali!
Gustung-gusto namin ang Kubernetes at lahat ng pinahihintulutan ng teknolohiyang ito na gawin mo, at gusto rin namin ang pagiging simple at magaan. Ang Kubernetes ay idinisenyo upang gawing hindi kapani-paniwalang madaling patakbuhin ang mga distributed, scalable na container, ngunit ang pagiging simple nito ay hindi na sapat upang dalhin ang mga aplikasyon sa produksyon ngayon. Dito pumapasok ang OpenShift, na nakikisabay sa mga oras at nag-aalok ng mga developer-centric na Kubernetes. Napakaraming pagsisikap ang namuhunan upang maiangkop ang platform ng OpenShift na partikular para sa developer, kabilang ang paglikha ng mga tool tulad ng S2I, ODI, Portal ng Developer, OpenShift Operator Framework, pagsasama ng IDE, Mga Catalog ng Developer, pagsasama ng Helm, pagsubaybay, at marami pang iba.
Inaasahan namin na ang artikulong ito ay kawili-wili at kapaki-pakinabang para sa iyo. At makakahanap ka ng mga karagdagang mapagkukunan, materyales at iba pang bagay na kapaki-pakinabang para sa pagbuo sa OpenShift platform sa portal .
Pinagmulan: www.habr.com