ASP.NET Core App mit Azure SQL Database Backend bereitstellen Azure-gehostete Web-App mit Datenbank und Redis-Cache

Wir haben uns bereits in einigen Artikeln mit den Azure App Services auseinandergesetzt. Nun wollen wir eine ASP.Net-Core-Frontend-App (Linux) auf dem Azure App Service hosten und mit einer verwalteten, mittels Azure Cache für Redis beschleunigten Azure SQL-Server-Datenbank integrieren.

Wie üblich beginnen wir erst einmal damit, die für dieses Beispiel erforderlichen Azure-Ressourcen bereitzustellen: den App Service selbst, die Azure SQL Datenbank und den Redis Cache. Dieses Beispiel orientiert sich nahe an einem entsprechenden ASP-Quickstart der App-Services-Dokumentation.

Im Azure-Portal erstellen wir zunächst einen neuen App Service und wählen dabei die Variante „Web-App und Datenbank“. Es gilt nun, das Azure-Abonnement, eine vorhandene Ressourcengruppe (oder neu zu erstellende), die Region, den Laufzeitstapel „.NET 7 (STS)“ und die Datenbank-Engine „SQL Azure“ (Datenbank- und Servername werden dabei automatisch vorgeschlagen) auszuwählen. Mit „Ja“ aktivieren wir die Redis-Integration (hierbei ist ein Cachename erforderlich) und nutzen zunächst den Hosting-Plan „Basic“ (ein Upgrade ist später jederzeit möglich), der serverlos berechnet wird und bei Bedarf jederzeit skaliert.

Das Erstellen samt SQL-Datenbank und Cache wird einige Minuten in Anspruch nehmen. Danach geht es in den Abschnitt „Konfiguration“ der Web App zu den automatisch erstellten „Anwendungseinstellungen“ und/oder „Verbindungszeichenfolgen“. Hier notieren wir die „Namen“ für die Anwendungseinstellung „AZURE_REDIS_CONNECTIONSTRING“ sowie die „Verbindungszeichenfolge“ „AZURE_SQL_CONNECTIONSTRING“. Die zugehörigen Werte lassen sich jeweils mit einem Klick auf das Auge-Symbol sichtbar machen oder ändern.

Das Code-Beispiel für diesen Beitrag stammt aus Microsofts GitHub-Repository Azure-Samples . Es gibt, wie wir schon in anderen Beiträgen demonstriert haben, zahlreiche Möglichkeiten, individuellen Code auf einer Azure Web App bereitzustellen – mit und ohne Continuous Integration. Der Code lässt sich beispielsweise vom öffentlichen Microsoft-GitHub-Repo als Zip-File herunterladen und lokal entpacken oder mittels git in ein lokales Verzeichnis klonen, sofern git installiert ist.

Im Anschluss ist es möglich, die Web App im Bereitstellungscenter mit dem Quellcode-Anbieter „Git (lokal)“ remote an das lokale Arbeitsverzeichnis anzubinden und Änderungen via git push zu veröffentlichen. Für dieses Beispiel haben wir uns hingegen für die populäre Kombination von GitHub als Quellcode-Repository und GitHub Actions als Workflow-Engine (Build-Dienst) entschieden. Der Quellcode muss dann gar nicht erst heruntergeladen werden. Da es sich um ein öffentliches Repo handelt, kann man direkt mit einem Fork arbeiten.

Wir navigieren also zu https://github.com/Azure-Samples/msdocs-app-service-sqldb-dotnetcore und klicken rechts oben auf „Fork“. GitHub schickt den User – sofern angemeldet – direkt in dessen GitHub-Konto und schlägt einen passenden Repository-Namen vor. Nun gilt es noch, unten auf die grüne Schaltfläche „Create fork“ zu klicken. Im „geforkten“ Repository erscheint dann initial die Meldung „This branch is up to date with Azure-Samples/msdocs-app-service-sqldb-dotnetcore:main.“

Jetzt müssen wir nur noch im Bereitstellungscenter der Web App als Code-Quelle „GitHub“ auswählen (GitHub Actions wird dann automatisch als Build-Anbieter verwendet) und uns beim GitHub-Konto anmelden. Wir wählen das eben geforkte Repository mit dem Branch „main“ als Quelle und klicken auf „Speichern“, wodurch die initiale Bereitstellung der Web App ausgelöst wird.

Die Bereitstellungsprotokolle lassen sich im Tab „Protokolle“ live mitverfolgen – der Build-Prozess wiederum in GitHub, wenn man den Link in den Bereitstellungsprotokollen betätigt.

Aus GitHub heraus ist öffnen wir danach die Datei „DotNetCoreSqlDb/appsettings.json“ in der Browser-Version von VS Code. Dazu gilt es, einfach die Datei im Code-Browser von GitHub zu markieren und die Taste „.“ Zu betätigen. Hier muss der Bezeichner „MyDbConnection“ in „AZURE_SQL_CONNECTIONSTRING“, also der vom App Service zuvor generierten Verbindungszeichenfolge, geändert werden.

Auf die gleiche Weise öffnen wir die Datei „DotNetCoreSqlDb/Program.cs“ und ändern in der Methode „options.UseSqlServer“-Methode den Namen „MyDbConnection“ zu „AZURE_SQL_CONNECTIONSTRING“, da hier der Name der Verbindungszeichenfolge von der Beispielanwendung verwendet wird.

Im Code-Beispiel enthalten ist die „leere“ Methode builder.Services.AddDistributedMemoryCache(); – diese muss gelöscht und durch folgenden Beispiel-Code ersetzt werden, …

… um damit den Code zur Nutzung eines In-Memory-Caches für den Redis-Cache in Azure vorzubereiten. Das geschieht mit Hilfe des oben notierten AZURE_REDIS_CONNECTIONSTRING.

Nun will noch der Workflow für die Bereitstellung in GitHub Actions angepasst werden. Wir öffnen dazu die Datei .github/workflows/main_<name-ihrer-app>.yml, welche vom Erstellungs-Assistenten des App Service erstellt wurde, im Online-Editor von VS Code. Hier muss man unterhalb des Schrittes „dotnet publish“ einen weiteren Schritt hinzufügen, der das Entity Framework Core-Tool mit dem Kommando „dotnet tool install -g dotnet-ef“ installiert.

An dieser Stelle wird noch ein weiterer Schritt benötigt. Dieser generiert im Bereitstellungspaket ein passendes Datenbankmigrationspaket mittels:

dotnet ef migrations bundle --runtime linux-x64 -p DotNetCoreSqlDb/DotNetCoreSqlDb.csproj -o ${{env.DOTNET_ROOT}}/myapp/migrate.

Hierbei handelt es sich um eine eigenständige Datei, die sich dann später in der Produktionsumgebung (z. B. mittels ssh-Zugang) ausführen lässt. Sie dient dem Anpassen des Datenbankschemas und funktioniert auch, wenn das .NET SDK nicht installiert ist, denn der Linux-Container im App Service enthält nur die .NET-Runtime, nicht aber das .NET SDK.

Nun ist es möglich, die Änderungen aus GitHub erneut zu veröffentlichen. Hierfür klicken wir in der Browser-Version von VS Code auf die Extension „Quellcodeverwaltung“, denken uns eine Commit-Message aus und klicken auf „Commit und Push“.

Bei Erfolg leitet VS Code wieder an das GitHub-Repository zurück, in dem man das Ausführen der GitHub-Aktion verfolgen kann – genauso übrigens, wie in den Bereitstellungscenter-Protokollen der Web App.

In der Workflow-Datei sind unübersehbar zwei separate Phasen „build“ und „deploy“ definiert. Daher dauert es durchaus ein paar Minuten, bis die GitHub-Ausführung den Status „Abgeschlossen“ hat.

Da der Zugang zur SQL-Datenbank durch das virtuelle Netzwerk geschützt ist, können wir zum Ausführen der Dotnet-Datenbankmigration eine SSH-Sitzung zum App Service-Container herstellen. Hierfür ist es notwendig, im Azure-Portal der Web App im Abschnitt „Entwicklungstools“ auf „SSH“ und dann auf „Los“ zu klicken.

Zum Generieren des Datenbank-Schemas müssen wir mit …

… in das Site-Root der App wechseln und dann dort das vom eben durchgeführten Workflow bereitgestellte Migrationspaket ausführen:

Anschließend sollte sich die Linux-basierte .Net-Core-Web-Site mit MS-SQL-Server-Datenbank-Backend und Redis-Cache problemlos aufrufen lassen.

(ID:49626491)