Självstudie: Distribuera en ASP.NET Core- och Azure SQL Database-app till Azure App Service

Artikel
09/29/2024

I den här självstudien får du lära dig hur du distribuerar en datadriven ASP.NET Core-app till Azure App Service och ansluter till en Azure SQL Database. Du distribuerar också en Azure Cache for Redis för att aktivera cachelagringskoden i ditt program. Azure App Service är en mycket skalbar webbvärdtjänst med självkorrigering som enkelt kan distribuera appar i Windows eller Linux. Även om den här självstudien använder en ASP.NET Core 8.0-app är processen densamma för andra versioner av ASP.NET Core.

I den här självstudien lär du dig att:

Skapa en säker App Service-, SQL Database- och Redis-cachearkitektur som standard
Skydda anslutningshemligheter med hjälp av en hanterad identitet och Key Vault-referenser.
Distribuera ett exempel ASP.NET Core-app till App Service från en GitHub-lagringsplats.
Ansluter App Service-anslutningssträng och appinställningar i programkoden.
Gör uppdateringar och distribuera om programkoden.
Generera databasschema genom att ladda upp ett migreringspaket.
Strömma diagnostikloggar från Azure.
Hantera appen i Azure Portal.
Etablera samma arkitektur och distribuera med hjälp av Azure Developer CLI.
Optimera ditt utvecklingsarbetsflöde med GitHub Codespaces och GitHub Copilot.

Förutsättningar

Ett Azure-konto med en aktiv prenumeration. Om du inte har ett Azure-konto kan du skapa ett kostnadsfritt.
Ett GitHub-konto. du kan också få en gratis.
Kunskap om ASP.NET Core-utveckling.
(Valfritt) Prova GitHub Copilot, ett GitHub Copilot-konto. Det finns en kostnadsfri utvärderingsversion på 30 dagar.

Ett Azure-konto med en aktiv prenumeration. Om du inte har ett Azure-konto kan du skapa ett kostnadsfritt.
Azure Developer CLI installerat. Du kan följa stegen med Azure Cloud Shell eftersom Azure Developer CLI redan är installerat.
Kunskap om ASP.NET Core-utveckling.
(Valfritt) Prova GitHub Copilot, ett GitHub Copilot-konto. Det finns en kostnadsfri utvärderingsversion på 30 dagar.

Du kan snabbt distribuera exempelappen i den här självstudien och se den köras i Azure. Kör bara följande kommandon i Azure Cloud Shell och följ anvisningarna:

dotnet tool install --global dotnet-ef
mkdir msdocs-app-service-sqldb-dotnetcore
cd msdocs-app-service-sqldb-dotnetcore
azd init --template msdocs-app-service-sqldb-dotnetcore
azd up

1. Kör exemplet

Först konfigurerar du en exempeldatadriven app som utgångspunkt. Exempellagringsplatsen innehåller för enkelhetens skull en konfiguration av utvecklingscontainer. Utvecklingscontainern har allt du behöver för att utveckla ett program, inklusive databasen, cachen och alla miljövariabler som krävs av exempelprogrammet. Utvecklingscontainern kan köras i ett GitHub-kodområde, vilket innebär att du kan köra exemplet på valfri dator med en webbläsare.

Steg 1: I ett nytt webbläsarfönster:

Logga in på ditt GitHub-konto.
Navigera till https://github.com/Azure-Samples/msdocs-app-service-sqldb-dotnetcore/fork.
Avmarkera Kopiera endast huvudgrenen. Du vill ha alla grenar.
Välj Skapa förgrening.

Steg 2: I GitHub-förgreningen:

Välj main>starter-no-infra för startgrenen. Den här grenen innehåller bara exempelprojektet och inga Azure-relaterade filer eller konfigurationer.
Välj Kod>Skapa kodområde på starter-no-infra. Det tar några minuter att konfigurera kodområdet.

Steg 3: I kodområdesterminalen:

Kör databasmigreringar med dotnet ef database update.
Kör appen med dotnet run.
När du ser meddelandet Your application running on port 5093 is available.väljer du Öppna i webbläsare. Du bör se exempelprogrammet på en ny webbläsarflik. Om du vill stoppa programmet skriver du Ctrl+C.

Dricks

Du kan fråga GitHub Copilot om den här lagringsplatsen. Till exempel:

@workspace Vad gör det här projektet?
@workspace Vad gör mappen .devcontainer?

Har du problem? Kontrollera felsökningsavsnittet.

2. Skapa App Service, databas och cache

I det här steget skapar du Azure-resurserna. Stegen som används i den här självstudien skapar en uppsättning säkra som standardresurser som inkluderar App Service, Azure SQL Database och Azure Cache. För skapandeprocessen anger du:

Webbappens namn . Den används som en del av DNS-namnet för din app i form av https://<app-name>-<hash>.<region>.azurewebsites.net.
Regionen som ska köra appen fysiskt i världen. Den används också som en del av DNS-namnet för din app.
Runtime-stacken för appen. Det är där du väljer den .NET-version som ska användas för din app.
Värdplanen för appen. Det är prisnivån som innehåller uppsättningen funktioner och skalningskapacitet för din app.
Resursgruppen för appen. Med en resursgrupp kan du gruppera (i en logisk container) alla Azure-resurser som behövs för programmet.

Logga in på Azure Portal och följ dessa steg för att skapa dina Azure App Service-resurser.

Steg 1: I Azure Portal:

Ange "webbappdatabas" i sökfältet överst i Azure Portal.
Välj objektet webapp + databas under rubriken Marketplace . Du kan också navigera till guiden för att skapa direkt.

Steg 2: På sidan Skapa webbapp + databas fyller du i formuläret på följande sätt.

Resursgrupp: Välj Skapa ny och använd namnet msdocs-core-sql-tutorial.
Region: Alla Azure-regioner nära dig.
Namn: msdocs-core-sql-XYZ där XYZ är tre slumpmässiga tecken. Användarnamnet måste vara unikt inom Azure.
Körningsstack: .NET 8 (LTS).
Motor: SQLAzure. Azure SQL Database är en fullständigt hanterad paaS-databasmotor (plattform som en tjänst) som alltid körs på den senaste stabila versionen av SQL Server.
Lägg till Azure Cache for Redis?: Ja.
Värdplan: Basic. När du är klar kan du skala upp till en prisnivå för produktion.
Välj Granska + skapa.
När valideringen är klar väljer du Skapa.

Steg 3: Distributionen tar några minuter att slutföra. När distributionen är klar väljer du knappen Gå till resurs . Du tas direkt till App Service-appen, men följande resurser skapas:

Resursgrupp: Containern för alla skapade resurser.
App Service-plan: Definierar beräkningsresurserna för App Service. En Linux-plan på Basic-nivån skapas.
App Service: Representerar din app och körs i App Service-planen.
Virtuellt nätverk: Integrerat med App Service-appen och isolerar serverdelsnätverkstrafik.
Privata slutpunkter: Åtkomstslutpunkter för nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.
Nätverksgränssnitt: Representerar privata IP-adresser, en för var och en av de privata slutpunkterna.
Azure SQL Database-server: Endast tillgänglig bakom den privata slutpunkten.
Azure SQL Database: En databas och en användare skapas åt dig på servern.
Azure Cache for Redis: Endast tillgänglig bakom den privata slutpunkten.
Nyckelvalv: Endast tillgängligt bakom den privata slutpunkten. Används för att hantera hemligheter för App Service-appen.
Privat DNS zoner: Aktivera DNS-matchning av nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.

3. Skydda anslutningshemligheter

Guiden skapa genererade anslutningssträngen åt dig redan som .NET-anslutningssträng och appinställningar. Bästa praxis för säkerhet är dock att hålla hemligheter borta från App Service helt. Du flyttar dina hemligheter till ett nyckelvalv och ändrar appinställningen till Key Vault-referenser med hjälp av Service Connectors.

Dricks

Information om hur du använder lösenordslös autentisering finns i Hur gör jag för att ändra SQL Database-anslutningen till att använda en hanterad identitet i stället?

Steg 1: På App Service-sidan:

I den vänstra menyn väljer du Inställningar > Miljövariabler > Anslutningssträngar.
Välj AZURE_SQL_CONNECTIONSTRING.
I lägg till/redigera anslutningssträng går du till fältet Värde och letar reda på delen Lösenord= i slutet av strängen.
Kopiera lösenordssträngen efter Password= för senare användning. Med den här anslutningssträng kan du ansluta till SQL-databasen som skyddas bakom en privat slutpunkt. Lösenordet sparas direkt i App Service-appen, vilket inte är det bästa. På samma sätt innehåller Redis-cachen anslutningssträng på fliken Appinställningar en hemlighet. Du ändrar det här.

Steg 2: Skapa ett nyckelvalv för säker hantering av hemligheter.

I det övre sökfältet skriver du "key vault" och väljer sedan Marketplace>Key Vault.
I Resursgrupp väljer du msdocs-core-sql-tutorial.
I Key Vault-namn skriver du ett namn som endast består av bokstäver och siffror.
I Region anger du den till exempelplatsen som resursgrupp.

Steg 3:

Välj fliken Nätverk.
Avmarkera Aktivera offentlig åtkomst.
Välj Skapa en privat slutpunkt.
I Resursgrupp väljer du msdocs-core-sql-tutorial.
I Key Vault-namn skriver du ett namn som endast består av bokstäver och siffror.
I Region anger du den till exempelplatsen som resursgrupp.
I dialogrutan i Plats väljer du samma plats som din App Service-app.
I Resursgrupp väljer du msdocs-core-sql-tutorial.
I Namn skriver du msdocs-core-sql-XYZVvaultEndpoint.
I Virtuellt nätverk väljer du msdocs-core-sql-XYZVnet.
I undernätet msdocs-core-sql-XYZSubnet.
Välj OK.
Välj Granska + skapa och välj sedan Skapa. Vänta tills key vault-distributionen är klar. Du bör se "Distributionen är klar".

Steg 4:

I det övre sökfältet skriver du msdocs-core-sql och sedan App Service-resursen msdocs-core-sql-XYZ.
På sidan App Service går du till den vänstra menyn och väljer Inställningar > Tjänstanslutning. Det finns redan två anslutningsappar som guiden för att skapa appen har skapats åt dig.
Markera kryssrutan bredvid SQL Database-anslutningsappen och välj sedan Redigera.
Markera fliken autentisering.
I Lösenord klistrar du in lösenordet som du kopierade tidigare.
Välj Lagra hemlighet i Key Vault.
Under Key Vault-anslutning väljer du Skapa ny. Dialogrutan Skapa anslutning öppnas ovanpå redigeringsdialogrutan.

Steg 5: I dialogrutan Skapa anslutning för Key Vault-anslutningen:

I Key Vault väljer du det nyckelvalv som du skapade tidigare.
Välj Granska + skapa. Du bör se att Systemtilldelad hanterad identitet är inställd på Vald.
När verifieringen är klar väljer du Skapa.

Steg 6: Du är tillbaka i redigeringsdialogrutan för defaultConnector.

På fliken Autentisering väntar du tills key vault-anslutningsappen har skapats. När den är klar väljer listrutan Key Vault-anslutning automatiskt den.
Välj Nästa: Nätverk.
Välj Konfigurera brandväggsregler för att aktivera åtkomst till måltjänsten. Guiden för att skapa appar har redan skyddat SQL-databasen med en privat slutpunkt.
Välj Spara. Vänta tills meddelandet Uppdatera lyckades visas.

Steg 7: På sidan Tjänstanslutningsprogram:

Markera kryssrutan bredvid Cache for Redis-anslutningsappen och välj sedan Redigera.
Markera fliken autentisering.
Välj Lagra hemlighet i Key Vault.
Under Key Vault-anslutning väljer du det nyckelvalv som du skapade.
Välj Nästa: Nätverk.
Välj Konfigurera brandväggsregler för att aktivera åtkomst till måltjänsten. Guiden för att skapa appar har redan skyddat SQL-databasen med en privat slutpunkt.
Välj Spara. Vänta tills meddelandet Uppdatera lyckades visas.

Steg 8: Verifiera ändringarna:

På den vänstra menyn väljer du Miljövariabler > Anslutningssträngar igen.
Bredvid AZURE_SQL_CONNECTIONSTRING väljer du Visa värde. Värdet ska vara @Microsoft.KeyVault(...), vilket innebär att det är en nyckelvalvsreferens eftersom hemligheten nu hanteras i nyckelvalvet.
Om du vill verifiera Redis-anslutningssträng väljer du fliken Appinställning. Bredvid AZURE_REDIS_CONNECTIONSTRING väljer du Visa värde. Värdet bör också vara @Microsoft.KeyVault(...) .

4. Distribuera exempelkod

I det här steget konfigurerar du GitHub-distribution med GitHub Actions. Det är bara ett av många sätt att distribuera till App Service, men också ett bra sätt att ha kontinuerlig integrering i distributionsprocessen. Som standard startar varje git push till din GitHub-lagringsplats bygg- och distributionsåtgärden.

Steg 1: I den vänstra menyn väljer du Distributionsdistributionscenter>.

Steg 2: På sidan Distributionscenter:

I Källa väljer du GitHub. Som standard är GitHub Actions valt som byggprovider.
Logga in på ditt GitHub-konto och följ anvisningarna för att auktorisera Azure.
I Organisation väljer du ditt konto.
I Lagringsplats väljer du msdocs-app-service-sqldb-dotnetcore.
I Gren väljer du starter-no-infra. Det här är samma gren som du arbetade i med exempelappen, utan några Azure-relaterade filer eller konfigurationer.
Som Autentiseringstyp väljer du Användartilldelad identitet.
I den översta menyn väljer du Spara. App Service checkar in en arbetsflödesfil i den valda GitHub-lagringsplatsen i .github/workflows katalogen. Som standard skapar distributionscentret en användartilldelad identitet för arbetsflödet som ska autentiseras med Hjälp av Microsoft Entra (OIDC-autentisering). Alternativa autentiseringsalternativ finns i Distribuera till App Service med GitHub Actions.

Steg 3: Kör i GitHub-kodområdet i exempelgrenen git pull origin starter-no-infra. Detta hämtar den nyligen incheckade arbetsflödesfilen till ditt kodområde.

Steg 4 (alternativ 1: med GitHub Copilot):

Starta en ny chattsession genom att välja vyn Chatt och sedan välja +.
Fråga: "@workspace Hur ansluter appen till databasen och cachen?" Copilot kan ge dig en förklaring om klassen och hur den MyDatabaseContext konfigureras i Program.cs.
Fråga: "I produktionsläge vill jag att appen ska använda anslutningssträng som heter AZURE_SQL_CONNECTIONSTRING för databasen och appinställningen med namnet AZURE_REDIS_CONNECTIONSTRING*." Copilot kan ge dig ett kodförslag som liknar det i alternativ 2: utan GitHub Copilot-stegen nedan och till och med be dig att göra ändringen i filen Program.cs.
Öppna Program.cs i utforskaren och lägg till kodförslaget. GitHub Copilot ger dig inte samma svar varje gång, och det är inte alltid korrekt. Du kan behöva ställa fler frågor för att finjustera svaret. Tips finns i Vad kan jag göra med GitHub Copilot i mitt kodområde?.

Steg 4 (alternativ 2: utan GitHub Copilot):

Öppna Program.cs i utforskaren.
Leta upp den kommenterade koden (raderna 12–21) och ta bort kommentaren. Den här koden ansluter till databasen med hjälp AZURE_SQL_CONNECTIONSTRING av och ansluter till Redis-cachen med hjälp av appinställningen AZURE_REDIS_CONNECTIONSTRING.

Steg 5 (alternativ 1: med GitHub Copilot):

Öppna .github/workflows/starter-no-infra_msdocs-core-sql-XYZ i utforskaren. Den här filen skapades av guiden Skapa apptjänst.
Markera steget dotnet publish och välj .
Fråga Copilot: "Installera dotnet ef och skapa sedan ett migreringspaket i samma utdatamapp.".
Om förslaget är acceptabelt väljer du Acceptera. GitHub Copilot ger dig inte samma svar varje gång, och det är inte alltid korrekt. Du kan behöva ställa fler frågor för att finjustera svaret. Tips finns i Vad kan jag göra med GitHub Copilot i mitt kodområde?.

Steg 5 (alternativ 2: utan GitHub Copilot):

Öppna .github/workflows/starter-no-infra_msdocs-core-sql-XYZ i utforskaren. Den här filen skapades av guiden Skapa apptjänst.
Under steget dotnet publish lägger du till ett steg för att installera Entity Framework Core-verktyget med kommandot dotnet tool install -g dotnet-ef --version 8.*.
Under det nya steget lägger du till ytterligare ett steg för att generera ett databasmigreringspaket i distributionspaketet: dotnet ef migrations bundle --runtime linux-x64 -o ${{env.DOTNET_ROOT}}/myapp/migrationsbundle. Migreringspaketet är en fristående körbar fil som du kan köra i produktionsmiljön utan att behöva .NET SDK. App Service Linux-containern har bara .NET-körningen och inte .NET SDK.

Steg 6:

Välj källkontrolltillägget.
I textrutan skriver du ett incheckningsmeddelande som Configure Azure database and cache connections. Eller välj och låt GitHub Copilot generera ett incheckningsmeddelande åt dig.
Välj Checka in och bekräfta sedan med Ja.
Välj Synkronisera ändringar 1 och bekräfta sedan med OK.

Steg 7: Tillbaka på sidan Distributionscenter i Azure Portal:

Välj fliken Loggar och välj sedan Uppdatera för att se den nya distributionskörningen.
I loggobjektet för distributionskörningen väljer du posten Skapa/distribuera loggar med den senaste tidsstämpeln .

Steg 8: Du tas till din GitHub-lagringsplats och ser att GitHub-åtgärden körs. Arbetsflödesfilen definierar två separata steg, skapa och distribuera. Vänta tills GitHub-körningen visar statusen Lyckades. Det tar ungefär 5 minuter.

5. Generera databasschema

Med SQL Database som skyddas av det virtuella nätverket är det enklaste sättet att köra dotnet-databasmigreringar i en SSH-session med App Service-containern.

Steg 1: Gå tillbaka till App Service-sidan i den vänstra menyn, välj Utvecklingsverktyg>SSH och välj sedan Gå.

Steg 2: I SSH-terminalen:

Kör cd /home/site/wwwroot. Här är alla dina distribuerade filer.
Kör migreringspaketet som GitHub-arbetsflödet genererade med kommandot ./migrationsbundle -- --environment Production. Om det lyckas ansluter App Service till SQL Database. Kom ihåg att --environment Production motsvarar de kodändringar som du gjorde i Program.cs.

I SSH-sessionen kan endast ändringar av filer i /home sparas utöver omstarter av appar. Ändringar utanför /home sparas inte.

Har du problem? Kontrollera felsökningsavsnittet.

6. Bläddra till appen

Steg 1: På App Service-sidan:

Välj Översikt på den vänstra menyn.
Välj appens URL.

Steg 2: Lägg till några uppgifter i listan. Grattis, du kör en säker datadriven ASP.NET Core-app i Azure App Service.

Dricks

Exempelprogrammet implementerar cache-aside-mönstret . När du besöker en datavy för andra gången, eller läser in samma sida igen när du har gjort dataändringar, visar bearbetningstiden på webbsidan en mycket snabbare tid eftersom den läser in data från cacheminnet i stället för databasen.

7. Strömma diagnostikloggar

Azure App Service samlar in alla meddelanden som loggas till konsolen för att hjälpa dig att diagnostisera problem med ditt program. Exempelappen matar ut konsolloggmeddelanden i var och en av sina slutpunkter för att demonstrera den här funktionen.

Steg 1: På App Service-sidan:

Välj Övervaka>App Service-loggar på den vänstra menyn.
Under Programloggning väljer du Filsystem och sedan Spara.

Steg 2: Välj Loggström på den vänstra menyn. Du ser loggarna för din app, inklusive plattformsloggar och loggar inifrån containern.

8. Rensa resurser

När du är klar kan du ta bort alla resurser från din Azure-prenumeration genom att ta bort resursgruppen.

Steg 1: I sökfältet överst i Azure Portal:

Ange resursgruppsnamnet.
Välj resursgruppen.

Steg 2: På resursgruppssidan väljer du Ta bort resursgrupp.

Steg 3:

Ange resursgruppens namn för att bekräfta borttagningen.
Välj Ta bort.

2. Skapa Azure-resurser och distribuera en exempelapp

I det här steget skapar du Azure-resurserna och distribuerar en exempelapp för att App Service på Linux. Stegen som används i den här självstudien skapar en uppsättning säkra resurser som standard som inkluderar App Service, Azure SQL Database och Azure Cache for Redis.

Utvecklingscontainern har redan Azure Developer CLI (AZD).

Från lagringsplatsens rot kör du azd init.

azd init --template dotnet-app-service-sqldb-infra

När du uppmanas att ge följande svar:

Fråga	Svar
Den aktuella katalogen är inte tom. Vill du initiera ett projekt här i "<din katalog>"?	Y
Vad vill du göra med de här filerna?	Behåll mina befintliga filer oförändrade
Ange ett nytt miljönamn	Skriv ett unikt namn. AZD-mallen använder det här namnet som en del av DNS-namnet på din webbapp i Azure (`<app-name>-<hash>.azurewebsites.net`). Alfanumeriska tecken och bindestreck tillåts.

Logga in på Azure genom att azd auth login köra kommandot och följa kommandotolken:
```
azd auth login
```
Skapa nödvändiga Azure-resurser och distribuera appkoden med azd up kommandot . Följ uppmaningen för att välja önskad prenumeration och plats för Azure-resurserna.
```
azd up
```
Kommandot azd up tar cirka 15 minuter att slutföra (Redis-cachen tar mest tid). Den kompilerar och distribuerar även programkoden, men du ändrar koden senare så att den fungerar med App Service. När den körs innehåller kommandot meddelanden om etablerings- och distributionsprocessen, inklusive en länk till distributionen i Azure. När det är klart visar kommandot även en länk till distributionsprogrammet.

Den här AZD-mallen innehåller filer (azure.yaml och infra-katalogen ) som genererar en säker arkitektur som standard med följande Azure-resurser:
- Resursgrupp: Containern för alla skapade resurser.
- App Service-plan: Definierar beräkningsresurserna för App Service. En Linux-plan på Basic-nivån skapas.
- App Service: Representerar din app och körs i App Service-planen.
- Virtuellt nätverk: Integrerat med App Service-appen och isolerar serverdelsnätverkstrafik.
- Privata slutpunkter: Åtkomstslutpunkter för nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.
- Nätverksgränssnitt: Representerar privata IP-adresser, en för var och en av de privata slutpunkterna.
- Azure SQL Database-server: Endast tillgänglig bakom den privata slutpunkten.
- Azure SQL Database: En databas och en användare skapas åt dig på servern.
- Azure Cache for Redis: Endast tillgänglig bakom den privata slutpunkten.
- Nyckelvalv: Endast tillgängligt bakom den privata slutpunkten. Används för att hantera hemligheter för App Service-appen.
- Privat DNS zoner: Aktivera DNS-matchning av nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.
När kommandot har skapat resurser och distribuerat programkoden första gången fungerar inte den distribuerade exempelappen ännu eftersom du måste göra små ändringar för att den ska kunna ansluta till databasen i Azure.

Har du problem? Kontrollera felsökningsavsnittet.

3. Kontrollera anslutningssträng

Dricks

Sql-standarddatabasen anslutningssträng använder SQL-autentisering. Mer säker och lösenordslös autentisering finns i Hur gör jag för att ändra SQL Database-anslutningen till att använda en hanterad identitet i stället?

Den AZD-mall som du använder genererade anslutningsvariablerna åt dig redan som appinställningar och matar ut dem till terminalen för din bekvämlighet. Appinställningar är ett sätt att hålla anslutningshemligheter borta från din kodlagringsplats.

I AZD-utdata hittar du inställningarna AZURE_SQL_CONNECTIONSTRING och AZURE_REDIS_CONNECTIONSTRING. Endast inställningsnamnen visas. De ser ut så här i AZD-utdata:
```
 App Service app has the following connection strings:
     - AZURE_SQL_CONNECTIONSTRING
     - AZURE_REDIS_CONNECTIONSTRING
     - AZURE_KEYVAULT_RESOURCEENDPOINT
     - AZURE_KEYVAULT_SCOPE
 
```
AZURE_SQL_CONNECTIONSTRINGinnehåller anslutningssträng till SQL Database i Azure och AZURE_REDIS_CONNECTIONSTRING innehåller anslutningssträng till Azure Redis-cachen. Du måste använda dem i koden senare.
För att underlätta för dig visar AZD-mallen direktlänken till appens appinställningarssida. Hitta länken och öppna den på en ny webbläsarflik.

Har du problem? Kontrollera felsökningsavsnittet.

I GitHub-kodområdet startar du en ny chattsession genom att välja vyn Chatt och sedan välja +.
Fråga: "@workspace Hur ansluter appen till databasen och cachen?" Copilot kan ge dig en förklaring om klassen och hur den MyDatabaseContext konfigureras i Program.cs.
Fråga: "I produktionsläge vill jag att appen ska använda anslutningssträng som heter AZURE_SQL_CONNECTIONSTRING för databasen och appinställningen med namnet AZURE_REDIS_CONNECTIONSTRING*." Copilot kan ge dig ett kodförslag som liknar det i alternativ 2: utan GitHub Copilot-stegen nedan och till och med be dig att göra ändringen i filen Program.cs.
Öppna Program.cs i utforskaren och lägg till kodförslaget.

GitHub Copilot ger dig inte samma svar varje gång, och det är inte alltid korrekt. Du kan behöva ställa fler frågor för att finjustera svaret. Tips finns i Vad kan jag göra med GitHub Copilot i mitt kodområde?.

Öppna Program.cs från utforskaren.

contextIntialized() I metoden letar du upp den kommenterade koden (raderna 12–21) och avkommenteras.

else
{
    builder.Services.AddDbContext<MyDatabaseContext>(options =>
        options.UseSqlServer(builder.Configuration.GetConnectionString("AZURE_SQL_CONNECTIONSTRING")));
    builder.Services.AddStackExchangeRedisCache(options =>
    {
    options.Configuration = builder.Configuration["AZURE_REDIS_CONNECTIONSTRING"];
    options.InstanceName = "SampleInstance";
    });
}

När appen inte är i utvecklingsläge (till exempel i Azure App Service) ansluter den här koden till databasen med hjälp AZURE_SQL_CONNECTIONSTRING av och ansluter till Redis-cachen med hjälp av appinställningen AZURE_REDIS_CONNECTIONSTRING.

Innan du distribuerar dessa ändringar måste du fortfarande generera ett migreringspaket.

Har du problem? Kontrollera felsökningsavsnittet.

5. Generera databasschema

Med SQL Database som skyddas av det virtuella nätverket är det enklaste sättet att köra databasmigreringar i en SSH-session med App Service-containern. Men App Service Linux-containrarna har inte .NET SDK, så det enklaste sättet att köra databasmigreringar är att ladda upp ett fristående migreringspaket.

Generera ett migreringspaket för projektet med följande kommando:
```
dotnet ef migrations bundle --runtime linux-x64 -o migrationsbundle
```
Dricks

Exempelprogrammet (se DotNetCoreSqlDb.csproj) har konfigurerats för att inkludera den här migreringsbundle-filen . azd package Under fasen läggs migreringsbundle till i distributionspaketet.
Distribuera alla ändringar med azd up.
```
azd up
```
I azd-utdata letar du upp URL:en för SSH-sessionen och navigerar till den i webbläsaren. Det ser ut så här i utdata:
```
 Open SSH session to App Service container at: https://<app-name>-<hash>.scm.azurewebsites.net/webssh/host
 
```
Kör följande kommandon i SSH-terminalen:
```
cd /home/site/wwwroot
./migrationsbundle -- --environment Production
```
Om det lyckas ansluter App Service till databasen. Kom ihåg att --environment Production motsvarar de kodändringar som du gjorde i Program.cs.

I SSH-sessionen kan endast ändringar av filer i /home sparas utöver omstarter av appar. Ändringar utanför /home sparas inte.

Har du problem? Kontrollera felsökningsavsnittet.

6. Bläddra till appen

I AZD-utdata letar du reda på url:en för din app och navigerar till den i webbläsaren. URL:en ser ut så här i AZD-utdata:

 Deploying services (azd deploy)

   (✓) Done: Deploying service web
   - Endpoint: https://<app-name>-<hash>.azurewebsites.net/

Lägg till några uppgifter i listan.

Grattis, du kör en webbapp i Azure App Service med säker anslutning till Azure SQL Database.

Har du problem? Kontrollera felsökningsavsnittet.

7. Strömma diagnostikloggar

Azure App Service kan samla in konsolloggar som hjälper dig att diagnostisera problem med ditt program. För enkelhetens skull har AZD-mallen redan aktiverat loggning till det lokala filsystemet och skickar loggarna till en Log Analytics-arbetsyta.

Exempelprogrammet innehåller standardloggningsinstruktioner för att demonstrera den här funktionen, enligt följande kodfragment:

public async Task<IActionResult> Index()
{
    var todoItems = await _cache.GetAsync(_TodoItemsCacheKey);
    if (todoItems != null)
    {
        _logger.LogInformation("Data from cache.");
        var todoList = JsonConvert.DeserializeObject<List<Todo>>(Encoding.UTF8.GetString(todoItems));
        return View(todoList);
    }
    else
    {
        _logger.LogInformation("Data from database.");
        var todoList = await _context.Todo.ToListAsync();
        var serializedTodoList = JsonConvert.SerializeObject(todoList);
        await _cache.SetAsync(_TodoItemsCacheKey, Encoding.UTF8.GetBytes(serializedTodoList));
        return View(todoList);
    }
}

I AZD-utdata hittar du länken för att strömma App Service-loggar och navigera till den i webbläsaren. Länken ser ut så här i AZD-utdata:

Stream App Service logs at: https://portal.azure.com/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream

Läs mer om loggning i .NET-appar i serien på Aktivera Azure Monitor OpenTelemetry för .NET-, Node.js-, Python- och Java-program.

Har du problem? Kontrollera felsökningsavsnittet.

8. Rensa resurser

Om du vill ta bort alla Azure-resurser i den aktuella distributionsmiljön kör azd down du och följer anvisningarna.

azd down

Felsökning

Portaldistributionsvyn för Azure SQL Database visar statusen Konflikt
I Azure Portal visar loggströmsgränssnittet för webbappen nätverksfel
SSH-sessionen i webbläsaren visar SSH CONN CLOSED
Portalloggströmsidan visas Connected! men inga loggar

Portaldistributionsvyn för Azure SQL Database visar statusen Konflikt

Beroende på din prenumeration och den region du väljer kan distributionsstatusen för Azure SQL Database vara Conflict, med följande meddelande i Åtgärdsinformation:

Location '<region>' is not accepting creation of new Windows Azure SQL Database servers at this time.

Det här felet orsakas troligen av en gräns för din prenumeration för den region du väljer. Prova att välja en annan region för distributionen.

I Azure Portal visar loggströmsgränssnittet för webbappen nätverksfel

Du kan se det här felet:

Unable to open a connection to your app. This may be due to any network security groups or IP restriction rules that you have placed on your app. To use log streaming, please make sure you are able to access your app directly from your current network.

Detta är vanligtvis ett tillfälligt fel när appen startas först. Vänta några minuter och kontrollera igen.

SSH-sessionen i webbläsaren visar `SSH CONN CLOSED`

Det tar några minuter innan Linux-containern startas. Vänta några minuter och kontrollera igen.

Portalloggströmsidan visas `Connected!` men inga loggar

När du har konfigurerat diagnostikloggar startas appen om. Du kan behöva uppdatera sidan för att ändringarna ska börja gälla i webbläsaren.

Vanliga frågor och svar

Hur mycket kostar den här installationen?
Hur gör jag för att ansluta till Azure SQL Database-servern som skyddas bakom det virtuella nätverket med andra verktyg?
Hur fungerar utveckling av lokala appar med GitHub Actions?
Hur gör jag för att felsöka under GitHub Actions-distributionen?
Hur gör jag för att ändra SQL Database-anslutningen så att den använder en hanterad identitet i stället?
Jag har inte behörighet att skapa en användartilldelad identitet
Vad kan jag göra med GitHub Copilot i mitt kodområde?

Hur mycket kostar den här installationen?

Prissättningen för de skapade resurserna är följande:

App Service-planen skapas på Basic-nivån och kan skalas upp eller ned. Se Priser för App Service.
Azure SQL Database skapas på en serverlös nivå för generell användning på Standard-seriens maskinvara med minsta möjliga kärnor. Det finns en liten kostnad och kan distribueras till andra regioner. Du kan minimera kostnaderna ännu mer genom att minska dess maximala storlek, eller så kan du skala upp den genom att justera servernivå, beräkningsnivå, maskinvarukonfiguration, antal kärnor, databasstorlek och zonredundans. Läs mer i Prissättning för Azure SQL Database.
Azure Cache for Redis skapas på Basic-nivån med den minsta cachestorleken. Det finns en liten kostnad som är associerad med den här nivån. Du kan skala upp den till högre prestandanivåer för högre tillgänglighet, klustring och andra funktioner. Se Priser för Azure Cache for Redis.
Det virtuella nätverket debiteras inte om du inte konfigurerar extra funktioner, till exempel peering. Se Priser för Azure Virtual Network.
Den privata DNS-zonen medför en liten avgift. Se Priser för Azure DNS.

Hur gör jag för att ansluta till Azure SQL Database-servern som skyddas bakom det virtuella nätverket med andra verktyg?

För grundläggande åtkomst från ett kommandoradsverktyg kan du köra sqlcmd från appens SSH-terminal. Appens container levereras inte med sqlcmd, så du måste installera den manuellt. Kom ihåg att den installerade klienten inte finns kvar i omstarter av appar.
Om du vill ansluta från en SQL Server Management Studio-klient eller från Visual Studio måste datorn finnas i det virtuella nätverket. Det kan till exempel vara en virtuell Azure-dator som är ansluten till ett av undernäten, eller en dator i ett lokalt nätverk som har en plats-till-plats-VPN-anslutning med det virtuella Azure-nätverket.

Hur fungerar utveckling av lokala appar med GitHub Actions?

Ta den autogenererade arbetsflödesfilen från App Service som exempel. Var git push och en startar en ny version och distributionskörning. Från en lokal klon av GitHub-lagringsplatsen får du önskade uppdateringar att skicka den till GitHub. Till exempel:

git add .
git commit -m "<some-message>"
git push origin main

Hur gör jag för att felsöka under GitHub Actions-distributionen?

Om ett steg misslyckas i den autogenererade GitHub-arbetsflödesfilen kan du prova att ändra det misslyckade kommandot för att generera mer utförliga utdata. Du kan till exempel få mer utdata från något av dotnet kommandona genom att lägga till alternativet -v . Checka in och skicka ändringarna för att utlösa en annan distribution till App Service.

Jag har inte behörighet att skapa en användartilldelad identitet

Se Konfigurera GitHub Actions-distribution från Distributionscenter.

Hur gör jag för att ändra SQL Database-anslutningen så att den använder en hanterad identitet i stället?

Standard anslutningssträng till SQL-databasen hanteras av Service Connector, med namnet defaultConnector, och den använder SQL-autentisering. Om du vill ersätta den med en anslutning som använder en hanterad identitet kör du följande kommandon i Cloud Shell när du har ersatt platshållarna:

az extension add --name serviceconnector-passwordless --upgrade
az sql server update --enable-public-network true
az webapp connection delete sql --connection defaultConnector --resource-group <group-name> --name <app-name>
az webapp connection create sql --connection defaultConnector --resource-group <group-name> --name <app-name> --target-resource-group <group-name> --server <database-server-name> --database <database-name> --client-type dotnet --system-identity --config-connstr true
az sql server update --enable-public-network false

Som standard gör kommandot az webapp connection create sql --client-type dotnet --system-identity --config-connstr följande:

Anger användaren som Microsoft Entra-ID-administratör för SQL-databasservern.
Skapa en systemtilldelad hanterad identitet och ge den åtkomst till databasen.
Genererar ett lösenordslöst anslutningssträng med namnet AZURE_SQL_CONNECTIONGSTRING, som appen redan använder i slutet av självstudien.

Din app bör nu ha anslutning till SQL-databasen. Mer information finns i Självstudie: Ansluta till Azure-databaser från App Service utan hemligheter med hjälp av en hanterad identitet.

Dricks

Vill du inte aktivera offentlig nätverksanslutning? Du kan hoppa över az sql server update --enable-public-network true genom att köra kommandona från ett Azure Cloud Shell som är integrerat med ditt virtuella nätverk om du har rollen Ägare i din prenumeration.

För att ge identiteten den nödvändiga åtkomsten till databasen som skyddas av det virtuella nätverket az webapp connection create sql behöver du direktanslutning med Entra-ID-autentisering till databasservern. Som standard har Azure Cloud Shell inte den här åtkomsten till den nätverkssäkra databasen.

Vad kan jag göra med GitHub Copilot i mitt kodområde?

Du kanske har märkt att GitHub Copilot-chattvyn redan fanns där när du skapade kodområdet. För din bekvämlighet inkluderar vi GitHub Copilot-chatttillägget i containerdefinitionen (se .devcontainer/devcontainer.json). Du behöver dock ett GitHub Copilot-konto (30 dagars kostnadsfri utvärderingsversion tillgänglig).

Några tips när du pratar med GitHub Copilot:

I en enda chattsession bygger frågorna och svaren på varandra och du kan justera dina frågor för att finjustera det svar du får.
Som standard har GitHub Copilot inte åtkomst till någon fil på lagringsplatsen. Om du vill ställa frågor om en fil öppnar du filen i redigeraren först.
Om du vill ge GitHub Copilot åtkomst till alla filer på lagringsplatsen när du förbereder dess svar börjar du din fråga med @workspace. Mer information finns i Use the @workspace agent.
I chattsessionen kan GitHub Copilot föreslå ändringar och (med @workspace) även var ändringarna ska utföras, men det är inte tillåtet att göra ändringarna åt dig. Det är upp till dig att lägga till de föreslagna ändringarna och testa dem.

Här är några andra saker du kan säga för att finjustera svaret du får:

Jag vill att den här koden endast ska köras i produktionsläge.
Jag vill att den här koden endast ska köras i Azure App Service och inte lokalt.
Parametern --output-path verkar inte ha stöd.

Gå vidare till nästa självstudie för att lära dig hur du skyddar din app med en anpassad domän och ett certifikat.

Skydda med anpassad domän och certifikat

Eller kolla in andra resurser:

Självstudie: Ansluta till SQL Database från App Service utan hemligheter med hjälp av en hanterad identitet

Konfigurera ASP.NET Core-appen

Dela via

Självstudie: Distribuera en ASP.NET Core- och Azure SQL Database-app till Azure App Service

Förutsättningar

1. Kör exemplet

2. Skapa App Service, databas och cache

3. Skydda anslutningshemligheter

4. Distribuera exempelkod

5. Generera databasschema

6. Bläddra till appen

7. Strömma diagnostikloggar

8. Rensa resurser

2. Skapa Azure-resurser och distribuera en exempelapp

3. Kontrollera anslutningssträng

4. Ändra exempelkod och distribuera om

5. Generera databasschema

6. Bläddra till appen

7. Strömma diagnostikloggar

8. Rensa resurser

Felsökning

Portaldistributionsvyn för Azure SQL Database visar statusen Konflikt

I Azure Portal visar loggströmsgränssnittet för webbappen nätverksfel

SSH-sessionen i webbläsaren visar `SSH CONN CLOSED`

Portalloggströmsidan visas `Connected!` men inga loggar

Vanliga frågor och svar

Hur mycket kostar den här installationen?

Hur gör jag för att ansluta till Azure SQL Database-servern som skyddas bakom det virtuella nätverket med andra verktyg?

Hur fungerar utveckling av lokala appar med GitHub Actions?

Hur gör jag för att felsöka under GitHub Actions-distributionen?

Jag har inte behörighet att skapa en användartilldelad identitet

Hur gör jag för att ändra SQL Database-anslutningen så att den använder en hanterad identitet i stället?

Vad kan jag göra med GitHub Copilot i mitt kodområde?

Feedback

Ytterligare resurser

Dela via

Självstudie: Distribuera en ASP.NET Core- och Azure SQL Database-app till Azure App Service

Förutsättningar

Hoppa till slutet

1. Kör exemplet

2. Skapa App Service, databas och cache

3. Skydda anslutningshemligheter

4. Distribuera exempelkod

5. Generera databasschema

6. Bläddra till appen

7. Strömma diagnostikloggar

8. Rensa resurser

2. Skapa Azure-resurser och distribuera en exempelapp

3. Kontrollera anslutningssträng

4. Ändra exempelkod och distribuera om

5. Generera databasschema

6. Bläddra till appen

7. Strömma diagnostikloggar

8. Rensa resurser

Felsökning

Portaldistributionsvyn för Azure SQL Database visar statusen Konflikt

I Azure Portal visar loggströmsgränssnittet för webbappen nätverksfel

SSH-sessionen i webbläsaren visar SSH CONN CLOSED

Portalloggströmsidan visas Connected! men inga loggar

Vanliga frågor och svar

Hur mycket kostar den här installationen?

Hur gör jag för att ansluta till Azure SQL Database-servern som skyddas bakom det virtuella nätverket med andra verktyg?

Hur fungerar utveckling av lokala appar med GitHub Actions?

Hur gör jag för att felsöka under GitHub Actions-distributionen?

Jag har inte behörighet att skapa en användartilldelad identitet

Hur gör jag för att ändra SQL Database-anslutningen så att den använder en hanterad identitet i stället?

Vad kan jag göra med GitHub Copilot i mitt kodområde?

Relaterat innehåll

Feedback

Ytterligare resurser

SSH-sessionen i webbläsaren visar `SSH CONN CLOSED`

Portalloggströmsidan visas `Connected!` men inga loggar