Det här inlägget skrevs för att vår personal hade en hel del samtal med kunder om att utveckla applikationer på Kubernetes och detaljerna kring sådan utveckling på OpenShift.
Vi brukar börja med tesen att Kubernetes bara är Kubernetes, och OpenShift är redan en Kubernetes-plattform, som Microsoft AKS eller Amazon EKS. Var och en av dessa plattformar har sina egna fördelar, fokuserade på en viss målgrupp. Och efter det flyter samtalet redan in i en jämförelse av styrkor och svagheter hos specifika plattformar.
I allmänhet tänkte vi skriva det här inlägget med en utgång som "Lyssna, det spelar ingen roll var du kör koden, på OpenShift eller på AKS, på EKS, på några anpassade Kubernetes, ja på alla Kubernetes (låt oss kalla det KUK för kort) "Det är väldigt enkelt, både där och där."
Sedan planerade vi att ta den enklaste "Hello World" och använda den för att visa vad som är vanligt och vad som är skillnaderna mellan CMC och Red Hat OpenShift Container Platform (nedan OCP eller helt enkelt OpenShift).
Men under loppet av att skriva det här inlägget insåg vi att vi har blivit så vana vid att använda OpenShift att vi helt enkelt inte inser hur det har växt och förvandlats till en fantastisk plattform som har blivit mycket mer än bara en Kubernetes-distribution. Vi tenderar att ta OpenShifts mognad och enkelhet för given, samtidigt som vi förbiser dess storslagenhet.
I allmänhet är det dags för aktiv omvändelse, och nu kommer vi steg för steg att jämföra driftsättningen av vår "Hello World" på KUK och på OpenShift, och vi kommer att göra det så objektivt som möjligt (ja, förutom att ibland visa en personlig inställning till ämnet). Om du är intresserad av en rent subjektiv åsikt i denna fråga kan du läsa den . Och i detta inlägg kommer vi att hålla oss till fakta och bara fakta.
Kluster
Så vår "Hello World" behöver kluster. Låt oss bara säga "nej" till alla offentliga moln, för att inte betala för servrar, register, nätverk, dataöverföring, etc. Följaktligen väljer vi ett enkelt en-nodskluster på (för KUK) och (för ett OpenShift-kluster). Båda dessa alternativ är verkligen enkla att installera, men kräver ganska mycket resurser på din bärbara dator.
Montering på KUK-e
Låt oss gå.
Steg 1 - Bygg vår containerbild
Låt oss börja med att distribuera vår "Hello World" till minikube. Detta kommer att kräva:
- 1. Installerad Docker.
- 2. Installerade Git.
- 3. Installerade Maven (egentligen använder det här projektet mvnw binär, så du kan klara dig utan det).
- 4. Egentligen är själva källan, dvs. förvarsklon
Det första steget är att skapa ett Quarkus-projekt. Var inte rädd om du aldrig har använt Quarkus.io – det är enkelt. Du väljer bara de komponenter du vill använda i projektet (RestEasy, Hibernate, Amazon SQS, Camel, etc.), och sedan ställer Quarkus själv, utan något av ditt deltagande, upp maven-arketypen och lägger allt på github. Det vill säga, bokstavligen ett klick med musen - och du är klar. Det är därför vi älskar Quarkus.
Det enklaste sättet att bygga vår "Hello World" till en containeriserad bild är att använda quarkus-maven-tilläggen för Docker, som kommer att göra allt nödvändigt arbete. Med tillkomsten av Quarkus har detta blivit riktigt enkelt och enkelt: lägg till tillägget container-image-docker och du kan skapa bilder med maven-kommandon.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Och slutligen bygger vi vår bild med Maven. Som ett resultat förvandlas vår källkod till en färdig containerbild, som redan kan köras i containerkörningstiden.
./mvnw -X clean package -Dquarkus.container-image.build=true
Det är faktiskt allt, nu kan du köra behållaren med kommandot docker run, efter att ha mappat vår tjänst till port 8080 så att den kan nås.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Efter att containerinstansen har startat är allt som återstår att kontrollera med curl-kommandot att vår tjänst körs:
Så allt fungerar, och det var väldigt enkelt och enkelt.
Steg 2 - Skicka in vår behållare till behållarens bildarkiv
För närvarande lagras bilden vi skapade lokalt i vår lokala containerlagring. Om vi vill använda den här bilden i vår KUK-miljö måste vi lägga den i något annat arkiv. Kubernetes har inte dessa funktioner, så vi kommer att använda dockerhub. För för det första är det gratis, och för det andra gör (nästan) alla det.
Detta är också väldigt enkelt, och här behövs bara ett dockerhub-konto.
Så vi installerar dockerhub och skickar vår bild dit.
Steg 3 - Starta Kubernetes
Det finns många sätt att sätta ihop en kubernetes-konfiguration för att köra vår "Hello World", men vi kommer att använda det enklaste av dem, eftersom vi är sådana människor ...
Först startar vi minikube-klustret:
minikube start
Steg 4 - Implementera vår containerbild
Nu måste vi konvertera vår kod och behållarbild till kubernetes-konfiguration. Med andra ord behöver vi en pod och en distributionsdefinition som pekar på vår containerbild på dockerhub. Ett av de enklaste sätten att göra detta är att köra kommandot create deployment som pekar på vår bild:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Med det här kommandot sa vi till vår COOK att skapa en distributionskonfiguration som ska innehålla pod-specifikationen för vår containerbild. Det här kommandot kommer också att tillämpa den här konfigurationen på vårt minikube-kluster och skapa en distribution som laddar ner vår containeravbildning och kör en pod på klustret.
Steg 5 - öppen tillgång till vår tjänst
Nu när vi har en distribuerad containeravbildning är det dags att tänka på hur man konfigurerar extern åtkomst till denna Restful-tjänst, som faktiskt är programmerad i vår kod.
Det finns många sätt här. Du kan till exempel använda kommandot expose för att automatiskt skapa lämpliga Kubernetes-komponenter som tjänster och slutpunkter. Det här är faktiskt vad vi kommer att göra genom att köra exponeringskommandot för vårt distributionsobjekt:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Låt oss uppehålla oss vid alternativet "-typ" för exponeringskommandot ett ögonblick.
När vi exponerar och skapar de komponenter som behövs för att driva vår tjänst behöver vi bland annat kunna koppla upp oss utifrån till hello-quarkus-tjänsten som sitter inne i vårt mjukvarudefinierade nätverk. Och parameter Typ tillåter oss att skapa och ansluta saker som lastbalanserare för att dirigera trafik till det nätverket.
Till exempel att skriva type=LoadBalancerinitierar vi automatiskt den offentliga molnbelastningsbalansen för att ansluta till vårt Kubernetes-kluster. Detta är naturligtvis bra, men du måste förstå att en sådan konfiguration kommer att vara tätt knuten till ett specifikt offentligt moln och det kommer att bli svårare att överföra det mellan Kubernetes-instanser i olika miljöer.
I vårt exempel typ=NodePort, det vill säga samtalet till vår tjänst går via nodens IP-adress och portnumret. Det här alternativet låter dig inte använda några offentliga moln, men kräver ett antal ytterligare steg. Först behöver du din egen lastbalanserare, så vi kommer att distribuera NGINX lastbalanserare i vårt kluster.
Steg 6 - Konfigurera en lastbalanserare
minikube har ett antal plattformsfunktioner som gör det enkelt att skapa de komponenter du behöver för extern åtkomst, såsom ingångskontroller. Minikube levereras med Nginx ingångskontrollern, och allt vi behöver göra är att aktivera den och konfigurera den.
minikube addons enable ingress
Nu, med bara ett kommando, kommer vi att skapa en Nginx ingresskontroller som kommer att fungera i vårt minikube-kluster:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Steg 7 - Ställ in ingången
Nu måste vi konfigurera Nginx ingresskontrollern för att acceptera hello-quarkus-förfrågningar.
Och slutligen måste vi tillämpa denna konfiguration.
kubectl apply -f ingress.yml
Eftersom vi gör allt detta på vår egen maskin lägger vi helt enkelt till vår nods IP-adress till filen /etc/hosts för att dirigera http-förfrågningar till vår minikube till NGINX-lastbalanseraren.
192.168.99.100 hello-quarkus.info
Det var allt, nu är vår minikube-tjänst tillgänglig från utsidan genom Nginx ingresskontroller.
Tja, det var lätt, eller hur? Eller inte så mycket?
Kör på OpenShift (Code Ready Containers)
Och nu ska vi se hur allt görs på Red Hat OpenShift Container Platform (OCP).
Som i fallet med minikube väljer vi ett schema med ett OpenShift-kluster med en nod i form av Code Ready Containers (CRC). Tidigare kallades det minishift och var baserat på OpenShift Origin-projektet, men nu är det CRC och byggt på Red Hats OpenShift Container Platform.
Här, förlåt, vi kan inte låta bli att säga: "OpenShift är fantastiskt!"
Till en början tänkte vi skriva att utveckling på OpenShift inte skiljer sig från utveckling på Kubernetes. Och faktiskt är det så det är. Men när vi skrev det här inlägget kom vi ihåg hur många onödiga rörelser du måste göra när du inte har OpenShift, och därför är det, återigen, vackert. Vi älskar att saker är lätta, och hur lätt det är att distribuera och köra vårt exempel på OpenShift jämfört med minikube är det som inspirerade oss att skriva det här inlägget.
Låt oss gå igenom processen och se vad vi behöver göra.
Så i minikube-exemplet började vi med Docker... Vänta, vi behöver inte Docker installerat på maskinen längre.
Och vi behöver ingen lokal git.
Och Maven behövs inte.
Och du behöver inte skapa en containerbild för hand.
Och du behöver inte leta efter något arkiv med behållarbilder.
Och du behöver inte installera en ingångskontroll.
Och du behöver inte heller konfigurera ingress.
Förstår du? För att distribuera och köra vår applikation på OpenShift behövs inget av ovanstående. Och själva processen är som följer.
Steg 1 – Starta ditt OpenShift-kluster
Vi använder Code Ready Containers från Red Hat, som i huvudsak är samma Minikube, men bara med ett fullt ennods Openshift-kluster.
crc start
Steg 2 - Bygg och distribuera programmet till OpenShift-klustret
Det är i detta steg som enkelheten och bekvämligheten med OpenShift manifesterar sig i all ära. Som med alla Kubernetes-distributioner har vi många sätt att köra en applikation på ett kluster. Och, som i fallet med KUK, väljer vi specifikt den enklaste.
OpenShift har alltid byggts som en plattform för att bygga och köra containeriserade applikationer. Att bygga containrar har alltid varit en integrerad del av den här plattformen, så det finns ett gäng ytterligare Kubernetes-resurser för motsvarande uppgifter.
Vi kommer att använda OpenShifts Source 2 Image (S2I) process, som har flera olika sätt att ta vår källkod (kod eller binärer) och förvandla den till en containeriserad bild som körs på ett OpenShift-kluster.
För detta behöver vi två saker:
- Vår källkod i git-förvaret
- Builder-bild, baserad på vilken monteringen kommer att utföras.
Det finns många sådana bilder, underhållna både av Red Hat och av communityn, och vi kommer att använda OpenJDK-bilden, ja, eftersom jag bygger en Java-applikation.
Du kan köra en S2I-build både från OpenShift Developers grafiska konsol och från kommandoraden. Vi kommer att använda kommandot new-app och tala om för den var man ska hämta byggarbilden och vår källkod.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Det är allt, vår applikation är skapad. Genom att göra det gjorde S2I-processen följande saker:
- Skapade en servicebuild-pod för alla möjliga saker relaterade till att bygga applikationen.
- Skapat en OpenShift Build-konfiguration.
- Jag laddade ner byggarbilden till det interna OpenShift docker-registret.
- Klonad "Hello World" till lokalt arkiv.
- Såg att det fanns en maven pom där och så kompilerade appen med maven.
- Skapat en ny behållaravbildning som innehåller den kompilerade Java-applikationen och placerade denna avbildning i det interna behållarregistret.
- Skapat en Kubernetes-distribution med specifikationer för en pod, tjänst osv.
- Lanserade distributionscontaineravbildning.
- Tog bort service build-pod.
Det finns mycket på den här listan, men huvudsaken är att hela bygget sker uteslutande i OpenShift, det interna Docker-registret finns i OpenShift, och byggprocessen skapar alla Kubernetes-komponenter och kör dem på klustret.
Om du visuellt övervakar lanseringen av S2I i konsolen kan du se hur byggpodden startas under bygget.
Och låt oss nu ta en titt på byggarpoddens loggar: för det första kan du se hur Maven gör sitt jobb och laddar ner beroenden för att bygga vår java-applikation.
Efter att maven-bygget är klart startas byggandet av behållaravbildningen, och sedan skickas den byggda bilden till det interna förvaret.
Allt, monteringsprocessen är klar. Låt oss nu se till att poddarna och tjänsterna för vår applikation har startat i klustret.
oc get service
Det är allt. Och det finns bara ett lag. Allt vi behöver göra är att exponera den här tjänsten för extern åtkomst.
Steg 3 - gör tjänsten exponerad för åtkomst utifrån
Som i fallet med KUK, på OpenShift-plattformen, behöver vår "Hello World" också en router för att dirigera extern trafik till en tjänst i klustret. I OpenShift gör detta det väldigt enkelt. För det första är HAProxy-routingkomponenten installerad i klustret som standard (den kan ändras till samma NGINX). För det andra finns det speciella och mycket konfigurerbara resurser som kallas Routes, som påminner om Ingress-objekt i gamla goda Kubernetes (i själva verket påverkade OpenShifts Routes kraftigt designen av Ingress-objekt, som nu kan användas i OpenShift), men för vår "Hej World", och i nästan alla andra fall räcker standardrutten för oss utan ytterligare konfiguration.
För att skapa en routbar FQDN för "Hello World" (ja, OpenShiift har sin egen DNS för routing efter tjänstnamn), exponerar vi helt enkelt vår tjänst:
oc expose service quarkus-hello-world
Om du tittar på den nyskapade rutten kan du hitta FQDN och annan ruttinformation där:
oc get route
Och slutligen får vi tillgång till vår tjänst från webbläsaren:
Men nu var det verkligen lätt!
Vi älskar Kubernetes och allt som den här tekniken låter dig göra, och vi älskar också enkelhet och lätthet. Kubernetes designades för att göra distribuerade, skalbara behållare otroligt lätta att använda, men dess enkelhet räcker inte längre för att få applikationer i produktion idag. Det är här OpenShift kommer in i bilden, hänger med i tiden och erbjuder utvecklarcentrerade Kubernetes. Mycket arbete har investerats för att skräddarsy OpenShift-plattformen specifikt för utvecklaren, inklusive skapandet av verktyg som S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-integration, Developer Catalogs, Helm-integration, övervakning och många andra.
Vi hoppas att den här artikeln var intressant och användbar för dig. Och du kan hitta ytterligare resurser, material och annat användbart för utveckling på OpenShift-plattformen på portalen .
Källa: will.com