Questo post è stato scritto perché i nostri collaboratori hanno avuto molte conversazioni con i clienti riguardo allo sviluppo di applicazioni su Kubernetes e alle specifiche di tale sviluppo su OpenShift.
Di solito iniziamo con l'affermazione che Kubernetes è semplicemente Kubernetes, mentre OpenShift è già una piattaforma Kubernetes, come Microsoft AKS o Amazon EKS. Ognuna di queste piattaforme ha i propri vantaggi, orientati a un diverso pubblico. E da lì la conversazione si sposta a confrontare i punti di forza e di debolezza delle piattaforme specifiche.
In generale, pensavamo di scrivere questo post con una conclusione del tipo «Ascoltate, non importa dove eseguire il codice, su OpenShift o su AKS, su EKS, su un Kubernetes personalizzato, insomma su qualsiasi Kubernetes (per brevità lo chiameremo KUK) – è davvero semplice, sia da una parte che dall'altra».
Poi avevamo in programma di prendere il più semplice «Hello World» e, utilizzando il suo esempio, mostrare cosa c'è di comune e quali sono le differenze tra KUK e Red Hat OpenShift Container Platform (di seguito, OCP o semplicemente OpenShift).
Tuttavia, durante la scrittura di questo post, abbiamo capito che ci siamo abituati così tanto a usare OpenShift che non ci rendiamo nemmeno conto di quanto sia cresciuto e trasformato in una piattaforma sorprendente, diventando molto più di un semplice distribuzione di Kubernetes. Ci siamo abituati a considerare la maturità e la semplicità di OpenShift come scontate, trascurando la sua magnificenza.
In sintesi, è giunto il momento di una risoluzione fattiva, e ora confronteremo passo dopo passo il nostro «Hello World» su KUK e su OpenShift, e lo faremo in modo il più obiettivo possibile (a parte quando esprimiamo qualche opinione personale sull'argomento). Se siete interessati a un'opinione puramente soggettiva su questo tema, potete leggerla . In questo post ci atterremo ai fatti e solo ai fatti.
Cluster
Quindi, per il nostro «Hello World» abbiamo bisogno di cluster. Diciamo subito «no» a qualsiasi cloud pubblico per non pagare per server, registri, reti, traffico dati, ecc. Pertanto, scegliamo un semplice cluster singolo su (per KUK) e (per il cluster OpenShift). Entrambi questi metodi sono davvero semplici da installare, ma richiederanno molte risorse sul tuo laptop.
Costruzione su KUK
Dunque, andiamo.
Passo 1 – costruiamo la nostra immagine container
Inizierò distribuendo il nostro «Hello World» su minikube. Per farlo, avremo bisogno di:
- 1. Docker installato.
- 2. Git installato.
- 3. Maven installato (in realtà, in questo progetto si utilizza il binario mvnw, quindi si può fare anche a meno).
- 4. L'effettivo codice sorgente, cioè il clone del repository
Per prima cosa, dobbiamo creare un progetto Quarkus. Non spaventatevi se non avete mai lavorato con il sito Quarkus.io – è facile. Basta scegliere i componenti che si desidera utilizzare nel progetto (RestEasy, Hibernate, Amazon SQS, Camel, ecc.), e poi Quarkus si occuperà da solo di configurare l'archetipo maven e caricare tutto su github. Quindi, letteralmente un clic del mouse – ed è fatto. È per questo che amiamo Quarkus.
Il modo più semplice per costruire il nostro «Hello World» in un'immagine container è utilizzare le estensioni quarkus-maven per Docker, che faranno tutto il lavoro necessario. Con l'introduzione di Quarkus, è diventato davvero facile e semplice: aggiungete l'estensione container-image-docker e potete creare immagini usando i comandi maven.
./mvnw quarkus:add-extension -Dextensions="container-image-docker"
E infine, eseguiamo la costruzione della nostra immagine usando Maven. In questo modo il nostro codice sorgente si trasformerà in un'immagine container pronta, che può già essere eseguita in un ambiente di esecuzione di container.
./mvnw -X clean package -Dquarkus.container-image.build=true
Questo è tutto, ora possiamo avviare il container con il comando docker run, mappando il nostro servizio sulla porta 8080, in modo da poterci accedere.
docker run -i --rm -p 8080:8080 gcolman/quarkus-hello-world
Dopo che l'istanza del container è stata avviata, resta solo da controllare con il comando curl che il nostro servizio funziona:
Quindi, tutto funziona e è stata davvero facile e semplice.
Passo 2 – inviamo il nostro container al repository delle immagini di container
Fino ad ora, l'immagine che abbiamo creato viene conservata localmente, nel nostro repository di container locale. Se vogliamo utilizzare questa immagine nel nostro ambiente KUK, dobbiamo caricarla in un altro repository. In Kubernetes non ci sono tali funzioni, quindi utilizzeremo dockerhub. Perché, primo, è gratuito, e secondo, (quasi) tutti lo fanno.
Anche questo è molto semplice, serve solo un account su dockerhub.
Quindi, ci registriamo su dockerhub e carichiamo lì la nostra immagine.
Passo 3 – avviamo Kubernetes
Ci sono molti modi per costruire la configurazione di kubernetes per eseguire il nostro «Hello World», ma useremo il più semplice di tutti, dato che siamo così...
Per prima cosa avviamo il cluster minikube:
minikube start
Passo 4 – distribuiamo la nostra immagine container
Ora dobbiamo convertire il nostro codice e l'immagine del container nelle configurazioni di Kubernetes. In altre parole, abbiamo bisogno di una definizione per il pod e il deployment che faccia riferimento alla nostra immagine del container su Docker Hub. Uno dei modi più semplici per farlo è eseguire il comando create deployment, specificando la nostra immagine:
kubectl create deployment hello-quarkus --image=gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Con questo comando abbiamo detto a Kubernetes di creare una configurazione di deployment, che dovrebbe contenere la specifica del pod per la nostra immagine del container. Questo comando applicherà anche questa configurazione al nostro cluster minikube e creerà un deployment che scaricherà la nostra immagine del container e avvierà un pod nel cluster.
Passo 5 – apriamo l'accesso al nostro servizio
Ora che abbiamo il nostro container distribuito, è tempo di pensare a come configurare l'accesso esterno a questo servizio RESTful, che in effetti è programmato nel nostro codice.
Ci sono molti modi per farlo. Ad esempio, possiamo utilizzare il comando expose per creare automaticamente i componenti Kubernetes corrispondenti, come services ed endpoints. Infatti, è esattamente ciò che faremo, eseguendo il comando expose per il nostro oggetto deployment:
kubectl expose deployment hello-quarkus --type=NodePort --port=8080
Fermiamoci un attimo sull'opzione "--type" del comando expose.
Quando facciamo expose e creiamo i componenti necessari per eseguire il nostro servizio, abbiamo bisogno che dall'esterno sia possibile connettersi al servizio hello-quarkus, che si trova all'interno della nostra rete programmabile. E il parametro type ci permette di creare e connettere elementi come i load balancer, per instradare il traffico a questa rete.
Ad esempio, specificando --type=LoadBalancer, inizializziamo automaticamente un load balancer nel cloud pubblico per connetterci al nostro cluster Kubernetes. Questo è ovviamente fantastico, ma dobbiamo capire che tale configurazione sarà legata a un cloud pubblico specifico e sarà più difficile da trasferire tra istanze Kubernetes in ambienti diversi.
Nel nostro esempio --type=NodePort, cioè l'accesso al nostro servizio avviene tramite l'indirizzo IP del nodo e il numero di porta. Questa opzione consente di non utilizzare alcun cloud pubblico, ma richiede alcuni passaggi aggiuntivi. In primo luogo, abbiamo bisogno di un proprio load balancer, quindi installeremo un load balancer NGINX nel nostro cluster.
Passo 6 – installiamo il load balancer
Minikube ha diverse funzioni di piattaforma che semplificano la creazione dei componenti necessari per l'accesso esterno, come gli ingress controller. Minikube include un ingress controller NGINX, e ci rimane solo da attivarlo e configurarlo.
minikube addons enable ingress
Ora, con un solo comando, creiamo l'ingress controller NGINX che funzionerà all'interno del nostro cluster minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Passo 7 – configuriamo l'ingress
Ora dobbiamo configurare l'ingress controller NGINX affinché gestisca le richieste di hello-quarkus.
E infine, dobbiamo applicare questa configurazione.
kubectl apply -f ingress.yml
Poiché stiamo facendo tutto questo sul nostro computer, aggiungiamo semplicemente l'indirizzo IP del nostro nodo nel file /etc/hosts, per indirizzare le richieste http al nostro minikube sul load balancer NGINX.
192.168.99.100 hello-quarkus.info
Ecco fatto, ora il nostro servizio minikube è accessibile dall'esterno attraverso l'ingress controller NGINX.
Bene, è stato facile, vero? O no?
Esecuzione su OpenShift (Code Ready Containers)
Ora vediamo come si fa tutto questo sulla 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). In passato si chiamava minishift ed era basato sul progetto OpenShift Origin, ora è CRC ed è costruito sulla OpenShift Container Platform di Red Hat.
Qui non possiamo trattenere il nostro entusiasmo e dire: "OpenShift è fantastico!"
Inizialmente pensavamo di scrivere che sviluppare su OpenShift non è diverso dallo sviluppare su Kubernetes. E in effetti è così. Ma durante la scrittura di questo post ci siamo resi conto di quanti passaggi inutili si devono compiere quando non si ha OpenShift, e quindi, ribadiamo, è fantastico. Ci piace quando le cose sono facili, e il modo in cui il nostro esempio viene distribuito e avviato su OpenShift, rispetto a minikube, ci ha spinto a scrivere questo post.
Facciamo una panoramica del processo e vediamo cosa dobbiamo fare.
Quindi, nell'esempio con minikube, iniziavamo con Docker... Aspetta, non abbiamo più bisogno di avere Docker installato sulla macchina.
E non ci serve nemmeno git locale.
E non ci serve Maven.
E non dobbiamo creare manualmente l'immagine del container.
E non dobbiamo cercare alcun repository di immagini del container.
E non dobbiamo installare l'ingress controller.
E non dobbiamo nemmeno configurare l'ingress.
Hai capito, vero? Per avviare e lanciare la nostra applicazione su OpenShift, non è necessario nulla di quanto elencato sopra. E il processo appare come segue.
Passo 1 – Avviamo il nostro cluster OpenShift
Utilizziamo Code Ready Containers di Red Hat, che è fondamentalmente lo stesso di Minikube, ma con un cluster OpenShift mononodale completo.
crc start
Passo 2 – Eseguiamo la build e il deployment dell'applicazione nel cluster OpenShift
È proprio in questo passaggio che la semplicità e la comodità di OpenShift si manifestano in tutto il loro splendore. Come in tutte le distribuzioni di Kubernetes, abbiamo molti modi per avviare un'applicazione nel cluster. E, come nel caso di K8s, scegliamo specificamente il metodo più semplice.
OpenShift è sempre stato concepito come una piattaforma per la creazione e l'esecuzione di applicazioni containerizzate. La creazione dei container è sempre stata parte integrante di questa piattaforma, quindi qui ci sono molte risorse Kubernetes aggiuntive per le relative necessità.
Utilizzeremo il processo Source to Image (S2I) di OpenShift, che offre diversi modi per prendere il nostro sorgente (codice o file binari) e trasformarlo in un'immagine del container eseguibile nel cluster OpenShift.
Per questo avremo bisogno di due cose:
- Il nostro codice sorgente in un repository git
- Un'immagine builder su cui verrà effettuata la build.
Esistono molte di queste immagini, sostenute sia da Red Hat che dalla comunità, e useremo l'immagine OpenJDK visto che sto costruendo un'app Java.
È possibile avviare una build S2I sia dalla console grafica di OpenShift Developer che dalla riga di comando. Utilizzeremo il comando new-app, indicandogli da dove prendere l'immagine 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
Ecco fatto, la nostra applicazione è stata creata. Nel processo S2I sono state eseguite le seguenti operazioni:
- È stato creato un pod di build temporaneo per gestire le cose legate alla build dell'applicazione.
- È stata creata una configurazione OpenShift Build.
- È stata scaricata l'immagine builder nel registro docker interno di OpenShift.
- È stato clonato 'Hello World' nel repository locale.
- Ha visto che c'era un pom di maven, e quindi ha compilato l'applicazione usando maven.
- È stata creata una nuova immagine container contenente l'app Java compilata, e questa immagine è stata depositata nel registro interno dei container.
- È stata creata una Kubernetes Deployment con le specifiche del pod, del servizio, ecc.
- È stato avviato il deployment dell'immagine container.
- È stato rimosso il pod di build temporaneo.
Ci sono molte cose in questo elenco, ma ciò che è importante è che l'intero processo di build avviene esclusivamente all'interno di OpenShift, il registro Docker interno si trova all'interno di OpenShift e il processo di build crea tutti i componenti Kubernetes e li lancia nel cluster.
Se si monitora visivamente l'avvio di S2I nella console, si può vedere come, durante la build, venga avviato il pod di build.
Ora diamo un'occhiata ai log del pod builder: prima di tutto, si vede come maven svolge il suo lavoro e scarica le dipendenze per la build della nostra applicazione Java.
Dopo che la build di maven è completata, inizia la costruzione dell'immagine container, e poi questa immagine costruita viene inviata al repository interno.
Ecco, il processo di build è completato. Ora assicuriamoci che i pod e i servizi della nostra applicazione siano avviati nel cluster.
oc get service
Ecco fatto. E solo un comando. Non ci resta che esporre questo servizio per accedervi dall'esterno.
Passo 3 – esponiamo il servizio per accesso esterno
Come nel caso di K8s, anche per il nostro 'Hello World' sulla piattaforma OpenShift è necessario un router per indirizzare il traffico esterno al servizio all'interno del cluster. OpenShift lo fa in modo molto semplice. In primo luogo, nel cluster è già presente un componente di routing HAProxy (che può essere sostituito con NGINX). In secondo luogo, ci sono risorse speciali con ampie possibilità di configurazione chiamate Routes, che ricordano gli oggetti Ingress nel vecchio buono Kubernetes (in effetti, le Route di OpenShift hanno influenzato fortemente il design degli oggetti Ingress che ora possono essere utilizzati anche in OpenShift), ma per il nostro 'Hello World', e per quasi tutti gli altri casi, ci basta la Route standard senza ulteriore configurazione.
Per creare un FQDN instradabile per 'Hello World' (sì, in OpenShift c'è il proprio DNS per l'instradamento tramite i nomi dei servizi), eseguiremo semplicemente l'expose per il nostro servizio:
oc expose service quarkus-hello-world
Se guardiamo la Route appena creata, possiamo trovare il FQDN e altre informazioni sull'instradamento:
oc get route
E infine, accediamo al nostro servizio dal browser:
Ecco, ora è stato davvero facile!
Amiamo Kubernetes e tutto ciò che questa tecnologia consente, oltre a noi stessi amiamo la semplicità e la facilità. Kubernetes è stato creato per semplificare enormemente la gestione di contenitori distribuiti e scalabili, ma la sua semplicità oggi non basta più per l'implementazione delle applicazioni. Qui entra in gioco OpenShift, che è al passo con i tempi e offre un Kubernetes principalmente orientato agli sviluppatori. Sono stati investiti molti sforzi per adattare la piattaforma OpenShift specificamente per gli sviluppatori, inclusa la creazione di strumenti come S2I, ODI, Developer Portal, OpenShift Operator Framework, integrazione con IDE, Cataloghi per Sviluppatori, integrazione con Helm, monitoraggio e molti altri.
Speriamo che questo articolo sia stato interessante e utile per voi. Potete trovare ulteriori risorse, materiali e altre cose utili per lo sviluppo sulla piattaforma OpenShift nel portale .
Fonte: habr.com
