Questo post è stato scritto perché il nostro staff ha avuto alcune conversazioni con i clienti sullo sviluppo di applicazioni su Kubernetes e sulle specifiche di tale sviluppo su OpenShift.
Di solito partiamo con la tesi che Kubernetes è solo Kubernetes e OpenShift è già una piattaforma Kubernetes, come Microsoft AKS o Amazon EKS. Ognuna di queste piattaforme ha i suoi vantaggi, focalizzati su un particolare target di riferimento. E dopo, la conversazione sfocia già in un confronto tra i punti di forza e di debolezza di piattaforme specifiche.
In generale, abbiamo pensato di scrivere questo post con un output del tipo “Ascolta, non importa dove esegui il codice, su OpenShift o su AKS, su EKS, su alcuni Kubernetes personalizzati, sì su qualsiasi Kubernetes (chiamiamolo KUK in breve) "È davvero semplice, sia lì che lì."
Quindi abbiamo pianificato di prendere il più semplice "Hello World" e di utilizzarlo per mostrare cosa ha in comune e quali sono le differenze tra la CMC e la Red Hat OpenShift Container Platform (di seguito, OCP o semplicemente OpenShift).
Tuttavia, nel corso della stesura di questo post, ci siamo resi conto che siamo diventati così abituati a utilizzare OpenShift che semplicemente non ci rendiamo conto di come sia cresciuto e si sia trasformato in una straordinaria piattaforma che è diventata molto più di una semplice distribuzione Kubernetes. Tendiamo a dare per scontata la maturità e la semplicità di OpenShift, trascurandone la magnificenza.
In generale, è giunto il momento del pentimento attivo, e ora confronteremo passo dopo passo la messa in servizio del nostro "Hello World" su KUK e su OpenShift, e lo faremo nel modo più obiettivo possibile (beh, tranne a volte mostrando un personale atteggiamento verso l'argomento). Se sei interessato a un'opinione puramente soggettiva su questo problema, puoi leggerla . E in questo post ci atterremo ai fatti e solo ai fatti.
Cluster
Quindi, il nostro "Hello World" ha bisogno di cluster. Diciamo semplicemente "no" a qualsiasi cloud pubblico, per non pagare server, registri, reti, trasferimento dati, ecc. Di conseguenza, scegliamo un semplice cluster a un nodo (per KUK) e (per un cluster OpenShift). Entrambe queste opzioni sono davvero facili da installare, ma richiedono molte risorse sul tuo laptop.
Assemblea su KUK-e
Allora, andiamo.
Passaggio 1: creazione dell'immagine del contenitore
Iniziamo distribuendo il nostro "Hello World" su minikube. Ciò richiederà:
- 1. Finestra mobile installata.
- 2. Git installato.
- 3. Maven installato (in realtà, questo progetto utilizza il binario mvnw, quindi puoi farne a meno).
- 4. In realtà, la fonte stessa, ad es. clone del deposito
Il primo passo è creare un progetto Quarkus. Non aver paura se non hai mai usato Quarkus.io: è facile. Seleziona semplicemente i componenti che desideri utilizzare nel progetto (RestEasy, Hibernate, Amazon SQS, Camel, ecc.), quindi Quarkus stesso, senza alcuna tua partecipazione, imposta l'archetipo Maven e mette tutto su Github. Cioè, letteralmente un clic del mouse - e il gioco è fatto. Questo è il motivo per cui amiamo Quarkus.
Il modo più semplice per creare il nostro "Hello World" in un'immagine containerizzata è utilizzare le estensioni quarkus-maven per Docker, che faranno tutto il lavoro necessario. Con l'avvento di Quarkus, questo è diventato davvero facile e semplice: aggiungi l'estensione container-image-docker e potrai creare immagini con comandi maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
E infine, costruiamo la nostra immagine utilizzando Maven. Di conseguenza, il nostro codice sorgente si trasforma in un'immagine del contenitore già pronta, che può già essere eseguita nel runtime del contenitore.
./mvnw -X clean package -Dquarkus.container-image.build=true
In effetti questo è tutto, ora puoi eseguire il container con il comando docker run, dopo aver mappato il nostro servizio sulla porta 8080 in modo che sia possibile accedervi.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Dopo che l'istanza del container è stata avviata, non resta che verificare con il comando curl che il nostro servizio sia in esecuzione:
Quindi funziona tutto ed è stato davvero facile e semplice.
Passaggio 2: invia il nostro contenitore al repository di immagini del contenitore
Per ora, l'immagine che abbiamo creato è archiviata localmente nel nostro contenitore di archiviazione locale. Se vogliamo utilizzare questa immagine nel nostro ambiente KUK, dobbiamo inserirla in qualche altro repository. Kubernetes non ha queste funzionalità, quindi utilizzeremo dockerhub. Perché, in primo luogo, è gratis e, in secondo luogo, lo fanno (quasi) tutti.
Anche questo è molto semplice e qui è necessario solo un account dockerhub.
Quindi installiamo dockerhub e inviamo lì la nostra immagine.
Passaggio 3: avviare Kubernetes
Esistono molti modi per mettere insieme una configurazione Kubernetes per eseguire il nostro "Hello World", ma useremo il più semplice, perché siamo persone del genere...
Innanzitutto, avviamo il cluster minikube:
minikube start
Passaggio 4: distribuzione dell'immagine del contenitore
Ora dobbiamo convertire il nostro codice e l'immagine del contenitore nella configurazione di Kubernetes. In altre parole, abbiamo bisogno di un pod e di una definizione di distribuzione che punti alla nostra immagine del contenitore su dockerhub. Uno dei modi più semplici per farlo è eseguire il comando create deploy che punta alla nostra immagine:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Con questo comando, abbiamo detto al nostro COOK di creare una configurazione di distribuzione, che dovrebbe contenere le specifiche del pod per la nostra immagine del contenitore. Questo comando applicherà questa configurazione anche al nostro cluster minikube e creerà una distribuzione che scaricherà la nostra immagine del contenitore ed eseguirà un pod sul cluster.
Passaggio 5: accesso aperto al nostro servizio
Ora che abbiamo un'immagine del contenitore distribuita, è tempo di pensare a come configurare l'accesso esterno a questo servizio Restful, che, di fatto, è programmato nel nostro codice.
Ci sono molti modi qui. Ad esempio, puoi utilizzare il comando esporre per creare automaticamente componenti Kubernetes appropriati come servizi ed endpoint. In realtà, questo è ciò che faremo eseguendo il comando esporre per il nostro oggetto di distribuzione:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Soffermiamoci per un momento sull'opzione "-type" del comando Expose.
Quando esponiamo e creiamo i componenti necessari per eseguire il nostro servizio, dobbiamo, tra le altre cose, essere in grado di connetterci dall'esterno al servizio hello-quarkus che si trova all'interno della nostra rete definita dal software. E parametro Digitare ci consente di creare e connettere elementi come bilanciatori del carico per instradare il traffico verso quella rete.
Ad esempio, scrivere tipo=Bilanciatore del carico, inizializziamo automaticamente il sistema di bilanciamento del carico del cloud pubblico per connetterci al nostro cluster Kubernetes. Questo, ovviamente, è fantastico, ma devi capire che tale configurazione sarà strettamente legata a uno specifico cloud pubblico e sarà più difficile trasferirla tra istanze Kubernetes in ambienti diversi.
Nel nostro esempio tipo=Porta del nodo, cioè la chiamata al nostro servizio passa dall'indirizzo IP del nodo e dal numero di porta. Questa opzione consente di non utilizzare cloud pubblici, ma richiede una serie di passaggi aggiuntivi. Innanzitutto, hai bisogno del tuo bilanciatore del carico, quindi implementeremo il bilanciatore del carico NGINX nel nostro cluster.
Passaggio 6: impostare un bilanciatore del carico
minikube dispone di una serie di funzionalità della piattaforma che semplificano la creazione dei componenti necessari per l'accesso esterno, come i controller di ingresso. Minikube viene fornito in bundle con il controller di ingresso Nginx e tutto ciò che dobbiamo fare è abilitarlo e configurarlo.
minikube addons enable ingress
Ora, con un solo comando, creeremo un controller di ingresso Nginx che funzionerà all'interno del nostro cluster minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Passaggio 7: configurare l'ingresso
Ora dobbiamo configurare il controller di ingresso Nginx per accettare le richieste hello-quarkus.
E infine, dobbiamo applicare questa configurazione.
kubectl apply -f ingress.yml
Dato che stiamo facendo tutto questo sulla nostra macchina, aggiungiamo semplicemente l'indirizzo IP del nostro nodo al file /etc/hosts per indirizzare le richieste http al nostro minikube al bilanciatore di carico NGINX.
192.168.99.100 hello-quarkus.info
Questo è tutto, ora il nostro servizio minikube è disponibile dall'esterno tramite il controller di ingresso Nginx.
Beh, è stato facile, vero? O non così tanto?
Esegui su OpenShift (contenitori Code Ready)
E ora vediamo come viene fatto il tutto su Red Hat OpenShift Container Platform (OCP).
Come nel caso di minikube, scegliamo uno schema con un cluster OpenShift a nodo singolo sotto forma di Code Ready Containers (CRC). Un tempo si chiamava minishift ed era basato sul progetto OpenShift Origin, ma ora è CRC e costruito sulla piattaforma OpenShift Container Platform di Red Hat.
Ecco, scusate, non possiamo fare a meno di dire: "OpenShift è fantastico!"
Inizialmente pensavamo di scrivere che lo sviluppo su OpenShift non è diverso dallo sviluppo su Kubernetes. E in effetti è così. Ma mentre scriviamo questo post, ci siamo ricordati di quanti movimenti inutili devi fare quando non hai OpenShift, e quindi, ancora una volta, è bellissimo. Ci piace che le cose siano semplici e quanto sia facile distribuire ed eseguire il nostro esempio su OpenShift rispetto a minikube è ciò che ci ha ispirato a scrivere questo post.
Esaminiamo il processo e vediamo cosa dobbiamo fare.
Quindi nell'esempio minikube, abbiamo iniziato con Docker… Aspetta, non abbiamo più bisogno di Docker installato sulla macchina.
E non abbiamo bisogno di un git locale.
E Maven non è necessario.
Inoltre, non è necessario creare manualmente un'immagine del contenitore.
E non devi cercare alcun repository di immagini del contenitore.
E non è necessario installare un controller di ingresso.
E non è nemmeno necessario configurare l'ingresso.
Capisci? Per distribuire ed eseguire la nostra applicazione su OpenShift, non è necessario nulla di quanto sopra. E il processo stesso è il seguente.
Passaggio 1: avvio del cluster OpenShift
Utilizziamo Code Ready Containers di Red Hat, che è essenzialmente lo stesso Minikube, ma solo con un cluster Openshift completo a nodo singolo.
crc start
Passaggio 2: creare e distribuire l'applicazione nel cluster OpenShift
È in questa fase che la semplicità e la comodità di OpenShift si manifestano in tutto il suo splendore. Come con tutte le distribuzioni Kubernetes, abbiamo molti modi per eseguire un'applicazione su un cluster. E, come nel caso di KUK, scegliamo appositamente quello più semplice.
OpenShift è sempre stato concepito come piattaforma per la creazione e l'esecuzione di applicazioni containerizzate. La creazione di container è sempre stata parte integrante di questa piattaforma, quindi sono disponibili numerose risorse Kubernetes aggiuntive per le attività corrispondenti.
Utilizzeremo il processo Source 2 Image (S2I) di OpenShift, che prevede diversi modi per prendere il nostro codice sorgente (codice o file binari) e trasformarlo in un'immagine containerizzata che viene eseguita su un cluster OpenShift.
Per questo abbiamo bisogno di due cose:
- Il nostro codice sorgente nel repository git
- Immagine del builder, in base alla quale verrà eseguito l'assemblaggio.
Esistono molte immagini di questo tipo, gestite sia da Red Hat che dalla comunità, e utilizzeremo l'immagine OpenJDK, poiché sto costruendo un'applicazione Java.
Puoi eseguire una build S2I sia dalla console grafica di OpenShift Developer che dalla riga di comando. Utilizzeremo il comando new-app, dicendogli dove trovare l'immagine del builder e il nostro codice sorgente.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
Questo è tutto, la nostra applicazione è stata creata. In tal modo, il processo S2I ha fatto le seguenti cose:
- Creato un build-pod di servizio per tutti i tipi di cose relative alla creazione dell'applicazione.
- Creata una configurazione OpenShift Build.
- Ho scaricato l'immagine del builder nel registro interno della finestra mobile OpenShift.
- Clonato "Hello World" nel repository locale.
- Ho visto che c'era un pom di Maven lì dentro e così ho compilato l'app con Maven.
- Creata una nuova immagine del contenitore contenente l'applicazione Java compilata e inserita questa immagine nel registro del contenitore interno.
- Creata una distribuzione Kubernetes con le specifiche per un pod, un servizio, ecc.
- Avviata la distribuzione dell'immagine del contenitore.
- Pod di build del servizio rimosso.
C'è molto in questo elenco, ma la cosa principale è che l'intera build avviene esclusivamente all'interno di OpenShift, il registro Docker interno è all'interno di OpenShift e il processo di build crea tutti i componenti Kubernetes e li esegue sul cluster.
Se monitori visivamente l'avvio di S2I nella console, puoi vedere come viene avviato il pod di build durante la compilazione.
E ora diamo un'occhiata ai log del builder pod: in primo luogo, lì puoi vedere come Maven fa il suo lavoro e scarica le dipendenze per costruire la nostra applicazione Java.
Una volta completata la build di Maven, viene avviata la build dell'immagine del contenitore, quindi questa immagine creata viene inviata al repository interno.
Tutto, il processo di assemblaggio è completato. Ora assicuriamoci che i pod e i servizi della nostra applicazione siano avviati nel cluster.
oc get service
È tutto. E c'è solo una squadra. Tutto quello che dobbiamo fare è esporre questo servizio all'accesso esterno.
Passaggio 3: rendere il servizio accessibile dall'esterno
Come nel caso di KUK, anche sulla piattaforma OpenShift il nostro “Hello World” necessita di un router per indirizzare il traffico esterno verso un servizio interno al cluster. In OpenShift questo lo rende molto semplice. Innanzitutto, il componente di routing HAProxy è installato nel cluster per impostazione predefinita (può essere modificato nello stesso NGINX). In secondo luogo, ci sono risorse speciali e altamente configurabili chiamate Routes, che ricordano gli oggetti Ingress del buon vecchio Kubernetes (in effetti, le Routes di OpenShift hanno fortemente influenzato la progettazione degli oggetti Ingress, che ora possono essere utilizzati in OpenShift), ma per il nostro "Hello World", e in quasi tutti gli altri casi ci basta il percorso standard senza ulteriori configurazioni.
Per creare un FQDN instradabile per "Hello World" (sì, OpenShiift ha il proprio DNS per l'instradamento in base ai nomi dei servizi), esponiamo semplicemente il nostro servizio:
oc expose service quarkus-hello-world
Se guardi il percorso appena creato, puoi trovare lì l'FQDN e altre informazioni sul routing:
oc get route
E infine, accediamo al nostro servizio dal browser:
Ma ora era davvero facile!
Amiamo Kubernetes e tutto ciò che questa tecnologia permette di fare, e amiamo anche la semplicità e la leggerezza. Kubernetes è stato progettato per rendere i contenitori distribuiti e scalabili incredibilmente facili da utilizzare, ma la sua semplicità non è più sufficiente per portare le applicazioni in produzione oggi. Ed è qui che entra in gioco OpenShift, che è al passo con i tempi e propone Kubernetes, focalizzato soprattutto sullo sviluppatore. Sono stati investiti molti sforzi per personalizzare la piattaforma OpenShift appositamente per lo sviluppatore, inclusa la creazione di strumenti come S2I, ODI, portale per sviluppatori, OpenShift Operator Framework, integrazione IDE, cataloghi per sviluppatori, integrazione Helm, monitoraggio e molti altri.
Speriamo che questo articolo sia stato interessante e utile per te. E sul portale puoi trovare risorse aggiuntive, materiali e altre cose utili per lo sviluppo sulla piattaforma OpenShift .
Fonte: habr.com