Dette indlæg blev skrevet, fordi vores medarbejdere havde en del samtaler med kunder om applikationsudvikling på Kubernetes og de særlige forhold ved sådan udvikling på OpenShift.
Vi starter normalt med tesen om, at Kubernetes bare er Kubernetes, og OpenShift er allerede en Kubernetes-platform, som Microsoft AKS eller Amazon EKS. Hver af disse platforme har sine egne fordele, rettet mod en bestemt målgruppe. Og herefter går samtalen over på at sammenligne styrker og svagheder ved specifikke platforme.
Generelt tænkte vi på at skrive dette indlæg med en konklusion som "Hør, det er lige meget, hvor koden skal køres, på OpenShift eller på AKS, på EKS, på nogle brugerdefinerede Kubernetes eller på hvad Kubernetes nu (for kortheds skyld, lad os kalde det KUK) "Det er virkelig enkelt, både der og der."
Så planlagde vi at tage den enkleste "Hello World" og bruge dens eksempel til at vise, hvad der er fælles, og hvad der er forskellen mellem KUC og Red Hat OpenShift Container Platform (herefter OCP eller blot OpenShift).
Men da vi skrev dette indlæg, indså vi, at vi havde været så vant til at bruge OpenShift i så lang tid, at vi simpelthen ikke var klar over, hvordan det var vokset og blev til en fantastisk platform, der blev meget mere end blot en Kubernetes-distribution. Vi har en tendens til at tage OpenShifts modenhed og enkelhed for givet, og vi mister dets glans af syne.
Generelt er tiden kommet til aktiv omvendelse, og nu vil vi trin for trin sammenligne idriftsættelsen af vores "Hello World" på KUK og på OpenShift, og vi vil gøre dette så objektivt som muligt (godt, undtagen ved nogle gange at vise en personlig holdning til emnet). Hvis du er interesseret i en rent subjektiv mening om dette spørgsmål, så kan du læse den . Og i dette indlæg vil vi holde os til fakta og kun fakta.
Klynger
Så vores "Hello World" kræver klynger. Vi siger straks "nej" til offentlige skyer for ikke at betale for servere, registre, netværk, dataoverførsel osv. Derfor vælger vi en simpel enkelt-node klynge på (for KUK) og (til OpenShift-klynge). Begge disse muligheder er virkelig nemme at installere, men vil kræve ret mange ressourcer på din bærbare computer.
Montering på KUK-e
Så lad os gå.
Trin 1 – opbygning af vores containerbillede
Lad os starte med at implementere vores "Hello World" til minikube. For at gøre dette skal du bruge:
- 1. Docker installeret.
- 2. Git installeret.
- 3. Installeret Maven (faktisk bruger dette projekt mvnw binær, så du kan undvære det).
- 4. Egentlig er kilden selv, dvs. repository klon
Det første skridt er at skabe et Quarkus-projekt. Bliv ikke forskrækket, hvis du aldrig har arbejdet med Quarkus.io – det er nemt. Du vælger bare de komponenter, du vil bruge i projektet (RestEasy, Hibernate, Amazon SQS, Camel osv.), og så konfigurerer Quarkus selv, uden din deltagelse, maven-arketypen og sætter alt på github. Det vil sige, bogstaveligt talt et klik med musen, og du er færdig. Det er derfor, vi elsker Quarkus.
Den nemmeste måde at bygge vores "Hello World" ind i et containerbillede er at bruge quarkus-maven-udvidelserne til Docker, som vil udføre alt det nødvendige arbejde. Med fremkomsten af Quarkus er dette blevet virkelig nemt og enkelt: Tilføj container-image-docker-udvidelsen, og du kan oprette billeder ved hjælp af maven-kommandoer.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Til sidst bygger vi vores image ved hjælp af Maven. Som et resultat bliver vores kildekode til et færdiglavet containerbillede, der allerede kan køres i container runtime-miljøet.
./mvnw -X clean package -Dquarkus.container-image.build=true
Det er alt, nu kan du starte containeren med kommandoen docker run, og kortlægge vores service til port 8080, så den kan tilgås.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Efter containerforekomsten er startet, er der kun tilbage at kontrollere med curl-kommandoen, at vores service kører:
Så alt fungerer, og det var virkelig nemt og enkelt.
Trin 2 – send vores container til containerbilledet
Indtil videre er det billede, vi oprettede, gemt lokalt i vores lokale containerlager. Hvis vi vil bruge dette billede i vores COOK-miljø, skal det placeres i et andet depot. Kubernetes har ikke sådanne funktioner, så vi vil bruge dockerhub. For for det første er det gratis, og for det andet gør (næsten) alle det.
Dette er også meget enkelt, og alt hvad du behøver er en dockerhub-konto.
Så vi installerer dockerhub og sender vores billede dertil.
Trin 3 – start Kubernetes
Der er mange måder at samle kubernetes-konfigurationen til at køre vores "Hello World", men vi vil bruge den enkleste af dem, det er sådan vi er...
Lad os først starte minikube-klyngen:
minikube start
Trin 4 – implementer vores containerbillede
Nu skal vi konvertere vores kode og containerbillede til kubernetes-konfigurationer. Med andre ord har vi brug for en pod og en implementeringsdefinition, der peger på vores containerbillede på dockerhub. En af de nemmeste måder at gøre dette på er at køre kommandoen create deployment, der peger på vores image:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Med denne kommando bad vi vores COO om at oprette en implementeringskonfiguration, som skulle indeholde pod-specifikationen for vores containerbillede. Denne kommando vil også anvende denne konfiguration på vores minikube-klynge og oprette en implementering, der vil downloade vores containerbillede og starte poden i klyngen.
Trin 5 – åben adgang til vores service
Nu hvor vi har et installeret containerbillede, er det tid til at tænke over, hvordan man konfigurerer ekstern adgang til denne Restful-tjeneste, som faktisk er programmeret i vores kode.
Der er mange måder her. For eksempel kan du bruge eksponerkommandoen til automatisk at oprette de relevante Kubernetes-komponenter, såsom tjenester og slutpunkter. Faktisk er dette, hvad vi vil gøre ved at udføre ekspose-kommandoen for vores implementeringsobjekt:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Lad os tage et øjeblik på at se på "-type"-indstillingen for eksponerkommandoen.
Når vi eksponerer og laver de komponenter, der er nødvendige for at køre vores service, skal vi blandt andet kunne forbinde udefra til hello-quarkus servicen, som sidder inde i vores softwaredefinerede netværk. Og parameter typen giver os mulighed for at oprette og forbinde ting som load balancere for at dirigere trafik til dette netværk.
For eksempel ved at skrive type=LoadBalancer, sørger vi automatisk for en belastningsbalancer i den offentlige sky for at oprette forbindelse til vores Kubernetes-klynge. Dette er selvfølgelig fantastisk, men du skal forstå, at en sådan konfiguration vil være strengt bundet til en specifik offentlig sky og vil være sværere at overføre mellem Kubernetes-instanser i forskellige miljøer.
I vores eksempel type=NodePort, det vil sige, at vores service tilgås af nodens IP-adresse og portnummer. Denne mulighed giver dig mulighed for ikke at bruge nogen offentlige skyer, men kræver en række yderligere trin. For det første har du brug for din egen load balancer, så vi vil implementere NGINX load balancer i vores klynge.
Trin 6 – installer en belastningsbalancer
minikube har en række platformsfunktioner, der gør det nemmere at skabe eksternt tilgængelige komponenter, såsom ingress controllere. Minikube leveres sammen med Nginx-indgangscontrolleren, og alt hvad vi skal gøre er at aktivere den og konfigurere den.
minikube addons enable ingress
Nu vil vi oprette en Nginx-indgangscontroller med kun én kommando, som vil fungere inde i vores minikube-klynge:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Trin 7 – Opsætning af ingress
Nu skal vi konfigurere Nginx-indgangscontrolleren, så den accepterer hello-quarkus-anmodninger.
Og endelig skal vi anvende denne konfiguration.
kubectl apply -f ingress.yml
Da vi gør alt dette på vores egen computer, tilføjer vi blot vores nodes IP-adresse til /etc/ hosts-filen for at dirigere http-anmodninger til vores minikube til NGINX load balancer.
192.168.99.100 hello-quarkus.info
Det er det, nu er vores minikube-tjeneste tilgængelig eksternt gennem Nginx-indgangscontrolleren.
Nå, det var nemt, ikke? Eller ikke så meget?
Kører på OpenShift (kodeklare containere)
Lad os nu se, hvordan alt dette gøres på Red Hat OpenShift Container Platform (OCP).
Som med minikube vælger vi et enkelt-node OpenShift-klyngedesign i form af Code Ready Containers (CRC). Tidligere hed det minishift og var baseret på OpenShift Origin-projektet, men nu er det CRC og bygget på Red Hats OpenShift Container Platform.
Her kan vi desværre ikke lade være med at sige: "OpenShift er vidunderligt!"
I første omgang tænkte vi at skrive, at udvikling på OpenShift ikke adskiller sig fra udvikling på Kubernetes. Og i bund og grund er det sådan, det er. Men i processen med at skrive dette indlæg, huskede vi, hvor mange ekstra bevægelser du skal lave, når du ikke har OpenShift, og derfor er det igen vidunderligt. Vi elsker det, når alt er gjort nemt, og hvor nemt vores eksempel er at implementere og køre på OpenShift sammenlignet med minikube, er det, der fik os til at skrive dette indlæg.
Lad os gå gennem processen og se, hvad vi skal gøre.
Så i minikube-eksemplet startede vi med Docker... Vent, vi har ikke længere brug for Docker installeret på maskinen.
Og vi har ikke brug for lokal git.
Og Maven er ikke nødvendig.
Og du behøver ikke oprette et containerbillede i hånden.
Og du behøver ikke lede efter noget lager af containerbilleder.
Og der er ingen grund til at installere en indgangscontroller.
Og du behøver heller ikke at konfigurere indgang.
Du forstår, ikke? For at implementere og køre vores applikation på OpenShift behøver du ikke noget af ovenstående. Og selve processen ser sådan ud.
Trin 1 – Start din OpenShift-klynge
Vi bruger Code Ready Containers fra Red Hat, som i det væsentlige er den samme Minikube, men kun med en fuldgyldig enkelt-node Openshift-klynge.
crc start
Trin 2 – Byg og implementer applikationen til OpenShift-klyngen
Det er på dette trin, at enkelheden og bekvemmeligheden ved OpenShift afsløres i al sin herlighed. Som med alle Kubernetes-distributioner har vi mange måder at køre en applikation på i en klynge. Og som i tilfældet med KUK vælger vi specifikt den enkleste.
OpenShift har altid været bygget som en platform til at skabe og køre containeriserede applikationer. Containerbygning har altid været en integreret del af denne platform, så der er et væld af yderligere Kubernetes-ressourcer til relaterede opgaver.
Vi vil bruge OpenShifts Source 2 Image (S2I) proces, som har flere forskellige måder at tage vores kilde (kode eller binære filer) og omdanne det til et containeriseret billede, der kører på en OpenShift-klynge.
For at gøre dette har vi brug for to ting:
- Vores kildekode er i git-depotet
- Builder-billede, som byggeriet vil blive udført på grundlag af.
Der er mange sådanne billeder vedligeholdt både af Red Hat og på fællesskabsniveau, og vi vil bruge OpenJDK-billedet, ja, da jeg er ved at bygge en Java-applikation.
Du kan køre S2I build både fra OpenShift Developer grafiske konsol og fra kommandolinjen. Vi vil bruge kommandoen new-app, der fortæller den, hvor den skal hente builder-billedet og vores kildekode.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Det er det, vores applikation er oprettet. Ved at gøre det gjorde S2I-processen følgende ting:
- Lavet en service build-pod til alle mulige ting relateret til at bygge applikationen.
- Oprettede OpenShift Build-konfigurationen.
- Jeg downloadede builder-billedet til det interne OpenShift docker-register.
- Klonet "Hello World" til det lokale depot.
- Jeg så, at der var en maven pom der, så jeg kompilerede applikationen ved hjælp af maven.
- Oprettede et nyt containerbillede, der indeholder det kompilerede Java-program, og placerede dette billede i det interne containerregister.
- Oprettet Kubernetes Deployment med specifikationer for pod, service osv.
- Jeg begyndte at implementere containerbilledet.
- Fjernede service build-pod.
Der er meget på denne liste, men det vigtigste er, at hele buildet udelukkende sker inde i OpenShift, det interne Docker-register er inde i OpenShift, og byggeprocessen opretter alle Kubernetes-komponenterne og kører dem i klyngen.
Hvis du visuelt overvåger lanceringen af S2I i konsollen, kan du se, hvordan build-poden startes, når bygningen er fuldført.
Lad os nu tage et kig på builder-pod-logfilerne: for det første viser den, hvordan Maven gør sit arbejde og downloader afhængigheder for at bygge vores java-applikation.
Efter maven-bygningen er fuldført, startes opbygningen af containerbilledet, og derefter sendes dette byggede billede til det interne lager.
Det er det, byggeprocessen er færdig. Lad os nu sikre os, at pods og tjenester i vores applikation kører i klyngen.
oc get service
Det er alt. Og kun ét hold. Det eneste, vi skal gøre, er at udsætte denne service for adgang udefra.
Trin 3 – eksponer tjenesten for adgang udefra
Som i tilfældet med KUC har vores "Hello World" på OpenShift-platformen også brug for en router til at dirigere ekstern trafik til tjenesten i klyngen. OpenShift gør dette meget nemt. For det første er HAProxy-routingkomponenten installeret i klyngen som standard (den kan ændres til den samme NGINX). For det andet er der specielle og meget konfigurerbare ressourcer kaldet Routes og minder om Ingress-objekter i gode gamle Kubernetes (faktisk havde OpenShifts Routes stor indflydelse på designet af Ingress-objekter, som nu kan bruges i OpenShift), men for vores "Hello World" , og i næsten alle andre tilfælde er standardruten nok for os uden yderligere konfiguration.
For at oprette en routbar FQDN til "Hello World" (ja, OpenShiift har sin egen DNS til routing efter tjenestenavne), vil vi blot afsløre vores tjeneste:
oc expose service quarkus-hello-world
Hvis du ser på den nyoprettede rute, kan du finde FQDN og andre ruteoplysninger der:
oc get route
Og endelig får vi adgang til vores service fra browseren:
Men nu var det virkelig nemt!
Vi elsker Kubernetes og alt, hvad denne teknologi giver os mulighed for, og vi elsker også enkelheden og letheden. Kubernetes blev skabt for utroligt at forenkle driften af distribuerede, skalerbare containere, men dens enkelhed er ikke længere nok til at sætte applikationer i produktion i dag. Det er her, OpenShift kommer i spil, følger med tiden og tilbyder Kubernetes, der primært er rettet mod udvikleren. Der er investeret mange kræfter i at skræddersy OpenShift-platformen specifikt til udvikleren, herunder skabelsen af værktøjer som S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-integration, Developer Catalogs, Helm-integration, overvågning og mange andre.
Vi håber, at denne artikel var interessant og nyttig for dig. Du kan finde yderligere ressourcer, materialer og andet nyttigt til udvikling på OpenShift-platformen på portalen .
Kilde: www.habr.com