See postitus on kirjutatud, kuna meie töötajad vestlesid klientidega üsna palju Kubernetes rakenduste arendamise ja OpenShiftis arendamise spetsiifika kohta.
Tavaliselt alustame teesiga, et Kubernetes on lihtsalt Kubernetes ja OpenShift on juba Kubernetese platvorm, nagu Microsoft AKS või Amazon EKS. Igal neist platvormidest on oma eelised, mis on keskendunud konkreetsele sihtrühmale. Ja pärast seda läheb jutt juba konkreetsete platvormide tugevate ja nõrkade külgede võrdlusse.
Üldiselt mõtlesime selle postituse kirjutada sellise väljundiga nagu "Kuulge, pole vahet, kus te koodi käivitate, OpenShiftis või AKS-is, EKS-is, mõnes kohandatud Kubernetesis, jah mis tahes Kubernetesis (nimetagem seda lühidalt KUK-ks) "See on tõesti lihtne, nii seal kui seal."
Siis plaanisime võtta kõige lihtsama "Tere maailm" ja selle abil näidata, mis on ühine ja mis erinevused on CMC ja Red Hat OpenShift Container Platformi (edaspidi OCP või lihtsalt OpenShift) vahel.
Selle postituse kirjutamise käigus mõistsime aga, et oleme OpenShifti kasutamisega nii ära harjunud, et me lihtsalt ei mõista, kuidas see on kasvanud ja muutunud hämmastavaks platvormiks, millest on saanud palju enamat kui lihtsalt Kubernetese distributsioon. Me kipume OpenShifti küpsust ja lihtsust pidama enesestmõistetavaks, jättes samal ajal tähelepanuta selle suurejoonelisuse.
Üldiselt on aeg aktiivseks meeleparanduseks kätte jõudnud ja nüüd hakkame samm-sammult võrdlema oma “Tere maailma” tellimist KUK-is ja OpenShiftis ning teeme seda võimalikult objektiivselt (noh, välja arvatud mõnikord isikliku isikliku näitamine). suhtumine teemasse). Kui olete huvitatud puhtalt subjektiivsest arvamusest selles küsimuses, võite seda lugeda . Ja selles postituses jääme faktide ja ainult faktide juurde.
Klastrid
Niisiis, meie "Tere maailm" vajab klastreid. Ütleme lihtsalt "ei" suvalistele avalikele pilvedele, et mitte maksta serverite, registrite, võrkude, andmeedastuse jms eest. Sellest lähtuvalt valime sisse lihtsa ühe sõlmega klastri (KUK jaoks) ja (OpenShifti klastri jaoks). Mõlemaid valikuid on tõesti lihtne installida, kuid need nõuavad teie sülearvutis üsna palju ressursse.
Kokkupanek KUK-e
Nii et lähme.
1. samm – meie konteineri kujutise loomine
Alustame oma "Tere maailm" juurutamisega minikube. Selleks on vaja:
- 1. Installitud Docker.
- 2. Installitud Git.
- 3. Installitud Maven (tegelikult kasutab see projekt mvnw binaarfaili, nii et saate ilma selleta hakkama).
- 4. Tegelikult on allikas ise, s.o. hoidla kloon
Esimene samm on Quarkuse projekti loomine. Ärge kartke, kui te pole Quarkus.io-d kunagi kasutanud – see on lihtne. Valite lihtsalt komponendid, mida soovite projektis kasutada (RestEasy, Hibernate, Amazon SQS, Camel jne) ja siis Quarkus ise, ilma teie osaluseta, seadistab maven arhetüübi ja paneb kõik githubi. See tähendab, et sõna otseses mõttes üks hiireklõps – ja ongi valmis. See on põhjus, miks me armastame Quarkust.
Lihtsaim viis meie "Tere maailma" konteinerkujutiseks ehitada on kasutada Dockeri jaoks laiendusi quarkus-maven, mis teeb ära kogu vajaliku töö. Quarkuse tulekuga on see muutunud väga lihtsaks ja lihtsaks: lisage konteiner-image-docker laiendus ja saate luua pilte maven-käsklustega.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Ja lõpuks loome oma kuvandi Maveni abil. Selle tulemusena muutub meie lähtekood valmis konteineri kujutiseks, mida saab juba konteineri käitusajal käivitada.
./mvnw -X clean package -Dquarkus.container-image.build=true
See on tegelikult kõik, nüüd saate konteinerit käitada käsuga docker run, kui olete meie teenuse pordiga 8080 vastendanud, et sellele juurde pääseda.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Pärast konteineri eksemplari käivitumist jääb üle vaid kontrollida curl käsuga, et meie teenus töötab:
Niisiis, kõik töötab ja see oli tõesti lihtne ja lihtne.
2. samm – esitage meie konteiner konteineri kujutiste hoidlasse
Praegu salvestatakse meie loodud pilt kohalikus konteinerites. Kui tahame seda pilti oma KUK keskkonnas kasutada, siis peame selle paigutama mõnda teise hoidlasse. Kubernetesil neid funktsioone pole, seega kasutame dockerhubi. Sest esiteks on see tasuta ja teiseks teevad seda (peaaegu) kõik.
See on samuti väga lihtne ja siin on vaja ainult dockerhubi kontot.
Niisiis, installime dockerhubi ja saadame oma pildi sinna.
3. samm – käivitage Kubernetes
Kubernetese konfiguratsiooni kokkupanemiseks meie "Tere maailma" käitamiseks on palju võimalusi, kuid me kasutame neist kõige lihtsamat, sest me oleme sellised inimesed ...
Esiteks käivitame minikube klastri:
minikube start
4. samm – meie konteineri kujutise juurutamine
Nüüd peame teisendama oma koodi ja konteineri pildi kubernetese konfiguratsiooniks. Teisisõnu vajame kausta ja juurutamise määratlust, mis osutab meie konteineri kujutisele dockerhubis. Üks lihtsamaid viise selleks on käivitada juurutamise loomise käsk, mis osutab meie pildile:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Selle käsuga käskisime oma COOK-il luua juurutamise konfiguratsioon, mis peaks sisaldama meie konteineri kujutise kausta spetsifikatsiooni. See käsk rakendab selle konfiguratsiooni ka meie minikube klastris ja loob juurutuse, mis laadib alla meie konteineri pildi ja käivitab klastris podi.
5. samm – avage juurdepääs meie teenusele
Nüüd, kui meil on juurutatud konteineri kujutis, on aeg mõelda, kuidas konfigureerida välist juurdepääsu sellele Restfuli teenusele, mis on tegelikult meie koodis programmeeritud.
Siin on palju viise. Näiteks saate kasutada käsku expose, et luua automaatselt sobivad Kubernetese komponendid, nagu teenused ja lõpp-punktid. Tegelikult teeme seda, käivitades oma juurutusobjekti jaoks paljastamise käsu:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Jääme hetkeks expose käsu valikule "-type".
Kui me avaldame ja loome oma teenuse käitamiseks vajalikke komponente, peame muu hulgas saama ühenduse luua väljastpoolt teenusega hello-quarkus, mis asub meie tarkvaraga määratletud võrgus. Ja parameeter tüüp võimaldab meil luua ja ühendada selliseid asju nagu koormuse tasakaalustajad, et suunata liiklus sellesse võrku.
Näiteks kirjutamine type=Load Balancer, initsialiseerime avaliku pilvekoormuse tasakaalustaja automaatselt meie Kubernetese klastriga ühenduse loomiseks. See on muidugi suurepärane, kuid peate mõistma, et selline konfiguratsioon on tihedalt seotud konkreetse avaliku pilvega ja seda on erinevates keskkondades Kubernetese eksemplaride vahel keerulisem üle kanda.
Meie näites type=NodePort, see tähendab, et kõne meie teenusele toimub sõlme IP-aadressi ja pordi numbri järgi. See valik võimaldab teil mitte kasutada avalikke pilvi, kuid see nõuab mitmeid täiendavaid samme. Esiteks vajate oma koormuse tasakaalustajat, seega juurutame oma klastris NGINX koormuse tasakaalustaja.
6. samm – seadistage koormuse tasakaalustaja
minikube'il on mitmeid platvormi funktsioone, mis muudavad välise juurdepääsu jaoks vajalike komponentide (nt sissepääsukontrollerite) loomise lihtsaks. Minikube on komplektis Nginxi sissepääsukontrolleriga ja meil tuleb vaid see lubada ja konfigureerida.
minikube addons enable ingress
Nüüd loome vaid ühe käsuga Nginxi sissepääsukontrolleri, mis töötab meie minikube klastris:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
7. samm – seadistage sissepääs
Nüüd peame konfigureerima Nginxi sissepääsukontrolleri hello-quarkuse taotluste vastuvõtmiseks.
Ja lõpuks peame seda konfiguratsiooni rakendama.
kubectl apply -f ingress.yml
Kuna me teeme seda kõike oma masinas, lisame lihtsalt oma sõlme IP-aadressi faili /etc/hosts, et suunata http-päringud meie minikube'i NGINX-i koormuse tasakaalustajasse.
192.168.99.100 hello-quarkus.info
See on kõik, nüüd on meie minikube teenus saadaval väljastpoolt Nginxi sissepääsukontrolleri kaudu.
Noh, see oli lihtne, eks? Või mitte nii palju?
Käitage OpenShiftiga (koodivalmidusega konteinerid)
Ja nüüd vaatame, kuidas see kõik Red Hat OpenShift Container Platformil (OCP) tehtud on.
Nagu minikube puhul, valime skeemi ühe sõlme OpenShift klastriga Code Ready Containers (CRC) kujul. Varem nimetati seda minishiftiks ja see põhines OpenShift Origin projektil, kuid nüüd on see CRC ja ehitatud Red Hati OpenShift konteineriplatvormile.
Siin, vabandust, me ei saa jätta ütlemata: "OpenShift on suurepärane!"
Algselt mõtlesime kirjutada, et OpenShifti arendus ei erine Kubernetes arendamisest. Ja tegelikult see nii ongi. Kuid selle postituse kirjutamise käigus meenus meile, kui palju tarbetuid liigutusi peate tegema, kui teil pole OpenShifti, ja seetõttu on see jällegi ilus. Meile meeldib, kui asjad on lihtsad, ja see, kui lihtne on meie eeskuju OpenShiftis kasutusele võtta ja käivitada võrreldes minikube'iga, inspireeris meid seda postitust kirjutama.
Käime protsessi läbi ja vaatame, mida peame tegema.
Nii et minikube näite puhul alustasime Dockeriga... Oota, me ei pea enam Dockerit masinasse installima.
Ja me ei vaja kohalikku gitti.
Ja Mavenit pole vaja.
Ja te ei pea käsitsi konteineripilti looma.
Ja te ei pea otsima konteineripiltide hoidlat.
Ja te ei pea installima sissepääsukontrollerit.
Ja te ei pea ka sissepääsu konfigureerima.
Kas sa saad aru? Meie rakenduse juurutamiseks ja käitamiseks OpenShiftis pole ülaltoodut vaja. Ja protsess ise on järgmine.
1. samm – OpenShifti klastri käivitamine
Kasutame Red Hati Code Ready Containereid, mis on sisuliselt sama Minikube, kuid ainult täieliku ühesõlmelise Openshift-klastriga.
crc start
2. samm – looge rakendus ja juurutage see OpenShift-klastrisse
Just selles etapis avaldub OpenShifti lihtsus ja mugavus kogu oma hiilguses. Nagu kõigi Kubernetese distributsioonide puhul, on meil rakenduse klastris käitamiseks palju võimalusi. Ja nagu KUK-i puhul, valime konkreetselt kõige lihtsama.
OpenShift on alati loodud konteinerrakenduste loomise ja käitamise platvormina. Konteinerite ehitamine on alati olnud selle platvormi lahutamatu osa, seega on vastavate ülesannete jaoks olemas hunnik Kubernetese lisaressursse.
Kasutame OpenShifti Source 2 Image (S2I) protsessi, millel on mitu erinevat viisi allika (koodi või kahendfailide) leidmiseks ja selle muutmiseks konteinerkujutiseks, mis töötab OpenShifti klastris.
Selleks vajame kahte asja:
- Meie lähtekood git-hoidlas
- Builder-image, mille alusel koostet teostatakse.
Selliseid pilte on palju, neid haldab nii Red Hat kui ka kogukond, ja me kasutame OpenJDK pilti, kuna ma ehitan Java rakendust.
Saate käivitada S2I-järgu nii OpenShift Developeri graafiliselt konsoolilt kui ka käsurealt. Kasutame käsku new-app, öeldes, kust hankida ehitaja pilt ja meie lähtekood.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
See on kõik, meie rakendus on loodud. Seda tehes tegi S2I protsess järgmisi asju:
- Loodud teenuse build-pod kõikvõimalike rakenduse loomisega seotud asjade jaoks.
- Loodud OpenShift Buildi konfiguratsioon.
- Laadisin koostaja pildi alla sisemisse OpenShifti dokkimisregistrisse.
- Klooniti "Tere maailm" kohalikku hoidlasse.
- Nägin, et seal oli maven pom ja nii koostasin rakenduse koos maveniga.
- Loodud uus konteineri kujutis, mis sisaldab kompileeritud Java-rakendust, ja lisada see pilt sisemisse konteineriregistrisse.
- Loodud Kubernetese juurutus koos podi, teenuse jne spetsifikatsioonidega.
- Käivitatud juurutamise konteineri kujutis.
- Eemaldatud hooldusmoodul.
Selles loendis on palju, kuid peamine on see, et kogu ehitamine toimub ainult OpenShifti sees, sisemine Dockeri register on OpenShifti sees ning ehitusprotsess loob kõik Kubernetese komponendid ja käivitab need klastris.
Kui jälgite visuaalselt konsoolis S2I käivitamist, näete, kuidas ehituspodi ehituse ajal käivitatakse.
Ja nüüd vaatame ehituspodi logisid: esiteks näete, kuidas maven oma tööd teeb ja meie Java-rakenduse loomiseks sõltuvusi alla laadib.
Pärast Maveni järgu lõpetamist alustatakse konteineri kujutise ehitamist ja seejärel saadetakse see ehitatud pilt sisemisse hoidlasse.
Kõik, montaažiprotsess on lõppenud. Nüüd veendume, et meie rakenduse kaunad ja teenused on klastris käivitunud.
oc get service
See on kõik. Ja seal on ainult üks meeskond. Kõik, mida me tegema peame, on avaldada see teenus välisele juurdepääsule.
3. samm – muutke teenus väljastpoolt juurdepääsetavaks
Nagu KUK-i puhul, vajab ka meie “Tere maailm” OpenShifti platvormil ruuterit välise liikluse suunamiseks klastrisisesesse teenusesse. OpenShiftis teeb see selle väga lihtsaks. Esiteks on vaikimisi klastrisse installitud HAProxy marsruutimise komponent (selle saab muuta samale NGINX-ile). Teiseks on olemas spetsiaalsed ja hästi konfigureeritavad ressursid nimega Routes, mis meenutavad Ingressi objekte vanas heas Kubernetes (tegelikult mõjutasid OpenShifti marsruudid Ingressi objektide disaini, mida saab nüüd OpenShiftis kasutada), kuid meie "Tere Maailm" ja peaaegu kõigil muudel juhtudel piisab meile tavalisest marsruudist ilma täiendava konfiguratsioonita.
"Hello World" jaoks marsruutitava FQDN-i loomiseks (jah, OpenShiiftil on teenusenimede järgi marsruutimiseks oma DNS), avalikustame lihtsalt oma teenuse:
oc expose service quarkus-hello-world
Kui vaatate vastloodud marsruuti, leiate sealt FQDN-i ja muud marsruutimisteavet:
oc get route
Ja lõpuks pääseme oma teenusele ligi brauserist:
Aga nüüd oli see tõesti lihtne!
Armastame Kubernetest ja kõike, mida see tehnoloogia võimaldab teha, ning armastame ka lihtsust ja kergust. Kubernetesi eesmärk oli muuta hajutatud, skaleeritavad konteinerid uskumatult hõlpsasti kasutatavaks, kuid selle lihtsusest ei piisa tänapäeval rakenduste tootmiseks. Siin tuleb mängu OpenShift, mis käib ajaga kaasas ja pakub arendajakeskseid Kubernetes. OpenShifti platvormi spetsiaalselt arendaja jaoks kohandamiseks on tehtud palju jõupingutusi, sealhulgas selliste tööriistade loomine nagu S2I, ODI, arendajaportaal, OpenShift Operator Framework, IDE integreerimine, arendajakataloogid, Helmi integreerimine, jälgimine ja paljud teised.
Loodame, et see artikkel oli teile huvitav ja kasulik. Ja lisaressursse, materjale ja muud OpenShifti platvormil arendamiseks kasulikku leiab portaalist .
Allikas: www.habr.com