Distribuire applicazioni in Azure Red Hat OpenShift usando 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à orizzontale o scalabilità su zero su richiesta. In questo modo si elimina il consumo di risorse quando non sono in uso.
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, sistemi SaaS (Software as a Service) e altri servizi.
È possibile usare le funzionalità predefinite dell'interfaccia OpenShift per gestire tutti gli aspetti della distribuzione di contenitori serverless. Gli sviluppatori possono identificare visivamente gli eventi che determinano l'avvio di applicazioni in contenitori. Esistono anche 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.
Nota
È consigliabile installare la riga di comando di OpenShift in Azure Cloud Shell e usarla per tutte le operazioni della riga di comando in questo articolo. Aprire la shell da shell.azure.com o selezionare il collegamento:
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, verrà visualizzato un messaggio che informa che si sta usando il default progetto.
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 Knative (kn)
Scaricare la versione più recente dell'interfaccia della riga di comando appropriata per il computer dahttps://github.com/knative/client/releases/
Se si eseguono comandi in Azure Cloud Shell, scaricare l'interfaccia della riga di comando 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 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
Dovrebbe essere visualizzato un URL simile al seguente.
https://console-openshift-console.apps.wzy5hg7x.eastus.aroapp.io/
Aprire un Web browser e aprire l'URL della console. Accedere usando kubeadmin le credenziali.
Installare l'operatore OpenShift Serverless
Dopo aver eseguito l'accesso alla console Web OpenShift, verificare di essere in visualizzazione Amministrazione istrator. Aprire l'huboperatore 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 openshift-serverless nomi . Scorrere verso il basso e selezionare Installa.
Entro pochi minuti, la pagina di stato indica che l'operatore è installato ed è pronto per l'uso. Selezionare il pulsante Visualizza operatore per continuare.
Installare Knative Serving
L'opzione per eseguire un contenitore in modo serverless in OpenShift Serverless è possibile usando 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 selezionare knative-servernell'elenco Progetto . 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 .
OpenShift Serverless viene installato quando la colonna Stato mostra Pronto. A questo momento è possibile 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
Passare dalla visualizzazione Amministrazione istrator alla visualizzazione Sviluppo. 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 repository Git. Un'applicazione Web di esempio viene implementata con il linguaggio di programmazione Python.
Nota
OpenShift rileva che si tratta di un progetto Python e seleziona l'immagine del generatore appropriata.
Scorrere fino a Risorse e verificare che il servizio Knative sia selezionato come tipo di risorsa da generare. Verrà creato un servizio Knative, un tipo di distribuzione che consente il ridimensionamento senza server OpenShift su zero quando è inattivo.
Selezionare Crea nella parte inferiore della pagina. In questo modo vengono create risorse per gestire la compilazione 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 compilazione, viene visualizzato un segno di spunta verde nell'angolo inferiore sinistro del servizio.
Visualizzare la scalabilità delle applicazioni
Nella parte superiore della visualizzazione Topologia selezionare Conteggio pod nell'elenco Opzioni di visualizzazione. Attendere che il numero di pod venga ridotto a zero pod. La riduzione delle prestazioni può richiedere alcuni minuti.
Nell'angolo superiore destro del pannello 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. È 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. Con ogni aggiornamento della configurazione del servizio, viene creata una nuova revisione. La route del servizio punta quindi tutto il traffico alla revisione pronta più recente per impostazione predefinita. È possibile modificare questo comportamento definendo la revisione che ottiene parti 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 visualizzarne i dettagli. I badge sotto l'anello Pod e nella parte superiore del pannello dei dettagli devono essere (REV). Nel pannello laterale, nella scheda Risorse scorrere verso il basso e selezionare la configurazione associata al servizio.
Forzare un aggiornamento della configurazione passando alla scheda YAML e scorrere 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 anche essere attivati aggiornando il tag dell'immagine del contenitore.
Tornare 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. A questo momento dovrebbe essere possibile dividere il traffico tra le revisioni nel servizio.
La visualizzazione Topologia mostrerà ora come viene distribuito il traffico tra le revisioni.
Uso dell'interfaccia della riga di comando Knative (kn)
Nei passaggi precedenti è stata usata la console Web OpenShift per creare e distribuire un'applicazione in OpenShift Serverless. Poiché OpenShift Serverless esegue Knative sotto, è anche possibile usare l'interfaccia della riga di comando Knative (kn) per creare servizi Knative.
Nota
Se l'interfaccia della kn riga di comando non è già stata installata, assicurarsi di seguire la procedura descritta nella sezione dei prerequisiti di questo articolo. Assicurarsi anche di aver eseguito l'accesso usando l'interfaccia ocdella riga di comando openshift .
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 :latest tag immagine e una variabile MESSAGE_PREFIXdi ambiente :
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 viene assegnato il 100% del traffico. Si supponga di voler implementare una strategia di distribuzione blu/verde in cui è possibile eseguire rapidamente il rollback alla versione precedente dell'applicazione. Knative rende questo facile.
È possibile aggiornare il servizio per creare tre tag di traffico, assegnando al 100% il traffico.
- current: punta alla versione attualmente distribuita
- prev: punta alla versione precedente
- latest: punta sempre alla 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 rollback alla versione precedente, è possibile aggiornare la distribuzione del traffico per 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 che mostra che il 100% della distribuzione del traffico passa 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 a usare 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
Al termine dell'applicazione, è 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:
- Installare l'operatore OpenShift Serverless e Knative Serving
- Distribuire un progetto serverless usando la console Web
- Distribuire un progetto serverless usando l'interfaccia della riga di comando knative (kn)
- Configurare distribuzioni blu/verde e distribuzioni canary usando l'interfaccia della riga di comando knative (kn)
Altre informazioni su come creare e distribuire applicazioni serverless basate su eventi in Azure Red Hat OpenShift con OpenShift Serverless, seguire la documentazione Introduzione a OpenShift Serverless e la documentazione Creazione e gestione di applicazioni serverless.