{"id":97254,"date":"2020-10-17T02:42:32","date_gmt":"2020-10-17T00:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe"},"modified":"2020-10-17T02:42:32","modified_gmt":"2020-10-17T00:42:32","slug":"prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Mi dispiace, OpenShift, non ti abbiamo apprezzato abbastanza e ti abbiamo dato per scontato","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Questo post \u00e8 scritto perch\u00e9 i nostri collaboratori hanno avuto molte conversazioni con i clienti sullo sviluppo di applicazioni su Kubernetes e sulle specificit\u00e0 di tale sviluppo su OpenShift.<\/p>\n

\"Mi
\n
\nDi solito iniziamo con la tesi che Kubernetes \u00e8 semplicemente Kubernetes, mentre OpenShift \u00e8 gi\u00e0 una piattaforma Kubernetes, come Microsoft AKS o Amazon EKS. Ognuna di queste piattaforme ha i propri vantaggi, orientati a un pubblico specifico. Da l\u00ec, la conversazione si sposta su un confronto tra i punti di forza e di debolezza delle diverse piattaforme.
\n<\/a><\/noindex>
\nIn generale, volevamo scrivere questo post con la conclusione del tipo \u00abAscoltate, non importa dove eseguire il codice, su OpenShift o su AKS, su EKS, su qualche Kubernetes personalizzato, s\u00ec, su qualsiasi Kubernetes (per brevit\u00e0 lo chiameremo KUK)<\/i> \u2013 \u00e8 davvero semplice, sia l\u00ec che l\u00e0\u00bb.<\/p>\n

Poi avevamo pianificato di prendere il semplice \u00abHello World\u00bb e con il suo esempio mostrare cosa hanno in comune e quali sono le differenze tra KUK e Red Hat OpenShift Container Platform (d'ora in poi, OCP o semplicemente OpenShift).<\/p>\n

Tuttavia, durante la scrittura di questo post, ci siamo resi conto che ci siamo abituati talmente tanto a utilizzare OpenShift che non ci rendiamo conto di come sia cresciuto e si sia trasformato in una piattaforma straordinaria, diventando molto pi\u00f9 di un semplice distributore di Kubernetes. Abbiamo dato per scontata la maturit\u00e0 e la semplicit\u00e0 di OpenShift, trascurando la sua grandezza.<\/p>\n

In generale, \u00e8 giunto il momento di un sincero ravvedimento, e ora confronteremo passo passo l'implementazione del nostro \u00abHello World\u00bb su KUK e su OpenShift, e lo faremo nel modo pi\u00f9 oggettivo possibile (tranne per il fatto di mostrare talvolta un'opinione personale sull'argomento). Se siete interessati a un'opinione puramente soggettiva su questo argomento, potete leggerla qui (EN)<\/a><\/noindex>. In questo post ci atteneremo ai fatti e solo ai fatti.<\/p>\n

Cluster<\/h3>\n

\nQuindi, per il nostro \u00abHello World\u00bb abbiamo bisogno di cluster. Diremo subito \u00abno\u00bb a qualsiasi cloud pubblico, per non pagare server, registry, rete, trasferimenti di dati, ecc. Pertanto, scegliamo un semplice cluster a nodo singolo su Minikube<\/a><\/noindex> (per KUK) e Code Ready Containers<\/a><\/noindex> (per il cluster OpenShift). Entrambe queste opzioni sono davvero semplici da installare, ma richiederanno abbastanza risorse sul vostro laptop.<\/p>\n

\"Mi<\/p>\n

Costruzione su KUK<\/h3>\n

\nBene, iniziamo.<\/p>\n

Passo 1 \u2013 costruiamo la nostra immagine del contenitore<\/h4>\n

\nIniziamo con il distribuire il nostro \u00abHello World\u00bb su minikube. Per questo avremo bisogno di:<\/p>\n

    \n
  1. 1. Docker installato.<\/li>\n
  2. 2. Git installato.<\/li>\n
  3. 3. Maven installato (in realt\u00e0 in questo progetto si utilizza il binario mvnw, quindi si pu\u00f2 fare a meno di questo).<\/li>\n
  4. 4. Il sorgente vero e proprio, ovvero una copia del repository github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nPer prima cosa dobbiamo creare un progetto Quarkus. Non preoccupatevi se non avete mai lavorato con il sito Quarkus.io: \u00e8 facile. Basta scegliere i componenti che si desidera utilizzare nel progetto (RestEasy, Hibernate, Amazon SQS, Camel, ecc.), e poi Quarkus configurer\u00e0 da solo, senza alcun vostro intervento, l\u2019archetipo Maven e pubblicher\u00e0 tutto su GitHub. In altre parole, basta un clic del mouse, ed \u00e8 fatto. Questo \u00e8 ci\u00f2 che amiamo di Quarkus.<\/p>\n

    \"Mi<\/p>\n

    Il modo pi\u00f9 semplice per costruire il nostro 'Hello World' in un'immagine container \u00e8 utilizzare le estensioni quarkus-maven per Docker, che faranno tutto il lavoro necessario. Con l'arrivo di Quarkus, questo \u00e8 diventato davvero facile e semplice: aggiungete l'estensione container-image-docker e potrete creare le immagini con i comandi Maven.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nE infine, eseguiamo la costruzione della nostra immagine utilizzando Maven. Di conseguenza, il nostro codice sorgente si trasforma in un'immagine container gi\u00e0 pronta, che pu\u00f2 essere eseguita nell'ambiente di esecuzione del container.<\/p>\n
    \"Mi<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nEcco, quindi, tutto. Ora potete avviare il container con il comando docker run, mappando il nostro servizio sulla porta 8080, in modo che possa essere raggiunto.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Mi<\/p>\n
    Dopo che l'istanza del container \u00e8 stata avviata, resta solo da controllare con il comando curl che il nostro servizio funzioni:<\/p>\n
    \"Mi<\/p>\n
    Quindi, tutto funziona, ed \u00e8 stato davvero facile e semplice.<\/p>\n
    Passo 2 \u2013 inviamo il nostro container al repository di immagini container<\/h4>\n
    \nFinora, l\u2019immagine che abbiamo creato \u00e8 memorizzata localmente, nel nostro archivio container locale. Se vogliamo utilizzare quest\u2019immagine nel nostro ambiente Kubernetes, dobbiamo conservarla in un altro repository. In Kubernetes non ci sono queste funzioni, quindi utilizzeremo Docker Hub. Perch\u00e9, prima di tutto, \u00e8 gratuito, e in secondo luogo, (quasi) tutti lo fanno.<\/p>\n
    \u00c8 anche molto semplice, ed \u00e8 necessario solo avere un account su Docker Hub.<\/p>\n
    Quindi, facciamo il login su Docker Hub e inviamo la nostra immagine.<\/p>\n
    \"Mi<\/p>\n
    Passo 3 \u2013 avviamo Kubernetes<\/h4>\n
    \nCi sono molti modi per assemblare la configurazione Kubernetes per eseguire il nostro 'Hello World', ma useremo il metodo pi\u00f9 semplice, proprio perch\u00e9 siamo cos\u00ec...<\/p>\n
    Per prima cosa, avviamo il cluster minikube:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Passaggio 4 \u2013 distribuiamo la nostra immagine del contenitore<\/h4>\n
    \nOra dobbiamo convertire il nostro codice e l'immagine del contenitore nelle configurazioni di kubernetes. In altre parole, abbiamo bisogno di una definizione di pod e deployment che faccia riferimento alla nostra immagine del contenitore su dockerhub. Uno dei modi pi\u00f9 semplici per farlo \u00e8 eseguire il comando create deployment, specificando la nostra immagine:<\/p>\n
    \"Mi<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nCon questo comando abbiamo detto al nostro K8S di creare una configurazione di deployment che deve contenere la specifica del pod per la nostra immagine del contenitore. Questo comando applicher\u00e0 anche questa configurazione al nostro cluster minikube, e creer\u00e0 un deployment che scaricher\u00e0 la nostra immagine del contenitore e avvier\u00e0 un pod nel cluster.<\/p>\n
    Passaggio 5 \u2013 apriamo l'accesso al nostro servizio<\/h4>\n
    \nOra che abbiamo l'immagine del contenitore distribuita, \u00e8 tempo di pensare a come configurare l'accesso esterno a questo servizio Restful, che \u00e8 effettivamente programmato nel nostro codice.<\/p>\n
    Ci sono molti modi per farlo. Ad esempio, possiamo utilizzare il comando expose per creare automaticamente i componenti Kubernetes corrispondenti, come services e endpoints. Infatti, questo \u00e8 esattamente ci\u00f2 che faremo eseguendo il comando expose per il nostro oggetto di deployment:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nFermiamoci un attimo sull'opzione \"--type\" del comando expose.<\/p>\n
    Quando facciamo expose e creiamo i componenti necessari per eseguire il nostro servizio, dobbiamo assicurarci, tra le altre cose, che dall'esterno sia possibile connettersi al servizio hello-quarkus, che si trova all'interno della nostra rete programmaticamente definita. E il parametro type<\/b> ci consente di creare e collegare elementi come bilanciatori di carico, per instradare il traffico in questa rete.<\/p>\n
    Ad esempio, specificando type=LoadBalancer<\/b>, iniziamo automaticamente un bilanciatore di carico nel cloud pubblico, per connetterci al nostro cluster Kubernetes. Questo, ovviamente, \u00e8 fantastico, ma bisogna capire che questa configurazione sar\u00e0 fortemente legata a un cloud pubblico specifico e sar\u00e0 pi\u00f9 difficile trasferirla tra gli istanze Kubernetes in ambienti diversi.<\/p>\n
    Nel nostro esempio type=NodePort<\/b>, cio\u00e8 il riferimento 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 una serie di passaggi aggiuntivi. Innanzitutto, \u00e8 necessario un proprio bilanciatore di carico, quindi implementeremo nel nostro cluster il bilanciatore di carico NGINX.<\/p>\n
    Passo 6 \u2013 installiamo il bilanciatore di carico<\/h4>\n
    \nMinikube ha una serie di funzionalit\u00e0 di piattaforma che semplificano la creazione dei componenti necessari per l'accesso esterno, come i controller ingress. Minikube viene fornito con il controller ingress Nginx, e non ci resta che abilitarlo e configurarlo.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nOra, con un solo comando, creer\u00f2 il controller ingress Nginx, che funzioner\u00e0 all'interno del nostro cluster minikube:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 In esecuzione 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Passo 7 \u2013 Configuriamo l'ingress<\/h4>\n
    \nOra dobbiamo configurare il controller ingress Nginx affinch\u00e9 elabori le richieste hello-quarkus.<\/p>\n
    \"Mi<\/p>\n
    \"Mi<\/p>\n
    E, infine, dobbiamo applicare questa configurazione.<\/p>\n
    \"Mi<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Mi<\/p>\n
    Poich\u00e9 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 bilanciatore di carico NGINX.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nOra, il nostro servizio minikube \u00e8 accessibile dall'esterno tramite il controller ingress Nginx.<\/p>\n
    \"Mi<\/p>\n
    Bene, \u00e8 stato facile, vero? O non tanto?<\/h3>\n
    \"Mi<\/p>\n
    Avvio su OpenShift (Code Ready Containers)<\/h3>\n
    \nOra vediamo come si fa tutto questo sulla Red Hat OpenShift Container Platform (OCP).<\/p>\n
    Come nel caso di minikube, scegliamo uno schema con cluster OpenShift a nodo singolo sotto forma di Code Ready Containers (CRC). In precedenza era chiamato minishift e si basava sul progetto OpenShift Origin, ora \u00e8 CRC ed \u00e8 costruito sulla piattaforma OpenShift Container di Red Hat.<\/p>\n
    Qui, scusate, non possiamo esprimerci senza dire: \u00abOpenShift \u00e8 fantastico!\u00bb<\/p>\n
    Inizialmente pensavamo di scrivere che lo sviluppo su OpenShift non differisce dallo sviluppo su Kubernetes. E in effetti \u00e8 cos\u00ec. Ma mentre scrivevamo questo post, ci siamo ricordati di quanti ulteriori passaggi si devono compiere quando non si utilizza OpenShift, e per questo, ripetiamo, \u00e8 fantastico. Ci piace quando tutto \u00e8 fatto facilmente, e il modo in cui il nostro esempio si distribuisce e si avvia su OpenShift, rispetto a minikube, ci ha spinto a scrivere questo post.<\/p>\n
    Facciamo un rapido riepilogo del processo e vediamo cosa sar\u00e0 necessario fare.<\/p>\n
    Quindi, nell'esempio con minikube, abbiamo iniziato con Docker... Aspetta, non abbiamo pi\u00f9 bisogno che Docker sia installato sulla macchina.<\/p>\n
    E non abbiamo bisogno di git locale.
    \nE nemmeno di Maven.
    \nE non \u00e8 necessario creare manualmente un'immagine del contenitore.
    \nE non \u00e8 necessario cercare un repository di immagini dei contenitori.
    \nE non \u00e8 necessario installare un ingress-controller.
    \nE non \u00e8 necessario configurare l'ingress.<\/b><\/p>\n
    Hai capito, giusto? Per distribuire e avviare la nostra applicazione su OpenShift, non \u00e8 necessario nulla di quanto elencato sopra. E il processo avviene come segue.<\/p>\n
    Passo 1 \u2013 Avviamo il nostro cluster OpenShift<\/h4>\n
    \nUtilizziamo Code Ready Containers di Red Hat, che \u00e8 essenzialmente lo stesso di Minikube, ma con un cluster OpenShift a nodi singoli completamente funzionale.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Passo 2 \u2013 Costruiamo e distribuiamo l'applicazione nel cluster OpenShift<\/h4>\n
    \n\u00c8 proprio in questo passo che la semplicit\u00e0 e la comodit\u00e0 di OpenShift si manifestano in tutto il loro splendore. Come in tutte le distribuzioni di Kubernetes, abbiamo molte opzioni per avviare un'applicazione nel cluster. E, come nel caso di KUK, scegliamo deliberatamente il modo pi\u00f9 semplice.<\/p>\n
    OpenShift \u00e8 sempre stato progettato come una piattaforma per creare ed eseguire applicazioni contenitore. La creazione di contenitori \u00e8 sempre stata una parte integrante di questa piattaforma, quindi ci sono molti risorse Kubernetes aggiuntive per i compiti correlati.<\/p>\n
    Utilizzeremo il processo Source 2 Image (S2I) di OpenShift, che presenta diversi modi per prendere la nostra sorgente (codice o file binari) e trasformarla in un'immagine del contenitore, eseguibile nel cluster OpenShift.<\/p>\n
    A tal fine, avremo bisogno di due cose:<\/p>\n