Handledning: Distribuera en applikation med ASP.NET Core och Azure SQL Database till Azure App Service

I denna handledning lär du dig hur man distribuerar en datadriven ASP.NET Core-applikation till Azure App Service och ansluter till en Azure SQL-databas. Du kommer också att distribuera en Azure Cache för Redis för att aktivera cachekod i din applikation. Azure App Service är en mycket skalbar, självkorrigerande webbhotelltjänst som enkelt kan distribuera appar på Windows eller Linux. Även om denna handledning använder en ASP.NET Core 8.0-app, är processen densamma för andra versioner av ASP.NET Core.

I denna handledning lär du dig hur du:

• Skapa en säker som standard App Service, SQL-databas och Redis-cache-arkitektur.
• Skydda anslutningshemligheter med en hanterad identitet och referenser till Key Vault.
• Distribuera ett exempel på en ASP.NET Core-app till App Service från ett GitHub-repositorium.
• Få åtkomst till anslutningssträngar och inställningar för App Service i applikationskoden.
• Gör uppdateringar och distribuera om applikationskoden.
• Generera databasens schema genom att ladda upp ett migreringspaket.
• Streama diagnostikloggar från Azure.
• Hantera appen i Azure-portalen.
• Tillhandahåll samma arkitektur och distribuera genom att använda 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 gratis.
• Ett GitHub-konto. Du kan också få en gratis.
• Kunskap i ASP.NET Core-utveckling.
• (Valfritt) För att prova GitHub Copilot krävs ett GitHub Copilot-konto. En 30-dagars gratis provperiod är tillgänglig.

• Ett Azure-konto med en aktiv prenumeration. Om du inte har ett Azure-konto, kan du skapa ett gratis.
• Azure Developer CLI installerat. Du kan följa stegen med Azure Cloud Shell eftersom den redan har Azure Developer CLI installerad.
• Kunskap i ASP.NET Core-utveckling.
• (Valfritt) För att prova GitHub Copilot krävs ett GitHub Copilot-konto. En 30-dagars gratis provperiod är tillgänglig.

Hoppa till slutet

Om du bara vill se exempelappen i den här handledningen som körs i Azure, kör bara följande kommandon i Azure Cloud Shell och följ instruktionerna.

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 sätter du upp en exempelapp baserad på data som en startpunkt. För din bekvämlighet innehåller exemplarkatalogen en utvecklingscontainerkonfiguration. Utvecklingscontainern innehåller allt du behöver för att utveckla en applikation, inklusive databasen, cachen och alla miljövariabler som behövs av exempelapplikationen. Utvecklingsbehållaren kan köras i en GitHub codespace, vilket innebär att du kan köra exemplet på vilken dator som helst med en webbläsare.

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

1. Logga in på ditt GitHub-konto.
2. Navigera till https://github.com/Azure-Samples/msdocs-app-service-sqldb-dotnetcore/fork.
3. Avmarkera Copy the main branch only. Du vill ha alla grenarna.
4. Välj Skapa förgrening.

Steg 2: I GitHub-forken:

1. Välj main>starter-no-infra för startgrenen. Denna gren innehåller endast exempelprojektet och inga Azure-relaterade filer eller konfigurationer.
2. Välj Code>Codespaces>Skapa kodområde på starter-no-infra. Det tar några minuter att ställa in codespace.

Steg 3: I koderummets terminal:

1. Kör databasmigrationer med dotnet ef database update.
2. Kör appen med dotnet run.
3. När du ser meddelandet Your application running on port 5093 is available., välj Öppna i webbläsare. Du bör se exempelapplikationen i en ny webbläsarflik. För att stoppa applikationen, skriv Ctrl+C.

Tips

Du kan fråga GitHub Copilot om det här arkivet. Till exempel:

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

Har du problem? Kontrollera felsökningssektionen.

2. Skapa App Service, databas och cache

I det här steget skapar du Azure-resurserna. De steg som används i denna handledning skapar en uppsättning resurser som är "säkra som standard" och inkluderar App Service, Azure SQL Database och Azure Cache. För skapandeprocessen ska du ange:

• Namnet för webbappen. Den används som en del av DNS-namnet för din app.
• Regionen där appen körs fysiskt i världen. Det används också som en del av DNS-namnet för din app.
• Körstacken för appen. Det är här du väljer vilken .NET-version du vill använda för din app.
• Hosting-planen för appen. Det är prissättningsnivån som inkluderar uppsättningen av funktioner och skalningskapacitet för din app.
• Resursgrupp för appen. En resursgrupp låter dig gruppera (i en logisk behållare) alla Azure-resurser som behövs för applikationen.

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

Steg 1: I Azure-portalen:

1. Skriv in "webbappdatabas" i sökfältet högst upp på Azure-portalen.
2. Välj det objekt som är märkt Webbapp + Databas under rubriken Marknadsplats. Du kan också navigera till skapar-guiden direkt.

Steg 2: På sidan Skapa webbapp + databas, fyll i formuläret enligt följande.

1. Resursgrupp: Välj Skapa ny och använd namnet msdocs-core-sql-tutorial.
2. Region: Valfri Azure-region nära dig.
3. Namn: msdocs-core-sql-XYZ där XYZ är tre valfria slumpmässiga tecken. Det här namnet måste vara unikt över hela Azure.
4. Körningsstack: .NET 8 (LTS).
5. Motor: SQLAzure. Azure SQL Database är en fullständigt hanterad databasmotor som tjänst (PaaS) som alltid körs på den senaste stabila versionen av SQL Server.
6. Lägg till Azure Cache för Redis?: Ja.
7. Värdplan: Grundläggande. När du är redo kan du skala upp till en produktionsprisnivå.
8. Välj Förhandsgranska + skapa.
9. När valideringen är klar, välj Skapa.

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

• Resursgrupp: Behållaren för alla skapade resurser.
• App Service plan: Definierar datorkapaciteten för App Service. En Linux-plan i Basic-nivån har skapats.
• App Service: Representerar din app och körs i App Service-planen.
• Virtuellt nätverk: Integrerat med App Service-appen och isolerar trafik för bakgrundsnätverk.
• Privata ändpunkter: Åtkomständpunkter för nyckelvalvet, databasservern och Redis-cache i det virtuella nätverket.
• Nätverksgränssnitt: Representerar privata IP-adresser, en för varje privat slutpunkt.
• Azure SQL Database server: Endast åtkomlig från dess privata slutpunkt.
• Azure SQL Database: En databas och en användare skapas för dig på servern.
• Azure Cache för Redis: Endast tillgänglig från dess privata slutpunkt.
• Key vault: Endast åtkomlig från bakom dess privata slutpunkt. Används för att hantera hemligheter för App Service-appen.
• Privata DNS-zoner: Aktivera DNS-upplösning av nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.

3. Säkerställ anslutningshemligheter

Guiden för skapande har redan genererat anslutningsvariabeln åt dig som .NET-anslutningssträngar och appinställningar. Den bästa praxis för säkerhet är att helt undvika att lagra hemligheter i App Service. Du flyttar dina hemligheter till ett nyckelvalv och ändrar din appinställning till Key Vault-referenser med hjälp av Service Connectors.

Tips

För att använda lösenordslös autentisering, se Hur ändrar jag SQL-databasanslutningen för att använda en hanterad identitet istället?

Steg 1: Hämta den befintliga anslutningssträng

1. I den vänstra menyn på App Service-sidan, välj Inställningar > Miljövariabler > Anslutningssträngar.
2. Välj AZURE_SQL_CONNECTIONSTRING.
3. I lägg till/redigera anslutningssträng, i värdefältet, hitta Password=-delen i slutet av strängen.
4. Kopiera lösenordssträngen efter Password= för senare användning. Denna anslutningssträng låter dig ansluta till SQL-databasen som är skyddad bakom en privat slutpunkt. Hemligheterna sparas dock direkt i App Service-appen, vilket inte är det bästa. Likaså innehåller anslutningssträngen till Redis-cache i fliken App-inställningar en hemlighet. Du kommer att ändra detta.

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

1. I det översta sökfältet skriver du "key vault", välj sedan Marknadsplats>Key Vault.
2. I Resursgrupp väljer du msdocs-core-sql-tutorial.
3. I Nyckelvalvets namn, skriv ett namn som endast består av bokstäver och siffror.
4. I Region anger du den till samma plats som resursgruppen.

Steg 3: Skydda nyckelvalvet med en privat slutpunkt

1. Välj fliken Nätverk.
2. Avmarkera Aktivera offentlig åtkomst.
3. Välj Skapa en privat slutpunkt.
4. I Resursgrupp väljer du msdocs-core-sql-tutorial.
5. I dialogrutan, i Plats, välj samma plats som din App Service-app.
6. I Namn skriver du msdocs-core-sql-XYZVvaultEndpoint.
7. I Plats väljer du samma plats som din App Service-app.
8. I Virtuellt nätverk väljer du msdocs-core-sql-XYZVnet.
9. På undernätetmsdocs-core-sql-XYZSubnet.
10. Välj OK.
11. Välj Granska + skapaoch välj sedan Skapa. Vänta tills distributionen av nyckelvalvet är klar. Du bör se "Din driftsättning är klar."

Steg 4:

1. I den översta sökrutan, skriv msdocs-core-sql, och sedan App Service-resursen kallad msdocs-core-sql-XYZ.
2. På sidan App Service, i den vänstra menyn, välj Inställningar > Service Connector. Det finns redan två anslutningar som appskapartrollkarlen har skapat åt dig.
3. Välj kryssrutan bredvid SQL-databaskopplingen, och välj sedan Edit.
4. Välj fliken Autentisering.
5. I Password klistrar du in lösenordet du kopierade tidigare.
6. Välj Lagra Hemlighet i Nyckelvalv.
7. Under Key Vault-anslutning, välj Skapa ny. Ett Skapa anslutning-dialogruta öppnas ovanpå redigeringsdialogrutan.

Steg 5: Upprätta Key Vault-anslutningen

1. I dialogrutan Skapa anslutning för Key Vault-anslutningen går du till Key Vault och väljer det nyckelvalv som du skapade tidigare.
2. Välj Granska + Skapa.
3. När valideringen är klar, välj Skapa.

Steg 6: Slutför inställningarna för SQL-databasanslutningen

1. Du är tillbaka i redigeringsdialogrutan för defaultConnector. I fliken Authentication, vänta på att nyckelvalvets anslutning ska skapas. När det är klart, väljer Key Vault Connection rullgardinsmenyn det automatiskt.
2. Välj Nästa: Nätverk.
3. Välj Spara. Vänta tills Uppdateringen lyckades meddelandet visas.

Steg 7: Konfigurera Redis-anslutningen för att använda Key Vault-hemligheter

1. På sidan Service Connector markerar du kryssrutan bredvid Cache for Redis-anslutningsappen och väljer sedan Redigera.
2. Välj fliken Autentisering.
3. Välj Lagra Hemlighet i Nyckelvalv.
4. Under Nyckelvalvanslutning, välj det nyckelvalv du skapade.
5. Välj Nästa: Nätverk.
6. Välj Konfigurera brandväggsregler för att möjliggöra åtkomst till målservice. Appskapare-guiden har redan säkrat SQL-databasen med en privat slutpunkt.
7. Välj Spara. Vänta tills Uppdateringen lyckades meddelandet visas.

Steg 8: Verifiera Key Vault-integreringen

1. Från den vänstra menyn, välj Inställningar > Miljövariabler > Anslutningssträngar igen.
2. Bredvid AZURE_SQL_CONNECTIONSTRING, välj Visa värde. Värdet ska vara @Microsoft.KeyVault(...), vilket betyder att det är en key vault reference eftersom hemligheten nu hanteras i nyckelvalvet.
3. För att verifiera Redis-anslutningssträngen, välj fliken App-inställningar. Bredvid AZURE_REDIS_CONNECTIONSTRING väljer du Visa värde. Värdet bör vara @Microsoft.KeyVault(...) också.

För att sammanfatta processen för att skydda dina anslutningshemligheter:

• Hämtar anslutningshemligheterna från App Service-appens miljövariabler.
• Skapar ett nyckelvalv.
• Skapa en Key Vault-anslutning med den systemtilldelade hanterade identiteten.
• Uppdatera tjänstanslutningarna för att lagra konfidentiell information i nyckelvalvet.

4. Distribuera exempelkod

I det här steget konfigurerar du GitHub-distributionen med hjälp av GitHub Actions. Det är bara ett av många sätt att distribuera till App Service, men också ett utmärkt sätt att ha kontinuerlig integration i din distributionsprocess. Som standard startar varje git push till ditt GitHub-förråd bygget och distributionen.

Steg 1: I den vänstra menyn, välj Distribuering>Distributionscenter.

Steg 2: På sidan Distributionscenter:

1. I Källa väljer du GitHub. Som standard är GitHub Actions vald som byggleverantör.
2. Logga in på ditt GitHub-konto och följ anvisningarna för att godkänna Azure.
3. I Organisation, välj ditt konto.
4. I Lagringsplats väljer du msdocs-app-service-sqldb-dotnetcore.
5. I Branch, välj starter-no-infra. Det här är samma gren som du arbetade med i din exempelapp, utan några Azure-relaterade filer eller konfiguration.
6. För Autentiseringstyp, välj Användartilldelad identitet.
7. I toppmenyn, välj Spara. App Service lägger till en arbetsflödesfil i den valda GitHub-repositoryn, i .github/workflows-katalogen. Som standard skapar distributionscentret en användartilldelad identitet för att arbetsflödet ska kunna autentisera med Microsoft Entra (OIDC-autentisering). Alternativa autentiseringsalternativ finns i Distribuera till App Service med GitHub Actions.

Steg 3: Gå tillbaka till GitHub-kodområdet för din exempelfork och kör git pull origin starter-no-infra. Detta hämtar den nyligen incheckade arbetsflödesfilen till din kodmiljö.

Steg 4 (Alternativ 1: med GitHub Copilot):

1. Börja en ny chattsession genom att välja Chat vyn och sedan välja +.
2. Fråga, "@arbetsyta Hur ansluter appen till databasen och cacheminnet?" Copilot kan ge dig en förklaring om MyDatabaseContext-klassen och hur den är konfigurerad i Program.cs.
3. Be, "I produktionsläge vill jag att appen ska använda anslutningssträngen som kallas AZURE_SQL_CONNECTIONSTRING för databasen och appinställningen som kallas AZURE_REDIS_CONNECTIONSTRING*." Copilot kan ge dig ett kodförslag som liknar det som visas i stegen för Alternativ 2: utan GitHub Copilot nedan och till och med be dig göra ändringen i filen Program.cs.
4. Ö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 kanske behöver ställa fler frågor för att finslipa dess svar. För tips, se Vad kan jag göra med GitHub Copilot i min kodmiljö?.

Steg 4 (alternativ 2: utan GitHub Copilot):

1. Öppna Program.cs i Utforskaren.
2. Hitta den kommenterade koden (raderna 12-21) och avkommentera den. Den här koden ansluter till databasen med hjälp av AZURE_SQL_CONNECTIONSTRING och ansluter till Redis-cacheminnet med hjälp av appinställningen AZURE_REDIS_CONNECTIONSTRING.

Steg 5 (Alternativ 1: med GitHub Copilot):

1. Öppna .github/workflows/starter-no-infra_msdocs-core-sql-XYZ i Utforskaren. Den här filen skapades av guiden för att skapa App Service.
2. Markera dotnet publish steget och välj .
3. Ask Copilot, "Installera dotnet ef, och skapa sedan ett migreringspaket i samma utdata-mapp."
4. Om förslaget är acceptabelt, välj Acceptera. GitHub Copilot ger dig inte samma svar varje gång och det är inte alltid korrekt. Du kanske behöver ställa fler frågor för att finslipa dess svar. För tips, se Vad kan jag göra med GitHub Copilot i min kodmiljö?.

Steg 5 (alternativ 2: utan GitHub Copilot):

1. Öppna .github/workflows/starter-no-infra_msdocs-core-sql-XYZ i Utforskaren. Den här filen skapades av guiden för att skapa App Service.
2. Under dotnet publish-steget, lägg till ett steg för att installera Entity Framework Core-verktyget med kommandot dotnet tool install -g dotnet-ef --version 8.*.
3. Under det nya steget, lägg till ett annat steg för att skapa ett databas migrationspaket i distributionspaketet: dotnet ef migrations bundle --runtime linux-x64 -o ${{env.DOTNET_ROOT}}/myapp/migrationsbundle. Migrationspaketet är en självständig körbar fil som du kan köra i produktionsmiljön utan att behöva .NET SDK. App Service Linux-behållaren har endast .NET-runtime och inte .NET SDK.

Steg 6:

1. Välj Source Control-tillägget.
2. I textrutan, skriv ett meddelande för commit som Configure Azure database and cache connections. Eller, välj och låt GitHub Copilot generera ett commit-meddelande åt dig.
3. Välj Commit, och bekräfta sedan med Ja.
4. Välj Sync changes 1, och bekräfta med OK.

Steg 7: Tillbaka på sidan för Deployment Center i Azure-portalen:

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

Steg 8: Du tas till ditt GitHub-repository och ser att GitHub-åtgärden är igång. Arbetsflödesfilen definierar två separata steg: bygga och distribuera. Vänta tills GitHub-körningen visar statusen Success. Det tar cirka 5 minuter.

Har du problem? Kontrollera felsökningssektionen.

5. Generera databasschema

Med SQL-databasen skyddad av det virtuella nätverket, är det enklaste sättet att köra dotnet databas-migreringar att använda en SSH-session med Linux-containern i App Service.

Steg 1: Tillbaka i App Service-sidan, i den vänstra menyn,

1. Välj Utvecklingsverktyg>SSH.
2. Välj Gå. (Starten tar några minuter.)

Steg 2: I SSH-sessionen:

1. Kör cd /home/site/wwwroot. Här är alla dina distribuerade filer.
2. Kör den migrationspaket som GitHub-arbetsflödet skapade, med kommandot ./migrationsbundle -- --environment Production. Om det lyckas, ansluter App Service framgångsrikt till SQL-databasen. Kom ihåg att --environment Production motsvarar kodändringarna du gjorde i Program.cs.

I SSH-sessionen kan endast ändringar av filer i /home bevara bortom appomstarter. Ändringar utanför /home sparas inte.

Har du problem? Kontrollera felsökningssektionen.

6. Bläddra till appen

Steg 1: På App Service-sidan:

1. Från vänstermenyn, välj Overview.
2. Välj URL:en för din app.

Steg 2: Lägg till några uppgifter på listan. Grattis, du kör en webbapp i Azure App Service, med säker anslutning till Azure SQL Database.

Tips

Exempelapplikationen implementerar cache-aside-mönstret. När du besöker en datavy för andra gången, eller laddar om samma sida efter att ha gjort dataändringar, visar Bearbetningstid på webbsidan en mycket snabbare tid eftersom den laddar data från cachen istället för databasen.

7. Strömma diagnostikloggar

Azure App Service fångar upp alla konsolloggfiler för att hjälpa dig att diagnostisera problem med din applikation. Exempelappen inkluderar loggningskod i var och en av sina slutpunkter för att demonstrera denna kapacitet.

Steg 1: På App Service-sidan:

1. Från menyn till vänster, välj Övervakning>App Service-loggar.
2. Under Programloggning väljer du Filsystem.
3. I toppmenyn, välj Spara.

Steg 2: Från den vänstra menyn, välj Loggström. 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 högst upp i Azure-portalen:

1. Ange namnet på resursgruppen.
2. Välj resursgruppen.

Steg 2: På sidan för resursgruppen, välj Ta bort resursgrupp.

Steg 3:

1. Ange namnet på resursgruppen för att bekräfta din radering.
2. Välj Ta bort.

2. Skapa Azure-resurser och distribuera en exempelapp

I detta steg skapar du Azure-resurser och distribuerar en exempelapplikation till App Service på Linux. Stegen som används i denna handledning skapar en uppsättning av resurser som är säkrade som standard, inklusive App Service, Azure SQL Database och Azure Cache för Redis.

Dev-containern har redan Azure Developer CLI (AZD).

1. Från kodförrådets rot, kör azd init.

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

2. När du uppmanas, ge följande svar:

   Fråga	Svar
   Den aktuella katalogen är inte tom. Vill du initiera ett projekt här i '<your-directory>'?	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 detta namn som en del av DNS-namnet för din webbapp i Azure (<app-name>-<hash>.azurewebsites.net). Alfanumeriska tecken och bindestreck är tillåtna.

3. Logga in på Azure genom att köra kommandot azd auth login och följ instruktionerna.

   azd auth login
   

4. Skapa de nödvändiga Azure-resurserna och distribuera appkoden med azd up-kommandot. Följ instruktionerna för att välja det önskade abonnemanget och platsen för Azure-resurserna.

   azd up
   

   Kommandot azd up tar cirka 15 minuter att slutföra (Redis-cachen tar mest tid). Den kompilering och driftsättning av din applikationskod görs också, men du kommer senare att ändra din kod för att fungera med App Service. När det körs, ger kommandot meddelanden om tillhandahållande- och driftsprocessen, inklusive en länk till driften i Azure. När det är klart visar kommandot också en länk till applikationen för distribution.

   Denna AZD-mall innehåller filer (azure.yaml och katalogen infra) som skapar en säker standardarkitektur med följande Azure-resurser:

   • Resursgrupp: Behållaren för alla skapade resurser.
   • App Service plan: Definierar datorkapaciteten för App Service. En Linux-plan i Basic-nivån har skapats.
   • App Service: Representerar din app och körs i App Service-planen.
   • Virtuellt nätverk: Integrerat med App Service-appen och isolerar trafik för bakgrundsnätverk.
   • Privata ändpunkter: Åtkomständpunkter för nyckelvalvet, databasservern och Redis-cache i det virtuella nätverket.
   • Nätverksgränssnitt: Representerar privata IP-adresser, en för varje privat slutpunkt.
   • Azure SQL Database server: Endast åtkomlig från dess privata slutpunkt.
   • Azure SQL Database: En databas och en användare skapas för dig på servern.
   • Azure Cache för Redis: Endast tillgänglig från dess privata slutpunkt.
   • Key vault: Endast åtkomlig från bakom dess privata slutpunkt. Används för att hantera hemligheter för App Service-appen.
   • Privata DNS-zoner: Aktivera DNS-upplösning av nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.

   När kommandot har avslutat att skapa resurser och distribuera applikationskoden för första gången, fungerar inte den distribuerade exempelappen än eftersom du måste göra små ändringar för att få den att ansluta till databasen i Azure.

Har du problem? Kontrollera felsökningssektionen.

3. Bekräfta anslutningssträngar

Tips

Standardsträngen för anslutning till SQL-databasen använder SQL-autentisering. För mer säker och lösenordslös autentisering, se Hur ändrar jag SQL-databasanslutningen för att istället använda en hanterad identitet?

AZD-mallen du använder har redan genererat anslutningsvariablerna åt dig som appinställningar och skickar dem till terminalen för din bekvämlighet. Inställningar för appar är ett sätt att hålla anslutningshemligheter utanför din koddatabas.

1. I AZD-utdata, hitta inställningarna AZURE_SQL_CONNECTIONSTRING och AZURE_REDIS_CONNECTIONSTRING. Endast inställningsnamnen visas. De ser ut så här i AZD-utmatningen.

    App Service app has the following connection strings:
        - AZURE_SQL_CONNECTIONSTRING
        - AZURE_REDIS_CONNECTIONSTRING
        - AZURE_KEYVAULT_RESOURCEENDPOINT
        - AZURE_KEYVAULT_SCOPE
    

   AZURE_SQL_CONNECTIONSTRING innehåller anslutningssträngen till SQL-databasen i Azure, och AZURE_REDIS_CONNECTIONSTRING innehåller anslutningssträngen till Azure Redis-cachen. Du behöver använda dem i din kod senare.

2. För din bekvämlighet visar AZD-mallen dig den direkta länken till appens inställningssida. Hitta länken och öppna den i en ny flik i webbläsaren.

Har du problem? Kontrollera felsökningssektionen.

4. Modifiera exempelkoden och återsätt i drift

Med GitHub Copilot

1. I GitHub-kodutrymmet, starta en ny chatt-session genom att välja vyn Chat och sedan välja +.

2. Fråga, "@arbetsyta Hur ansluter appen till databasen och cacheminnet?" Copilot kan ge dig en förklaring om MyDatabaseContext-klassen och hur den är konfigurerad i Program.cs.

3. Be, "I produktionsläge vill jag att appen ska använda anslutningssträngen som kallas AZURE_SQL_CONNECTIONSTRING för databasen och appinställningen som kallas AZURE_REDIS_CONNECTIONSTRING*." Copilot kan ge dig ett kodförslag som liknar det som visas i stegen för Alternativ 2: utan GitHub Copilot nedan och till och med be dig göra ändringen i filen Program.cs.

4. Ö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 kanske behöver ställa fler frågor för att finslipa dess svar. För tips, se Vad kan jag göra med GitHub Copilot i min kodmiljö?.

1. Från utforskaren, öppna Program.cs.

2. I contextIntialized()-metoden, hitta den kommenterade koden (rader 12-21) och avkommentera den.

   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 (som i Azure App Service) ansluter den här koden till databasen med hjälp av AZURE_SQL_CONNECTIONSTRING 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 migrationspaket.

Har du problem? Kontrollera felsökningssektionen.

5. Generera databasschema

Med SQL-databasen skyddad av det virtuella nätverket är det enklaste sättet att köra databasöverföringar i en SSH-session med App Service-behållaren. Linux-behållare för App Service har dock inte .NET SDK, så det enklaste sättet att köra databasomvandlingar är att ladda upp en självständig omvandlingspaket.

1. Generera ett migreringspaket för ditt projekt med följande kommando:

   dotnet ef migrations bundle --runtime linux-x64 -o migrationsbundle
   

   Tips

   Exempelapplikationen (se DotNetCoreSqlDb.csproj) är konfigurerad för att inkludera denna migrationsbundle-fil. Under azd package stadiet kommer migrationspaketet att läggas till distributionspaketet.

2. Implementera alla ändringar med azd up.

   azd up
   

3. I AZD-utdata letar du reda på 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: <URL>
    

4. I SSH-sessionen, kör följande kommandon:

   cd /home/site/wwwroot
   ./migrationsbundle -- --environment Production
   

   Om det lyckas, har App Service anslutits framgångsrikt till databasen. Kom ihåg att --environment Production motsvarar kodändringarna du gjorde i Program.cs.

   Anmärkning

   Endast ändringar i filer i /home kan bevaras utöver omstarter av appar. Ändringar utanför /home sparas inte.

Har du problem? Kontrollera felsökningssektionen.

6. Bläddra till appen

1. I AZD:s utskrift, hitta URL:en till din app och navigera till den i webbläsaren. URL:en ser ut så här i AZD-utdata:

    Deploying services (azd deploy)
   
      (✓) Done: Deploying service web
      - Endpoint: <URL>
    

2. Lägg till några uppgifter på listan.

   

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

Har du problem? Kontrollera felsökningssektionen.

7. Strömma diagnostikloggar

Azure App Service kan fånga konsolloggar för att hjälpa dig att diagnostisera problem med din applikation. För enkelhetens skull har AZD-mallen redan aktiverat loggning till det lokala filsystemet och skickar loggarna till ett Log Analytics-arbetsområde.

Exempelapplikationen inkluderar standardloggningsuttryck för att demonstrera denna kapacitet, som visas i följande kodexempel:

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, hitta 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:s resultat:

Stream App Service logs at: <URL>

Lär dig mer om loggning i .NET-appar i serien Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications.

Har du problem? Kontrollera felsökningssektionen.

8. Rensa resurser

För att radera alla Azure-resurser i den aktuella driftsmiljön, kör azd down och följ instruktionerna.

azd down

Felsökning

• Portalens distributionsvy för Azure SQL Database visar status Konflikt
• I Azure-portalen visar loggströmsgränssnittet för webbappen nätverksfel
• SSH-sessionen i webbläsaren visar SSH CONN CLOSED
• Portalsidans loggström visar Connected! men inga loggar

Portalens distributionsvy för Azure SQL Database visar en Konfliktstatus

Beroende på din prenumeration och den region du väljer kan du se att distributionsstatusen för Azure SQL Database är Conflict, med följande meddelande i operationsdetaljerna:

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

Detta fel beror troligtvis på en begränsning i din prenumeration för den region du har valt. Försök att välja en annan region för din distribution.

I Azure-portalen visar loggström UI 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 övergående fel när appen startas för första gången. Vänta några minuter och kontrollera igen.

SSH-sessionen i webbläsaren visar SSH CONN CLOSED

Det tar några minuter för Linux-behållaren att starta. Vänta några minuter och kontrollera igen.

Portalloggflödessidan visar Connected! men inga loggar

När du konfigurerar loggar för diagnostik startas appen om. Du kan behöva uppdatera sidan för att ändringarna ska träda i kraft i webbläsaren.

Vanliga frågor

• Hur mycket kostar denna setup?
• Hur ansluter jag till Azure SQL-databasservern som är säkrad bakom det virtuella nätverket med andra verktyg?
• Hur fungerar lokal apputveckling med GitHub Actions?
• Hur felsöker jag fel under GitHub Actions-utbyggnaden?
• Hur ändrar jag SQL-databasanslutningen till att istället använda en hanterad identitet?
• Jag har inte behörighet att skapa en användartilldelad identitet
• Vad kan jag göra med GitHub Copilot i min kodmiljö?

Hur mycket kostar denna setup?

Prissättningen för de skapade resurserna är som följer:

• App Service-planen skapas i Basic-nivån och kan skalas upp eller ner. Se App Service-prissättning.
• Azure SQL-databasen skapas i den allmänna serverlösa nivån på standardseriehårdvara med minsta antal kärnor. Det finns en liten kostnad och det kan distribueras till andra regioner. Du kan minska kostnaderna ännu mer genom att reducera dess maximala storlek, eller du kan öka den genom att justera tjänstnivån, beräkningsnivån, hårdvarukonfigurationen, antalet kärnor, databassstorlek och zonsredundans. Se Priser för Azure SQL Database.
• Azure Cache för Redis skapas i Basic-nivån med den minsta cache-storleken. Det finns en liten kostnad i samband med denna nivå. Du kan skala upp det 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 medför inga avgifter om du inte konfigurerar extra funktioner, såsom peering. Se Priser för Azure Virtual Network.
• Den privata DNS-zonen medför en liten avgift. Se Priser för Azure DNS.

Hur ansluter jag till Azure SQL Database-servern som är säkrad 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 kommer inte med sqlcmd, så du måste installera den manuellt. Kom ihåg att den installerade klienten inte bibehålls vid omstarter av appen.
• För att ansluta från en SQL Server Management Studio-klient eller från Visual Studio, måste din dator vara inom det virtuella nätverket. Till exempel kan det vara en Azure VM som är ansluten till ett av de nätverkssegmenten, eller en dator i ett lokalt nätverk som har en site-to-site VPN-anslutning med det virtuella Azure-nätverket.

Hur fungerar lokal apputveckling med GitHub Actions?

Ta filen med den autogenererade arbetsflödesfilen från App Service som ett exempel, varje git push startar en ny bygg- och distributionskörning. Från en lokal klon av GitHub-förvaret gör du de önskade uppdateringarna och pushar dem till GitHub. Till exempel:

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

Hur felsöker jag fel under GitHub Actions-distributionen?

Om ett steg misslyckas i den autogenererade GitHub-arbetsflödesfilen, prova att ändra det misslyckade kommandot för att generera mer detaljerad utdata. Till exempel kan du få mer output från vilken som helst av dotnet-kommandona genom att lägga till -v-alternativet. Utför och skicka dina ändringar för att utlösa ytterligare en distribution till App Service.

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

Se Ställ in GitHub Actions-distribution från distributionscentret.

Hur ändrar jag SQL-databasanslutningen så att den istället använder en hanterad identitet?

Standardanslutningssträngen till SQL-databasen hanteras av Service Connector, med namnet defaultConnector, och den använder SQL-autentisering. För att ersätta den med en anslutning som använder en hanterad identitet, kör följande kommandon i cloud shell efter att ha 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:

• Ställer in din användare som administratör för Microsoft Entra ID på SQL-databasservern.
• Skapa en systemtilldelad hanterad identitet och ge den åtkomst till databasen.
• Skapar en lösenordsfri anslutningssträng kallad AZURE_SQL_CONNECTIONGSTRING, som din app redan använder i slutet av handledningen.

Din app bör nu ha anslutning till SQL-databasen. För mer information, se Tutorial: Connect to Azure databases from App Service without secrets using a managed identity.

Tips

Vill du inte aktivera anslutning till offentligt nätverk? Du kan hoppa över az sql server update --enable-public-network true genom att köra kommandona från en Azure Cloud Shell som är integrerad med ditt virtuella nätverk om du har rolltilldelningen Ägare på ditt abonnemang.

För att tilldela identiteten den nödvändiga åtkomsten till databasen som säkras av det virtuella nätverket, behöver az webapp connection create sql direkt anslutning med Entra ID-autentisering till databasservern. Som standard har Azure cloud shell inte denna åtkomst till den nätverkssäkrade databasen.

Vad kan jag göra med GitHub Copilot i min kodmiljö?

Du kanske har märkt att GitHub Copilot-chattvyn redan fanns där för dig när du skapade kodespacet. För din bekvämlighet inkluderar vi GitHub Copilot chat extension i containerdefinitionen (se .devcontainer/devcontainer.json). Du behöver dock ett GitHub Copilot-konto (30 dagars gratis provperiod tillgänglig).

Några tips för dig 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 svaret du får.
• Som standard har GitHub Copilot inte åtkomst till några filer i ditt arkiv. För att ställa frågor om en fil, öppna filen i redigeraren först.
• För att ge GitHub Copilot tillgång till alla filer i arkivet när den förbereder sina svar, börja din fråga med @workspace. För mer information, se Use the @workspace agent.
• I chattsessionen kan GitHub Copilot föreslå ändringar och (med @workspace) till och med var ändringarna ska gö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 det.

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

• Jag vill att denna kod endast ska köras i produktionsläge.
• Jag vill att denna kod endast ska köras i Azure App Service och inte lokalt.
• Parametern --output-path verkar vara osupportad.

Relaterat innehåll

Gå vidare till nästa handledning för att lära dig hur du säkrar din app med en anpassad domän och certifikat.

  Säkra med anpassad domän och certifikat

Eller, kolla in andra resurser:

Tutorial: Anslut till SQL-databasen från App Service utan hemligheter med en hanterad identitet

Konfigurera ASP.NET Core-appen