Bereitstellen einer Anwendung in Azure Red Hat OpenShift mithilfe von OpenShift Serverless
In diesem Artikel stellen Sie mithilfe von OpenShift Serverless eine Anwendung in einem Azure Red Hat OpenShift-Cluster bereit. OpenShift Serverless ermöglicht Entwicklern das Bereitstellen und Ausführen von Anwendungen, die bei Bedarf hoch- oder auf Null herunterskaliert werden. Dadurch wird der Verbrauch von Ressourcen vermieden, wenn sie nicht gebraucht werden.
Der Anwendungscode kann zusammen mit den entsprechenden Laufzeiten in einen Container gepackt werden. Serverlose Funktionen starten die Anwendungscontainer, wenn sie durch ein Ereignis ausgelöst werden. Sie können Anwendungen über verschiedene Ereignisse auslösen: von Ihren eigenen Anwendungen, von mehreren Cloud-Dienstanbietern, Software-as-a-Service-Systemen und anderen Diensten.
Sie können integrierte OpenShift-Schnittstellenfeatures verwenden, um alle Aspekte der serverlosen Containerbereitstellung zu verwalten. Entwickler können visuell erkennen, durch welche Ereignisse ihre containerisierten Anwendungen gestartet werden. Es gibt auch mehrere Möglichkeiten zum Ändern von Ereignisparametern. OpenShift Serverless-Anwendungen können in andere OpenShift-Dienste wie OpenShift Pipelines, Service Mesh und Monitoring integriert werden. Dies bietet eine vollständige serverlose Anwendungsentwicklung und Bereitstellungserfahrung.
Vor der Installation
Erstellen eines Clusters
Sehen Sie sich das Tutorial Erstellen eines Azure Red Hat OpenShift-Clusters an. Wenn Sie die Befehlszeilenschnittstelle (CLI) lokal installieren und verwenden möchten, müssen Sie für dieses Tutorial die Azure CLI-Version 2.6.0 oder höher ausführen. Führen Sie az --version aus, um Ihre aktuelle Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.
Herstellen einer Verbindung mit dem Cluster
Zum Verwalten eines Azure Red Hat OpenShift-Clusters müssen Sie den OpenShift-Befehlszeilen-Client oc verwenden.
Hinweis
Es wird empfohlen, die Installation der OpenShift-Befehlszeile in Azure Cloud Shell vorzunehmen und sie für alle Befehlszeilenvorgänge in diesem Artikel zu verwenden. Öffnen Sie Ihre Shell über shell.azure.com oder durch Klicken auf den Link:
Befolgen Sie das Tutorial zum Installieren der CLI, dem Abrufen der Clusteranmeldeinformationen und dem Herstellen einer Verbindung mit dem Cluster mithilfe der Webkonsole und der OpenShift-Befehlszeilenschnittstelle.
Nachdem Sie sich angemeldet haben, sollte eine Meldung mit dem Text angezeigt werden, dass Sie das default-Projekt verwenden.
Login successful.
You have access to 61 projects, the list has been suppressed. You can list all projects with 'oc projects'
Using project "default".
Installieren der Knative-Befehlszeilenschnittstelle (kn)
Laden Sie die neueste Version der Befehlszeilenschnittstelle (CLI), die für Ihren Computer geeignet ist, von https://github.com/knative/client/releases/ herunter.
Falls Sie die Befehle in Azure Cloud Shell ausführen, laden Sie die aktuelle Knative-Befehlszeilenschnittstelle für Linux herunter.
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
Öffnen der OpenShift-Webkonsole
Suchen Sie ihre Clusterwebkonsolen-URL, indem Sie das folgende Skript ausführen:
az aro show \
--name <cluster name> \
--resource-group <resource group> \
--query "consoleProfile.url" -o tsv
Sie sollten eine URL ähnlich der folgenden erhalten.
https://console-openshift-console.apps.wzy5hg7x.eastus.aroapp.io/
Öffnen Sie einen Webbrowser und rufen Sie die URL der Konsole auf. Melden Sie sich unter Verwendung von kubeadmin-Anmeldeinformationen an.
Installieren des OpenShift Serverless-Operators
Wenn Sie in der OpenShift-Webkonsole angemeldet sind, vergewissern Sie sich, dass Sie sich in der Administratoransicht befinden. Öffnen Sie den OperatorHub und wählen Sie den OpenShift Serverless aus.
Klicken Sie als Nächstes auf Installieren, um die Installationsseite des Operators zu öffnen.
Wählen Sie den entsprechenden Updatekanal für die Version Ihres Azure Red Hat OpenShift-Clusters aus, und installieren Sie den Operator im Namespace openshift-serverless. Scrollen Sie nach unten, und klicken Sie auf Installieren.
Nach ein paar Minuten sollte auf der Statusseite angezeigt werden, dass der Operator installiert wurde und einsatzbereit ist. Klicken Sie auf die Schaltfläche Operator anzeigen, um fortzufahren.
Installieren von Knative Serving
Upstream-Knative ermöglicht die serverlose Ausführung beliebiger Container in OpenShift Serverless. Knative erweitert Kubernetes, um eine Reihe von Komponenten bereitzustellen, die moderne Anwendungen über ihre serverlose Methodik bereitstellen, ausführen und verwalten.
Erstellen einer Instanz von Knative Serving
Wählen Sie in der oberen linken Ecke des Fensters in der Liste Projekt die Option knative-server aus. Wählen Sie dann im Fensterbereich Bereitgestellte APIs auf der Karte Knative Serving die Option Instanz erstellen.
Behalten Sie auf der Seite Knative Serving erstellen alle Standardwerte bei. Scrollen Sie nach unten, und klicken Sie auf die Schaltfläche Erstellen.
OpenShift Serverless wird installiert, wenn in der Spalte StatusBereit angezeigt wird. Jetzt können Sie ein OpenShift Serverless-Projekt erstellen.
Erstellen eines serverlosen Projekts
Führen Sie den folgenden Befehl aus, um ein neues Projekt mit dem Namen demoserverless zu erstellen:
oc new-project demoserverless
Die Ausgabe sollte ähnlich der Folgenden aussehen:
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
Wechseln wir aus der Administratoransicht zur Entwickleransicht. Wir wechseln zur Liste der Projekte im linken Menü und wählen dann demoserverless aus. Nun sollte die Seite Topologie für das Projekt angezeigt werden.
Bereitstellung über die Webkonsole
Wählen Sie auf der Seite Topologie die Option Aus Git aus. Verwenden Sie auf der Seite Aus Git importierenhttps://github.com/sclorg/django-ex.git als Git Repo-URL. Die Beispielwebanwendung wird mit der Programmiersprache Python implementiert.
Hinweis
OpenShift erkennt, dass es sich um ein Python-Projekt handelt und wählt das geeignete Builderimage aus.
Scrollen Sie nach unten zum Abschnitt Ressourcen, und vergewissern Sie sich, dass Knative Service (Knative-Dienst) als zu generierender Ressourcentyp ausgewählt ist. Durch diese Aktion wird ein Knative-Dienst erstellt, ein Bereitstellungstyp, der es OpenShift Serverless ermöglicht, im Leerlauf auf Null herunterzuskalieren.
Wählen Sie am unteren Rand der Seite die Option Erstellen aus. Hierdurch werden Ressourcen erstellt, die zum Verwalten des Builds und Bereitstellen der Anwendung benötigt werden. Anschließend werden Sie zur Topologieübersicht für das Projekt umgeleitet.
Die Topologieübersicht liefert eine visuelle Darstellung der Anwendung, die Sie bereitgestellt haben. In dieser Ansicht sehen Sie die Gesamtstruktur der Anwendung.
Warten Sie, bis der Buildvorgang abgeschlossen wird. Dies kann einige Minuten dauern. Nach Abschluss des Buildvorgangs wird in der unteren linken Ecke des Diensts ein grünes Häkchen angezeigt.
Anzeigen der Skalierung Ihrer Anwendung
Klicken Sie oben in der Topologieansicht in der Liste Anzeigeoptionen auf Podanzahl. Warten Sie, bis die Podanzahl auf 0 Pods herunterskaliert wurde. Das Herunterskalieren kann einige Minuten dauern.
Klicken Sie in der oberen rechten Ecke des Bereichs für den Knative-Dienst auf das Symbol URL öffnen. Die Anwendung wird auf einer neuen Browserregisterkarte geöffnet. Schließen Sie die Registerkarte, und kehren Sie zur Topologieansicht zurück. Dort können Sie sehen, dass die Anwendung auf einen Pod hochskaliert wurde, um Ihre Anforderung zu erfüllen. Nach einigen Minuten wird Ihre Anwendung wieder auf 0 Pods herunterskaliert.
Erzwingen einer neuen Revision und Festlegen der Datenverkehrsverteilung
Knative-Dienste ermöglichen die Datenverkehrszuordnung, d. h. Revisionen eines Diensts können einem zugewiesenen Teil des Datenverkehrs zugeordnet werden. Bei jeder Aktualisierung der Dienstkonfiguration wird eine neue Revision erstellt. Die Dienstroute leitet den gesamten Datenverkehr standardmäßig zur neusten Revision, die bereit ist. Sie können dieses Verhalten ändern, indem Sie definieren, welcher Revision ein Teil des Datenverkehrs zugeordnet wird. Die Datenverkehrszuordnung bietet auch die Möglichkeit, eindeutige URLs für bestimmte Revisionen zu erstellen.
Wählen Sie in der erstellten Topologie die Revision aus, die innerhalb Ihres Dienstes angezeigt wird, um dessen Details anzuzeigen. Die Badges unter dem Pod-Ring und oben im Detailbereich sollten (REV) lauten. Scrollen Sie im Seitenbereich auf der Registerkarte Ressourcen nach unten, und klicken Sie auf die Konfiguration, die Ihrem Dienst zugeordnet ist.
Erzwingen Sie ein Konfigurationsupdate, indem Sie zur Registerkarte YAML wechseln, nach unten scrollen und den Wert von timeoutSeconds ändern. Ändern Sie den Wert in 301. Wählen Sie Speichern. In der Praxis kann ein solches Konfigurationsupdate auch durch Aktualisieren des Containerimagetags ausgelöst werden.
Gehen Sie zurück zur Topologieansicht. Dort können Sie sehen, dass eine neue Revision bereitgestellt wurde. Wählen Sie den Dienst aus, der mit dem Badge (KSVC) endet, und klicken Sie auf die Schaltfläche Datenverkehrsverteilung festlegen. Sie sollten nun in der Lage sein, den Datenverkehr zwischen den Revisionen im Dienst aufzuteilen.
In der Topologieansicht wird jetzt angezeigt, wie der Datenverkehr zwischen den Revisionen verteilt wird.
Verwenden der Knative-Befehlszeilenschnittstelle (kn)
In den vorherigen Schritten haben Sie die OpenShift-Webkonsole verwendet, um eine Anwendung zu erstellen und in OpenShift Serverless bereitzustellen. Da OpenShift Serverless Knative im Hintergrund ausführt, können Sie Knative-Dienste auch mithilfe der Knative-Befehlszeilenschnittstelle (kn) erstellen.
Hinweis
Falls Sie die kn-CLI noch nicht installiert haben, führen Sie die Schritte im Abschnitt „Voraussetzungen“ dieses Artikels aus. Stellen Sie auch sicher, dass Sie sich mit der OpenShift-Befehlszeilenschnittstelle oc angemeldet haben.
In diesem Artikel verwenden wir ein Containerimage, das bereits unter quay.io/rhdevelopers/knative-tutorial-greeter erstellt wurde.
Bereitstellen eines Diensts
Führen Sie den folgenden Befehl aus, um den Dienst bereitzustellen:
kn service create greeter \
--image quay.io/rhdevelopers/knative-tutorial-greeter:quarkus \
--namespace demoserverless \
--revision-name greeter-v1
Eine Ausgabe ähnlich der folgenden wird angezeigt.
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
Mit dem folgenden Befehl können Sie eine Liste der Routen im Projekt abrufen:
kn route list
In der Ausgabe wird eine Liste der Routen im Namespace zurückgegeben. Öffnen Sie die URL in einem Webbrowser, um den bereitgestellten Dienst anzuzeigen.
NAME URL READY
greeter http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io True
Bereitstellen einer neuen Version des Diensts
Stellen Sie eine neue Version der Anwendung bereit, indem Sie den folgenden Befehl ausführen und dabei das Imagetag :latest sowie eine Umgebungsvariable MESSAGE_PREFIX übergeben:
kn service update greeter \
--image quay.io/rhdevelopers/knative-tutorial-greeter:latest \
--namespace demoserverless \
--env MESSAGE_PREFIX=GreeterV2 \
--revision-name greeter-v2
Sie erhalten eine Bestätigung, dass eine neue Revision greeter-v2 bereitgestellt wurde.
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
Führen Sie den folgenden Befehl aus, um eine Liste aller Revisionen und deren Datenverkehrsverteilung anzuzeigen:
kn revision list
Es wird eine Liste ähnlich der folgenden ausgegeben. Beachten Sie, dass in diesem Fall die neue Revision 100 % des Datenverkehrs erhält.
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
Blue/Green- und Canary-Bereitstellungen
Wenn eine neue Revision bereitgestellt wird, wird standardmäßig 100 % des Datenverkehrs zugewiesen. Angenommen, Sie möchten eine Blue/Green-Bereitstellungsstrategie implementieren, bei der Sie schnell ein Rollback auf die ältere Version der Anwendung ausführen können. Mit Knative ist dies ganz einfach.
Aktualisieren Sie den Dienst, um drei Datenverkehrstags zu erstellen und 100 % des Datenverkehrs entsprechend zuzuweisen.
- aktuell: verweist auf die aktuell bereitgestellte Version
- vorher: verweist auf die vorherige Version
- neueste: verweist immer auf die neueste Version
kn service update greeter \
--tag greeter-v2=current \
--tag greeter-v1=prev \
--tag @latest=latest
Sie erhalten eine Bestätigung, die in etwa wie folgt aussieht.
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
Listen Sie die Routen mit dem folgenden Befehl auf:
kn route describe greeter
Sie erhalten eine Ausgabe, in der die URLs für jedes der Tags zusammen mit ihrer Datenverkehrsverteilung angezeigt werden.
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
[..]
Angenommen, Sie möchten schnell ein Rollback auf die vorherige Version ausführen. Dazu können Sie die Datenverkehrsverteilung so aktualisieren, dass 100 % des Datenverkehrs an das Tag für die vorherige Version gesendet werden:
kn service update greeter --traffic current=0 --traffic prev=100
Listen Sie die Routen auf, und überprüfen Sie sie erneut, indem Sie den folgenden Befehl verwenden:
kn route describe greeter
Sie erhalten eine Ausgabe, die zeigt, dass der Datenverkehr zu 100 % der vorherigen Version zugewiesen wird.
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
[..]
Experimentieren Sie mit der Datenverkehrsverteilung, und aktualisieren Sie dabei die Hauptroute (in diesem Fall http://greeter-demoserverless.apps.wzy5hg7x.eastus.aroapp.io) in Ihrem Browser.
Bereinigen von Ressourcen
Wenn Sie die Anwendung nicht mehr benötigen, können Sie das Projekt mit dem folgenden Befehl löschen:
oc delete project demoserverless
Sie können auch den Cluster löschen, indem Sie die Anweisungen in Tutorial: Löschen eines Azure Red Hat OpenShift 4-Clusters befolgen.
Nächste Schritte
In diesem Leitfaden haben Sie Folgendes gelernt:
- Installieren des OpenShift Serverless-Operators und von Knative Serving
- Bereitstellen eines serverlosen Projekts mithilfe der Webkonsole
- Bereitstellen eines serverlosen Projekts mithilfe der Knative-CLI (kn)
- Konfigurieren von Blue/Green- und Canary-Bereitstellungen mit der Knative-CLI (kn)
Weitere Informationen zum Erstellen und Bereitstellen serverloser, ereignisgesteuerter Anwendungen in Azure Red Hat OpenShift mithilfe von OpenShift Serverless finden Sie in den Dokumentationen zu den ersten Schritten mit OpenShift Serverless und zum Erstellen und Verwalten serverloser Anwendungen.