Ta objava je bila napisana zato, ker je imelo naše osebje kar nekaj pogovorov s strankami o razvoju aplikacij na Kubernetes in posebnostih takšnega razvoja na OpenShift.
Ponavadi začnemo s tezo, da je Kubernetes le Kubernetes, OpenShift pa je že platforma Kubernetes, kot sta Microsoft AKS ali Amazon EKS. Vsaka od teh platform ima svoje prednosti, osredotočene na določeno ciljno publiko. In potem pogovor že steče v primerjavo prednosti in slabosti posameznih platform.
Na splošno smo razmišljali, da bi to objavo napisali z izhodom, kot je »Poslušajte, ni pomembno, kje zaženete kodo, na OpenShift ali na AKS, na EKS, na nekaterih Kubernetes po meri, da na katerem koli Kubernetesu (recimo mu na kratko KUK) "Tam in tam je res preprosto."
Nato smo nameravali vzeti najpreprostejši "Hello World" in z njim pokazati, kaj je skupno in kakšne so razlike med CMC in Red Hat OpenShift Container Platform (v nadaljevanju OCP ali preprosto OpenShift).
Vendar smo med pisanjem te objave ugotovili, da smo se uporabe OpenShift tako navadili, da se preprosto ne zavedamo, kako je zrasel in se spremenil v neverjetno platformo, ki je postala veliko več kot le distribucija Kubernetes. Ponavadi jemljemo zrelost in preprostost OpenShift-a za samoumevno in izgubljamo izpred oči njegovo veličastnost.
Na splošno je prišel čas za aktivno kesanje in zdaj bomo korak za korakom primerjali zagon našega »Hello World« na KUK in na OpenShift, in to bomo storili čim bolj objektivno (no, razen včasih prikazovanja osebnega odnos do teme). Če vas zanima čisto subjektivno mnenje o tem vprašanju, ga lahko preberete . In v tej objavi se bomo držali dejstev in samo dejstev.
Grozdi
Torej, naš "Hello World" potrebuje grozde. Recimo takoj "ne" kakršnim koli javnim oblakom, da ne bi plačevali strežnikov, registrov, omrežij, prenosa podatkov itd. V skladu s tem izberemo preprosto gručo z enim vozliščem (za KUK) in (za gručo OpenShift). Obe možnosti sta zelo enostavni za namestitev, vendar zahtevata precej sredstev na vašem prenosniku.
Montaža na KUK-e
Torej gremo.
1. korak – Izdelava naše slike vsebnika
Začnimo z uvedbo našega »Hello World« v minikube. To bo zahtevalo:
- 1. Nameščen Docker.
- 2. Git je nameščen.
- 3. Nameščen Maven (pravzaprav ta projekt uporablja binarno datoteko mvnw, tako da lahko brez nje).
- 4. Pravzaprav že sam vir, tj. repozitorij klon
Prvi korak je ustvariti projekt Quarkus. Naj vas ne skrbi, če še nikoli niste delali s Quarkus.io – preprosto je. Samo izberete komponente, ki jih želite uporabiti v projektu (RestEasy, Hibernate, Amazon SQS, Camel itd.), nato pa Quarkus sam, brez vaše udeležbe, nastavi arhetip maven in vse postavi na github. Se pravi, dobesedno en klik miške in končali ste. Zato obožujemo Quarkus.
Najlažji način za vgradnjo našega »Hello World« v sliko vsebnika je uporaba razširitev quarkus-maven za Docker, ki bodo opravile vse potrebno delo. S prihodom Quarkusa je to postalo zelo enostavno in preprosto: dodajte razširitev container-image-docker in lahko ustvarite slike z uporabo ukazov maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
In končno, svojo podobo gradimo z Mavenom. Posledično se naša izvorna koda spremeni v pripravljeno sliko vsebnika, ki jo lahko že izvajamo v izvajalnem okolju vsebnika.
./mvnw -X clean package -Dquarkus.container-image.build=true
To je pravzaprav vse, zdaj lahko zaženete vsebnik z ukazom za docker run, potem ko ste našo storitev preslikali na vrata 8080, tako da je do nje mogoče dostopati.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Ko se primerek vsebnika zažene, ostane le še, da z ukazom curl preverimo, ali se naša storitev izvaja:
Torej, vse deluje in je bilo res enostavno in preprosto.
2. korak – Predložite naš vsebnik v repozitorij slik vsebnika
Za zdaj je slika, ki smo jo ustvarili, shranjena lokalno v naši lokalni shrambi vsebnika. Če želimo to sliko uporabiti v našem okolju KUK, jo moramo dati v drugo skladišče. Kubernetes nima teh funkcij, zato bomo uporabili dockerhub. Ker, prvič, je zastonj, in drugič, (skoraj) vsi to počnejo.
Tudi to je zelo preprosto in tukaj je potreben samo račun dockerhub.
Torej, namestimo dockerhub in tja pošljemo svojo sliko.
3. korak - Zaženite Kubernetes
Obstaja veliko načinov za sestavljanje konfiguracije kubernetes za zagon našega "Hello World", vendar bomo uporabili najpreprostejšega od njih, ker smo takšni ljudje ...
Najprej zaženimo gručo minikube:
minikube start
4. korak – razporedite sliko vsebnika
Zdaj moramo našo kodo in sliko vsebnika pretvoriti v konfiguracijo kubernetes. Z drugimi besedami, potrebujemo pod in definicijo uvajanja, ki kaže na našo sliko vsebnika na dockerhub. Eden najlažjih načinov za to je, da zaženete ukaz create deployment, ki kaže na našo sliko:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
S tem ukazom smo našemu COOK-u naročili, naj ustvari konfiguracijo uvajanja, ki mora vsebovati specifikacijo pod za našo sliko vsebnika. Ta ukaz bo uporabil to konfiguracijo tudi za našo gručo minikube in ustvaril razmestitev, ki bo prenesla našo sliko vsebnika in zagnala pod v gruči.
5. korak - odprite dostop do naše storitve
Zdaj, ko imamo nameščeno sliko vsebnika, je čas, da razmislimo o tem, kako konfigurirati zunanji dostop do te storitve Restful, ki je pravzaprav programirana v naši kodi.
Tukaj je veliko načinov. Z ukazom expose lahko na primer samodejno ustvarite ustrezne komponente Kubernetes, kot so storitve in končne točke. Pravzaprav bomo to naredili z izvedbo ukaza expose za naš razmestitveni objekt:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Vzemimo si trenutek in si oglejmo možnost "-type" ukaza expose.
Ko razkrijemo in ustvarimo komponente, potrebne za delovanje naše storitve, moramo med drugim imeti možnost povezave od zunaj s storitvijo hello-quarkus, ki je v našem programsko definiranem omrežju. In parameter tip nam omogoča ustvarjanje in povezovanje stvari, kot so izravnalniki obremenitve, za usmerjanje prometa v to omrežje.
Na primer s pisanjem tip=LoadBalancer, samodejno inicializiramo javni izravnalnik obremenitve v oblaku za povezavo z našo gručo Kubernetes. To je seveda super, vendar morate razumeti, da bo takšna konfiguracija tesno vezana na določen javni oblak in jo bo težje prenašati med instancami Kubernetes v različnih okoljih.
V našem primeru tip=NodePort, to pomeni, da klic v našo storitev poteka prek naslova IP vozlišča in številke vrat. Ta možnost vam omogoča, da ne uporabljate javnih oblakov, vendar zahteva številne dodatne korake. Prvič, potrebujete svoj lastni izravnalnik obremenitve, zato bomo v našo gručo uvedli izravnalnik obremenitve NGINX.
6. korak - Nastavite izravnalnik obremenitve
minikube ima številne funkcije platforme, ki olajšajo ustvarjanje komponent, ki jih potrebujete za zunanji dostop, kot so vhodni krmilniki. Minikube je priložen vstopnemu krmilniku Nginx in vse, kar moramo storiti, je, da ga omogočimo in konfiguriramo.
minikube addons enable ingress
Zdaj bomo s samo enim ukazom ustvarili vstopni krmilnik Nginx, ki bo deloval znotraj naše gruče minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Korak 7 - Nastavite vstop
Zdaj moramo konfigurirati vstopni krmilnik Nginx za sprejemanje zahtev hello-quarkus.
In končno moramo uporabiti to konfiguracijo.
kubectl apply -f ingress.yml
Ker vse to počnemo na lastnem računalniku, preprosto dodamo naslov IP našega vozlišča v datoteko /etc/hosts, da usmerimo zahteve http v naš minikube na izravnalnik obremenitve NGINX.
192.168.99.100 hello-quarkus.info
To je to, zdaj je naša storitev minikube na voljo od zunaj prek vstopnega krmilnika Nginx.
No, to je bilo enostavno, kajne? Ali ne toliko?
Zagon na OpenShift (vsebniki, pripravljeni za kodo)
Zdaj pa poglejmo, kako se vse to izvaja na vsebniški platformi Red Hat OpenShift (OCP).
Tako kot v primeru minikube izberemo shemo z gručo OpenShift z enim vozliščem v obliki vsebnikov, pripravljenih za kodo (CRC). Prej se je imenoval minishift in je temeljil na projektu OpenShift Origin, zdaj pa je CRC in je zgrajen na platformi OpenShift Container Platform družbe Red Hat.
Tu si, žal, ne moremo kaj, da ne bi rekli: "OpenShift je čudovit!"
Sprva smo mislili napisati, da se razvoj na OpenShift ne razlikuje od razvoja na Kubernetesu. In v bistvu je tako. Toda med pisanjem te objave smo se spomnili, koliko nepotrebnih gibov morate narediti, ko nimate OpenShift, in zato je spet lepo. Radi imamo stvari, ki so enostavne, in to, kako enostavno je uvesti in zagnati naš primer na OpenShift v primerjavi z minikube, nas je navdihnilo, da smo napisali to objavo.
Pojdimo skozi postopek in poglejmo, kaj moramo storiti.
V primeru minikube smo torej začeli z Dockerjem ... Počakajte, Dockerja ne potrebujemo več nameščenega na stroju.
In ne potrebujemo lokalnega gita.
In Maven ni potreben.
In slike vsebnika vam ni treba ustvariti ročno.
In ni vam treba iskati nobenega repozitorija slik vsebnikov.
In ni vam treba namestiti vstopnega krmilnika.
Prav tako vam ni treba konfigurirati vstopa.
Ali razumeš? Za uvedbo in zagon naše aplikacije na OpenShift ni potrebno nič od zgoraj navedenega. In sam postopek je naslednji.
1. korak – Zagon gruče OpenShift
Uporabljamo Code Ready Containers podjetja Red Hat, ki je v bistvu isti Minikube, vendar le s polno gručo Openshift z enim vozliščem.
crc start
2. korak - zgradite in namestite aplikacijo v gručo OpenShift
Na tem koraku se preprostost in priročnost OpenShift pokažeta v vsem svojem sijaju. Kot pri vseh distribucijah Kubernetes imamo na voljo veliko načinov za izvajanje aplikacije v gruči. In tako kot pri KUK-u izberemo posebej najenostavnejšega.
OpenShift je bil vedno zgrajen kot platforma za gradnjo in izvajanje kontejnerskih aplikacij. Gradnja vsebnikov je bila vedno sestavni del te platforme, zato obstaja kup dodatnih virov Kubernetes za ustrezna opravila.
Uporabili bomo proces Source 2 Image (S2I) OpenShift, ki ima več različnih načinov, da našo izvorno kodo (kodo ali binarne datoteke) spremenimo v posodobljeno sliko, ki se izvaja v gruči OpenShift.
Za to potrebujemo dve stvari:
- Naša izvorna koda v repozitoriju git
- Builder-slika, na podlagi katere bo izvedena montaža.
Obstaja veliko takšnih slik, ki jih vzdržujeta Red Hat in skupnost, in uporabili bomo sliko OpenJDK, no, saj gradim aplikacijo Java.
Zgradbo S2I lahko zaženete iz grafične konzole OpenShift Developer in iz ukazne vrstice. Uporabili bomo ukaz new-app, ki mu bo povedal, kje naj dobi sliko graditelja in našo izvorno kodo.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
To je to, naša aplikacija je ustvarjena. Pri tem je proces S2I naredil naslednje:
- Ustvarjen je pod za gradnjo storitve za vse vrste stvari, povezanih z gradnjo aplikacije.
- Ustvaril konfiguracijo OpenShift Build.
- Prenesel sem sliko graditelja v notranji register dockerjev OpenShift.
- Kloniran »Hello World« v lokalno skladišče.
- Videl sem, da je tam maven pom, zato sem aplikacijo prevedel z uporabo maven.
- Ustvaril je novo sliko vsebnika, ki vsebuje prevedeno aplikacijo Java, in to sliko postavil v notranji register vsebnikov.
- Ustvarjena uvedba Kubernetes s specifikacijami za pod, storitev itd.
- Zagnana slika vsebnika za razmestitev.
- Odstranjen servisni build-pod.
Na tem seznamu je veliko, a glavna stvar je, da se celotna izdelava zgodi izključno znotraj OpenShift, notranji register Docker je znotraj OpenShift in postopek gradnje ustvari vse komponente Kubernetes in jih izvaja v gruči.
Če vizualno spremljate zagon S2I v konzoli, lahko vidite, kako se gradbeni sklop zažene, ko je gradnja končana.
In zdaj si poglejmo dnevnike gradbenega sklopa: najprej si lahko ogledate, kako maven opravlja svoje delo in prenaša odvisnosti za izdelavo naše aplikacije java.
Ko je gradnja maven končana, se začne gradnja slike vsebnika, nato pa se ta zgrajena slika pošlje v notranji repozitorij.
Vse, postopek montaže je končan. Zdaj pa se prepričajmo, da so se sklopi in storitve naše aplikacije zagnali v gruči.
oc get service
To je vse. In samo ena ekipa. Vse kar moramo storiti je, da to storitev izpostavimo dostopu od zunaj.
3. korak – izpostavite storitev dostopu od zunaj
Kot v primeru KUK-a, na platformi OpenShift tudi naš »Hello World« potrebuje usmerjevalnik za usmerjanje zunanjega prometa na storitev znotraj gruče. V OpenShift je to zelo enostavno. Prvič, komponenta usmerjanja HAProxy je privzeto nameščena v gručo (lahko jo spremenite v isti NGINX). Drugič, obstajajo posebni in zelo nastavljivi viri, imenovani Routes, ki spominjajo na objekte Ingress v dobrem starem Kubernetesu (pravzaprav so Routes OpenShift močno vplivali na zasnovo objektov Ingress, ki jih je zdaj mogoče uporabiti v OpenShiftu), vendar za naše "Pozdravljeni World«, v skoraj vseh drugih primerih pa nam standardna Route zadostuje brez dodatne konfiguracije.
Za ustvarjanje usmerjevalnega FQDN za »Hello World« (da, OpenShiift ima lasten DNS za usmerjanje po imenih storitev), preprosto izpostavimo našo storitev:
oc expose service quarkus-hello-world
Če pogledate na novo ustvarjeno pot, lahko tam najdete FQDN in druge informacije o usmerjanju:
oc get route
In končno, do naše storitve dostopamo iz brskalnika:
Ampak zdaj je bilo res enostavno!
Obožujemo Kubernetes in vse, kar nam ta tehnologija omogoča, obožujemo pa tudi preprostost in lahkotnost. Kubernetes je bil ustvarjen za neverjetno poenostavitev delovanja porazdeljenih, razširljivih vsebnikov, vendar njegova preprostost danes ni več dovolj za uvedbo aplikacij v proizvodnjo. Tu nastopi OpenShift, ki gre v korak s časom in ponuja Kubernetes, namenjen predvsem razvijalcem. Veliko truda je bilo vloženega v prilagoditev platforme OpenShift posebej za razvijalce, vključno z ustvarjanjem orodij, kot so S2I, ODI, portal za razvijalce, OpenShift Operator Framework, integracija IDE, katalogi razvijalcev, integracija Helm, spremljanje in mnoga druga.
Upamo, da je bil ta članek za vas zanimiv in koristen. Na portalu pa lahko najdete dodatne vire, materiale in druge stvari, uporabne za razvoj na platformi OpenShift .
Vir: www.habr.com