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

I den här handledningen lär du 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 Redis-cache för att aktivera cachelagringskoden i ditt program. Azure App Service är en mycket skalbar, självuppdaterande webbhostingstjänst som enkelt kan distribuera appar på Windows eller Linux. Även om den här handledningen använder en ASP.NET Core 8.0-app är processen densamma för andra versioner av ASP.NET Core.

Viktigt!

Azure Cache for Redis meddelade sin tidslinje för pensionering för alla SKU:er. Vi rekommenderar att du flyttar dina befintliga Azure Cache for Redis-instanser till Azure Managed Redis så snart du kan.

Migreringsvägledning:

Mer information om pensionering:

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 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.
  • 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.
  • Strömma diagnostikloggar från Azure.
  • Hantera appen i Azure-portalen.
  • 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 kan skapa ett kostnadsfritt.
  • Ett GitHub konto. Du kan också få en gratis.
  • Kunskap om ASP.NET Core utveckling.
  • (Valfritt) Om du vill prova GitHub Copilot GitHub Copilot konto. En 30-dagars gratis provperiod är tillgänglig.

Hoppa till slutet

Om du bara vill se exempelappen i den här självstudien som körs i Azure kör du bara följande kommandon i Azure Cloud Shell och följer 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 sätter du upp en exempelapp baserad på data som en startpunkt. För din bekvämlighet innehåller sample-lagringsplatsen en dev-container konfiguration. 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. 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.

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

  1. Logga in på ditt GitHub-konto.
  2. Gå 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 förgrening:

  1. Välj main>starter-no-infra för startgrenen. Den här grenen innehåller bara 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 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ökningssektionen.

2. Skapa App Service, databas och cache

I det här steget skapar du Azure resurser. Stegen som används i denna handledning skapar en uppsättning säkra resurser som standard, inklusive 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 där du väljer den .NET version som ska användas 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. Med en resursgrupp kan du gruppera (i en logisk container) alla Azure resurser som behövs för programmet.

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. I det övre sökfältet skriver du App Service.
  2. Välj objektet med etiketten App Service under rubriken Tjänster .
  3. Välj Skapa>webbapp. Du kan också navigera direkt till guiden för skapande.

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

  1. Namn: msdocs-core-sql-XYZ. En resursgrupp med namnet msdocs-core-sql-XYZ_group genereras åt dig.
  2. Körmiljö: .NET 8 (LTS).
  3. Operativsystem: Linux.
  4. Region: önskad region.
  5. Linux-plan: Skapa ny och använd namnet msdocs-core-sql-XYZ.
  6. Prisplan: Bas B1. När du är redo kan du skala upp till en annan prisnivå.

Steg 3:

  1. Välj fliken Databas .
  2. Välj Skapa en databas.
  3. I Motor väljer du SQLAzure.
  4. Skapa en Redis-cache.
  5. I Namn (under Cache) anger du ett namn för cachen.
  6. I SKU väljer du Grundläggande.

Steg 4:

  1. Välj fliken Distribution .
  2. Aktivera kontinuerlig distribution.
  3. I Organization väljer du ditt GitHub alias.
  4. I Lagringsplats väljer du msdocs-app-service-sqldb-dotnetcore.
  5. I Branch, välj starter-no-infra.
  6. Kontrollera att Grundläggande autentisering är inaktiverat.
  7. Välj Förhandsgranska + skapa.
  8. När valideringen är klar, välj Skapa.

Steg 5: Implementeringen tar några minuter att bli klar. 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-servern: Endast tillgänglig från bakom dess privata slutpunkt.
  • Azure SQL Database: En databas och en användare skapas åt dig på servern.
  • Redis: Redis kan bara nås genom sin privata slutpunkt.
  • Key vault: Endast åtkomlig från bakom dess privata slutpunkt. Används för att hantera hemligheter för App Service-appen.
  • Private DNS-zon: Aktivera DNS-upplösning för nyckelvalvet, databasservern och Redis-cachen i det virtuella nätverket.

3. Säkerställ anslutningshemligheter

Guiden har redan skapat anslutningsvariabeln åt dig som .NET-anslutningssträngar och app-instä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 appinställningen till Key Vault-referenser med hjälp av Service Connectors.

Steg 1: Hämta den befintliga connection string

  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 Add/Edit connection string hittar du fältet Password= i slutet av strängen i fältet Value.
  4. Kopiera lösenordssträngen efter Password= för senare användning. Med den här connection string kan du ansluta till SQL-databasen som skyddas bakom en privat slutpunkt. Hemligheterna sparas dock direkt i App Service-appen, vilket inte är det bästa. På samma sätt innehåller App-inställningar-fliken en connection string för Redis-cache med känslig information. Du kommer att ändra detta.

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

  1. I det övre sökfältet skriver du "key vault" och väljer sedan Marketplace>Key Vault.
  2. I Resursgrupp väljer du msdocs-core-sql-XYZ_group.
  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-XYZ_group.
  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 Virtuellt nätverk väljer du det virtuella nätverket i gruppen msdocs-core-sql-XYZ_group .
  8. I Undernät väljer du det tillgängliga kompatibla undernätet. Webbappsguiden skapade den för din bekvämlighet.
  9. Välj OK.
  10. 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 Key Vault.
  7. Under Key Vault Anslutning väljer du Skapa ny. Ett Skapa anslutning-dialogruta öppnas ovanpå redigeringsdialogrutan.

Steg 5: Upprätta Key Vault anslutning

  1. I dialogrutan Skapa anslutning för den Key Vault anslutningen i Key Vault väljer du key vault 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äljs det automatiskt i listrutan Key Vault Connection.
  2. Välj Nästa: Nätverk.
  3. 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.
  4. Välj Spara. Vänta tills Uppdateringen lyckades meddelandet visas.

Steg 7: Konfigurera Redis-anslutningsappen så att den använder 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 Key Vault.
  4. Under Key Vault Anslutning väljer du den key vault 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.
  7. Välj Spara. Vänta tills Uppdateringen lyckades meddelandet visas.

Steg 8: Verifiera för 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 innebär att det är en key vault-referens eftersom hemligheten nu hanteras i nyckelvalvet.
  3. Kontrollera Redis-anslutningssträngen genom att välja fliken Inställningar för appar. Bredvid AZURE_REDIS_CONNECTIONSTRING väljer du Visa värde. Värdet ska också vara @Microsoft.KeyVault(...).

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 distribution 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 din GitHub-lagringsplats bygg- och distributionsåtgärden.

Steg 1: Tillbaka i GitHub kodområdet för din exempelfork, kör git pull origin starter-no-infra. Detta hämtar den nyligen incheckade arbetsflödesfilen till din kodmiljö.

Steg 2 (alternativ 1: med GitHub Copilot):

  1. Börja en ny chattsession genom att välja Chat vyn och sedan välja +.
  2. Fråga: "@workspace Hur ansluter appen till databasen och cachen?" Copilot kan ge dig en förklaring om klassen MyDatabaseContext och hur den konfigureras i Program.cs.
  3. Fråga: "I produktionsläge vill jag att appen ska använda connection string 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 Option 2: utan GitHub Copilot steg som följer och till och med be dig att 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. Tips finns i Vad kan jag göra med GitHub Copilot i kodområdet?.

Steg 2 (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 3 (alternativ 1: med GitHub Copilot):

  1. Öppna .github/workflows/starter-no-infra_msdocs-core-sql-XYZ i Utforskaren. Guiden Skapa App Service skapade den här filen.
  2. Markera dotnet publish steget och välj .
  3. Ask Copilot" Installera dotnet ef och skapa sedan ett migreringspaket i samma utdatamapp."
  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. Tips finns i Vad kan jag göra med GitHub Copilot i kodområdet?.

Steg 3 (alternativ 2: utan GitHub Copilot):

  1. Öppna .github/workflows/starter-no-infra_msdocs-core-sql-XYZ i Utforskaren. Guiden för att skapa App Service skapade den här filen
  2. Under steget dotnet publish lägger du till ett steg för att installera verktyget Entity Framework Core 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. 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örning och inte .NET SDK.

Steg 4:

  1. Välj Source Control-tillägget.
  2. 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.
  3. Välj Commit, och bekräfta sedan med Ja.
  4. Välj Sync changes 1, och bekräfta med OK.

Steg 5: Tillbaka på sidan Distributionscenter 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 6: Du tas till din GitHub lagringsplats och ser att åtgärden GitHub körs. Arbetsflödesfilen definierar två separata steg: bygga och distribuera. Vänta tills GitHub körs för att visa 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 . (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 migreringspaketet som GitHub arbetsflödet genererade 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 läser in samma sida igen när du har gjort dataändringar, visar bearbetningstiden på webbsidan en 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 konsolloggar som hjälper dig att diagnostisera problem med ditt program. 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 överst 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 det här steget skapar du Azure resurser och distribuerar en exempelapp till App Service on Linux. Stegen som används i den här självstudien skapar en uppsättning säkra standardresurser som inkluderar App Service, Azure SQL Database och Redis-cache.

Utvecklingscontainern 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 det här namnet som en del av DNS-namnet på 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ölja kommandotolken:

    azd auth login
    
  4. Skapa nödvändiga Azure resurser och distribuera appkoden med kommandot azd up. Följ uppmaningen för att välja önskad prenumeration och plats för de 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 innehåller kommandot meddelanden om etablerings- och distributionsprocessen, inklusive en länk till distributionen i Azure. När det är klart visar kommandot också en länk till applikationen för distribution.

    Den här AZD-mallen innehåller filer (azure.yaml och katalogen infra) som genererar en säker arkitektur som standard 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-servern: Endast tillgänglig från bakom dess privata slutpunkt.
    • Azure SQL Database: En databas och en användare skapas åt dig på servern.
    • Redis: Endast tillgänglig via sin privata slutpunkt.
    • Key vault: Endast åtkomlig från bakom dess privata slutpunkt. Används för att hantera hemligheter för App Service-appen.
    • Private DNS-zon: Aktivera DNS-upplösning för 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ökningssektionen.

3. Bekräfta anslutningssträngar

Tips

Sql-standarddatabasen connection string 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

  1. I GitHub-kodområdet startar du en ny chattsession genom att välja vyn Chat och sedan välja +.

  2. Fråga: "@workspace Hur ansluter appen till databasen och cachen?" Copilot kan ge dig en förklaring om klassen MyDatabaseContext och hur den konfigureras i Program.cs.

  3. Fråga: "I produktionsläge vill jag att appen ska använda connection string 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 Option 2: utan GitHub Copilot steg som följer och till och med be dig att 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. Tips finns i Vad kan jag göra med GitHub Copilot i kodområdet?.

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. 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.

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

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

    Tips

    Exempelprogrammet (se DotNetCoreSqlDb.csproj) har konfigurerats för att inkludera den här filen migrationsbundle. 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.

    En skärmbild av ASP.NET Core-webbappen med en SQL-databas som körs på Azure, som visar uppgifter.

    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 samla in konsolloggar som hjälper dig att diagnostisera problem med ditt program. För bekvämlighetens skull har AZD-mallen redan aktiverat loggning till det lokala filsystemet och skickar loggarna till en Log Analytics-arbetsyta.

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äs mer om loggning i .NET-appar i serien om Enable Azure Monitor OpenTelemetry för .NET, Node.js, Python och Java-applikationer.

Har du problem? Kontrollera felsökningssektionen.

8. Rensa resurser

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

azd down

Felsökning

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.

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ö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 ö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?

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 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 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 Azure SQL Database priser.
  • Azure Cache for Redis skapas på nivån Basic med minsta cachestorlek. 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 för Redis. Mer information finns i Priser för Azure Managed Redis.
  • Det virtuella nätverket medför inga avgifter om du inte konfigurerar extra funktioner, såsom peering. Se Azure Virtual Network priser.
  • Den privata DNS-zonen medför en liten avgift. Se Azure DNS priser.

Hur ansluter jag till den Azure SQL Database server 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 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.
  • 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 Azure virtuell dator som är ansluten till ett av undernäten, eller en dator i ett lokalt nätverk som har en site-to-site VPN anslutning till det Azure virtuella nätverket.

Hur fungerar utveckling av lokala appar 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-lagringsplatsen 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 distributionen av GitHub Actions?

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. 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 Distribueringscentret.

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

Service Connector hanterar standard connection string till SQL-databasen med namnet defaultConnector och 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:

  • 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 en lösenordslös anslutningssträng med namnet AZURE_SQL_CONNECTIONGSTRING, som appen redan använder i slutet av guiden.

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

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 ett Azure cloud shell som är integrerat med ditt virtuella nätverk om du har Owner rolltilldelning för din prenumeration.

För att ge identiteten den nödvändiga åtkomsten till databasen som skyddas av det virtuella nätverket behöver az webapp connection create sql 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. Vi inkluderar 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 svaret du får.
  • Som standard har GitHub Copilot inte åtkomst till någon fil på lagringsplatsen. För att ställa frågor om en fil, öppna filen i redigeraren först.
  • Börja frågan med @workspace om du vill ge GitHub Copilot åtkomst till alla filer på lagringsplatsen när du förbereder dess svar. För mer information, se 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 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 den här koden bara ska köras i Azure App Service och inte lokalt.
  • Parametern --output-path verkar vara osupportad.

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.

Eller, kolla in andra resurser: