Förlåt, OpenShift, vi värderade dig inte tillräckligt och tog dig för given.

Detta inlägg är skrivet eftersom våra medarbetare har haft många samtal med kunder om applikationsutveckling på Kubernetes och om specifika aspekter av sådan utveckling på OpenShift.

Vi börjar vanligtvis med tesen att Kubernetes är bara Kubernetes, medan OpenShift är en Kubernetes-plattform, likt Microsoft AKS eller Amazon EKS. Varje plattform har sina egna fördelar som är riktade mot olika målgrupper. Efter det övergår samtalet ofta till att jämföra styrkor och svagheter hos specifika plattformar.

Vi tänkte faktiskt skriva detta inlägg med slutsatsen "Lyssna, det spelar ingen roll var du kör din kod, på OpenShift eller AKS, EKS, på någon anpassad Kubernetes, ja vilket som helst-Kubernetes (för kort kallar vi det KUK) – det är verkligen bara enkelt, både här och där."

Sedan planerade vi att ta ett enkelt "Hello World" och visa, med hjälp av det exemplet, vad som är gemensamt och vad som skiljer KUK från Red Hat OpenShift Container Platform (nedan kallad OCP eller bara OpenShift).

Men medan vi skrev detta inlägg insåg vi att vi har blivit så vana vid att använda OpenShift att vi inte ens inser hur mycket det har vuxit och förvandlats till en fantastisk plattform som är mycket mer än bara en Kubernetes-distribution. Vi har kommit att ta OpenShifts mognad och enkelhet för givet, och missat dess storhet.

I allmänhet är det dags för aktiv ånger, och nu kommer vi steg för steg att jämföra implementeringen av vårt "Hello World" på KUK och OpenShift, och göra det så objektivt som möjligt (även om vi ibland uttrycker vår personliga åsikt om ämnet). Om du är intresserad av en rent subjektiv åsikt om detta ämne, kan du läsa den här (EN). I detta inlägg kommer vi att hålla oss till fakta och endast fakta.

Kluster

Så, för vårt "Hello World" behöver vi kluster. Låt oss genast säga "nej" till alla offentliga moln för att slippa betala för servrar, register, nätverk, dataöverföring osv. Därför väljer vi ett enkelt enkelnods-kluster på Minikube (för KUK) och Code Ready Containers (för OpenShift-klustret). Båda dessa alternativ är verkligen enkla att installera, men de kommer att kräva ganska mycket resurser på din laptop.

Byggning på KUK

Så, låt oss köra igång.

Steg 1 – vi bygger vår containerbild

Jag börjar med att deploya vårt "Hello World" på minikube. För detta behöver vi:

1. 1. Installerad Docker.
2. 2. Installerad Git.
3. 3. Installerad Maven (faktiskt används mvnw-binärfilen i detta projekt, så det går bra utan det).
4. 4. Själva källan, det vill säga klonen av förrådet github.com/gcolman/quarkus-hello-world.git

Först måste vi skapa ett Quarkus-projekt. Oroa dig inte om du aldrig har arbetat med sidan Quarkus.io – det är enkelt. Välj bara de komponenter du vill använda i projektet (RestEasy, Hibernate, Amazon SQS, Camel etc.), och Quarkus konfigurerar automatiskt Maven-archetypen och lägger allt på GitHub. Det vill säga, bokstavligen ett musklick – och klart. Det är därför vi älskar Quarkus.

Det enklaste sättet att bygga vår "Hello World" i en containerbild är att använda quarkus-maven-tillägget för Docker, som utför allt nödvändigt arbete. Med Quarkus har det blivit riktigt 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, kör vi bygget av vår bild med hjälp av Maven. Resultatet blir att vår källkod omvandlas till en färdig containerbild, som vi redan kan köra i en container exekveringsmiljö.

./mvnw -X clean package -Dquarkus.container-image.build=true

Och så är det klart, nu kan vi köra containern med kommandot docker run, och mappa vår tjänst till port 8080 så att vi kan nå den.

docker run -i --rm -p 8080:8080 gcolman/quarkus-hello-world

När containerinstansen har startat, behöver vi bara kontrollera med kommandot curl att vår tjänst fungerar:

Så, allt fungerar, och det var faktiskt riktigt enkelt.

Steg 2 – skicka vår container till en containerbildrepo

Hit tills lagras den bild vi skapade lokalt i vårt lokala containerlager. Om vi vill använda denna bild i vår K8s-miljö, behöver vi lägga den i ett annat förråd. Kubernetes har inte sådana funktioner, så vi kommer att använda dockerhub. För det första är det gratis, och för det andra gör (nästan) alla så.

Det är också mycket enkelt, och det krävs bara ett konto på dockerhub.

Så, vi skapar ett konto på dockerhub och skickar dit vår bild.

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 sättet, så vi är.

Först kör vi minikube-klustret:

minikube start

Steg 4 – vi distribuerar vår containeravbildning

Nu måste vi omvandla vår kod och containeravbildning till Kubernetes-konfigurationer. Med andra ord, vi behöver en pod- och deploymentsdefinition som pekar på vår containeravbildning på Docker Hub. Ett av de enklaste sätten att göra detta är att köra kommandot create deployment och ange vår avbildning:

kubectl create deployment hello-quarkus --image=gcolman/quarkus-hello-world:1.0.0-SNAPSHOT

Genom detta kommando bad vi vår KUB att skapa en deploymentskonfiguration, som ska innehålla specifikationen för en pod för vår containeravbildning. Detta kommando kommer också att tillämpa denna konfiguration på vår minikube-kluster och skapa en deployment som laddar ner vår containeravbildning och startar en pod i klustret.

Steg 5 – vi öppnar tillgång till vår tjänst

Nu när vi har distribuerat vår containeravbildning är det dags att tänka på hur vi konfigurerar extern åtkomst till denna Restful-tjänst, som faktiskt programmerades i vår kod.

Det finns många sätt att göra detta. Till exempel kan vi använda kommandot expose för att automatiskt skapa motsvarande Kubernetes-komponenter, såsom services och endpoints. Det är precis vad vi kommer att göra genom att köra expose-kommandot för vår deploymentsobjekt:

kubectl expose deployment hello-quarkus --type=NodePort --port=8080

Låt oss stanna upp en minut vid alternativet "--type" i expose-kommandot.

När vi gör expose och skapar komponenterna som behövs för att köra vår tjänst, behöver vi bland annat att kunna ansluta till tjänsten hello-quarkus, som sitter inuti vårt programvarudefinierade nätverk. Och parametern typ låter oss skapa och koppla sådana saker som belastningsbalanserare för att dirigera trafik till detta nätverk.

Till exempel, genom att skriva --type=LoadBalancer, initierar vi automatiskt en belastningsbalanserare i den offentliga molnmiljön för att kunna ansluta till vårt Kubernetes-kluster. Detta är naturligtvis fantastiskt, men man måste förstå att en sådan konfiguration kommer att vara strikt kopplad till ett specifikt offentligt moln och det blir svårare att flytta mellan Kubernetes-instanser i olika miljöer.

I vårt exempel --type=NodePort, det vill säga att åtkomsten till vår tjänst sker via nodens IP-adress och portnummer. Denna lösning kräver inga offentliga moln, men innebär ett antal ytterligare steg. För det första behövs en egen lastbalanserare, så vi kommer att sätta upp en lastbalanserare NGINX i vårt kluster.

Steg 6 – installera lastbalanseraren

Minikube har ett antal plattformsfunktioner som underlättar skapandet av nödvändiga komponenter för extern åtkomst, såsom ingress-kontroller. Minikube levereras med ingress-kontrollern Nginx, och vi behöver bara aktivera och konfigurera den.

minikube addons enable ingress

Nu skapar vi med ett enda kommando ingress-kontrollern Nginx, som kommer att arbeta inuti vårt minikube-kluster:

ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m

Steg 7 – Konfigurera ingress

Nu måste vi konfigurera ingress-kontrollern Nginx för att den ska kunna ta emot förfrågningar från hello-quarkus.

Och till sist, vi behöver tillämpa denna konfiguration.

kubectl apply -f ingress.yml

Eftersom vi gör allt detta på vår dator, lägger vi bara till IP-adressen till vår nod i filen /etc/hosts för att dirigera http-förfrågningar till vår minikube via lastbalanseraren NGINX.

192.168.99.100 hello-quarkus.info

Det är klart, nu är vår minikube-tjänst tillgänglig utanför via ingress-kontrollern Nginx.

Tja, var det inte enkelt? Eller kanske inte så mycket?

Körning på OpenShift (Code Ready Containers)

Och nu ska vi se hur allt görs på Red Hat OpenShift Container Platform (OCP).

Som i minikube-fallet väljer vi en en-nods OpenShift-klusterlösning i form av Code Ready Containers (CRC). Tidigare kallades detta minishift och baserades på OpenShift Origin-projektet, men nu är det CRC och bygger på Red Hats OpenShift Container Platform.

Här kan vi inte låta bli att säga: "OpenShift är fantastiskt!"

Vi tänkte från början skriva att utvecklingen på OpenShift inte skiljer sig från utvecklingen på Kubernetes. Och i grunden är det sant. Men under skrivandet av detta inlägg kom vi ihåg hur många extra steg man måste ta utan OpenShift, och därför är det, som sagt, fantastiskt. Vi älskar när allt görs enkelt, och hur mycket enklare vårt exempel distribueras och körs på OpenShift jämfört med minikube var helt enkelt vad som motiverade oss att skriva detta inlägg.

Låt oss gå igenom processen och se vad vi behöver göra.

Så i exemplet med minikube började vi med Docker... Vänta, vi behöver inte längre ha Docker installerat på maskinen.

Och lokal git behövs inte.
Och Maven behövs inte.
Och det behövs inte att manuellt skapa en containerbild.
Och det behövs inte att leta efter något containerbildsrepo.
Och det behövs inte att installera en ingress-controller.
Och det behövs inte att konfigurera ingress heller.

Förstår du? För att driftsätta och köra vår applikation på OpenShift behöver vi inte något av det ovanstående. Och själva processen ser ut på följande sätt.

Steg 1 – Starta din OpenShift-kluster.

Vi använder Code Ready Containers från Red Hat, som i princip är samma som Minikube, men med en fullt fungerande en-nod-klyngstruktur för Openshift.

crc start

Steg 2 – Bygg och driftsätt applikationen i OpenShift-klustret.

Just här visa OpenShifts enkelhet och användarvänlighet sig i sin fulla prakt. Som i alla Kubernetes-distributioner har vi många sätt att starta en applikation i klustret. Och precis som i fallet med K8s väljer vi medvetet det allra enklaste alternativet.

OpenShift har alltid byggts som en plattform för att skapa och köra containerapplikationer. Byggandet av containrar har alltid varit en integrerad del av denna plattform, så här finns det massor av ytterligare Kubernetes-resurser för relevanta uppgifter.

Vi kommer att använda OpenShifts Source 2 Image (S2I)-process, som har flera olika sätt att ta vår källa (kod eller binärfiler) och omvandla den till en containerbild som körs i OpenShift-klustret.

För detta behöver vi två saker:

• Vår källkod i en git-repo
• Builder-bild som byggprocessen kommer att baseras på.

Det finns många sådana bilder, både stödjade av Red Hat och på samhällsnivå, och vi kommer att använda bilden OpenJDK, eftersom jag bygger en Java-applikation.

S2I-byggandet kan startas både från OpenShift Developer-grafikkonsolen och från kommandoraden. Vi kommer att använda kommandot new-app, där vi anger var vi ska hämta builder-bilden 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 klart, vår applikation är skapad. Dessutom genomförde S2I-processen följande saker:

• Skapade en service-build-pod för olika bygg-relaterade saker.
• Skapade en OpenShift Build-konfiguration.
• Laddade ner builder-bilden till OpenShifts interna docker-register.
• Klonade 'Hello World' till det lokala registret.
• Jag såg att det fanns en maven pom, så jag kompilerade applikationen med hjälp av maven.
• Jag skapade en ny containerbild som innehåller den kompilera Java-applikationen och lade denna bild i det interna containerregistret.
• Jag skapade en Kubernetes-deployment med specifikationer för pod, tjänst, etc.
• Jag startade deployment av containerbilden.
• Jag tog bort den temporära build-poden.

Det finns mycket här, men det viktigaste är att hela byggprocessen sker helt inom OpenShift, det interna Docker-registret ligger inom OpenShift, och byggprocessen skapar alla Kubernetes-komponenter och startar dem i klustret.

Om man visuellt övervakar starten av S2I i konsolen kan man se hur build-poden startar när byggprocessen körs.

Och nu låt oss titta på loggarna för builder-poden: först och främst kan man se hur maven gör sitt arbete och laddar ner beroenden för att bygga vår java-applikation.

Efter att maven-bygget har avslutats startas byggandet av containerbilden och den färdiga bilden skickas till det interna arkivet.

Processen för byggandet är klar. Nu ska vi se till att poddar och tjänster för vår applikation har startat i klustret.

oc get service

Och det är allt. Och bara en kommandorad. Nu har vi bara att exponera denna tjänst för åtkomst utifrån.

Steg 3 – exponerar tjänsten för åtkomst utifrån

Precis som med KUK, behöver vår "Hello World"-applikation också en router på OpenShift för att styra extern trafik till tjänsten inom klustret. OpenShift gör detta mycket enkelt. För det första, i klustret finns en HAProxy-routingkomponent installerad som standard (den kan bytas ut mot NGINX). För det andra finns det speciella resurser som tillåter omfattande konfiguration, som kallas Routes och liknar Ingress-objekt i den gamla goda Kubernetes (faktiskt har OpenShifts Routes starkt påverkat designen av Ingress-objekt som nu också kan användas i OpenShift), men för vår "Hello World" och de flesta andra fallen räcker det med standard Route utan ytterligare konfiguration.

För att skapa en routad FQDN för "Hello World" (ja, OpenShift har sin egen DNS för routing via servicenamn) kör vi helt enkelt expose för vår tjänst:

oc expose service quarkus-hello-world

Om vi kollar den just skapade Route kan vi hitta FQDN och annan information om routing:

oc get route

Och till sist, vi går till vår tjänst via webbläsaren:

Och nu var det verkligen enkelt!

Vi älskar Kubernetes och allt som denna teknik möjliggör, liksom vi älskar enkelhet och smidighet. Kubernetes skapades för att drastiskt förenkla driften av distribuerade skalbara behållare, men för att införa applikationer är denna enkelhet idag inte tillräcklig. Här kommer OpenShift in i bilden, som håller jämna steg med tiden och erbjuder Kubernetes som främst riktar sig till utvecklare. Mycket arbete har lagts ner för att skräddarsy OpenShift-plattformen specifikt för utvecklare, inklusive skapandet av verktyg som S2I, ODI, Developer Portal, OpenShift Operator Framework, integration med IDE, Developer Catalogues, integration med Helm, övervakning och många andra.

Vi hoppas att denna artikel har varit intressant och användbar för dig. Du kan hitta ytterligare resurser, material och andra användbara saker för utveckling på OpenShift-plattformen på portalen Red Hat Developers.

Källa: habr.com