Šis ieraksts tika uzrakstīts, jo mūsu darbiniekiem bija diezgan daudz sarunu ar klientiem par aplikāciju izstrādi Kubernetes un šādas izstrādes specifiku OpenShift.
Mēs parasti sākam ar tēzi, ka Kubernetes ir tikai Kubernetes, un OpenShift jau ir Kubernetes platforma, piemēram, Microsoft AKS vai Amazon EKS. Katrai no šīm platformām ir savas priekšrocības, kas vērstas uz konkrētu mērķauditoriju. Un pēc tam saruna pārvēršas par konkrētu platformu stipro un vājo pušu salīdzināšanu.
Kopumā mēs domājām rakstīt šo ziņu ar tādu secinājumu kā “Klausies, nav svarīgi, kur palaist kodu, OpenShift vai AKS, EKS, dažās pielāgotās Kubernetes vai jebkurā Kubernetes ierīcē. (īsuma labad sauksim to par KUK) "Tas ir patiešām vienkārši gan tur, gan tur."
Tad mēs plānojām paņemt vienkāršāko “Hello World” un izmantot tās piemēru, lai parādītu, kas ir kopīgs un ar ko atšķiras KUC un Red Hat OpenShift Container Platform (turpmāk OCP vai vienkārši OpenShift).
Tomēr, rakstot šo ziņu, mēs sapratām, ka esam tik ilgi pieraduši izmantot OpenShift, ka vienkārši neapzinājāmies, kā tā ir izaugusi un pārvērtusies par pārsteidzošu platformu, kas kļuva daudz vairāk nekā tikai Kubernetes izplatīšana. Mums ir tendence uzskatīt OpenShift briedumu un vienkāršību par pašsaprotamu un aizmirst par tās spožumu.
Kopumā ir pienācis laiks aktīvai grēku nožēlai, un tagad mēs soli pa solim salīdzināsim mūsu “Hello World” nodošanu ekspluatācijā KUK un OpenShift, un mēs to darīsim pēc iespējas objektīvi (nu, izņemot dažkārt parādot personiskā attieksme pret tēmu). Ja jūs interesē tīri subjektīvs viedoklis par šo jautājumu, varat to izlasīt . Un šajā ierakstā mēs paliksim pie faktiem un tikai faktiem.
Kopas
Tātad mūsu “Sveika pasaule” prasa kopas. Mēs nekavējoties pateiksim “nē” jebkuriem publiskajiem mākoņiem, lai nemaksātu par serveriem, reģistriem, tīkliem, datu pārsūtīšanu utt. Attiecīgi mēs izvēlamies vienkāršu viena mezgla kopu (par KUK) un (OpenShift klasterim). Abas šīs opcijas ir patiešām viegli instalējamas, taču tām būs nepieciešams diezgan daudz resursu jūsu klēpjdatorā.
Montāža uz KUK-e
Tātad, ejam.
1. darbība – konteinera attēla izveide
Sāksim ar mūsu “Hello World” izvietošanu minikube. Lai to izdarītu, jums būs nepieciešams:
- 1. Docker instalēts.
- 2. Git instalēts.
- 3. Instalēts Maven (patiesībā šajā projektā tiek izmantots mvnw binārs, tāpēc var iztikt bez tā).
- 4. Faktiski pats avots, t.i. repozitorija klons
Pirmais solis ir izveidot Quarkus projektu. Nebaidieties, ja nekad neesat strādājis ar Quarkus.io — tas ir vienkārši. Jūs vienkārši izvēlaties komponentus, kurus vēlaties izmantot projektā (RestEasy, Hibernate, Amazon SQS, Camel utt.), un pēc tam pats Quarkus bez jūsu līdzdalības konfigurē maven arhetipu un visu ievieto github. Tas ir, burtiski viens peles klikšķis, un esat pabeidzis. Tāpēc mēs mīlam Quarkus.
Vienkāršākais veids, kā izveidot mūsu “Hello World” konteinera attēlu, ir izmantot Docker paplašinājumus quarkus-maven, kas veiks visu nepieciešamo darbu. Līdz ar Quarkus parādīšanos tas ir kļuvis patiešām viegli un vienkārši: pievienojiet paplašinājumu konteiners-attēla-docker un varat izveidot attēlus, izmantojot komandas maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Visbeidzot, mēs veidojam savu tēlu, izmantojot Maven. Rezultātā mūsu pirmkods pārvēršas par gatavu konteinera attēlu, ko jau var palaist konteinera izpildlaika vidē.
./mvnw -X clean package -Dquarkus.container-image.build=true
Tas arī viss. Tagad varat palaist konteineru ar docker run komandu, kartējot mūsu pakalpojumu ar portu 8080, lai tam varētu piekļūt.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Pēc konteinera instances palaišanas atliek tikai pārbaudīt ar curl komandu, vai mūsu pakalpojums darbojas:
Tātad viss darbojas, un tas bija patiešām viegli un vienkārši.
2. darbība – nosūtiet mūsu konteineru uz konteinera attēlu krātuvi
Pagaidām mūsu izveidotais attēls tiek glabāts lokāli, mūsu vietējā konteineru krātuvē. Ja mēs vēlamies izmantot šo attēlu savā COOK vidē, tad tas ir jāievieto kādā citā repozitorijā. Kubernetes šādu funkciju nav, tāpēc izmantosim dockerhub. Jo, pirmkārt, tas ir bez maksas, otrkārt, to dara (gandrīz) visi.
Tas ir arī ļoti vienkārši, un viss, kas jums nepieciešams, ir Dockerhub konts.
Tātad, mēs instalējam dockerhub un nosūtām tur savu attēlu.
3. darbība – palaidiet Kubernetes
Ir daudz veidu, kā salikt kubernetes konfigurāciju, lai palaistu mūsu “Hello World”, taču mēs izmantosim vienkāršāko no tiem, tādi mēs esam...
Vispirms palaidīsim minikube klasteru:
minikube start
4. darbība — izvietojiet mūsu konteinera attēlu
Tagad mums ir jāpārvērš mūsu kods un konteinera attēls kubernetes konfigurācijās. Citiem vārdiem sakot, mums ir nepieciešama podziņa un izvietošanas definīcija, kas norāda uz mūsu konteinera attēlu vietnē Dockerhub. Viens no vienkāršākajiem veidiem, kā to izdarīt, ir palaist komandu izveidot izvietošanu, kas norāda uz mūsu attēlu:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Ar šo komandu mēs likām savam COO izveidot izvietošanas konfigurāciju, kurā būtu jāietver mūsu konteinera attēla pod specifikācija. Šī komanda piemēros šo konfigurāciju arī mūsu minikube klasterim un izveidos izvietošanu, kas lejupielādēs mūsu konteinera attēlu un palaidīs kopu klasterī.
5. darbība – atveriet piekļuvi mūsu pakalpojumam
Tagad, kad mums ir izvietots konteinera attēls, ir pienācis laiks domāt par to, kā konfigurēt ārējo piekļuvi šim pakalpojumam Restful, kas faktiski ir ieprogrammēts mūsu kodā.
Šeit ir daudz veidu. Piemēram, varat izmantot komandu exose, lai automātiski izveidotu atbilstošos Kubernetes komponentus, piemēram, pakalpojumus un galapunktus. Faktiski tas ir tas, ko mēs darīsim, izpildot mūsu izvietošanas objekta eksponēšanas komandu:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Atvēlēsim brīdi, lai apskatītu komandas eksponēšanas opciju "-type".
Kad mēs atklājam un izveidojam komponentus, kas nepieciešami mūsu pakalpojuma palaišanai, mums, cita starpā, ir jāspēj no ārpuses izveidot savienojumu ar pakalpojumu hello-quarkus, kas atrodas mūsu programmatūras definētajā tīklā. Un parametrs tips ļauj mums izveidot un savienot lietas, piemēram, slodzes balansētājus, lai novirzītu trafiku uz šo tīklu.
Piemēram, rakstot tips=LoadBalancer, mēs automātiski nodrošinām slodzes balansētāju publiskajā mākonī, lai izveidotu savienojumu ar mūsu Kubernetes klasteru. Tas, protams, ir lieliski, taču jums ir jāsaprot, ka šāda konfigurācija būs stingri piesaistīta konkrētam publiskam mākoni un to būs grūtāk pārsūtīt starp Kubernetes gadījumiem dažādās vidēs.
Mūsu piemērā type=NodePort, tas ir, mūsu pakalpojumam var piekļūt, izmantojot mezgla IP adresi un porta numuru. Šī opcija ļauj neizmantot publiskos mākoņus, taču tai ir nepieciešamas vairākas papildu darbības. Pirmkārt, jums ir nepieciešams savs slodzes balansētājs, tāpēc mēs izvietosim NGINX slodzes balansētāju mūsu klasterī.
6. solis – uzstādiet slodzes balansētāju
minikube ir vairākas platformas funkcijas, kas atvieglo ārēji pieejamu komponentu, piemēram, ieejas kontrolleru, izveidi. Minikube ir komplektā ar Nginx ieejas kontrolieri, un viss, kas mums jādara, ir tas jāiespējo un jākonfigurē.
minikube addons enable ingress
Tagad mēs izveidosim Nginx ieejas kontrolieri tikai ar vienu komandu, kas darbosies mūsu minikube klasterī:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
7. darbība – ieejas iestatīšana
Tagad mums ir jākonfigurē Nginx ieejas kontrolleris, lai tas pieņemtu hello-quarkus pieprasījumus.
Un visbeidzot, mums ir jāpiemēro šī konfigurācija.
kubectl apply -f ingress.yml
Tā kā mēs to visu darām savā datorā, mēs vienkārši pievienojam sava mezgla IP adresi failam /etc/ hosts, lai http pieprasījumus novirzītu uz mūsu minikube uz NGINX slodzes balansētāju.
192.168.99.100 hello-quarkus.info
Tas arī viss, tagad mūsu minikube pakalpojums ir pieejams ārēji, izmantojot Nginx ieejas kontrolleri.
Nu, tas bija viegli, vai ne? Vai ne tik daudz?
Darbojas ar OpenShift (kodam gatavi konteineri)
Tagad redzēsim, kā tas viss tiek darīts Red Hat OpenShift konteineru platformā (OCP).
Tāpat kā minikube gadījumā, mēs izvēlamies viena mezgla OpenShift klastera dizainu Code Ready Containers (CRC) formā. Iepriekš tas tika saukts par minishift un tika balstīts uz OpenShift Origin projektu, bet tagad tas ir CRC un veidots uz Red Hat OpenShift konteineru platformas.
Šeit mēs, atvainojiet, nevaram nepateikt: “OpenShift ir brīnišķīgs!”
Sākotnēji mēs domājām rakstīt, ka izstrāde OpenShift neatšķiras no izstrādes Kubernetes. Un būtībā tas tā ir. Bet rakstot šo ziņu, mēs atcerējāmies, cik daudz papildu kustību jums ir jāveic, ja jums nav OpenShift, un tāpēc tas atkal ir brīnišķīgi. Mums patīk, kad viss tiek darīts viegli, un tas, cik viegli mūsu piemēru ir izvietot un palaist OpenShift salīdzinājumā ar minikube, pamudināja mūs uzrakstīt šo ziņu.
Iesim cauri procesam un redzēsim, kas mums jādara.
Tātad minikube piemērā mēs sākām ar Docker... Pagaidiet, mums vairs nav nepieciešams Docker instalēts mašīnā.
Un mums nav vajadzīgs vietējais ģīmis.
Un Mavens nav vajadzīgs.
Un jums nav jāizveido konteinera attēls ar savām rokām.
Un jums nav jāmeklē konteinera attēlu krātuve.
Un nav nepieciešams uzstādīt ieejas kontrolieri.
Un jums arī nav jākonfigurē ieeja.
Jūs saprotat, vai ne? Lai izvietotu un palaistu mūsu lietojumprogrammu OpenShift, jums nav nepieciešams neviens no iepriekš minētajiem. Un pats process izskatās šādi.
1. darbība – palaidiet savu OpenShift klasteru
Mēs izmantojam Code Ready Containers no Red Hat, kas būtībā ir tas pats Minikube, bet tikai ar pilnvērtīgu viena mezgla Openshift klasteru.
crc start
2. darbība — izveidojiet un izvietojiet lietojumprogrammu OpenShift klasterī
Tieši šajā posmā OpenShift vienkāršība un ērtības tiek atklātas visā tās krāšņumā. Tāpat kā ar visiem Kubernetes izplatījumiem, mums ir daudz veidu, kā palaist lietojumprogrammu klasterī. Un, tāpat kā KUK gadījumā, mēs īpaši izvēlamies vienkāršāko.
OpenShift vienmēr ir veidota kā platforma konteinerizētu lietojumprogrammu izveidei un palaišanai. Konteineru veidošana vienmēr ir bijusi šīs platformas neatņemama sastāvdaļa, tāpēc ar to saistītiem uzdevumiem ir pieejams daudz papildu Kubernetes resursu.
Mēs izmantosim OpenShift Source 2 Image (S2I) procesu, kuram ir vairāki dažādi veidi, kā iegūt mūsu avotu (kodu vai bināros failus) un pārvērst to konteinerizētā attēlā, kas darbojas OpenShift klasterī.
Lai to izdarītu, mums ir vajadzīgas divas lietas:
- Mūsu pirmkods atrodas git repozitorijā
- Būvnieka attēls, uz kura pamata tiks veikta būvniecība.
Ir daudz šādu attēlu, ko uztur gan Red Hat, gan kopienas līmenī, un mēs izmantosim OpenJDK attēlu, jo es veidoju Java lietojumprogrammu.
S2I būvējumu var palaist gan no OpenShift Developer grafiskās konsoles, gan no komandrindas. Mēs izmantosim komandu new-app, norādot, kur iegūt veidotāja attēlu un mūsu avota kodu.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Tas arī viss, mūsu lietojumprogramma ir izveidota. To darot, S2I process veica šādas darbības:
- Izveidots pakalpojumu būvpods visu veidu lietām, kas saistītas ar lietojumprogrammas izveidi.
- Izveidoja OpenShift Build konfigurāciju.
- Es lejupielādēju veidotāja attēlu iekšējā OpenShift docker reģistrā.
- Klonēts "Hello World" uz vietējo repozitoriju.
- Es redzēju, ka tur ir maven pom, tāpēc es sastādīju aplikāciju, izmantojot maven.
- Izveidots jauns konteinera attēls, kurā ir apkopota Java lietojumprogramma, un ievietots šis attēls iekšējā konteinera reģistrā.
- Izveidota Kubernetes izvietošana ar specifikācijām podam, pakalpojumam utt.
- Es sāku izvietot konteinera attēlu.
- Noņemts pakalpojuma build-pod.
Šajā sarakstā ir daudz, taču galvenais ir tas, ka visa būvēšana notiek tikai OpenShift iekšienē, iekšējais Docker reģistrs atrodas OpenShift iekšpusē, un veidošanas process izveido visus Kubernetes komponentus un palaiž tos klasterī.
Ja konsolē vizuāli pārraugāt S2I palaišanu, varat redzēt, kā būvēšanas pods tiek palaists, kad būvēšana ir pabeigta.
Tagad apskatīsim veidotāju pod žurnālus: pirmkārt, tas parāda, kā maven veic savu darbu, un lejupielādē atkarības, lai izveidotu mūsu Java lietojumprogrammu.
Kad Maven būvēšana ir pabeigta, tiek sākta konteinera attēla būvēšana, un pēc tam šis veidotais attēls tiek nosūtīts uz iekšējo repozitoriju.
Tas arī viss, izveides process ir pabeigts. Tagad pārliecināsimies, ka mūsu lietojumprogrammas podi un pakalpojumi darbojas klasterī.
oc get service
Tas ir viss. Un tikai viena komanda. Viss, kas mums jādara, ir atklāt šo pakalpojumu, lai tas varētu piekļūt no ārpuses.
3. darbība – atklājiet pakalpojumam piekļuvi no ārpuses
Tāpat kā KUC gadījumā, OpenShift platformā mūsu “Hello World” arī ir nepieciešams maršrutētājs, lai novirzītu ārējo trafiku uz pakalpojumu klasterī. OpenShift to padara ļoti vienkāršu. Pirmkārt, HAProxy maršrutēšanas komponents ir instalēts klasterī pēc noklusējuma (to var mainīt uz to pašu NGINX). Otrkārt, ir īpaši un ļoti konfigurējami resursi, ko sauc par maršrutiem un atgādina Ingress objektus vecajā labajā Kubernetes (patiesībā OpenShift maršruti lielā mērā ietekmēja Ingress objektu dizainu, ko tagad var izmantot OpenShift), bet mūsu "Hello World" , un gandrīz visos citos gadījumos mums pietiek ar standarta Maršrutu bez papildu konfigurācijas.
Lai izveidotu maršrutējamu FQDN “Hello World” (jā, OpenShiift ir savs DNS maršrutēšanai pēc pakalpojumu nosaukumiem), mēs vienkārši atklāsim savu pakalpojumu:
oc expose service quarkus-hello-world
Ja skatāties uz jaunizveidoto maršrutu, tajā varat atrast FQDN un citu maršrutēšanas informāciju:
oc get route
Visbeidzot, mēs piekļūstam savam pakalpojumam no pārlūkprogrammas:
Bet tagad tas bija patiešām viegli!
Mēs mīlam Kubernetes un visu, ko šī tehnoloģija mums ļauj darīt, kā arī mēs mīlam vienkāršību un vieglumu. Kubernetes tika izveidots, lai neticami vienkāršotu sadalīto, mērogojamo konteineru darbību, taču ar tās vienkāršību vairs nepietiek, lai šodien ieviestu lietojumprogrammas ražošanā. Šeit tiek izmantota OpenShift, kas seko līdzi laikam un piedāvā Kubernetes, kas galvenokārt paredzēta izstrādātājam. Ir ieguldīts daudz pūļu, lai OpenShift platformu pielāgotu īpaši izstrādātājam, tostarp tādu rīku izveidei kā S2I, ODI, izstrādātāju portāls, OpenShift Operator Framework, IDE integrācija, izstrādātāju katalogi, Helm integrācija, uzraudzība un daudzi citi.
Mēs ceram, ka šis raksts jums bija interesants un noderīgs. Portālā var atrast papildu resursus, materiālus un citas izstrādei noderīgas lietas OpenShift platformā .
Avots: www.habr.com
