{"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 stato scritto perch\u00e9 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.<\/p>\n

\"Mi
\n
\nDi solito iniziamo con l'affermazione 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 diverso pubblico. E da l\u00ec la conversazione si sposta a confrontare i punti di forza e di debolezza delle piattaforme specifiche.
\n<\/a><\/noindex>
\nIn generale, pensavamo di scrivere questo post con una conclusione del tipo \u00abAscoltate, non importa dove eseguire il codice, su OpenShift o su AKS, su EKS, su un Kubernetes personalizzato, insomma su qualsiasi Kubernetes (per brevit\u00e0 lo chiameremo KUK)<\/i> \u2013 \u00e8 davvero semplice, sia da una parte che dall'altra\u00bb.<\/p>\n

Poi avevamo in programma di prendere il pi\u00f9 semplice \u00abHello World\u00bb e, utilizzando il suo esempio, mostrare cosa c'\u00e8 di comune e quali sono le differenze tra KUK e Red Hat OpenShift Container Platform (di seguito, OCP o semplicemente OpenShift).<\/p>\n

Tuttavia, durante la scrittura di questo post, abbiamo capito che ci siamo abituati cos\u00ec tanto a usare OpenShift che non ci rendiamo nemmeno conto di quanto sia cresciuto e trasformato in una piattaforma sorprendente, diventando molto pi\u00f9 di un semplice distribuzione di Kubernetes. Ci siamo abituati a considerare la maturit\u00e0 e la semplicit\u00e0 di OpenShift come scontate, trascurando la sua magnificenza.<\/p>\n

In sintesi, \u00e8 giunto il momento di una risoluzione fattiva, e ora confronteremo passo dopo passo il nostro \u00abHello World\u00bb su KUK e su OpenShift, e lo faremo in modo il pi\u00f9 obiettivo possibile (a parte quando esprimiamo qualche opinione personale sull'argomento). Se siete interessati a un'opinione puramente soggettiva su questo tema, potete leggerla qui (EN)<\/a><\/noindex>. In questo post ci atterremo ai fatti e solo ai fatti.<\/p>\n

Cluster<\/h3>\n

\nQuindi, per il nostro \u00abHello World\u00bb abbiamo bisogno di cluster. Diciamo subito \u00abno\u00bb a qualsiasi cloud pubblico per non pagare per server, registri, reti, traffico dati, ecc. Pertanto, scegliamo un semplice cluster singolo su Minikube<\/a><\/noindex> (per KUK) e Code Ready Containers<\/a><\/noindex> (per il cluster OpenShift). Entrambi questi metodi sono davvero semplici da installare, ma richiederanno molte risorse sul tuo laptop.<\/p>\n

\"Mi<\/p>\n

Costruzione su KUK<\/h3>\n

\nDunque, andiamo.<\/p>\n

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

\nInizier\u00f2 distribuendo il nostro \u00abHello World\u00bb su minikube. Per farlo, 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 anche a meno).<\/li>\n
  4. 4. L'effettivo codice sorgente, cio\u00e8 il clone del repository github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nPer prima cosa, dobbiamo creare un progetto Quarkus. Non spaventatevi se non avete mai lavorato con il sito Quarkus.io \u2013 \u00e8 facile. Basta scegliere i componenti che si desidera utilizzare nel progetto (RestEasy, Hibernate, Amazon SQS, Camel, ecc.), e poi Quarkus si occuper\u00e0 da solo di configurare l'archetipo maven e caricare tutto su github. Quindi, letteralmente un clic del mouse \u2013 ed \u00e8 fatto. \u00c8 per questo che amiamo Quarkus.<\/p>\n

    \"Mi<\/p>\n

    Il modo pi\u00f9 semplice per costruire il nostro \u00abHello World\u00bb in un'immagine container \u00e8 utilizzare le estensioni quarkus-maven per Docker, che faranno tutto il lavoro necessario. Con l'introduzione di Quarkus, \u00e8 diventato davvero facile e semplice: aggiungete l'estensione container-image-docker e potete creare immagini usando 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 usando Maven. In questo modo il nostro codice sorgente si trasformer\u00e0 in un'immagine container pronta, che pu\u00f2 gi\u00e0 essere eseguita in un ambiente di esecuzione di container.<\/p>\n
    \"Mi<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nQuesto \u00e8 tutto, ora possiamo avviare il container con il comando docker run, mappando il nostro servizio sulla porta 8080, in modo da poterci accedere.<\/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 funziona:<\/p>\n
    \"Mi<\/p>\n
    Quindi, tutto funziona e \u00e8 stata davvero facile e semplice.<\/p>\n
    Passo 2 \u2013 inviamo il nostro container al repository delle immagini di container<\/h4>\n
    \nFino 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\u00e9, primo, \u00e8 gratuito, e secondo, (quasi) tutti lo fanno.<\/p>\n
    Anche questo \u00e8 molto semplice, serve solo un account su dockerhub.<\/p>\n
    Quindi, ci registriamo su dockerhub e carichiamo l\u00ec la nostra immagine.<\/p>\n
    \"Mi<\/p>\n
    Passo 3 \u2013 avviamo Kubernetes<\/h4>\n
    \nCi sono molti modi per costruire la configurazione di kubernetes per eseguire il nostro \u00abHello World\u00bb, ma useremo il pi\u00f9 semplice di tutti, dato che siamo cos\u00ec...<\/p>\n
    Per prima cosa avviamo il cluster minikube:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Passo 4 \u2013 distribuiamo la nostra immagine container<\/h4>\n
    \nOra 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\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 a Kubernetes di creare una configurazione di deployment, che dovrebbe contenere la specifica del pod per la nostra immagine del container. Questo comando applicher\u00e0 anche questa configurazione al nostro cluster minikube e creer\u00e0 un deployment che scaricher\u00e0 la nostra immagine del container e avvier\u00e0 un pod nel cluster.<\/p>\n
    Passo 5 \u2013 apriamo l'accesso al nostro servizio<\/h4>\n
    \nOra che abbiamo il nostro container distribuito, \u00e8 tempo di pensare a come configurare l'accesso esterno a questo servizio RESTful, che in effetti \u00e8 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 ed endpoints. Infatti, \u00e8 esattamente ci\u00f2 che faremo, eseguendo il comando expose per il nostro oggetto 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, 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<\/b> ci permette di creare e connettere elementi come i load balancer, per instradare il traffico a questa rete.<\/p>\n
    Ad esempio, specificando --type=LoadBalancer<\/b>, inizializziamo automaticamente un load balancer nel cloud pubblico per connetterci al nostro cluster Kubernetes. Questo \u00e8 ovviamente fantastico, ma dobbiamo capire che tale configurazione sar\u00e0 legata a un cloud pubblico specifico e sar\u00e0 pi\u00f9 difficile da trasferire tra istanze Kubernetes in ambienti diversi.<\/p>\n
    Nel nostro esempio --type=NodePort<\/b>, cio\u00e8 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.<\/p>\n
    Passo 6 \u2013 installiamo il load balancer<\/h4>\n
    \nMinikube 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.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nOra, con un solo comando, creiamo l'ingress controller NGINX che funzioner\u00e0 all'interno del nostro cluster minikube:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Running 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Passo 7 \u2013 configuriamo l'ingress<\/h4>\n
    \nOra dobbiamo configurare l'ingress controller NGINX affinch\u00e9 gestisca le richieste di 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 load balancer NGINX.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nEcco fatto, ora il nostro servizio minikube \u00e8 accessibile dall'esterno attraverso l'ingress controller NGINX.<\/p>\n
    \"Mi<\/p>\n
    Bene, \u00e8 stato facile, vero? O no?<\/h3>\n
    \"Mi<\/p>\n
    Esecuzione 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 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 \u00e8 CRC ed \u00e8 costruito sulla OpenShift Container Platform di Red Hat.<\/p>\n
    Qui non possiamo trattenere il nostro entusiasmo e dire: \"OpenShift \u00e8 fantastico!\"<\/p>\n
    Inizialmente pensavamo di scrivere che sviluppare su OpenShift non \u00e8 diverso dallo sviluppare su Kubernetes. E in effetti \u00e8 cos\u00ec. 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, \u00e8 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.<\/p>\n
    Facciamo una panoramica del processo e vediamo cosa dobbiamo fare.<\/p>\n
    Quindi, nell'esempio con minikube, iniziavamo con Docker... Aspetta, non abbiamo pi\u00f9 bisogno di avere Docker installato sulla macchina.<\/p>\n
    E non ci serve nemmeno git locale.
    \nE non ci serve Maven.
    \nE non dobbiamo creare manualmente l'immagine del container.
    \nE non dobbiamo cercare alcun repository di immagini del container.
    \nE non dobbiamo installare l'ingress controller.
    \nE non dobbiamo nemmeno configurare l'ingress.<\/b><\/p>\n
    Hai capito, vero? Per avviare e lanciare la nostra applicazione su OpenShift, non \u00e8 necessario nulla di quanto elencato sopra. E il processo appare come segue.<\/p>\n
    Passo 1 \u2013 Avviamo il nostro cluster OpenShift<\/h4>\n
    \nUtilizziamo Code Ready Containers di Red Hat, che \u00e8 fondamentalmente lo stesso di Minikube, ma con un cluster OpenShift mononodale completo.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Passo 2 \u2013 Eseguiamo la build e il deployment dell'applicazione nel cluster OpenShift<\/h4>\n
    \n\u00c8 proprio in questo passaggio 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 molti modi per avviare un'applicazione nel cluster. E, come nel caso di K8s, scegliamo specificamente il metodo pi\u00f9 semplice.<\/p>\n
    OpenShift \u00e8 sempre stato concepito come una piattaforma per la creazione e l'esecuzione di applicazioni containerizzate. La creazione dei container \u00e8 sempre stata parte integrante di questa piattaforma, quindi qui ci sono molte risorse Kubernetes aggiuntive per le relative necessit\u00e0.<\/p>\n
    Utilizzeremo il processo Source 2 Image (S2I) di OpenShift, che ha diversi modi per prendere il nostro sorgente (codice o file binari) e trasformarlo in un'immagine container che pu\u00f2 essere eseguita nel cluster OpenShift.<\/p>\n
    Per questo avremo bisogno di due cose:<\/p>\n