Distribuire applicazioni in Azure Red Hat OpenShift tramite OpenShift Serverless

In questo articolo, si distribuirà un'applicazione in un cluster Azure Red Hat OpenShift con OpenShift Serverless. OpenShift Serverless consente agli sviluppatori di distribuire ed eseguire applicazioni con scalabilità verticale o a zero su richiesta. In questo modo si evita il consumo di risorse quando non vengono utilizzate.

Il codice dell'applicazione può essere incluso in un contenitore insieme ai runtime appropriati. La funzionalità serverless avvierà i contenitori dell'applicazione quando vengono attivati da un evento. È possibile attivare applicazioni tramite vari eventi: dalle proprie applicazioni, da più provider di servizi cloud, da sistemi SaaS (Software as a Service) e da altri servizi.

È possibile usare le funzionalità dell'interfaccia OpenShift predefinite per gestire tutti gli aspetti della distribuzione di contenitori serverless. Gli sviluppatori possono identificare visivamente gli eventi che determinano l'avvio di applicazioni incluse in contenitori. Esistono inoltre diversi modi per modificare i parametri dell'evento. Le applicazioni OpenShift Serverless possono essere integrate con altri servizi OpenShift, ad esempio OpenShift Pipelines, Service Mesh e Monitoring. Ciò offre un'esperienza completa di sviluppo e distribuzione di applicazioni serverless.

Prima di iniziare

Creare un cluster

Segui l'esercitazione per creare un cluster Azure Red Hat OpenShift. Se si sceglie di installare e usare l'interfaccia della riga di comando (CLI) in locale, questa esercitazione richiede l'uso dell'interfaccia della riga di comando di Azure versione 2.6.0 o successiva. Eseguire az --version per trovare la versione corrente. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Stabilire la connessione al cluster

Per gestire un cluster Azure Red Hat OpenShift, è necessario usare oc, il client della riga di comando OpenShift.

Seguire l'esercitazione per installare l'interfaccia della riga di comando, recuperare le credenziali del cluster e connettersi al cluster con la console Web e l'interfaccia della riga di comando di OpenShift.

Dopo aver eseguito l'accesso, si dovrebbe visualizzare un messaggio che informa che si sta usando il progetto di default.

Login successful.

You have access to 61 projects, the list has been suppressed. You can list all projects with 'oc projects'

Using project "default".

Installare l'interfaccia della riga di comando di Knative (kn)

Scaricare la versione più recente dell'interfaccia della riga di comando appropriata per il computer da https://github.com/knative/client/releases/

Se si eseguono comandi in Azure Cloud Shell, scaricare l'interfaccia della riga di comando di Knative più recente per Linux.

cd ~
wget https://github.com/knative/client/releases/download/v0.22.0/kn-linux-amd64

mkdir knative
chmod +x kn-linux-amd64
mv kn-linux-amd64 knative/kn
echo 'export PATH=$PATH:~/knative' >> ~/.bashrc && source ~/.bashrc

Aprire la console Web di OpenShift

Trovare l'URL della console Web del cluster eseguendo lo script seguente:

 az aro show \
    --name <cluster name> \
    --resource-group <resource group> \
    --query "consoleProfile.url" -o tsv

Si dovrebbe visualizzare un URL simile al seguente.

https://console-openshift-console.apps.wzy5hg7x.eastus.aroapp.io/

Aprire un Web browser e quindi l'URL della console. Accedere usando le credenziali kubeadmin.

Installare l'operatore OpenShift Serverless

Dopo aver eseguito l'accesso alla console Web OpenShift, confermare di essere nella visualizzazione Amministratore. Aprire l'Hub operatore e selezionare l'operatore OpenShift Serverless.

Aprire quindi la pagina di installazione dell'operatore selezionando Installa.

Scegliere il Canale di aggiornamento appropriato per la versione del cluster di Azure Red Hat OpenShift e installare l'operatore nello spazio dei nomi openshift-serverless. Scorrere verso il basso e selezionare Installa.

Entro pochi minuti, la pagina di stato indica che l'operatore è stato installato ed è pronto per l'uso. Selezionare il pulsante Visualizza operatore per continuare.

Installare Knative Serving

È possibile eseguire un container in modalità serverless in OpenShift Serverless tramite l'utilizzo di Knative upstream. Knative estende Kubernetes per fornire un set di componenti che distribuiscono, eseguono e gestiscono applicazioni moderne tramite la metodologia serverless.

Creare un'istanza di Knative Serving

Nell'angolo superiore sinistro della finestra, nell'elenco Progetto , selezionare knative-server. Quindi, nel riquadro API fornite, selezionare Crea istanza all'interno della scheda Knative Serving.

Nella pagina Crea Knative Serving, mantenere tutti i valori predefiniti. Scorrere verso il basso e selezionare il pulsante Crea.

Quando la colonna Stato visualizza Pronto, OpenShift Serverless è installato. Si è ora pronti per creare un progetto OpenShift Serverless.

Creare un progetto serverless

Per creare un nuovo progetto denominato demoserverless, eseguire il comando seguente:

oc new-project demoserverless

L'output avrà un aspetto analogo al seguente:

Now using project "demoserverless" on server "https://api.wzy5hg7x.eastus.aroapp.io:6443".

You can add applications to this project with the 'new-app' command. For example, build a new example application in Python with the following:

    oc new-app django-psql-example

Or use kubectl to deploy a simple Kubernetes application:

    kubectl create deployment hello-node --image=gcr.io/hello-minikube-zero-install/hello-node

Spostarsi dalla visualizzazione Amministratore alla visualizzazione Sviluppatore. Passare all'elenco dei progetti nel menu a sinistra e selezionare demoserverless. Si è ora nella pagina Topologia per il progetto.

Eseguire la distribuzione tramite la console Web

Nella pagina Topologia selezionare Da Git. Nella pagina Importa da Git, usare https://github.com/sclorg/django-ex.git come URL del repository Git. Un'applicazione Web di esempio viene implementata con il linguaggio di programmazione Python.

Scorrere fino a Risorse e verificare che il servizio Knative sia selezionato come tipo di risorsa da generare. In questo modo verrà creato un servizio Knative, un tipo di distribuzione che consente il ridimensionamento di OpenShift Serverless a zero quando è inattivo.

Selezionare Crea nella parte inferiore della pagina. Tale servizio crea risorse per gestire la creazione e la distribuzione dell'applicazione. Si verrà quindi reindirizzati alla panoramica della topologia per il progetto.

La panoramica della topologia fornisce una rappresentazione visiva dell'applicazione distribuita. È possibile visualizzare la struttura complessiva dell'applicazione.

Attendere il completamento del processo di compilazione. L'operazione potrebbe richiedere alcuni minuti. Al termine della creazione, viene visualizzato un segno di spunta verde nell'angolo inferiore sinistro del servizio.

Visualizzare la scalabilità delle applicazioni

Nella parte superiore della visualizzazione Topologia, nell’elenco Opzioni di visualizzazione, selezionare Numero di pod. Attendere che il numero di pod venga ridotto a zero pod. Il ridimensionamento verso il basso può richiedere alcuni minuti.

Nell'angolo superiore destro del pannello del Servizio Knative, selezionare l'icona Apri URL. L'applicazione viene aperta in una nuova scheda del browser. Chiudere la scheda e tornare alla visualizzazione Topologia. Qui è possibile osservare che l'applicazione è stata ridimensionata fino a un Pod per soddisfare la richiesta. Dopo alcuni minuti, l'applicazione riduce le prestazioni fino a zero pod.

Forzare una nuova revisione e impostare la distribuzione del traffico

I servizi Knative consentono il mapping del traffico, il che significa che è possibile eseguire il mapping delle revisioni di un servizio a una parte del traffico allocata. Ad ogni aggiornamento della configurazione del servizio, viene creata una nuova revisione. Per impostazione predefinita, la route del servizio indirizza quindi tutto il traffico verso l'ultima revisione pronta. È possibile modificare questo comportamento definendo quale revisione riceve porzioni del traffico. Il mapping del traffico offre anche la possibilità di creare URL univoci per le singole revisioni.

Nella topologia creata, selezionare la revisione visualizzata all'interno del servizio per esaminarne i dettagli. I distintivi presenti sotto l'anello pod e nella parte superiore del pannello dei dettagli devono essere (REV). Nel pannello laterale, all’interno della scheda Risorse, scorrere verso il basso e selezionare la configurazione associata al servizio.

Forzare un aggiornamento della configurazione passando alla scheda YAML e scorrendo verso il basso per modificare il valore di timeoutSeconds. Modificare il valore in 301. Seleziona Salva. In uno scenario reale, gli aggiornamenti della configurazione possono essere attivati anche tramite l'aggiornamento del tag dell'immagine del contenitore.

Tornando alla visualizzazione Topologia, si noterà che è stata distribuita una nuova revisione. Selezionare il servizio che termina con il badge (KSVC) e selezionare il pulsante Imposta distribuzione traffico. Si dovrebbe essere adesso in grado di suddividere il traffico tra le revisioni del servizio.

La visualizzazione Topologia mostrerà adesso come viene distribuito il traffico tra le revisioni.

Utilizzo dell'interfaccia della riga di comando di Knative (kn)

Nei passaggi precedenti, si è usato la console Web OpenShift per creare e distribuire un'applicazione in OpenShift Serverless. Poiché OpenShift Serverless esegue Knative nella parte sottostante, è anche possibile usare l'interfaccia della riga di comando di Knative (kn) per creare servizi Knative.

Si userà un'immagine del contenitore già compilata in quay.io/rhdevelopers/knative-tutorial-greeter.

Distribuire un servizio

Per distribuire il servizio, eseguire il comando seguente:

kn service create greeter \
--image quay.io/rhdevelopers/knative-tutorial-greeter:quarkus \
--namespace demoserverless \
--revision-name greeter-v1

Verrà visualizzato un output simile al seguente.

Creating service 'greeter' in namespace 'demoserverless':

  0.044s The Route is still working to reflect the latest desired specification.
  0.083s ...
  0.114s Configuration "greeter" is waiting for a Revision to become ready.
 10.420s ...
 10.489s Ingress has not yet been reconciled.
 10.582s Waiting for load balancer to be ready
 10.763s Ready to serve.

Service 'greeter' created to latest revision 'greeter-v1' is available at URL:
http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io

È possibile recuperare un elenco di route nel progetto eseguendo:

kn route list

Verrà restituito un elenco di route nello spazio dei nomi. Aprire l'URL in un Web browser per visualizzare il servizio distribuito.

NAME      URL                                                            READY
greeter   http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io   True

Distribuire una nuova versione del servizio

Distribuire una nuova versione dell'applicazione eseguendo il comando seguente e passando il :latesttag dell'immagine e una variabile di ambienteMESSAGE_PREFIX:

kn service update greeter \
 --image quay.io/rhdevelopers/knative-tutorial-greeter:latest \
 --namespace demoserverless \
 --env MESSAGE_PREFIX=GreeterV2 \
 --revision-name greeter-v2

Si riceverà una conferma della distribuzione di una nuova revisione greeter-v2.

Updating Service 'greeter' in namespace 'demoserverless':

  5.029s Traffic is not yet migrated to the latest revision.
  5.086s Ingress has not yet been reconciled.
  5.190s Waiting for load balancer to be ready
  5.332s Ready to serve.

Service 'greeter' updated to latest revision 'greeter-v2' is available at URL:
http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io

Per visualizzare un elenco di tutte le revisioni e delle relative distribuzioni del traffico, eseguire il comando seguente:

kn revision list

Verrà visualizzato un elenco simile all'output seguente. Si noti che in questa istanza la nuova revisione riceve il 100% del traffico.

NAME            SERVICE   TRAFFIC   TAGS   GENERATION   AGE     CONDITIONS   READY   REASON
greeter-v2      greeter   100%             2            90s     3 OK / 4     True
greeter-v1      greeter                    1            5m32s   3 OK / 4     True

Distribuzioni blu/verde e canary

Quando viene distribuita una nuova revisione, per impostazione predefinita le viene assegnato il 100% del traffico. Si supponga di voler implementare una strategia di distribuzione blu/verde in cui è possibile eseguire rapidamente il ripristino dello stato precedente alla versione meno recente dell'applicazione. Knative lo rende facile.

È possibile aggiornare il servizio per creare tre tag di traffico, assegnando loro il 100% del traffico.

• current: indica la versione attualmente distribuita
• prev: indica la versione precedente
• latest: indica sempre la versione più recente

kn service update greeter \
   --tag greeter-v2=current \
   --tag greeter-v1=prev \
   --tag @latest=latest

Si otterrà una conferma simile alla seguente.

Updating Service 'greeter' in namespace 'demoserverless':

  0.037s Ingress has not yet been reconciled.
  0.121s Waiting for load balancer to be ready
  0.287s Ready to serve.

Service 'greeter' with latest revision 'greeter-v2' (unchanged) is available at URL:
http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io

Elencare le route usando il comando seguente:

kn route describe greeter

Verrà visualizzato l'output che mostra gli URL per ognuno dei tag, insieme alla distribuzione del traffico.

Name:       greeter
Namespace:  demoserverless
Age:        10m
URL:        http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io
Service:    greeter

Traffic Targets:
  100%  @latest (greeter-v2) #latest
        URL:  http://latest-greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io
    0%  greeter-v1 #prev
        URL:  http://prev-greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io
    0%  greeter-v2 #current
        URL:  http://current-greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io

[..]

Si supponga di voler eseguire rapidamente il ripristino dello stato precedente alla versione precedente aggiornando la distribuzione del traffico in modo da inviare il 100% del traffico al tag precedente:

kn service update greeter --traffic current=0 --traffic prev=100

Elencare le route e ricontrollare usando il comando seguente:

kn route describe greeter

Verrà visualizzato l’output in cui viene mostrato che il 100% della distribuzione del traffico è destinato alla versione precedente.

Name:       greeter
Namespace:  demoserverless
Age:        19m
URL:        http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io
Service:    greeter

Traffic Targets:
    0%  @latest (greeter-v2) #latest
        URL:  http://latest-greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io
  100%  greeter-v1 #prev
        URL:  http://prev-greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io
    0%  greeter-v2 #current
        URL:  http://current-greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io

[..]

Provare metodi diversi per la distribuzione del traffico durante l'aggiornamento della route principale nel browser (http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io in questo caso).

Pulire le risorse

Quando si è terminato con l'applicazione, sarà possibile eseguire il comando seguente per eliminare il progetto:

oc delete project demoserverless

È anche possibile eliminare il cluster seguendo le istruzioni riportate in Esercitazione: eliminare un cluster Azure Red Hat OpenShift 4.

Passaggi successivi

In questa guida si è appreso come:

Per altre informazioni su come creare e distribuire applicazioni serverless basate su eventi in Azure Red Hat OpenShift tramite OpenShift Serverless, seguire la procedura descritta nella documentazione Introduzione a OpenShift Serverless e nella documentazione Creazione e gestione di applicazioni serverless.