Dit bericht is geschreven omdat onze medewerkers nogal wat gesprekken met klanten hadden over het ontwikkelen van applicaties op Kubernetes en de specifieke kenmerken van een dergelijke ontwikkeling op OpenShift.
We beginnen meestal met de stelling dat Kubernetes gewoon Kubernetes is en dat OpenShift al een Kubernetes-platform is, zoals Microsoft AKS of Amazon EKS. Elk van deze platformen heeft zijn eigen voordelen, gericht op een bepaalde doelgroep. En daarna mondt het gesprek al uit in een vergelijking van de sterke en zwakke punten van specifieke platformen.
Over het algemeen dachten we erover om dit bericht te schrijven met een uitvoer als "Luister, het maakt niet uit waar je de code uitvoert, op OpenShift of op AKS, op EKS, op sommige aangepaste Kubernetes, ja op elke Kubernetes (laten we het kort KUK noemen) "Het is heel eenvoudig, zowel daar als daar."
Toen waren we van plan om de eenvoudigste "Hello World" te gebruiken om te laten zien wat gebruikelijk is en wat de verschillen zijn tussen de CMC en het Red Hat OpenShift Container Platform (hierna OCP of kortweg OpenShift genoemd).
Tijdens het schrijven van dit bericht realiseerden we ons echter dat we zo gewend zijn geraakt aan het gebruik van OpenShift dat we gewoon niet beseffen hoe het is gegroeid en is veranderd in een geweldig platform dat veel meer is geworden dan alleen een Kubernetes-distributie. We hebben de neiging om de volwassenheid en eenvoud van OpenShift als vanzelfsprekend te beschouwen, terwijl we de pracht ervan over het hoofd zien.
Over het algemeen is de tijd gekomen voor actief berouw, en nu zullen we stap voor stap de ingebruikname van onze "Hello World" op KUK en op OpenShift vergelijken, en we zullen het zo objectief mogelijk doen (nou ja, behalve soms een persoonlijk houding ten opzichte van het onderwerp). Als u geïnteresseerd bent in een puur subjectieve mening over deze kwestie, dan kunt u deze lezen . En in deze post houden we het bij de feiten en alleen de feiten.
Clusters
Onze "Hello World" heeft dus clusters nodig. Laten we gewoon "nee" zeggen tegen openbare clouds, om niet te betalen voor servers, registers, netwerken, gegevensoverdracht, enz. Daarom kiezen we voor een eenvoudig cluster met één knooppunt (voor KUK) en (voor een OpenShift-cluster). Beide opties zijn heel eenvoudig te installeren, maar vereisen nogal wat bronnen op uw laptop.
Montage op KUK-e
Dus laten we gaan.
Stap 1 - Onze containerafbeelding bouwen
Laten we beginnen met het implementeren van onze "Hello World" op minikube. Dit vereist:
- 1. Docker geïnstalleerd.
- 2. Git geïnstalleerd.
- 3. Maven geïnstalleerd (eigenlijk gebruikt dit project mvnw binary, dus je kunt het zonder doen).
- 4. Eigenlijk is de bron zelf, d.w.z. repository kloon
De eerste stap is het aanmaken van een Quarkus-project. Wees niet bang als je Quarkus.io nog nooit hebt gebruikt - het is eenvoudig. U selecteert gewoon de componenten die u in het project wilt gebruiken (RestEasy, Hibernate, Amazon SQS, Camel, enz.), en vervolgens stelt Quarkus zelf, zonder uw medewerking, het maven-archetype in en zet alles op github. Dat wil zeggen, letterlijk één muisklik - en u bent klaar. Daarom houden we van Quarkus.
De gemakkelijkste manier om onze "Hello World" in een gecontaineriseerde afbeelding te bouwen, is door de quarkus-maven-extensies voor Docker te gebruiken, die al het nodige werk zullen doen. Met de komst van Quarkus is dit heel gemakkelijk en eenvoudig geworden: voeg de container-image-docker-extensie toe en je kunt afbeeldingen maken met maven-commando's.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
En tot slot bouwen we ons imago op met Maven. Hierdoor verandert onze broncode in een kant-en-klare container-image, die al in de container-runtime kan worden uitgevoerd.
./mvnw -X clean package -Dquarkus.container-image.build=true
Dat is in feite alles, nu kunt u de container uitvoeren met de opdracht docker run, nadat u onze service hebt toegewezen aan poort 8080 zodat deze toegankelijk is.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Nadat de containerinstantie is gestart, hoeft u alleen nog maar met de curl-opdracht te controleren of onze service wordt uitgevoerd:
Dus alles werkt, en het was heel gemakkelijk en eenvoudig.
Stap 2 - Dien onze container in bij de opslagplaats voor containerafbeeldingen
Voorlopig wordt de afbeelding die we hebben gemaakt lokaal opgeslagen in onze lokale containeropslag. Als we deze afbeelding in onze KUK-omgeving willen gebruiken, moeten we deze in een andere repository plaatsen. Kubernetes heeft deze features niet, dus gaan we dockerhub gebruiken. Omdat het ten eerste gratis is en ten tweede (bijna) iedereen het doet.
Dit is ook heel eenvoudig en hier is alleen een dockerhub-account nodig.
Dus we installeren dockerhub en sturen onze afbeelding daarheen.
Stap 3 - Start Kubernetes
Er zijn veel manieren om een Kubernetes-configuratie samen te stellen om onze "Hello World" uit te voeren, maar we zullen de eenvoudigste gebruiken, omdat we zulke mensen zijn ...
Eerst starten we het minikube-cluster:
minikube start
Stap 4 - Onze containerafbeelding implementeren
Nu moeten we onze code en containerimage converteren naar Kubernetes-configuratie. Met andere woorden, we hebben een pod en een implementatiedefinitie nodig die verwijzen naar onze containerafbeelding op dockerhub. Een van de gemakkelijkste manieren om dit te doen, is door de opdracht create deployment uit te voeren die naar onze afbeelding wijst:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Met deze opdracht hebben we onze COOK verteld om een implementatieconfiguratie te maken, die de pod-specificatie voor onze containerafbeelding zou moeten bevatten. Met deze opdracht wordt deze configuratie ook toegepast op ons minikube-cluster en wordt een implementatie gemaakt die onze container-image downloadt en een pod op het cluster uitvoert.
Stap 5 - open toegang tot onze service
Nu we een geïmplementeerde containerimage hebben, is het tijd om na te denken over hoe we externe toegang tot deze Restful-service kunnen configureren, die in feite in onze code is geprogrammeerd.
Er zijn hier veel manieren. U kunt bijvoorbeeld de opdracht bloot gebruiken om automatisch de juiste Kubernetes-componenten te maken, zoals services en eindpunten. Dit is eigenlijk wat we zullen doen door de opdracht bloot uit te voeren voor ons implementatieobject:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Laten we even stilstaan bij de "-type"-optie van het bloot-commando.
Wanneer we de componenten blootleggen en maken die nodig zijn om onze service uit te voeren, moeten we onder andere van buitenaf verbinding kunnen maken met de hello-quarkus-service die zich binnen ons door software gedefinieerde netwerk bevindt. En parameters type dan: stelt ons in staat om zaken als load balancers te creëren en te verbinden om verkeer naar dat netwerk te leiden.
Bijvoorbeeld schrijven type=LoadBalancer, initialiseren we automatisch de load balancer van de openbare cloud om verbinding te maken met ons Kubernetes-cluster. Dit is natuurlijk geweldig, maar u moet begrijpen dat een dergelijke configuratie nauw verbonden is met een specifieke openbare cloud en dat het moeilijker zal zijn om deze over te dragen tussen Kubernetes-instanties in verschillende omgevingen.
In ons voorbeeld type=NodePort, dat wil zeggen, de oproep naar onze service gaat via het IP-adres van het knooppunt en het poortnummer. Met deze optie kunt u geen gebruik maken van public clouds, maar zijn er wel een aantal extra stappen nodig. Ten eerste heb je je eigen load balancer nodig, dus zullen we de NGINX load balancer in ons cluster implementeren.
Stap 6 - Stel een load balancer in
minikube heeft een aantal platformfuncties die het gemakkelijk maken om de componenten te maken die u nodig hebt voor externe toegang, zoals ingangscontrollers. Minikube wordt geleverd met de Nginx ingangscontroller en het enige wat we hoeven te doen is het inschakelen en configureren.
minikube addons enable ingress
Nu zullen we met slechts één opdracht een Nginx ingangscontroller maken die binnen ons minikube-cluster zal werken:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Stap 7 - Stel de ingang in
Nu moeten we de Nginx ingangscontroller configureren om hello-quarkus-verzoeken te accepteren.
En tot slot moeten we deze configuratie toepassen.
kubectl apply -f ingress.yml
Omdat we dit allemaal op onze eigen machine doen, voegen we eenvoudig het IP-adres van ons knooppunt toe aan het /etc/hosts-bestand om http-verzoeken naar onze minikube naar de NGINX-loadbalancer te leiden.
192.168.99.100 hello-quarkus.info
Dat is alles, nu is onze minikube-service van buitenaf beschikbaar via de Nginx ingangscontroller.
Nou, dat was makkelijk, toch? Of niet zo veel?
Uitvoeren op OpenShift (Code Ready-containers)
En laten we nu eens kijken hoe het allemaal werkt op het Red Hat OpenShift Container Platform (OCP).
Net als in het geval van minikube kiezen we een schema met een OpenShift-cluster met één knooppunt in de vorm van Code Ready Containers (CRC). Vroeger heette het minishift en was het gebaseerd op het OpenShift Origin-project, maar nu is het CRC en gebouwd op Red Hat's OpenShift Container Platform.
Hier, sorry, we kunnen niet anders dan zeggen: "OpenShift is geweldig!"
Aanvankelijk dachten we te schrijven dat ontwikkeling op OpenShift niet anders is dan ontwikkeling op Kubernetes. En in feite is dat zoals het is. Maar tijdens het schrijven van dit bericht, herinnerden we ons hoeveel onnodige bewegingen je moet maken als je geen OpenShift hebt, en daarom is het wederom prachtig. We houden ervan dat dingen gemakkelijk zijn, en hoe gemakkelijk het is om ons voorbeeld op OpenShift te implementeren en uit te voeren in vergelijking met minikube, is wat ons inspireerde om dit bericht te schrijven.
Laten we het proces doorlopen en kijken wat we moeten doen.
Dus in het minikube-voorbeeld zijn we begonnen met Docker... Wacht, we hoeven Docker niet meer op de machine te installeren.
En we hebben geen lokale git nodig.
En Maven is niet nodig.
En u hoeft niet met de hand een containerimage te maken.
En u hoeft niet te zoeken naar een opslagplaats met containerafbeeldingen.
En u hoeft geen ingangscontroller te installeren.
En u hoeft ook geen toegang te configureren.
Begrijp je dat? Om onze applicatie op OpenShift te implementeren en uit te voeren, is niets van het bovenstaande nodig. En het proces zelf is als volgt.
Stap 1 - Uw OpenShift-cluster starten
We gebruiken Code Ready Containers van Red Hat, wat in wezen dezelfde Minikube is, maar alleen met een volledig single-node Openshift-cluster.
crc start
Stap 2 - Bouw en implementeer de applicatie in het OpenShift-cluster
Het is bij deze stap dat de eenvoud en het gemak van OpenShift zich in al zijn glorie manifesteren. Zoals met alle Kubernetes-distributies, hebben we veel manieren om een applicatie op een cluster uit te voeren. En, zoals in het geval van KUK, kiezen we specifiek voor de eenvoudigste.
OpenShift is altijd gebouwd als een platform voor het bouwen en uitvoeren van gecontaineriseerde applicaties. Het bouwen van containers is altijd een integraal onderdeel van dit platform geweest, dus er zijn een heleboel extra Kubernetes-resources voor de bijbehorende taken.
We gebruiken OpenShift's Source 2 Image (S2I)-proces, dat verschillende manieren heeft om onze broncode (code of binaire bestanden) om te zetten in een gecontaineriseerde afbeelding die draait op een OpenShift-cluster.
Hiervoor hebben we twee dingen nodig:
- Onze broncode in de git-repository
- Builder-image, op basis waarvan de montage zal worden uitgevoerd.
Er zijn veel van dergelijke afbeeldingen, die zowel door Red Hat als door de gemeenschap worden onderhouden, en we zullen de OpenJDK-afbeelding gebruiken, aangezien ik een Java-toepassing aan het bouwen ben.
U kunt een S2I-build zowel vanuit de grafische console van OpenShift Developer als vanaf de opdrachtregel uitvoeren. We zullen de opdracht new-app gebruiken om te vertellen waar de builder-afbeelding en onze broncode kunnen worden opgehaald.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Dat is alles, onze applicatie is gemaakt. Daarbij heeft het S2I-proces de volgende dingen gedaan:
- Een service build-pod gemaakt voor allerlei dingen die te maken hebben met het bouwen van de applicatie.
- Een OpenShift Build-configuratie gemaakt.
- Ik heb de builder-image gedownload naar het interne OpenShift docker-register.
- "Hello World" gekloond naar lokale repository.
- Zag dat er een maven pom in zat en zo de app gecompileerd met maven.
- Een nieuwe containerimage gemaakt met de gecompileerde Java-toepassing en deze image in het interne containerregister geplaatst.
- Een Kubernetes-implementatie gemaakt met specificaties voor een pod, service, enz.
- Gelanceerd containerimage implementeren.
- Service build-pod verwijderd.
Er staat veel op deze lijst, maar het belangrijkste is dat de volledige build exclusief binnen OpenShift plaatsvindt, het interne Docker-register zich binnen OpenShift bevindt en dat het buildproces alle Kubernetes-componenten maakt en op het cluster uitvoert.
Als je de lancering van S2I in de console visueel volgt, kun je zien hoe de build-pod wordt gelanceerd tijdens de build.
En laten we nu eens kijken naar de logboeken van de builder-pod: ten eerste kun je daar zien hoe maven zijn werk doet en afhankelijkheden downloadt om onze java-applicatie te bouwen.
Nadat de maven-build is voltooid, wordt de build van de containerimage gestart en vervolgens wordt deze build-image naar de interne repository gestuurd.
Alles, het montageproces is voltooid. Laten we er nu voor zorgen dat de pods en services van onze applicatie in het cluster zijn gestart.
oc get service
Dat is alles. En er is maar één team. Het enige wat we hoeven te doen is deze dienst bloot te stellen voor toegang van buitenaf.
Stap 3 - maak de service zichtbaar voor toegang van buitenaf
Net als in het geval van KUK heeft onze "Hello World" op het OpenShift-platform ook een router nodig om extern verkeer naar een dienst binnen de cluster te leiden. In OpenShift maakt dit het heel gemakkelijk. Ten eerste wordt de HAProxy-routeringscomponent standaard in het cluster geïnstalleerd (deze kan worden gewijzigd in dezelfde NGINX). Ten tweede zijn er speciale en zeer configureerbare bronnen genaamd Routes, die doen denken aan Ingress-objecten in de goede oude Kubernetes (in feite hebben OpenShift's Routes een grote invloed gehad op het ontwerp van Ingress-objecten, die nu kunnen worden gebruikt in OpenShift), maar voor onze "Hallo World", en in bijna alle andere gevallen is de standaardroute voor ons voldoende zonder extra configuratie.
Om een routeerbare FQDN te maken voor "Hello World" (ja, OpenShiift heeft zijn eigen DNS voor routering op servicenamen), stellen we eenvoudigweg onze service bloot:
oc expose service quarkus-hello-world
Als u naar de nieuw gemaakte route kijkt, kunt u daar de FQDN en andere routeringsinformatie vinden:
oc get route
En tot slot hebben we toegang tot onze service vanuit de browser:
Maar nu was het echt makkelijk!
We houden van Kubernetes en alles wat je met deze technologie kunt doen, en we houden ook van eenvoud en lichtheid. Kubernetes is ontworpen om gedistribueerde, schaalbare containers ongelooflijk eenvoudig te bedienen te maken, maar de eenvoud is niet langer genoeg om applicaties vandaag in productie te brengen. En hier komt OpenShift om de hoek kijken, dat met zijn tijd meegaat en Kubernetes aanbiedt, vooral gericht op de ontwikkelaar. Er is veel moeite gestoken om het OpenShift-platform specifiek voor de ontwikkelaar aan te passen, inclusief het creëren van tools zoals S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-integratie, Developer Catalogs, Helm-integratie, monitoring en vele andere.
We hopen dat dit artikel interessant en nuttig voor je was. En u kunt aanvullende bronnen, materialen en andere dingen vinden die nuttig zijn voor het ontwikkelen op het OpenShift-platform op de portal .
Bron: www.habr.com