Dette innlegget ble skrevet fordi våre ansatte hadde en del samtaler med klienter om utvikling av applikasjoner på Kubernetes og spesifikasjonene ved slik utvikling på OpenShift.
Vi starter vanligvis med tesen om at Kubernetes bare er Kubernetes, og OpenShift er allerede en Kubernetes-plattform, som Microsoft AKS eller Amazon EKS. Hver av disse plattformene har sine egne fordeler, fokusert på en bestemt målgruppe. Og etter det flyter samtalen allerede inn i en sammenligning av styrker og svakheter ved spesifikke plattformer.
Generelt tenkte vi å skrive dette innlegget med en konklusjon som "Hør, det spiller ingen rolle hvor du skal kjøre koden, på OpenShift eller på AKS, på EKS, på noen tilpassede Kubernetes, eller på hva Kubernetes" (la oss kalle det KUK for kort) "Det er veldig enkelt, både der og der."
Så planla vi å ta den enkleste "Hello World" og bruke den til å vise hva som er felles og hva som er forskjellene mellom CMC og Red Hat OpenShift Container Platform (heretter OCP eller ganske enkelt OpenShift).
Men i løpet av å skrive dette innlegget innså vi at vi har blitt så vant til å bruke OpenShift at vi rett og slett ikke skjønner hvordan det har vokst og blitt til en fantastisk plattform som har blitt mye mer enn bare en Kubernetes-distribusjon. Vi har en tendens til å ta modenheten og enkelheten til OpenShift for gitt, samtidig som vi overser dens storhet.
Generelt er tiden inne for aktiv omvendelse, og nå vil vi trinn for trinn sammenligne idriftsettingen av vår "Hello World" på KUK og på OpenShift, og vi vil gjøre det så objektivt som mulig (vel, bortsett fra noen ganger å vise en personlig holdning til emnet). Hvis du er interessert i en rent subjektiv mening om dette spørsmålet, kan du lese den . Og i dette innlegget vil vi holde oss til fakta og kun fakta.
Klynger
Så vår "Hello World" trenger klynger. La oss bare si "nei" til eventuelle offentlige skyer, for ikke å betale for servere, registre, nettverk, dataoverføring osv. Følgelig velger vi en enkel en-node klynge på (for KUK) og (for en OpenShift-klynge). Begge disse alternativene er veldig enkle å installere, men krever ganske mye ressurser på den bærbare datamaskinen.
Montering på KUK-e
Så la oss gå.
Trinn 1 – Bygg vårt containerbilde
La oss starte med å distribuere vår "Hello World" til minikube. For å gjøre dette trenger du:
- 1. Docker installert.
- 2. Installert Git.
- 3. Installert Maven (faktisk bruker dette prosjektet mvnw binær, så du kan klare deg uten).
- 4. Egentlig er selve kilden, dvs. depotklone
Det første trinnet er å lage et Quarkus-prosjekt. Ikke vær redd hvis du aldri har brukt Quarkus.io – det er enkelt. Du velger bare komponentene du vil bruke i prosjektet (RestEasy, Hibernate, Amazon SQS, Camel, etc.), og så setter Quarkus selv, uten noe av din deltagelse, opp maven-arketypen og legger alt på github. Det vil si bokstavelig talt ett museklikk - og du er ferdig. Det er derfor vi elsker Quarkus.
Den enkleste måten å bygge vår "Hello World" inn i et containerisert bilde er å bruke quarkus-maven-utvidelsene for Docker, som vil gjøre alt nødvendig arbeid. Med bruken av Quarkus har dette blitt veldig enkelt og enkelt: legg til container-image-docker-utvidelsen og du kan lage bilder med maven-kommandoer.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Og til slutt bygger vi bildet vårt ved å bruke Maven. Som et resultat blir kildekoden vår til et ferdig beholderbilde, som allerede kan kjøres i beholderens kjøretid.
./mvnw -X clean package -Dquarkus.container-image.build=true
Det er faktisk alt, nå kan du kjøre containeren med docker run-kommandoen, etter å ha kartlagt tjenesten vår til port 8080 slik at den kan nås.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Etter at containerforekomsten har startet, gjenstår det bare å sjekke med curl-kommandoen at tjenesten vår kjører:
Så alt fungerer, og det var veldig enkelt og enkelt.
Trinn 2 - Send inn beholderen vår til beholderbildelageret
Foreløpig lagres bildet vi opprettet lokalt i vårt lokale containerlager. Hvis vi vil bruke dette bildet i vårt KUK-miljø, må vi legge det i et annet depot. Kubernetes har ikke disse funksjonene, så vi vil bruke dockerhub. For for det første er det gratis, og for det andre gjør (nesten) alle det.
Dette er også veldig enkelt, og alt du trenger er en dockerhub-konto.
Så vi installerer dockerhub og sender bildet vårt dit.
Trinn 3 - Start Kubernetes
Det er mange måter å sette sammen en kubernetes-konfigurasjon for å kjøre vår "Hello World", men vi vil bruke den enkleste av dem, fordi vi er slike mennesker ...
Først starter vi minikube-klyngen:
minikube start
Trinn 4 – Implementering av containerbildet vårt
Nå må vi konvertere koden og containerbildet vårt til kubernetes-konfigurasjoner. Med andre ord, vi trenger en pod og distribusjonsdefinisjon som peker til containerbildet vårt på dockerhub. En av de enkleste måtene å gjøre dette på er å kjøre kommandoen create deployment som peker på bildet vårt:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Med denne kommandoen ba vi vår COO om å lage en distribusjonskonfigurasjon, som skulle inneholde pod-spesifikasjonen for containerbildet vårt. Denne kommandoen vil også bruke denne konfigurasjonen på minikube-klyngen vår, og opprette en distribusjon som vil laste ned containerbildet vårt og starte poden i klyngen.
Trinn 5 - åpen tilgang til tjenesten vår
Nå som vi har et distribuert containerbilde, er det på tide å tenke på hvordan du konfigurerer ekstern tilgang til denne Restful-tjenesten, som faktisk er programmert i koden vår.
Det er mange måter her. For eksempel kan du bruke eksponer-kommandoen til automatisk å lage passende Kubernetes-komponenter som tjenester og endepunkter. Faktisk er dette hva vi vil gjøre ved å utføre eksponeringskommandoen for distribusjonsobjektet vårt:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
La oss ta et øyeblikk til å se på "-type"-alternativet til eksponer-kommandoen.
Når vi eksponerer og lager komponentene som trengs for å drive tjenesten vår, trenger vi blant annet å kunne koble fra utsiden til hello-quarkus-tjenesten som sitter inne i vårt programvaredefinerte nettverk. Og parameter typen lar oss lage og koble til ting som lastbalansere for å rute trafikk til det nettverket.
For eksempel ved å skrive type=LoadBalancer, klargjør vi automatisk en lastbalanser i den offentlige skyen for å koble til Kubernetes-klyngen vår. Dette er selvfølgelig flott, men du må forstå at en slik konfigurasjon vil være strengt knyttet til en spesifikk offentlig sky og vil være vanskeligere å overføre mellom Kubernetes-forekomster i forskjellige miljøer.
I vårt eksempel type=NodePort, det vil si at anropet til vår tjeneste går etter IP-adressen til noden og portnummeret. Dette alternativet lar deg ikke bruke noen offentlige skyer, men krever en rekke ekstra trinn. Først trenger du din egen lastbalanser, så vi vil distribuere NGINX lastbalanser i klyngen vår.
Trinn 6 - Sett opp en lastbalanser
minikube har en rekke plattformfunksjoner som gjør det enkelt å lage komponentene du trenger for ekstern tilgang, for eksempel ingress-kontrollere. Minikube leveres sammen med Nginx-inngangskontrolleren, og alt vi trenger å gjøre er å aktivere den og konfigurere den.
minikube addons enable ingress
Nå, med bare én kommando, vil vi lage en Nginx-inngangskontroller som vil fungere inne i minikube-klyngen vår:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Trinn 7 – Sette opp ingress
Nå må vi konfigurere Nginx-inngangskontrolleren slik at den godtar hello-quarkus-forespørsler.
Og til slutt må vi bruke denne konfigurasjonen.
kubectl apply -f ingress.yml
Siden vi gjør alt dette på vår egen maskin, legger vi ganske enkelt til nodens IP-adresse til /etc/hosts-filen for å sende http-forespørsler til minikuben vår til NGINX-lastbalanseren.
192.168.99.100 hello-quarkus.info
Det er det, nå er minikube-tjenesten vår tilgjengelig eksternt gjennom Nginx-inngangskontrolleren.
Vel, det var lett, ikke sant? Eller ikke så mye?
Kjør på OpenShift (kodeklare beholdere)
Og la oss nå se hvordan det hele gjøres på Red Hat OpenShift Container Platform (OCP).
Som i tilfellet med minikube, velger vi et opplegg med en enkelt-node OpenShift-klynge i form av Code Ready Containers (CRC). Det pleide å hete minishift og var basert på OpenShift Origin-prosjektet, men nå er det CRC og bygget på Red Hats OpenShift Container Platform.
Her, beklager, vi kan ikke la være å si: "OpenShift er flott!"
I utgangspunktet tenkte vi å skrive at utvikling på OpenShift ikke er forskjellig fra utvikling på Kubernetes. Og faktisk er det sånn det er. Men i prosessen med å skrive dette innlegget husket vi hvor mange unødvendige bevegelser du må gjøre når du ikke har OpenShift, og derfor er det vakkert igjen. Vi elsker at ting er enkelt, og hvor enkelt det er å distribuere og kjøre eksemplet vårt på OpenShift sammenlignet med minikube er det som inspirerte oss til å skrive dette innlegget.
La oss gå gjennom prosessen og se hva vi må gjøre.
Så i minikube-eksemplet startet vi med Docker... Vent, vi trenger ikke Docker installert på maskinen lenger.
Og vi trenger ikke en lokal git.
Og Maven er ikke nødvendig.
Og du trenger ikke lage et beholderbilde for hånd.
Og du trenger ikke å lete etter noe arkiv med containerbilder.
Og du trenger ikke installere en ingress-kontroller.
Og du trenger ikke konfigurere ingress heller.
Forstår du? For å distribuere og kjøre applikasjonen vår på OpenShift, er ingen av de ovennevnte nødvendig. Og selve prosessen er som følger.
Trinn 1 – Starte OpenShift-klyngen
Vi bruker Code Ready Containers fra Red Hat, som i hovedsak er den samme Minikube, men bare med en full enkelt-node Openshift-klynge.
crc start
Trinn 2 - Bygg og distribuer applikasjonen til OpenShift-klyngen
Det er på dette trinnet at enkelheten og bekvemmeligheten til OpenShift avsløres i all sin prakt. Som med alle Kubernetes-distribusjoner, har vi mange måter å kjøre en applikasjon i en klynge på. Og, som i tilfellet med KUK, velger vi spesifikt den enkleste.
OpenShift har alltid vært bygget som en plattform for å lage og kjøre containeriserte applikasjoner. Containerbygging har alltid vært en integrert del av denne plattformen, så det er massevis av ekstra Kubernetes-ressurser for relaterte oppgaver.
Vi vil bruke OpenShifts Source 2 Image (S2I) prosess, som har flere forskjellige måter å ta kilden vår (kode eller binærfiler) og gjøre den om til et containerisert bilde som kjører på en OpenShift-klynge.
For å gjøre dette trenger vi to ting:
- Kildekoden vår i git-depotet
- Builder-bilde, basert på hvilken monteringen skal utføres.
Det er mange slike bilder vedlikeholdt både av Red Hat og på fellesskapsnivå, og vi vil bruke OpenJDK-bildet, vel, siden jeg bygger en Java-applikasjon.
Du kan kjøre S2I-bygget både fra den grafiske konsollen for OpenShift Developer og fra kommandolinjen. Vi vil bruke new-app-kommandoen, og fortelle den hvor den skal hente byggherrebildet og kildekoden vår.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Det er det, applikasjonen vår er opprettet. Ved å gjøre det gjorde S2I-prosessen følgende ting:
- Laget en service build-pod for alle slags ting relatert til å bygge applikasjonen.
- Opprettet en OpenShift Build-konfig.
- Jeg lastet ned byggebildet til det interne OpenShift docker-registeret.
- Klonet "Hello World" til lokalt depot.
- Så at det var en maven pom der inne og kompilerte appen med maven.
- Laget et nytt containerbilde som inneholder den kompilerte Java-applikasjonen og satte dette bildet inn i det interne containerregisteret.
- Opprettet Kubernetes Deployment med spesifikasjoner for pod, service osv.
- Lanserte distribusjonsbeholderbilde.
- Fjernet service build-pod.
Det er mye på denne listen, men det viktigste er at hele bygget skjer utelukkende inne i OpenShift, det interne Docker-registeret er inne i OpenShift, og byggeprosessen oppretter alle Kubernetes-komponentene og kjører dem i klyngen.
Hvis du visuelt overvåker lanseringen av S2I i konsollen, kan du se hvordan byggepoden lanseres under byggingen.
Og la oss nå ta en titt på byggepodens logger: For det første kan du se hvordan Maven gjør jobben sin og laster ned avhengigheter for å bygge vår java-applikasjon.
Etter at maven-byggingen er fullført, startes byggingen av beholderbildet, og deretter sendes dette bygde bildet til det interne depotet.
Alt, monteringsprosessen er fullført. La oss nå sørge for at podene og tjenestene til applikasjonen vår har startet i klyngen.
oc get service
Det er alt. Og bare ett lag. Alt vi trenger å gjøre er å avsløre denne tjenesten for ekstern tilgang.
Trinn 3 - gjør tjenesten eksponert for tilgang fra utsiden
Som i tilfellet med KUK, på OpenShift-plattformen, trenger vår "Hello World" også en ruter for å dirigere ekstern trafikk til en tjeneste inne i klyngen. I OpenShift gjør dette det veldig enkelt. For det første er HAProxy-rutingskomponenten installert i klyngen som standard (den kan endres til samme NGINX). For det andre er det spesielle og svært konfigurerbare ressurser kalt Routes, som minner om Ingress-objekter i gode gamle Kubernetes (faktisk har OpenShifts Routes sterkt påvirket utformingen av Ingress-objekter, som nå kan brukes i OpenShift) , men for vår "Hei World", og i nesten alle andre tilfeller er standardruten nok for oss uten ekstra konfigurasjon.
For å lage en ruterbar FQDN for "Hello World" (ja, OpenShiift har sin egen DNS for ruting etter tjenestenavn), viser vi ganske enkelt tjenesten vår:
oc expose service quarkus-hello-world
Hvis du ser på den nyopprettede ruten, kan du finne FQDN og annen ruteinformasjon der:
oc get route
Og til slutt får vi tilgang til tjenesten vår fra nettleseren:
Men nå var det veldig enkelt!
Vi elsker Kubernetes og alt som denne teknologien lar deg gjøre, og vi elsker også enkelhet og letthet. Kubernetes ble designet for å gjøre distribuerte, skalerbare beholdere utrolig enkle å betjene, men dens enkelhet er ikke lenger nok til å bringe applikasjoner i produksjon i dag. Og det er her OpenShift kommer inn i bildet, som følger med i tiden og tilbyr Kubernetes, primært fokusert på utvikleren. Mye innsats har blitt investert for å skreddersy OpenShift-plattformen spesifikt for utvikleren, inkludert opprettelsen av verktøy som S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-integrasjon, Developer Catalogs, Helm-integrasjon, overvåking og mange andre.
Vi håper at denne artikkelen var interessant og nyttig for deg. Og du kan finne tilleggsressurser, materialer og andre ting som er nyttige for utvikling på OpenShift-plattformen på portalen .
Kilde: www.habr.com