Webanwendung unter Microsoft Azure hosten, Teil 4 Code in eine Azure Functions App integrieren

Das Grundgerüst für die Azure Functions App steht. Im vierten Teil dieses Tutorials rollen nun wir den eigentlichen Funktions-Code für unsere serverlose Web-Anwendung aus, der letztlich das Berechnen unserer Thumbnails gewährleisten soll.

Nachdem wir in den vorangegangenen vier Teilen die Grundlagen für unseren Image Resizer gelegt haben sind wir nun soweit, den eigentlichen Funktionscode für unsere Functions App bereitzustellen. Die im Folgenden verwendete Beispielfunktion für den eigentliche Größenänderung ist in C# auf GitHub verfügbar. Das „Pullen“ und Bereitstellen des Codes lässt sich z. B. über die Kommandozeile mit dem folgenden Befehl realisieren:

Man kann aber auch in der Functions App im Abschnitt „Funktionen / Funktionen“ mit einem Klick auf „Lokal entwickeln“ den zuvor von GitHub geklonten Code manuell von VS Code, Visual Studio oder jedem anderen Editor hinzufügen.

Eine Alternative besteht darin, im Menü „Deployment Center“ wieder eine eigene CI/CD-Pipeline erstellen. Zur Wahl stehen hier das Anbinden eines lokalen Git-Repository, welches man sich zu diesem Zweck z. B. in der Cloud Shell von GitHub klonen kann, oder ein Upload des Funktions-Code via FTP. Sofort verwendbare FTP-Anmelde-Daten sowie der FTP-Endpunkt werden dabei im Dialog „App-Anmeldeinformationen“ automatisch kreiert; wer mag, kann aber auch individuelle Anmeldedaten unter „Benutzeranmeldeinformationen“ erstellen.

Den Service reaktiv machen

Jetzt fehlt nur noch unser Event-Trigger, den die Image-Berechnung soll ja automatisch erfolgen, sobald ein neues Bild hochgeladen wird. Hier benötigen wir eine Event-Subscription für den Azure-Service EventGrid.

Vergleicht man sämtliche Messaging-Dienste in Azure, also Event Grid, Event Hubs, Service Bus und Warteschlangen in einem Speicherkonto ist jeder der Dienste für bestimmte Szenarien gedacht. Allerdings ergänzen sich die Messaging-Dienste häufig gegenseitig und können zusammen verwendet werden; Event Grid jedoch eignet sich in erster Linie für die Reaktive Programmierung.

Konkret handelt es sich hierbei um ein Ereignisbackplane, das ereignisgesteuerte, reaktive Programmierung ermöglicht. Hierbei kommt ähnlich wie bei Simple Notification Service von AWS (SNS) ein Publisher-/Subscriber-Modell zum Einsatz, wobei Publisher Ereignisse ausgeben, aber keinen Einfluss darauf haben, welche Ereignisse behandelt werden.

Die Abonnenten entscheiden sozusagen selbst, welche Ereignisse sie behandeln möchten. Das Ereignis-Abonnement gibt also dabei an, welche vom Anbieter generierten Ereignisse an einen bestimmten Endpunkt gesendet werden sollen. In unserem Fall wird der Endpunkt von der Azure Functions verfügbar gemacht. Wie das funktioniert, sehen wir uns im letzten Teil an.

(ID:46866558)