Webanwendung über Microsoft Azure hosten, Teil 3 Serverlose Bereitstellung einer Azure Functions App

Anbieter zum Thema

Mit Hilfe von Azure Web Apps und Azure Functions wollen wir eine hochverfügbare Webanwendung zum Berechnen von Thumbnails ohne explizit eigene Infrastruktur bereitstellen. In diesem Beitrag unseres vierteiligen Workshops kümmern wir uns um den serverlosen Teil der Anwendung.

Laufende Functions App ohne individuellen Code.
Laufende Functions App ohne individuellen Code.
(Bild: Drilling / Microsoft)

In diesem Beitrag kümmern wir uns darum, dass eine serverlose Azure-Functions-App den Code für die eigentliche Konvertierung von Bildern bereitstellt. Für die Ablauf-Logik, d. h. die Interaktion mit den übrigens Diensten, wie z. B. den im zweiten Teil dieser Image-Resizer-Serie angelegten Containern, setzen wir auf EventGrid.

Noch nicht verwendete Ressource Provider müssen abgesehen von Standard-Ressource-Providern wie „Compute“ oder „Storage“ im Falle von EventGrid erst beim Azure Ressource Manager registriert werden.
Noch nicht verwendete Ressource Provider müssen abgesehen von Standard-Ressource-Providern wie „Compute“ oder „Storage“ im Falle von EventGrid erst beim Azure Ressource Manager registriert werden.
(Bild: Drilling / Microsoft)

Dieser Dienst wird unsere Azure Functions App triggern, sobald ein neue Upload im image-Container erfolgt. Dazu ist es – soweit noch nicht geschehen – jetzt auch vor dem Anbinden von EventGrid erforderlich, den Ressource-Provider für EventGrid zu registrieren. Dies kann wahlweise in der Cloud Shell mit …

az provider register --namespace Microsoft.EventGrid

… erfolgen oder im Azure-Portal nach Auswahl der gerade verwendeten Azure Subscription im Menü „Einstellungen / Ressourcenanbieter" mit einem Klick auf „Registrieren“ beim Anbieter-Eintrag „Microsoft.EventGrid“.

Die Backend-Systeme bekommen aus Sicherheitsgründen ihre eigene Speicher-Lokation.
Die Backend-Systeme bekommen aus Sicherheitsgründen ihre eigene Speicher-Lokation.
(Bild: Drilling / Microsoft)

Nun benötigen wir einen weiteren Storage Account für unsere Azure-Functions-Ressource. Wie man unter Azure ein Speicher-Konto anlegt, haben wir in Teil 1 dieser Serie gezeigt. Wir verwenden den gleichen Account-Typ „StorageV2“ und das gleiche Redundanz-Modell (LRS). Trotzdem ist es sinnvoll, die Speicher-Lokation der Anwendungs-Daten von denen der Backend-Logik zu separieren. Da aber beide Speicherkonten zum gleichen Projekt gehören, kommen sie selbstverständlich in die gleiche Ressourcengruppe.

Azure Functions App

Bild: Functions-App-gui1.PNG

Auch das Erstellen einer Azure Functions App kann via Azure Portal oder Cloud Shell erfolgen.
Auch das Erstellen einer Azure Functions App kann via Azure Portal oder Cloud Shell erfolgen.
(Bild: Drilling / Microsoft)

Nun können wir uns dem Erstellen der serverlosen Funktion, einer „Azure Functions App“ zuwenden. Diese setzen wir zum serverlosen Hosten unserer Resizer-Funktion ein. Das Erstellen kann wieder wahlweise per CLI in der Cloud Shell oder im Azure Portal erfolgen. Der Name der Funktions-App als Standard-DNS-Domäne für die Funktions-App verwendet wird, muss der Name genau wie bei unserer Web App aus Teil 2 in Azure eindeutig sein. Eine ähnliche Funktion wie bei Web Apps der „App Service Plan“ erfüllt bei Functions Apps der so genannte „Consumption Plan“ (Nutzungsplan).

Für das serverlose Hosten einer Azure Functions App verwenden wir den Planungs-Typ "Verbrauch (Serverlos).“
Für das serverlose Hosten einer Azure Functions App verwenden wir den Planungs-Typ "Verbrauch (Serverlos).“
(Bild: Drilling / Microsoft)

Um diesen anzugeben, wählt man im Schritt 2 des Functions-App-Bereitstellungs-Assistenten bei „Plantyp“ den Eintrag „Verbrauch (serverlos)“. In diesem Fall kümmert sich Microsoft Azure im die dynamische Skalierung und bedarfsgesteuerte Ausführung des Plans. Die alternative Option „Premium“ bietet erweiterte Funktionen und eine bessere Steuerung der dynamischen Skalierung.

In Azure ist es aber auch bei einer Functions App auf Wunsch möglich, mit den Eintrag „App Service-Plan“ einen Plan für eine klassische bedarfsgesteuerte Ausführung auszuwählen, wie wir es schon im Teil 2 bei der Web App gesehen haben. Wir bleiben allerdings bei serverlos, dem eigentlich üblichen Bereitstellungs- und Abrechnungsplan bei „Function-as-Code“.

Selbstverständlich können wir unsere Azure Functions auch per Cloud Shell bereitstellen. Wir verwenden dazu wieder die Azure CLI:

az functionapp create --name resizer-function --storage-account azditresizesa --resource-group azditresizerrg --consumption-plan-location eastus --functions-version 2

Functions App konfigurieren

Unsere Functions App benötigt Anmeldeinformationen auf das Speicherkonto mit dem Blob-Speicher für Quell-Images und Thumbnails.
Unsere Functions App benötigt Anmeldeinformationen auf das Speicherkonto mit dem Blob-Speicher für Quell-Images und Thumbnails.
(Bild: Drilling / Microsoft)

Die Funktion benötigt Anmeldeinformationen für das Blob-Speicherkonto. Diese lassen sich z. B. mit den beiden folgenden Befehlen den Anwendungseinstellungen der Functions App hinzufügen:

storageConnectionString=$(az storage account show-connection-string --resource-group azditresizerrg --name azditresizersa1 --query connectionString --output tsv)
az functionapp config appsettings set --name Resizer-Function --resource-group azditresizerrg --settings AzureWebJobsStorage=$storageConnectionString THUMBNAIL_CONTAINER_NAME=thumbnails THUMBNAIL_WIDTH=100 FUNCTIONS_EXTENSION_VERSION=~2

Alternativ lassen sich die Anmeldeinformationen genau wie bei der Web App im zweiten Teil auch in der GUI im Abschnitt „Configuration“ bei „Application settings“ hinzufügen. Hierzu klickt man bei „AzureWebJobsStorage“ auf das Bearbeiten-Symbol und fügt bei „Value“ eine der beiden Verbindungszeichenfolgen des Speicherkontos hinzu, das wir im ersten Teil als Basis für den ThumbnailsContainer angelegt haben.

Die Functions App benötigt noch weitere Anwendungseinstellungen.
Die Functions App benötigt noch weitere Anwendungseinstellungen.
(Bild: Drilling / Microsoft)

Das gilt auch für zwei weitere benötigte und im o. g. Befehl bereits enthaltene Anwendungseinstellungen „THUMBNAIL_CONTAINER_NAME“ und „THUMBNAIL_WIDTH“. Hierbei darf man nicht vergessen, auf „Save“ zu klicken.

Eine Functions App ohne individuellen Code.
Eine Functions App ohne individuellen Code.
(Bild: Drilling / Microsoft)

Wie ein Klick auf die URL der Functions App beweist, läuft die App bereits, hostet aber noch keinen eigenen Code.

(ID:46860845)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung