Tämä viesti on kirjoitettu, koska työntekijämme kävivät melko paljon keskusteluja asiakkaiden kanssa Kubernetes-sovelluskehityksestä ja OpenShift-kehityksen erityispiirteistä.
Aloitamme yleensä väitöskirjasta, että Kubernetes on vain Kubernetes ja OpenShift on jo Kubernetes-alusta, kuten Microsoft AKS tai Amazon EKS. Jokaisella näistä alustoista on omat etunsa, jotka on suunnattu tietylle kohdeyleisölle. Ja tämän jälkeen keskustelu kääntyy tiettyjen alustojen vahvuuksien ja heikkouksien vertailuun.
Yleensä ajattelimme kirjoittaa tämän viestin päätelmänä, kuten "Kuuntele, sillä ei ole väliä missä koodi suoritetaan, OpenShiftissä tai AKS:ssä, EKS:ssä, muokatuissa Kubernetesissä tai missä tahansa Kubernetesissa (Lyhyyden vuoksi sanotaan sitä KUK:ksi) "Se on todella yksinkertaista, sekä siellä että siellä."
Sitten suunnittelimme ottavan yksinkertaisimman "Hello World" ja sen esimerkin avulla näyttääksemme, mikä on yleistä ja mitä eroa on KUC:n ja Red Hat OpenShift Container Platformin (jäljempänä OCP tai yksinkertaisesti OpenShift) välillä.
Tätä viestiä kirjoittaessamme kuitenkin ymmärsimme, että olimme niin tottuneet käyttämään OpenShiftiä niin kauan, että emme yksinkertaisesti ymmärtäneet, kuinka se oli kasvanut ja muuttunut hämmästyttäväksi alustaksi, josta tuli paljon enemmän kuin pelkkä Kubernetes-jakelu. Meillä on tapana pitää OpenShiftin kypsyyttä ja yksinkertaisuutta itsestäänselvyytenä ja unohtaa sen loisto.
Yleisesti ottaen aktiivisen parannuksen aika on tullut, ja nyt verrataan askel askeleelta "Hello World" -ohjelman käyttöönottoa KUK:ssa ja OpenShiftissä, ja teemme tämän mahdollisimman objektiivisesti (no, paitsi joskus näyttämällä henkilökohtainen asenne aiheeseen). Jos olet kiinnostunut puhtaasti subjektiivisesta mielipiteestä tästä aiheesta, voit lukea sen . Ja tässä viestissä pysymme faktoissa ja vain faktoissa.
Klusterit
Joten "Hello World" vaatii klustereita. Sanomme heti "ei" kaikille julkisille pilville, jotta emme maksa palvelimista, rekistereistä, verkoista, tiedonsiirrosta jne. Vastaavasti valitsemme yksinkertaisen yksisolmun klusterin (KUK:lle) ja (OpenShift-klusterille). Molemmat vaihtoehdot ovat todella helppoja asentaa, mutta ne vaativat melko paljon resursseja kannettavassa tietokoneessa.
Kokoonpano KUK-e
Joten mennään.
Vaihe 1 – konttiimagomme rakentaminen
Aloitetaan ottamalla käyttöön "Hello World" minikubeen. Tätä varten tarvitset:
- 1. Docker asennettu.
- 2. Git asennettu.
- 3. Asennettu Maven (itse asiassa tämä projekti käyttää mvnw-binaaria, joten voit tehdä ilman sitä).
- 4. Itse asiassa itse lähde, ts. arkiston klooni
Ensimmäinen askel on Quarkus-projektin luominen. Älä huolestu, jos et ole koskaan työskennellyt Quarkus.io:n kanssa – se on helppoa. Valitset vain komponentit, joita haluat käyttää projektissa (RestEasy, Hibernate, Amazon SQS, Camel jne.), ja sitten Quarkus itse, ilman sinun osallistumistasi, määrittää maven arkkityypin ja laittaa kaiken githubiin. Eli kirjaimellisesti yksi hiiren napsautus ja olet valmis. Tästä syystä rakastamme Quarkusta.
Helpoin tapa rakentaa "Hello World" konttikuvaksi on käyttää Dockerin quarkus-maven-laajennuksia, jotka tekevät kaiken tarvittavan työn. Quarkuksen myötä tästä on tullut todella helppoa ja yksinkertaista: lisää konteiner-image-docker-laajennus ja voit luoda kuvia käyttämällä maven-komentoja.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Lopuksi rakennamme imagomme Mavenin avulla. Tämän seurauksena lähdekoodimme muuttuu valmiiksi konttikuvaksi, jota voidaan jo ajaa konttiajonaikaisessa ympäristössä.
./mvnw -X clean package -Dquarkus.container-image.build=true
Siinä kaikki, nyt voit käynnistää kontin Docker run -komennolla, joka yhdistää palvelumme porttiin 8080, jotta sitä voidaan käyttää.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Kun säilön ilmentymä on käynnistynyt, sinun tarvitsee vain tarkistaa curl-komennolla, että palvelumme on käynnissä:
Joten kaikki toimii ja se oli todella helppoa ja yksinkertaista.
Vaihe 2 – lähetä säilömme konttikuvavarastoon
Toistaiseksi luomamme kuva on tallennettu paikallisesti paikalliseen konttivarastoimme. Jos haluamme käyttää tätä kuvaa COOK-ympäristössämme, se on sijoitettava johonkin muuhun arkistoon. Kubernetes ei sisällä tällaisia ominaisuuksia, joten käytämme dockerhubia. Koska ensinnäkin se on ilmaista, ja toiseksi (melkein) kaikki tekevät sitä.
Tämä on myös hyvin yksinkertaista, ja tarvitset vain dockerhub-tilin.
Joten asennamme dockerhubin ja lähetämme kuvamme sinne.
Vaihe 3 - käynnistä Kubernetes
On monia tapoja koota kubernetes-konfiguraatiota "Hello World" -ohjelmaa varten, mutta käytämme niistä yksinkertaisimpia, sellaisia olemme...
Ensin käynnistetään minikube-klusteri:
minikube start
Vaihe 4 – ota konttikuvamme käyttöön
Nyt meidän on muutettava koodimme ja säiliökuvamme kubernetes-kokoonpanoiksi. Toisin sanoen tarvitsemme pod- ja käyttöönottomäärityksen, joka osoittaa konttikuvaamme Dockerhubissa. Yksi helpoimmista tavoista tehdä tämä on ajaa image deployment -komento:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Tällä komennolla pyysimme COO:ta luomaan käyttöönottokokoonpanon, jonka pitäisi sisältää säiliökuvamme pod-määritykset. Tämä komento käyttää tätä määritystä myös minikube-klusteriimme ja luo käyttöönoton, joka lataa konttikuvamme ja käynnistää podin klusterissa.
Vaihe 5 – avaa pääsy palveluihimme
Nyt kun meillä on käytössä konttikuva, on aika miettiä, kuinka määrittää ulkoinen pääsy tähän Restful-palveluun, joka itse asiassa on ohjelmoitu koodiimme.
Täällä on monia tapoja. Voit esimerkiksi käyttää expose-komentoa luodaksesi automaattisesti asianmukaiset Kubernetes-komponentit, kuten palvelut ja päätepisteet. Itse asiassa teemme tämän suorittamalla Expose-komennon käyttöönottoobjektillemme:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Katsotaanpa hetki expose-komennon "-type"-vaihtoehtoa.
Kun paljastamme ja luomme palvelumme suorittamiseen tarvittavia komponentteja, meidän on muun muassa kyettävä muodostamaan yhteys ulkopuolelta hello-quarkus -palveluun, joka sijaitsee ohjelmiston määrittämässä verkossamme. Ja parametri tyyppi avulla voimme luoda ja yhdistää asioita, kuten kuormituksen tasaajia reitittämään liikennettä tähän verkkoon.
Esimerkiksi kirjoittamalla type=LoadBalancer, tarjoamme automaattisesti kuormantasaajan julkisessa pilvessä yhteyden muodostamiseksi Kubernetes-klusteriimme. Tämä on tietysti hienoa, mutta sinun on ymmärrettävä, että tällainen kokoonpano on tiukasti sidottu tiettyyn julkiseen pilveen ja sitä on vaikeampi siirtää Kubernetes-esiintymien välillä eri ympäristöissä.
Esimerkissämme type=NodePort, eli palveluumme käytetään solmun IP-osoitteen ja porttinumeron avulla. Tämän vaihtoehdon avulla voit olla käyttämättä julkisia pilviä, mutta vaatii useita lisävaiheita. Ensinnäkin tarvitset oman kuormituksen tasaajan, joten otamme NGINX-kuormituksen tasaajan käyttöön klusteriimme.
Vaihe 6 – asenna kuormantasauslaite
minikubella on useita alustatoimintoja, jotka helpottavat ulkopuolelta saatavien komponenttien, kuten sisääntuloohjaimien, luomista. Minikube toimitetaan Nginx-sisääntuloohjaimen mukana, ja meidän tarvitsee vain ottaa se käyttöön ja määrittää se.
minikube addons enable ingress
Nyt luomme Nginx-sisääntuloohjaimen yhdellä komennolla, joka toimii minikube-klusterimme sisällä:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Vaihe 7 – Sisääntulon määrittäminen
Nyt meidän on määritettävä Nginx-sisääntuloohjain niin, että se hyväksyy hello-quarkus-pyynnöt.
Ja lopuksi meidän on käytettävä tätä kokoonpanoa.
kubectl apply -f ingress.yml
Koska teemme tämän kaiken omalla tietokoneellamme, lisäämme vain solmumme IP-osoitteen /etc/ hosts-tiedostoon reitittääksemme http-pyynnöt minikubeemme NGINX-kuormituksen tasapainottimeen.
192.168.99.100 hello-quarkus.info
Siinä kaikki, nyt minikube-palvelumme on käytettävissä ulkoisesti Nginx-tuloohjaimen kautta.
No, se oli helppoa, eikö? Vai ei niin paljon?
Käynnissä OpenShift-tilassa (koodivalmiit säilöt)
Katsotaan nyt, kuinka tämä kaikki tehdään Red Hat OpenShift Container Platform (OCP) -alustalla.
Kuten minikubessa, valitsemme yhden solmun OpenShift-klusterin suunnittelun Code Ready Containers (CRC) -muodossa. Aiemmin sitä kutsuttiin minishiftiksi ja se perustui OpenShift Origin -projektiin, mutta nyt se on CRC ja rakennettu Red Hatin OpenShift Container Platformille.
Tässä emme valitettavasti voi muuta kuin sanoa: "OpenShift on ihana!"
Aluksi ajattelimme kirjoittaa, että OpenShift-kehitys ei eroa Kubernetes-kehityksestä. Ja pohjimmiltaan asia on näin. Mutta tätä viestiä kirjoittaessamme muistimme, kuinka monta ylimääräistä liikettä sinun täytyy tehdä, kun sinulla ei ole OpenShiftiä, ja siksi se on jälleen upeaa. Rakastamme sitä, kun kaikki tehdään helposti, ja kuinka helppoa esimerkkimme on ottaa käyttöön ja suorittaa OpenShiftillä verrattuna minikubeen, sai meidät kirjoittamaan tämän viestin.
Käydään prosessi läpi ja katsotaan, mitä meidän on tehtävä.
Joten minikube-esimerkissä aloitimme Dockerilla... Odota, meidän ei enää tarvitse asentaa Dockeria koneeseen.
Ja emme tarvitse paikallista gittiä.
Ja Mavenia ei tarvita.
Eikä sinun tarvitse luoda konttikuvaa käsin.
Eikä sinun tarvitse etsiä säilökuvien arkistoa.
Eikä sisääntuloohjainta tarvitse asentaa.
Sinun ei myöskään tarvitse määrittää sisääntuloa.
Ymmärrätkö, eikö? Et tarvitse mitään yllä olevista ottaaksesi käyttöön ja suorittaaksesi sovelluksemme OpenShiftissä. Ja itse prosessi näyttää tältä.
Vaihe 1 - Käynnistä OpenShift-klusteri
Käytämme Red Hatin Code Ready Containers -konttia, joka on pohjimmiltaan sama Minikube, mutta vain täysimittaisella yhden solmun Openshift-klusterilla.
crc start
Vaihe 2 – Rakenna ja ota sovellus käyttöön OpenShift-klusteriin
Juuri tässä vaiheessa OpenShiftin yksinkertaisuus ja mukavuus paljastuvat kaikessa loistossaan. Kuten kaikissa Kubernetes-jakeluissa, meillä on monia tapoja suorittaa sovellus klusterissa. Ja kuten KUK:n tapauksessa, valitsemme nimenomaan yksinkertaisimman.
OpenShift on aina rakennettu alustaksi konttisovellusten luomiseen ja suorittamiseen. Säiliön rakentaminen on aina ollut olennainen osa tätä alustaa, joten Kubernetes-lisäresursseja on runsaasti vastaaviin tehtäviin.
Käytämme OpenShiftin Source 2 Image (S2I) -prosessia, jolla on useita eri tapoja ottaa lähde (koodi tai binaarit) ja muuttaa se konttikuvaksi, joka toimii OpenShift-klusterissa.
Tätä varten tarvitsemme kaksi asiaa:
- Lähdekoodimme on git-arkistossa
- Rakennuskuva, jonka perusteella rakentaminen suoritetaan.
Tällaisia kuvia ylläpitää paljon sekä Red Hat että yhteisötasolla, ja käytämme OpenJDK-kuvaa, no, koska olen rakentamassa Java-sovellusta.
Voit suorittaa S2I-koontiversion sekä OpenShift Developerin graafisesta konsolista että komentoriviltä. Käytämme new-app-komentoa kertomalla sille, mistä saa rakennustyökalun kuvan ja lähdekoodimme.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Siinä kaikki, sovelluksemme on luotu. Näin tehdessään S2I-prosessi teki seuraavat asiat:
- Loi palvelukokonaisuuden kaikenlaisille sovelluksen rakentamiseen liittyville asioille.
- Loi OpenShift Build -kokoonpanon.
- Latasin rakennustyökalun kuvan sisäiseen OpenShift Docker -rekisteriin.
- Kloonattiin "Hello World" paikalliseen arkistoon.
- Näin, että siellä oli maven pom, joten käänsin sovelluksen mavenilla.
- Loi uuden säilökuvan, joka sisältää käännetyn Java-sovelluksen, ja lisäsi tämän kuvan sisäiseen säilörekisteriin.
- Luotu Kubernetes-käyttöönotto spesifikaatioineen podille, palveluille jne.
- Aloitin säilön kuvan käyttöönoton.
- Irrotettu huoltokotelo.
Tässä luettelossa on paljon, mutta tärkeintä on, että koko rakennus tapahtuu yksinomaan OpenShiftin sisällä, sisäinen Docker-rekisteri on OpenShiftin sisällä ja rakennusprosessi luo kaikki Kubernetes-komponentit ja ajaa ne klusterissa.
Jos seuraat visuaalisesti S2I:n käynnistämistä konsolissa, voit nähdä, kuinka koontiversio käynnistetään, kun koontiversio on valmis.
Katsotaanpa nyt rakentajan pod-lokeja: ensinnäkin se näyttää kuinka maven tekee työnsä ja lataa riippuvuuksia Java-sovelluksemme rakentamiseksi.
Kun Maven-koontiversio on valmis, säiliökuvan rakentaminen aloitetaan ja tämä rakennettu kuva lähetetään sisäiseen arkistoon.
Siinä kaikki, rakennusprosessi on valmis. Varmistetaan nyt, että sovelluksemme podit ja palvelut ovat käynnissä klusterissa.
oc get service
Siinä kaikki. Ja vain yksi joukkue. Meidän tarvitsee vain paljastaa tämä palvelu ulkopuolelta saataville.
Vaihe 3 – paljasta palvelu ulkopuolelta käsin
Kuten KUC:n tapauksessa, OpenShift-alustalla "Hello World" tarvitsee myös reitittimen ohjaamaan ulkoista liikennettä klusterin palveluun. OpenShift tekee tästä erittäin helppoa. Ensinnäkin HAProxy-reitityskomponentti asennetaan oletusarvoisesti klusteriin (se voidaan vaihtaa samaan NGINX:ään). Toiseksi, on olemassa erityisiä ja hyvin konfiguroitavia resursseja nimeltä Routes ja jotka muistuttavat Ingress-objekteja vanhassa hyvässä Kubernetesissa (itse asiassa OpenShiftin reitit vaikuttivat suuresti Ingress-objektien suunnitteluun, joita voidaan nyt käyttää OpenShiftissä), mutta meidän "Hei maailmalle" , ja melkein kaikissa muissa tapauksissa vakioreitti riittää meille ilman lisämäärityksiä.
Luodaksemme reititettävän FQDN:n "Hello World" -sovellukselle (kyllä, OpenShiiftillä on oma DNS reititystä varten palvelunimien perusteella), paljastamme palvelumme:
oc expose service quarkus-hello-world
Jos katsot äskettäin luotua reittiä, löydät sieltä FQDN:n ja muut reititystiedot:
oc get route
Ja lopuksi pääsemme palveluumme selaimesta:
Mutta nyt se oli todella helppoa!
Rakastamme Kubernetesia ja kaikkea, mitä tämän tekniikan avulla voimme tehdä, ja rakastamme myös yksinkertaisuutta ja helppoutta. Kubernetes luotiin uskomattoman yksinkertaistamaan hajautettujen, skaalautuvien säiliöiden toimintaa, mutta sen yksinkertaisuus ei enää riitä sovellusten tuomiseen tuotantoon nykyään. Tässä tulee esiin OpenShift, joka pysyy ajan tasalla ja tarjoaa ensisijaisesti kehittäjälle suunnatun Kubernetesin. Paljon työtä on tehty OpenShift-alustan räätälöimiseen erityisesti kehittäjälle, mukaan lukien työkalujen, kuten S2I, ODI, Developer Portal, OpenShift Operator Framework, IDE-integraatio, Developer Catalogues, Helm-integraatio, valvonta ja monet muut, luominen.
Toivomme, että tämä artikkeli oli mielenkiintoinen ja hyödyllinen sinulle. Portaalin OpenShift-alustalta löydät lisäresursseja, materiaaleja ja muuta kehittämisen kannalta hyödyllistä .
Lähde: will.com