Azure WebApps mit Speicher-Backend

So baust du eine Azure-Web-App mit Azure-Storage-Anbindung

Passende Schulungen

AZ-204 Developing Solutions for Microsoft Azure (AZ-204T00)

Ich habe dir bereits in mehreren Artikeln die Grundlagen der Bereitstellung, Verwaltung, Konfiguration und Skalierung von Azure-Webanwendungen nahegebracht. Nun wir es Zeit, sich der Integration solcher Web Apps mit anderen Plattform-Diensten in Azure wie Datenbanken oder Speicherblobs, sowie mit Hilfe der VNet-Integration auch mit Infrastruktur-Diensten zuzuwenden. In diesen Artikel möchte ich dir zeigen, wie deine Web-App mit einem Azure-Blob-Container kommunizieren kann.

Ich habe dazu in Anlehnung an den Kurs „Developing Solutions für Microsoft Azure“ folgenden Szenario vorbereitet: Wir erstellen eine erste Web-App ohne grafische Benutzeroberfläche  – quasi eine reine API-App  -, die via REST-Calls mit einem Storage-Account kommuniziert. Für das Autorisieren des Zugriffs verwenden wir die Speicherkontoschlüssel. Diese API-App ist zwar als reine Hintergrund-Anwendung konzipiert, du kannst sie aber über deinen Browser und die REST-API einfach testen. Sie sollte dann die Inhalte eines Speicher-Blobs auslesen und als JSON-Array mit Meta-Daten zurückgeben (nicht die Bilder im Browser anzeigen. Dies tut dann eine zweite Web App).

Dann erstellen wir diese zweite Web-App als ASP-Frontend-Anwendung, mit deren Hilfe du dann komfortabel die im Blog-Container enthaltenen Bilder anzeigen sowie neue Bilder komfortabel hochladen kannst. Das Wesentliche hierbei ist, dass du die erste API-Web-App so konfigurieren musst, dass sie mit dem Speicher-Container und die Frontend-App mit Backend-App kommunizieren kann. Dies löst du in beiden Fällen mit so genannten App-Services-Anwendungseinstellungen, die du dir wie Umgebungsvariablen vorstellen kannst. Die API-App bekommt auf diese Weise die Speicherkontoschlüssel mitgeteilt und die Frontend-App die URL der Backend-App. Beide Apps fußen übrigens auf einer .NET-Laufzeitumgebung mit Windows-Unterbau.

Azure WebApps mit Speicher-Backend – Vorbereitungen

Erstellen wir also zunächst im Azure Portal den Azure Storage Account. Dies sollte dir geläufig sein. Wähle eine Ressourcengruppe, eine Region und einen eindeutigen Namen für dein Speicherkonto, den Typ „General Purpose v2“ und verwende das Replikationsmodell LRS, um keine unnötigen Kosten zu verursachen. Dann erstellst du einen Blog-Container mit einem Namen deiner Wahl. Die Zugriffsebene bleibt „Privat (kein anonymer Zugriff)“. Dann wechselst du „in“ den Container und lädst ein beliebiges Bild hoch. Die „Authentifizierungsmethode“ ist in der Standardeinstellung „Zugriffsschlüssel“, was für dieses Beispiel gut passt.

Web-Apps erstellen

Da beide Web-Apps einen .Net-Technologiestapel verwenden brauchen wir nun eigentlich einen passenden App-Service-Plan. Diesen kannst du vorher erstellen oder direkt beim Erstellen der ersten Web-App. Wir nehmen den schnelleren Weg. Suche also einfach im Azure-Portal nach „App Services“ und erstelle mit „+Erstellen / Web-App“ die erste Web-App, welche in unserem Beispiel als API-App im Hintergrund laufen soll.

Dies ist aber keine Frage der App-Services-Einstellungen, sondern des Technologie-Stacks (hier .Net) und des bereitgestellten Codes. Achte beim Web-App-Namen darauf, den neuerdings als Default gesetzten Schiebe-Regler für einen „eindeutigen Standardhostnamen“ auf off zu setzen. Die Funktion ist noch Vorschau und führt außerdem zu unnötig langen Host-Namen. Wähle bei „Runtimestapel“ den Eintrag „.Net 8 (LTS)“, als Betriebssystem „Windows“ sowie die gleiche Region, in der sich auch dein Speicherkonto befindet. Dies ist zwar nicht zwingend, aber den Kosten, der Übersichtlichkeit, der Verwaltbarkeit und der Compliance zuträglich. Bei „Windows-Plan“ klickst du auf „Erstellen“, um deinen Namen für den neu anzulegenden App-Services-Plan festzulegen:

Als Tarifplan wählst du „S1“, weil dieser der preiswerteste unter den Dedicated-Plänen ist. Anschließend wechselst du „in“ deine neue API-Web-App und dort zum Menü „Einstellungen / Umgebungsvariablen“. Unter Umgebungsvariablen versteht Microsoft im Kontext einer Web-App „App-Einstellungen“ und/oder „Verbindungszeichenfolgen“. Genau genommen sind „App-Einstellungen“ Variablen, die als Umgebungsvariablen an den Anwendungscode übergeben werden. In welche Form das genau geschieht und wie sie interpretiert werden hängt vom jeweiligen Laufzeitstapel ab.

App-Einstellungen

Bei ASP.NET- und ASP.NET Core entspricht das Festlegen von App-Einstellungen im App Service dem Festlegen der entsprechenden Einstellung in „<appSettings>“ in der Datei „Web.config“ oder „appsettings.json,“ wobei die Werte in App Service jene in Web.config oder appsettings.json überschreiben. Du kannst damit generell Entwicklungseinstellungen, wie ein Datenbank-Passwort in Web.config oder appsettings.json sicher in App Service speichern. In unserem Fall geht es um die Verbindungszeichenfolge für dein Speicherkonto, welche u. a. den Speicherkontoschlüssel enthält. Wie du im Screenshot erkennen kannst, könntest du im Tab „Verbindungszeichenfolgen“ diese auch direkt hinterlegen. Die Einstellungen hier sind ausschließlich und speziell für Datenbank- und Speicherkonto-Verbindungen gedacht. App-Einstellungen hingegen sind allgemeiner und können für verschiedene Konfigurationszwecke verwendet werden. Der Hauptunterschied liegt in der Art und Weise, wie du die Einstellung aus deinem Code abgerufen möchtest.

Kopiere aus deinem Speicherkonto unter „Sicherheit + Netzwerkbetrieb / Zugriffsschlüssel“ die Verbindungszeichenfolge eines der beiden Schlüssel in deine Zwischenablage.

Dann kehrst du zu deiner API-Web-App zurück und legst unter „Einstellungen / Umgebungsvariablen“ im Tab „App-Einstellungen“ mit „Hinzufügen“ eine neue Umgebungsvariable an. Gebe ihr z. B. den Namen „SpeicherVerbindungszeichenfolge“ und füge als Wert den Inhalt deiner Zwischenablage ein.

Du siehst die neue App-Einstellung dann in der Übersicht. Hast du beim Erstellen der Web-App das per Default aktivierte Feature „Application Insights“ bewusst deaktiviert, sollte dies auch deine Einzige App-Einstellung sein. „Mit“ Application Insights gibt es noch drei weitere, wie folgende Abbildung zeigt:

Klickst du auf das Auge bei „Wert anzeigen“ siehst du auch zu schnellen Kontrollzwecken direkt auch den Inhalt der Variable. Wenn du jetzt testweise die App-Services-URL aufrufst, erhältst du zunächst die Standard-HTML-Begrüßungsseite des App-Services-Dienstes, weil wir ja noch keinen individuellen Code bereitgestellt haben, der in C# den Blob-Containerinhalt mit Hilfe der Umgebungsvariable abruft. Dies wollen wir nun tun.

Individueller Code für die API-App

Wie bereits in anderen Artikeln zu den Azure App Services erläutert, hast du mehrere Möglichkeiten, individuellen Code auf deine Web-App bereitzustellen, darunter ..

• CI/CD, bzw. DevOps mittels: GitHub, Bitbucket, Git (lokal) oder Azure Repos
• Manuelle Bereitstellung (Push) mittels Git extern
• Manuelle Bereitstellung (Push) mittels SFTP
• Manuelle Bereitstellung (Push) mittels Kudu Zip-Deployment

Die Varianten mit Continous Deployment hatte ich dir am Beispiel GitHub und Git (lokal) bereits erläutert. Da Microsoft Demo-Code für dieses Beispiel auf GitHub als Zip-Archiv bereitstellt, werden wir in diesem Fall das Feature Zip-Deployment des Kudu-Systems nutzen.

Lade dir zum Bereitstellen des .Net-Codes für deine API-App dieses https://github.com/MicrosoftLearning/AZ-204-DevelopingSolutionsforMicrosoftAzure.ja-jp/blob/main/Allfiles/Labs/01/Starter/API/api.zip Zip-Archiv herunter. Du musst es nicht entpacken. Doch zunächst zu Kudu.

Kudu

Kudu ist ein leistungsstarkes Toolset, das fest in Azure Web Apps integriert ist. Es bietet eine Vielzahl von Funktionen zur Verwaltung und Diagnose von Web-Anwendungen, ohne Azure-Portal.  Sobald du eine Azure Web-App erstellst, wird von App Service eine HTTPS-geschützte Begleit-App miterstellt, die so genannte Kudu-App. Auf diese kannst du über mehrere Art- und Weisen zugreifen:

• So gibt es zunächst eine App auf der isolierten Ebene, zu erreichen unter https://<app-name>.scm.azurewebsites.net
• Es gibt eine im Internet zugängliche App auf der isolierten Ebene (App Service-Umgebung) unter https://<app-name>.scm.<ase-name>.p.azurewebsites.net
• Zudem gibt es eine interne App auf der isolierten Ebene (App Service-Umgebung für den internen Lastenausgleich) unter https://<app-name>.scm.<ase-name>.appserviceenvironment.net

Du erreichst die App am einfachsten, wenn du in deinem App-Service zum Menü „Entwicklungstools / Erweiterte Tools“ navigierst und dort auf „Los“ klickst.

Kudu dient zunächst dazu, dir nützliche Informationen zu deiner App Service-App auf einen Blick anzuzeigen, wie App-Einstellungen, Verbindungszeichenfolgen, Umgebungsvariablen, Servervariablen, HTTP-Header. Außerdem stellt dir Kudu eine Reihen von coolen Features zur Verfügung. Diese sind z. B.:

• Ausführen von Befehlen in der Kudu-Konsole
• Herunterladen von IIS-Speicherabbildern zur Diagnose und Docker-Protokollen
• Verwalten von IIS-Prozessen und Website-Erweiterungen
• Hinzufügen von Bereitstellungs-Webhooks für Windows-Apps
• Generieren von benutzerdefinierte Bereitstellungsskripts
• Zugriff mit einer REST-API zulassen
• Benutzeroberfläche für die ZIP-basierte Bereitstellung mit /ZipDeploy.

Ferner gibt es eine Debug-Konsole, in der du Befehle ausführen und Dateien verwalten kannst. Ferner kannst du mit dem „Process Explorer“ die laufenden Prozesse deiner Anwendung überwachen und verwalten. Außerdem ermöglicht Kudu den Zugriff auf verschiedene Log-Dateien, die bei der Fehlerbehebung und Leistungsüberwachung hilfreich sind. Die letztgenannte Funktion der Aufzählung oben ist die für uns Interessante. Die Startseite von Kudu sieht zunächst so aus, wie in dieser Abbildung. Vergleiche dazu auch die URL: https://<webapp-name>.scm.azurewebsites.net/, die sich nur durch die Zeichenkette „scm“ von deiner Web-App-URL unterscheidet:

Du kannst diesen Teil unseres Setups komfortabel mit Hilfe der REST-API testen, indem die App-Services-URL einfach im Browser aufrufst. Du solltest ein JSON-Dokument zurückbekommen, welches die im Storage-Container enthaltenen Blob-Einträge anzeigt. Du findest die URL auf der Übersichtsseite bei „Standarddomäne“. Vergiss nicht, im Browser das HTTPS davor zu setzen. Im Menü Tools findest du u. a. die von uns gesuchte Funktion „Zip Push Deploy“. Bevor wir aber die Funktion nutzen, klicke im Menü „Debug console“ auf „Powershell. Du erhältst dann nämlich nicht nur eine PS-Console, sondern auch einen Datei-Explorer.

Du findest diese Web-Site im Ordner „site / wwwroot“. Wie unschwer zu erkennen ist, besteht deine Website derzeit nur aus der Beispiel-HTML-Seite „hostingstart.html“ des Azure-App-Service.

Dies wird sich ändern, wenn du im Menü „Tools“ die Funktion „Zip Push Deploy“ aufrufst und das vorhin heruntergeladene Zip-File für deine API-Anwendung hochlädst. Du musst nur das Zip-File aus dienen Downloadordner in das Browser-Fenster ziehen. Das Ergebnis sieht dann so aus:

Das Archiv wurde also direkt entpackt und das Zip-Files selbst entfernt. Würdest du die oben erwähnte Umgebungsvariable erst jetzt einrichten, würde der App-Service auch direkt den entsprechenden Eintrag in der Datei „appsettings.json“ vornehmen. Das musst du leider bei der im Beispiel gewählten Reihenfolge noch einmal manuell machen. Du kannst die Datei allerdings direkt in der Kudu-Debug-Console bearbeiten, indem du auf das Bearbeiten-Symbol klickst und hier deinen Speicher-Conenction-String einträgst:

Nach einem Neustart der Web-App (kannst du auf der Übersichtsseite der Web App im Azure-Portal anstoßen) kannst du deine API-Web-App erneut testen, indem du deine Website-URL im Browser aufrufst. Sie zeigt dann das hochgeladenen Bild in deinem Blob-Container im Browser als JSON-Dokument:

Frontend-App

Nun ist es Zeit, die zweite Web-App bereitzustellen, welche als Frontend dienen soll. Erstelle also einen weiteren App-Service in der gleichen Ressourcengruppe und Region, ebenfalls mit .Net-8-basierten Windows-App-Services-Plan. Die Schritte sind die gleichen, wie bei unserer API-App. Ich nenne sie hier „frontendapp“. Du kannst auch den gleichen Windows-Plan für die Bereitstellung verwenden:

Auch dieser Web-App verpasst du anschließend eine App-Einstellung. Jetzt verwenden wir den Namen „apiurl“ und als Wert die Website-URL deiner API-App. Das sollte dann in etwa so aussehen. Den Teil https:// musst du selbst voranstellen.

Schließlich musst du noch den individuellen Code für die ASP-Net-Frontend-App bereitstellen. Diesen findest du als Zip-Archiv im Microsofts-Learning-Repository https://github.com/MicrosoftLearning/AZ-204-DevelopingSolutionsforMicrosoftAzure/blob/master/Allfiles/Labs/01/Starter/Web/web.zip. Als Bereitstellung-Methode verwenden wir erneut Kudu-Zip-Deploy, diesmal zur Abwechselung von der Kommandozeile.

Öffne daher in deinem Azure-Portal die Cloud Shell, klicke auf „Wechsel zu Bash“ und lade über den Button „Dateien verwalten“ dein Zip-File in die Cloud Shell hoch. Du kannst auch dein lokales Terminal unter Linux oder Windows verwenden, musst dann aber erst die https://learn.microsoft.com/en-us/cli/azure/install-azure-cli Azure CLI installieren und dich mit „az login“ bei deinem Azure-Mandanten anmelden. Wir nehmen hier einfachheitshalber die Cloud-Shell-Variante. Optional kannst du dir in der Cloud Shell deine Frontend-Web-App anzeigen lassen, mit ..

az webapp list --resource-group <resource-group-name>  --query "[?starts_with(name, '<frontend-app-name')].{Name:name}" --output tsv

Du kannst das erfolgreiche Deployment deiner ASP-App auch in der Kudu-Debug-Console überprüfen:

Teste nun deine Frontend-App, indem du die Siute-URL aufrufst. Du solltest nun eine Web-Gallery aller Bilder in deinem Speicherkonto sehen, sowie einen Upload-Button mit der Option weitere Bilder hochzuladen.

Wenn du magst, teste nun noch den Upload-Button. Wähle dazu mit dem „Browse“-Button ein Bild von deiner Festplatte und klicke anschließend auf „Upload“: