Hierdie pos is geskryf omdat ons personeel heelwat gesprekke met kliënte gehad het oor die ontwikkeling van toepassings op Kubernetes en die besonderhede van sulke ontwikkeling op OpenShift.
Ons begin gewoonlik met die tesis dat Kubernetes net Kubernetes is, en OpenShift is reeds 'n Kubernetes-platform, soos Microsoft AKS of Amazon EKS. Elkeen van hierdie platforms het sy eie voordele, gefokus op 'n spesifieke teikengehoor. En daarna vloei die gesprek reeds oor in ’n vergelyking van die sterk- en swakpunte van spesifieke platforms.
Oor die algemeen het ons daaraan gedink om hierdie pos te skryf met 'n uitset soos "Luister, dit maak nie saak waar jy die kode laat loop nie, op OpenShift of op AKS, op EKS, op sommige pasgemaakte Kubernetes, ja op enige Kubernetes (kom ons noem dit kortweg KUK) "Dit is regtig eenvoudig, beide daar en daar."
Toe het ons beplan om die eenvoudigste "Hallo Wêreld" te neem en dit te gebruik om te wys wat algemeen is en wat die verskille is tussen die CMC en die Red Hat OpenShift Container Platform (hierna OCP of bloot OpenShift).
Met die skryf van hierdie plasing het ons egter besef dat ons so gewoond geraak het aan die gebruik van OpenShift dat ons eenvoudig nie besef hoe dit gegroei het en verander het in 'n wonderlike platform wat veel meer as net 'n Kubernetes-verspreiding geword het nie. Ons is geneig om die volwassenheid en eenvoud van OpenShift as vanselfsprekend te aanvaar, terwyl ons die grootsheid daarvan uitkyk.
Oor die algemeen het die tyd aangebreek vir aktiewe bekering, en nou sal ons stap vir stap die ingebruikneming van ons "Hello World" op KUK en op OpenShift vergelyk, en ons sal dit so objektief moontlik doen (wel, miskien wys soms 'n persoonlike houding teenoor die onderwerp). As jy belangstel in 'n suiwer subjektiewe mening oor hierdie kwessie, dan kan jy dit lees . En in hierdie plasing sal ons by die feite bly en slegs die feite.
Trosse
Dus, ons "Hallo Wêreld" het trosse nodig. Kom ons sê net "nee" vir enige publieke wolke, om nie te betaal vir bedieners, registers, netwerke, data-oordrag, ens. Gevolglik kies ons 'n eenvoudige een-nodus kluster op (vir KUK) en (vir 'n OpenShift-kluster). Albei hierdie opsies is baie maklik om te installeer, maar vereis nogal baie hulpbronne op jou skootrekenaar.
Vergadering op KUK-e
Dus, kom ons gaan.
Stap 1 - Bou ons houerbeeld
Kom ons begin deur ons "Hallo Wêreld" na minikube te ontplooi. Dit sal vereis:
- 1. Geïnstalleerde Docker.
- 2. Geïnstalleerde Git.
- 3. Geïnstalleerde Maven (eintlik gebruik hierdie projek mvnw binary, so jy kan daarsonder klaarkom).
- 4. Eintlik is die bron self, d.w.s. bewaarplek kloon
Die eerste stap is om 'n Quarkus-projek te skep. Moenie bang wees as jy nog nooit Quarkus.io gebruik het nie - dit is maklik. Jy kies net die komponente wat jy in die projek wil gebruik (RestEasy, Hibernate, Amazon SQS, Camel, ens.), en dan stel Quarkus self, sonder enige van jou deelname, die maven-argetipe op en sit alles op github. Dit wil sê, letterlik een klik van die muis - en jy is klaar. Dit is hoekom ons lief is vir Quarkus.
Die maklikste manier om ons "Hallo Wêreld" in 'n houerbeeld te bou, is om die quarkus-maven-uitbreidings vir Docker te gebruik, wat al die nodige werk sal doen. Met die koms van Quarkus het dit baie maklik en eenvoudig geword: voeg die container-image-docker-uitbreiding by en jy kan beelde skep met maven-opdragte.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
En uiteindelik bou ons ons beeld met Maven. As gevolg hiervan verander ons bronkode in 'n klaargemaakte houerbeeld, wat reeds in die houerlooptyd uitgevoer kan word.
./mvnw -X clean package -Dquarkus.container-image.build=true
Dit is eintlik al, nou kan jy die houer laat loop met die docker run-opdrag, nadat ons ons diens na poort 8080 gekarteer het sodat dit toegang kan kry.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Nadat die houer-instansie begin het, is al wat oorbly om te kyk met die krul-opdrag dat ons diens loop:
So, alles werk, en dit was regtig maklik en eenvoudig.
Stap 2 - Dien ons houer in by die houerbeeldbewaarplek
Vir nou word die beeld wat ons geskep het plaaslik in ons plaaslike houerberging gestoor. As ons hierdie prent in ons KUK-omgewing wil gebruik, moet ons dit in 'n ander bewaarplek plaas. Kubernetes het nie hierdie kenmerke nie, so ons sal dockerhub gebruik. Want eerstens is dit gratis, en tweedens doen (byna) almal dit.
Dit is ook baie eenvoudig, en slegs 'n dockerhub-rekening is hier nodig.
Dus, ons installeer dockerhub en stuur ons beeld daarheen.
Stap 3 - Begin Kubernetes
Daar is baie maniere om 'n kubernetes-konfigurasie saam te stel om ons "Hello World" uit te voer, maar ons sal die eenvoudigste daarvan gebruik, want ons is sulke mense ...
Eerstens begin ons die minikube-groepering:
minikube start
Stap 4 - Ontplooi ons houerbeeld
Nou moet ons ons kode en houerbeeld omskakel na kubernetes-konfigurasie. Met ander woorde, ons benodig 'n pod en 'n ontplooiingsdefinisie wat na ons houerbeeld op dockerhub wys. Een van die maklikste maniere om dit te doen, is om die skep-ontplooiingsopdrag uit te voer wat na ons beeld wys:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Met hierdie opdrag het ons ons KOOK aangesê om 'n ontplooiingskonfigurasie te skep, wat die peulspesifikasie vir ons houerbeeld moet bevat. Hierdie opdrag sal ook hierdie konfigurasie op ons minikube-groepering toepas, en 'n ontplooiing skep wat ons houerbeeld sal aflaai en 'n pod op die groep sal laat loop.
Stap 5 - oop toegang tot ons diens
Noudat ons 'n ontplooide houerbeeld het, is dit tyd om te dink oor hoe om eksterne toegang tot hierdie Restful-diens op te stel, wat in werklikheid in ons kode geprogrammeer is.
Hier is baie maniere. Byvoorbeeld, jy kan die blootstel-opdrag gebruik om outomaties toepaslike Kubernetes-komponente soos dienste en eindpunte te skep. Eintlik is dit wat ons sal doen deur die blootstelopdrag vir ons ontplooiingsvoorwerp uit te voer:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Kom ons vertoef vir 'n oomblik by die "-tipe" opsie van die blootstelopdrag.
Wanneer ons die komponente ontbloot en skep wat nodig is om ons diens uit te voer, moet ons onder meer van buite kan koppel aan die hello-quarkus-diens wat binne ons sagteware-gedefinieerde netwerk sit. En parameter tipe stel ons in staat om dinge soos lasbalanseerders te skep en te koppel om verkeer na daardie netwerk te lei.
Byvoorbeeld, skryf tipe=LoadBalancer, inisialiseer ons outomaties die publieke wolklasbalanseerder om aan ons Kubernetes-kluster te koppel. Dit is natuurlik wonderlik, maar jy moet verstaan dat so 'n konfigurasie stewig gekoppel sal wees aan 'n spesifieke publieke wolk en dit sal moeiliker wees om dit tussen Kubernetes-gevalle in verskillende omgewings oor te dra.
In ons voorbeeld tipe=NodePort, dit wil sê, die oproep na ons diens gaan deur die IP-adres van die nodus en die poortnommer. Hierdie opsie laat jou toe om geen publieke wolke te gebruik nie, maar vereis 'n aantal bykomende stappe. Eerstens het jy jou eie lasbalanseerder nodig, so ons sal die NGINX-lasbalanseerder in ons groepie ontplooi.
Stap 6 - Stel 'n lasbalanseerder op
minikube het 'n aantal platformkenmerke wat dit maklik maak om die komponente te skep wat jy nodig het vir eksterne toegang, soos ingangsbeheerders. Minikube kom saam met die Nginx-ingangsbeheerder saam, en al wat ons hoef te doen is om dit te aktiveer en in te stel.
minikube addons enable ingress
Nou, met net een opdrag, sal ons 'n Nginx-ingangsbeheerder skep wat binne ons minikube-groepering sal werk:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Stap 7 - Stel die ingang op
Nou moet ons die Nginx-ingangsbeheerder instel om hallo-quarkus-versoeke te aanvaar.
En uiteindelik moet ons hierdie konfigurasie toepas.
kubectl apply -f ingress.yml
Aangesien ons dit alles op ons eie masjien doen, voeg ons eenvoudig ons nodus se IP-adres by die /etc/hosts-lêer om http-versoeke na ons minikube na die NGINX load balancer te rig.
192.168.99.100 hello-quarkus.info
Dit is dit, nou is ons minikube-diens van buite af beskikbaar deur die Nginx-ingangsbeheerder.
Wel, dit was maklik, reg? Of nie soveel nie?
Hardloop op OpenShift (kode-gereed houers)
En kom ons kyk nou hoe dit alles op die Red Hat OpenShift Container Platform (OCP) gedoen word.
Soos in die geval van minikube, kies ons 'n skema met 'n enkelnode OpenShift-kluster in die vorm van Code Ready Containers (CRC). Dit is vroeër minishift genoem en was gebaseer op die OpenShift Origin-projek, maar nou is dit CRC en gebou op Red Hat se OpenShift Container Platform.
Hier, jammer, ons kan nie anders as om te sê: "OpenShift is wonderlik!"
Aanvanklik het ons gedink om te skryf dat ontwikkeling op OpenShift nie verskil van ontwikkeling op Kubernetes nie. En eintlik is dit hoe dit is. Maar in die proses om hierdie pos te skryf, het ons onthou hoeveel onnodige bewegings jy moet maak as jy nie OpenShift het nie, en daarom is dit weer pragtig. Ons hou daarvan dat dinge maklik is, en hoe maklik dit is om ons voorbeeld op OpenShift te ontplooi en uit te voer in vergelyking met minikube, is wat ons geïnspireer het om hierdie pos te skryf.
Kom ons loop deur die proses en kyk wat ons moet doen.
So in die minikube-voorbeeld het ons met Docker begin ... Wag, ons het nie meer Docker nodig wat op die masjien geïnstalleer is nie.
En ons het nie 'n plaaslike git nodig nie.
En Maven is nie nodig nie.
En jy hoef nie 'n houerbeeld met die hand te skep nie.
En jy hoef nie na enige bewaarplek van houerbeelde te soek nie.
En jy hoef nie 'n ingangsbeheerder te installeer nie.
En jy hoef ook nie ingang te konfigureer nie.
Verstaan jy? Om ons toepassing op OpenShift te ontplooi en uit te voer, is nie een van die bogenoemde nodig nie. En die proses self is soos volg.
Stap 1 – Begin jou OpenShift-kluster
Ons gebruik Code Ready Containers van Red Hat, wat in wese dieselfde Minikube is, maar slegs met 'n volledige enkelnode Openshift-kluster.
crc start
Stap 2 - Bou en ontplooi die toepassing na die OpenShift-kluster
Dit is by hierdie stap dat die eenvoud en gerief van OpenShift homself in al sy glorie manifesteer. Soos met alle Kubernetes-verspreidings, het ons baie maniere om 'n toepassing op 'n groep te laat loop. En, soos in die geval van KUK, kies ons spesifiek die eenvoudigste een.
OpenShift is nog altyd gebou as 'n platform vir die bou en uitvoer van houertoepassings. Die bou van houers was nog altyd 'n integrale deel van hierdie platform, so daar is 'n klomp bykomende Kubernetes-hulpbronne vir die ooreenstemmende take.
Ons sal OpenShift se Source 2 Image (S2I) proses gebruik, wat verskeie maniere het om ons bron (kode of binaries) te neem en dit te omskep in 'n houervormige beeld wat op 'n OpenShift-kluster loop.
Hiervoor het ons twee dinge nodig:
- Ons bronkode in die git-bewaarplek
- Bouer-beeld, gebaseer op wat die samestelling uitgevoer sal word.
Daar is baie sulke beelde, wat beide deur Red Hat en deur die gemeenskap onderhou word, en ons sal die OpenJDK-beeld gebruik, wel, aangesien ek 'n Java-toepassing bou.
U kan 'n S2I-bou sowel vanaf die OpenShift Developer-grafiese konsole as vanaf die opdragreël laat loop. Ons sal die nuwe-app-opdrag gebruik, wat dit vertel waar om die bouer-prent en ons bronkode te kry.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Dit is dit, ons toepassing is geskep. Sodoende het die S2I-proses die volgende dinge gedoen:
- Het 'n diensbou-pod geskep vir allerhande dinge wat verband hou met die bou van die toepassing.
- Het 'n OpenShift Build-konfigurasie geskep.
- Ek het die bouer-beeld na die interne OpenShift-dokker-register afgelaai.
- Gekloon "Hallo Wêreld" na plaaslike bewaarplek.
- Het gesien daar is 'n maven pom in en so die app saamgestel met maven.
- Het 'n nuwe houerbeeld geskep wat die saamgestelde Java-toepassing bevat en plaas hierdie prent in die interne houerregister.
- Het 'n Kubernetes-ontplooiing geskep met spesifikasies vir 'n pod, diens, ens.
- Het ontplooi houerbeeld bekendgestel.
- Verwyder diens build-pod.
Daar is baie op hierdie lys, maar die belangrikste ding is dat die hele bou uitsluitlik binne OpenShift plaasvind, die interne Docker-register is binne OpenShift, en die bouproses skep alle Kubernetes-komponente en laat dit op die cluster hardloop.
As jy die bekendstelling van S2I in die konsole visueel monitor, kan jy sien hoe die boupod tydens die bou van stapel gestuur word.
En kom ons kyk nou na die bouer-peul se logs: eerstens, daar kan jy sien hoe Maven sy werk doen en afhanklikhede aflaai om ons java-toepassing te bou.
Nadat die maven-bou voltooi is, word die bou van die houerbeeld begin, en dan word hierdie geboude prent na die interne bewaarplek gestuur.
Alles, die monteerproses is voltooi. Kom ons maak nou seker dat die peule en dienste van ons toepassing in die groep begin het.
oc get service
Dis al. En daar is net een span. Al wat ons hoef te doen is om hierdie diens bloot te stel vir toegang van buite.
Stap 3 - maak die diens bloot vir toegang van buite
Soos in die geval van KUK, op die OpenShift-platform, benodig ons "Hello World" ook 'n roeteerder om eksterne verkeer na 'n diens binne die groepering te lei. In OpenShift maak dit dit baie maklik. Eerstens word die HAProxy-roeteringkomponent by verstek in die groep geïnstalleer (dit kan na dieselfde NGINX verander word). Tweedens, daar is spesiale en hoogs konfigureerbare hulpbronne genaamd Roetes, wat herinner aan Ingress-voorwerpe in goeie ou Kubernetes (om die waarheid te sê, OpenShift se Roetes het die ontwerp van Ingress-voorwerpe, wat nou in OpenShift gebruik kan word) sterk beïnvloed, maar vir ons "Hallo World", en in byna alle ander gevalle is die standaardroete vir ons genoeg sonder bykomende konfigurasie.
Om 'n roeteerbare FQDN vir "Hello World" te skep (ja, OpenShiift het sy eie DNS vir roetering volgens diensname), stel ons bloot ons diens bloot:
oc expose service quarkus-hello-world
As jy na die nuutgeskepte roete kyk, kan jy die FQDN en ander roete-inligting daar vind:
oc get route
En uiteindelik kry ons toegang tot ons diens vanaf die blaaier:
Maar nou was dit regtig maklik!
Ons is mal oor Kubernetes en alles wat hierdie tegnologie jou toelaat om te doen, en ons hou ook van eenvoud en ligtheid. Kubernetes is ontwerp om verspreide, skaalbare houers ongelooflik maklik te maak om te bedryf, maar die eenvoud daarvan is nie meer genoeg om toepassings vandag in produksie te bring nie. En dit is waar OpenShift ter sprake kom, wat tred hou met die tyd en Kubernetes bied, hoofsaaklik gefokus op die ontwikkelaar. Baie moeite is belê om die OpenShift-platform spesifiek vir die ontwikkelaar aan te pas, insluitend die skepping van instrumente soos S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-integrasie, Ontwikkelaarkatalogusse, Helm-integrasie, monitering, en vele ander.
Ons hoop dat hierdie artikel vir u interessant en nuttig was. En jy kan bykomende hulpbronne, materiaal en ander dinge vind wat nuttig is vir ontwikkeling op die OpenShift-platform op die portaal .
Bron: will.com